From jpuydt at free.fr Thu Jun 15 04:54:55 2006 From: jpuydt at free.fr (Julien PUYDT) Date: Thu, 15 Jun 2006 10:54:55 +0200 Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code Message-ID: <4491205F.5070708@free.fr> Hi, in private mails (with quite big attachments since I provided some sample stupid code), ?ric Bischoff found my code not that explicit concerning what I have in mind. Since I would like to keep things as opened as possible, I drop my text here :-) Let's see if I can manage to give useful ideas. ***** BIG WORDS Model - View - Controller ***** VIEWING (GENERIC) We need to be able to present a book to the user. For that, the view needs to have a list of contacts (no, a single contact definitely isn't enough!). So we need a function call to get a list of contacts. The problem is that this list will change during time (new contacts added, others removed, presence changed, status message changed, and the list goes on). So the view will need to be notified about it. Hence the idea that the book will have "contact-added" and "contact-removed" signals, and the contacts a "updated" signal. In addition to that, there is an interesting special case to handle : you have a contact in a book, and this contact shows up in a search result. When you remove the contact from the book, we want to make it disappear from the list too. Hence a "removed" signal for contacts. Now this is all nice, but what can we do if an addressbook contains millions of entries ? And if a search gives thousands of results ? In such cases, my stance is that the low level code should do something about it, since it is the one giving the problem. How can the high level code cope correctly with the situation anyway ? Only the low level code can say "Eh, I already made two hundred contacts go through the wire for that search, perhaps I should make it easy!". The question to really ask, and to which I have no satisfactory answer is: "How do me make the low level tell the high level it had to cut the list ?". ***** VIEWING (CONTACTS) The contacts should contain enough to be viewed from a generic view in the contacts window, and be shown in a search result. That won't prevent some other parts of the code to make a better use of them. For example, in the contact window we will probably be able to see a contact's title and description, but not its detailed presence, while the main window will contain a much better and more specific view for the live contacts. ***** CONTROLLING (GENERIC) Now, we want to be able to act on our objects ; say rename a book or a contact, subscribe/unsubscribe to its presence, etc. The best thing to do is to be able to get menus for each of them. Notice the plural: we will certainly to have at least menu in the menu bar and a popup menu. The first bad news about such menus is that they won't be generic : they will depend heavily on the specific type of object (no rename for avahi contacts, subscribe/unsubscribe only for XMPP contacts...). So we will certainly need some sort of shared actions that will be basic bricks for building menu (like the shared-actions.[ch] of my first round of proposals), that each implementation will mix as it sees fit. The second bad news about them is that they won't be static either. They will have to update themselves following the object they are attached to. Say your nice XMPP contact is connected with a client which has VoIP support, but now connects with a no-VoIP client, and disconnects the first : we want the "Call" menuitem to disappear to reflect this. So my proposition (no code yet) is that those menus will be obtained by subclassing of GtkMenu, register to get signals from the contact/book they are attached to, and use that to keep themselves up to date. ***** CONTROLLING (CONTACTS) Let's try to be more specific: in avahi-contact-menu.h, we would have: GtkWidget *avahi_contact_menu_new (AvahiContact *contact); and in gm-contact.h: GtkWidget *gm_contact_get_menu_new (GmContact *contact); This later function would be different in each implementation, which allows for example the avahi_contact_get_menu_new implementation to call avahi_contact_menu_new. The high level code called a generic function, but got access to a very specific implementation, which knows the full api of the specific contact, and hence will provide the best service. ***** CONTROLLING (BOOKS) Perhaps the menu shouldn't be attached to the book himself, but to its view. That would allow to place things such as "Show offline contacts" in it. Mostly the idea would be to have controllers for both the model-as-model and its view-as-model. ***** ABOUT EVOLUTION-DATA-SERVER The evolution-data-server api looks pretty good -- except that it seems to mainly handle static vcard-based contacts, where I would like to be able to handle things like. For example, we find a nice contacts-changed signal, but in the EBookView api... not in the EBook api, which seems strange. ***** ABOUT LIBGAIM I shriek everytime I read/think about that comment in blist.h (just before the declaration of struct _GaimBuddy) : "A buddy. This contains everything Gaim will ever need to know about someone on the buddy list. Everything." (sic). and that one (before the declaration of struct _GaimContact) : "A contact. This contains everything Gaim will ever need to know about a contact." and that one (before the declaration of struct _GaimGroup) : "A group. This contains everything Gaim will ever need to know about a group." Notice that the comment before struct _GaimChat, although very similar, isn't so bad in my eye :-) Notice too that although I find the way it is done inelegant, it still is very good and efficient to get the job done, and contains quite an impressive list of good ideas. (And it's more portable as ekiga, gasp!) ***** ABOUT LIBGALAGO Why, why, oh why does it contain a GalagoList api which looks so much like a GList but isn't !? Apart from that, I would say it looks nice, but is out of scope for what we want to do right now : it doesn't deal with addressbooks, but with persons as single. "Using" it would be nice at some point. ***** LAST WORDS Congratulations, comments and flames welcome, but flames will end in /dev/null. Snark PS: this message is already two or three days old... but got stuck. From ebischoff at nerim.net Thu Jun 15 07:18:05 2006 From: ebischoff at nerim.net (=?utf-8?q?=C3=89ric_Bischoff?=) Date: Thu, 15 Jun 2006 13:18:05 +0200 Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code In-Reply-To: <4491205F.5070708@free.fr> References: <4491205F.5070708@free.fr> Message-ID: <200606151318.05338.ebischoff@nerim.net> Hi Julien, and thanks for this nice document. That looks like a good basis for thinking aloud :-). Le Jeudi 15 Juin 2006 10:54, Julien PUYDT a ?crit?: > ***** BIG WORDS > > Model - View - Controller Excellent basis. > ***** VIEWING (GENERIC) > > We need to be able to present a book to the user. For that, the view > needs to have a list of contacts (no, a single contact definitely isn't > enough!). So we need a function call to get a list of contacts. In this paragraph I will assume that you mean "the view needs a list of all contacts from the address book driver". If it is not what you mean, please ignore this paragraph... The view needs to display, say, 10 contects at a time. No need to keep a list of all contacts in memory. All we "need" is a function that gets _one_ contact from the driver. The view can then use this information to keep the list of the 10 contacts that it currently displays. > The problem is that this list will change during time (new contacts > added, others removed, presence changed, status message changed, and the > list goes on). So the view will need to be notified about it. Hence the > idea that the book will have "contact-added" and "contact-removed" > signals, and the contacts a "updated" signal. > In addition to that, there is an interesting special case to handle : > you have a contact in a book, and this contact shows up in a search > result. When you remove the contact from the book, we want to make it > disappear from the list too. Hence a "removed" signal for contacts. While this sounds cool, I am not sure that this will be possible in some circumstances. The underlying address book (evolution, KDE address book, LDAP server, Zeroconf, ...) might not have the mechanisms to send such a signal. I can imagine situations where some users on machine A update a LDAP server on machine B while Ekiga runs on machine C, with the network connection between B and C being temporarily broken. Will an update message come up to the driver, and if yes when and how? Please notice that I do not know LDAP well and that such mechanisms might exist. Should that be the case, please ignore these paragraphs. What do I propose instead? To be less ambitious, and have an address book that only pulls the data from the data source. If the user does not press "refresh", then he/she might have outdated information. If he/she presses "refresh", then the addresses are fetched again from the source. > Now this is all nice, but what can we do if an addressbook contains > millions of entries ? And if a search gives thousands of results ? In > such cases, my stance is that the low level code should do something > about it, since it is the one giving the problem. I do not like that repartition of tasks. Let me take an example. When you write an operating system, you write: - disk drivers (the low level code that does physical read and write from and to the hard disk) - a filesystem (the high level code that gathers individual sectors into files, handles a cache, etc) The low level code should not be bothered with handling the disk cache. Okay, the problem comes from the disk driver, because it does slow access to the medium. That does not mean that it's not another component, the filesystem, that can solve it. Why this repartition of tasks? Because the performance problem is a problem that can be shared by many disk drivers. Therefore, the solution can be put in common in the high level code. > How can the high level > code cope correctly with the situation anyway ? Only the low level code > can say "Eh, I already made two hundred contacts go through the wire for > that search, perhaps I should make it easy!". Why transfer 200 contacts when the view knows that it needs only 10? > The question to really ask, and to which I have no satisfactory answer > is: "How do me make the low level tell the high level it had to cut the > list ?". The views know that contacts 301 to 309 are displayed. It's the view that knows where to cut. In fact, there's nothing to cut, since all the view does is ask the driver for the contects it needs. > ***** VIEWING (CONTACTS) > > The contacts should contain enough to be viewed from a generic view in > the contacts window, and be shown in a search result. That won't prevent > some other parts of the code to make a better use of them. > > For example, in the contact window we will probably be able to see a > contact's title and description, but not its detailed presence, while > the main window will contain a much better and more specific view for > the live contacts. You say that the "contact" class must have _enough_ information to be used both in situation A and in sitation B. It would be better to have _different_ "contact" classes for situations "A" and "B". The list of contacts could just manage a name, a company and a phone number. The search result could handle much more detailed information. In other words, there's no need to put all the model's data into the views' data. Each view can handle the data it needs. > ***** CONTROLLING (GENERIC) > > Now, we want to be able to act on our objects ; say rename a book or a > contact, subscribe/unsubscribe to its presence, etc. > > The best thing to do is to be able to get menus for each of them. Notice > the plural: we will certainly to have at least menu in the menu bar and > a popup menu. > > The first bad news about such menus is that they won't be generic : they > will depend heavily on the specific type of object (no rename for avahi > contacts, subscribe/unsubscribe only for XMPP contacts...). So we will > certainly need some sort of shared actions that will be basic bricks for > building menu (like the shared-actions.[ch] of my first round of > proposals), that each implementation will mix as it sees fit. I assume here that an 'implementation" is one of the address book drivers, and that you mean that the drivers will be in charge of building menus. If those assumptions are wrong, the paragraph below does not apply, please just ignore it. Just the same as a hard disk driver does not display menus to the user, I think that the address book drivers in Ekiga should not be responsible for user interaction. The high level code should be responsible for that. Of course the contents of the various menus depends on the address book capabilities. That's why the API between the driver and the high level code should include "query capabilities functions:" class addressBook { virtual bool isReadOnly() = 0; virtual bool canSubscribeContacts() = 0; ... }; > The second bad news about them is that they won't be static either. They > will have to update themselves following the object they are attached > to. Say your nice XMPP contact is connected with a client which has VoIP > support, but now connects with a no-VoIP client, and disconnects the > first : we want the "Call" menuitem to disappear to reflect this. > > So my proposition (no code yet) is that those menus will be obtained by > subclassing of GtkMenu, register to get signals from the contact/book > they are attached to, and use that to keep themselves up to date. In your example, a signal is not needed. Knowing that there is no VoIP number in the current contact is enough. > ***** CONTROLLING (CONTACTS) > > Let's try to be more specific: > in avahi-contact-menu.h, we would have: > GtkWidget *avahi_contact_menu_new (AvahiContact *contact); > and in gm-contact.h: > GtkWidget *gm_contact_get_menu_new (GmContact *contact); > > This later function would be different in each implementation, which > allows for example the avahi_contact_get_menu_new implementation to call > avahi_contact_menu_new. The high level code called a generic function, > but got access to a very specific implementation, which knows the full > api of the specific contact, and hence will provide the best service. Again, this logic should be in the high-level code and needs not be avahi-specific. What exactly should be presented to the user could be determined from querying the address book for its capabilities. > ***** CONTROLLING (BOOKS) > > Perhaps the menu shouldn't be attached to the book himself, but to its > view. That would allow to place things such as "Show offline contacts" > in it. Mostly the idea would be to have controllers for both the > model-as-model and its view-as-model. Agree. > ***** ABOUT EVOLUTION-DATA-SERVER > > The evolution-data-server api looks pretty good -- except that it seems > to mainly handle static vcard-based contacts, where I would like to be > able to handle things like. > > For example, we find a nice contacts-changed signal, but in the > EBookView api... not in the EBook api, which seems strange. > > ***** ABOUT LIBGAIM > > I shriek everytime I read/think about that comment in blist.h (just > before the declaration of struct _GaimBuddy) : > "A buddy. This contains everything Gaim will ever need to know about > someone on the buddy list. Everything." (sic). > and that one (before the declaration of struct _GaimContact) : > "A contact. This contains everything Gaim will ever need to know about > a contact." > and that one (before the declaration of struct _GaimGroup) : > "A group. This contains everything Gaim will ever need to know about a > group." > > Notice that the comment before struct _GaimChat, although very similar, > isn't so bad in my eye :-) > > Notice too that although I find the way it is done inelegant, it still > is very good and efficient to get the job done, and contains quite an > impressive list of good ideas. (And it's more portable as ekiga, gasp!) > > ***** ABOUT LIBGALAGO > > Why, why, oh why does it contain a GalagoList api which looks so much > like a GList but isn't !? > > Apart from that, I would say it looks nice, but is out of scope for what > we want to do right now : it doesn't deal with addressbooks, but with > persons as single. > > "Using" it would be nice at some point. > > ***** LAST WORDS > > Congratulations, comments and flames welcome, but flames will end in > /dev/null. It definitly deserves congratulations. You forgot to mention one of your nice ideas, that it that it should be possible to search in several address books at a time. For the comments, please note that my comments are based on a lot of assumptions and guesses. In particular, I assume that you have in mind a different assignment of tasks of the various software layers than the one that I would like to see. If those assumptions reveal wrong, then of course my comments do not make much sense. If I did not misinterpret your thoughts, you have a very lazy view of the high-level code. It's software that sits down and waits for signals to act. Somehow, the high level code provides "services" to the drivers. The drivers are the ones who understand what's going on. I have the opposite view: the address book drivers are simple and stupid. Their main task is to go and fetch the requested contacts. The high level code has an active attitude: it queries the drivers for contacts, it queries the drivers capabilities, it displays the contact windows, it handles the menues... The high level code has the real intelligence. I hope that helps, -- Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m?dire." (Le concombre masqu?, Mandriva) From kk at verfaction.de Thu Jun 15 10:03:43 2006 From: kk at verfaction.de (Kilian Krause) Date: Thu, 15 Jun 2006 16:03:43 +0200 Subject: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 In-Reply-To: <200606081002.37875.conrad_videokonferenz@gmx.de> References: <200606081002.37875.conrad_videokonferenz@gmx.de> Message-ID: <1150380224.6599.22.camel@ganymede.verfaction.de> Hey Conrad, Am Donnerstag, den 08.06.2006, 10:02 +0000 schrieb Conrad Beckert: > has anybody an idea where the Debian packages for Ekiga 2.0.2 (or the > corresponding CVS versions) are? on their way. > The last version I can install using apt-get a couple of days old (May 25 - or > somethin) - at least this is a version with the nonfunctional German locale. > (defaults to English) > > What's up? /me is having a sheer lack of time and thus it took me a while to get everything polished and fixed just like i love to have it. =) Everything should be back to normal as of tonight (eventually sarge cvs snaps and win32 will remain for the weekend - we'll see) -- Best regards, Kilian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://mail.gnome.org/archives/gnomemeeting-devel-list/attachments/20060615/a45b4b0a/attachment.bin From jpuydt at free.fr Thu Jun 15 11:40:33 2006 From: jpuydt at free.fr (Julien PUYDT) Date: Thu, 15 Jun 2006 17:40:33 +0200 Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code In-Reply-To: <200606151318.05338.ebischoff@nerim.net> References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> Message-ID: <44917F71.10408@free.fr> ?ric Bischoff a ?crit : >> ***** VIEWING (GENERIC) >> >> We need to be able to present a book to the user. For that, the view >> needs to have a list of contacts (no, a single contact definitely isn't >> enough!). So we need a function call to get a list of contacts. > > In this paragraph I will assume that you mean "the view needs a list of all > contacts from the address book driver". If it is not what you mean, please > ignore this paragraph... Well, all contacts may be asking too much. I expect drivers to keep things sane. > The view needs to display, say, 10 contects at a time. No need to keep a list > of all contacts in memory. > > All we "need" is a function that gets _one_ contact from the driver. The view > can then use this information to keep the list of the 10 contacts that it > currently displays. Blah. If you're gonna loop on a list of contacts anyway, then get the list at once. Saying "I get only the 10 I need" is nice, but how do you tell the driver which they are ? Especially a roster XMPP generally comes as a single roster push you ask for when connecting, then little update pushes. >> The problem is that this list will change during time (new contacts >> added, others removed, presence changed, status message changed, and the >> list goes on). So the view will need to be notified about it. Hence the >> idea that the book will have "contact-added" and "contact-removed" >> signals, and the contacts a "updated" signal. >> In addition to that, there is an interesting special case to handle : >> you have a contact in a book, and this contact shows up in a search >> result. When you remove the contact from the book, we want to make it >> disappear from the list too. Hence a "removed" signal for contacts. > > While this sounds cool, I am not sure that this will be possible in some > circumstances. The underlying address book (evolution, KDE address book, LDAP > server, Zeroconf, ...) might not have the mechanisms to send such a signal. No problem : then they don't. Let's take the avahi book. It will probably update the list of users regularly (and have some action to update *now*). How will it work ? Well, it will populate a cache with those contacts, and on updating, flush it ("contact-removed" emitted on all of them), then repopulate it ("contact-added"). > I can imagine situations where some users on machine A update a LDAP server on > machine B while Ekiga runs on machine C, with the network connection between > B and C being temporarily broken. Will an update message come up to the > driver, and if yes when and how? If the backend doesn't give incremental changes, that still fits in my design. > What do I propose instead? To be less ambitious, and have an address book that > only pulls the data from the data source. If the user does not press > "refresh", then he/she might have outdated information. If he/she presses > "refresh", then the addresses are fetched again from the source. Bad. If the backend gives incremental changes, you don't handle it. Such a design works only for the most simple backends. >> Now this is all nice, but what can we do if an addressbook contains >> millions of entries ? And if a search gives thousands of results ? In >> such cases, my stance is that the low level code should do something >> about it, since it is the one giving the problem. > > I do not like that repartition of tasks. > > Let me take an example. When you write an operating system, you write: > - disk drivers > (the low level code that does physical read and write from and to > the hard disk) > - a filesystem > (the high level code that gathers individual sectors into files, > handles a cache, etc) > > The low level code should not be bothered with handling the disk cache. Okay, > the problem comes from the disk driver, because it does slow access to the > medium. That does not mean that it's not another component, the filesystem, > that can solve it. > > Why this repartition of tasks? Because the performance problem is a problem > that can be shared by many disk drivers. Therefore, the solution can be put > in common in the high level code. Your file manager doesn't handle the filesystems itself : they all present the same interface, and take care of caching themselves. I want the addressbook manager to be *high* level. If some caching is needed between the addressbook manager and the backend, I want the driver to take care of it. In fact, I implemented a SearchBook to take care of presenting all search results (whatever the book), and it's certainly desirable to provide a CachedBook, which will avoid code duplication. >> How can the high level >> code cope correctly with the situation anyway ? Only the low level code >> can say "Eh, I already made two hundred contacts go through the wire for >> that search, perhaps I should make it easy!". > > Why transfer 200 contacts when the view knows that it needs only 10? The view may show only ten at the same time on the screen, but the mouse wheel makes it so easy to go through all of the 200, that it wouldn't be wise to have them ready. If there are several thousands, that's more annoying. >> The question to really ask, and to which I have no satisfactory answer >> is: "How do me make the low level tell the high level it had to cut the >> list ?". > > The views know that contacts 301 to 309 are displayed. It's the view that > knows where to cut. In fact, there's nothing to cut, since all the view does > is ask the driver for the contects it needs. How do you number the contacts in a sane way? >> ***** VIEWING (CONTACTS) >> >> The contacts should contain enough to be viewed from a generic view in >> the contacts window, and be shown in a search result. That won't prevent >> some other parts of the code to make a better use of them. >> >> For example, in the contact window we will probably be able to see a >> contact's title and description, but not its detailed presence, while >> the main window will contain a much better and more specific view for >> the live contacts. > > You say that the "contact" class must have _enough_ information to be used > both in situation A and in sitation B. > > It would be better to have _different_ "contact" classes for situations "A" > and "B". Of course there will be. I was discussing the base class. > The list of contacts could just manage a name, a company and a phone number. I would put the following : 1) a title (generally the name) 2) a description (for example a location, a status message, etc) 3) an icon > The search result could handle much more detailed information. Of course it cannot. Your search result is a book which needs to be able to show avahi contacts, sip contacts, call history contacts, etc... so it can only show the contacts as generic. > In other words, there's no need to put all the model's data into the views' > data. Each view can handle the data it needs. The view which is specific to an addressbook, of course can show the data from the specific contact associated to it. But the generic view can only show generic information. >> ***** CONTROLLING (GENERIC) >> >> Now, we want to be able to act on our objects ; say rename a book or a >> contact, subscribe/unsubscribe to its presence, etc. >> >> The best thing to do is to be able to get menus for each of them. Notice >> the plural: we will certainly to have at least menu in the menu bar and >> a popup menu. >> >> The first bad news about such menus is that they won't be generic : they >> will depend heavily on the specific type of object (no rename for avahi >> contacts, subscribe/unsubscribe only for XMPP contacts...). So we will >> certainly need some sort of shared actions that will be basic bricks for >> building menu (like the shared-actions.[ch] of my first round of >> proposals), that each implementation will mix as it sees fit. > > I assume here that an 'implementation" is one of the address book drivers, and > that you mean that the drivers will be in charge of building menus. If those > assumptions are wrong, the paragraph below does not apply, please just ignore > it. Yes, that's precisely that. > Just the same as a hard disk driver does not display menus to the user, I > think that the address book drivers in Ekiga should not be responsible for > user interaction The menu is supposed to contain actions which are specific to the given contact, book or view. Hence it must be created by code which is specific to that contact, book or view. It cannot be done by the generic code. > The high level code should be responsible for that. Of course the contents of > the various menus depends on the address book capabilities. That's why the > API between the driver and the high level code should include "query > capabilities functions:" > > class addressBook > { > virtual bool isReadOnly() = 0; > virtual bool canSubscribeContacts() = 0; > ... > }; No, that is wrong and I already explained why. Putting everything in the base class is bad. >> The second bad news about them is that they won't be static either. They >> will have to update themselves following the object they are attached >> to. Say your nice XMPP contact is connected with a client which has VoIP >> support, but now connects with a no-VoIP client, and disconnects the >> first : we want the "Call" menuitem to disappear to reflect this. >> >> So my proposition (no code yet) is that those menus will be obtained by >> subclassing of GtkMenu, register to get signals from the contact/book >> they are attached to, and use that to keep themselves up to date. > > In your example, a signal is not needed. > > Knowing that there is no VoIP number in the current contact is enough. That is wrong. The same contact could update itself and gain it. Or update itself and lose it. >> ***** CONTROLLING (CONTACTS) >> >> Let's try to be more specific: >> in avahi-contact-menu.h, we would have: >> GtkWidget *avahi_contact_menu_new (AvahiContact *contact); >> and in gm-contact.h: >> GtkWidget *gm_contact_get_menu_new (GmContact *contact); >> >> This later function would be different in each implementation, which >> allows for example the avahi_contact_get_menu_new implementation to call >> avahi_contact_menu_new. The high level code called a generic function, >> but got access to a very specific implementation, which knows the full >> api of the specific contact, and hence will provide the best service. > > Again, this logic should be in the high-level code and needs not be > avahi-specific. What exactly should be presented to the user could be > determined from querying the address book for its capabilities. Which means : 1) *all* of the addressbooks would by default have *all* the possible apis for such capability by default, with a isAbleToDoFoo function for each Foo capability ; 2) if an addressbook needs a new capability, we'll have to modify the base addressbook to add it in for it ; it won't just be a matter for the new code to add only what is necessary for itself in its own files. >> ***** CONTROLLING (BOOKS) >> >> Perhaps the menu shouldn't be attached to the book himself, but to its >> view. That would allow to place things such as "Show offline contacts" >> in it. Mostly the idea would be to have controllers for both the >> model-as-model and its view-as-model. > > Agree. Nice. >> Congratulations, comments and flames welcome, but flames will end in >> /dev/null. > > It definitly deserves congratulations. You forgot to mention one of your nice > ideas, that it that it should be possible to search in several address books > at a time. Well, that is the main side-effect of having a base class for contacts. > For the comments, please note that my comments are based on a lot of > assumptions and guesses. In particular, I assume that you have in mind a > different assignment of tasks of the various software layers than the one > that I would like to see. If those assumptions reveal wrong, then of course > my comments do not make much sense. I think you are focused on an addressbook as something both very big and very static, which explains many of our divergences. > If I did not misinterpret your thoughts, you have a very lazy view of the > high-level code. It's software that sits down and waits for signals to act. > Somehow, the high level code provides "services" to the drivers. The drivers > are the ones who understand what's going on. Yes, that's it. The high-level code doesn't know what an AvahiContact or EDSContact is ; it only knows avbout GmContact. That means it cannot do fancy things with them, and has to call functions on them to do anything interesting. > I have the opposite view: the address book drivers are simple and stupid. > Their main task is to go and fetch the requested contacts. The high level > code has an active attitude: it queries the drivers for contacts, it queries > the drivers capabilities, it displays the contact windows, it handles the > menues... The high level code has the real intelligence. Your high level code is very complex, and has to be modified heavily anytime we add a new type of addressbook with new capabilities. Anytime you want to do something, you should ask yourself the question: "Who knows how to do it?". You want to send a message to a contact ? Who knows if it's even possible, and how to do it ? The contact itself! Hence this should be handled by the contact. Of course, as-is that would mean a lot of code duplication. That's where we can use a toolbox ; of which you had an example in the first round of sample code I sent in private. To make it explicit for the -devel- readers, this sample code had a function: void shared_action_rename (GObject *obj); so any object which could be renamed, had only to: - have a "name" property ; - provide an action which trigerred that function on itself. the function handled showing a nice dialog to rename the function. The idea is that of course quite a few objects will have common capabilities ; but instead of putting them all in the high level code and clutter it with functions and conditional, I want to provide the bricks which the low-level code will use to build a specific and well-fit system. Snark From ebischoff at nerim.net Thu Jun 15 14:26:49 2006 From: ebischoff at nerim.net (=?utf-8?q?=C3=89ric_Bischoff?=) Date: Thu, 15 Jun 2006 20:26:49 +0200 Subject: [GnomeMeeting-devel-list] =?utf-8?q?Ideas_and_considerations_for_?= =?utf-8?q?the=09addressbook_code?= In-Reply-To: <44917F71.10408@free.fr> References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> <44917F71.10408@free.fr> Message-ID: <200606152026.49639.ebischoff@nerim.net> Le Jeudi 15 Juin 2006 17:40, Julien PUYDT a ?crit?: > Saying "I get only the 10 I need" is nice, but how do you tell the > driver which they are ? There are several ways to acheive that. It could be contact numbers. Or it could be some data kept internally inside the driver. It could be a void *. Etc. > > While this sounds cool, I am not sure that this will be possible in some > > circumstances. The underlying address book (evolution, KDE address book, > > LDAP server, Zeroconf, ...) might not have the mechanisms to send such a > > signal. > > No problem : then they don't. OK. So that should not be a requirement, and certainly not a mechanism at the core of the system. Just a nice plus. > > Why transfer 200 contacts when the view knows that it needs only 10? > > The view may show only ten at the same time on the screen, but the mouse > wheel makes it so easy to go through all of the 200, that it wouldn't be > wise to have them ready. Yes. You could have a few spare contacts before and after the user's view. This algorithm is rather common. > If there are several thousands, that's more annoying. Okay. Let's simulate your algorithm, or what I have understood of it. The user views a search selection of contacts named "Tom". His/her window should contain contacts Tom Smith (#1032), Tom Jones (#2050) and Tom Doe (#3172). The high level software asks the driver "get me all contacts". After a relatively long time, the driver is wise and stops at contact 200. It returns a list with contacts 1, 2, 3, etc, up to 200. The high level software searches for Tom's in the list and finds none, since the Tom's have numbers 1032, 2050 and 3172. The returned list is useless, and the window remains blank. I know that it cannot be _that_ bad and that I certainly misunderstood something. But what? > > The views know that contacts 301 to 309 are displayed. It's the view that > > knows where to cut. In fact, there's nothing to cut, since all the view > > does is ask the driver for the contects it needs. > > How do you number the contacts in a sane way? These numbers are here for the demonstration. I agree that numbers probably are not so well adapted to real address books. You could use "markers". I think that all address books use contact UIDs. A given UID could be used to mark the place where the address book stopped "last time". For most usage you do not even need anything. Most operation is sequential. Take for example searching. Usually you browse all records and only keep in the result list the ones that match. > I would put the following : > 1) a title (generally the name) > 2) a description (for example a location, a status message, etc) > 3) an icon Yes, we are discussing principles. Details can be arranged later. > > The search result could handle much more detailed information. > > Of course it cannot. Your search result is a book which needs to be able > to show avahi contacts, sip contacts, call history contacts, etc... so > it can only show the contacts as generic. Why would you be unable to display detailed information about objects which you only know as generic? while (genericContact = nextContact()) { if (genericContact->book()->canSubscribeContacts()) proposeSubscription(genericContact); ... } > The view which is specific to an addressbook, of course can show the > data from the specific contact associated to it. But the generic view > can only show generic information. Wrong ;-). Not shown in the code sample above, but that's also the whole point of virtual methods. > The menu is supposed to contain actions which are specific to the given > contact, book or view. Hence it must be created by code which is > specific to that contact, book or view. It cannot be done by the generic > code. ;-) > > class addressBook > > { > > virtual bool isReadOnly() = 0; > > virtual bool canSubscribeContacts() = 0; > > ... > > }; > > No, that is wrong and I already explained why. Putting everything in the > base class is bad. Do you realize that the above is not an implementation? It's just an API definition. Those are pure virtual methods. Everything is implemented in the derived subclasses. Such style of coding is very classical, good, C++ (or java). > > In your example, a signal is not needed. > > > > Knowing that there is no VoIP number in the current contact is enough. > > That is wrong. The same contact could update itself and gain it. Or > update itself and lose it. I should have added "at a given time". > Which means : > 1) *all* of the addressbooks would by default have *all* the possible > apis for such capability by default, with a isAbleToDoFoo function for > each Foo capability ; No. Defining pure virtual functions in the base class does not mean that you implement a function in the derived class. If it can't do something, and lets the engine know it, then it can't ;-). > 2) if an addressbook needs a new capability, we'll have to modify the > base addressbook to add it in for it ; it won't just be a matter for the > new code to add only what is necessary for itself in its own files. Wrong again, C++ comes with programming techniques that permit to locate the real implementations in the derived classes. > > It definitly deserves congratulations. You forgot to mention one of your > > nice ideas, that it that it should be possible to search in several > > address books at a time. > > Well, that is the main side-effect of having a base class for contacts. ;-) > I think you are focused on an addressbook as something both very big and > very static, which explains many of our divergences. I think that we are both wrong here ;-). An address book could be big (which you underestimated), and it could be moving (which I underestimated). > Yes, that's it. The high-level code doesn't know what an AvahiContact or > EDSContact is ; it only knows avbout GmContact. That means it cannot do > fancy things with them, and has to call functions on them to do anything > interesting. I have a view that is not so far away. The book just knows contacts. Virtual methods and subclassing both the book and the contacts does the rest. > Your high level code is very complex, and has to be modified heavily > anytime we add a new type of addressbook with new capabilities. Yes, but much more generic. And if the same capability exists in a second address book, the code is already written. > Of course, as-is that would mean a lot of code duplication. That's where > we can use a toolbox ; of which you had an example in the first round of > sample code I sent in private. Ah, you too you can see the duplication problem with your method ;-). A tool box... Sounds like a C library ;-). I think that we basically foresee the same problems, but you want to do them in the procedural, C way, and I would like them to be done in the object-oriented, C++ way. > To make it explicit for the -devel- readers, this sample code had a > function: > void shared_action_rename (GObject *obj); > so any object which could be renamed, had only to: > - have a "name" property ; > - provide an action which trigerred that function on itself. > the function handled showing a nice dialog to rename the function. Yup. You see functions where I see methods ;-). > The idea is that of course quite a few objects will have common > capabilities ; but instead of putting them all in the high level code > and clutter it with functions and conditional, Yes, that would be the logical consequence if we were in C. We are not. We have virtual methods. > I want to provide the > bricks which the low-level code will use to build a specific and > well-fit system. You will end up with an engine doing about nothing, and all the work to be reimplemented again and again in the drivers. Plus painfully shared code in the "toolbox" to avoid almost identical code where it can be avoided. That's typical procedural approach. -- Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m?dire." (Le concombre masqu?, Mandriva) From jpuydt at free.fr Thu Jun 15 16:46:00 2006 From: jpuydt at free.fr (Julien PUYDT) Date: Thu, 15 Jun 2006 22:46:00 +0200 Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code In-Reply-To: <200606152026.49639.ebischoff@nerim.net> References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> <44917F71.10408@free.fr> <200606152026.49639.ebischoff@nerim.net> Message-ID: <4491C708.3060203@free.fr> ?ric Bischoff a ?crit : > Le Jeudi 15 Juin 2006 17:40, Julien PUYDT a ?crit : >> Saying "I get only the 10 I need" is nice, but how do you tell the >> driver which they are ? > > There are several ways to acheive that. It could be contact numbers. Or it > could be some data kept internally inside the driver. It could be a void *. > Etc. Well, then you reduced the question: "How do I tell the driver which contacts I want?" to: "How do I tell the driver which identifiers I want?" I don't find this impressive. >>> While this sounds cool, I am not sure that this will be possible in some >>> circumstances. The underlying address book (evolution, KDE address book, >>> LDAP server, Zeroconf, ...) might not have the mechanisms to send such a >>> signal. >> No problem : then they don't. > > OK. So that should not be a requirement, and certainly not a mechanism at the > core of the system. Just a nice plus. It *must* be at the core of the system. We _do_ want to update the live data when it changes. >>> Why transfer 200 contacts when the view knows that it needs only 10? >> The view may show only ten at the same time on the screen, but the mouse >> wheel makes it so easy to go through all of the 200, that it wouldn't be >> wise to have them ready. > > Yes. You could have a few spare contacts before and after the user's view. > This algorithm is rather common. What do "before" and "after" mean ? >> If there are several thousands, that's more annoying. > > Okay. Let's simulate your algorithm, or what I have understood of it. > > The user views a search selection of contacts named "Tom". His/her window > should contain contacts Tom Smith (#1032), Tom Jones (#2050) and Tom Doe > (#3172). The high level software asks the driver "get me all contacts". After > a relatively long time, the driver is wise and stops at contact 200. It > returns a list with contacts 1, 2, 3, etc, up to 200. The high level software > searches for Tom's in the list and finds none, since the Tom's have numbers > 1032, 2050 and 3172. The returned list is useless, and the window remains > blank. > > I know that it cannot be _that_ bad and that I certainly misunderstood > something. But what? I certainly have issues with big books, and must find some satisfying way to handle them. But doing function calls to walk on a list where I could get the list and walk it myself directly, is definitely wrong. >>> The views know that contacts 301 to 309 are displayed. It's the view that >>> knows where to cut. In fact, there's nothing to cut, since all the view >>> does is ask the driver for the contects it needs. >> How do you number the contacts in a sane way? > > These numbers are here for the demonstration. I agree that numbers probably > are not so well adapted to real address books. > > You could use "markers". I think that all address books use contact UIDs. A > given UID could be used to mark the place where the address book stopped > "last time". Notice that the only place where you call the _get_contacts function is when you first populate the book. The rest of the time you don't want to know. > For most usage you do not even need anything. Most operation is sequential. > Take for example searching. Usually you browse all records and only keep in > the result list the ones that match. Most operations are sequential when the book is static. When your contacts go online/offline/whatever, that certainly is random access, and I can tell you a first/current/next approach doesn't fly in such a situation. >>> The search result could handle much more detailed information. >> Of course it cannot. Your search result is a book which needs to be able >> to show avahi contacts, sip contacts, call history contacts, etc... so >> it can only show the contacts as generic. > > Why would you be unable to display detailed information about objects which > you only know as generic? > > while (genericContact = nextContact()) > { > if (genericContact->book()->canSubscribeContacts()) > proposeSubscription(genericContact); > ... > } Yes, of course. You put everything at the high level, something which I already stressed was very very bad. Let's try an example. A text editor will just access files. It won't wonder if they are local or remote, it won't wonder about where the data really is on disk, need caching, etc. This is the job of the low-level system. The text editor doesn't have functions and tests to handle all of the various situations possible. High level is high, it doesn't take mud baths with the details, it doesn't handle them. It delegates them to the low level. >> The view which is specific to an addressbook, of course can show the >> data from the specific contact associated to it. But the generic view >> can only show generic information. > > Wrong ;-). Partially wrong. The generic view can indeed get access to some specific features (like the menus I explained). But it certainly *must* not get them by handling *all* possible situations. >>> class addressBook >>> { >>> virtual bool isReadOnly() = 0; >>> virtual bool canSubscribeContacts() = 0; >>> ... >>> }; >> No, that is wrong and I already explained why. Putting everything in the >> base class is bad. > > Do you realize that the above is not an implementation? It's just an API > definition. Those are pure virtual methods. Everything is implemented in the > derived subclasses. > > Such style of coding is very classical, good, C++ (or java). Such style of coding is not classical, is bad and evil. I see abstractions layers everywhere to hide the details of the lower level, and you want to push those details high up the stack. >>> In your example, a signal is not needed. >>> >>> Knowing that there is no VoIP number in the current contact is enough. >> That is wrong. The same contact could update itself and gain it. Or >> update itself and lose it. > > I should have added "at a given time". > >> Which means : >> 1) *all* of the addressbooks would by default have *all* the possible >> apis for such capability by default, with a isAbleToDoFoo function for >> each Foo capability ; > > No. Defining pure virtual functions in the base class does not mean that you > implement a function in the derived class. If it can't do something, and lets > the engine know it, then it can't ;-). You push all the code to the high level, and never really abstract. That is very wrong. >> 2) if an addressbook needs a new capability, we'll have to modify the >> base addressbook to add it in for it ; it won't just be a matter for the >> new code to add only what is necessary for itself in its own files. > > Wrong again, C++ comes with programming techniques that permit to locate the > real implementations in the derived classes. If I add a new addressbook type with a Foo capability, your designs says I have to modify the base class and add: bool canDoFoo (); void pleaseDoFooThisWay (...); void pleaseDoFooThisOtherWay (...); void etcFoo (...) (with all the virtual pure syntactic crap needed) My idea of right design is that if the new addressbook is the only one needing Foo, it will handle it himself (through a specific api that its view and controller will know and use). >> I think you are focused on an addressbook as something both very big and >> very static, which explains many of our divergences. > > I think that we are both wrong here ;-). An address book could be big (which > you underestimated), and it could be moving (which I underestimated). I agree I have issues seeing how to do things *properly* with a very large addressbook. >> Yes, that's it. The high-level code doesn't know what an AvahiContact or >> EDSContact is ; it only knows avbout GmContact. That means it cannot do >> fancy things with them, and has to call functions on them to do anything >> interesting. > > I have a view that is not so far away. The book just knows contacts. Virtual > methods and subclassing both the book and the contacts does the rest. > >> Your high level code is very complex, and has to be modified heavily >> anytime we add a new type of addressbook with new capabilities. > > Yes, but much more generic. It isn't much more generic. It is an awful and indigest mix of all the specific implementations. > And if the same capability exists in a second address book, the code is > already written. Not really. >> Of course, as-is that would mean a lot of code duplication. That's where >> we can use a toolbox ; of which you had an example in the first round of >> sample code I sent in private. > > Ah, you too you can see the duplication problem with your method ;-). > > A tool box... Sounds like a C library ;-). Which are very useful and allow to abstract common work at a lower layer and not take care of it ourselves way up. > I think that we basically foresee the same problems, but you want to do them > in the procedural, C way, and I would like them to be done in the > object-oriented, C++ way. Your view isn't OO, and isn't C++. >> To make it explicit for the -devel- readers, this sample code had a >> function: >> void shared_action_rename (GObject *obj); >> so any object which could be renamed, had only to: >> - have a "name" property ; >> - provide an action which trigerred that function on itself. >> the function handled showing a nice dialog to rename the function. > > Yup. You see functions where I see methods ;-). I see functions spread in maintainable files, with well-separated features and responsibility. You see functions named "methods" stuffed into the same poor base class, which has to handle everything and the rest, and where the limits between everything is blurred. Where I say function and do: gm_contact_do_foo (contact, arguments); you say method and to: contact->do_foo (arguments); which I agree is shorter, but isn't the magical solution you think it is! :-) >> The idea is that of course quite a few objects will have common >> capabilities ; but instead of putting them all in the high level code >> and clutter it with functions and conditional, > > Yes, that would be the logical consequence if we were in C. We are not. We > have virtual methods. You *do* have isReadOnly and canSubscribeContacts, which you will use to do the ifs I said where very wrong, and you will do so at the high level, which is precisely the place where details shouldn't be handled! It isn't a case of leaky abstraction, it is a case of no-abstraction! >> I want to provide the >> bricks which the low-level code will use to build a specific and >> well-fit system. > > You will end up with an engine doing about nothing, and all the work to be > reimplemented again and again in the drivers. Plus painfully shared code in > the "toolbox" to avoid almost identical code where it can be avoided. That's > typical procedural approach. I generally end up with nice layers of functions doing almost nothing, with clean api between the layer, ensuring the code will be pretty maintainable. See lib/gmconf/ for example. We have a nice api in gmconf.h, and an implementation in gmconf-glib.c, which is layered in the same file, with lowlevel functions doing some work, and higher level doing another. Not everything done at the same final level. When I wrote that code, the goal was to make gconf (the gnome configuration management system) optional, so the port to win32 would be easier. I wrote a generic api to handle things, then two implementations *hidden* behind it. Well, at least we both agree I don't handle the case of very large addressbooks very well :-/ Snark From jpuydt at free.fr Fri Jun 16 09:56:24 2006 From: jpuydt at free.fr (Julien PUYDT) Date: Fri, 16 Jun 2006 15:56:24 +0200 Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code In-Reply-To: <4491205F.5070708@free.fr> References: <4491205F.5070708@free.fr> Message-ID: <4492B888.8060206@free.fr> Julien PUYDT a ?crit : > ***** ABOUT EVOLUTION-DATA-SERVER > > The evolution-data-server api looks pretty good -- except that it seems > to mainly handle static vcard-based contacts, where I would like to be > able to handle things like. Hmmm... this sentence should have ended with "able to handle things like live contacts with presence (SIP and XMPP)". On the subject of big addressbook handling, I must say what evolution-data-server does is quite nice : they run a query (EQuery) on a book (EBook), which gives them a view of the result (EBookView). That means that they can easily do a partial view of an addressbook, since they control what is seen! While this organisation doesn't suffer from the problem ?ric pointed out, it has still a problem : how does one just "search" ? I mean, if your api is "search a book => get a view", how does one make a search which encompasses all books? Snark PS: notice that the current addressbook code happily tries to get all contacts, whatever the size of the addressbook -- and even not asynchronously! From jpuydt at free.fr Sat Jun 17 03:07:30 2006 From: jpuydt at free.fr (Julien PUYDT) Date: Sat, 17 Jun 2006 09:07:30 +0200 Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code In-Reply-To: <4492B888.8060206@free.fr> References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> Message-ID: <4493AA32.5030602@free.fr> Julien PUYDT a ?crit : > While this organisation doesn't suffer from the problem ?ric pointed > out, it has still a problem : how does one just "search" ? I mean, if > your api is "search a book => get a view", how does one make a search > which encompasses all books? Ok, I think I'm on something : let's a book have a simple api, where on one side: 1) a book can return a view for itself, which means the view becomes specific, and hence can handle the case of big addressbooks ; 2) a full search function, which will return a new book, restricted to the the search ; again this book has its view, which will handle the case of big searches ; 3) a restricted search function, which will return say at most a hundred contacts matching the string ; this one allows to make a search on all the books, since we are assured we won't be drowned by the number. This organisation would allow a clean approach for the view on a single addressbook, while still having the possibility to have a working "Find a contact" button. Does that looks nicer ? Snark From ebischoff at nerim.net Sat Jun 17 05:22:59 2006 From: ebischoff at nerim.net (=?utf-8?q?=C3=89ric_Bischoff?=) Date: Sat, 17 Jun 2006 11:22:59 +0200 Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code In-Reply-To: <4491C708.3060203@free.fr> References: <4491205F.5070708@free.fr> <200606152026.49639.ebischoff@nerim.net> <4491C708.3060203@free.fr> Message-ID: <200606171123.00082.ebischoff@nerim.net> Le Jeudi 15 Juin 2006 22:46, Julien PUYDT a ?crit?: > > OK. So that should not be a requirement, and certainly not a mechanism at > > the core of the system. Just a nice plus. > > It *must* be at the core of the system. We _do_ want to update the live > data when it changes. Sorry, that was not clear. By "at the core" I meant "necessary for the address books to work". > > Yes. You could have a few spare contacts before and after the user's > > view. This algorithm is rather common. > > What do "before" and "after" mean ? Records just before and after the ones that are displayed in sequential order. > > I know that it cannot be _that_ bad and that I certainly misunderstood > > something. But what? > > I certainly have issues with big books, and must find some satisfying > way to handle them. But doing function calls to walk on a list where I > could get the list and walk it myself directly, is definitely wrong. What is wrong is to see that as a list ;-). > Most operations are sequential when the book is static. When your > contacts go online/offline/whatever, that certainly is random access, > and I can tell you a first/current/next approach doesn't fly in such a > situation. I would not say "not fly" but it certainly becomes much more acrobatic, I agree. > If I add a new addressbook type with a Foo capability, your designs says > I have to modify the base class and add: > > bool canDoFoo (); > void pleaseDoFooThisWay (...); > void pleaseDoFooThisOtherWay (...); > void etcFoo (...) > (with all the virtual pure syntactic crap needed) This "crap" is a lightweight modification since it is only one function declaration. No implementation. That is done in the subclasses, if necessary. > My idea of right design is that if the new addressbook is the only one > needing Foo, it will handle it himself (through a specific api that its > view and controller will know and use). Okay. Perharps the our differences in opinion is not that much on the programming design, but more on what the software has to do. To me, an address book is just an address book, they are not that different one from the other. Ekiga need to dig through them to show names, categories and to pick up SIP numbers to call the people. I see a relatively homogeneous user interface, with more or less the same appearance (if not exactly the same) for the various address books. I have a "unifying" vision. To you, all address books have very strong pecularities and the software has to adapt a lot to each of them, to take them to the maximum of their possibilities. The user will get different display, different menues, and even different functionality. That explains why you want to put everything in the "drivers", while I want to put a lot of common logic in the "engine". > > I think that we are both wrong here ;-). An address book could be big > > (which you underestimated), and it could be moving (which I > > underestimated). > > I agree I have issues seeing how to do things *properly* with a very > large addressbook. Yes, and I have certainly underestimated the "dynamic" aspect :-(. > Your view isn't OO, and isn't C++. Come on ;-). > You see functions named "methods" stuffed into the same poor base class, No. Again and again, the base class only has declarations. It sees an abstraction of what the address book is. In every C++ book, you can see examples like this class vehicle { virtual void accelerate(int a) = 0; ... }; class car : public vehicle { virtual void accelerate(int a); ... }; class plane : public vehicle { virtual void accelerate(int a); ... }; Planes and cars have very different ways to accelerate. Planes can't brake and cars can't fly, but such designs are clean and very popular. > Well, at least we both agree I don't handle the case of very large > addressbooks very well :-/ Yes, this discussion is not pointless :-). And at the end if you are more comfortable with libraries of C functions than with subclassing and virtual functions, it's no problem. After all, it's you who are going to be doing the dirty work (and I think we all thank you for that!). -- Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m?dire." (Le concombre masqu?, Mandriva) From jpuydt at free.fr Sat Jun 17 15:05:51 2006 From: jpuydt at free.fr (Julien PUYDT) Date: Sat, 17 Jun 2006 21:05:51 +0200 Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code In-Reply-To: <200606171123.00082.ebischoff@nerim.net> References: <4491205F.5070708@free.fr> <200606152026.49639.ebischoff@nerim.net> <4491C708.3060203@free.fr> <200606171123.00082.ebischoff@nerim.net> Message-ID: <4494528F.2040804@free.fr> ?ric Bischoff a ?crit : >>> Yes. You could have a few spare contacts before and after the user's >>> view. This algorithm is rather common. >> What do "before" and "after" mean ? > > Records just before and after the ones that are displayed in sequential order. Sequential hurts. >>> I know that it cannot be _that_ bad and that I certainly misunderstood >>> something. But what? >> I certainly have issues with big books, and must find some satisfying >> way to handle them. But doing function calls to walk on a list where I >> could get the list and walk it myself directly, is definitely wrong. > > What is wrong is to see that as a list ;-). Indeed. >> If I add a new addressbook type with a Foo capability, your designs says >> I have to modify the base class and add: >> >> bool canDoFoo (); >> void pleaseDoFooThisWay (...); >> void pleaseDoFooThisOtherWay (...); >> void etcFoo (...) >> (with all the virtual pure syntactic crap needed) > > This "crap" is a lightweight modification since it is only one function > declaration. No implementation. That is done in the subclasses, if necessary. Notice that I used "crap" to describe the syntactic need in C++ to add "virtual" and "= 0" everywhere. And your "lightweight modification" still involves modifying the base class anytime a child class needs something! >> My idea of right design is that if the new addressbook is the only one >> needing Foo, it will handle it himself (through a specific api that its >> view and controller will know and use). > > Okay. Perharps the our differences in opinion is not that much on the > programming design, but more on what the software has to do. > > To me, an address book is just an address book, they are not that different > one from the other. Ekiga need to dig through them to show names, categories > and to pick up SIP numbers to call the people. I see a relatively homogeneous > user interface, with more or less the same appearance (if not exactly the > same) for the various address books. I have a "unifying" vision. > > To you, all address books have very strong pecularities and the software has > to adapt a lot to each of them, to take them to the maximum of their > possibilities. The user will get different display, different menues, and > even different functionality. Well, look at what we have to put already in the addressbooks: - evolution-data-server addressbooks ; - avahi contacts ; - history contacts ; - speeddials. And the future holds : - SIP contacts ; - XMPP contacts. > That explains why you want to put everything in the "drivers", while I want to > put a lot of common logic in the "engine". Your high level is what I call low level : it handles all of the details! >> Your view isn't OO, and isn't C++. > > Come on ;-). > >> You see functions named "methods" stuffed into the same poor base class, > > No. Again and again, the base class only has declarations. It sees an > abstraction of what the address book is. You're still stuffing that in the base class, which is awful. Does the QWidget class have all the methods of all its child already declared? > In every C++ book, you can see examples like this > > class vehicle { > virtual void accelerate(int a) = 0; > ... > }; > > class car : public vehicle { > virtual void accelerate(int a); > ... > }; > > class plane : public vehicle { > virtual void accelerate(int a); > ... > }; > Planes and cars have very different ways to accelerate. Planes can't brake and > cars can't fly, but such designs are clean and very popular. They all accelerate, and that is the reason why having an accelerate method is put as a requirement in the base class. Anyway I since made another proposition which I find neater ; I'm eagerly waiting for your comments on it :-) Snark From siti at orcon.net.nz Sat Jun 17 16:11:38 2006 From: siti at orcon.net.nz (Stephen Cook) Date: Sun, 18 Jun 2006 08:11:38 +1200 Subject: [GnomeMeeting-devel-list] IAX2 Message-ID: <1150575098.10433.5.camel@siti> Hello, It's been a long time I gave you guys an update. In IAX2 in opal I have got music on hold going which is nice :). I will be doing registration next as this is probably the most important feature for users. Also I have not run in to any stability problems with IAX2. My iax2/ekiga integration is working well as a tester with my asterisk server. It basically has all the functionality there but needs more integration and bug/quirky fixes. Also some refactoring in the future would be nice depending if I get time or not... From jan.schampera at web.de Sat Jun 17 21:32:42 2006 From: jan.schampera at web.de (Jan Schampera) Date: Sun, 18 Jun 2006 03:32:42 +0200 Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code In-Reply-To: <4493AA32.5030602@free.fr> References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> <4493AA32.5030602@free.fr> Message-ID: <20060618033242.5cce3d15@localhost.localdomain> On Sat, 17 Jun 2006 09:07:30 +0200 Julien PUYDT wrote: > 1) a book can return a view for itself, which means the view becomes > specific, and hence can handle the case of big addressbooks ; And which view would such a book return by default? > 2) a full search function, which will return a new book, restricted > to the the search ; again this book has its view, which will handle > the case of big searches ; ACK > 3) a restricted search function, which will return say at most a > hundred contacts matching the string ; this one allows to make a > search on all the books, since we are assured we won't be drowned by > the number. > Does that looks nicer ? Yip. J. -- God is real... unless declared as integer. From jpuydt at free.fr Sun Jun 18 06:19:43 2006 From: jpuydt at free.fr (Julien PUYDT) Date: Sun, 18 Jun 2006 12:19:43 +0200 Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code In-Reply-To: <20060618033242.5cce3d15@localhost.localdomain> References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> <4493AA32.5030602@free.fr> <20060618033242.5cce3d15@localhost.localdomain> Message-ID: <449528BF.3020104@free.fr> Jan Schampera a ?crit : >> 1) a book can return a view for itself, which means the view becomes >> specific, and hence can handle the case of big addressbooks ; > And which view would such a book return by default? No default view. I think there should be a GmFullBook class (from which all books which can be displayed fully), and an associated GmFullBookView class, which would then be default for the children. >> Does that looks nicer ? > Yip. Nice. I'm writing some code to showcase things... may take long since I lack time those days :-/ Snark From dsandras at seconix.com Sun Jun 18 15:31:27 2006 From: dsandras at seconix.com (Damien Sandras) Date: Sun, 18 Jun 2006 21:31:27 +0200 Subject: [GnomeMeeting-devel-list] IAX2 In-Reply-To: <1150575098.10433.5.camel@siti> References: <1150575098.10433.5.camel@siti> Message-ID: <1150659087.2477.3.camel@golgoth01> Le dimanche 18 juin 2006 ? 08:11 +1200, Stephen Cook a ?crit : > Hello, > > It's been a long time I gave you guys an update. > > In IAX2 in opal I have got music on hold going which is nice :). I will > be doing registration next as this is probably the most important > feature for users. Also I have not run in to any stability problems > with IAX2. > > My iax2/ekiga integration is working well as a tester with my asterisk > server. It basically has all the functionality there but needs more > integration and bug/quirky fixes. Also some refactoring in the future > would be nice depending if I get time or not... Hi, I've seen Derek committed some code from you. I think it is important that you keep a repository with your patches so that we really know what you have fixed/added for Google SoC. (Actually, I should see the patches, even though it is perfectly acceptable that Derek commits them). Thank you, -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net sip:600000 at ekiga.net From johan_brn at yahoo.com Sun Jun 18 16:13:29 2006 From: johan_brn at yahoo.com (Johan Brannlund) Date: Sun, 18 Jun 2006 13:13:29 -0700 Subject: [GnomeMeeting-devel-list] Main window size Message-ID: I posted the below as a wishlist bug, but apparently the developers prefer carrying out the discussion on this mailing list. This is what I wrote: "I just tried the 20060615 cvs snapshot of ekiga, and it's getting better all the time. I have a small request though: I don't use video, which means that the main window is much bigger than it has to be. Would it be possible to add a resizing widget, or to automatically make the window smaller when video is disabled?" Damien also added the following comment: "I would also say that it will look less bigger when having a contacts list. :) " ... which I don't quite understand. At least in my snapshot, the contacts are in a separate window. Regards, Johan From siti at orcon.net.nz Sun Jun 18 21:21:55 2006 From: siti at orcon.net.nz (Stephen Cook) Date: Mon, 19 Jun 2006 13:21:55 +1200 Subject: [GnomeMeeting-devel-list] IAX2 In-Reply-To: <1150659087.2477.3.camel@golgoth01> References: <1150575098.10433.5.camel@siti> <1150659087.2477.3.camel@golgoth01> Message-ID: <1150680115.31741.1.camel@siti> On Sun, 2006-06-18 at 21:31 +0200, Damien Sandras wrote: > Le dimanche 18 juin 2006 ? 08:11 +1200, Stephen Cook a ?crit : > > Hello, > > > > It's been a long time I gave you guys an update. > > > > In IAX2 in opal I have got music on hold going which is nice :). I will > > be doing registration next as this is probably the most important > > feature for users. Also I have not run in to any stability problems > > with IAX2. > > > > My iax2/ekiga integration is working well as a tester with my asterisk > > server. It basically has all the functionality there but needs more > > integration and bug/quirky fixes. Also some refactoring in the future > > would be nice depending if I get time or not... > > Hi, > > > I've seen Derek committed some code from you. > > I think it is important that you keep a repository with your patches so > that we really know what you have fixed/added for Google SoC. > (Actually, I should see the patches, even though it is perfectly > acceptable that Derek commits them). I'll try and get you to review them first. I'll also put the patches on my website and give you guys a link soon. > > Thank you, From jpuydt at free.fr Mon Jun 19 01:25:13 2006 From: jpuydt at free.fr (Julien PUYDT) Date: Mon, 19 Jun 2006 07:25:13 +0200 Subject: [GnomeMeeting-devel-list] Main window size In-Reply-To: References: Message-ID: <44963539.6080309@free.fr> Johan Brannlund a ?crit : > I posted the below as a wishlist bug, but apparently the developers prefer > carrying out the discussion on this mailing list. This is what I wrote: Well, bug reports are nice for a beta or a stable release ; during the development cycle, discussing on the -devel- mailing-list is better (especially right at the beginning). :-) > "I just tried the 20060615 cvs snapshot of ekiga, and it's getting better > all the time. I have a small request though: I don't use video, which > means that the main window is much bigger than it has to be. > > Would it be possible to add a resizing widget, or to automatically make the > window smaller when video is disabled?" > > Damien also added the following comment: > > "I would also say that it will look less bigger when having a contacts > list. :) " > > ... which I don't quite understand. At least in my snapshot, the contacts > are in a separate window. He means that you should see some of your contacts in the main window in the future, with presence information about them. Snark From dsandras at seconix.com Mon Jun 19 04:54:04 2006 From: dsandras at seconix.com (Damien Sandras) Date: Mon, 19 Jun 2006 10:54:04 +0200 Subject: [GnomeMeeting-devel-list] Main window size In-Reply-To: <44963539.6080309@free.fr> References: <44963539.6080309@free.fr> Message-ID: <1150707244.2904.2.camel@golgoth01> Le lundi 19 juin 2006 ? 07:25 +0200, Julien PUYDT a ?crit : > Johan Brannlund a ?crit : > > I posted the below as a wishlist bug, but apparently the developers prefer > > carrying out the discussion on this mailing list. This is what I wrote: > > Well, bug reports are nice for a beta or a stable release ; during the > development cycle, discussing on the -devel- mailing-list is better > (especially right at the beginning). :-) > Yes, because it is a work in progress. So it will change with time, and get improved. No worries :) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net sip:600000 at ekiga.net From dsandras@seconix.com Thu Jun 1 02:40:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F28C93B00EB for ; Thu, 1 Jun 2006 02:40:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10407-03 for ; Thu, 1 Jun 2006 02:40:07 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 9FA173B00CB for ; Thu, 1 Jun 2006 02:40:06 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id DE1A2496FC for ; Thu, 1 Jun 2006 08:23:55 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15636-08 for ; Thu, 1 Jun 2006 08:23:54 +0200 (CEST) Received: from [172.16.100.156] (tcts.fpms.ac.be [193.190.194.194]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 0CBC0496FB for ; Thu, 1 Jun 2006 08:23:54 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <447DF183.3090300@cs.stanford.edu> References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-15 Date: Thu, 01 Jun 2006 08:41:01 +0200 Message-Id: <1149144061.2457.4.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 06:40:10 -0000 Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > I'd imagine it would work on win32, but don't know. > Probably. > I'll work on the patches. > > Where's the right place to add required libraries like openGL? In configure.in. > configure.in seems to be autogenerated by something, but whatever it is > doesn't seem to be in the CVS snapshot... > configure.in is in the CVS snapshot. > Thanks, > > -Dan > > Julien PUYDT wrote: > > > Dan Sandberg a écrit : > > > >> How should we proceed? I could just send you an updated gui/main.cpp > >> file... > > > > > > I'd like to see patches instead of full files, preferably independant > > on each others. > > > > There's also the question of the portability of this : since you > > mention SDL, I guess this will work great on win32 too ? > > > > Snark > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From hoglet@solit.se Thu Jun 1 09:09:47 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 90B2B3B017F for ; Thu, 1 Jun 2006 09:09:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04710-03 for ; Thu, 1 Jun 2006 09:09:45 -0400 (EDT) Received: from aurian.solit.se (unknown [82.182.216.174]) by menubar.gnome.org (Postfix) with ESMTP id 63B703B0134 for ; Thu, 1 Jun 2006 09:09:45 -0400 (EDT) Received: from ip76.kassjo.se ([85.11.28.76] helo=localhost.localdomain) by aurian.solit.se with asmtp (Exim 3.35 #1 (Debian)) id 1Flmvj-0004Et-00 for ; Thu, 01 Jun 2006 15:09:39 +0200 Date: Thu, 1 Jun 2006 15:09:38 +0200 From: Kent Asplund To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Re: Ekiga branched Message-Id: <20060601150938.fcdea791.hoglet@solit.se> In-Reply-To: <1148209984.2488.26.camel@golgoth01> References: <1147894199.7225.2.camel@golgoth01> <1148207277.6654.0.camel@frobisher.madeley.id.au> <1148209984.2488.26.camel@golgoth01> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: ej spam, SpamAssassin (resultat=-4.4, krav 5, IN_REP_TO -4.43) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.832 tagged_above=-999 required=2 tests=[AWL=-0.510, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142] X-Spam-Score: -1.832 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:09:47 -0000 --Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 21 May 2006 13:13:04 +0200 Damien Sandras wrote: > Le dimanche 21 mai 2006 =E0 18:27 +0800, Davyd Madeley a =E9crit : > > On Wed, 2006-05-17 at 21:29 +0200, Damien Sandras wrote: > >=20 > > > I have created a new branch named "gnome-2-14" for Ekiga from the > > > current CVS HEAD. > >=20 > > What are your exciting plans for the next Ekiga? > >=20 >=20 > Most of the plans are on http://wiki.ekiga.org, but I would summarize it > by those big features : > - New user interface I have some problems selling Ekiga to my wife an mother-in-law because it lacks the list of contacts you are about to implement. Another detail is the "contact" button that they did not see as intuitive. Exchanging the button to a green phone handle (red when calling in progress) would make it more alike others and therefore easier to accept. Greetings /Kent --=20 Killing time murders opportunities. --Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEfucS4WZLcIH5l3kRAm+MAJ95cAJ7mAiuBBLrCdfk7vNFTiLv7ACeKWZd 6tzVdWbow84O8RfCFvm51AU= =lD5w -----END PGP SIGNATURE----- --Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ-- From jpuydt@free.fr Thu Jun 1 09:20:42 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 792AE3B01C4 for ; Thu, 1 Jun 2006 09:20:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05042-09 for ; Thu, 1 Jun 2006 09:20:38 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 505C93B01E3 for ; Thu, 1 Jun 2006 09:20:37 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-30-82-253-132-170.adsl.proxad.net [82.253.132.170]) by smtp1-g19.free.fr (Postfix) with ESMTP id DA3499ADFF for ; Thu, 1 Jun 2006 15:20:35 +0200 (CEST) Message-ID: <447EE9BE.5030005@free.fr> Date: Thu, 01 Jun 2006 15:21:02 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Re: Ekiga branched References: <1147894199.7225.2.camel@golgoth01> <1148207277.6654.0.camel@frobisher.madeley.id.au> <1148209984.2488.26.camel@golgoth01> <20060601150938.fcdea791.hoglet@solit.se> In-Reply-To: <20060601150938.fcdea791.hoglet@solit.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599] X-Spam-Score: -2.561 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:20:42 -0000 Kent Asplund a écrit : > Exchanging the button to a green phone handle (red when calling in > progress) would make it more alike others and therefore easier to > accept. The classic case of "your flying car lacks a spare wheel!" ;-) Snark From jan.schampera@web.de Thu Jun 1 12:03:48 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B922E3B0E4B for ; Thu, 1 Jun 2006 12:03:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18635-04 for ; Thu, 1 Jun 2006 12:03:47 -0400 (EDT) Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by menubar.gnome.org (Postfix) with ESMTP id EBE813B0E61 for ; Thu, 1 Jun 2006 12:01:39 -0400 (EDT) Received: from fwd29.aul.t-online.de by mailout05.sul.t-online.com with smtp id 1FlpcA-0003xH-07; Thu, 01 Jun 2006 18:01:38 +0200 Received: from mail.home.thebonsai.de (VypBOcZSYex2PaURfsq4FLxwkOKh2FKpRdjn4Nur7iMG3ImbsTH1w4@[84.147.102.147]) by fwd29.sul.t-online.de with esmtp id 1FlpO1-0yxMBM0; Thu, 1 Jun 2006 17:47:01 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id E08C06B173 for ; Thu, 1 Jun 2006 17:47:00 +0200 (CEST) Date: Thu, 1 Jun 2006 17:44:27 +0200 From: Jan Schampera To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode Message-ID: <20060601174427.48266dee@localhost.localdomain> In-Reply-To: <447DE4E2.7040204@cs.stanford.edu> References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> Organization: private X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: VypBOcZSYex2PaURfsq4FLxwkOKh2FKpRdjn4Nur7iMG3ImbsTH1w4@t-dialin.net X-TOI-MSGID: e6494e3b-869b-447f-a832-f769a200d3af X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.942 tagged_above=-999 required=2 tests=[AWL=0.656, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.942 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:03:48 -0000 On Wed, 31 May 2006 11:48:02 -0700 Dan Sandberg wrote: > 2) Replace the SDL/GTK/GDK calls that do the full screen resizing with > OpenGL ones. [ This is done, needs to be integrated ] Guess that's the key I searched for, when I measured those performance problems. Something that is "usually" installed on the user's machines and that has more power then GDK/SDL (I was afraid to raise yet another exotic dependancy, but OpenGL seems fair enough). J. -- "Be liberal in what you accept, and conservative in what you send." - J. B. Postel, master of the net. From siti@orcon.net.nz Fri Jun 2 05:53:55 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5C8803B10AE for ; Fri, 2 Jun 2006 05:53:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15897-03 for ; Fri, 2 Jun 2006 05:53:53 -0400 (EDT) Received: from dbmail-mx4.orcon.co.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 1A8E13B0EB6 for ; Fri, 2 Jun 2006 05:53:52 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx4.orcon.co.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k529rnLs032645 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 2 Jun 2006 21:53:50 +1200 From: Stephen Cook To: GnomeMeeting development mailing list Content-Type: text/plain Date: Fri, 02 Jun 2006 21:55:24 +1200 Message-Id: <1149242124.4509.17.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.2/1506/Fri Jun 2 16:01:20 2006 on dbmail-mx4.orcon.co.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: Subject: [GnomeMeeting-devel-list] IAX2 In Ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 09:53:55 -0000 Hi, I haven't introduced myself here before, I am Stephen Cook (siti). My proposal for implementing IAX2 in ekiga got accepted with google's summer of code. To give an update (I'll try and keep you guys regularly posted as to what's happening, any problems etc.). Currently I have been looking at the code to gain an understanding of ekiga and opal's code and design. Also obviously checking out the IAX2 code in opal :). From what I have seen and got working, I will work on getting IAX2 going in ekiga first. The main part of this will obviously involve writing a gnome meeting endpoint for IAX2. One key problem I have identified is the accounts code. The protocols are tightly integrated with how it works. I could either refactor this code to loosen the integration or hack iax2 support in there and refactor it later ;). The advantage of this refactored will be when someone wants to add Xmpp/libjingle support, or some other protocol down the track. Well, please tell me your thoughts and comments on this project. -Stephen From x@cs.stanford.edu Fri Jun 2 06:04:24 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0CBE83B0EB6 for ; Fri, 2 Jun 2006 06:04:24 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16680-02 for ; Fri, 2 Jun 2006 06:04:22 -0400 (EDT) Received: from smtp102.plus.mail.mud.yahoo.com (smtp102.plus.mail.mud.yahoo.com [68.142.206.235]) by menubar.gnome.org (Postfix) with SMTP id 1A3583B0490 for ; Fri, 2 Jun 2006 06:04:22 -0400 (EDT) Received: (qmail 57482 invoked from network); 2 Jun 2006 10:04:21 -0000 Received: from unknown (HELO ?192.168.2.47?) (dan?sandberg@71.138.128.214 with plain) by smtp102.plus.mail.mud.yahoo.com with SMTP; 2 Jun 2006 10:04:20 -0000 Message-ID: <44800CFA.5090800@cs.stanford.edu> Date: Fri, 02 Jun 2006 03:03:38 -0700 From: Dan Sandberg User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> In-Reply-To: <1149144061.2457.4.camel@golgoth01> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.808 tagged_above=-999 required=2 tests=[AWL=-0.593, BAYES_00=-2.599, SPF_SOFTFAIL=1.384] X-Spam-Score: -1.808 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 10:04:24 -0000 So configure.in is hand-generated? Surprising. 1) How exactly do I add the opengl ( libgl ) library? 2) Xrandr is mentioned in the Makefile, but is not in configure.in. How exactly does it get put into the Makefile? 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I didn't want to code against a moving target. Thanks, -Dan Damien Sandras wrote: >Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > > >>I'd imagine it would work on win32, but don't know. >> >> >> > >Probably. > > > >>I'll work on the patches. >> >>Where's the right place to add required libraries like openGL? >> >> > >In configure.in. > > > >>configure.in seems to be autogenerated by something, but whatever it is >>doesn't seem to be in the CVS snapshot... >> >> >> > >configure.in is in the CVS snapshot. > > > > >>Thanks, >> >>-Dan >> >>Julien PUYDT wrote: >> >> >> >>>Dan Sandberg a écrit : >>> >>> >>> >>>>How should we proceed? I could just send you an updated gui/main.cpp >>>>file... >>>> >>>> >>>I'd like to see patches instead of full files, preferably independant >>>on each others. >>> >>>There's also the question of the portability of this : since you >>>mention SDL, I guess this will work great on win32 too ? >>> >>>Snark >>>_______________________________________________ >>>Gnomemeeting-devel-list mailing list >>>Gnomemeeting-devel-list@gnome.org >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list >>> >>> >>> >>_______________________________________________ >>Gnomemeeting-devel-list mailing list >>Gnomemeeting-devel-list@gnome.org >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list >> >> From dsandras@seconix.com Fri Jun 2 07:06:22 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9B2253B0407 for ; Fri, 2 Jun 2006 07:06:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20694-02 for ; Fri, 2 Jun 2006 07:06:20 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 830933B0490 for ; Fri, 2 Jun 2006 07:06:20 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 3567C4974A for ; Fri, 2 Jun 2006 12:49:55 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03852-06 for ; Fri, 2 Jun 2006 12:49:51 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 5D9BD49749 for ; Fri, 2 Jun 2006 12:49:51 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <1149242124.4509.17.camel@siti> References: <1149242124.4509.17.camel@siti> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 02 Jun 2006 13:06:14 +0200 Message-Id: <1149246374.2966.25.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:06:22 -0000 Le vendredi 02 juin 2006 à 21:55 +1200, Stephen Cook a écrit : > Hi, > > I haven't introduced myself here before, I am Stephen Cook (siti). My > proposal for implementing IAX2 in ekiga got accepted with google's > summer of code. > > To give an update (I'll try and keep you guys regularly posted as to > what's happening, any problems etc.). > > Currently I have been looking at the code to gain an understanding of > ekiga and opal's code and design. Also obviously checking out the IAX2 > code in opal :). From what I have seen and got working, I will work on > getting IAX2 going in ekiga first. The main part of this will obviously > involve writing a gnome meeting endpoint for IAX2. > I would say that the main part will be to write / finish the IAX2 code in OPAL, either new code, or reusing the current code so that all features that you see in SIP and H.323 are also available for IAX2. Your first project will be to look the limitations of the current code and write a document showing what features you have tested, what work is required to complete them, and what new work is required for new features (Call Hold, Call Transfer, Registering, Call Forward, ...). Writing the endpoint in Ekiga is the last part of the project once the code in OPAL is full functional. Ekiga only contains high-level code. > One key problem I have identified is the accounts code. The protocols > are tightly integrated with how it works. I could either refactor this > code to loosen the integration or hack iax2 support in there and > refactor it later ;). The advantage of this refactored will be when > someone wants to add Xmpp/libjingle support, or some other protocol down > the track. > I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and finally perhaps to a refactoring of the accounts code as it is not the primary purpose of the Google SoC :) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Fri Jun 2 07:08:01 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 243E83B0407 for ; Fri, 2 Jun 2006 07:08:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20781-05 for ; Fri, 2 Jun 2006 07:07:58 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 6C7333B10B6 for ; Fri, 2 Jun 2006 07:07:58 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 5426B49753 for ; Fri, 2 Jun 2006 12:51:33 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06419-06 for ; Fri, 2 Jun 2006 12:51:18 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id EF0D549750 for ; Fri, 2 Jun 2006 12:51:17 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44800CFA.5090800@cs.stanford.edu> References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 02 Jun 2006 13:07:41 +0200 Message-Id: <1149246461.2966.28.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:08:01 -0000 Le vendredi 02 juin 2006 à 03:03 -0700, Dan Sandberg a écrit : > So configure.in is hand-generated? Surprising. > That's te way it works. You write configure.in and configure is generated from there. I guess you are confusing things here. > 1) How exactly do I add the opengl ( libgl ) library? > By writing autconf code in configure.in. No idea exactly how it should be done. > 2) Xrandr is mentioned in the Makefile, but is not in configure.in. How > exactly does it get put into the Makefile? > Probably by an external library that we are using. > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I didn't want > to code against a moving target. > Yes. It is even OK if you do not provide the configure.in code, but only the OpenGL Ekiga code. > Thanks, > > -Dan > > Damien Sandras wrote: > > >Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > > > > > >>I'd imagine it would work on win32, but don't know. > >> > >> > >> > > > >Probably. > > > > > > > >>I'll work on the patches. > >> > >>Where's the right place to add required libraries like openGL? > >> > >> > > > >In configure.in. > > > > > > > >>configure.in seems to be autogenerated by something, but whatever it is > >>doesn't seem to be in the CVS snapshot... > >> > >> > >> > > > >configure.in is in the CVS snapshot. > > > > > > > > > >>Thanks, > >> > >>-Dan > >> > >>Julien PUYDT wrote: > >> > >> > >> > >>>Dan Sandberg a écrit : > >>> > >>> > >>> > >>>>How should we proceed? I could just send you an updated gui/main.cpp > >>>>file... > >>>> > >>>> > >>>I'd like to see patches instead of full files, preferably independant > >>>on each others. > >>> > >>>There's also the question of the portability of this : since you > >>>mention SDL, I guess this will work great on win32 too ? > >>> > >>>Snark > >>>_______________________________________________ > >>>Gnomemeeting-devel-list mailing list > >>>Gnomemeeting-devel-list@gnome.org > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > >>> > >>> > >>> > >>_______________________________________________ > >>Gnomemeeting-devel-list mailing list > >>Gnomemeeting-devel-list@gnome.org > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > >> > >> > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From jpuydt@free.fr Fri Jun 2 09:55:37 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 35E163B0A0B for ; Fri, 2 Jun 2006 09:55:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30481-03 for ; Fri, 2 Jun 2006 09:55:35 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id DF18F3B0468 for ; Fri, 2 Jun 2006 09:55:34 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-30-82-253-132-170.adsl.proxad.net [82.253.132.170]) by smtp6-g19.free.fr (Postfix) with ESMTP id D0F23225C9 for ; Fri, 2 Jun 2006 15:55:31 +0200 (CEST) Message-ID: <44804375.6090107@free.fr> Date: Fri, 02 Jun 2006 15:56:05 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga References: <1149242124.4509.17.camel@siti> <1149246374.2966.25.camel@golgoth01> In-Reply-To: <1149246374.2966.25.camel@golgoth01> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599] X-Spam-Score: -2.561 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 13:55:37 -0000 Damien Sandras a écrit : > I would say that the main part will be to write / finish the IAX2 code > in OPAL, either new code, or reusing the current code so that all > features that you see in SIP and H.323 are also available for IAX2. > > Your first project will be to look the limitations of the current code > and write a document showing what features you have tested, what work is > required to complete them, and what new work is required for new > features (Call Hold, Call Transfer, Registering, Call Forward, ...). > > Writing the endpoint in Ekiga is the last part of the project once the > code in OPAL is full functional. Ekiga only contains high-level code. I don't fully agree with you: writing low-level code all summer long then finally writing the upper-level code, will lead to a non-working feature :-/ Having a least minimal functionality in ekiga would be nice to test the low-level regularly, and see it improving. >> One key problem I have identified is the accounts code. The protocols >> are tightly integrated with how it works. I could either refactor this >> code to loosen the integration or hack iax2 support in there and >> refactor it later ;). The advantage of this refactored will be when >> someone wants to add Xmpp/libjingle support, or some other protocol down >> the track. > > I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and > finally perhaps to a refactoring of the accounts code as it is not the > primary purpose of the Google SoC :) Indeed, the purpose is the IAX2 support, not refactoring the code. I would say that hardcoding the IAX2 account setup in the code would be enough for the SoC. Making it work in the ui in the accounts would be bonus if you had the time, or would be a work to do afterwards. Snark From dsandras@seconix.com Fri Jun 2 10:34:17 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C28113B045D for ; Fri, 2 Jun 2006 10:34:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00352-08 for ; Fri, 2 Jun 2006 10:34:16 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id CE7FF3B0478 for ; Fri, 2 Jun 2006 10:34:15 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 0EFE1496C7 for ; Fri, 2 Jun 2006 16:17:49 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08222-10 for ; Fri, 2 Jun 2006 16:17:42 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 3C897496C6 for ; Fri, 2 Jun 2006 16:17:42 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44804375.6090107@free.fr> References: <1149242124.4509.17.camel@siti> <1149246374.2966.25.camel@golgoth01> <44804375.6090107@free.fr> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 02 Jun 2006 16:34:27 +0200 Message-Id: <1149258867.8383.10.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 14:34:17 -0000 Le vendredi 02 juin 2006 à 15:56 +0200, Julien PUYDT a écrit : > Damien Sandras a écrit : > > I would say that the main part will be to write / finish the IAX2 code > > in OPAL, either new code, or reusing the current code so that all > > features that you see in SIP and H.323 are also available for IAX2. > > > > Your first project will be to look the limitations of the current code > > and write a document showing what features you have tested, what work is > > required to complete them, and what new work is required for new > > features (Call Hold, Call Transfer, Registering, Call Forward, ...). > > > > Writing the endpoint in Ekiga is the last part of the project once the > > code in OPAL is full functional. Ekiga only contains high-level code. > > I don't fully agree with you: writing low-level code all summer long > then finally writing the upper-level code, will lead to a non-working > feature :-/ I agree with you, but you can not start writing the EndPoint if there is no code behind it ;) > > Having a least minimal functionality in ekiga would be nice to test the > low-level regularly, and see it improving. > > >> One key problem I have identified is the accounts code. The protocols > >> are tightly integrated with how it works. I could either refactor this > >> code to loosen the integration or hack iax2 support in there and > >> refactor it later ;). The advantage of this refactored will be when > >> someone wants to add Xmpp/libjingle support, or some other protocol down > >> the track. > > > > I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and > > finally perhaps to a refactoring of the accounts code as it is not the > > primary purpose of the Google SoC :) > > Indeed, the purpose is the IAX2 support, not refactoring the code. I > would say that hardcoding the IAX2 account setup in the code would be > enough for the SoC. > > Making it work in the ui in the accounts would be bonus if you had the > time, or would be a work to do afterwards. > Exactly. > Snark > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From t.schorpp@gmx.de Fri Jun 2 11:06:17 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 63A943B02F7 for ; Fri, 2 Jun 2006 11:06:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02214-08 for ; Fri, 2 Jun 2006 11:06:10 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by menubar.gnome.org (Postfix) with SMTP id 7B6603B0421 for ; Fri, 2 Jun 2006 11:06:09 -0400 (EDT) Received: (qmail invoked by alias); 02 Jun 2006 15:06:08 -0000 Received: from p85.212.150.108.tisdip.tiscali.de (EHLO [192.168.1.100]) [85.212.150.108] by mail.gmx.net (mp001) with SMTP; 02 Jun 2006 17:06:08 +0200 X-Authenticated: #17142692 Message-ID: <448053DE.1010406@gmx.de> Date: Fri, 02 Jun 2006 17:06:06 +0200 From: thomas schorpp User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1 X-Accept-Language: de, en-us MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Bad review about Ekiga References: <1148993400.2400.77.camel@golgoth01> In-Reply-To: <1148993400.2400.77.camel@golgoth01> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.476 tagged_above=-999 required=2 tests=[AWL=-0.011, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] X-Spam-Score: -2.476 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: t.schorpp@gmx.de, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 15:06:17 -0000 Damien Sandras wrote: > http://linux.softpedia.com/progViewUserReviews/156167.html > > This software is a descendant of the former "gnome-meeting" software. It > comes bundled with its own SIP service but claims to work with others. > Unfortunately it has inherited not only the GUI from gnome-meeting but > also the habit to crash every other minute without apparent reason. So I > never got to really test it yet. > > The developers might be better off not making the same mistake as they > did with gnome-meeting and should try to fix all the bugs instead of > adding more crashing bells and whistles. Bad? Bad yes: for marketing. You cant just say this commenter were just too stupid to get the right libs together. Bad no: for development. says You need better CM: - suggest the devs and QA people, users, agree on a certain range of gui libs versions. - suggest meeting with distro maintainers and tight the deps found above to avoid lib/binary inconsistencies. - improve exception handling and fault tolerance on the outside interfaces. ? y tom From craigs@postincrement.com Fri Jun 2 19:57:21 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CDB2A3B11E3 for ; Fri, 2 Jun 2006 19:57:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32469-02 for ; Fri, 2 Jun 2006 19:57:18 -0400 (EDT) Received: from bastion.southeren.com (unknown [220.244.81.10]) by menubar.gnome.org (Postfix) with ESMTP id 870583B11CC for ; Fri, 2 Jun 2006 19:57:17 -0400 (EDT) Received: from [10.0.2.13] (rapido.southeren.com [10.0.2.13]) by bastion.southeren.com (8.12.8/8.12.8) with ESMTP id k52NteJG016237; Sat, 3 Jun 2006 09:55:40 +1000 Date: Sat, 03 Jun 2006 09:55:43 +1000 From: Craig Southeren To: Stephen Cook , GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga In-Reply-To: <1149242124.4509.17.camel@siti> References: <1149242124.4509.17.camel@siti> Message-Id: <20060603095331.79CD.CRAIGS@postincrement.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Becky! ver. 2.11.02 [en] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.939 tagged_above=-999 required=2 tests=[AWL=-0.482, BAYES_00=-2.599, SPF_FAIL=1.142] X-Spam-Score: -1.939 X-Spam-Level: Cc: Derek Smithies X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 23:57:22 -0000 On Fri, 02 Jun 2006 21:55:24 +1200 Stephen Cook wrote: > Hi, >=20 > I haven't introduced myself here before, I am Stephen Cook (siti). My > proposal for implementing IAX2 in ekiga got accepted with google's > summer of code. >=20 > To give an update (I'll try and keep you guys regularly posted as to > what's happening, any problems etc.). >=20 > Currently I have been looking at the code to gain an understanding of > ekiga and opal's code and design. Also obviously checking out the IAX2 > code in opal :). From what I have seen and got working, I will work on > getting IAX2 going in ekiga first. The main part of this will obviously > involve writing a gnome meeting endpoint for IAX2. >=20 > One key problem I have identified is the accounts code. The protocols > are tightly integrated with how it works. I could either refactor this > code to loosen the integration or hack iax2 support in there and > refactor it later ;). The advantage of this refactored will be when > someone wants to add Xmpp/libjingle support, or some other protocol down > the track. >=20 > Well, please tell me your thoughts and comments on this project. As a New Zealander, you are uniquely placed to communicate with the author of the OPAL IAX2 code, Derek Smithies, who is a fellow Kiwi! I am sure that you will be able to get the OPAL IAX2 code working with Ekiga in no time at all with his help.=20 If you have any questions, please contact me directly. Craig ----------------------------------------------------------------------- Craig Southeren Post Increment =96 VoIP Consulting and Software craigs@postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren@hotmail.com Mobile: +61 417231046 =20 "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting From hoglet@solit.se Sat Jun 3 03:46:01 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9178F3B04E8 for ; Sat, 3 Jun 2006 03:46:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19488-05 for ; Sat, 3 Jun 2006 03:45:59 -0400 (EDT) Received: from aurian.solit.se (unknown [82.182.216.174]) by menubar.gnome.org (Postfix) with ESMTP id 9DD3C3B0505 for ; Sat, 3 Jun 2006 03:45:59 -0400 (EDT) Received: from ip76.kassjo.se ([85.11.28.76] helo=localhost.localdomain) by aurian.solit.se with asmtp (Exim 3.35 #1 (Debian)) id 1FmQpW-0006J7-00 for ; Sat, 03 Jun 2006 09:45:54 +0200 Date: Sat, 3 Jun 2006 09:45:50 +0200 From: Kent Asplund To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Bad review about Ekiga Message-Id: <20060603094550.0e1ff8aa.hoglet@solit.se> In-Reply-To: <1148993400.2400.77.camel@golgoth01> References: <1148993400.2400.77.camel@golgoth01> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: ej spam, SpamAssassin (resultat=-4.4, krav 5, IN_REP_TO -4.43) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.898 tagged_above=-999 required=2 tests=[AWL=-1.435, BAYES_20=-0.74, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142] X-Spam-Score: -0.898 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 07:46:01 -0000 --Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 30 May 2006 14:50:00 +0200 Damien Sandras wrote: > http://linux.softpedia.com/progViewUserReviews/156167.html >=20 > This software is a descendant of the former "gnome-meeting" software. It > comes bundled with its own SIP service but claims to work with others. > Unfortunately it has inherited not only the GUI from gnome-meeting but > also the habit to crash every other minute without apparent reason. So I > never got to really test it yet. >=20 > The developers might be better off not making the same mistake as they > did with gnome-meeting and should try to fix all the bugs instead of > adding more crashing bells and whistles. I have never had a crash and the program was easy to setup. I have had some problem but they have been outside of Ekiga (siproxd and firewall) Ekiga has som distance to go to "get finished" but it is still THE BEST PROGRAM AROUND! Subjectively of course :) Waiting patiently for 2.2 /Hoglet --=20 Go ahead... make my day. -- Dirty Harry --Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEgT4x4WZLcIH5l3kRApw3AJ9yPgdPoUSeKGniD1w0w0cMTXajRACfWaDG 2YUvSTxFnaSeD8q0uWWv6zE= =2nFl -----END PGP SIGNATURE----- --Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny-- From hoglet@solit.se Sat Jun 3 03:54:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C25A43B05C8 for ; Sat, 3 Jun 2006 03:54:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19755-10 for ; Sat, 3 Jun 2006 03:54:38 -0400 (EDT) Received: from aurian.solit.se (unknown [82.182.216.174]) by menubar.gnome.org (Postfix) with ESMTP id B980A3B04F9 for ; Sat, 3 Jun 2006 03:54:38 -0400 (EDT) Received: from ip76.kassjo.se ([85.11.28.76] helo=localhost.localdomain) by aurian.solit.se with asmtp (Exim 3.35 #1 (Debian)) id 1FmQxt-0006L4-00 for ; Sat, 03 Jun 2006 09:54:33 +0200 Date: Sat, 3 Jun 2006 09:54:33 +0200 From: Kent Asplund To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Re: Ekiga branched Message-Id: <20060603095433.82461abf.hoglet@solit.se> In-Reply-To: <447EE9BE.5030005@free.fr> References: <1147894199.7225.2.camel@golgoth01> <1148207277.6654.0.camel@frobisher.madeley.id.au> <1148209984.2488.26.camel@golgoth01> <20060601150938.fcdea791.hoglet@solit.se> <447EE9BE.5030005@free.fr> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: ej spam, SpamAssassin (resultat=-4.4, krav 5, IN_REP_TO -4.43) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.764 tagged_above=-999 required=2 tests=[AWL=-0.519, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142, TW_KT=0.077] X-Spam-Score: -1.764 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 07:54:39 -0000 --Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 01 Jun 2006 15:21:02 +0200 Julien PUYDT wrote: > Kent Asplund a =E9crit : > > Exchanging the button to a green phone handle (red when calling in > > progress) would make it more alike others and therefore easier to > > accept. >=20 > The classic case of "your flying car lacks a spare wheel!" ;-) I'm taking the risk of seeming to be completely without humour. No, it is more a case of having a car with automatic gearbox and instead of having a lever you have a button for changing direction.=20 It works perfektly OK but people will think that it is a strange car and choose another one. (I think Citro=EBn had this problem) My wife just said "it is made for nerds not humans" Greetings /Hoglet the nerd --=20 I don't know anything about music. In my line you don't have to. -- Elvis Presley --Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEgUA54WZLcIH5l3kRAiYpAJ4/lkEYFVjWRQrYSvn7D9XmkU+6FgCgiejD m2Sp2AVqfZZHzT5TaBCVu5I= =OH96 -----END PGP SIGNATURE----- --Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ-- From devel@tootai.net Sat Jun 3 11:12:15 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3EF583B05AE for ; Sat, 3 Jun 2006 11:12:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11557-03 for ; Sat, 3 Jun 2006 11:12:10 -0400 (EDT) Received: from mail1.tootai.net (ns1.tootai.net [82.231.69.24]) by menubar.gnome.org (Postfix) with ESMTP id A02F63B0348 for ; Sat, 3 Jun 2006 11:12:09 -0400 (EDT) Received: from [192.168.0.17] (unknown [192.168.0.17]) by mail1.tootai.net (Postfix) with ESMTP id E2ACD398BA0 for ; Sat, 3 Jun 2006 17:12:06 +0200 (CEST) Message-ID: <4481A6AF.2060703@tootai.net> Date: Sat, 03 Jun 2006 17:11:43 +0200 From: Daniel Huhardeaux Organization: TOOTAi User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: GnomeMeeting development mailing list Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: Subject: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 15:12:15 -0000 Resent as it didn't pass at the first try (too big, I cut the begining of logs) Hi all, Ekiga behind a firewall is registering to an asterisk server which is on internet. The sip user is authorized with gsm,ulaw,alaw on asterisk side. When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is started, connection is showed with PCMU (why not GSM?), see the traffic in/out (~6 kB) but have no audio. I hangup the call, the hangup info is shown in the toolbar, PCMU disappear in codec and immediately after, traffic in/out continue with 0/0, icon in KDE Toolbar show Ekiga on line. The only solution I have is to kill Ekiga. If I deactivate GSM codec, everything is fine. Below you will find a d4 output from the call. [...] 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 OpalUDP Ended connect, selecting 82.231.69.24:35065 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP Queueing PDU: 1 INVITE <407> 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP Waiting for PDU on udp$213.203.241.243:5060 2006/06/02 13:12:32.901 0:10.661 SIP Handler:8520268 SIP PDU handler thread started. 2006/06/02 13:12:32.902 0:10.662 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:32.902 0:10.663 SIP Handler:8520268 SIP Handling PDU 1 INVITE <407> (with transaction) 2006/06/02 13:12:32.903 0:10.663 SIP Handler:8520268 SIP Transaction 1 INVITE completed. 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP Sending PDU on udp$213.203.241.243:5060 ACK sip:800@sip.tootai.net SIP/2.0 CSeq: 1 ACK Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bK803b125b-96f0-da11-8388-000ea6217592;rport From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: ;tag=as315809c6 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 70 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP Received Proxy Authentication Required response 2006/06/02 13:12:32.906 0:10.666 SIP Handler:8520268 SIP Transaction 2 INVITE created. 2006/06/02 13:12:32.906 0:10.667 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:33.090 0:10.850 SIP Handler:8520268 RTP_UDP Session 1 created: 82.231.69.24:35010-35011 ssrc=703395120 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 RTP Adding session RTP_UDP 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 SIP Using RTP payload [pt=101] for NTE 2006/06/02 13:12:33.100 0:10.860 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k H.261(QCIF) H.261(CIF) YUV420P RGB32 RGB24 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 2 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 2 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 SIP IsMediaBypassPossible: session 2 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:33.281 0:11.041 SIP Handler:8520268 RTP_UDP Session 2 created: 82.231.69.24:35014-35015 ssrc=2454563097 2006/06/02 13:12:33.282 0:11.042 SIP Handler:8520268 RTP Adding session RTP_UDP 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k H.261(QCIF) H.261(CIF) YUV420P RGB32 RGB24 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 SIP Adding authentication information 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP Sending PDU on udp$213.203.241.243:5060 INVITE sip:800@sip.tootai.net SIP/2.0 Date: Fri, 02 Jun 2006 11:12:32 GMT CSeq: 2 INVITE Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;rport User-Agent: Ekiga/2.0.1-20060521-01 From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: Contact: Proxy-Authorization: Digest username="104", realm="sip.tootai.net", nonce="12d01d5d", uri="sip:800@sip.tootai.net", response="60b65ec9045130eab45495d3c65fbc5e", algorithm=md5 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Type: application/sdp Content-Length: 302 Max-Forwards: 70 v=0 o=- 1149246753 1149246753 IN IP4 82.231.69.24 s=Opal SIP Session c=IN IP4 82.231.69.24 t=0 0 m=audio 35010 RTP/AVP 101 3 0 8 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 m=video 35014 RTP/AVP 31 a=rtpmap:31 H261/90000 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP PDU Received on udp$213.203.241.243:5060 SIP/2.0 100 Trying CSeq: 2 INVITE Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 User-Agent: Asterisk PBX From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP Queueing PDU: 2 INVITE <100> 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP Waiting for PDU on udp$213.203.241.243:5060 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP Handling PDU 2 INVITE <100> (with transaction) 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP Transaction 2 INVITE proceeding. 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Set targetAddress to sip:800@213.203.241.243 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Received Trying response 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP Media session port=7166 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP Adding media session with 2 formats 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP Unknown media attribute silenceSupp:off - - - - 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SIP PDU Received on udp$213.203.241.243:5060 SIP/2.0 200 OK CSeq: 2 INVITE Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 User-Agent: Asterisk PBX From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: ;tag=as5d2831d1 Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Type: application/sdp Content-Length: 221 v=0 o=root 26912 26912 IN IP4 213.203.241.243 s=session c=IN IP4 213.203.241.243 t=0 0 m=audio 7166 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP Queueing PDU: 2 INVITE <200> 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP Waiting for PDU on udp$213.203.241.243:5060 2006/06/02 13:12:33.388 0:11.148 SIP Handler:8520268 SIP Handling PDU 2 INVITE <200> (with transaction) 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP Transaction 2 INVITE completed. 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP Set targetAddress to sip:800@213.203.241.243 2006/06/02 13:12:33.390 0:11.150 SIP Handler:8520268 SIP Adding authentication information 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP Adjusting transport to address udp$213.203.241.243:5060 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP Sending PDU on udp$213.203.241.243:5060 ACK sip:800@213.203.241.243 SIP/2.0 CSeq: 2 ACK Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bK6e2ca15b-96f0-da11-8388-000ea6217592;rport From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: ;tag=as5d2831d1 Contact: Proxy-Authorization: Digest username="104", realm="sip.tootai.net", nonce="12d01d5d", uri="sip:800@213.203.241.243", response="059defd67706254552a5c23eada565b5", algorithm=md5 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 70 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP Received INVITE OK response 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 SIP RTP payload type PCMU matched to codec G.711-uLaw-64k 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 OpalCon OpenSourceMediaStream for session 1 on Call[1]-EP[Default] 2006/06/02 13:12:33.398 0:11.158 SIP Handler:8520268 OpalCon Selected media stream PCM-16 -> G.711-uLaw-64k 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 Call PatchMediaStreams Call[1]-EP[Default] 2006/06/02 13:12:34.196 0:11.957 SIP Handler:8520268 OpalCon OpenSinkMediaStream Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session=1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon OpenSinkMediaStream, selected PCM-16 -> G.711-uLaw-64k 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:34.197 0:11.958 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Patch Added sink from PCM-16 Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 16 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 to G.711-uLaw-64k Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 8 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Codec G711-uLaw-64k encoder created 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Patch Added media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k using transcoder PCM-16->G.711-uLaw-64k 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Media Audio source data size set to 320 bytes and 2 buffers. 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call GetOtherPartyConnection Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon OpenSourceMediaStream for session 1 on Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon Selected media stream G.711-uLaw-64k -> PCM-16 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 Call PatchMediaStreams Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon OpenSinkMediaStream Call[1]-EP[Default] session=1 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon OpenSinkMediaStream, selected G.711-uLaw-64k -> PCM-16 2006/06/02 13:12:34.513 0:12.274 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:34.514 0:12.274 SIP Handler:8520268 Patch Added sink from G.711-uLaw-64k Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 8 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 to PCM-16 Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 16 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Codec G711-uLaw-64k decoder created 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Media Audio sink data size set to 320 bytes and 2 buffers. 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Patch Added media stream sink OpalAudioMediaStream-Sink-PCM-16 using transcoder G.711-uLaw-64k->PCM-16 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.525 0:12.285 SIP Handler:8520268 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.527 0:12.287 SIP Handler:8520268 RTP_UDP SetRemoteSocketInfo: session=1 data channel, new=213.203.241.243:7166, local=82.231.69.24:35010-35011, remote=0.0.0.0:0-0 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 SIP Could not find SDP media description for Video 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 OpalMan OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 Call OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 PCSS SetConnected() 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 GMPCSSEndpoint PCSS connection established 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 GMManager Will establish the connection 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 OpalMan OnEstablished Call[1]-EP[Default] 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 Call OnEstablished Call[1]-EP[Default] 2006/06/02 13:12:34.540 0:12.300 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[Default] G.711-uLaw-64k 2006/06/02 13:12:34.541 0:12.301 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k 2006/06/02 13:12:34.542 0:12.302 SIP Handler:8520268 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.543 0:12.303 SIP Handler:8520268 Call OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] G.711-uLaw-64k 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[Default] 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k 2006/06/02 13:12:34.552 0:12.312 SIP Handler:8520268 Call OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k 2006/06/02 13:12:34.553 0:12.313 Media Patch:8175708 Patch Thread started for Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:34.556 0:12.316 SIP Handler:8520268 Media Starting thread Media Patch:8175708 2006/06/02 13:12:34.557 0:12.317 Media Patch:8527348 Patch Thread started for Patch OpalRTPMediaStream-Source-G.711-uLaw-64k -> OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:34.568 0:12.329 Media Patch:8527348 RTP Jitter buffer created: size=101 delay=160-4000/160 (20ms) obj=0x8526b30 2006/06/02 13:12:34.572 0:12.333 RTP Jitter:8526b30 RTP Jitter RTP receive thread started: 0x8526b30 2006/06/02 13:12:34.574 0:12.334 RTP Jitter:8526b30 RTP First receive data: ver=2 pt=GSM psz=33 m=0 x=0 seq=39915 ts=160 src=824302623 ccnt=0 2006/06/02 13:12:34.580 0:12.341 SIP Handler:8520268 Media Starting thread Media Patch:8527348 2006/06/02 13:12:34.581 0:12.341 SIP Handler:8520268 OpalCon Media stream threads started. 2006/06/02 13:12:34.582 0:12.342 SIP Handler:8520268 OpalCon Media stream threads started. 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP Found existing session 2 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 GMManager Will establish the connection 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 OpalMan OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.607 0:12.367 SIP Handler:8520268 Call OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.610 0:12.371 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:34.648 0:12.408 Media Patch:8527348 RTP Jitter buffer length exceeded 2006/06/02 13:12:34.649 0:12.409 Media Patch:8527348 RTP Jitter buffer length exceed was prior to first write. Not increasing buffer size 2006/06/02 13:12:35.277 0:13.037 Media Patch:8175708 RTP First sent data: ver=2 pt=PCMU psz=160 m=1 x=0 seq=1460 ts=0 src=703395120 ccnt=0 2006/06/02 13:12:35.608 0:13.368 Housekeeper RTP Found existing session 1 2006/06/02 13:12:35.609 0:13.369 Housekeeper RTP Found existing session 2 2006/06/02 13:12:36.137 0:13.898 RTP Jitter:8526b30 RTP Receive statistics: packets=101 octets=3714 lost=0 tooLate=0 order=0 avgTime=15 maxTime=1556 minTime=0 jitter=16 maxJitter=188 2006/06/02 13:12:36.573 0:14.333 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (9760) 2006/06/02 13:12:36.614 0:14.374 Housekeeper RTP Found existing session 1 2006/06/02 13:12:36.615 0:14.375 Housekeeper RTP Found existing session 2 2006/06/02 13:12:36.974 0:14.734 RTP Jitter:8526b30 RTP Jitter buffer continuously full, throwing away entire buffer. 2006/06/02 13:12:36.995 0:14.756 RTP Jitter:8526b30 RTP Jitter buffer full, threw away 21 oldest frames 2006/06/02 13:12:37.374 0:15.134 RTP Jitter:8526b30 RTP Receive statistics: packets=201 octets=19714 lost=0 tooLate=0 order=0 avgTime=12 maxTime=23 minTime=0 jitter=0 maxJitter=188 2006/06/02 13:12:37.620 0:15.380 Housekeeper RTP Found existing session 1 2006/06/02 13:12:37.621 0:15.381 Housekeeper RTP Found existing session 2 2006/06/02 13:12:37.820 0:15.580 Media Patch:8175708 RTP Transmit statistics: packets=101 octets=16160 avgTime=25 maxTime=48 minTime=23 2006/06/02 13:12:38.624 0:16.384 Housekeeper RTP Found existing session 1 2006/06/02 13:12:38.625 0:16.385 Housekeeper RTP Found existing session 2 2006/06/02 13:12:38.993 0:16.753 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (29120) 2006/06/02 13:12:39.374 0:17.134 RTP Jitter:8526b30 RTP Receive statistics: packets=301 octets=35714 lost=0 tooLate=0 order=0 avgTime=20 maxTime=26 minTime=14 jitter=1 maxJitter=188 2006/06/02 13:12:39.395 0:17.155 RTP Jitter:8526b30 RTP Jitter buffer continuously full, throwing away entire buffer. 2006/06/02 13:12:39.415 0:17.176 RTP Jitter:8526b30 RTP Jitter buffer full, threw away 21 oldest frames 2006/06/02 13:12:39.632 0:17.392 Housekeeper RTP Found existing session 1 2006/06/02 13:12:39.633 0:17.393 Housekeeper RTP Found existing session 2 2006/06/02 13:12:40.384 0:18.144 Media Patch:8175708 RTP Transmit statistics: packets=201 octets=32160 avgTime=25 maxTime=44 minTime=22 2006/06/02 13:12:40.640 0:18.400 Housekeeper RTP Found existing session 1 2006/06/02 13:12:40.641 0:18.401 Housekeeper RTP Found existing session 2 2006/06/02 13:12:41.373 0:19.133 RTP Jitter:8526b30 RTP Receive statistics: packets=401 octets=51714 lost=0 tooLate=0 order=0 avgTime=19 maxTime=26 minTime=13 jitter=1 maxJitter=188 2006/06/02 13:12:41.413 0:19.173 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (48480) 2006/06/02 13:12:41.648 0:19.424 Housekeeper RTP Found existing session 1 2006/06/02 13:12:41.665 0:19.425 Housekeeper RTP Found existing session 2 2006/06/02 13:12:41.813 0:19.573 RTP Jitter:8526b30 RTP Jitter buffer continuously full, throwing away entire buffer. 2006/06/02 13:12:41.833 0:19.593 RTP Jitter:8526b30 RTP Jitter buffer full, threw away 21 oldest frames 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP Found existing session 1 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP Found existing session 2 2006/06/02 13:12:42.920 0:20.680 Media Patch:8175708 RTP Transmit statistics: packets=301 octets=48160 avgTime=25 maxTime=49 minTime=22 2006/06/02 13:12:43.378 0:21.139 RTP Jitter:8526b30 RTP Receive statistics: packets=501 octets=67714 lost=0 tooLate=0 order=0 avgTime=20 maxTime=27 minTime=12 jitter=1 maxJitter=188 2006/06/02 13:12:43.696 0:21.457 Housekeeper RTP Found existing session 1 2006/06/02 13:12:43.697 0:21.457 Housekeeper RTP Found existing session 2 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot Call Clearing Call[1] reason=EndedByLocalUser 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot OpalCon Releasing Call[1]-EP[Default] 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon Call end reason for Default set to EndedByLocalUser 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon SetPhase from EstablishedPhase to ReleasingPhase 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon Releasing Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon Call end reason for fa44075b-96f0-da11-8388-000ea6217592@nomade set to EndedByLocalUser 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon SetPhase from EstablishedPhase to ReleasingPhase 2006/06/02 13:12:43.820 0:21.581 OnRelease:856e8a0 OpalCon OnReleased Call[1]-EP[Default] 2006/06/02 13:12:43.822 0:21.583 OnRelease:856e8a0 Media Closing raw media stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.824 0:21.584 OnRelease:856e8a0 Media Closing stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.825 0:21.585 OnRelease:856e8a0 Media Disconnecting OpalAudioMediaStream-Source-PCM-16 from patch thread Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.827 0:21.587 OnRelease:856e8a0 Patch Closing media patch Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.829 0:21.589 OnRelease:856e8a0 Media Closing raw media stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.830 0:21.590 OnRelease:856e8a0 Media Closing stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.831 0:21.591 OnRelease:84f8c00 SIP OnReleased: Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade], phase = ReleasingPhase 2006/06/02 13:12:43.833 0:21.593 OnRelease:84f8c00 OpalCon SetPhase from ReleasingPhase to ReleasingPhase 2006/06/02 13:12:43.834 0:21.594 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (67840) 2006/06/02 13:12:43.836 0:21.596 OnRelease:84f8c00 SIP Transaction 4 BYE created. 2006/06/02 13:12:43.842 0:21.603 OnRelease:84f8c00 Media Closing RTP for OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.844 0:21.604 OnRelease:84f8c00 RTP_UDP Session 1, Shutting down write. 2006/06/02 13:12:43.845 0:21.605 OnRelease:84f8c00 Media Closing stream OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.846 0:21.606 OnRelease:84f8c00 Media Disconnecting OpalRTPMediaStream-Sink-G.711-uLaw-64k from patch thread Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.848 0:21.609 OnRelease:84f8c00 Patch Removing media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.855 0:21.626 OnRelease:84f8c00 Media Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.867 0:21.627 OnRelease:84f8c00 RTP_UDP Session 1, Shutting down read. 2006/06/02 13:12:43.868 0:21.628 OnRelease:84f8c00 Media Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.869 0:21.630 OnRelease:84f8c00 Media Disconnecting OpalRTPMediaStream-Source-G.711-uLaw-64k from patch thread Patch OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.893 0:21.653 Media Patch:8175708 Patch Thread ended for Patch OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.893 0:21.653 OnRelease:84f8c00 Patch Closing media patch Patch OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.916 0:21.676 RTP Jitter:8526b30 RTP_UDP Session 1, Read shutdown. 2006/06/02 13:12:43.917 0:21.677 RTP Jitter:8526b30 RTP Jitter RTP receive thread ended 2006/06/02 13:12:43.917 0:21.677 OnRelease:84f8c00 Media Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.918 0:21.678 OnRelease:84f8c00 RTP_UDP Session 1, Shutting down read. 2006/06/02 13:12:43.919 0:21.679 OnRelease:84f8c00 Media Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.922 0:21.683 OnRelease:856e8a0 Patch Waiting for media patch thread to stop Patch OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.926 0:21.686 OnRelease:856e8a0 Patch Media patch thread Patch OpalAudioMediaStream-Source-PCM-16 destroyed. 2006/06/02 13:12:43.930 0:21.691 OnRelease:856e8a0 Media Closing raw media stream OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:43.932 0:21.693 OnRelease:856e8a0 Media Closing stream OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:43.933 0:21.694 OnRelease:856e8a0 Media Disconnecting OpalAudioMediaStream-Sink-PCM-16 from patch thread Patch OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.956 0:21.717 OnRelease:856e8a0 Patch Removing media stream sink OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP Found existing session 1 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP Found existing session 2 2006/06/02 13:12:45.696 0:23.456 Housekeeper RTP Found existing session 1 2006/06/02 13:12:45.697 0:23.457 Housekeeper RTP Found existing session 2 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP Found existing session 1 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP Found existing session 2 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP Found existing session 1 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP Found existing session 2 2006/06/02 13:12:48.708 0:26.468 Housekeeper RTP Found existing session 1 2006/06/02 13:12:48.709 0:26.469 Housekeeper RTP Found existing session 2 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP Found existing session 1 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP Found existing session 2 2006/06/02 13:12:50.712 0:28.473 Housekeeper RTP Found existing session 1 2006/06/02 13:12:50.713 0:28.473 Housekeeper RTP Found existing session 2 2006/06/02 13:12:51.716 0:29.477 Housekeeper RTP Found existing session 1 2006/06/02 13:12:51.717 0:29.477 Housekeeper RTP Found existing session 2 2006/06/02 13:12:52.716 0:30.477 Housekeeper RTP Found existing session 1 2006/06/02 13:12:52.717 0:30.477 Housekeeper RTP Found existing session 2 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP Found existing session 1 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP Found existing session 2 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP Found existing session 1 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP Found existing session 2 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP Found existing session 1 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP Found existing session 2 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP Found existing session 1 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP Found existing session 2 2006/06/02 13:12:57.733 0:35.493 Housekeeper RTP Found existing session 1 2006/06/02 13:12:57.734 0:35.494 Housekeeper RTP Found existing session 2 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP Found existing session 1 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP Found existing session 2 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP Found existing session 1 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP Found existing session 2 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP Found existing session 1 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP Found existing session 2 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP Found existing session 1 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP Found existing session 2 2006/06/02 13:13:02.777 0:40.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:02.778 0:40.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP Found existing session 2 2006/06/02 13:13:04.369 0:42.129 Housekeeper SIP Set state Terminated_Success for transaction 1 INVITE 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP Found existing session 2 2006/06/02 13:13:05.777 0:43.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:05.777 0:43.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:06.613 0:44.374 Housekeeper SIP Set state Terminated_Success for transaction 2 INVITE 2006/06/02 13:13:06.777 0:44.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:06.778 0:44.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:07.777 0:45.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:07.778 0:45.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP Found existing session 2 Processus arrêté -- Daniel From dsandras@seconix.com Sat Jun 3 13:58:00 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 184373B06A7 for ; Sat, 3 Jun 2006 13:58:00 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20355-03 for ; Sat, 3 Jun 2006 13:57:57 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 19BB03B036E for ; Sat, 3 Jun 2006 13:57:56 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id BC1A4493FD; Sat, 3 Jun 2006 19:41:15 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13551-03; Sat, 3 Jun 2006 19:41:05 +0200 (CEST) Received: from d51A5F203.access.telenet.be (d51A5F203.access.telenet.be [81.165.242.3]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id BC664493EE; Sat, 3 Jun 2006 19:41:05 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <20060603095331.79CD.CRAIGS@postincrement.com> References: <1149242124.4509.17.camel@siti> <20060603095331.79CD.CRAIGS@postincrement.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Sat, 03 Jun 2006 19:57:45 +0200 Message-Id: <1149357465.2414.30.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: Cc: Derek Smithies X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 17:58:00 -0000 Le samedi 03 juin 2006 à 09:55 +1000, Craig Southeren a écrit : > On Fri, 02 Jun 2006 21:55:24 +1200 > Stephen Cook wrote: > > > Hi, > > > > I haven't introduced myself here before, I am Stephen Cook (siti). My > > proposal for implementing IAX2 in ekiga got accepted with google's > > summer of code. > > > > To give an update (I'll try and keep you guys regularly posted as to > > what's happening, any problems etc.). > > > > Currently I have been looking at the code to gain an understanding of > > ekiga and opal's code and design. Also obviously checking out the IAX2 > > code in opal :). From what I have seen and got working, I will work on > > getting IAX2 going in ekiga first. The main part of this will obviously > > involve writing a gnome meeting endpoint for IAX2. > > > > One key problem I have identified is the accounts code. The protocols > > are tightly integrated with how it works. I could either refactor this > > code to loosen the integration or hack iax2 support in there and > > refactor it later ;). The advantage of this refactored will be when > > someone wants to add Xmpp/libjingle support, or some other protocol down > > the track. > > > > Well, please tell me your thoughts and comments on this project. > > As a New Zealander, you are uniquely placed to communicate with the > author of the OPAL IAX2 code, Derek Smithies, who is a fellow Kiwi! I am > sure that you will be able to get the OPAL IAX2 code working with Ekiga > in no time at all with his help. > > If you have any questions, please contact me directly. > Craig, I do not think moving to an offline conversation with Stephen is a good idea. Julien and myself are supposed to mentor the project. Your help is of course welcome, but we have to be kept informed. Notice also that the project is not only about making IAX2 work with Ekiga. -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Sat Jun 3 14:01:08 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 59C003B01BB for ; Sat, 3 Jun 2006 14:01:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20343-10 for ; Sat, 3 Jun 2006 14:01:02 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id BA0863B04B1 for ; Sat, 3 Jun 2006 14:01:01 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 1184A496A8 for ; Sat, 3 Jun 2006 19:44:21 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13551-04 for ; Sat, 3 Jun 2006 19:44:12 +0200 (CEST) Received: from d51A5F203.access.telenet.be (d51A5F203.access.telenet.be [81.165.242.3]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 993CE49685 for ; Sat, 3 Jun 2006 19:44:07 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <4481A6AF.2060703@tootai.net> References: <4481A6AF.2060703@tootai.net> Content-Type: text/plain; charset=ISO-8859-15 Date: Sat, 03 Jun 2006 20:00:48 +0200 Message-Id: <1149357648.2414.34.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 18:01:08 -0000 Hi, Le samedi 03 juin 2006 à 17:11 +0200, Daniel Huhardeaux a écrit : > Resent as it didn't pass at the first try (too big, I cut the begining > of logs) > > Hi all, > > Ekiga behind a firewall is registering to an asterisk server which is on > internet. The sip user is authorized with gsm,ulaw,alaw on asterisk side. > > When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is > started, connection is showed with PCMU (why not GSM?), see the traffic > in/out (~6 kB) but have no audio. > Asterisk answers with 200 OK indicating that the call should be done with PCMU. > I hangup the call, the hangup info is shown in the toolbar, PCMU > disappear in codec and immediately after, traffic in/out continue with > 0/0, icon in KDE Toolbar show Ekiga on line. The only solution I have is > to kill Ekiga. > Please try with 2.0.2. Craig has done work in CVS and things are potentially broken. If the problem persists once plugins support is in CVS, please report again. > If I deactivate GSM codec, everything is fine. Below you will find a d4 > output from the call. > I do not think activating GSM or not has any influence. The problem is probably something else. > > [...] > 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 OpalUDP > Ended connect, selecting 82.231.69.24:35065 > 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP > Queueing PDU: 1 INVITE <407> > 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP > Waiting for PDU on udp$213.203.241.243:5060 > 2006/06/02 13:12:32.901 0:10.661 SIP Handler:8520268 SIP PDU > handler thread started. > 2006/06/02 13:12:32.902 0:10.662 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:32.902 0:10.663 SIP Handler:8520268 SIP > Handling PDU 1 INVITE <407> (with transaction) > 2006/06/02 13:12:32.903 0:10.663 SIP Handler:8520268 SIP > Transaction 1 INVITE completed. > 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP > Sending PDU on udp$213.203.241.243:5060 > ACK sip:800@sip.tootai.net SIP/2.0 > CSeq: 1 ACK > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bK803b125b-96f0-da11-8388-000ea6217592;rport > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: ;tag=as315809c6 > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE > Content-Length: 0 > Max-Forwards: 70 > > > 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP > Received Proxy Authentication Required response > 2006/06/02 13:12:32.906 0:10.666 SIP Handler:8520268 SIP > Transaction 2 INVITE created. > 2006/06/02 13:12:32.906 0:10.667 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:33.090 0:10.850 SIP Handler:8520268 RTP_UDP > Session 1 created: 82.231.69.24:35010-35011 ssrc=703395120 > 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 RTP > Adding session RTP_UDP > 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 SIP > Using RTP payload [pt=101] for NTE > 2006/06/02 13:12:33.100 0:10.860 SIP Handler:8520268 Call > GetMediaFormats for > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > GSM-06.10 > G.711-uLaw-64k > G.711-ALaw-64k > H.261(QCIF) > H.261(CIF) > YUV420P > RGB32 > RGB24 > > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 2 > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 2 > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 2 > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:33.281 0:11.041 SIP Handler:8520268 RTP_UDP > Session 2 created: 82.231.69.24:35014-35015 ssrc=2454563097 > 2006/06/02 13:12:33.282 0:11.042 SIP Handler:8520268 RTP > Adding session RTP_UDP > 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 Call > GetMediaFormats for > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > GSM-06.10 > G.711-uLaw-64k > G.711-ALaw-64k > H.261(QCIF) > H.261(CIF) > YUV420P > RGB32 > RGB24 > > 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 SIP > Adding authentication information > 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP > Sending PDU on udp$213.203.241.243:5060 > INVITE sip:800@sip.tootai.net SIP/2.0 > Date: Fri, 02 Jun 2006 11:12:32 GMT > CSeq: 2 INVITE > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;rport > User-Agent: Ekiga/2.0.1-20060521-01 > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: > Contact: > Proxy-Authorization: Digest username="104", realm="sip.tootai.net", > nonce="12d01d5d", uri="sip:800@sip.tootai.net", > response="60b65ec9045130eab45495d3c65fbc5e", algorithm=md5 > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE > Content-Type: application/sdp > Content-Length: 302 > Max-Forwards: 70 > > v=0 > o=- 1149246753 1149246753 IN IP4 82.231.69.24 > s=Opal SIP Session > c=IN IP4 82.231.69.24 > t=0 0 > m=audio 35010 RTP/AVP 101 3 0 8 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=rtpmap:3 GSM/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > m=video 35014 RTP/AVP 31 > a=rtpmap:31 H261/90000 > > 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP PDU > Received on udp$213.203.241.243:5060 > SIP/2.0 100 Trying > CSeq: 2 INVITE > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 > User-Agent: Asterisk PBX > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: > Contact: > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > Content-Length: 0 > > > 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP > Queueing PDU: 2 INVITE <100> > 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP > Waiting for PDU on udp$213.203.241.243:5060 > 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP > Handling PDU 2 INVITE <100> (with transaction) > 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP > Transaction 2 INVITE proceeding. > 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Set > targetAddress to sip:800@213.203.241.243 > 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP > Received Trying response > 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP > Media session port=7166 > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP > Adding media session with 2 formats > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP > Unknown media attribute silenceSupp:off - - - - > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SIP PDU > Received on udp$213.203.241.243:5060 > SIP/2.0 200 OK > CSeq: 2 INVITE > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 > User-Agent: Asterisk PBX > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: ;tag=as5d2831d1 > Contact: > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > Content-Type: application/sdp > Content-Length: 221 > > v=0 > o=root 26912 26912 IN IP4 213.203.241.243 > s=session > c=IN IP4 213.203.241.243 > t=0 0 > m=audio 7166 RTP/AVP 0 101 > a=rtpmap:0 PCMU/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=silenceSupp:off - - - - > > 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP > Queueing PDU: 2 INVITE <200> > 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP > Waiting for PDU on udp$213.203.241.243:5060 > 2006/06/02 13:12:33.388 0:11.148 SIP Handler:8520268 SIP > Handling PDU 2 INVITE <200> (with transaction) > 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP > Transaction 2 INVITE completed. > 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP Set > targetAddress to sip:800@213.203.241.243 > 2006/06/02 13:12:33.390 0:11.150 SIP Handler:8520268 SIP > Adding authentication information > 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP > Adjusting transport to address udp$213.203.241.243:5060 > 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP > Sending PDU on udp$213.203.241.243:5060 > ACK sip:800@213.203.241.243 SIP/2.0 > CSeq: 2 ACK > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bK6e2ca15b-96f0-da11-8388-000ea6217592;rport > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: ;tag=as5d2831d1 > Contact: > Proxy-Authorization: Digest username="104", realm="sip.tootai.net", > nonce="12d01d5d", uri="sip:800@213.203.241.243", > response="059defd67706254552a5c23eada565b5", algorithm=md5 > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE > Content-Length: 0 > Max-Forwards: 70 > > > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP > Received INVITE OK response > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 SIP RTP > payload type PCMU matched to codec G.711-uLaw-64k > 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k > 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 OpalCon > OpenSourceMediaStream for session 1 on Call[1]-EP[Default] > 2006/06/02 13:12:33.398 0:11.158 SIP Handler:8520268 OpalCon > Selected media stream PCM-16 -> G.711-uLaw-64k > 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 OpalMan > OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 Call > PatchMediaStreams Call[1]-EP[Default] > 2006/06/02 13:12:34.196 0:11.957 SIP Handler:8520268 OpalCon > OpenSinkMediaStream > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session=1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon > OpenSinkMediaStream, selected PCM-16 -> G.711-uLaw-64k > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:34.197 0:11.958 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 OpalMan > OnOpenMediaStream > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Patch > Added sink > from PCM-16 > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 16 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > to G.711-uLaw-64k > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 8 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > > 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Codec > G711-uLaw-64k encoder created > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Patch > Added media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k using > transcoder PCM-16->G.711-uLaw-64k > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Media > Audio source data size set to 320 bytes and 2 buffers. > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call > GetOtherPartyConnection > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon > OpenSourceMediaStream for session 1 on > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon > Selected media stream G.711-uLaw-64k -> PCM-16 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalMan > OnOpenMediaStream > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 Call > PatchMediaStreams > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon > OpenSinkMediaStream Call[1]-EP[Default] session=1 > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon > OpenSinkMediaStream, selected G.711-uLaw-64k -> PCM-16 > 2006/06/02 13:12:34.513 0:12.274 SIP Handler:8520268 OpalMan > OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:34.514 0:12.274 SIP Handler:8520268 Patch > Added sink > from G.711-uLaw-64k > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 8 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > to PCM-16 > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 16 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Codec > G711-uLaw-64k decoder created > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Media > Audio sink data size set to 320 bytes and 2 buffers. > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Patch > Added media stream sink OpalAudioMediaStream-Sink-PCM-16 using > transcoder G.711-uLaw-64k->PCM-16 > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.525 0:12.285 SIP Handler:8520268 OpalCon > OpenSourceMediaStream (already opened) for session 1 on > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.527 0:12.287 SIP Handler:8520268 RTP_UDP > SetRemoteSocketInfo: session=1 data channel, new=213.203.241.243:7166, > local=82.231.69.24:35010-35011, remote=0.0.0.0:0-0 > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 SIP > Could not find SDP media description for Video > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 OpalMan > OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 Call > OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 PCSS > SetConnected() > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 > GMPCSSEndpoint PCSS connection established > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 > GMManager Will establish the connection > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 OpalMan > OnEstablished Call[1]-EP[Default] > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 Call > OnEstablished Call[1]-EP[Default] > 2006/06/02 13:12:34.540 0:12.300 SIP Handler:8520268 Call > GetMediaFormats for Call[1]-EP[Default] > G.711-uLaw-64k > > 2006/06/02 13:12:34.541 0:12.301 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k > 2006/06/02 13:12:34.542 0:12.302 SIP Handler:8520268 OpalCon > OpenSourceMediaStream (already opened) for session 1 on > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.543 0:12.303 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call > GetMediaFormats for > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > G.711-uLaw-64k > > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 OpalCon > OpenSourceMediaStream (already opened) for session 1 on > Call[1]-EP[Default] > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k > 2006/06/02 13:12:34.552 0:12.312 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k > 2006/06/02 13:12:34.553 0:12.313 Media Patch:8175708 Patch > Thread started for Patch OpalAudioMediaStream-Source-PCM-16 -> > OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:34.556 0:12.316 SIP Handler:8520268 Media > Starting thread Media Patch:8175708 > 2006/06/02 13:12:34.557 0:12.317 Media Patch:8527348 Patch > Thread started for Patch OpalRTPMediaStream-Source-G.711-uLaw-64k -> > OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:34.568 0:12.329 Media Patch:8527348 RTP > Jitter buffer created: size=101 delay=160-4000/160 (20ms) obj=0x8526b30 > 2006/06/02 13:12:34.572 0:12.333 RTP Jitter:8526b30 RTP > Jitter RTP receive thread started: 0x8526b30 > 2006/06/02 13:12:34.574 0:12.334 RTP Jitter:8526b30 RTP > First receive data: ver=2 pt=GSM psz=33 m=0 x=0 seq=39915 ts=160 > src=824302623 ccnt=0 > 2006/06/02 13:12:34.580 0:12.341 SIP Handler:8520268 Media > Starting thread Media Patch:8527348 > 2006/06/02 13:12:34.581 0:12.341 SIP Handler:8520268 OpalCon > Media stream threads started. > 2006/06/02 13:12:34.582 0:12.342 SIP Handler:8520268 OpalCon > Media stream threads started. > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP > Found existing session 2 > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 > GMManager Will establish the connection > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 OpalMan > OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.607 0:12.367 SIP Handler:8520268 Call > OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.610 0:12.371 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:34.648 0:12.408 Media Patch:8527348 RTP > Jitter buffer length exceeded > 2006/06/02 13:12:34.649 0:12.409 Media Patch:8527348 RTP > Jitter buffer length exceed was prior to first write. Not increasing > buffer size > 2006/06/02 13:12:35.277 0:13.037 Media Patch:8175708 RTP > First sent data: ver=2 pt=PCMU psz=160 m=1 x=0 seq=1460 ts=0 > src=703395120 ccnt=0 > 2006/06/02 13:12:35.608 0:13.368 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:35.609 0:13.369 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:36.137 0:13.898 RTP Jitter:8526b30 RTP > Receive statistics: packets=101 octets=3714 lost=0 tooLate=0 order=0 > avgTime=15 maxTime=1556 minTime=0 jitter=16 maxJitter=188 > 2006/06/02 13:12:36.573 0:14.333 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (9760) > 2006/06/02 13:12:36.614 0:14.374 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:36.615 0:14.375 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:36.974 0:14.734 RTP Jitter:8526b30 RTP > Jitter buffer continuously full, throwing away entire buffer. > 2006/06/02 13:12:36.995 0:14.756 RTP Jitter:8526b30 RTP > Jitter buffer full, threw away 21 oldest frames > 2006/06/02 13:12:37.374 0:15.134 RTP Jitter:8526b30 RTP > Receive statistics: packets=201 octets=19714 lost=0 tooLate=0 order=0 > avgTime=12 maxTime=23 minTime=0 jitter=0 maxJitter=188 > 2006/06/02 13:12:37.620 0:15.380 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:37.621 0:15.381 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:37.820 0:15.580 Media Patch:8175708 RTP > Transmit statistics: packets=101 octets=16160 avgTime=25 maxTime=48 > minTime=23 > 2006/06/02 13:12:38.624 0:16.384 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:38.625 0:16.385 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:38.993 0:16.753 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (29120) > 2006/06/02 13:12:39.374 0:17.134 RTP Jitter:8526b30 RTP > Receive statistics: packets=301 octets=35714 lost=0 tooLate=0 order=0 > avgTime=20 maxTime=26 minTime=14 jitter=1 maxJitter=188 > 2006/06/02 13:12:39.395 0:17.155 RTP Jitter:8526b30 RTP > Jitter buffer continuously full, throwing away entire buffer. > 2006/06/02 13:12:39.415 0:17.176 RTP Jitter:8526b30 RTP > Jitter buffer full, threw away 21 oldest frames > 2006/06/02 13:12:39.632 0:17.392 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:39.633 0:17.393 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:40.384 0:18.144 Media Patch:8175708 RTP > Transmit statistics: packets=201 octets=32160 avgTime=25 maxTime=44 > minTime=22 > 2006/06/02 13:12:40.640 0:18.400 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:40.641 0:18.401 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:41.373 0:19.133 RTP Jitter:8526b30 RTP > Receive statistics: packets=401 octets=51714 lost=0 tooLate=0 order=0 > avgTime=19 maxTime=26 minTime=13 jitter=1 maxJitter=188 > 2006/06/02 13:12:41.413 0:19.173 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (48480) > 2006/06/02 13:12:41.648 0:19.424 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:41.665 0:19.425 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:41.813 0:19.573 RTP Jitter:8526b30 RTP > Jitter buffer continuously full, throwing away entire buffer. > 2006/06/02 13:12:41.833 0:19.593 RTP Jitter:8526b30 RTP > Jitter buffer full, threw away 21 oldest frames > 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:42.920 0:20.680 Media Patch:8175708 RTP > Transmit statistics: packets=301 octets=48160 avgTime=25 maxTime=49 > minTime=22 > 2006/06/02 13:12:43.378 0:21.139 RTP Jitter:8526b30 RTP > Receive statistics: packets=501 octets=67714 lost=0 tooLate=0 order=0 > avgTime=20 maxTime=27 minTime=12 jitter=1 maxJitter=188 > 2006/06/02 13:12:43.696 0:21.457 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:43.697 0:21.457 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot Call > Clearing Call[1] reason=EndedByLocalUser > 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot OpalCon > Releasing Call[1]-EP[Default] > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > Call end reason for Default set to EndedByLocalUser > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > SetPhase from EstablishedPhase to ReleasingPhase > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > Releasing Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > Call end reason for fa44075b-96f0-da11-8388-000ea6217592@nomade set to > EndedByLocalUser > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > SetPhase from EstablishedPhase to ReleasingPhase > 2006/06/02 13:12:43.820 0:21.581 OnRelease:856e8a0 OpalCon > OnReleased Call[1]-EP[Default] > 2006/06/02 13:12:43.822 0:21.583 OnRelease:856e8a0 Media > Closing raw media stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.824 0:21.584 OnRelease:856e8a0 Media > Closing stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.825 0:21.585 OnRelease:856e8a0 Media > Disconnecting OpalAudioMediaStream-Source-PCM-16 from patch thread Patch > OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.827 0:21.587 OnRelease:856e8a0 Patch > Closing media patch Patch OpalAudioMediaStream-Source-PCM-16 -> > OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.829 0:21.589 OnRelease:856e8a0 Media > Closing raw media stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.830 0:21.590 OnRelease:856e8a0 Media > Closing stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.831 0:21.591 OnRelease:84f8c00 SIP > OnReleased: > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade], phase = > ReleasingPhase > 2006/06/02 13:12:43.833 0:21.593 OnRelease:84f8c00 OpalCon > SetPhase from ReleasingPhase to ReleasingPhase > 2006/06/02 13:12:43.834 0:21.594 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (67840) > 2006/06/02 13:12:43.836 0:21.596 OnRelease:84f8c00 SIP > Transaction 4 BYE created. > 2006/06/02 13:12:43.842 0:21.603 OnRelease:84f8c00 Media > Closing RTP for OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.844 0:21.604 OnRelease:84f8c00 RTP_UDP > Session 1, Shutting down write. > 2006/06/02 13:12:43.845 0:21.605 OnRelease:84f8c00 Media > Closing stream OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.846 0:21.606 OnRelease:84f8c00 Media > Disconnecting OpalRTPMediaStream-Sink-G.711-uLaw-64k from patch thread > Patch OpalAudioMediaStream-Source-PCM-16 -> > OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.848 0:21.609 OnRelease:84f8c00 Patch > Removing media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.855 0:21.626 OnRelease:84f8c00 Media > Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.867 0:21.627 OnRelease:84f8c00 RTP_UDP > Session 1, Shutting down read. > 2006/06/02 13:12:43.868 0:21.628 OnRelease:84f8c00 Media > Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.869 0:21.630 OnRelease:84f8c00 Media > Disconnecting OpalRTPMediaStream-Source-G.711-uLaw-64k from patch thread > Patch OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.893 0:21.653 Media Patch:8175708 Patch > Thread ended for Patch OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.893 0:21.653 OnRelease:84f8c00 Patch > Closing media patch Patch OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.916 0:21.676 RTP Jitter:8526b30 RTP_UDP > Session 1, Read shutdown. > 2006/06/02 13:12:43.917 0:21.677 RTP Jitter:8526b30 RTP > Jitter RTP receive thread ended > 2006/06/02 13:12:43.917 0:21.677 OnRelease:84f8c00 Media > Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.918 0:21.678 OnRelease:84f8c00 RTP_UDP > Session 1, Shutting down read. > 2006/06/02 13:12:43.919 0:21.679 OnRelease:84f8c00 Media > Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.922 0:21.683 OnRelease:856e8a0 Patch > Waiting for media patch thread to stop Patch > OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.926 0:21.686 OnRelease:856e8a0 Patch > Media patch thread Patch OpalAudioMediaStream-Source-PCM-16 destroyed. > 2006/06/02 13:12:43.930 0:21.691 OnRelease:856e8a0 Media > Closing raw media stream OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:43.932 0:21.693 OnRelease:856e8a0 Media > Closing stream OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:43.933 0:21.694 OnRelease:856e8a0 Media > Disconnecting OpalAudioMediaStream-Sink-PCM-16 from patch thread Patch > OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.956 0:21.717 OnRelease:856e8a0 Patch > Removing media stream sink OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:45.696 0:23.456 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:45.697 0:23.457 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:48.708 0:26.468 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:48.709 0:26.469 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:50.712 0:28.473 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:50.713 0:28.473 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:51.716 0:29.477 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:51.717 0:29.477 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:52.716 0:30.477 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:52.717 0:30.477 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:57.733 0:35.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:57.734 0:35.494 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:02.777 0:40.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:02.778 0:40.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:04.369 0:42.129 Housekeeper SIP Set > state Terminated_Success for transaction 1 INVITE > 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:05.777 0:43.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:05.777 0:43.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:06.613 0:44.374 Housekeeper SIP Set > state Terminated_Success for transaction 2 INVITE > 2006/06/02 13:13:06.777 0:44.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:06.778 0:44.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:07.777 0:45.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:07.778 0:45.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP > Found existing session 2 > Processus arrêté > -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From devel@tootai.net Sat Jun 3 19:25:05 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EBBDB3B06DD for ; Sat, 3 Jun 2006 19:24:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02787-06 for ; Sat, 3 Jun 2006 19:24:40 -0400 (EDT) Received: from mail1.tootai.net (ns1.tootai.net [82.231.69.24]) by menubar.gnome.org (Postfix) with ESMTP id 16D123B0756 for ; Sat, 3 Jun 2006 19:24:35 -0400 (EDT) Received: from [192.168.0.17] (unknown [192.168.0.17]) by mail1.tootai.net (Postfix) with ESMTP id 9C142398B99 for ; Sun, 4 Jun 2006 01:24:35 +0200 (CEST) Message-ID: <44821A19.10001@tootai.net> Date: Sun, 04 Jun 2006 01:24:09 +0200 From: Daniel Huhardeaux Organization: TOOTAi User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 References: <4481A6AF.2060703@tootai.net> <1149357648.2414.34.camel@golgoth01> In-Reply-To: <1149357648.2414.34.camel@golgoth01> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[AWL=0.000, BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 23:25:05 -0000 Damien Sandras wrote: > [...] >> When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is >> started, connection is showed with PCMU (why not GSM?), see the traffic >> in/out (~6 kB) but have no audio. >> >> > > Asterisk answers with 200 OK indicating that the call should be done > with PCMU. > Ok, but as GSM has my preference in Ekiga as well as in asterisk, the call should be done in GSM > [...] > > Please try with 2.0.2. Craig has done work in CVS and things are > potentially broken. If the problem persists once plugins support is in > CVS, please report again. > I use the Ekiga snapshot SID version which don't provide newest version as the one mentioned :-( Kilian? BTW, asterisk is 1.2-r16008 from 29/03/2006 - SVN stable. > > >> If I deactivate GSM codec, everything is fine. Below you will find a d4 >> output from the call. >> >> > > I do not think activating GSM or not has any influence. The problem is > probably something else. > I would like to believe you, but this problem happends only with GSM codec. -- Daniel From ebischoff@nerim.net Sun Jun 4 11:52:03 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C970B3B011B for ; Sun, 4 Jun 2006 11:52:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26992-10 for ; Sun, 4 Jun 2006 11:52:01 -0400 (EDT) Received: from mallaury.nerim.net (smtp-100-sunday.noc.nerim.net [62.4.17.100]) by menubar.gnome.org (Postfix) with ESMTP id 9601A3B00CE for ; Sun, 4 Jun 2006 11:52:01 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by mallaury.nerim.net (Postfix) with ESMTP id 32E474F399 for ; Sun, 4 Jun 2006 17:51:50 +0200 (CEST) From: =?iso-8859-1?q?=C9ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Sun, 4 Jun 2006 17:52:11 +0200 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606041752.12228.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.535 tagged_above=-999 required=2 tests=[AWL=0.064, BAYES_00=-2.599] X-Spam-Score: -2.535 X-Spam-Level: Subject: [GnomeMeeting-devel-list] KDE address book support in Ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 15:52:04 -0000 (this message has already been sent by mistake on gnomemeeting-list a few=20 hours ago, sorry for the crossposting) Hi everyone, A small notice to let you know that I am working on adding support for KDE= =20 Address Book (kab) to Ekiga. I already have some early "proof of concept"=20 code working (see screenshot at=20 http://opensource.bureau-cornavin.com/ekiga/screenshot.png). KDE Address Book is an application of its own, but it's also a library that= is=20 used by most KDE applications (KMail, Kontact, KPilot, Kopete, ...), and al= so=20 by third-party applications like OpenOffice.org. It can use several=20 "resources" for its addresses: local VCard files, remote LDAP servers, etc. Before anyone does the remark : YES it would be better if Evolution/GNOME a= nd=20 KDE shared the same address book library. But currently we have to live wit= h=20 this situation... There are two issues that currently slow me down a bit: 1) Ekiga's address book model distinguishes between "local" and "remote"=20 address books. This makes little sense for kab which can transparently use= =20 both local and remote resources. In a first time, my code will act as a=20 "local" address book, just like Evolution address book. 2) KDE address book currently has no field for SIP nor H323 addresses. I am= =20 currently trying to contact Will Stephenson (KDE) who added support for Sky= pe=20 addresses to see how we could do that cleanly. Of course, this functionality will remain optional and require no library f= or=20 those who can live without it :-). Any suggestion, wish, encouragement, criticism, and/or offer for help is=20 welcome. Hoping that helps, =2D-=20 =C9ric From jpuydt@free.fr Sun Jun 4 12:08:13 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C97F03B009F; Sun, 4 Jun 2006 12:08:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28175-05; Sun, 4 Jun 2006 12:08:00 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 880B03B0187; Sun, 4 Jun 2006 12:08:00 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-54-82-251-83-65.adsl.proxad.net [82.251.83.65]) by smtp5-g19.free.fr (Postfix) with ESMTP id 3EBD2250F8; Sun, 4 Jun 2006 18:07:59 +0200 (CEST) Message-ID: <44830581.8080503@free.fr> Date: Sun, 04 Jun 2006 18:08:33 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting mailing list , GnomeMeeting development mailing list References: <200606041116.31785.ebischoff@nerim.net> In-Reply-To: <200606041116.31785.ebischoff@nerim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: Cc: Subject: [GnomeMeeting-devel-list] Re: [GnomeMeeting-list] KDE address book support in Ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 16:08:14 -0000 Éric Bischoff a écrit : > A small notice to let you know that I am working on adding support for KDE > Address Book (kab) to Ekiga. I already have some early "proof of concept" > code working (see screenshot at > http://opensource.bureau-cornavin.com/ekiga/screenshot.png). I know :-) > KDE Address Book is an application of its own, but it's also a library that is > used by most KDE applications (KMail, Kontact, KPilot, Kopete, ...), and also > by third-party applications like OpenOffice.org. It can use several > "resources" for its addresses: local VCard files, remote LDAP servers, etc. Nice. > Before anyone does the remark : YES it would be better if Evolution/GNOME and > KDE shared the same address book library. But currently we have to live with > this situation... Indeed. > There are two issues that currently slow me down a bit: > > 1) Ekiga's address book model distinguishes between "local" and "remote" > address books. This makes little sense for kab which can transparently use > both local and remote resources. In a first time, my code will act as a > "local" address book, just like Evolution address book. I'm refactoring the addressbook ; and I don't like that distinction either. I'm still trying to convince Damien and Jan my ideas can fly. I think Jan is already beginning to see where I go ; Damien hasn't had the time to dive into it. > 2) KDE address book currently has no field for SIP nor H323 addresses. I am > currently trying to contact Will Stephenson (KDE) who added support for Skype > addresses to see how we could do that cleanly. Ok. > Of course, this functionality will remain optional and require no library for > those who can live without it :-). Ok too. We'll go with a --enable-kde at compile time. Then later on we'll see if it's possible to do something at runtime. > Any suggestion, wish, encouragement, criticism, and/or offer for help is > welcome. * Suggestion: use -devel-list ;-) * Wish: what you have written will work well with what I have in mind * Encouragement: I like the idea very much, and appreciate your working on ekiga * Criticism: couldn't you do that either long before or just after the re-architecturing? ;-) * Offer for help: uh... I'm refactoring, and it may help (the api I ask from "addressbooks" is much lighter). Snark on #ekiga From ebischoff@nerim.net Sun Jun 4 12:36:03 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6EBCD3B00E9 for ; Sun, 4 Jun 2006 12:36:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29967-09 for ; Sun, 4 Jun 2006 12:36:02 -0400 (EDT) Received: from kraid.nerim.net (smtp-100-sunday.nerim.net [62.4.16.100]) by menubar.gnome.org (Postfix) with ESMTP id 16E7B3B009F for ; Sun, 4 Jun 2006 12:36:01 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id C772E40E31 for ; Sun, 4 Jun 2006 18:35:59 +0200 (CEST) From: =?iso-8859-1?q?=C9ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Re: [GnomeMeeting-list] KDE address book support in Ekiga Date: Sun, 4 Jun 2006 18:36:11 +0200 User-Agent: KMail/1.8.2 References: <200606041116.31785.ebischoff@nerim.net> <44830581.8080503@free.fr> In-Reply-To: <44830581.8080503@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606041836.12390.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.553 tagged_above=-999 required=2 tests=[AWL=0.046, BAYES_00=-2.599] X-Spam-Score: -2.553 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 16:36:03 -0000 Le Dimanche 4 Juin 2006 18:08, Julien PUYDT a =E9crit=A0: > I know :-) I know you know ;-). > I'm refactoring the addressbook ; and I don't like that distinction > either. I'm still trying to convince Damien and Jan my ideas can fly. I > think Jan is already beginning to see where I go ; Damien hasn't had the > time to dive into it. Okay, I have not written much code yet, so there will be no problem to adap= t=20 it to your new layout, whatever it will be. > Ok too. We'll go with a --enable-kde at compile time. Then later on > we'll see if it's possible to do something at runtime. Yes, I was figuring out something like that. > * Suggestion: use -devel-list ;-) Yup, sorry... :-/ > * Wish: what you have written will work well with what I have in mind See above, I have not written much yet, and it's "obvious" code anyway, so= =20 there's no problem even if I have to restart from scratch. > * Encouragement: I like the idea very much, and appreciate your working > on ekiga Thank you for the warm welcome, Julien :-). > * Criticism: couldn't you do that either long before or just after the > re-architecturing? ;-) No. Did you hear about Murphy's law ? ;-) > * Offer for help: uh... I'm refactoring, and it may help (the api I ask > from "addressbooks" is much lighter). Indeed. =2D-=20 =C9ric From dsandras@seconix.com Mon Jun 5 15:24:19 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 115A33B038A for ; Mon, 5 Jun 2006 15:24:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24872-10 for ; Mon, 5 Jun 2006 15:24:15 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 482C73B0420 for ; Mon, 5 Jun 2006 15:24:15 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 73E6049870 for ; Mon, 5 Jun 2006 21:07:08 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23599-08 for ; Mon, 5 Jun 2006 21:06:52 +0200 (CEST) Received: from [192.168.0.161] (39.128-245-81.adsl-dyn.isp.belgacom.be [81.245.128.39]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 4C3C84986E for ; Mon, 5 Jun 2006 21:06:52 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44821A19.10001@tootai.net> References: <4481A6AF.2060703@tootai.net> <1149357648.2414.34.camel@golgoth01> <44821A19.10001@tootai.net> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 05 Jun 2006 21:24:50 +0200 Message-Id: <1149535490.2508.3.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.455 tagged_above=-999 required=2 tests=[AWL=0.009, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.455 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 19:24:19 -0000 Le dimanche 04 juin 2006 à 01:24 +0200, Daniel Huhardeaux a écrit : > Damien Sandras wrote: > > [...] > >> When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is > >> started, connection is showed with PCMU (why not GSM?), see the traffic > >> in/out (~6 kB) but have no audio. > >> > >> > > > > Asterisk answers with 200 OK indicating that the call should be done > > with PCMU. > > > Ok, but as GSM has my preference in Ekiga as well as in asterisk, the > call should be done in GSM I agree, but if you look at the 200 OK sent by Asterisk, GSM is not part of it, while it is part of the INVITE sent by Ekiga. > > I do not think activating GSM or not has any influence. The problem is > > probably something else. > > > I would like to believe you, but this problem happends only with GSM codec. Is there some way I could reproduce it here? -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Mon Jun 5 17:45:53 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 776D43B03A0; Mon, 5 Jun 2006 17:45:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02457-06; Mon, 5 Jun 2006 17:45:52 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 22F123B0295; Mon, 5 Jun 2006 17:45:52 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 8C0904984F; Mon, 5 Jun 2006 23:28:44 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29850-10; Mon, 5 Jun 2006 23:28:37 +0200 (CEST) Received: from [192.168.0.161] (39.128-245-81.adsl-dyn.isp.belgacom.be [81.245.128.39]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 089E44984C; Mon, 5 Jun 2006 23:28:36 +0200 (CEST) From: Damien Sandras To: gnomemeeting-list@gnome.org Content-Type: text/plain Date: Mon, 05 Jun 2006 23:46:32 +0200 Message-Id: <1149543992.2508.40.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.455 tagged_above=-999 required=2 tests=[AWL=0.009, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.455 X-Spam-Level: Cc: gnomemeeting-devel-list@gnome.org Subject: [GnomeMeeting-devel-list] Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 21:45:53 -0000 Hello to all, Ekiga 2.0.2 is available on http://www.ekiga.org More packages will be added as they are released. Thanks a lot to all supporters of the project! -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From simon@mungewell.org Mon Jun 5 18:20:27 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1BD3C3B0389 for ; Mon, 5 Jun 2006 18:20:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04790-06 for ; Mon, 5 Jun 2006 18:20:25 -0400 (EDT) Received: from pd3mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by menubar.gnome.org (Postfix) with ESMTP id 864BD3B04F7 for ; Mon, 5 Jun 2006 18:20:25 -0400 (EDT) Received: from pd3mr3so.prod.shaw.ca (pd3mr3so-qfe3.prod.shaw.ca [10.0.141.179]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0E00FK5RE0KD10@l-daemon> for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:20:24 -0600 (MDT) Received: from pn2ml4so.prod.shaw.ca ([10.0.121.148]) by pd3mr3so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0E002HJRE0FOB0@pd3mr3so.prod.shaw.ca> for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:20:24 -0600 (MDT) Received: from slone.mungewell.org ([68.146.98.7]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0E00GPGRE0XH60@l-daemon> for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:20:24 -0600 (MDT) Received: from simon by slone.mungewell.org with local (Exim 4.61) (envelope-from ) id 1FnNDw-0002Wd-6Y for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:07:00 -0600 Date: Mon, 05 Jun 2006 16:07:00 -0600 From: simon Subject: Re: [GnomeMeeting-devel-list] Ekiga 2.0.2 In-reply-to: <1149543992.2508.40.camel@golgoth01> To: GnomeMeeting development mailing list Message-id: <20060605220700.GA9699@mungewell.org> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline References: <1149543992.2508.40.camel@golgoth01> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[AWL=-0.000, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 22:20:27 -0000 On Mon, Jun 05, 2006 at 11:46:32PM +0200, Damien Sandras wrote: > Hello to all, > > > Ekiga 2.0.2 is available on http://www.ekiga.org > Woo Woo another release party! What only a '.' release - oh, guess we'll have to share a can of Pop ;-) Seriously though, Thanks to Damien and all the other developers. Simon From siti@orcon.net.nz Tue Jun 6 05:25:31 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5963D3B00EF for ; Tue, 6 Jun 2006 05:25:31 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29810-06 for ; Tue, 6 Jun 2006 05:25:29 -0400 (EDT) Received: from dbmail-mx2.orcon.net.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id AB0663B00E2 for ; Tue, 6 Jun 2006 05:25:28 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx2.orcon.net.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k569PFih007843 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Jun 2006 21:25:16 +1200 Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Stephen Cook To: Derek Smithies In-Reply-To: References: Content-Type: text/plain Date: Tue, 06 Jun 2006 21:25:24 +1200 Message-Id: <1149585924.16149.8.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx2.orcon.net.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.532 tagged_above=-999 required=2 tests=[AWL=0.068, BAYES_00=-2.599] X-Spam-Score: -2.532 X-Spam-Level: Cc: GnomeMeeting development mailing list X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 09:25:31 -0000 On Tue, 2006-06-06 at 10:32 +1200, Derek Smithies wrote: > Hi, > Ok, just back from a long weekend (three days of not touching a computer) > and back into things. > > Stephen, I saw some comment from you on this topic at: > > http://siti.geek.nz/web/content/blogsection/4/26/ > > interesting - very interesting.. > > hey - now that is a coincidence. > I studied at Canterbury University also. Well that's cool :) Could you send me a private email with an instant messaging address that you use. BTW Damien and others we will keep as much information on the mailing list. To give you guys an update I have IAX2 calls going in ekiga although it needs a lot of work :). Then obviously the improvements to IAX2 in opal... > > > ============== > > Craig, I do not think moving to an offline conversation with Stephen is > > a good idea. Julien and myself are supposed to mentor the project. Your > > help is of course welcome, but we have to be kept informed. > Sorry Damien, but there will be a lot of offline comment. > I suspect that Stephen and I live in the same city. Sending a CC of phone > conversations etc will not be easy. > > I will endeavour though to keep you informed of what is happening, and we > can move everything forward towards the nirvana of iax2, sip, and h323 in > gnomemeeting. > > > =========================== > > Stephen, > > I am really happy to work with you on IAX2 - really happy. This > would be great for the project. It should be a good learning experience for me and I am sure it'll be good fun :) From dsandras@seconix.com Tue Jun 6 05:29:32 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 40D9E3B0A68 for ; Tue, 6 Jun 2006 05:29:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30841-02 for ; Tue, 6 Jun 2006 05:29:30 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 9F34C3B0A5C for ; Tue, 6 Jun 2006 05:29:30 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id DDF8E493CB; Tue, 6 Jun 2006 11:12:16 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30209-02; Tue, 6 Jun 2006 11:11:57 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 679F9492DA; Tue, 6 Jun 2006 11:11:57 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: Stephen Cook In-Reply-To: <1149585924.16149.8.camel@siti> References: <1149585924.16149.8.camel@siti> Content-Type: text/plain; charset=ISO-8859-15 Date: Tue, 06 Jun 2006 11:29:17 +0200 Message-Id: <1149586157.2470.27.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Cc: Derek Smithies , GnomeMeeting development mailing list X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 09:29:32 -0000 Le mardi 06 juin 2006 à 21:25 +1200, Stephen Cook a écrit : > On Tue, 2006-06-06 at 10:32 +1200, Derek Smithies wrote: > > Hi, > > Ok, just back from a long weekend (three days of not touching a computer) > > and back into things. > > > > Stephen, I saw some comment from you on this topic at: > > > > http://siti.geek.nz/web/content/blogsection/4/26/ > > > > interesting - very interesting.. > > > > hey - now that is a coincidence. > > I studied at Canterbury University also. > Well that's cool :) > > Could you send me a private email with an instant messaging address that > you use. > > BTW Damien and others we will keep as much information on the mailing > list. > > To give you guys an update I have IAX2 calls going in ekiga although it > needs a lot of work :). Then obviously the improvements to IAX2 in > opal... > Excellent ;-) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From jpuydt@free.fr Tue Jun 6 06:41:15 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 18B6B3B00E0 for ; Tue, 6 Jun 2006 06:41:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10263-10 for ; Tue, 6 Jun 2006 06:41:14 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id BD54A3B00D2 for ; Tue, 6 Jun 2006 06:41:13 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-57-82-249-29-56.adsl.proxad.net [82.249.29.56]) by smtp1-g19.free.fr (Postfix) with ESMTP id 909369AAC7 for ; Tue, 6 Jun 2006 12:41:12 +0200 (CEST) Message-ID: <44855BEC.1040306@free.fr> Date: Tue, 06 Jun 2006 12:41:48 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga References: <1149585924.16149.8.camel@siti> In-Reply-To: <1149585924.16149.8.camel@siti> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.585 tagged_above=-999 required=2 tests=[AWL=0.014, BAYES_00=-2.599] X-Spam-Score: -2.585 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 10:41:15 -0000 Stephen Cook a écrit : > Could you send me a private email with an instant messaging address that > you use. > > BTW Damien and others we will keep as much information on the mailing > list. > > To give you guys an update I have IAX2 calls going in ekiga although it > needs a lot of work :). Then obviously the improvements to IAX2 in > opal... This sounds great :-) Do all codecs work ok ? Could you make a short list of what is lacking, so your progress can easily be seen ? :-) Snark From siti@orcon.net.nz Tue Jun 6 08:02:29 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0E2D93B008B for ; Tue, 6 Jun 2006 08:02:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19082-05 for ; Tue, 6 Jun 2006 08:02:18 -0400 (EDT) Received: from dbmail-mx3.orcon.co.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 7C3DD3B0A9D for ; Tue, 6 Jun 2006 08:01:24 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx3.orcon.co.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k56C17Ej021180 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 7 Jun 2006 00:01:12 +1200 Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Stephen Cook To: GnomeMeeting development mailing list In-Reply-To: <44855BEC.1040306@free.fr> References: <1149585924.16149.8.camel@siti> <44855BEC.1040306@free.fr> Content-Type: text/plain; charset=utf-8 Date: Wed, 07 Jun 2006 00:01:17 +1200 Message-Id: <1149595277.17468.7.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx3.orcon.co.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.495 tagged_above=-999 required=2 tests=[AWL=-0.031, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.495 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 12:02:29 -0000 On Tue, 2006-06-06 at 12:41 +0200, Julien PUYDT wrote: > Stephen Cook a écrit : > > Could you send me a private email with an instant messaging address that > > you use. > > > > BTW Damien and others we will keep as much information on the mailing > > list. > > > > To give you guys an update I have IAX2 calls going in ekiga although it > > needs a lot of work :). Then obviously the improvements to IAX2 in > > opal... > > This sounds great :-) > > Do all codecs work ok ? I have only tried ULAW > > Could you make a short list of what is lacking, so your progress can > easily be seen ? In Ekiga: * Url handler for IAX2 * If I have time in the future -- Refactor protocol components in ekiga In Iax2: * Call Hold * Transfer Calls * Register > > :-) > > Snark > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list From jan.schampera@web.de Tue Jun 6 11:41:54 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 300F43B00A7 for ; Tue, 6 Jun 2006 11:41:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01645-10 for ; Tue, 6 Jun 2006 11:41:52 -0400 (EDT) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by menubar.gnome.org (Postfix) with ESMTP id 5016E3B0117 for ; Tue, 6 Jun 2006 11:41:52 -0400 (EDT) Received: from fwd28.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1Fndgj-000497-06; Tue, 06 Jun 2006 17:41:49 +0200 Received: from mail.home.thebonsai.de (SxWWnGZHgenZylg6UcgKDR7M2nKdws-wslY10mn82PtIepb06FcVZ4@[84.147.103.162]) by fwd28.sul.t-online.de with esmtp id 1Fndgc-1VKS9o0; Tue, 6 Jun 2006 17:41:42 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id B18576B0FF for ; Tue, 6 Jun 2006 17:41:40 +0200 (CEST) Date: Tue, 6 Jun 2006 17:37:41 +0200 From: Jan Schampera To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga Message-ID: <20060606173741.7739fbf0@localhost.localdomain> In-Reply-To: <1149595277.17468.7.camel@siti> References: <1149585924.16149.8.camel@siti> <44855BEC.1040306@free.fr> <1149595277.17468.7.camel@siti> Organization: private X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: SxWWnGZHgenZylg6UcgKDR7M2nKdws-wslY10mn82PtIepb06FcVZ4@t-dialin.net X-TOI-MSGID: d621850d-8c24-4c96-bc80-424b3278e7ee X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.966 tagged_above=-999 required=2 tests=[AWL=0.632, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.966 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 15:41:54 -0000 On Wed, 07 Jun 2006 00:01:17 +1200 Stephen Cook wrote: > In Ekiga: > * Url handler for IAX2 > * If I have time in the future -- Refactor protocol components in > ekiga > > In Iax2: > * Call Hold > * Transfer Calls > * Register I X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C93A63B023C for ; Tue, 6 Jun 2006 18:32:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26160-07 for ; Tue, 6 Jun 2006 18:32:35 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by menubar.gnome.org (Postfix) with ESMTP id EE5BE3B0124 for ; Tue, 6 Jun 2006 18:32:34 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x31so57152pye for ; Tue, 06 Jun 2006 15:32:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=PWNZjwnHiPmpdYl2MsXZ9YZF9d4xYPXUg1ADy6s6gr7kpZpuMn+pMk4SiPqw6G91hexsOp1xDFUNDwMZyQ+X01mIY9TDqR0zrylP3BBJTKYCjcgQm4+vLCMe9AVXFuvgQ8NYOFrWwmRpr+zSS1OaVc2h2FssBRFPxlSabyu06bg= Received: by 10.35.76.9 with SMTP id d9mr79929pyl; Tue, 06 Jun 2006 15:32:33 -0700 (PDT) Received: by 10.35.9.3 with HTTP; Tue, 6 Jun 2006 15:32:33 -0700 (PDT) Message-ID: <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> Date: Tue, 6 Jun 2006 18:32:33 -0400 From: "mcquaid mcquaid" To: "GnomeMeeting development mailing list" Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode In-Reply-To: <1149246461.2966.28.camel@golgoth01> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7731_6834590.1149633153798" References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> <1149246461.2966.28.camel@golgoth01> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.041 tagged_above=-999 required=2 tests=[AWL=0.062, BAYES_00=-2.599, HTML_40_50=0.496, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.041 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 22:32:38 -0000 ------=_Part_7731_6834590.1149633153798 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Just a user, I'm curious as to why the trend of throwing opengl at everything. On one hand I think it's really cool, but this isn't like xgl where we want wobbly windows or something, just accelerated video. Isn't that what hardware video overlay is for? It takes a large burden off the cpu for video playback. Would benefit more people as some don't have prope= r opengl drivers. On 6/2/06, Damien Sandras wrote: > > Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit : > > So configure.in is hand-generated? Surprising. > > > > That's te way it works. You write configure.in and configure is > generated from there. I guess you are confusing things here. > > > 1) How exactly do I add the opengl ( libgl ) library? > > > > By writing autconf code in configure.in. No idea exactly how it should > be done. > > > 2) Xrandr is mentioned in the Makefile, but is not in configure.in. Ho= w > > exactly does it get put into the Makefile? > > > > Probably by an external library that we are using. > > > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I didn't wan= t > > to code against a moving target. > > > > Yes. It is even OK if you do not provide the configure.in code, but only > the OpenGL Ekiga code. > > > Thanks, > > > > -Dan > > > > Damien Sandras wrote: > > > > >Le mercredi 31 mai 2006 =E0 12:41 -0700, Dan Sandberg a =E9crit : > > > > > > > > >>I'd imagine it would work on win32, but don't know. > > >> > > >> > > >> > > > > > >Probably. > > > > > > > > > > > >>I'll work on the patches. > > >> > > >>Where's the right place to add required libraries like openGL? > > >> > > >> > > > > > >In configure.in. > > > > > > > > > > > >>configure.in seems to be autogenerated by something, but whatever it > is > > >>doesn't seem to be in the CVS snapshot... > > >> > > >> > > >> > > > > > >configure.in is in the CVS snapshot. > > > > > > > > > > > > > > >>Thanks, > > >> > > >>-Dan > > >> > > >>Julien PUYDT wrote: > > >> > > >> > > >> > > >>>Dan Sandberg a =E9crit : > > >>> > > >>> > > >>> > > >>>>How should we proceed? I could just send you an updated > gui/main.cpp > > >>>>file... > > >>>> > > >>>> > > >>>I'd like to see patches instead of full files, preferably independan= t > > >>>on each others. > > >>> > > >>>There's also the question of the portability of this : since you > > >>>mention SDL, I guess this will work great on win32 too ? > > >>> > > >>>Snark > > >>>_______________________________________________ > > >>>Gnomemeeting-devel-list mailing list > > >>>Gnomemeeting-devel-list@gnome.org > > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >>> > > >>> > > >>> > > >>_______________________________________________ > > >>Gnomemeeting-devel-list mailing list > > >>Gnomemeeting-devel-list@gnome.org > > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >> > > >> > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > -- > _ Damien Sandras > (o- > //\ Ekiga Softphone: http://www.ekiga.org/ > v_/_ FOSDEM 2006 : http://www.fosdem.org/ > SIP Phone : sip:dsandras@ekiga.net > sip:600000@ekiga.net > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > ------=_Part_7731_6834590.1149633153798 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Just a user, I'm curious as to why the trend of throwing opengl at everythi= ng.  On one hand I think it's really cool, but this isn't like xgl whe= re we want wobbly windows or something, just accelerated video.  Isn't= that what hardware video overlay is for?  It takes a large burden off= the cpu for video playback.  Would benefit more people as some don't = have proper opengl drivers.

On 6/2/06, Damien Sandras <dsand= ras@seconix.com> wrote:
Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit :
> = So configure.in is hand-generated? = ; Surprising.
>

That's te way it works. You write configure.in and configure is
generated from there. I guess you are = confusing things here.

> 1) How exactly do I add the opengl ( lib= gl ) library?
>

By writing autconf code in configure.in. No idea exactly how it should
be done.

> 2) = Xrandr is mentioned in the Makefile, but is not in configure.in.  How
> exactly does it get put in= to the Makefile?
>

Probably by an external library that we are using.

&= gt; 3) Is it ok if I send in a patch that is for Ekiga 2.0.1?  I = didn't want
> to code against a moving target.
>

Yes. It= is even OK if you do not provide the=20 configure.in code, but only
the Open= GL Ekiga code.

> Thanks,
>
> -Dan
>
> Dam= ien Sandras wrote:
>
> >Le mercredi 31 mai 2006 =E0 12:41 -0= 700, Dan Sandberg a =E9crit :
> >
> >
> >>I'd imagine it would work on win= 32, but don't know.
> >>
> >>
> >>
&= gt; >
> >Probably.
> >
> >
> >
> >>I'll work on the patches.
> >>
> >>Whe= re's the right place to add required libraries like openGL?
> >>= ;
> >>
> >
> >In configure.in.
> >
> >
> >
> >>configure.in seems to be autogenerated by= something, but whatever it is
> >>doesn't seem to be in the CV= S snapshot...
> >>
> >>
> >>
> >
> &g= t;configure.in is in the CVS snapshot.<= br>> >
> >
> >
> >
> >>Thanks,
> >>
> >>-Dan
> >>
> >>Jul= ien PUYDT wrote:
> >>
> >>
> >>
>= >>>Dan Sandberg a =E9crit :
> >>>
> >>= >
> >>>
> >>>>How should we proceed? &= nbsp;I could just send you an updated gui/main.cpp
> >>>>= file...
> >>>>
> >>>>
> >>&= gt;I'd like to see patches instead of full files, preferably independant
> >>>on each others.
> >>>
> >>&= gt;There's also the question of the portability of this : since you
>= >>>mention SDL, I guess this will work great on win32 too ?
> >>>
> >>>Snark
> >>>___________= ____________________________________
> >>>Gnomemeeting-devel= -list mailing list
> >>> Gnomemeeting-devel-list@gnome.org
> >>>http://mail.gnome= .org/mailman/listinfo/gnomemeeting-devel-list
> >>>
> >>>
> >>>
> >>____________________= ___________________________
> >>Gnomemeeting-devel-list mailing= list
> >> Gnomemeeting-devel-list@gnome.org
> >>http://mail.gnome.org= /mailman/listinfo/gnomemeeting-devel-list
> >>
> >= >
>
> _______________________________________________
> Gn= omemeeting-devel-list mailing list
> Gnomemeeting-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
-- _      Damien Sandras
(o-
//\ &n= bsp;   Ekiga Softphone: http://= www.ekiga.org/
v_/_    FOSDEM 2006  &n= bsp; : http://www.fosdem.org/
       &nb= sp;SIP Phone      : sip:dsandras@ekiga.net
    &nbs= p;            &= nbsp;       sip:600000@ekiga.net

____________________________________= ___________
Gnomemeeting-devel-list mailing list
Gnomemeeting-devel-list@gnome.org
http://mail.= gnome.org/mailman/listinfo/gnomemeeting-devel-list

------=_Part_7731_6834590.1149633153798-- From x@cs.stanford.edu Tue Jun 6 18:47:00 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5D25C3B036D for ; Tue, 6 Jun 2006 18:46:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26984-04 for ; Tue, 6 Jun 2006 18:46:56 -0400 (EDT) Received: from smtp104.plus.mail.mud.yahoo.com (smtp104.plus.mail.mud.yahoo.com [68.142.206.237]) by menubar.gnome.org (Postfix) with SMTP id 502483B0124 for ; Tue, 6 Jun 2006 18:46:56 -0400 (EDT) Received: (qmail 87952 invoked from network); 6 Jun 2006 22:46:55 -0000 Received: from unknown (HELO ?192.168.2.47?) (dan?sandberg@71.138.128.214 with plain) by smtp104.plus.mail.mud.yahoo.com with SMTP; 6 Jun 2006 22:46:54 -0000 Message-ID: <448605B0.6080504@cs.stanford.edu> Date: Tue, 06 Jun 2006 15:46:08 -0700 From: Dan Sandberg User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> <1149246461.2966.28.camel@golgoth01> <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> In-Reply-To: <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.808 tagged_above=-999 required=2 tests=[AWL=-0.593, BAYES_00=-2.599, SPF_SOFTFAIL=1.384] X-Spam-Score: -1.808 X-Spam-Level: Cc: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 22:47:00 -0000 I could be wrong, but I believe that video overlay moves the data direct from a capture card to the video card, bypassing the CPU. Since we're trying to display images that come from over the network, there's no way to bypass the CPU. And doing a nice looking resize from 176x144 to 640x480 is quite slow. Then you have to copy the whole 640x480 image to the display card, which is slow. With OpenGL you just copy the 176x144 image to the video card, and have it do the resize. Cheers, -Dan mcquaid mcquaid wrote: > Just a user, I'm curious as to why the trend of throwing opengl at > everything. On one hand I think it's really cool, but this isn't like > xgl where we want wobbly windows or something, just accelerated > video. Isn't that what hardware video overlay is for? It takes a > large burden off the cpu for video playback. Would benefit more > people as some don't have proper opengl drivers. > > On 6/2/06, *Damien Sandras* > wrote: > > Le vendredi 02 juin 2006 à 03:03 -0700, Dan Sandberg a écrit : > > So configure.in is > hand-generated? Surprising. > > > > That's te way it works. You write configure.in > and configure is > generated from there. I guess you are confusing things here. > > > 1) How exactly do I add the opengl ( libgl ) library? > > > > By writing autconf code in configure.in . No > idea exactly how it should > be done. > > > 2) Xrandr is mentioned in the Makefile, but is not in > configure.in . How > > exactly does it get put into the Makefile? > > > > Probably by an external library that we are using. > > > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I > didn't want > > to code against a moving target. > > > > Yes. It is even OK if you do not provide the configure.in > code, but only > the OpenGL Ekiga code. > > > Thanks, > > > > -Dan > > > > Damien Sandras wrote: > > > > >Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > > > > > > > > >>I'd imagine it would work on win32, but don't know. > > >> > > >> > > >> > > > > > >Probably. > > > > > > > > > > > >>I'll work on the patches. > > >> > > >>Where's the right place to add required libraries like openGL? > > >> > > >> > > > > > >In configure.in . > > > > > > > > > > > >>configure.in seems to be autogenerated > by something, but whatever it is > > >>doesn't seem to be in the CVS snapshot... > > >> > > >> > > >> > > > > > >configure.in is in the CVS snapshot. > > > > > > > > > > > > > > >>Thanks, > > >> > > >>-Dan > > >> > > >>Julien PUYDT wrote: > > >> > > >> > > >> > > >>>Dan Sandberg a écrit : > > >>> > > >>> > > >>> > > >>>>How should we proceed? I could just send you an updated > gui/main.cpp > > >>>>file... > > >>>> > > >>>> > > >>>I'd like to see patches instead of full files, preferably > independant > > >>>on each others. > > >>> > > >>>There's also the question of the portability of this : since you > > >>>mention SDL, I guess this will work great on win32 too ? > > >>> > > >>>Snark > > >>>_______________________________________________ > > >>>Gnomemeeting-devel-list mailing list > > >>> Gnomemeeting-devel-list@gnome.org > > > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >>> > > >>> > > >>> > > >>_______________________________________________ > > >>Gnomemeeting-devel-list mailing list > > >> Gnomemeeting-devel-list@gnome.org > > > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >> > > >> > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > -- > _ Damien Sandras > (o- > //\ Ekiga Softphone: http://www.ekiga.org/ > v_/_ FOSDEM 2006 : http://www.fosdem.org/ > SIP Phone : sip:dsandras@ekiga.net > > sip:600000@ekiga.net > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > From mcquaidster@gmail.com Tue Jun 6 19:15:44 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1CB1D3B0100 for ; Tue, 6 Jun 2006 19:15:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28543-05 for ; Tue, 6 Jun 2006 19:15:41 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id 15D153B033F for ; Tue, 6 Jun 2006 19:15:40 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x31so65185pye for ; Tue, 06 Jun 2006 16:15:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Mcduoi+u93PszObMtVWeXgYeQW4VI1eW7YkgZ+7d03TZ67OjKeE6aoo507wYkIOly9icd2mdZ2fuDTkH7FKrnfSoGo+jOXhxLaobIUCU6gQdxyXgRqVTPVs16J/2P3hFDJ8K1ELtr1xuKRWtdbXceWGlDpZn2R3lxDak1f6E47c= Received: by 10.35.40.10 with SMTP id s10mr72093pyj; Tue, 06 Jun 2006 16:15:39 -0700 (PDT) Received: by 10.35.9.3 with HTTP; Tue, 6 Jun 2006 16:15:39 -0700 (PDT) Message-ID: <58a398810606061615s6a801fected291a67dbb85214@mail.gmail.com> Date: Tue, 6 Jun 2006 19:15:39 -0400 From: "mcquaid mcquaid" To: "Dan Sandberg" Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode In-Reply-To: <448605B0.6080504@cs.stanford.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8108_3516387.1149635739799" References: <447CCA43.3@stdout.at> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> <1149246461.2966.28.camel@golgoth01> <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> <448605B0.6080504@cs.stanford.edu> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.242 tagged_above=-999 required=2 tests=[AWL=0.223, BAYES_00=-2.599, HTML_50_60=0.134, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.242 X-Spam-Level: Cc: GnomeMeeting development mailing list X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 23:15:44 -0000 ------=_Part_8108_3516387.1149635739799 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hmm, again I don't know much about this but I think what you describe can b= e handled by hardware video overlay. Just a quick googling has this about hardware video overlay at the zoomplayer's website: http://www.inmatrix.com/zplayer/highlights/vidrender.shtml *The Video Overlay:* > At around 1995, when MPEG1 (VCD) playback started to become popular on th= e > PC, the actual processing power of the PC was not quite strong enough to > play such content. The display card manufacturers at the time came up wit= h a > solution called "The Video Overlay". The Video Overlay is a special hardw= are > on the display card which is used to perform several video-display featur= es > in hardware (Stretching, Color-Space Conversion, etc...), thus allowing > smooth playback of video at no cost to the CPU. It does go on to say that video rendering via dx9 (and thus I assume opengl) provide better image quality and don't suffer from some multimonitor issues with video overlay. Afaik, only one display can have hardware overlay so that's what he's referring to there. But, for the most part, it sounds like hardware overlay would be a nice solution as well that just about everyone would benefit from as again, ther= e are still a lot of people without good opengl in linux but most probably functional hardware overlay. Maybe an option for both? On 6/6/06, Dan Sandberg wrote: > > I could be wrong, but I believe that video overlay moves the data direct > from a capture card to the video card, bypassing the CPU. Since we're > trying to display images that come from over the network, there's no way > to bypass the CPU. And doing a nice looking resize from 176x144 to > 640x480 is quite slow. Then you have to copy the whole 640x480 image to > the display card, which is slow. With OpenGL you just copy the 176x144 > image to the video card, and have it do the resize. > > Cheers, > > -Dan > > mcquaid mcquaid wrote: > > Just a user, I'm curious as to why the trend of throwing opengl at > > everything. On one hand I think it's really cool, but this isn't like > > xgl where we want wobbly windows or something, just accelerated > > video. Isn't that what hardware video overlay is for? It takes a > > large burden off the cpu for video playback. Would benefit more > > people as some don't have proper opengl drivers. > > > > On 6/2/06, *Damien Sandras* > > wrote: > > > > Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit : > > > So configure.in is > > hand-generated? Surprising. > > > > > > > That's te way it works. You write configure.in > > and configure is > > generated from there. I guess you are confusing things here. > > > > > 1) How exactly do I add the opengl ( libgl ) library? > > > > > > > By writing autconf code in configure.in . No > > idea exactly how it should > > be done. > > > > > 2) Xrandr is mentioned in the Makefile, but is not in > > configure.in . How > > > exactly does it get put into the Makefile? > > > > > > > Probably by an external library that we are using. > > > > > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I > > didn't want > > > to code against a moving target. > > > > > > > Yes. It is even OK if you do not provide the configure.in > > code, but only > > the OpenGL Ekiga code. > > > > > Thanks, > > > > > > -Dan > > > > > > Damien Sandras wrote: > > > > > > >Le mercredi 31 mai 2006 =E0 12:41 -0700, Dan Sandberg a =E9crit = : > > > > > > > > > > > >>I'd imagine it would work on win32, but don't know. > > > >> > > > >> > > > >> > > > > > > > >Probably. > > > > > > > > > > > > > > > >>I'll work on the patches. > > > >> > > > >>Where's the right place to add required libraries like openGL? > > > >> > > > >> > > > > > > > >In configure.in . > > > > > > > > > > > > > > > >>configure.in seems to be autogenerated > > by something, but whatever it is > > > >>doesn't seem to be in the CVS snapshot... > > > >> > > > >> > > > >> > > > > > > > >configure.in is in the CVS snapshot. > > > > > > > > > > > > > > > > > > > >>Thanks, > > > >> > > > >>-Dan > > > >> > > > >>Julien PUYDT wrote: > > > >> > > > >> > > > >> > > > >>>Dan Sandberg a =E9crit : > > > >>> > > > >>> > > > >>> > > > >>>>How should we proceed? I could just send you an updated > > gui/main.cpp > > > >>>>file... > > > >>>> > > > >>>> > > > >>>I'd like to see patches instead of full files, preferably > > independant > > > >>>on each others. > > > >>> > > > >>>There's also the question of the portability of this : since > you > > > >>>mention SDL, I guess this will work great on win32 too ? > > > >>> > > > >>>Snark > > > >>>_______________________________________________ > > > >>>Gnomemeeting-devel-list mailing list > > > >>> Gnomemeeting-devel-list@gnome.org > > > > > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > >>> > > > >>> > > > >>> > > > >>_______________________________________________ > > > >>Gnomemeeting-devel-list mailing list > > > >> Gnomemeeting-devel-list@gnome.org > > > > > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > >> > > > >> > > > > > > _______________________________________________ > > > Gnomemeeting-devel-list mailing list > > > Gnomemeeting-devel-list@gnome.org > > > > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > -- > > _ Damien Sandras > > (o- > > //\ Ekiga Softphone: http://www.ekiga.org/ > > v_/_ FOSDEM 2006 : http://www.fosdem.org/ > > SIP Phone : sip:dsandras@ekiga.net > > > > sip:600000@ekiga.net > > > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > ------=_Part_8108_3516387.1149635739799 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hmm, again I don't know much about this but I think what you describe can b= e handled by
hardware video overlay.

Just a quick googling has t= his about hardware video overlay at the zoomplayer's website:

http://www.inmatrix.com/zplayer/highlights/vidrender.shtml

The Video Overlay:
At around 1995, when MPEG1 (VCD) playback started to become popular on the = PC, the actual processing power of the PC was not quite strong enough to play such content. The display card manufacturers a= t the time came up with a solution called "The Video Overlay". The Video Overlay is a special hardware on = the display card which is used to perform several video-display features in hardware (Stretching, Color-Space Conversion, etc...), thus all= owing smooth playback of video at no cost to the CPU.


It does go on to say  that video rend= ering via dx9 (and thus I assume opengl)  provide better image quality= and don't suffer from some multimonitor issues with video overlay.
Afai= k, only one display can have hardware overlay so that's what he's referring= to there.

But, for the most part, it sounds like hardware overlay would be a = nice solution as well that just about everyone would benefit from as again,= there are still a lot of people without good opengl in linux but most prob= ably functional hardware overlay.

Maybe an option for both? 

On 6/6/06, Dan Sandberg <<= a href=3D"mailto:x@cs.stanford.edu">x@cs.stanford.edu> wrote:=
I could be wrong, but I believe that video overlay moves the data directfrom a capture card to the video card, bypassing the CPU.  Since= we're
trying to display images that come from over the network, there's= no way
to bypass the CPU.  And doing a nice looking resize from 176x= 144 to
640x480 is quite slow.  Then you have to copy the whole= 640x480 image to
the display card, which is slow.  With OpenG= L you just copy the 176x144
image to the video card, and have it do the resize.

Cheers,
<= br>-Dan

mcquaid mcquaid wrote:
> Just a user, I'm curious as t= o why the trend of throwing opengl at
> everything.  On one= hand I think it's really cool, but this isn't like
> xgl where we want wobbly windows or something, just accelerated> video.  Isn't that what hardware video overlay is for? = ; It takes a
> large burden off the cpu for video playback. = ; Would benefit more
> people as some don't have proper opengl drivers.
>
> On 6/= 2/06, *Damien Sandras* <dsandras= @seconix.com
> <mailto: dsandras@seconix.com>> wrote:
>
>   &n= bsp; Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit :
= >     > So config= ure.in < http://configure.in> is
>     hand-generat= ed?  Surprising.
>     >
>
= >     That's te way it works. You write configure.in
>     < http://configure.in> and configure is
>    = ; generated from there. I guess you are confusing things here.
>
&= gt;     > 1) How exactly do I add the opengl ( libgl= ) library?
>     >
>
>     By writing autconf code in configure.in <http:= //configure.in>. No
>     idea exactly how= it should
>     be done.
>
>     > 2) Xrandr is mentioned in the Makefile, b= ut is not in
>     configure.in <http://configure.in<= /a>>.  How
>     > exactly does i= t get put into the Makefile?
>     >
>
>   &nbs= p; Probably by an external library that we are using.
>
> =     > 3) Is it ok if I send in a patch that is for Ekiga = 2.0.1?  I
>     didn't want
>&nbs= p;    > to code against a moving target.
>     >
>
>   &nbs= p; Yes. It is even OK if you do not provide the configure.in
>     <http://configure.in> code, but only
>     the OpenGL Ekiga code.
>
> &n= bsp;   > Thanks,
>     >
>&= nbsp;    > -Dan
>     >
&= gt;     > Damien Sandras wrote:
>  &= nbsp;  >
>     > >Le mercredi 31 ma= i 2006 =E0 12:41 -0700, Dan Sandberg a =E9crit :
>     > >
>     = > >
>     > >>I'd imagine it would= work on win32, but don't know.
>     > >&g= t;
>     > >>
>   &= nbsp; > >>
>     > >
>     > >Probably.
>  &nbs= p;  > >
>     > >
> &= nbsp;   > >
>     > >>I'= ll work on the patches.
>     > >>
&g= t;     > >>Where's the right place to add requ= ired libraries like openGL?
>     > >>
>   &nb= sp; > >>
>     > >
> &n= bsp;   > >In configure.in <http://configure.in>.
>=      > >
>     > >
>     = > >
>     > >>configure.in <http://con= figure.in> seems to be autogenerated
>    = by something, but whatever it is
>     > >>doesn't seem to be in the CVS= snapshot...
>     > >>
> &nb= sp;   > >>
>     > >>=
>     > >
>     = > >configure.in <http://configure.in> is in = the CVS snapshot.
>     > >
> &n= bsp;   > >
>     > >
>= ;     > >
>     > &g= t;>Thanks,
>     > >>
>     > >>-Dan
>   = ;  > >>
>     > >>Julien P= UYDT wrote:
>     > >>
> &nbs= p;   > >>
>     > >><= br>>     > >>>Dan Sandberg a =E9crit :
>     > >>>
>   = ;  > >>>
>     > >>>=
>     > >>>>How should we proceed= ?  I could just send you an updated
>   &nbs= p; gui/main.cpp
>     > >>>>file..= .
>     > >>>>
>  &= nbsp;  > >>>>
>     > >= >>I'd like to see patches instead of full files, preferably
>&n= bsp;    independant
>     > >= ;>>on each others.
>     > >>>
>   = ;  > >>>There's also the question of the portability of th= is : since you
>     > >>>mention SDL= , I guess this will work great on win32 too ?
>   &nbs= p; > >>>
>     > >>>Snark
>  =    > >>>_____________________________________________= __
>     > >>>Gnomemeeting-devel-list= mailing list
>     > >>> Gnomemeeting-devel-list@gnome.org
>     <m= ailto:Gnomemeeting-dev= el-list@gnome.org>
>     > >>>= http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>&= nbsp;    > >>>
>     &= gt; >>>
>     > >>>
>&= nbsp;    > >>______________________________________= _________
>     > >>Gnomemeeting-devel-list maili= ng list
>     > >> Gnomemeeting-devel-list@gnome.org
&g= t;     <mailto: Gnomemeeting-devel-list@gnome.org>
>     &= gt; >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list<= /a>
>     > >>
>     > >>
>   &nb= sp; >
>     > _____________________________= __________________
>     > Gnomemeeting-devel-= list mailing list
>     > Gnomemeeting-devel-list@gnome.org
>     <m= ailto:Gnomemeeting-dev= el-list@gnome.org>
>     > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>&= nbsp;    --
>     _  &nb= sp;   Damien Sandras
>     (o-
= >     //\     Ekiga Softphone: <= a href=3D"http://www.ekiga.org/">http://www.ekiga.org/
>     v_/_    FOSDEM 200= 6    : http://www.fo= sdem.org/
>         =     SIP Phone      : sip:dsandras@ekiga.net
> =     <mailto: sip:dsandr= as@ekiga.net>
>        = ;            &n= bsp;         sip:600000@ekiga.net
>   &n= bsp; <mailto: sip:600000@ekiga.net>
>= ;
>     _________________________________________= ______
>     Gnomemeeting-devel-list mailing list=
>     Gnomemeeting-devel-list@gnome.org
>     <m= ailto:Gnomemeeting-dev= el-list@gnome.org>
>     http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>&= nbsp;    <http://mail.gnome.org/mailman/listinfo/gnomemee= ting-devel-list >
>
>
> ----------------------------------------------= --------------------------
>
> ________________________________= _______________
> Gnomemeeting-devel-list mailing list
> Gnomemeeting-devel-list@gnome.org
> http://mail.gnome.org/mailman= /listinfo/gnomemeeting-devel-list
>

------=_Part_8108_3516387.1149635739799-- From stefan@watri.org.au Wed Jun 7 00:39:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 26FE33B0B45 for ; Wed, 7 Jun 2006 00:39:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12142-08 for ; Wed, 7 Jun 2006 00:39:13 -0400 (EDT) Received: from asclepius.uwa.edu.au (asclepius.uwa.edu.au [130.95.128.56]) by menubar.gnome.org (Postfix) with ESMTP id 1153F3B022D for ; Wed, 7 Jun 2006 00:39:11 -0400 (EDT) Received: from asclepius.kas (localhost.localdomain [127.0.0.1]) by asclepius.uwa.edu.au (Postfix) with SMTP id 9EF11184629 for ; Wed, 7 Jun 2006 12:39:05 +0800 (WST) Received: from asclepius (localhost.localdomain [127.0.0.1]) by asclepius.prekas (Postfix) with SMTP id 7CB52188123 for ; Wed, 7 Jun 2006 12:39:05 +0800 (WST) X-UWA-Client-IP: 130.95.28.15 (UWA) Received: from ns1.watri.uwa.edu.au (ns1.watri.org.au [130.95.28.15]) by asclepius.extinput (Postfix) with ESMTP id 6CCE5188174 for ; Wed, 7 Jun 2006 12:39:05 +0800 (WST) Received: from gluttony (gluttony.watri.org.au [130.95.29.76]) by ns1.watri.uwa.edu.au (8.13.1/8.13.1) with ESMTP id k574d4dE023954 for ; Wed, 7 Jun 2006 12:39:04 +0800 (WST) Message-Id: <200606070439.k574d4dE023954@ns1.watri.uwa.edu.au> From: =?iso-8859-1?Q?Stefan_Br=FCns?= To: "'GnomeMeeting development mailing list'" Subject: RE: [GnomeMeeting-devel-list] Full Screen Mode Date: Wed, 7 Jun 2006 12:41:40 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <448605B0.6080504@cs.stanford.edu> Thread-Index: AcaJu2+MfoUGcqUFRii2sxvr70Y3NQALgJIg X-SpamTest-Info: Profile: Formal (387/060606) X-SpamTest-Info: Profile: Detect Hard [UCS 290904] X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking Spam - Subject (UCS) [02-08-04] X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.176 tagged_above=-999 required=2 tests=[AWL=-1.125, BAYES_40=-0.185, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] X-Spam-Score: -1.176 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 04:39:16 -0000 > -----Original Message----- > From: gnomemeeting-devel-list-bounces@gnome.org > [mailto:gnomemeeting-devel-list-bounces@gnome.org] On Behalf > Of Dan Sandberg > Sent: Wednesday, 7 June 2006 6:46 AM > To: GnomeMeeting development mailing list > Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode > > I could be wrong, but I believe that video overlay moves the > data direct > >from a capture card to the video card, bypassing the CPU. > Since we're > trying to display images that come from over the network, > there's no way > to bypass the CPU. And doing a nice looking resize from 176x144 to > 640x480 is quite slow. Then you have to copy the whole > 640x480 image to > the display card, which is slow. With OpenGL you just copy > the 176x144 > image to the video card, and have it do the resize. Just to clarify some things: Video overlay over XV support scaling in hardware, and colorspace transforms. Unfortunately, most graphic cards support only one overlay at a time. In case you only have a single video, this is fine, but as soon as you have multiple (local/remote, maybe conference anytime in the future), you have to do the compositing before uploading the image to the card. In case of Picture in Picture, this means that you a) Scale the to be small video down, compose it into the large one, and upload the composed image. Drawback: Also the small image may end up as large as an unscaled CIF image, it will have a lower resolution, due to the downscaling. or b) Scale the to be large image up, and compose the small image into it. Also the small image will have its full resolution (it may be a CIF (352x288) image on a 1024x768 or larger screen), the upscaling of the large image adds a lot of burden to the CPU and memory transfers. On the other hand, if you use OpenGL textures, you have all the benefits: - You can upload every video to a different texture, every video ends up on the screen with all the available resolution, all the scaling is done on the GPU (which is very efficient for this). - Most cards support YUV colorspaces for textures, so color transform can be done on the card. - As the different videos stream end up on different textures, you may have the local video with full 25fps framerate, and the remote with something like 10fps. - Superimposing any text (Chat, callers name, new incoming call ...) comes down to putting the text into just another texture. This may be easily alpha blended, with full screen resolution (if you superimpose text on the video directly, you can only use the videos resolution, and edges may look really strange due to the UV subsampling). - You may due almost arbitrary transforms on the video, without burdening the CPU (have a look at the Conference feature of iChat AV to see what I mean). Greetings, Stefan From t.schorpp@gmx.de Wed Jun 7 03:35:24 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 125143B0C5F for ; Wed, 7 Jun 2006 03:35:24 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23077-04 for ; Wed, 7 Jun 2006 03:35:22 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by menubar.gnome.org (Postfix) with SMTP id 544083B0368 for ; Wed, 7 Jun 2006 03:35:21 -0400 (EDT) Received: (qmail invoked by alias); 07 Jun 2006 07:35:19 -0000 Received: from p85.212.144.48.tisdip.tiscali.de (EHLO [192.168.1.100]) [85.212.144.48] by mail.gmx.net (mp029) with SMTP; 07 Jun 2006 09:35:19 +0200 X-Authenticated: #17142692 Message-ID: <448681B6.5000204@gmx.de> Date: Wed, 07 Jun 2006 09:35:18 +0200 From: thomas schorpp User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1 X-Accept-Language: de, en-us MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode References: <200606070439.k574d4dE023954@ns1.watri.uwa.edu.au> In-Reply-To: <200606070439.k574d4dE023954@ns1.watri.uwa.edu.au> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.476 tagged_above=-999 required=2 tests=[AWL=-0.011, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] X-Spam-Score: -2.476 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: t.schorpp@gmx.de, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 07:35:24 -0000 Stefan Brüns wrote: >>-----Original Message----- >>From: gnomemeeting-devel-list-bounces@gnome.org >>[mailto:gnomemeeting-devel-list-bounces@gnome.org] On Behalf >>Of Dan Sandberg >>Sent: Wednesday, 7 June 2006 6:46 AM >>To: GnomeMeeting development mailing list >>Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode >> >>I could be wrong, but I believe that video overlay moves the >>data direct >>>from a capture card to the video card, bypassing the CPU. >>Since we're >>trying to display images that come from over the network, >>there's no way >>to bypass the CPU. And doing a nice looking resize from 176x144 to >>640x480 is quite slow. Then you have to copy the whole >>640x480 image to >>the display card, which is slow. With OpenGL you just copy >>the 176x144 >>image to the video card, and have it do the resize. > > > Just to clarify some things: > > Video overlay over XV support scaling in hardware, and colorspace > transforms. are You sure? ive some display apps here which can switch between XV and "real overlay". kvdr, tvtime, xawtv... XV can use significant high cpu load in my experience here... > > Unfortunately, most graphic cards support only one overlay at a time. not sure about this, too. all the chips i had since ati mach64 supported at least 2 overlays at a time. kvdr supports even up to 4 overlays(?) on modern cards respectively. http://www.s.netic.de/gfiala/ > In > case you only have a single video, this is fine, but as soon as you have > multiple (local/remote, maybe conference anytime in the future), you have to > do the compositing before uploading the image to the card. In case of > Picture in Picture, this means that you > > a) Scale the to be small video down, compose it into the large one, and > upload the composed image. Drawback: Also the small image may end up as > large as an unscaled CIF image, it will have a lower resolution, due to the > downscaling. > > or > b) Scale the to be large image up, and compose the small image into it. Also > the small image will have its full resolution (it may be a CIF (352x288) > image on a 1024x768 or larger screen), the upscaling of the large image adds > a lot of burden to the CPU and memory transfers. > > On the other hand, if you use OpenGL textures, you have all the benefits: > - You can upload every video to a different texture, every video ends up on > the screen with all the available resolution, all the scaling is done on the > GPU (which is very efficient for this). > - Most cards support YUV colorspaces for textures, so color transform can be > done on the card. > - As the different videos stream end up on different textures, you may have > the local video with full 25fps framerate, and the remote with something > like 10fps. > - Superimposing any text (Chat, callers name, new incoming call ...) comes > down to putting the text into just another texture. This may be easily alpha > blended, with full screen resolution (if you superimpose text on the video > directly, you can only use the videos resolution, and edges may look really > strange due to the UV subsampling). > - You may due almost arbitrary transforms on the video, without burdening > the CPU (have a look at the Conference feature of iChat AV to see what I > mean). > > Greetings, > is there no standard "network video class" for the application layer somewhere? > Stefan tom From jpuydt@free.fr Wed Jun 7 07:50:57 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 57F3B3B030A for ; Wed, 7 Jun 2006 07:50:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08294-07 for ; Wed, 7 Jun 2006 07:50:54 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id 565043B03D0 for ; Wed, 7 Jun 2006 07:50:54 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp3-g19.free.fr (Postfix) with ESMTP id 26AE4498B4 for ; Wed, 7 Jun 2006 13:50:53 +0200 (CEST) Message-ID: <4486BDD0.9050805@free.fr> Date: Wed, 07 Jun 2006 13:51:44 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.845 tagged_above=-999 required=2 tests=[AWL=-0.735, BAYES_05=-1.11] X-Spam-Score: -1.845 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Refactoring of the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 11:50:57 -0000 Hi, after some discussions, it seems my initial ideas just don't fly. I don't consider them as a full failure, but they certainly are 80% so. I has in particular a long (private) discussion with Éric Bischoff, which allowed me to test my ideas on a newcomer. :-) Snark From jpuydt@free.fr Wed Jun 7 08:02:38 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A3A943B0CA0 for ; Wed, 7 Jun 2006 08:02:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09379-09 for ; Wed, 7 Jun 2006 08:02:30 -0400 (EDT) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by menubar.gnome.org (Postfix) with ESMTP id 0A6253B0CFE for ; Wed, 7 Jun 2006 08:01:42 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp2-g19.free.fr (Postfix) with ESMTP id 9A1E973329 for ; Wed, 7 Jun 2006 14:01:41 +0200 (CEST) Message-ID: <4486C05B.9080200@free.fr> Date: Wed, 07 Jun 2006 14:02:35 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> In-Reply-To: <4486BDD0.9050805@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:02:38 -0000 Julien PUYDT a écrit : > Notice that I forgot the conclusion : back to blackboard :-) Snark From pbrobinson@gmail.com Wed Jun 7 08:05:53 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D7E343B0C89 for ; Wed, 7 Jun 2006 08:05:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09667-03 for ; Wed, 7 Jun 2006 08:05:53 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by menubar.gnome.org (Postfix) with ESMTP id 33FD03B0C35 for ; Wed, 7 Jun 2006 08:05:52 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id q2so283058uge for ; Wed, 07 Jun 2006 05:05:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=G9St54usrU1EqN6hzRVdcsL0b9E6Bqxv3H4s4TGGxDEm0S9y4VTy4J2/S9c86GUzX86KIkPRd3gDHRfgFY6rCHfD2mYVgjzsw18dl0V8Ib8+WG4xy7/jO5pBwQEky1I69/GeIoNY6Q1nIE7TBp9rIFYmsHkPs+aO3lXDh5BJAzE= Received: by 10.67.89.5 with SMTP id r5mr423228ugl; Wed, 07 Jun 2006 05:05:51 -0700 (PDT) Received: by 10.67.25.6 with HTTP; Wed, 7 Jun 2006 05:05:51 -0700 (PDT) Message-ID: <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> Date: Wed, 7 Jun 2006 13:05:51 +0100 From: "Peter Robinson" To: "GnomeMeeting development mailing list" Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code In-Reply-To: <4486C05B.9080200@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4486BDD0.9050805@free.fr> <4486C05B.9080200@free.fr> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.56 tagged_above=-999 required=2 tests=[AWL=-0.518, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.56 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:05:54 -0000 > Julien PUYDT a =E9crit : > > > > Notice that I forgot the conclusion : back to blackboard :-) So are there any ideas running around that blackboard as of yet? Peter From jpuydt@free.fr Wed Jun 7 08:22:36 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CBE393B08CC for ; Wed, 7 Jun 2006 08:22:36 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10857-05 for ; Wed, 7 Jun 2006 08:22:35 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 97D9B3B0CDC for ; Wed, 7 Jun 2006 08:22:35 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp5-g19.free.fr (Postfix) with ESMTP id 65742275AC for ; Wed, 7 Jun 2006 14:22:34 +0200 (CEST) Message-ID: <4486C53D.2080306@free.fr> Date: Wed, 07 Jun 2006 14:23:25 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> In-Reply-To: <4486BDD0.9050805@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:22:37 -0000 Ok, so let's see what the constraints are. 1) the already available addressbooks must fit in the new scheme ; 2) the future kde addressbooks must find their place easily ; 3) searching should be dead-easy ; 4) the future "live" contacts must find their place easily ; 5) the backend-frontend frontier should be clear enough to allow for easy DBUS exporting 6) Damien wants it fast. Yes, going back to the blackboard isn't the best way to achieve 6... Snark From jpuydt@free.fr Wed Jun 7 08:52:53 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 92FD63B03C4 for ; Wed, 7 Jun 2006 08:52:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12995-08 for ; Wed, 7 Jun 2006 08:52:50 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id D0F7E3B0C97 for ; Wed, 7 Jun 2006 08:52:49 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp3-g19.free.fr (Postfix) with ESMTP id AEAAC497A1 for ; Wed, 7 Jun 2006 14:52:48 +0200 (CEST) Message-ID: <4486CC54.9090206@free.fr> Date: Wed, 07 Jun 2006 14:53:40 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <4486C05B.9080200@free.fr> <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> In-Reply-To: <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:52:53 -0000 Peter Robinson a écrit : > So are there any ideas running around that blackboard as of yet? Plenty. Snark From ebischoff@nerim.net Wed Jun 7 09:43:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C57F03B03C1 for ; Wed, 7 Jun 2006 09:43:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17343-08 for ; Wed, 7 Jun 2006 09:43:14 -0400 (EDT) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by menubar.gnome.org (Postfix) with ESMTP id BB8E53B03F1 for ; Wed, 7 Jun 2006 09:43:13 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 09C7C40FD8 for ; Wed, 7 Jun 2006 15:43:11 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Wed, 7 Jun 2006 15:43:21 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <4486C53D.2080306@free.fr> In-Reply-To: <4486C53D.2080306@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606071543.22163.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.562 tagged_above=-999 required=2 tests=[AWL=0.037, BAYES_00=-2.599] X-Spam-Score: -2.562 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 13:43:16 -0000 Le Mercredi 7 Juin 2006 14:23, Julien PUYDT a =C3=A9crit=C2=A0: > Yes, going back to the blackboard isn't the best way to achieve 6... You don't go black to the blackboard with no experience ;-). In pecular, I have been proposing a framework for address book "drivers" li= ke: class EkigaAddressBook { public: virtual gchar *name() const =3D 0; virtual const EkigaContact *firstContact() =3D 0; virtual const EkigaContact *nextContact() =3D 0; }; class EkigaContact { public: virtual boolean hasName() const =3D 0; virtual gchar *name() const =3D 0; virtual boolean hasTelephone() const =3D 0; virtual gchar *telephone() const =3D 0; etc... }; class EkigaEvolutionAddressBook : public EkigaAddressBook { public: virtual gchar *name() const; virtual const EkigaContact *firstContact(); virtual const EkigaContact *nextContact(); }; class EkigaEvolutionContact : public EkigaContact { public: virtual boolean hasName() const; virtual gchar *name() const; virtual boolean hasTelephone() const; virtual gchar *telephone() const; etc... }; Comments and flames welcome. =2D-=20 =C3=89ric From jpuydt@free.fr Wed Jun 7 13:58:31 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6343F3B0BC1 for ; Wed, 7 Jun 2006 13:58:31 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02884-04 for ; Wed, 7 Jun 2006 13:58:23 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 55DA13B069F for ; Wed, 7 Jun 2006 13:58:19 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp1-g19.free.fr (Postfix) with ESMTP id E2BA8911A6 for ; Wed, 7 Jun 2006 19:58:17 +0200 (CEST) Message-ID: <4486F76C.7060301@free.fr> Date: Wed, 07 Jun 2006 17:57:32 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <4486C53D.2080306@free.fr> <200606071543.22163.ebischoff@nerim.net> In-Reply-To: <200606071543.22163.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 17:58:31 -0000 Éric Bischoff a écrit : > Le Mercredi 7 Juin 2006 14:23, Julien PUYDT a écrit : >> Yes, going back to the blackboard isn't the best way to achieve 6... > > You don't go black to the blackboard with no experience ;-). Of course no :-) > In pecular, I have been proposing a framework for address book "drivers" like: > > class EkigaAddressBook > { > public: > virtual gchar *name() const = 0; > virtual const EkigaContact *firstContact() = 0; > virtual const EkigaContact *nextContact() = 0; > }; I don't like your first/next idea. If I take an XMPP roster in ekiga, connect to the same account from another program, and add a contact there, the XMPP roster will do a roster push, which your api doesn't handle. A much better approach IMNSHO, when it comes to keeping track of a list of contacts, is the following pseudo-code api : - get the current list of contacts ; - notify/signal me when a new one appears. There are two ways to handle the removing of a contact from such a list: (i) either the book tells you the contact has been removed ; (ii) or the contact itself tells you so. Both can be handled by a notification/signal. My first tests used the second way to do so, but now I think the first is better : the signal tells you both the book and the contact. > class EkigaContact > { > public: > virtual boolean hasName() const = 0; > virtual gchar *name() const = 0; > > virtual boolean hasTelephone() const = 0; > virtual gchar *telephone() const = 0; > > etc... > }; Bad. :-) First, you don't handle the case where several telephone numbers are available. Then if you begin to put /everything/ in the *base* class, that will end badly. A base class should only have the most basic capabilities, not all of them. > Comments and flames welcome. As a last comment, I will repoint the two arguments I have to prefer a GObject solution to a C++ solution : 1) the GObject will nicely live and die in the glib mainloop, so we won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere ; 2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame /dev/null). Snark From jpuydt@free.fr Wed Jun 7 14:30:54 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6C9E83B0255 for ; Wed, 7 Jun 2006 14:30:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04954-09 for ; Wed, 7 Jun 2006 14:30:52 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 15D9C3B0135 for ; Wed, 7 Jun 2006 14:30:52 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp5-g19.free.fr (Postfix) with ESMTP id E116F2766C for ; Wed, 7 Jun 2006 20:30:50 +0200 (CEST) Message-ID: <44871B92.9090703@free.fr> Date: Wed, 07 Jun 2006 20:31:46 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <4486C05B.9080200@free.fr> <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> <4486CC54.9090206@free.fr> In-Reply-To: <4486CC54.9090206@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 18:30:54 -0000 Julien PUYDT a écrit : > Plenty. Ok, here are a few. First of all, Éric convinced me the "no common class for contacts" was bad. So the main organization should probably be the following : - at the upper level, there are sources of addressbooks (avahi, e-d-s, kab, call history, xmpp...) ; - those sources give access to addressbooks ; - those addressbooks contain contacts. Now the question is detailing what is done where :-) Snark From ebischoff@nerim.net Wed Jun 7 14:33:56 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E21DC3B027D for ; Wed, 7 Jun 2006 14:33:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05177-06 for ; Wed, 7 Jun 2006 14:33:54 -0400 (EDT) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by menubar.gnome.org (Postfix) with ESMTP id 360A33B0135 for ; Wed, 7 Jun 2006 14:33:53 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 7CB2240E26 for ; Wed, 7 Jun 2006 20:33:50 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Wed, 7 Jun 2006 20:33:52 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606071543.22163.ebischoff@nerim.net> <4486F76C.7060301@free.fr> In-Reply-To: <4486F76C.7060301@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606072033.54523.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.569 tagged_above=-999 required=2 tests=[AWL=0.030, BAYES_00=-2.599] X-Spam-Score: -2.569 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 18:33:56 -0000 Le Mercredi 7 Juin 2006 17:57, Julien PUYDT a =C3=A9crit=C2=A0: > A much better approach IMNSHO, when it comes to keeping track of a list > of contacts, is the following pseudo-code api : > - get the current list of contacts ; > - notify/signal me when a new one appears. I am not sure that the Evolution, LDAP or KAddressBook drivers will all be= =20 able to wake up when a new contact is created. The contact can be created=20 asynchronously by another user on another machine on some LDAP server far=20 away on a network that is broken half of the time, for example. So even the= =20 underlying Evolution / LDAP / KAddressBook libraries might not know. =46urthermore, keeping a list all contacts in memory can have a high cost i= n=20 memory usage. > There are two ways to handle the removing of a contact from such a list: > (i) either the book tells you the contact has been removed ; > (ii) or the contact itself tells you so. > Both can be handled by a notification/signal. My first tests used the > second way to do so, but now I think the first is better : the signal > tells you both the book and the contact. Is that such a problem if the driver loops over an older version of the lis= t? > First, you don't handle the case where several telephone numbers are > available. Yeah, yeah. That was just an example. > Then if you begin to put /everything/ in the *base* class, that will end > badly. A base class should only have the most basic capabilities, not > all of them. Well, most address books are expected to deliver names and telephone=20 numbers ,-). But if you don't want to code hooks that return NULL all the=20 time for properties that do not exist (which I can understand), there's an= =20 easy and clean variant: class EkigaContact { public: enum property { name, telephone, street, ... }; virtual bool hasProperty(property p) const =3D 0; gchar *value(property p) const =3D 0; }; So contact->value(street) returns the street address and if contact->hasProperty(street) is true. > As a last comment, I will repoint the two arguments I have to prefer a > GObject solution to a C++ solution : Well, that's the kind of debate that can typically end up in a religious=20 war ;-), but: 1) why reinvent the wheel? C++ has mechanisms for object programming, it's= =20 rather strange to reimplement them in C; 2) such choices tie Ekiga more deeply into GNOME libraries (okay, it's a GN= OME=20 project. But...) > 1) the GObject will nicely live and die in the glib mainloop, so we > won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere= ; > 2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga > more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame > /dev/null). GBUS is indeed a nice invention ;-). =2D-=20 =C3=89ric From jpuydt@free.fr Wed Jun 7 15:29:48 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 91CC53B027D for ; Wed, 7 Jun 2006 15:29:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08481-05 for ; Wed, 7 Jun 2006 15:29:45 -0400 (EDT) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by menubar.gnome.org (Postfix) with ESMTP id 54DB33B0546 for ; Wed, 7 Jun 2006 15:29:45 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp2-g19.free.fr (Postfix) with ESMTP id 2EC0A6FECE for ; Wed, 7 Jun 2006 21:29:44 +0200 (CEST) Message-ID: <4487295A.9060506@free.fr> Date: Wed, 07 Jun 2006 21:30:34 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606071543.22163.ebischoff@nerim.net> <4486F76C.7060301@free.fr> <200606072033.54523.ebischoff@nerim.net> In-Reply-To: <200606072033.54523.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 19:29:48 -0000 Éric Bischoff a écrit : > Le Mercredi 7 Juin 2006 17:57, Julien PUYDT a écrit : >> A much better approach IMNSHO, when it comes to keeping track of a list >> of contacts, is the following pseudo-code api : >> - get the current list of contacts ; >> - notify/signal me when a new one appears. > > I am not sure that the Evolution, LDAP or KAddressBook drivers will all be > able to wake up when a new contact is created. The contact can be created > asynchronously by another user on another machine on some LDAP server far > away on a network that is broken half of the time, for example. So even the > underlying Evolution / LDAP / KAddressBook libraries might not know. Well, for those what I propose still works : - they get a list of contacts (and emit the "contact-added" signal for each) ; - when they are refreshed, they remove all their contacts, and get the new list of contacts. And what I propose works also for XMPP rosters, which are dynamically updated. > Furthermore, keeping a list all contacts in memory can have a high cost in > memory usage. Indeed, some books shouldn't treat "get the list of contacts" litterally. That is why they shouldn't be too stupid :-) >> There are two ways to handle the removing of a contact from such a list: >> (i) either the book tells you the contact has been removed ; >> (ii) or the contact itself tells you so. >> Both can be handled by a notification/signal. My first tests used the >> second way to do so, but now I think the first is better : the signal >> tells you both the book and the contact. > > Is that such a problem if the driver loops over an older version of the list? To do what ? It is not a problem if the list of users on ekiga.net isn't updated live. But it certainly is if your XMPP roster isn't ! >> First, you don't handle the case where several telephone numbers are >> available. > > Yeah, yeah. That was just an example. :-) >> Then if you begin to put /everything/ in the *base* class, that will end >> badly. A base class should only have the most basic capabilities, not >> all of them. > > Well, most address books are expected to deliver names and telephone > numbers ,-). But if you don't want to code hooks that return NULL all the > time for properties that do not exist (which I can understand), there's an > easy and clean variant: > class EkigaContact > { > public: > enum property { name, telephone, street, ... }; > > virtual bool hasProperty(property p) const = 0; > gchar *value(property p) const = 0; > }; Eh... this looks like GObject properties! >> As a last comment, I will repoint the two arguments I have to prefer a >> GObject solution to a C++ solution : > > Well, that's the kind of debate that can typically end up in a religious > war ;-), but: > 1) why reinvent the wheel? C++ has mechanisms for object programming, it's > rather strange to reimplement them in C; > 2) such choices tie Ekiga more deeply into GNOME libraries (okay, it's a GNOME > project. But...) glib/gobject isn't gnome. It isn't even graphical. >> 1) the GObject will nicely live and die in the glib mainloop, so we >> won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere ; >> 2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga >> more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame >> /dev/null). > > GBUS is indeed a nice invention ;-). DBUS, not GBUS. Snark From ebischoff@nerim.net Wed Jun 7 17:05:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 354B63B00A5 for ; Wed, 7 Jun 2006 17:05:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14677-05 for ; Wed, 7 Jun 2006 17:05:13 -0400 (EDT) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by menubar.gnome.org (Postfix) with ESMTP id CB5F43B0135 for ; Wed, 7 Jun 2006 17:05:12 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 1E15A437B0 for ; Wed, 7 Jun 2006 22:52:51 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Wed, 7 Jun 2006 22:53:00 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606072033.54523.ebischoff@nerim.net> <4487295A.9060506@free.fr> In-Reply-To: <4487295A.9060506@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606072253.01820.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.573 tagged_above=-999 required=2 tests=[AWL=0.026, BAYES_00=-2.599] X-Spam-Score: -2.573 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 21:05:17 -0000 Le Mercredi 7 Juin 2006 21:30, Julien PUYDT a =C3=A9crit=C2=A0: > > I am not sure that the Evolution, LDAP or KAddressBook drivers will all > > be able to wake up when a new contact is created. The contact can be > > created asynchronously by another user on another machine on some LDAP > > server far away on a network that is broken half of the time, for > > example. So even the underlying Evolution / LDAP / KAddressBook librari= es > > might not know. > > Well, for those what I propose still works : > - they get a list of contacts (and emit the "contact-added" signal for > each) ; > - when they are refreshed, they remove all their contacts, and get the > new list of contacts. What makes you think that they get "refreshed" at some point? > And what I propose works also for XMPP rosters, which are dynamically > updated. Promise, I will look someday what a "XMPP roster" is ;-). > > Furthermore, keeping a list all contacts in memory can have a high cost > > in memory usage. > > Indeed, some books shouldn't treat "get the list of contacts" > litterally. That is why they shouldn't be too stupid :-) Then you must some kind of evolved caching mechanism in your driver. That's= =20 sounds overcomplicated and hard to code to me. If you simply loop through t= he=20 contacts, you can just get the information you need and display it. > > Is that such a problem if the driver loops over an older version of the > > list? > > To do what ? It is not a problem if the list of users on ekiga.net isn't > updated live. But it certainly is if your XMPP roster isn't ! If you convinced me of one thing, it's that I need to look at the definitio= n=20 of these SNMP toasters ;-). > > class EkigaContact > > { > > public: > > enum property { name, telephone, street, ... }; > > > > virtual bool hasProperty(property p) const =3D 0; > > gchar *value(property p) const =3D 0; > > }; > > Eh... this looks like GObject properties! Indeed! Excepted that you are just using the possibilities of the programmi= ng=20 language, not of some library. At this point, I must do some clarification: I am a newcomer to Ekiga and perfectly aware of the fact that I might ignor= e a=20 lot of things about the past and the possible future of this software. I am= a=20 complete ignorant of GNOME and its libraries. I do not know anything about= =20 the multithreading problems that Julien has to deal with. I am not here to= =20 slow down Julien, nor to get my views adopted. I will be more than happy to= =20 adapt my code to *any* API that Julien will bring up. And to shut my big=20 mouth up if anyone ask me to ;-). > glib/gobject isn't gnome. It isn't even graphical. Okay, to me who comes from the KDE world, it's the same thing, it starts wi= th=20 "g" ;-). > > GBUS is indeed a nice invention ;-). > > DBUS, not GBUS. Yes, sorry for the many typos... :-/ =2D-=20 =C3=89ric From jan.schampera@web.de Wed Jun 7 23:13:06 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7395E3B043B for ; Wed, 7 Jun 2006 23:13:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02368-03 for ; Wed, 7 Jun 2006 23:13:03 -0400 (EDT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by menubar.gnome.org (Postfix) with ESMTP id 6D4823B012E for ; Wed, 7 Jun 2006 23:13:03 -0400 (EDT) Received: from fwd35.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1FoAxC-0004rd-00; Thu, 08 Jun 2006 05:13:02 +0200 Received: from mail.home.thebonsai.de (Z2ab0kZBZewL1AHEQWezyBxMlAJSeayZbCOT8jbF9IKQFlf7QKn1Ul@[84.147.102.15]) by fwd35.sul.t-online.de with esmtp id 1FoAx4-1YpxqK0; Thu, 8 Jun 2006 05:12:54 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id 8DF136B173 for ; Thu, 8 Jun 2006 05:12:52 +0200 (CEST) Date: Thu, 8 Jun 2006 05:08:28 +0200 From: Jan Schampera To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Message-ID: <20060608050828.37d3ac08@localhost.localdomain> In-Reply-To: <200606072253.01820.ebischoff@nerim.net> References: <4486BDD0.9050805@free.fr> <200606072033.54523.ebischoff@nerim.net> <4487295A.9060506@free.fr> <200606072253.01820.ebischoff@nerim.net> Organization: private X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-ID: Z2ab0kZBZewL1AHEQWezyBxMlAJSeayZbCOT8jbF9IKQFlf7QKn1Ul@t-dialin.net X-TOI-MSGID: c2323eec-2b6b-468d-b9e5-6ee93ecdce82 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.971 tagged_above=-999 required=2 tests=[AWL=0.627, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.971 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 03:13:06 -0000 On Wed, 7 Jun 2006 22:53:00 +0200 =C3=89ric Bischoff wrote: > (GLib vs OOP) > Indeed! Excepted that you are just using the possibilities of the > programming language, not of some library. Please note, regardless all other arguments, that an own C++-object system will be totally independant of the used framework. In case we leave GTK and GLib some day, the OOP approach won't need any changes. The GObject approach would need either an equivalent in the new framework, or a rewrite to (finally) OOP. Beside that, I tend to say "a matter of taste". J. --=20 dreaming in digital living in realtime thinking in binary talking in IP WELCOME TO OUR WORLD From jpuydt@free.fr Thu Jun 8 04:39:27 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8DA623B05CC for ; Thu, 8 Jun 2006 04:39:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19858-03 for ; Thu, 8 Jun 2006 04:39:24 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id D38EA3B0E0F for ; Thu, 8 Jun 2006 04:39:23 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp6-g19.free.fr (Postfix) with ESMTP id A778922647 for ; Thu, 8 Jun 2006 10:39:22 +0200 (CEST) Message-ID: <4487E272.80605@free.fr> Date: Thu, 08 Jun 2006 10:40:18 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606072033.54523.ebischoff@nerim.net> <4487295A.9060506@free.fr> <200606072253.01820.ebischoff@nerim.net> In-Reply-To: <200606072253.01820.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 08:39:27 -0000 Éric Bischoff a écrit : > Le Mercredi 7 Juin 2006 21:30, Julien PUYDT a écrit : >>> I am not sure that the Evolution, LDAP or KAddressBook drivers will all >>> be able to wake up when a new contact is created. The contact can be >>> created asynchronously by another user on another machine on some LDAP >>> server far away on a network that is broken half of the time, for >>> example. So even the underlying Evolution / LDAP / KAddressBook libraries >>> might not know. >> Well, for those what I propose still works : >> - they get a list of contacts (and emit the "contact-added" signal for >> each) ; >> - when they are refreshed, they remove all their contacts, and get the >> new list of contacts. > > What makes you think that they get "refreshed" at some point? The user triggers the "refresh" action :-) >> And what I propose works also for XMPP rosters, which are dynamically >> updated. > > Promise, I will look someday what a "XMPP roster" is ;-). Perhaps you know what a "jabber roster" is? http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html >>> Furthermore, keeping a list all contacts in memory can have a high cost >>> in memory usage. >> Indeed, some books shouldn't treat "get the list of contacts" >> litterally. That is why they shouldn't be too stupid :-) > > Then you must some kind of evolved caching mechanism in your driver. That's > sounds overcomplicated and hard to code to me. If you simply loop through the > contacts, you can just get the information you need and display it. I don't think a trivial proxying counts as an "evolved caching mechanism" :-) >>> Is that such a problem if the driver loops over an older version of the >>> list? >> To do what ? It is not a problem if the list of users on ekiga.net isn't >> updated live. But it certainly is if your XMPP roster isn't ! > > If you convinced me of one thing, it's that I need to look at the definition > of these SNMP toasters ;-). Who's toast ? ;-) >>> class EkigaContact >>> { >>> public: >>> enum property { name, telephone, street, ... }; >>> >>> virtual bool hasProperty(property p) const = 0; >>> gchar *value(property p) const = 0; >>> }; >> Eh... this looks like GObject properties! > > Indeed! Excepted that you are just using the possibilities of the programming > language, not of some library. Can you add properties to the enum when inheriting ? > At this point, I must do some clarification: > > I am a newcomer to Ekiga and perfectly aware of the fact that I might ignore a > lot of things about the past and the possible future of this software. I am a > complete ignorant of GNOME and its libraries. I do not know anything about > the multithreading problems that Julien has to deal with. I am not here to > slow down Julien, nor to get my views adopted. I will be more than happy to > adapt my code to *any* API that Julien will bring up. And to shut my big > mouth up if anyone ask me to ;-). Yes, yes, no problem. I'm happy to have feedback :-) >> glib/gobject isn't gnome. It isn't even graphical. > > Okay, to me who comes from the KDE world, it's the same thing, it starts with > "g" ;-). glib, gobject & gtk+ already make ekiga run on win32. >>> GBUS is indeed a nice invention ;-). >> DBUS, not GBUS. > > Yes, sorry for the many typos... :-/ Eh... that one was pretty bad for someone who has something against g-letter words ;-) Snark From ebischoff@nerim.net Thu Jun 8 04:49:09 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DA33D3B013D for ; Thu, 8 Jun 2006 04:49:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20394-06 for ; Thu, 8 Jun 2006 04:49:08 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id 682F73B05A7 for ; Thu, 8 Jun 2006 04:49:07 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 6666B41095 for ; Thu, 8 Jun 2006 10:49:06 +0200 (CEST) From: =?iso-8859-15?q?=C9ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 10:49:15 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <20060608050828.37d3ac08@localhost.localdomain> In-Reply-To: <20060608050828.37d3ac08@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606081049.16046.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.577 tagged_above=-999 required=2 tests=[AWL=0.022, BAYES_00=-2.599] X-Spam-Score: -2.577 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 08:49:10 -0000 Le Jeudi 8 Juin 2006 05:08, Jan Schampera a =E9crit=A0: > > Indeed! Excepted that you are just using the possibilities of the > > programming language, not of some library. > > Please note, regardless all other arguments, that an own C++-object > system will be totally independant of the used framework. In case we > leave GTK and GLib some day, the OOP approach won't need any changes. > > The GObject approach would need either an equivalent in the new > framework, or a rewrite to (finally) OOP. Yes. That was precisely my point. > Beside that, I tend to say "a matter of taste". Yes. Sometimes programming has to do with aesthetics. Compare: =3D=3D=3D GObject way =3D=3D=3D struct _GmBook { GObject parent; }; struct _GmBookClass { GObjectClass parent; const gchar *(*get_name)(GmBook *self); }; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D with: =3D=3D=3D C++ way =3D=3D=3D class GmBook { public: virtual get_name() const; } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D My tastes tell me that second code, besides from being much shorter, has mo= re=20 "beauty" than the first one. But as you say, tastes are a very personal=20 thing. =2D-=20 =C9ric From jpuydt@free.fr Thu Jun 8 05:09:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C38A43B04E8 for ; Thu, 8 Jun 2006 05:09:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21821-03 for ; Thu, 8 Jun 2006 05:09:15 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 32ECF3B0505 for ; Thu, 8 Jun 2006 05:09:15 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp5-g19.free.fr (Postfix) with ESMTP id BD9EA275B9 for ; Thu, 8 Jun 2006 11:09:13 +0200 (CEST) Message-ID: <4487E971.8070602@free.fr> Date: Thu, 08 Jun 2006 11:10:09 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <20060608050828.37d3ac08@localhost.localdomain> <200606081049.16046.ebischoff@nerim.net> In-Reply-To: <200606081049.16046.ebischoff@nerim.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 09:09:16 -0000 Éric Bischoff a écrit : > Le Jeudi 8 Juin 2006 05:08, Jan Schampera a écrit : >>> Indeed! Excepted that you are just using the possibilities of the >>> programming language, not of some library. >> Please note, regardless all other arguments, that an own C++-object >> system will be totally independant of the used framework. In case we >> leave GTK and GLib some day, the OOP approach won't need any changes. >> >> The GObject approach would need either an equivalent in the new >> framework, or a rewrite to (finally) OOP. > > Yes. That was precisely my point. > >> Beside that, I tend to say "a matter of taste". > > Yes. Sometimes programming has to do with aesthetics. Compare: > > === GObject way === > struct _GmBook { > GObject parent; > }; > > struct _GmBookClass { > GObjectClass parent; > > const gchar *(*get_name)(GmBook *self); > }; > ================== > > with: > > === C++ way === > class GmBook { > public: > virtual get_name() const; > } > ================== > > My tastes tell me that second code, besides from being much shorter, has more > "beauty" than the first one. But as you say, tastes are a very personal > thing. My experience is that when it comes to export the object on DBUS, you're better off with a gobject than with a C++ object. One has some introspection, the other doesn't. I prefer working a little harder upfront, then have an easy life, than writing easy code then feel miserable :-) Snark From ebischoff@nerim.net Thu Jun 8 05:22:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C67273B0598 for ; Thu, 8 Jun 2006 05:22:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22528-04 for ; Thu, 8 Jun 2006 05:22:07 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id D66F33B0B13 for ; Thu, 8 Jun 2006 05:22:06 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 4966F40FBF for ; Thu, 8 Jun 2006 11:22:05 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 11:22:09 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <4487E272.80605@free.fr> In-Reply-To: <4487E272.80605@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606081122.11835.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.579 tagged_above=-999 required=2 tests=[AWL=0.020, BAYES_00=-2.599] X-Spam-Score: -2.579 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 09:22:11 -0000 Le Jeudi 8 Juin 2006 10:40, Julien PUYDT a =C3=A9crit=C2=A0: > > What makes you think that they get "refreshed" at some point? > > The user triggers the "refresh" action :-) Then you loop again through the address book contacts ;-). No need to keep = a=20 copy of the contacts for that. > > Promise, I will look someday what a "XMPP roster" is ;-). > > Perhaps you know what a "jabber roster" is? > http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html No, and this article does not contain the word "roster" :-(. > > Then you must some kind of evolved caching mechanism in your driver. > > That's sounds overcomplicated and hard to code to me. If you simply loop > > through the contacts, you can just get the information you need and > > display it. > > I don't think a trivial proxying counts as an "evolved caching > mechanism" :-) I told you in private that I had a very lazy concept of programming ;-). > Who's toast ? ;-) ;-). > Can you add properties to the enum when inheriting ? Yes: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D class Repas { public: enum plat { nouilles, riz, patates, pain }; virtual void mange(plat p) =3D 0; }; class BonRepas : public Repas { public: enum bonPlat { caviar =3D pain + 1, langouste, foiegras, saumon }; virtual void mange(plat p); }; void BonRepas::mange(plat p) { if ((bonPlat) p =3D=3D langouste) printf("Miam!\n"); } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D With anonymous enums you should even be able to get rid of the casts. But=20 named enums make the code clearer. > Yes, yes, no problem. I'm happy to have feedback :-) Thanks for your openess, Julien :-). > glib, gobject & gtk+ already make ekiga run on win32. I know. But I think it is always good to remove references to libraries if = you=20 do not really need them. > Eh... that one was pretty bad for someone who has something against > g-letter words ;-) I have nothing against, I am just ignorant ;-). =2D-=20 =C3=89ric From conrad_videokonferenz@gmx.de Thu Jun 8 06:04:43 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7A1F63B0CF2 for ; Thu, 8 Jun 2006 06:04:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24863-06 for ; Thu, 8 Jun 2006 06:04:41 -0400 (EDT) Received: from vz17136.evanzo-server.de (vz17136.evanzo-server.de [62.140.17.136]) by menubar.gnome.org (Postfix) with ESMTP id E081B3B05CC for ; Thu, 8 Jun 2006 06:04:40 -0400 (EDT) Received: from c133075.adsl.hansenet.de (c133075.adsl.hansenet.de [213.39.133.75]) (authenticated bits=0) by vz17136.evanzo-server.de (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id k58A4cTf030082 for ; Thu, 8 Jun 2006 12:04:39 +0200 From: Conrad Beckert To: gnomemeeting-devel-list@gnome.org Date: Thu, 8 Jun 2006 10:02:37 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606081002.37875.conrad_videokonferenz@gmx.de> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.106 tagged_above=-999 required=2 tests=[AWL=-1.138, BAYES_05=-1.11, SPF_FAIL=1.142] X-Spam-Score: -1.106 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 10:04:45 -0000 Hi, has anybody an idea where the Debian packages for Ekiga 2.0.2 (or the corresponding CVS versions) are? The last version I can install using apt-get a couple of days old (May 25 - or somethin) - at least this is a version with the nonfunctional German locale. (defaults to English) What's up? Conrad From jpuydt@free.fr Thu Jun 8 06:59:27 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 483C83B0ED8 for ; Thu, 8 Jun 2006 06:59:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27917-10 for ; Thu, 8 Jun 2006 06:59:15 -0400 (EDT) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by menubar.gnome.org (Postfix) with ESMTP id 1C5223B0630 for ; Thu, 8 Jun 2006 06:59:12 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp4-g19.free.fr (Postfix) with ESMTP id A681254974 for ; Thu, 8 Jun 2006 12:59:10 +0200 (CEST) Message-ID: <44880335.3060401@free.fr> Date: Thu, 08 Jun 2006 13:00:05 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <4487E272.80605@free.fr> <200606081122.11835.ebischoff@nerim.net> In-Reply-To: <200606081122.11835.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 10:59:27 -0000 Éric Bischoff a écrit : > Le Jeudi 8 Juin 2006 10:40, Julien PUYDT a écrit : >>> What makes you think that they get "refreshed" at some point? >> The user triggers the "refresh" action :-) > > Then you loop again through the address book contacts ;-). No need to keep a > copy of the contacts for that. You will need to keep a copy to show them to the user anyway. And notice that a same contact could be shown at several places through the user interface! >>> Promise, I will look someday what a "XMPP roster" is ;-). >> Perhaps you know what a "jabber roster" is? >> http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html > > No, and this article does not contain the word "roster" :-(. The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish them from 'live' contacts. The situation is that you may have jc@jabber.lat in your roster, with the information that the name is "Julius Caesar", and belongs to the groups "Politicians" and "Jokers". But when he connects from his pda, he will show up as jc@jabber.lat/pda, and will neither be able to do VoIP, nor receive XHTML messages. When he is home, he connects from his computer as jc@jabber.lat/home, and will be able to do both. Now he goes to work, from where he shows up as jc@jabber.lat/work, which can do XHTML messaging, but not VoIP. >> Yes, yes, no problem. I'm happy to have feedback :-) > > Thanks for your openess, Julien :-). No problem. More brains means better solutions :-) >> glib, gobject & gtk+ already make ekiga run on win32. > > I know. But I think it is always good to remove references to libraries if you > do not really need them. Well, glib is nice. The main problem KDE problem have with it is that it begins with a 'g' and is already used in GNOME. :-) Snark From ebischoff@nerim.net Thu Jun 8 09:37:50 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CE2BD3B03A6 for ; Thu, 8 Jun 2006 09:37:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08027-03 for ; Thu, 8 Jun 2006 09:37:49 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id 549EB3B0622 for ; Thu, 8 Jun 2006 09:37:48 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 1D58441027 for ; Thu, 8 Jun 2006 15:37:45 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 15:37:53 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606081122.11835.ebischoff@nerim.net> <44880335.3060401@free.fr> In-Reply-To: <44880335.3060401@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606081537.55137.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.504 tagged_above=-999 required=2 tests=[AWL=-0.059, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077] X-Spam-Score: -2.504 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 13:37:51 -0000 Le Jeudi 8 Juin 2006 13:00, Julien PUYDT a =C3=A9crit=C2=A0: > > Then you loop again through the address book contacts ;-). No need to > > keep a copy of the contacts for that. > > You will need to keep a copy to show them to the user anyway. Keeping contacts in memory is not the same at all as keeping an image of wh= at=20 Ekiga has to display of them. The GUI needs basically a list of strings to= =20 display, not the potentially complex data structure of an address book=20 contact. Having one of these complex structures in memory at a time is enough IMHO. Should it be only for performance reasons: when the user scrolls down the l= ist=20 by one contact, it is much quicker to retreive data from a prepared list of= =20 strings than from the contact itself. > And notice=20 > that a same contact could be shown at several places through the user > interface! Yes, and perharps displayed in different ways. > > No, and this article does not contain the word "roster" :-(. > > The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish > them from 'live' contacts. > > The situation is that you may have jc@jabber.lat in your roster, with > the information that the name is "Julius Caesar", and belongs to the > groups "Politicians" and "Jokers". But when he connects from his pda, he > will show up as jc@jabber.lat/pda, and will neither be able to do VoIP, > nor receive XHTML messages. When he is home, he connects from his > computer as jc@jabber.lat/home, and will be able to do both. Now he goes > to work, from where he shows up as jc@jabber.lat/work, which can do > XHTML messaging, but not VoIP. Aha. > > Thanks for your openess, Julien :-). > > No problem. More brains means better solutions :-) Yes, indeed. I hope my advice brings something constructive. As I told you = in=20 private, you keep it or throw it, it's your decision. > > I know. But I think it is always good to remove references to libraries > > if you do not really need them. > > Well, glib is nice. The main problem KDE problem have with it is that it > begins with a 'g' and is already used in GNOME. :-) Do not believe that. We are not religious people. For example, we are very= =20 happy sharing libxml with GNOME. Even though there is already a XML API in= =20 Qt! Just because libxml rocks... (oh yeah, there's no "g" in libxml... ;-) ) We already share libxml, desktop files, DocBook documentation, DBUS=20 communication, po translation memories, and many, many other things. Cool=20 apps like Ekiga can run in a KDE environment. Cool apps like ... errr...=20 KEuroCalc ;-) can run in a GNOME environment. And in fact I know that many= =20 people do that. In fact, the more we will be able to share with you, the happier we will be= =2E I=20 can ensure you that this has always been what we said, even during private= =20 discussions at KDE meetings. I do not know why we do not share glib. I have my ideas about that, but it'= s=20 just personal assumptions ;-). =2D-=20 =C3=89ric From jpuydt@free.fr Thu Jun 8 15:02:29 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6459F3B0F68 for ; Thu, 8 Jun 2006 15:02:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30195-09 for ; Thu, 8 Jun 2006 15:02:28 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id 1D6653B035A for ; Thu, 8 Jun 2006 15:02:28 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp6-g19.free.fr (Postfix) with ESMTP id A118022783 for ; Thu, 8 Jun 2006 21:02:23 +0200 (CEST) Message-ID: <4488747B.6080906@free.fr> Date: Thu, 08 Jun 2006 21:03:23 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606081122.11835.ebischoff@nerim.net> <44880335.3060401@free.fr> <200606081537.55137.ebischoff@nerim.net> In-Reply-To: <200606081537.55137.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.512 tagged_above=-999 required=2 tests=[AWL=-0.067, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077] X-Spam-Score: -2.512 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:02:29 -0000 Éric Bischoff a écrit : >> You will need to keep a copy to show them to the user anyway. > > Keeping contacts in memory is not the same at all as keeping an image of what > Ekiga has to display of them. The GUI needs basically a list of strings to > display, not the potentially complex data structure of an address book > contact. > > Having one of these complex structures in memory at a time is enough IMHO. Not at all. And it won't allow you to update informations like presence easily. > Should it be only for performance reasons: when the user scrolls down the list > by one contact, it is much quicker to retreive data from a prepared list of > strings than from the contact itself. The contact isn't that much more than strings... >> And notice >> that a same contact could be shown at several places through the user >> interface! > > Yes, and perharps displayed in different ways. Yes, that too. >>> No, and this article does not contain the word "roster" :-(. >> The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish >> them from 'live' contacts. >> >> The situation is that you may have jc@jabber.lat in your roster, with >> the information that the name is "Julius Caesar", and belongs to the >> groups "Politicians" and "Jokers". But when he connects from his pda, he >> will show up as jc@jabber.lat/pda, and will neither be able to do VoIP, >> nor receive XHTML messages. When he is home, he connects from his >> computer as jc@jabber.lat/home, and will be able to do both. Now he goes >> to work, from where he shows up as jc@jabber.lat/work, which can do >> XHTML messaging, but not VoIP. > > Aha. Yes, it's that bad :-/ >>> Thanks for your openess, Julien :-). >> No problem. More brains means better solutions :-) > > Yes, indeed. I hope my advice brings something constructive. As I told you in > private, you keep it or throw it, it's your decision. Last time you wrote that I ended throwing both your ideas and mines ;-) >>> I know. But I think it is always good to remove references to libraries >>> if you do not really need them. >> Well, glib is nice. The main problem KDE problem have with it is that it >> begins with a 'g' and is already used in GNOME. :-) > > Do not believe that. We are not religious people. For example, we are very > happy sharing libxml with GNOME. Even though there is already a XML API in > Qt! Just because libxml rocks... > > (oh yeah, there's no "g" in libxml... ;-) ) > > We already share libxml, desktop files, DocBook documentation, DBUS > communication, po translation memories, and many, many other things. Cool > apps like Ekiga can run in a KDE environment. Cool apps like ... errr... > KEuroCalc ;-) can run in a GNOME environment. And in fact I know that many > people do that. What is KEuroCalc ? > In fact, the more we will be able to share with you, the happier we will be. I > can ensure you that this has always been what we said, even during private > discussions at KDE meetings. This is why it's so important to have a good DBUS component. And this is made easier by using glib-object :-) > I do not know why we do not share glib. I have my ideas about that, but it's > just personal assumptions ;-). I can make a few guesses : 1) it does things that QT does ; 2) it does things that C++ STL does. Snark From ebischoff@nerim.net Thu Jun 8 15:38:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D9F313B054E for ; Thu, 8 Jun 2006 15:38:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32745-08 for ; Thu, 8 Jun 2006 15:38:37 -0400 (EDT) Received: from mallaury.nerim.net (smtp-104-thursday.noc.nerim.net [62.4.17.104]) by menubar.gnome.org (Postfix) with ESMTP id 3976E3B000E for ; Thu, 8 Jun 2006 15:38:35 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by mallaury.nerim.net (Postfix) with ESMTP id 1ED2F4F3A4 for ; Thu, 8 Jun 2006 21:38:22 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 21:38:46 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606081537.55137.ebischoff@nerim.net> <4488747B.6080906@free.fr> In-Reply-To: <4488747B.6080906@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606082138.46648.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.576 tagged_above=-999 required=2 tests=[AWL=0.023, BAYES_00=-2.599] X-Spam-Score: -2.576 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:38:40 -0000 Le Jeudi 8 Juin 2006 21:03, Julien PUYDT a =C3=A9crit=C2=A0: > > We already share libxml, desktop files, DocBook documentation, DBUS > > communication, po translation memories, and many, many other things. Co= ol > > apps like Ekiga can run in a KDE environment. Cool apps like ... errr... > > KEuroCalc ;-) can run in a GNOME environment. And in fact I know that > > many people do that. > > What is KEuroCalc ? Mentioning it was merely a joke: it's a small KDE app that I wrote. http://opensource.bureau-cornavin.com/keurocalc/ ;-) > > I do not know why we do not share glib. I have my ideas about that, but > > it's just personal assumptions ;-). > > I can make a few guesses : > 1) it does things that QT does ; > 2) it does things that C++ STL does. Exactly the same guesses as me ;-). It even does things that C++ _alone_ do= es. Best, =2D-=20 =C3=89ric From ph.l@libertysurf.fr Thu Jun 8 15:47:49 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9705F3B1039 for ; Thu, 8 Jun 2006 15:47:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00870-02 for ; Thu, 8 Jun 2006 15:47:38 -0400 (EDT) Received: from smtp4.mail.easynet.fr (smarthost169.mail.easynet.fr [212.180.1.169]) by menubar.gnome.org (Postfix) with ESMTP id 527163B1020 for ; Thu, 8 Jun 2006 15:47:35 -0400 (EDT) Received: from asi-236.asi256ip.easynet.fr ([212.180.39.236] helo=[145.111.24.1]) by smtp4.mail.easynet.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FoQUy-0004IP-Fg for gnomemeeting-devel-list@gnome.org; Thu, 08 Jun 2006 21:48:56 +0200 Message-ID: <44887ECE.9040902@libertysurf.fr> Date: Thu, 08 Jun 2006 21:47:26 +0200 From: Philippe Lefevre User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: gnomemeeting-devel-list@gnome.org References: <20060608160031.473BF3B0FB3@menubar.gnome.org> In-Reply-To: <20060608160031.473BF3B0FB3@menubar.gnome.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.436 tagged_above=-999 required=2 tests=[AWL=-0.853, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, TW_BX=0.077, TW_IB=0.077, TW_RW=0.077, TW_WX=0.077] X-Spam-Score: -1.436 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ekiga under windows X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ph.l@libertysurf.fr, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:47:49 -0000 Hello, Today I tried to install ekiga on my PC under XP and I never get anything to work :'( You'll find bellow what I did. I can do some other tests if it may in any help. PhiL My PC is running Windows XP SP1 1G memory. I installed GTK 2.0 (version 2.8.9.0) installed under C:\Program Files\Fichiers communs\GTK\2.0 and Ekiga (downloaded from CVS June 8, 2006) installed under C:\Program Files\Ekiga CYGWIN and MSYS are installed too with XP : nothing happen, no log (empty file even with -d 4 option) with MSYS : same issue $ echo $PATH .:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32: /c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/oracle9/bin:/c/oracle8/bin: /i/progicil/orawin2:/i/progicil/orawin2/bin: /c/Program Files/Microsoft SQL Server/80/Tools/BINN: /c/Program Files/Fichiers communs/GTK/2.0/bin:/c/php5: /c/php5/ext:/c/Program Files/MySQL/MySQL Server 5.0/bin: /c/bin:/c/cygdrive/c/cygwin/bin:/c/cygdrive/c/cygwin/sbin:/c/oracle9/bin: /c/oracle8/bin:/i/progicil/orawin2:/i/progicil/orawin2/bin: /c/Program Files/Ekiga:/c/caml/bin PHL@BORG /c/program files/ekiga $ ./ekiga.exe 1>log 2>&1 Log is empty $ ls -rwxr-xr-x 1 PHL Administ 7934464 May 16 05:26 ekiga.exe -rw-r--r-- 1 PHL Administ 1231950 May 16 05:26 ekiga.schemas -rwxr-xr-x 1 PHL Administ 44032 May 16 05:26 liblber.dll -rwxr-xr-x 1 PHL Administ 188416 May 16 05:26 libldap_r.dll -rwxr-xr-x 1 PHL Administ 1276928 May 16 05:26 libxml2-2.dll drwxr-xr-x 70 PHL Administ 0 Jun 8 09:52 locale -rw-r--r-- 1 PHL Administ 0 Jun 8 13:30 log Using GDB in a cygdrive environment : $ gdb ekiga.exe GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) (gdb) run Starting program: /cygdrive/c/Program Files/Ekiga/ekiga.exe Program received signal SIGSEGV, Segmentation fault. Program received signal SIGSEGV, Segmentation fault. Program exited with code 0200. You can't do that without a process to debug. (gdb) bt No stack. (gdb) From jpuydt@free.fr Thu Jun 8 15:50:47 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 143943B027F for ; Thu, 8 Jun 2006 15:50:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01017-01 for ; Thu, 8 Jun 2006 15:50:46 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id E67403B021A for ; Thu, 8 Jun 2006 15:50:45 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp3-g19.free.fr (Postfix) with ESMTP id C567B4901D; Thu, 8 Jun 2006 21:50:43 +0200 (CEST) Message-ID: <44887FCD.7040300@free.fr> Date: Thu, 08 Jun 2006 21:51:41 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: ph.l@libertysurf.fr, GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Ekiga under windows References: <20060608160031.473BF3B0FB3@menubar.gnome.org> <44887ECE.9040902@libertysurf.fr> In-Reply-To: <44887ECE.9040902@libertysurf.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.434 tagged_above=-999 required=2 tests=[AWL=-0.143, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077, TW_RW=0.077, TW_WX=0.077] X-Spam-Score: -2.434 X-Spam-Level: Cc: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:50:47 -0000 Philippe Lefevre a écrit : > Today I tried to install ekiga on my PC under XP and I never get > anything to work :'( Yes, we don't have a nice installer yet. > I installed GTK 2.0 (version 2.8.9.0) installed under > C:\Program Files\Fichiers communs\GTK\2.0 I'm wondering if that is recent enough. > CYGWIN and MSYS are installed too Unnecessary. > $ ls > -rwxr-xr-x 1 PHL Administ 7934464 May 16 05:26 ekiga.exe > -rw-r--r-- 1 PHL Administ 1231950 May 16 05:26 ekiga.schemas > -rwxr-xr-x 1 PHL Administ 44032 May 16 05:26 liblber.dll > -rwxr-xr-x 1 PHL Administ 188416 May 16 05:26 libldap_r.dll > -rwxr-xr-x 1 PHL Administ 1276928 May 16 05:26 libxml2-2.dll > drwxr-xr-x 70 PHL Administ 0 Jun 8 09:52 locale > -rw-r--r-- 1 PHL Administ 0 Jun 8 13:30 log No libSDL.dll or some such ? :-/ Snark From ph.l@libertysurf.fr Thu Jun 8 16:43:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 40F853B00EA for ; Thu, 8 Jun 2006 16:43:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04211-07 for ; Thu, 8 Jun 2006 16:43:38 -0400 (EDT) Received: from smtp3.mail.easynet.fr (smarthost168.mail.easynet.fr [212.180.1.168]) by menubar.gnome.org (Postfix) with ESMTP id 52BD23B000E for ; Thu, 8 Jun 2006 16:43:37 -0400 (EDT) Received: from asi-236.asi256ip.easynet.fr ([212.180.39.236] helo=[145.111.24.1]) by smtp3.mail.easynet.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FoRMF-0007kr-6F; Thu, 08 Jun 2006 22:43:59 +0200 Message-ID: <44888BF6.8020906@libertysurf.fr> Date: Thu, 08 Jun 2006 22:43:34 +0200 From: Philippe Lefevre User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: Julien PUYDT , gnomemeeting-devel-list@gnome.org References: <20060608160031.473BF3B0FB3@menubar.gnome.org> <44887ECE.9040902@libertysurf.fr> <44887FCD.7040300@free.fr> In-Reply-To: <44887FCD.7040300@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.283 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077, TW_RW=0.077, TW_WX=0.077] X-Spam-Score: -2.283 X-Spam-Level: Cc: Subject: [GnomeMeeting-devel-list] Re : Ekiga under windows X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ph.l@libertysurf.fr, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 20:43:39 -0000 Julien PUYDT a écrit : > Philippe Lefevre a écrit : > >> Today I tried to install ekiga on my PC under XP and I never get >> anything to work :'( > > > Yes, we don't have a nice installer yet. No pb, unzip works well for now. > >> I installed GTK 2.0 (version 2.8.9.0) installed under >> C:\Program Files\Fichiers communs\GTK\2.0 > > > I'm wondering if that is recent enough. > 2.8.9.0 is the latest stable version but there is a 2.8.15 too dated from March (still unstable ?) >> CYGWIN and MSYS are installed too > > > Unnecessary. > Of course. It's just to use dbg. (I installed it for other things anyway) >> $ ls >> -rwxr-xr-x 1 PHL Administ 7934464 May 16 05:26 ekiga.exe >> -rw-r--r-- 1 PHL Administ 1231950 May 16 05:26 ekiga.schemas >> -rwxr-xr-x 1 PHL Administ 44032 May 16 05:26 liblber.dll >> -rwxr-xr-x 1 PHL Administ 188416 May 16 05:26 libldap_r.dll >> -rwxr-xr-x 1 PHL Administ 1276928 May 16 05:26 libxml2-2.dll >> drwxr-xr-x 70 PHL Administ 0 Jun 8 09:52 locale >> -rw-r--r-- 1 PHL Administ 0 Jun 8 13:30 log > > > No libSDL.dll or some such ? :-/ > Sorry I don't think so. I will check tomorrow (it is on my PC at work) But, I just check the zip file... there is no libSDL (or name close to that) into it. > Snark > Thanks Julien. From mcquaidster@gmail.com Thu Jun 8 17:09:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DF4253B0622 for ; Thu, 8 Jun 2006 17:09:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05835-02 for ; Thu, 8 Jun 2006 17:09:06 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id 76D583B0F9D for ; Thu, 8 Jun 2006 17:09:06 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id z74so693545pyg for ; Thu, 08 Jun 2006 14:09:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=HVNAtak5n7Z91wpmXr/Qu5ON4YhH7Q4dCf+4y5GUbTwwY23VOAXrmjBMj7263bIU8fqFePgmvS6HIFqN59D2Jy6YmXM2xD1V+aMpky/Ed9jdEhbQxbJYZUEi6YN6vk99BkQspxK0SEsZWjsxDvHu3Rk9O5hKBW5HcpVNrhkyGCo= Received: by 10.35.63.2 with SMTP id q2mr2928428pyk; Thu, 08 Jun 2006 14:09:05 -0700 (PDT) Received: by 10.35.31.2 with HTTP; Thu, 8 Jun 2006 14:09:05 -0700 (PDT) Message-ID: <58a398810606081409o3026d11cnd9f5f3a16b0243e@mail.gmail.com> Date: Thu, 8 Jun 2006 17:09:05 -0400 From: "mcquaid mcquaid" To: "GnomeMeeting development mailing list" In-Reply-To: <58a398810606061625x7684427q73db38225fa398dc@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10127_1193274.1149800945207" References: <58a398810606061625x7684427q73db38225fa398dc@mail.gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.359 tagged_above=-999 required=2 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.359 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Re: no audio on incoming calls. X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 21:09:10 -0000 ------=_Part_10127_1193274.1149800945207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Can I get any assistance on this or is there something else I should be providing? I can get other voip apps like linphone working but I can't get ekiga to transmit audio either way on incoming calls. Not sure if it's any help but asterisk seems to behave in the same manner. With asterisk I again could make outgoing call fine, but for incoming it would route calls to my local sipphone, but no audio either way. On 6/6/06, mcquaid mcquaid wrote: > > I have tried ekiga from time to time, and now using the latest cvs, I > still have the same problem. > > On outgoing calls, audio transmits both ways without issue. > > When receiving a call, no audio is transmitted either way. > > I realize it'll probably be considered a firewall issue, but linphone has > always worked for me and I have never setup stun or a nat traversal method > in linphone. I'd prefer to use ekiga instead of linphone. > > Here is the output of an incoming call that lasts until ekiga reports > 'remote user cleared the call'. > > I tried ekiga lastest cvs as I read about 2.02 hoping this might have been > resolved. > > > > ------=_Part_10127_1193274.1149800945207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Can I get any assistance on this or is there something else I should be providing?  I can get other voip apps like linphone working but I can't get ekiga to transmit audio either way on incoming calls.  Not sure if it's any help but asterisk seems to behave in the same manner.  With asterisk I again could make outgoing call fine, but for incoming it would route calls to my local sipphone, but no audio either way.

On 6/6/06, mcquaid mcquaid <mcquaidster@gmail.com> wrote:
I have tried ekiga from time to time, and now using the latest cvs, I still have the same problem.

On outgoing calls, audio transmits both ways without issue.

When receiving a call, no audio is transmitted either way.

I realize it'll probably be considered a firewall issue, but linphone has always worked for me and I have never setup stun or a nat traversal method in linphone.  I'd prefer to use ekiga instead of linphone.

Here is the output of an incoming call that lasts until ekiga reports 'remote user cleared the call'.

I tried ekiga lastest cvs as I read about 2.02 hoping this might have been resolved.




------=_Part_10127_1193274.1149800945207-- From dsandras@seconix.com Fri Jun 9 03:56:41 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5D27B3B006E for ; Fri, 9 Jun 2006 03:56:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05479-07 for ; Fri, 9 Jun 2006 03:56:39 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 62A113B017E for ; Fri, 9 Jun 2006 03:56:39 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 2E8E349758 for ; Fri, 9 Jun 2006 09:38:49 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16204-09 for ; Fri, 9 Jun 2006 09:38:42 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 6559949755 for ; Fri, 9 Jun 2006 09:38:42 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Re: no audio on incoming calls. From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <58a398810606081409o3026d11cnd9f5f3a16b0243e@mail.gmail.com> References: <58a398810606061625x7684427q73db38225fa398dc@mail.gmail.com> <58a398810606081409o3026d11cnd9f5f3a16b0243e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 09 Jun 2006 09:56:30 +0200 Message-Id: <1149839790.3351.0.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 07:56:41 -0000 You should provide a debug 4 output. Le jeudi 08 juin 2006 à 17:09 -0400, mcquaid mcquaid a écrit : > Can I get any assistance on this or is there something else I should > be providing? I can get other voip apps like linphone working but I > can't get ekiga to transmit audio either way on incoming calls. Not > sure if it's any help but asterisk seems to behave in the same manner. > With asterisk I again could make outgoing call fine, but for incoming > it would route calls to my local sipphone, but no audio either way. > > On 6/6/06, mcquaid mcquaid wrote: > I have tried ekiga from time to time, and now using the latest > cvs, I still have the same problem. > > On outgoing calls, audio transmits both ways without issue. > > When receiving a call, no audio is transmitted either way. > > I realize it'll probably be considered a firewall issue, but > linphone has always worked for me and I have never setup stun > or a nat traversal method in linphone. I'd prefer to use > ekiga instead of linphone. > > Here is the output of an incoming call that lasts until ekiga > reports 'remote user cleared the call'. > > I tried ekiga lastest cvs as I read about 2.02 hoping this > might have been resolved. > > > > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From ph.l@libertysurf.fr Sat Jun 10 12:49:37 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 174BA3B01B8 for ; Sat, 10 Jun 2006 12:49:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15518-01 for ; Sat, 10 Jun 2006 12:49:36 -0400 (EDT) Received: from smtp4.mail.easynet.fr (smarthost169.mail.easynet.fr [212.180.1.169]) by menubar.gnome.org (Postfix) with ESMTP id C9C343B032B for ; Sat, 10 Jun 2006 12:49:35 -0400 (EDT) Received: from asi-236.asi256ip.easynet.fr ([212.180.39.236] helo=[145.111.24.1]) by smtp4.mail.easynet.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Fp6fr-0001ZY-Dc for gnomemeeting-devel-list@gnome.org; Sat, 10 Jun 2006 18:50:59 +0200 Message-ID: <448AF812.4010106@libertysurf.fr> Date: Sat, 10 Jun 2006 18:49:22 +0200 From: Philippe Lefevre User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: GnomeMeeting devel list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.839 tagged_above=-999 required=2 tests=[AWL=-1.437, BAYES_05=-1.11, DNS_FROM_RFC_POST=1.708] X-Spam-Score: -0.839 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ekiga 2.0.2 Ubuntu packages X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 16:49:37 -0000 Hi all, For a few days I'm looking for Ekiga 2.0.2 for ubuntu packages @ http://www.ekiga.org but there are no link available yet. Is this normal ? Thanks. PhiL From mathiaschulze@gmail.com Sun Jun 11 10:47:28 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7E1CC3B00B0 for ; Sun, 11 Jun 2006 10:47:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14779-09 for ; Sun, 11 Jun 2006 10:47:27 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by menubar.gnome.org (Postfix) with ESMTP id 6898E3B0084 for ; Sun, 11 Jun 2006 10:47:27 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id 9so1563867nzo for ; Sun, 11 Jun 2006 07:46:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=RdwAYw0jPdY9iOC0Sf+iOKQJ9I7YfnL/kWXyEPnc+Cr+QIVa1sKM88ZdFWngpOkudGwRUvtt1Aw9vAL7lpvseD6hTwpLtjhbhu306m/DpJDRigRtWN/PSaYRcSohSjgiAaMN7SNdOXCHLIjQ0ZzdPpKX46kbgKn0qo2/Dg4UYbo= Received: by 10.37.2.45 with SMTP id e45mr7180725nzi; Sun, 11 Jun 2006 07:46:45 -0700 (PDT) Received: from vaio ( [71.98.110.104]) by mx.gmail.com with ESMTP id 37sm151203nzf.2006.06.11.07.46.44; Sun, 11 Jun 2006 07:46:45 -0700 (PDT) From: Mathias Schulze To: gnomemeeting-devel-list@gnome.org Content-Type: text/plain Date: Sun, 11 Jun 2006 10:46:43 -0400 Message-Id: <1150037203.24558.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.821 tagged_above=-999 required=2 tests=[AWL=-0.779, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.821 X-Spam-Level: Subject: [GnomeMeeting-devel-list] alsa default device X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 14:47:28 -0000 Hello, I would like to make Ekiga automatically use my USB Headset whenever it is plugged in. It is no problem to switch the default device to the headset by a udev rule. But Ekiga seems to ignore any changes of the default device after start-up. I think if the default device is selected Ekiga should check the current default device immediately before starting the conversation. So if someone calls I can plug in the USB headset and accept the call. An example of a program which seems to do this is the gnome music player "Listen". An even better solution (but maybe too much work?) could be if Ekiga pops up a request whenever a new audio device appears to ask the user if this device should be used. Such request appears e.g. under Ubuntu in the control panel. Thanks for Ekiga, it's really great! Mathias From dsandras@seconix.com Mon Jun 12 04:46:20 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EDE963B00D8 for ; Mon, 12 Jun 2006 04:46:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26328-09 for ; Mon, 12 Jun 2006 04:46:16 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id B27083B009D for ; Mon, 12 Jun 2006 04:46:16 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 8BE0B83C22 for ; Mon, 12 Jun 2006 10:26:53 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29245-09 for ; Mon, 12 Jun 2006 10:26:48 +0200 (CEST) Received: from [192.168.0.161] (157.137-245-81.adsl-dyn.isp.belgacom.be [81.245.137.157]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id BF7E583C1F for ; Mon, 12 Jun 2006 10:26:48 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Ekiga 2.0.2 Ubuntu packages From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <448AF812.4010106@libertysurf.fr> References: <448AF812.4010106@libertysurf.fr> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 12 Jun 2006 10:46:31 +0200 Message-Id: <1150101991.2505.12.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 08:46:20 -0000 Le samedi 10 juin 2006 à 18:49 +0200, Philippe Lefevre a écrit : > Hi all, > For a few days I'm looking for Ekiga 2.0.2 for ubuntu packages @ > http://www.ekiga.org > but there are no link available yet. Is this normal ? They are coming soon... -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Mon Jun 12 08:26:32 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 96E503B0061 for ; Mon, 12 Jun 2006 08:26:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01773-10 for ; Mon, 12 Jun 2006 08:26:29 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 0BDDA3B000D for ; Mon, 12 Jun 2006 08:26:28 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id A4ACC83C24 for ; Mon, 12 Jun 2006 13:43:24 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15346-08 for ; Mon, 12 Jun 2006 13:43:15 +0200 (CEST) Received: from [192.168.0.161] (157.137-245-81.adsl-dyn.isp.belgacom.be [81.245.137.157]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 3FB8E83C22 for ; Mon, 12 Jun 2006 13:43:15 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] alsa default device From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <1150037203.24558.24.camel@localhost.localdomain> References: <1150037203.24558.24.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 12 Jun 2006 14:03:41 +0200 Message-Id: <1150113821.7909.5.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 12:26:32 -0000 Hi, Le dimanche 11 juin 2006 à 10:46 -0400, Mathias Schulze a écrit : > Hello, > > I would like to make Ekiga automatically use my USB Headset whenever it > is plugged in. It is no problem to switch the default device to the > headset by a udev rule. But Ekiga seems to ignore any changes of the > default device after start-up. > It is most probably due to ALSA and libasound if I understand correctly what you mean. If you change from "USB Headset" to "Soundcard" or to "Default", Ekiga will work correctly. However, you probably mean that you want to select "Default" as device in Ekiga and that "Default" will be linked to the USB headset or to the soundcard depending if the headset is plugged in or not. For Ekiga, it is transparent. Ekiga simply open the "Default" device when playing sounds. If the "Default" device is linked in real time to the USB headset while Ekiga is running, and if it still uses the sound card, then it means that libasound already mapped the default device to the soundcard when starting the application and doesn't accept changing it. So I would say that I'm 100% confident it is an ALSA limitation. However, I tried here changing the settings of my default device through .asoundrc when Ekiga is running and it works. > I think if the default device is selected Ekiga should check the current > default device immediately before starting the conversation. So if > someone calls I can plug in the USB headset and accept the call. > An example of a program which seems to do this is the gnome music player > "Listen". It is transparent for Ekiga. Ekiga opens the "Default" device whatever it is through ALSA. > > An even better solution (but maybe too much work?) could be if Ekiga > pops up a request whenever a new audio device appears to ask the user if > this device should be used. Such request appears e.g. under Ubuntu in > the control panel. It is planned in the future through HAL. > > Thanks for Ekiga, it's really great! > Mathias > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Mon Jun 12 17:23:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 441F03B01DB for ; Mon, 12 Jun 2006 17:23:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31653-03 for ; Mon, 12 Jun 2006 17:23:08 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 994B13B0010 for ; Mon, 12 Jun 2006 17:23:08 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 666F683C23 for ; Mon, 12 Jun 2006 23:01:22 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19698-06 for ; Mon, 12 Jun 2006 23:01:18 +0200 (CEST) Received: from [192.168.0.161] (157.137-245-81.adsl-dyn.isp.belgacom.be [81.245.137.157]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id AFAEE83C22 for ; Mon, 12 Jun 2006 23:01:18 +0200 (CEST) From: Damien Sandras To: gnomemeeting-devel-list@gnome.org Content-Type: text/plain Date: Mon, 12 Jun 2006 23:24:02 +0200 Message-Id: <1150147442.11823.2.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Subject: [GnomeMeeting-devel-list] New user interface : first stubs X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 21:23:10 -0000 Hi to all, I committed the first stubs of the new user interface. Please do not criticize too much as it is work in progress and it is in the very early stages of development. Julien is working on big changes too, but that should have no impact on the user interface. In the next few weeks, I will work more on : - the user interface - sip support (integrate Craig's changes) And finally work on a roster. Enjoy, -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From jpuydt@free.fr Tue Jun 13 13:58:03 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 530F33B03CF for ; Tue, 13 Jun 2006 13:58:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01110-02 for ; Tue, 13 Jun 2006 13:58:01 -0400 (EDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by menubar.gnome.org (Postfix) with ESMTP id EC4F23B00DB for ; Tue, 13 Jun 2006 13:58:00 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by postfix1-c.free.fr (Postfix) with ESMTP id 91A4B1CF1DC3 for ; Tue, 13 Jun 2006 17:47:25 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-32-82-254-24-205.adsl.proxad.net [82.254.24.205]) by smtp6-g19.free.fr (Postfix) with ESMTP id CD69E2286C for ; Tue, 13 Jun 2006 18:42:21 +0200 (CEST) Message-ID: <448EC473.7060800@free.fr> Date: Tue, 13 Jun 2006 15:58:11 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <448B2A40.5060600@free.fr> <20060612174347.5181a8f9@localhost.localdomain> <448DABA7.4060103@free.fr> <200606130951.56969.ebischoff@nerim.net> In-Reply-To: <200606130951.56969.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.567 tagged_above=-999 required=2 tests=[AWL=0.032, BAYES_00=-2.599] X-Spam-Score: -2.567 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 17:58:03 -0000 Hi, in private mails (with quite big attachments since I provided some sample stupid code), Éric Bischoff found my code not that explicit concerning what I have in mind. Since I would like to keep things as opened as possible, I drop my text here :-) Let's see if I can manage to give useful ideas. ***** BIG WORDS Model - View - Controller ***** VIEWING (GENERIC) We need to be able to present a book to the user. For that, the view needs to have a list of contacts (no, a single contact definitely isn't enough!). So we need a function call to get a list of contacts. The problem is that this list will change during time (new contacts added, others removed, presence changed, status message changed, and the list goes on). So the view will need to be notified about it. Hence the idea that the book will have "contact-added" and "contact-removed" signals, and the contacts a "updated" signal. In addition to that, there is an interesting special case to handle : you have a contact in a book, and this contact shows up in a search result. When you remove the contact from the book, we want to make it disappear from the list too. Hence a "removed" signal for contacts. Now this is all nice, but what can we do if an addressbook contains millions of entries ? And if a search gives thousands of results ? In such cases, my stance is that the low level code should do something about it, since it is the one giving the problem. How can the high level code cope correctly with the situation anyway ? Only the low level code can say "Eh, I already made two hundred contacts go through the wire for that search, perhaps I should make it easy!". The question to really ask, and to which I have no satisfactory answer is: "How do me make the low level tell the high level it had to cut the list ?". ***** VIEWING (CONTACTS) The contacts should contain enough to be viewed from a generic view in the contacts window, and be shown in a search result. That won't prevent some other parts of the code to make a better use of them. For example, in the contact window we will probably be able to see a contact's title and description, but not its detailed presence, while the main window will contain a much better and more specific view for the live contacts. ***** CONTROLLING (GENERIC) Now, we want to be able to act on our objects ; say rename a book or a contact, subscribe/unsubscribe to its presence, etc. The best thing to do is to be able to get menus for each of them. Notice the plural: we will certainly to have at least menu in the menu bar and a popup menu. The first bad news about such menus is that they won't be generic : they will depend heavily on the specific type of object (no rename for avahi contacts, subscribe/unsubscribe only for XMPP contacts...). So we will certainly need some sort of shared actions that will be basic bricks for building menu (like the shared-actions.[ch] of my first round of proposals), that each implementation will mix as it sees fit. The second bad news about them is that they won't be static either. They will have to update themselves following the object they are attached to. Say your nice XMPP contact is connected with a client which has VoIP support, but now connects with a no-VoIP client, and disconnects the first : we want the "Call" menuitem to disappear to reflect this. So my proposition (no code yet) is that those menus will be obtained by subclassing of GtkMenu, register to get signals from the contact/book they are attached to, and use that to keep themselves up to date. ***** CONTROLLING (CONTACTS) Let's try to be more specific: in avahi-contact-menu.h, we would have: GtkWidget *avahi_contact_menu_new (AvahiContact *contact); and in gm-contact.h: GtkWidget *gm_contact_get_menu_new (GmContact *contact); This later function would be different in each implementation, which allows for example the avahi_contact_get_menu_new implementation to call avahi_contact_menu_new. The high level code called a generic function, but got access to a very specific implementation, which knows the full api of the specific contact, and hence will provide the best service. ***** CONTROLLING (BOOKS) Perhaps the menu shouldn't be attached to the book himself, but to its view. That would allow to place things such as "Show offline contacts" in it. Mostly the idea would be to have controllers for both the model-as-model and its view-as-model. ***** ABOUT EVOLUTION-DATA-SERVER The evolution-data-server api looks pretty good -- except that it seems to mainly handle static vcard-based contacts, where I would like to be able to handle things like. For example, we find a nice contacts-changed signal, but in the EBookView api... not in the EBook api, which seems strange. ***** ABOUT LIBGAIM I shriek everytime I read/think about that comment in blist.h (just before the declaration of struct _GaimBuddy) : "A buddy. This contains everything Gaim will ever need to know about someone on the buddy list. Everything." (sic). and that one (before the declaration of struct _GaimContact) : "A contact. This contains everything Gaim will ever need to know about a contact." and that one (before the declaration of struct _GaimGroup) : "A group. This contains everything Gaim will ever need to know about a group." Notice that the comment before struct _GaimChat, although very similar, isn't so bad in my eye :-) Notice too that although I find the way it is done inelegant, it still is very good and efficient to get the job done, and contains quite an impressive list of good ideas. (And it's more portable as ekiga, gasp!) ***** ABOUT LIBGALAGO Why, why, oh why does it contain a GalagoList api which looks so much like a GList but isn't !? Apart from that, I would say it looks nice, but is out of scope for what we want to do right now : it doesn't deal with addressbooks, but with persons as single. "Using" it would be nice at some point. ***** LAST WORDS Congratulations, comments and flames welcome, but flames will end in /dev/null. Snark From jpuydt@free.fr Thu Jun 15 04:55:35 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7B51D3B008E for ; Thu, 15 Jun 2006 04:55:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24192-02 for ; Thu, 15 Jun 2006 04:55:31 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id C36A43B00CA for ; Thu, 15 Jun 2006 04:55:30 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp3-g19.free.fr (Postfix) with ESMTP id 26E1F496DD for ; Thu, 15 Jun 2006 10:54:59 +0200 (CEST) Message-ID: <4491205F.5070708@free.fr> Date: Thu, 15 Jun 2006 10:54:55 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.369 tagged_above=-999 required=2 tests=[AWL=0.230, BAYES_00=-2.599] X-Spam-Score: -2.369 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 08:55:35 -0000 Hi, in private mails (with quite big attachments since I provided some sample stupid code), Éric Bischoff found my code not that explicit concerning what I have in mind. Since I would like to keep things as opened as possible, I drop my text here :-) Let's see if I can manage to give useful ideas. ***** BIG WORDS Model - View - Controller ***** VIEWING (GENERIC) We need to be able to present a book to the user. For that, the view needs to have a list of contacts (no, a single contact definitely isn't enough!). So we need a function call to get a list of contacts. The problem is that this list will change during time (new contacts added, others removed, presence changed, status message changed, and the list goes on). So the view will need to be notified about it. Hence the idea that the book will have "contact-added" and "contact-removed" signals, and the contacts a "updated" signal. In addition to that, there is an interesting special case to handle : you have a contact in a book, and this contact shows up in a search result. When you remove the contact from the book, we want to make it disappear from the list too. Hence a "removed" signal for contacts. Now this is all nice, but what can we do if an addressbook contains millions of entries ? And if a search gives thousands of results ? In such cases, my stance is that the low level code should do something about it, since it is the one giving the problem. How can the high level code cope correctly with the situation anyway ? Only the low level code can say "Eh, I already made two hundred contacts go through the wire for that search, perhaps I should make it easy!". The question to really ask, and to which I have no satisfactory answer is: "How do me make the low level tell the high level it had to cut the list ?". ***** VIEWING (CONTACTS) The contacts should contain enough to be viewed from a generic view in the contacts window, and be shown in a search result. That won't prevent some other parts of the code to make a better use of them. For example, in the contact window we will probably be able to see a contact's title and description, but not its detailed presence, while the main window will contain a much better and more specific view for the live contacts. ***** CONTROLLING (GENERIC) Now, we want to be able to act on our objects ; say rename a book or a contact, subscribe/unsubscribe to its presence, etc. The best thing to do is to be able to get menus for each of them. Notice the plural: we will certainly to have at least menu in the menu bar and a popup menu. The first bad news about such menus is that they won't be generic : they will depend heavily on the specific type of object (no rename for avahi contacts, subscribe/unsubscribe only for XMPP contacts...). So we will certainly need some sort of shared actions that will be basic bricks for building menu (like the shared-actions.[ch] of my first round of proposals), that each implementation will mix as it sees fit. The second bad news about them is that they won't be static either. They will have to update themselves following the object they are attached to. Say your nice XMPP contact is connected with a client which has VoIP support, but now connects with a no-VoIP client, and disconnects the first : we want the "Call" menuitem to disappear to reflect this. So my proposition (no code yet) is that those menus will be obtained by subclassing of GtkMenu, register to get signals from the contact/book they are attached to, and use that to keep themselves up to date. ***** CONTROLLING (CONTACTS) Let's try to be more specific: in avahi-contact-menu.h, we would have: GtkWidget *avahi_contact_menu_new (AvahiContact *contact); and in gm-contact.h: GtkWidget *gm_contact_get_menu_new (GmContact *contact); This later function would be different in each implementation, which allows for example the avahi_contact_get_menu_new implementation to call avahi_contact_menu_new. The high level code called a generic function, but got access to a very specific implementation, which knows the full api of the specific contact, and hence will provide the best service. ***** CONTROLLING (BOOKS) Perhaps the menu shouldn't be attached to the book himself, but to its view. That would allow to place things such as "Show offline contacts" in it. Mostly the idea would be to have controllers for both the model-as-model and its view-as-model. ***** ABOUT EVOLUTION-DATA-SERVER The evolution-data-server api looks pretty good -- except that it seems to mainly handle static vcard-based contacts, where I would like to be able to handle things like. For example, we find a nice contacts-changed signal, but in the EBookView api... not in the EBook api, which seems strange. ***** ABOUT LIBGAIM I shriek everytime I read/think about that comment in blist.h (just before the declaration of struct _GaimBuddy) : "A buddy. This contains everything Gaim will ever need to know about someone on the buddy list. Everything." (sic). and that one (before the declaration of struct _GaimContact) : "A contact. This contains everything Gaim will ever need to know about a contact." and that one (before the declaration of struct _GaimGroup) : "A group. This contains everything Gaim will ever need to know about a group." Notice that the comment before struct _GaimChat, although very similar, isn't so bad in my eye :-) Notice too that although I find the way it is done inelegant, it still is very good and efficient to get the job done, and contains quite an impressive list of good ideas. (And it's more portable as ekiga, gasp!) ***** ABOUT LIBGALAGO Why, why, oh why does it contain a GalagoList api which looks so much like a GList but isn't !? Apart from that, I would say it looks nice, but is out of scope for what we want to do right now : it doesn't deal with addressbooks, but with persons as single. "Using" it would be nice at some point. ***** LAST WORDS Congratulations, comments and flames welcome, but flames will end in /dev/null. Snark PS: this message is already two or three days old... but got stuck. From ebischoff@nerim.net Thu Jun 15 07:18:00 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 98B4A3B032E for ; Thu, 15 Jun 2006 07:18:00 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01896-02 for ; Thu, 15 Jun 2006 07:17:57 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id 2C6AF3B0488 for ; Thu, 15 Jun 2006 07:17:56 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 3CBA240F45 for ; Thu, 15 Jun 2006 13:17:52 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Thu, 15 Jun 2006 13:18:05 +0200 User-Agent: KMail/1.8.2 References: <4491205F.5070708@free.fr> In-Reply-To: <4491205F.5070708@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606151318.05338.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.578 tagged_above=-999 required=2 tests=[AWL=0.021, BAYES_00=-2.599] X-Spam-Score: -2.578 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 11:18:01 -0000 Hi Julien, and thanks for this nice document. That looks like a good basis for thinkin= g=20 aloud :-). Le Jeudi 15 Juin 2006 10:54, Julien PUYDT a =C3=A9crit=C2=A0: > ***** BIG WORDS > > Model - View - Controller Excellent basis. > ***** VIEWING (GENERIC) > > We need to be able to present a book to the user. For that, the view > needs to have a list of contacts (no, a single contact definitely isn't > enough!). So we need a function call to get a list of contacts. In this paragraph I will assume that you mean "the view needs a list of all= =20 contacts from the address book driver". If it is not what you mean, please= =20 ignore this paragraph... The view needs to display, say, 10 contects at a time. No need to keep a li= st=20 of all contacts in memory. All we "need" is a function that gets _one_ contact from the driver. The vi= ew=20 can then use this information to keep the list of the 10 contacts that it=20 currently displays. > The problem is that this list will change during time (new contacts > added, others removed, presence changed, status message changed, and the > list goes on). So the view will need to be notified about it. Hence the > idea that the book will have "contact-added" and "contact-removed" > signals, and the contacts a "updated" signal. > In addition to that, there is an interesting special case to handle : > you have a contact in a book, and this contact shows up in a search > result. When you remove the contact from the book, we want to make it > disappear from the list too. Hence a "removed" signal for contacts. While this sounds cool, I am not sure that this will be possible in some=20 circumstances. The underlying address book (evolution, KDE address book, LD= AP=20 server, Zeroconf, ...) might not have the mechanisms to send such a signal. I can imagine situations where some users on machine A update a LDAP server= on=20 machine B while Ekiga runs on machine C, with the network connection betwee= n=20 B and C being temporarily broken. Will an update message come up to the=20 driver, and if yes when and how? Please notice that I do not know LDAP well and that such mechanisms might=20 exist. Should that be the case, please ignore these paragraphs. What do I propose instead? To be less ambitious, and have an address book t= hat=20 only pulls the data from the data source. If the user does not press=20 "refresh", then he/she might have outdated information. If he/she presses=20 "refresh", then the addresses are fetched again from the source. > Now this is all nice, but what can we do if an addressbook contains > millions of entries ? And if a search gives thousands of results ? In > such cases, my stance is that the low level code should do something > about it, since it is the one giving the problem. I do not like that repartition of tasks. Let me take an example. When you write an operating system, you write: =2D disk drivers (the low level code that does physical read and write from and to the hard disk) =2D a filesystem (the high level code that gathers individual sectors into files, handles a cache, etc) The low level code should not be bothered with handling the disk cache. Oka= y,=20 the problem comes from the disk driver, because it does slow access to the= =20 medium. That does not mean that it's not another component, the filesystem,= =20 that can solve it. Why this repartition of tasks? Because the performance problem is a problem= =20 that can be shared by many disk drivers. Therefore, the solution can be put= =20 in common in the high level code. > How can the high level > code cope correctly with the situation anyway ? Only the low level code > can say "Eh, I already made two hundred contacts go through the wire for > that search, perhaps I should make it easy!". Why transfer 200 contacts when the view knows that it needs only 10? > The question to really ask, and to which I have no satisfactory answer > is: "How do me make the low level tell the high level it had to cut the > list ?". The views know that contacts 301 to 309 are displayed. It's the view that=20 knows where to cut. In fact, there's nothing to cut, since all the view doe= s=20 is ask the driver for the contects it needs. > ***** VIEWING (CONTACTS) > > The contacts should contain enough to be viewed from a generic view in > the contacts window, and be shown in a search result. That won't prevent > some other parts of the code to make a better use of them. > > For example, in the contact window we will probably be able to see a > contact's title and description, but not its detailed presence, while > the main window will contain a much better and more specific view for > the live contacts. You say that the "contact" class must have _enough_ information to be used= =20 both in situation A and in sitation B. It would be better to have _different_ "contact" classes for situations "A"= =20 and "B". The list of contacts could just manage a name, a company and a phone number= =2E=20 The search result could handle much more detailed information. In other words, there's no need to put all the model's data into the views'= =20 data. Each view can handle the data it needs. > ***** CONTROLLING (GENERIC) > > Now, we want to be able to act on our objects ; say rename a book or a > contact, subscribe/unsubscribe to its presence, etc. > > The best thing to do is to be able to get menus for each of them. Notice > the plural: we will certainly to have at least menu in the menu bar and > a popup menu. > > The first bad news about such menus is that they won't be generic : they > will depend heavily on the specific type of object (no rename for avahi > contacts, subscribe/unsubscribe only for XMPP contacts...). So we will > certainly need some sort of shared actions that will be basic bricks for > building menu (like the shared-actions.[ch] of my first round of > proposals), that each implementation will mix as it sees fit. I assume here that an 'implementation" is one of the address book drivers, = and=20 that you mean that the drivers will be in charge of building menus. If thos= e=20 assumptions are wrong, the paragraph below does not apply, please just igno= re=20 it. Just the same as a hard disk driver does not display menus to the user, I=20 think that the address book drivers in Ekiga should not be responsible for= =20 user interaction. The high level code should be responsible for that. Of course the contents = of=20 the various menus depends on the address book capabilities. That's why the= =20 API between the driver and the high level code should include "query=20 capabilities functions:" class addressBook { virtual bool isReadOnly() =3D 0; virtual bool canSubscribeContacts() =3D 0; ... }; > The second bad news about them is that they won't be static either. They > will have to update themselves following the object they are attached > to. Say your nice XMPP contact is connected with a client which has VoIP > support, but now connects with a no-VoIP client, and disconnects the > first : we want the "Call" menuitem to disappear to reflect this. > > So my proposition (no code yet) is that those menus will be obtained by > subclassing of GtkMenu, register to get signals from the contact/book > they are attached to, and use that to keep themselves up to date. In your example, a signal is not needed. Knowing that there is no VoIP number in the current contact is enough. > ***** CONTROLLING (CONTACTS) > > Let's try to be more specific: > in avahi-contact-menu.h, we would have: > GtkWidget *avahi_contact_menu_new (AvahiContact *contact); > and in gm-contact.h: > GtkWidget *gm_contact_get_menu_new (GmContact *contact); > > This later function would be different in each implementation, which > allows for example the avahi_contact_get_menu_new implementation to call > avahi_contact_menu_new. The high level code called a generic function, > but got access to a very specific implementation, which knows the full > api of the specific contact, and hence will provide the best service. Again, this logic should be in the high-level code and needs not be=20 avahi-specific. What exactly should be presented to the user could be=20 determined from querying the address book for its capabilities. > ***** CONTROLLING (BOOKS) > > Perhaps the menu shouldn't be attached to the book himself, but to its > view. That would allow to place things such as "Show offline contacts" > in it. Mostly the idea would be to have controllers for both the > model-as-model and its view-as-model. Agree. > ***** ABOUT EVOLUTION-DATA-SERVER > > The evolution-data-server api looks pretty good -- except that it seems > to mainly handle static vcard-based contacts, where I would like to be > able to handle things like. > > For example, we find a nice contacts-changed signal, but in the > EBookView api... not in the EBook api, which seems strange. > > ***** ABOUT LIBGAIM > > I shriek everytime I read/think about that comment in blist.h (just > before the declaration of struct _GaimBuddy) : > "A buddy. This contains everything Gaim will ever need to know about > someone on the buddy list. Everything." (sic). > and that one (before the declaration of struct _GaimContact) : > "A contact. This contains everything Gaim will ever need to know about > a contact." > and that one (before the declaration of struct _GaimGroup) : > "A group. This contains everything Gaim will ever need to know about a > group." > > Notice that the comment before struct _GaimChat, although very similar, > isn't so bad in my eye :-) > > Notice too that although I find the way it is done inelegant, it still > is very good and efficient to get the job done, and contains quite an > impressive list of good ideas. (And it's more portable as ekiga, gasp!) > > ***** ABOUT LIBGALAGO > > Why, why, oh why does it contain a GalagoList api which looks so much > like a GList but isn't !? > > Apart from that, I would say it looks nice, but is out of scope for what > we want to do right now : it doesn't deal with addressbooks, but with > persons as single. > > "Using" it would be nice at some point. > > ***** LAST WORDS > > Congratulations, comments and flames welcome, but flames will end in > /dev/null. It definitly deserves congratulations. You forgot to mention one of your ni= ce=20 ideas, that it that it should be possible to search in several address book= s=20 at a time. =46or the comments, please note that my comments are based on a lot of=20 assumptions and guesses. In particular, I assume that you have in mind a=20 different assignment of tasks of the various software layers than the one=20 that I would like to see. If those assumptions reveal wrong, then of course= =20 my comments do not make much sense. If I did not misinterpret your thoughts, you have a very lazy view of the=20 high-level code. It's software that sits down and waits for signals to act.= =20 Somehow, the high level code provides "services" to the drivers. The driver= s=20 are the ones who understand what's going on. I have the opposite view: the address book drivers are simple and stupid.=20 Their main task is to go and fetch the requested contacts. The high level=20 code has an active attitude: it queries the drivers for contacts, it querie= s=20 the drivers capabilities, it displays the contact windows, it handles the=20 menues... The high level code has the real intelligence. I hope that helps, =2D-=20 Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m=C3=A9dire." (Le concombre masqu=C3=A9, Mandriva) From kk@verfaction.de Thu Jun 15 10:03:55 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C686B3B0336 for ; Thu, 15 Jun 2006 10:03:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15471-01 for ; Thu, 15 Jun 2006 10:03:54 -0400 (EDT) Received: from mx.verfaction.de (mx.verfaction.de [212.9.177.23]) by menubar.gnome.org (Postfix) with ESMTP id 779793B00CE for ; Thu, 15 Jun 2006 10:03:54 -0400 (EDT) Received: from erebos.verfaction.de ([2001:14b0:201:7357::1] helo=homemx.verfaction.de ident=Debian-exim) by mx.verfaction.de with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FqsRp-0003kA-3Z for gnomemeeting-devel-list@gnome.org; Thu, 15 Jun 2006 16:03:52 +0200 Received: from ganymede.kk.de ([192.168.7.10]) by homemx.verfaction.de with esmtp (Exim 4.50) id 1FqsRk-0000ld-Dw for gnomemeeting-devel-list@gnome.org; Thu, 15 Jun 2006 16:03:48 +0200 From: Kilian Krause To: GnomeMeeting development mailing list In-Reply-To: <200606081002.37875.conrad_videokonferenz@gmx.de> References: <200606081002.37875.conrad_videokonferenz@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aitPD1cXT483JdjYdYcu" Date: Thu, 15 Jun 2006 16:03:43 +0200 Message-Id: <1150380224.6599.22.camel@ganymede.verfaction.de> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-SA-Exim-Connect-IP: 2001:14b0:201:7357::1 X-SA-Exim-Mail-From: kk@verfaction.de X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 14:03:56 -0000 --=-aitPD1cXT483JdjYdYcu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hey Conrad, Am Donnerstag, den 08.06.2006, 10:02 +0000 schrieb Conrad Beckert: > has anybody an idea where the Debian packages for Ekiga 2.0.2 (or the=20 > corresponding CVS versions) are? on their way. > The last version I can install using apt-get a couple of days old (May 25= - or=20 > somethin) - at least this is a version with the nonfunctional German loc= ale.=20 > (defaults to English) >=20 > What's up? /me is having a sheer lack of time and thus it took me a while to get everything polished and fixed just like i love to have it. =3D) Everything should be back to normal as of tonight (eventually sarge cvs snaps and win32 will remain for the weekend - we'll see) --=20 Best regards, Kilian --=-aitPD1cXT483JdjYdYcu Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEkWi/vdkzt4X+wX8RAnZ/AJoCW2qvo1l8kFsAJzogWEPKv73LUACZAZk6 n6VWZ1JiCCXnGNsq5yEsLwU= =VwN+ -----END PGP SIGNATURE----- --=-aitPD1cXT483JdjYdYcu-- From jpuydt@free.fr Thu Jun 15 11:41:17 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D25F23B0616 for ; Thu, 15 Jun 2006 11:41:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20025-08 for ; Thu, 15 Jun 2006 11:41:15 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id 8BF5B3B041B for ; Thu, 15 Jun 2006 11:41:14 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp6-g19.free.fr (Postfix) with ESMTP id 3FD8B227D9 for ; Thu, 15 Jun 2006 17:40:32 +0200 (CEST) Message-ID: <44917F71.10408@free.fr> Date: Thu, 15 Jun 2006 17:40:33 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> In-Reply-To: <200606151318.05338.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.337 tagged_above=-999 required=2 tests=[AWL=0.185, BAYES_00=-2.599, TW_AV=0.077] X-Spam-Score: -2.337 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:41:18 -0000 Éric Bischoff a écrit : >> ***** VIEWING (GENERIC) >> >> We need to be able to present a book to the user. For that, the view >> needs to have a list of contacts (no, a single contact definitely isn't >> enough!). So we need a function call to get a list of contacts. > > In this paragraph I will assume that you mean "the view needs a list of all > contacts from the address book driver". If it is not what you mean, please > ignore this paragraph... Well, all contacts may be asking too much. I expect drivers to keep things sane. > The view needs to display, say, 10 contects at a time. No need to keep a list > of all contacts in memory. > > All we "need" is a function that gets _one_ contact from the driver. The view > can then use this information to keep the list of the 10 contacts that it > currently displays. Blah. If you're gonna loop on a list of contacts anyway, then get the list at once. Saying "I get only the 10 I need" is nice, but how do you tell the driver which they are ? Especially a roster XMPP generally comes as a single roster push you ask for when connecting, then little update pushes. >> The problem is that this list will change during time (new contacts >> added, others removed, presence changed, status message changed, and the >> list goes on). So the view will need to be notified about it. Hence the >> idea that the book will have "contact-added" and "contact-removed" >> signals, and the contacts a "updated" signal. >> In addition to that, there is an interesting special case to handle : >> you have a contact in a book, and this contact shows up in a search >> result. When you remove the contact from the book, we want to make it >> disappear from the list too. Hence a "removed" signal for contacts. > > While this sounds cool, I am not sure that this will be possible in some > circumstances. The underlying address book (evolution, KDE address book, LDAP > server, Zeroconf, ...) might not have the mechanisms to send such a signal. No problem : then they don't. Let's take the avahi book. It will probably update the list of users regularly (and have some action to update *now*). How will it work ? Well, it will populate a cache with those contacts, and on updating, flush it ("contact-removed" emitted on all of them), then repopulate it ("contact-added"). > I can imagine situations where some users on machine A update a LDAP server on > machine B while Ekiga runs on machine C, with the network connection between > B and C being temporarily broken. Will an update message come up to the > driver, and if yes when and how? If the backend doesn't give incremental changes, that still fits in my design. > What do I propose instead? To be less ambitious, and have an address book that > only pulls the data from the data source. If the user does not press > "refresh", then he/she might have outdated information. If he/she presses > "refresh", then the addresses are fetched again from the source. Bad. If the backend gives incremental changes, you don't handle it. Such a design works only for the most simple backends. >> Now this is all nice, but what can we do if an addressbook contains >> millions of entries ? And if a search gives thousands of results ? In >> such cases, my stance is that the low level code should do something >> about it, since it is the one giving the problem. > > I do not like that repartition of tasks. > > Let me take an example. When you write an operating system, you write: > - disk drivers > (the low level code that does physical read and write from and to > the hard disk) > - a filesystem > (the high level code that gathers individual sectors into files, > handles a cache, etc) > > The low level code should not be bothered with handling the disk cache. Okay, > the problem comes from the disk driver, because it does slow access to the > medium. That does not mean that it's not another component, the filesystem, > that can solve it. > > Why this repartition of tasks? Because the performance problem is a problem > that can be shared by many disk drivers. Therefore, the solution can be put > in common in the high level code. Your file manager doesn't handle the filesystems itself : they all present the same interface, and take care of caching themselves. I want the addressbook manager to be *high* level. If some caching is needed between the addressbook manager and the backend, I want the driver to take care of it. In fact, I implemented a SearchBook to take care of presenting all search results (whatever the book), and it's certainly desirable to provide a CachedBook, which will avoid code duplication. >> How can the high level >> code cope correctly with the situation anyway ? Only the low level code >> can say "Eh, I already made two hundred contacts go through the wire for >> that search, perhaps I should make it easy!". > > Why transfer 200 contacts when the view knows that it needs only 10? The view may show only ten at the same time on the screen, but the mouse wheel makes it so easy to go through all of the 200, that it wouldn't be wise to have them ready. If there are several thousands, that's more annoying. >> The question to really ask, and to which I have no satisfactory answer >> is: "How do me make the low level tell the high level it had to cut the >> list ?". > > The views know that contacts 301 to 309 are displayed. It's the view that > knows where to cut. In fact, there's nothing to cut, since all the view does > is ask the driver for the contects it needs. How do you number the contacts in a sane way? >> ***** VIEWING (CONTACTS) >> >> The contacts should contain enough to be viewed from a generic view in >> the contacts window, and be shown in a search result. That won't prevent >> some other parts of the code to make a better use of them. >> >> For example, in the contact window we will probably be able to see a >> contact's title and description, but not its detailed presence, while >> the main window will contain a much better and more specific view for >> the live contacts. > > You say that the "contact" class must have _enough_ information to be used > both in situation A and in sitation B. > > It would be better to have _different_ "contact" classes for situations "A" > and "B". Of course there will be. I was discussing the base class. > The list of contacts could just manage a name, a company and a phone number. I would put the following : 1) a title (generally the name) 2) a description (for example a location, a status message, etc) 3) an icon > The search result could handle much more detailed information. Of course it cannot. Your search result is a book which needs to be able to show avahi contacts, sip contacts, call history contacts, etc... so it can only show the contacts as generic. > In other words, there's no need to put all the model's data into the views' > data. Each view can handle the data it needs. The view which is specific to an addressbook, of course can show the data from the specific contact associated to it. But the generic view can only show generic information. >> ***** CONTROLLING (GENERIC) >> >> Now, we want to be able to act on our objects ; say rename a book or a >> contact, subscribe/unsubscribe to its presence, etc. >> >> The best thing to do is to be able to get menus for each of them. Notice >> the plural: we will certainly to have at least menu in the menu bar and >> a popup menu. >> >> The first bad news about such menus is that they won't be generic : they >> will depend heavily on the specific type of object (no rename for avahi >> contacts, subscribe/unsubscribe only for XMPP contacts...). So we will >> certainly need some sort of shared actions that will be basic bricks for >> building menu (like the shared-actions.[ch] of my first round of >> proposals), that each implementation will mix as it sees fit. > > I assume here that an 'implementation" is one of the address book drivers, and > that you mean that the drivers will be in charge of building menus. If those > assumptions are wrong, the paragraph below does not apply, please just ignore > it. Yes, that's precisely that. > Just the same as a hard disk driver does not display menus to the user, I > think that the address book drivers in Ekiga should not be responsible for > user interaction The menu is supposed to contain actions which are specific to the given contact, book or view. Hence it must be created by code which is specific to that contact, book or view. It cannot be done by the generic code. > The high level code should be responsible for that. Of course the contents of > the various menus depends on the address book capabilities. That's why the > API between the driver and the high level code should include "query > capabilities functions:" > > class addressBook > { > virtual bool isReadOnly() = 0; > virtual bool canSubscribeContacts() = 0; > ... > }; No, that is wrong and I already explained why. Putting everything in the base class is bad. >> The second bad news about them is that they won't be static either. They >> will have to update themselves following the object they are attached >> to. Say your nice XMPP contact is connected with a client which has VoIP >> support, but now connects with a no-VoIP client, and disconnects the >> first : we want the "Call" menuitem to disappear to reflect this. >> >> So my proposition (no code yet) is that those menus will be obtained by >> subclassing of GtkMenu, register to get signals from the contact/book >> they are attached to, and use that to keep themselves up to date. > > In your example, a signal is not needed. > > Knowing that there is no VoIP number in the current contact is enough. That is wrong. The same contact could update itself and gain it. Or update itself and lose it. >> ***** CONTROLLING (CONTACTS) >> >> Let's try to be more specific: >> in avahi-contact-menu.h, we would have: >> GtkWidget *avahi_contact_menu_new (AvahiContact *contact); >> and in gm-contact.h: >> GtkWidget *gm_contact_get_menu_new (GmContact *contact); >> >> This later function would be different in each implementation, which >> allows for example the avahi_contact_get_menu_new implementation to call >> avahi_contact_menu_new. The high level code called a generic function, >> but got access to a very specific implementation, which knows the full >> api of the specific contact, and hence will provide the best service. > > Again, this logic should be in the high-level code and needs not be > avahi-specific. What exactly should be presented to the user could be > determined from querying the address book for its capabilities. Which means : 1) *all* of the addressbooks would by default have *all* the possible apis for such capability by default, with a isAbleToDoFoo function for each Foo capability ; 2) if an addressbook needs a new capability, we'll have to modify the base addressbook to add it in for it ; it won't just be a matter for the new code to add only what is necessary for itself in its own files. >> ***** CONTROLLING (BOOKS) >> >> Perhaps the menu shouldn't be attached to the book himself, but to its >> view. That would allow to place things such as "Show offline contacts" >> in it. Mostly the idea would be to have controllers for both the >> model-as-model and its view-as-model. > > Agree. Nice. >> Congratulations, comments and flames welcome, but flames will end in >> /dev/null. > > It definitly deserves congratulations. You forgot to mention one of your nice > ideas, that it that it should be possible to search in several address books > at a time. Well, that is the main side-effect of having a base class for contacts. > For the comments, please note that my comments are based on a lot of > assumptions and guesses. In particular, I assume that you have in mind a > different assignment of tasks of the various software layers than the one > that I would like to see. If those assumptions reveal wrong, then of course > my comments do not make much sense. I think you are focused on an addressbook as something both very big and very static, which explains many of our divergences. > If I did not misinterpret your thoughts, you have a very lazy view of the > high-level code. It's software that sits down and waits for signals to act. > Somehow, the high level code provides "services" to the drivers. The drivers > are the ones who understand what's going on. Yes, that's it. The high-level code doesn't know what an AvahiContact or EDSContact is ; it only knows avbout GmContact. That means it cannot do fancy things with them, and has to call functions on them to do anything interesting. > I have the opposite view: the address book drivers are simple and stupid. > Their main task is to go and fetch the requested contacts. The high level > code has an active attitude: it queries the drivers for contacts, it queries > the drivers capabilities, it displays the contact windows, it handles the > menues... The high level code has the real intelligence. Your high level code is very complex, and has to be modified heavily anytime we add a new type of addressbook with new capabilities. Anytime you want to do something, you should ask yourself the question: "Who knows how to do it?". You want to send a message to a contact ? Who knows if it's even possible, and how to do it ? The contact itself! Hence this should be handled by the contact. Of course, as-is that would mean a lot of code duplication. That's where we can use a toolbox ; of which you had an example in the first round of sample code I sent in private. To make it explicit for the -devel- readers, this sample code had a function: void shared_action_rename (GObject *obj); so any object which could be renamed, had only to: - have a "name" property ; - provide an action which trigerred that function on itself. the function handled showing a nice dialog to rename the function. The idea is that of course quite a few objects will have common capabilities ; but instead of putting them all in the high level code and clutter it with functions and conditional, I want to provide the bricks which the low-level code will use to build a specific and well-fit system. Snark From ebischoff@nerim.net Thu Jun 15 14:27:54 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1F1163B04C0 for ; Thu, 15 Jun 2006 14:27:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27103-03 for ; Thu, 15 Jun 2006 14:27:51 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id E36E93B0412 for ; Thu, 15 Jun 2006 14:27:50 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 25E1340F90 for ; Thu, 15 Jun 2006 20:26:36 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Thu, 15 Jun 2006 20:26:49 +0200 User-Agent: KMail/1.8.2 References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> <44917F71.10408@free.fr> In-Reply-To: <44917F71.10408@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606152026.49639.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.533 tagged_above=-999 required=2 tests=[AWL=-0.011, BAYES_00=-2.599, SUBJECT_EXCESS_QP=0, TW_AV=0.077] X-Spam-Score: -2.533 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] =?utf-8?q?Ideas_and_considerations_for_?= =?utf-8?q?the=09addressbook_code?= X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 18:27:54 -0000 Le Jeudi 15 Juin 2006 17:40, Julien PUYDT a =C3=A9crit=C2=A0: > Saying "I get only the 10 I need" is nice, but how do you tell the > driver which they are ? There are several ways to acheive that. It could be contact numbers. Or it= =20 could be some data kept internally inside the driver. It could be a void *.= =20 Etc. > > While this sounds cool, I am not sure that this will be possible in some > > circumstances. The underlying address book (evolution, KDE address book, > > LDAP server, Zeroconf, ...) might not have the mechanisms to send such a > > signal. > > No problem : then they don't. OK. So that should not be a requirement, and certainly not a mechanism at t= he=20 core of the system. Just a nice plus. > > Why transfer 200 contacts when the view knows that it needs only 10? > > The view may show only ten at the same time on the screen, but the mouse > wheel makes it so easy to go through all of the 200, that it wouldn't be > wise to have them ready. Yes. You could have a few spare contacts before and after the user's view.= =20 This algorithm is rather common. > If there are several thousands, that's more annoying. Okay. Let's simulate your algorithm, or what I have understood of it. The user views a search selection of contacts named "Tom". His/her window=20 should contain contacts Tom Smith (#1032), Tom Jones (#2050) and Tom Doe=20 (#3172). The high level software asks the driver "get me all contacts". Aft= er=20 a relatively long time, the driver is wise and stops at contact 200. It=20 returns a list with contacts 1, 2, 3, etc, up to 200. The high level softwa= re=20 searches for Tom's in the list and finds none, since the Tom's have numbers= =20 1032, 2050 and 3172. The returned list is useless, and the window remains=20 blank. I know that it cannot be _that_ bad and that I certainly misunderstood=20 something. But what? > > The views know that contacts 301 to 309 are displayed. It's the view th= at > > knows where to cut. In fact, there's nothing to cut, since all the view > > does is ask the driver for the contects it needs. > > How do you number the contacts in a sane way? These numbers are here for the demonstration. I agree that numbers probably= =20 are not so well adapted to real address books. You could use "markers". I think that all address books use contact UIDs. A= =20 given UID could be used to mark the place where the address book stopped=20 "last time". =46or most usage you do not even need anything. Most operation is sequentia= l.=20 Take for example searching. Usually you browse all records and only keep in= =20 the result list the ones that match. > I would put the following : > 1) a title (generally the name) > 2) a description (for example a location, a status message, etc) > 3) an icon Yes, we are discussing principles. Details can be arranged later. > > The search result could handle much more detailed information. > > Of course it cannot. Your search result is a book which needs to be able > to show avahi contacts, sip contacts, call history contacts, etc... so > it can only show the contacts as generic. Why would you be unable to display detailed information about objects which= =20 you only know as generic? while (genericContact =3D nextContact()) { if (genericContact->book()->canSubscribeContacts()) proposeSubscription(genericContact); ... } > The view which is specific to an addressbook, of course can show the > data from the specific contact associated to it. But the generic view > can only show generic information. Wrong ;-). Not shown in the code sample above, but that's also the whole point of virt= ual=20 methods. > The menu is supposed to contain actions which are specific to the given > contact, book or view. Hence it must be created by code which is > specific to that contact, book or view. It cannot be done by the generic > code. ;-) > > class addressBook > > { > > virtual bool isReadOnly() =3D 0; > > virtual bool canSubscribeContacts() =3D 0; > > ... > > }; > > No, that is wrong and I already explained why. Putting everything in the > base class is bad. Do you realize that the above is not an implementation? It's just an API=20 definition. Those are pure virtual methods. Everything is implemented in th= e=20 derived subclasses. Such style of coding is very classical, good, C++ (or java). > > In your example, a signal is not needed. > > > > Knowing that there is no VoIP number in the current contact is enough. > > That is wrong. The same contact could update itself and gain it. Or > update itself and lose it. I should have added "at a given time". > Which means : > 1) *all* of the addressbooks would by default have *all* the possible > apis for such capability by default, with a isAbleToDoFoo function for > each Foo capability ; No. Defining pure virtual functions in the base class does not mean that yo= u=20 implement a function in the derived class. If it can't do something, and le= ts=20 the engine know it, then it can't ;-). > 2) if an addressbook needs a new capability, we'll have to modify the > base addressbook to add it in for it ; it won't just be a matter for the > new code to add only what is necessary for itself in its own files. Wrong again, C++ comes with programming techniques that permit to locate th= e=20 real implementations in the derived classes. > > It definitly deserves congratulations. You forgot to mention one of your > > nice ideas, that it that it should be possible to search in several > > address books at a time. > > Well, that is the main side-effect of having a base class for contacts. ;-) > I think you are focused on an addressbook as something both very big and > very static, which explains many of our divergences. I think that we are both wrong here ;-). An address book could be big (whic= h=20 you underestimated), and it could be moving (which I underestimated). > Yes, that's it. The high-level code doesn't know what an AvahiContact or > EDSContact is ; it only knows avbout GmContact. That means it cannot do > fancy things with them, and has to call functions on them to do anything > interesting. I have a view that is not so far away. The book just knows contacts. Virtua= l=20 methods and subclassing both the book and the contacts does the rest. > Your high level code is very complex, and has to be modified heavily > anytime we add a new type of addressbook with new capabilities. Yes, but much more generic. And if the same capability exists in a second address book, the code is=20 already written. > Of course, as-is that would mean a lot of code duplication. That's where > we can use a toolbox ; of which you had an example in the first round of > sample code I sent in private. Ah, you too you can see the duplication problem with your method ;-). A tool box... Sounds like a C library ;-). I think that we basically foresee the same problems, but you want to do the= m=20 in the procedural, C way, and I would like them to be done in the=20 object-oriented, C++ way. > To make it explicit for the -devel- readers, this sample code had a > function: > void shared_action_rename (GObject *obj); > so any object which could be renamed, had only to: > - have a "name" property ; > - provide an action which trigerred that function on itself. > the function handled showing a nice dialog to rename the function. Yup. You see functions where I see methods ;-). > The idea is that of course quite a few objects will have common > capabilities ; but instead of putting them all in the high level code > and clutter it with functions and conditional, Yes, that would be the logical consequence if we were in C. We are not. We= =20 have virtual methods. > I want to provide the=20 > bricks which the low-level code will use to build a specific and > well-fit system. You will end up with an engine doing about nothing, and all the work to be= =20 reimplemented again and again in the drivers. Plus painfully shared code in= =20 the "toolbox" to avoid almost identical code where it can be avoided. That'= s=20 typical procedural approach. =2D-=20 Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m=C3=A9dire." (Le concombre masqu=C3=A9, Mandriva) From jpuydt@free.fr Thu Jun 15 16:46:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 4F0A43B01FF for ; Thu, 15 Jun 2006 16:46:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32671-05 for ; Thu, 15 Jun 2006 16:46:37 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 91ADA3B00D0 for ; Thu, 15 Jun 2006 16:46:36 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp1-g19.free.fr (Postfix) with ESMTP id 743AD9A39A for ; Thu, 15 Jun 2006 22:46:01 +0200 (CEST) Message-ID: <4491C708.3060203@free.fr> Date: Thu, 15 Jun 2006 22:46:00 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> <44917F71.10408@free.fr> <200606152026.49639.ebischoff@nerim.net> In-Reply-To: <200606152026.49639.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.342 tagged_above=-999 required=2 tests=[AWL=0.180, BAYES_00=-2.599, TW_AV=0.077] X-Spam-Score: -2.342 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 20:46:39 -0000 Éric Bischoff a écrit : > Le Jeudi 15 Juin 2006 17:40, Julien PUYDT a écrit : >> Saying "I get only the 10 I need" is nice, but how do you tell the >> driver which they are ? > > There are several ways to acheive that. It could be contact numbers. Or it > could be some data kept internally inside the driver. It could be a void *. > Etc. Well, then you reduced the question: "How do I tell the driver which contacts I want?" to: "How do I tell the driver which identifiers I want?" I don't find this impressive. >>> While this sounds cool, I am not sure that this will be possible in some >>> circumstances. The underlying address book (evolution, KDE address book, >>> LDAP server, Zeroconf, ...) might not have the mechanisms to send such a >>> signal. >> No problem : then they don't. > > OK. So that should not be a requirement, and certainly not a mechanism at the > core of the system. Just a nice plus. It *must* be at the core of the system. We _do_ want to update the live data when it changes. >>> Why transfer 200 contacts when the view knows that it needs only 10? >> The view may show only ten at the same time on the screen, but the mouse >> wheel makes it so easy to go through all of the 200, that it wouldn't be >> wise to have them ready. > > Yes. You could have a few spare contacts before and after the user's view. > This algorithm is rather common. What do "before" and "after" mean ? >> If there are several thousands, that's more annoying. > > Okay. Let's simulate your algorithm, or what I have understood of it. > > The user views a search selection of contacts named "Tom". His/her window > should contain contacts Tom Smith (#1032), Tom Jones (#2050) and Tom Doe > (#3172). The high level software asks the driver "get me all contacts". After > a relatively long time, the driver is wise and stops at contact 200. It > returns a list with contacts 1, 2, 3, etc, up to 200. The high level software > searches for Tom's in the list and finds none, since the Tom's have numbers > 1032, 2050 and 3172. The returned list is useless, and the window remains > blank. > > I know that it cannot be _that_ bad and that I certainly misunderstood > something. But what? I certainly have issues with big books, and must find some satisfying way to handle them. But doing function calls to walk on a list where I could get the list and walk it myself directly, is definitely wrong. >>> The views know that contacts 301 to 309 are displayed. It's the view that >>> knows where to cut. In fact, there's nothing to cut, since all the view >>> does is ask the driver for the contects it needs. >> How do you number the contacts in a sane way? > > These numbers are here for the demonstration. I agree that numbers probably > are not so well adapted to real address books. > > You could use "markers". I think that all address books use contact UIDs. A > given UID could be used to mark the place where the address book stopped > "last time". Notice that the only place where you call the _get_contacts function is when you first populate the book. The rest of the time you don't want to know. > For most usage you do not even need anything. Most operation is sequential. > Take for example searching. Usually you browse all records and only keep in > the result list the ones that match. Most operations are sequential when the book is static. When your contacts go online/offline/whatever, that certainly is random access, and I can tell you a first/current/next approach doesn't fly in such a situation. >>> The search result could handle much more detailed information. >> Of course it cannot. Your search result is a book which needs to be able >> to show avahi contacts, sip contacts, call history contacts, etc... so >> it can only show the contacts as generic. > > Why would you be unable to display detailed information about objects which > you only know as generic? > > while (genericContact = nextContact()) > { > if (genericContact->book()->canSubscribeContacts()) > proposeSubscription(genericContact); > ... > } Yes, of course. You put everything at the high level, something which I already stressed was very very bad. Let's try an example. A text editor will just access files. It won't wonder if they are local or remote, it won't wonder about where the data really is on disk, need caching, etc. This is the job of the low-level system. The text editor doesn't have functions and tests to handle all of the various situations possible. High level is high, it doesn't take mud baths with the details, it doesn't handle them. It delegates them to the low level. >> The view which is specific to an addressbook, of course can show the >> data from the specific contact associated to it. But the generic view >> can only show generic information. > > Wrong ;-). Partially wrong. The generic view can indeed get access to some specific features (like the menus I explained). But it certainly *must* not get them by handling *all* possible situations. >>> class addressBook >>> { >>> virtual bool isReadOnly() = 0; >>> virtual bool canSubscribeContacts() = 0; >>> ... >>> }; >> No, that is wrong and I already explained why. Putting everything in the >> base class is bad. > > Do you realize that the above is not an implementation? It's just an API > definition. Those are pure virtual methods. Everything is implemented in the > derived subclasses. > > Such style of coding is very classical, good, C++ (or java). Such style of coding is not classical, is bad and evil. I see abstractions layers everywhere to hide the details of the lower level, and you want to push those details high up the stack. >>> In your example, a signal is not needed. >>> >>> Knowing that there is no VoIP number in the current contact is enough. >> That is wrong. The same contact could update itself and gain it. Or >> update itself and lose it. > > I should have added "at a given time". > >> Which means : >> 1) *all* of the addressbooks would by default have *all* the possible >> apis for such capability by default, with a isAbleToDoFoo function for >> each Foo capability ; > > No. Defining pure virtual functions in the base class does not mean that you > implement a function in the derived class. If it can't do something, and lets > the engine know it, then it can't ;-). You push all the code to the high level, and never really abstract. That is very wrong. >> 2) if an addressbook needs a new capability, we'll have to modify the >> base addressbook to add it in for it ; it won't just be a matter for the >> new code to add only what is necessary for itself in its own files. > > Wrong again, C++ comes with programming techniques that permit to locate the > real implementations in the derived classes. If I add a new addressbook type with a Foo capability, your designs says I have to modify the base class and add: bool canDoFoo (); void pleaseDoFooThisWay (...); void pleaseDoFooThisOtherWay (...); void etcFoo (...) (with all the virtual pure syntactic crap needed) My idea of right design is that if the new addressbook is the only one needing Foo, it will handle it himself (through a specific api that its view and controller will know and use). >> I think you are focused on an addressbook as something both very big and >> very static, which explains many of our divergences. > > I think that we are both wrong here ;-). An address book could be big (which > you underestimated), and it could be moving (which I underestimated). I agree I have issues seeing how to do things *properly* with a very large addressbook. >> Yes, that's it. The high-level code doesn't know what an AvahiContact or >> EDSContact is ; it only knows avbout GmContact. That means it cannot do >> fancy things with them, and has to call functions on them to do anything >> interesting. > > I have a view that is not so far away. The book just knows contacts. Virtual > methods and subclassing both the book and the contacts does the rest. > >> Your high level code is very complex, and has to be modified heavily >> anytime we add a new type of addressbook with new capabilities. > > Yes, but much more generic. It isn't much more generic. It is an awful and indigest mix of all the specific implementations. > And if the same capability exists in a second address book, the code is > already written. Not really. >> Of course, as-is that would mean a lot of code duplication. That's where >> we can use a toolbox ; of which you had an example in the first round of >> sample code I sent in private. > > Ah, you too you can see the duplication problem with your method ;-). > > A tool box... Sounds like a C library ;-). Which are very useful and allow to abstract common work at a lower layer and not take care of it ourselves way up. > I think that we basically foresee the same problems, but you want to do them > in the procedural, C way, and I would like them to be done in the > object-oriented, C++ way. Your view isn't OO, and isn't C++. >> To make it explicit for the -devel- readers, this sample code had a >> function: >> void shared_action_rename (GObject *obj); >> so any object which could be renamed, had only to: >> - have a "name" property ; >> - provide an action which trigerred that function on itself. >> the function handled showing a nice dialog to rename the function. > > Yup. You see functions where I see methods ;-). I see functions spread in maintainable files, with well-separated features and responsibility. You see functions named "methods" stuffed into the same poor base class, which has to handle everything and the rest, and where the limits between everything is blurred. Where I say function and do: gm_contact_do_foo (contact, arguments); you say method and to: contact->do_foo (arguments); which I agree is shorter, but isn't the magical solution you think it is! :-) >> The idea is that of course quite a few objects will have common >> capabilities ; but instead of putting them all in the high level code >> and clutter it with functions and conditional, > > Yes, that would be the logical consequence if we were in C. We are not. We > have virtual methods. You *do* have isReadOnly and canSubscribeContacts, which you will use to do the ifs I said where very wrong, and you will do so at the high level, which is precisely the place where details shouldn't be handled! It isn't a case of leaky abstraction, it is a case of no-abstraction! >> I want to provide the >> bricks which the low-level code will use to build a specific and >> well-fit system. > > You will end up with an engine doing about nothing, and all the work to be > reimplemented again and again in the drivers. Plus painfully shared code in > the "toolbox" to avoid almost identical code where it can be avoided. That's > typical procedural approach. I generally end up with nice layers of functions doing almost nothing, with clean api between the layer, ensuring the code will be pretty maintainable. See lib/gmconf/ for example. We have a nice api in gmconf.h, and an implementation in gmconf-glib.c, which is layered in the same file, with lowlevel functions doing some work, and higher level doing another. Not everything done at the same final level. When I wrote that code, the goal was to make gconf (the gnome configuration management system) optional, so the port to win32 would be easier. I wrote a generic api to handle things, then two implementations *hidden* behind it. Well, at least we both agree I don't handle the case of very large addressbooks very well :-/ Snark From jpuydt@free.fr Fri Jun 16 11:44:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AC28C3B0005 for ; Fri, 16 Jun 2006 11:44:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01534-04 for ; Fri, 16 Jun 2006 11:44:08 -0400 (EDT) Received: from postfix2-c.free.fr (postfix2-c.free.fr [213.228.0.80]) by menubar.gnome.org (Postfix) with ESMTP id E28BA3B0007 for ; Fri, 16 Jun 2006 11:44:07 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by postfix2-c.free.fr (Postfix) with ESMTP id E4AFC458B6CE for ; Fri, 16 Jun 2006 16:07:32 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp6-g19.free.fr (Postfix) with ESMTP id DF5BD2265E for ; Fri, 16 Jun 2006 17:02:28 +0200 (CEST) Message-ID: <4492B888.8060206@free.fr> Date: Fri, 16 Jun 2006 15:56:24 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> In-Reply-To: <4491205F.5070708@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.382 tagged_above=-999 required=2 tests=[AWL=0.217, BAYES_00=-2.599] X-Spam-Score: -2.382 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 15:44:10 -0000 Julien PUYDT a écrit : > ***** ABOUT EVOLUTION-DATA-SERVER > > The evolution-data-server api looks pretty good -- except that it seems > to mainly handle static vcard-based contacts, where I would like to be > able to handle things like. Hmmm... this sentence should have ended with "able to handle things like live contacts with presence (SIP and XMPP)". On the subject of big addressbook handling, I must say what evolution-data-server does is quite nice : they run a query (EQuery) on a book (EBook), which gives them a view of the result (EBookView). That means that they can easily do a partial view of an addressbook, since they control what is seen! While this organisation doesn't suffer from the problem Éric pointed out, it has still a problem : how does one just "search" ? I mean, if your api is "search a book => get a view", how does one make a search which encompasses all books? Snark PS: notice that the current addressbook code happily tries to get all contacts, whatever the size of the addressbook -- and even not asynchronously! From jpuydt@free.fr Sat Jun 17 03:08:50 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 27E423B03CB for ; Sat, 17 Jun 2006 03:08:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11317-07 for ; Sat, 17 Jun 2006 03:08:48 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 068E83B00DE for ; Sat, 17 Jun 2006 03:08:47 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-57-82-249-55-125.adsl.proxad.net [82.249.55.125]) by smtp1-g19.free.fr (Postfix) with ESMTP id CE8E69AA70 for ; Sat, 17 Jun 2006 09:07:34 +0200 (CEST) Message-ID: <4493AA32.5030602@free.fr> Date: Sat, 17 Jun 2006 09:07:30 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> In-Reply-To: <4492B888.8060206@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.586 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599] X-Spam-Score: -2.586 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 07:08:50 -0000 Julien PUYDT a écrit : > While this organisation doesn't suffer from the problem Éric pointed > out, it has still a problem : how does one just "search" ? I mean, if > your api is "search a book => get a view", how does one make a search > which encompasses all books? Ok, I think I'm on something : let's a book have a simple api, where on one side: 1) a book can return a view for itself, which means the view becomes specific, and hence can handle the case of big addressbooks ; 2) a full search function, which will return a new book, restricted to the the search ; again this book has its view, which will handle the case of big searches ; 3) a restricted search function, which will return say at most a hundred contacts matching the string ; this one allows to make a search on all the books, since we are assured we won't be drowned by the number. This organisation would allow a clean approach for the view on a single addressbook, while still having the possibility to have a working "Find a contact" button. Does that looks nicer ? Snark From ebischoff@nerim.net Sat Jun 17 05:24:05 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id ACD5F3B038B for ; Sat, 17 Jun 2006 05:24:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15888-07 for ; Sat, 17 Jun 2006 05:24:02 -0400 (EDT) Received: from kellthuzad.dmz.nerim.net (smtp-dmz-236-saturday.dmz.nerim.net [195.5.254.236]) by menubar.gnome.org (Postfix) with ESMTP id 2C81F3B0809 for ; Sat, 17 Jun 2006 05:24:01 -0400 (EDT) Received: from kraid.nerim.net (smtp-106-saturday.nerim.net [62.4.16.106]) by kellthuzad.dmz.nerim.net (Postfix) with ESMTP id 9BD1139D6B for ; Sat, 17 Jun 2006 11:23:14 +0200 (CEST) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 5A4A940E35 for ; Sat, 17 Jun 2006 11:22:48 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Sat, 17 Jun 2006 11:22:59 +0200 User-Agent: KMail/1.8.2 References: <4491205F.5070708@free.fr> <200606152026.49639.ebischoff@nerim.net> <4491C708.3060203@free.fr> In-Reply-To: <4491C708.3060203@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606171123.00082.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.51 tagged_above=-999 required=2 tests=[AWL=0.089, BAYES_00=-2.599] X-Spam-Score: -2.51 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 09:24:05 -0000 Le Jeudi 15 Juin 2006 22:46, Julien PUYDT a =C3=A9crit=C2=A0: > > OK. So that should not be a requirement, and certainly not a mechanism = at > > the core of the system. Just a nice plus. > > It *must* be at the core of the system. We _do_ want to update the live > data when it changes. Sorry, that was not clear. By "at the core" I meant "necessary for the addr= ess=20 books to work". > > Yes. You could have a few spare contacts before and after the user's > > view. This algorithm is rather common. > > What do "before" and "after" mean ? Records just before and after the ones that are displayed in sequential ord= er. > > I know that it cannot be _that_ bad and that I certainly misunderstood > > something. But what? > > I certainly have issues with big books, and must find some satisfying > way to handle them. But doing function calls to walk on a list where I > could get the list and walk it myself directly, is definitely wrong. What is wrong is to see that as a list ;-). > Most operations are sequential when the book is static. When your > contacts go online/offline/whatever, that certainly is random access, > and I can tell you a first/current/next approach doesn't fly in such a > situation. I would not say "not fly" but it certainly becomes much more acrobatic, I=20 agree. > If I add a new addressbook type with a Foo capability, your designs says > I have to modify the base class and add: > > bool canDoFoo (); > void pleaseDoFooThisWay (...); > void pleaseDoFooThisOtherWay (...); > void etcFoo (...) > (with all the virtual pure syntactic crap needed) This "crap" is a lightweight modification since it is only one function=20 declaration. No implementation. That is done in the subclasses, if necessar= y. > My idea of right design is that if the new addressbook is the only one > needing Foo, it will handle it himself (through a specific api that its > view and controller will know and use). Okay. Perharps the our differences in opinion is not that much on the=20 programming design, but more on what the software has to do. To me, an address book is just an address book, they are not that different= =20 one from the other. Ekiga need to dig through them to show names, categorie= s=20 and to pick up SIP numbers to call the people. I see a relatively homogeneo= us=20 user interface, with more or less the same appearance (if not exactly the=20 same) for the various address books. I have a "unifying" vision. To you, all address books have very strong pecularities and the software ha= s=20 to adapt a lot to each of them, to take them to the maximum of their=20 possibilities. The user will get different display, different menues, and=20 even different functionality. That explains why you want to put everything in the "drivers", while I want= to=20 put a lot of common logic in the "engine". > > I think that we are both wrong here ;-). An address book could be big > > (which you underestimated), and it could be moving (which I > > underestimated). > > I agree I have issues seeing how to do things *properly* with a very > large addressbook. Yes, and I have certainly underestimated the "dynamic" aspect :-(. > Your view isn't OO, and isn't C++. Come on ;-). > You see functions named "methods" stuffed into the same poor base class, No. Again and again, the base class only has declarations. It sees an=20 abstraction of what the address book is. In every C++ book, you can see examples like this class vehicle { virtual void accelerate(int a) =3D 0; ... }; class car : public vehicle { virtual void accelerate(int a); ... }; class plane : public vehicle { virtual void accelerate(int a); ... }; Planes and cars have very different ways to accelerate. Planes can't brake = and=20 cars can't fly, but such designs are clean and very popular. > Well, at least we both agree I don't handle the case of very large > addressbooks very well :-/ Yes, this discussion is not pointless :-). And at the end if you are more comfortable with libraries of C functions th= an=20 with subclassing and virtual functions, it's no problem. After all, it's yo= u=20 who are going to be doing the dirty work (and I think we all thank you for= =20 that!). =2D-=20 Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m=C3=A9dire." (Le concombre masqu=C3=A9, Mandriva) From jpuydt@free.fr Sat Jun 17 15:09:04 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2976B3B0144 for ; Sat, 17 Jun 2006 15:09:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04217-02 for ; Sat, 17 Jun 2006 15:08:59 -0400 (EDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by menubar.gnome.org (Postfix) with ESMTP id BC2893B019D for ; Sat, 17 Jun 2006 15:07:46 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-c.free.fr (Postfix) with ESMTP id 4C9DC1D0C42D for ; Sat, 17 Jun 2006 20:06:22 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-57-82-249-55-125.adsl.proxad.net [82.249.55.125]) by smtp5-g19.free.fr (Postfix) with ESMTP id B65BC26C83 for ; Sat, 17 Jun 2006 21:05:51 +0200 (CEST) Message-ID: <4494528F.2040804@free.fr> Date: Sat, 17 Jun 2006 21:05:51 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <200606152026.49639.ebischoff@nerim.net> <4491C708.3060203@free.fr> <200606171123.00082.ebischoff@nerim.net> In-Reply-To: <200606171123.00082.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.584 tagged_above=-999 required=2 tests=[AWL=0.015, BAYES_00=-2.599] X-Spam-Score: -2.584 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 19:09:04 -0000 Éric Bischoff a écrit : >>> Yes. You could have a few spare contacts before and after the user's >>> view. This algorithm is rather common. >> What do "before" and "after" mean ? > > Records just before and after the ones that are displayed in sequential order. Sequential hurts. >>> I know that it cannot be _that_ bad and that I certainly misunderstood >>> something. But what? >> I certainly have issues with big books, and must find some satisfying >> way to handle them. But doing function calls to walk on a list where I >> could get the list and walk it myself directly, is definitely wrong. > > What is wrong is to see that as a list ;-). Indeed. >> If I add a new addressbook type with a Foo capability, your designs says >> I have to modify the base class and add: >> >> bool canDoFoo (); >> void pleaseDoFooThisWay (...); >> void pleaseDoFooThisOtherWay (...); >> void etcFoo (...) >> (with all the virtual pure syntactic crap needed) > > This "crap" is a lightweight modification since it is only one function > declaration. No implementation. That is done in the subclasses, if necessary. Notice that I used "crap" to describe the syntactic need in C++ to add "virtual" and "= 0" everywhere. And your "lightweight modification" still involves modifying the base class anytime a child class needs something! >> My idea of right design is that if the new addressbook is the only one >> needing Foo, it will handle it himself (through a specific api that its >> view and controller will know and use). > > Okay. Perharps the our differences in opinion is not that much on the > programming design, but more on what the software has to do. > > To me, an address book is just an address book, they are not that different > one from the other. Ekiga need to dig through them to show names, categories > and to pick up SIP numbers to call the people. I see a relatively homogeneous > user interface, with more or less the same appearance (if not exactly the > same) for the various address books. I have a "unifying" vision. > > To you, all address books have very strong pecularities and the software has > to adapt a lot to each of them, to take them to the maximum of their > possibilities. The user will get different display, different menues, and > even different functionality. Well, look at what we have to put already in the addressbooks: - evolution-data-server addressbooks ; - avahi contacts ; - history contacts ; - speeddials. And the future holds : - SIP contacts ; - XMPP contacts. > That explains why you want to put everything in the "drivers", while I want to > put a lot of common logic in the "engine". Your high level is what I call low level : it handles all of the details! >> Your view isn't OO, and isn't C++. > > Come on ;-). > >> You see functions named "methods" stuffed into the same poor base class, > > No. Again and again, the base class only has declarations. It sees an > abstraction of what the address book is. You're still stuffing that in the base class, which is awful. Does the QWidget class have all the methods of all its child already declared? > In every C++ book, you can see examples like this > > class vehicle { > virtual void accelerate(int a) = 0; > ... > }; > > class car : public vehicle { > virtual void accelerate(int a); > ... > }; > > class plane : public vehicle { > virtual void accelerate(int a); > ... > }; > Planes and cars have very different ways to accelerate. Planes can't brake and > cars can't fly, but such designs are clean and very popular. They all accelerate, and that is the reason why having an accelerate method is put as a requirement in the base class. Anyway I since made another proposition which I find neater ; I'm eagerly waiting for your comments on it :-) Snark From siti@orcon.net.nz Sat Jun 17 16:21:14 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 166443B02D7 for ; Sat, 17 Jun 2006 16:21:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06960-02 for ; Sat, 17 Jun 2006 16:21:11 -0400 (EDT) Received: from dbmail-mx3.orcon.co.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 420E03B0769 for ; Sat, 17 Jun 2006 16:21:10 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx3.orcon.co.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k5HKBcBi027983 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 18 Jun 2006 08:11:39 +1200 From: Stephen Cook To: GnomeMeeting development mailing list Content-Type: text/plain Date: Sun, 18 Jun 2006 08:11:38 +1200 Message-Id: <1150575098.10433.5.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx3.orcon.co.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.484 tagged_above=-999 required=2 tests=[AWL=-0.020, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.484 X-Spam-Level: Subject: [GnomeMeeting-devel-list] IAX2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 20:21:14 -0000 Hello, It's been a long time I gave you guys an update. In IAX2 in opal I have got music on hold going which is nice :). I will be doing registration next as this is probably the most important feature for users. Also I have not run in to any stability problems with IAX2. My iax2/ekiga integration is working well as a tester with my asterisk server. It basically has all the functionality there but needs more integration and bug/quirky fixes. Also some refactoring in the future would be nice depending if I get time or not... From jan.schampera@web.de Sat Jun 17 23:26:05 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 973DD3B0089 for ; Sat, 17 Jun 2006 23:26:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21686-02 for ; Sat, 17 Jun 2006 23:26:04 -0400 (EDT) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by menubar.gnome.org (Postfix) with ESMTP id 718E83B0080 for ; Sat, 17 Jun 2006 23:26:04 -0400 (EDT) Received: from fwd28.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1Frm9f-0005mL-03; Sun, 18 Jun 2006 03:32:47 +0200 Received: from mail.home.thebonsai.de (Ee3Yp-Z-ge9I5Mahsz3ULnxaW3DaPSfdXF9f7jCM5sjCj+WYBVPHwg@[84.147.75.32]) by fwd28.sul.t-online.de with esmtp id 1Frm9c-1vtsA40; Sun, 18 Jun 2006 03:32:44 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id 610F16B154 for ; Sun, 18 Jun 2006 03:32:43 +0200 (CEST) Date: Sun, 18 Jun 2006 03:32:42 +0200 From: Jan Schampera To: gnomemeeting-devel-list@gnome.org Message-ID: <20060618033242.5cce3d15@localhost.localdomain> In-Reply-To: <4493AA32.5030602@free.fr> References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> <4493AA32.5030602@free.fr> Organization: private X-Mailer: Sylpheed-Claws 2.2.0 (GTK+ 2.8.18; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: Ee3Yp-Z-ge9I5Mahsz3ULnxaW3DaPSfdXF9f7jCM5sjCj+WYBVPHwg@t-dialin.net X-TOI-MSGID: d12d82d7-adb7-47a8-a0ce-a3a4ced5117e X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.982 tagged_above=-999 required=2 tests=[AWL=0.616, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.982 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 03:26:05 -0000 On Sat, 17 Jun 2006 09:07:30 +0200 Julien PUYDT wrote: > 1) a book can return a view for itself, which means the view becomes > specific, and hence can handle the case of big addressbooks ; And which view would such a book return by default? > 2) a full search function, which will return a new book, restricted > to the the search ; again this book has its view, which will handle > the case of big searches ; ACK > 3) a restricted search function, which will return say at most a > hundred contacts matching the string ; this one allows to make a > search on all the books, since we are assured we won't be drowned by > the number. > Does that looks nicer ? Yip. J. -- God is real... unless declared as integer. From jpuydt@free.fr Sun Jun 18 06:22:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8B7533B09FC for ; Sun, 18 Jun 2006 06:22:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18409-03 for ; Sun, 18 Jun 2006 06:22:08 -0400 (EDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by menubar.gnome.org (Postfix) with ESMTP id 03CAF3B0956 for ; Sun, 18 Jun 2006 06:22:07 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-c.free.fr (Postfix) with ESMTP id B13A21D0A67F for ; Sun, 18 Jun 2006 11:20:11 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-30-82-253-152-157.adsl.proxad.net [82.253.152.157]) by smtp5-g19.free.fr (Postfix) with ESMTP id 8697F270B8 for ; Sun, 18 Jun 2006 12:19:37 +0200 (CEST) Message-ID: <449528BF.3020104@free.fr> Date: Sun, 18 Jun 2006 12:19:43 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> <4493AA32.5030602@free.fr> <20060618033242.5cce3d15@localhost.localdomain> In-Reply-To: <20060618033242.5cce3d15@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 10:22:10 -0000 Jan Schampera a écrit : >> 1) a book can return a view for itself, which means the view becomes >> specific, and hence can handle the case of big addressbooks ; > And which view would such a book return by default? No default view. I think there should be a GmFullBook class (from which all books which can be displayed fully), and an associated GmFullBookView class, which would then be default for the children. >> Does that looks nicer ? > Yip. Nice. I'm writing some code to showcase things... may take long since I lack time those days :-/ Snark From dsandras@seconix.com Sun Jun 18 15:32:22 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 425673B0114 for ; Sun, 18 Jun 2006 15:32:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08600-02 for ; Sun, 18 Jun 2006 15:32:19 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 178373B0009 for ; Sun, 18 Jun 2006 15:32:18 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id EF61583C26 for ; Sun, 18 Jun 2006 21:11:21 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03870-02 for ; Sun, 18 Jun 2006 21:11:15 +0200 (CEST) Received: from [192.168.0.161] (206-158.242.81.adsl.skynet.be [81.242.158.206]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 657C683C23 for ; Sun, 18 Jun 2006 21:11:15 +0200 (CEST) From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <1150575098.10433.5.camel@siti> References: <1150575098.10433.5.camel@siti> Content-Type: text/plain; charset=ISO-8859-15 Date: Sun, 18 Jun 2006 21:31:27 +0200 Message-Id: <1150659087.2477.3.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.256 tagged_above=-999 required=2 tests=[AWL=0.208, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.256 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] IAX2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 19:32:22 -0000 Le dimanche 18 juin 2006 à 08:11 +1200, Stephen Cook a écrit : > Hello, > > It's been a long time I gave you guys an update. > > In IAX2 in opal I have got music on hold going which is nice :). I will > be doing registration next as this is probably the most important > feature for users. Also I have not run in to any stability problems > with IAX2. > > My iax2/ekiga integration is working well as a tester with my asterisk > server. It basically has all the functionality there but needs more > integration and bug/quirky fixes. Also some refactoring in the future > would be nice depending if I get time or not... Hi, I've seen Derek committed some code from you. I think it is important that you keep a repository with your patches so that we really know what you have fixed/added for Google SoC. (Actually, I should see the patches, even though it is perfectly acceptable that Derek commits them). Thank you, -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From gcgagd-gnomemeeting-devel-list@m.gmane.org Sun Jun 18 16:15:08 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8DDA23B0114 for ; Sun, 18 Jun 2006 16:15:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09248-09 for ; Sun, 18 Jun 2006 16:15:07 -0400 (EDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by menubar.gnome.org (Postfix) with ESMTP id 662BD3B00B2 for ; Sun, 18 Jun 2006 16:15:07 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Fs3eO-0006gT-LO for gnomemeeting-devel-list@gnome.org; Sun, 18 Jun 2006 22:13:40 +0200 Received: from jupiter.physics.ubc.ca ([142.103.234.78]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Jun 2006 22:13:40 +0200 Received: from johan_brn by jupiter.physics.ubc.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Jun 2006 22:13:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gnomemeeting-devel-list@gnome.org From: Johan Brannlund Date: Sun, 18 Jun 2006 13:13:29 -0700 Lines: 22 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: jupiter.physics.ubc.ca User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux)) Sender: news X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.752 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_YAHOO_RCVD=1.849, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.752 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Main window size X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 20:15:08 -0000 I posted the below as a wishlist bug, but apparently the developers prefer carrying out the discussion on this mailing list. This is what I wrote: "I just tried the 20060615 cvs snapshot of ekiga, and it's getting better all the time. I have a small request though: I don't use video, which means that the main window is much bigger than it has to be. Would it be possible to add a resizing widget, or to automatically make the window smaller when video is disabled?" Damien also added the following comment: "I would also say that it will look less bigger when having a contacts list. :) " ... which I don't quite understand. At least in my snapshot, the contacts are in a separate window. Regards, Johan From siti@orcon.net.nz Sun Jun 18 21:23:06 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 415B73B0387 for ; Sun, 18 Jun 2006 21:23:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18559-06 for ; Sun, 18 Jun 2006 21:23:01 -0400 (EDT) Received: from dbmail-mx2.orcon.net.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 66E1B3B0196 for ; Sun, 18 Jun 2006 21:23:01 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx2.orcon.net.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k5J1Lujn017301 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 19 Jun 2006 13:21:57 +1200 From: Stephen Cook To: GnomeMeeting development mailing list In-Reply-To: <1150659087.2477.3.camel@golgoth01> References: <1150575098.10433.5.camel@siti> <1150659087.2477.3.camel@golgoth01> Content-Type: text/plain; charset=utf-8 Date: Mon, 19 Jun 2006 13:21:55 +1200 Message-Id: <1150680115.31741.1.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx2.orcon.net.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.547 tagged_above=-999 required=2 tests=[AWL=0.052, BAYES_00=-2.599] X-Spam-Score: -2.547 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] IAX2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 01:23:06 -0000 On Sun, 2006-06-18 at 21:31 +0200, Damien Sandras wrote: > Le dimanche 18 juin 2006 à 08:11 +1200, Stephen Cook a écrit : > > Hello, > > > > It's been a long time I gave you guys an update. > > > > In IAX2 in opal I have got music on hold going which is nice :). I will > > be doing registration next as this is probably the most important > > feature for users. Also I have not run in to any stability problems > > with IAX2. > > > > My iax2/ekiga integration is working well as a tester with my asterisk > > server. It basically has all the functionality there but needs more > > integration and bug/quirky fixes. Also some refactoring in the future > > would be nice depending if I get time or not... > > Hi, > > > I've seen Derek committed some code from you. > > I think it is important that you keep a repository with your patches so > that we really know what you have fixed/added for Google SoC. > (Actually, I should see the patches, even though it is perfectly > acceptable that Derek commits them). I'll try and get you to review them first. I'll also put the patches on my website and give you guys a link soon. > > Thank you, From jpuydt@free.fr Mon Jun 19 01:26:43 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E9CF83B09E1 for ; Mon, 19 Jun 2006 01:26:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25898-10 for ; Mon, 19 Jun 2006 01:26:41 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 737143B03C7 for ; Mon, 19 Jun 2006 01:26:41 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-60-82-254-197-114.adsl.proxad.net [82.254.197.114]) by smtp1-g19.free.fr (Postfix) with ESMTP id C5B1D10170 for ; Mon, 19 Jun 2006 07:25:07 +0200 (CEST) Message-ID: <44963539.6080309@free.fr> Date: Mon, 19 Jun 2006 07:25:13 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.567 tagged_above=-999 required=2 tests=[AWL=0.032, BAYES_00=-2.599] X-Spam-Score: -2.567 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Main window size X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 05:26:43 -0000 Johan Brannlund a écrit : > I posted the below as a wishlist bug, but apparently the developers prefer > carrying out the discussion on this mailing list. This is what I wrote: Well, bug reports are nice for a beta or a stable release ; during the development cycle, discussing on the -devel- mailing-list is better (especially right at the beginning). :-) > "I just tried the 20060615 cvs snapshot of ekiga, and it's getting better > all the time. I have a small request though: I don't use video, which > means that the main window is much bigger than it has to be. > > Would it be possible to add a resizing widget, or to automatically make the > window smaller when video is disabled?" > > Damien also added the following comment: > > "I would also say that it will look less bigger when having a contacts > list. :) " > > ... which I don't quite understand. At least in my snapshot, the contacts > are in a separate window. He means that you should see some of your contacts in the main window in the future, with presence information about them. Snark From dsandras@seconix.com Mon Jun 19 04:55:21 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 539283B00A5 for ; Mon, 19 Jun 2006 04:55:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01183-02 for ; Mon, 19 Jun 2006 04:55:13 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id CCC843B0004 for ; Mon, 19 Jun 2006 04:55:11 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id D5FC083C1F for ; Mon, 19 Jun 2006 10:34:14 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32316-06 for ; Mon, 19 Jun 2006 10:34:11 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 694B183C1A for ; Mon, 19 Jun 2006 10:34:11 +0200 (CEST) From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44963539.6080309@free.fr> References: <44963539.6080309@free.fr> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 19 Jun 2006 10:54:04 +0200 Message-Id: <1150707244.2904.2.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Main window size X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 08:55:21 -0000 Le lundi 19 juin 2006 à 07:25 +0200, Julien PUYDT a écrit : > Johan Brannlund a écrit : > > I posted the below as a wishlist bug, but apparently the developers prefer > > carrying out the discussion on this mailing list. This is what I wrote: > > Well, bug reports are nice for a beta or a stable release ; during the > development cycle, discussing on the -devel- mailing-list is better > (especially right at the beginning). :-) > Yes, because it is a work in progress. So it will change with time, and get improved. No worries :) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From firstone5@hotmail.com Wed Jun 21 13:09:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C9A9D3B02A4 for ; Wed, 21 Jun 2006 13:09:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23702-03 for ; Wed, 21 Jun 2006 13:09:09 -0400 (EDT) Received: from hotmail.com (bay101-f15.bay101.hotmail.com [64.4.56.25]) by menubar.gnome.org (Postfix) with ESMTP id C2B763B01C1 for ; Wed, 21 Jun 2006 13:09:09 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Jun 2006 10:09:08 -0700 Message-ID: Received: from 64.4.56.200 by by101fd.bay101.hotmail.msn.com with HTTP; Wed, 21 Jun 2006 17:09:07 GMT X-Originating-IP: [69.245.3.192] X-Originating-Email: [firstone5@hotmail.com] X-Sender: firstone5@hotmail.com From: "M. Renee Hopkins" To: gnomemeeting-devel-list@gnome.org Date: Wed, 21 Jun 2006 17:09:07 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 21 Jun 2006 17:09:08.0863 (UTC) FILETIME=[68BD40F0:01C69555] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=0.607 tagged_above=-999 required=2 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: 0.607 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Mingw build of CVS ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:09:11 -0000 Greetings all, I am now building ekiga from cvs with the mingw tools on linux with some success, thanks to help from the list developers and patches. Most all features seem to be working. However, my builds don't detect the videoforwindows devices even though other ekiga.exe (not mine) versions correctly see the camera. Any ideas for missing switches on compile before I began greping through pwlib? I'm rather new to the code so any help is appreciated. Congrads to all developers on great work, MR From dsandras@seconix.com Wed Jun 21 13:42:37 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C742A3B05E9 for ; Wed, 21 Jun 2006 13:42:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25791-05 for ; Wed, 21 Jun 2006 13:42:36 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 0647C3B00B0 for ; Wed, 21 Jun 2006 13:42:35 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id AC0EF83C1C for ; Wed, 21 Jun 2006 19:22:12 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05950-02 for ; Wed, 21 Jun 2006 19:22:11 +0200 (CEST) Received: from [192.168.0.161] (185.1-247-81.adsl-dyn.isp.belgacom.be [81.247.1.185]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id C5DD783C1B for ; Wed, 21 Jun 2006 19:22:10 +0200 (CEST) From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-15 Date: Wed, 21 Jun 2006 19:43:29 +0200 Message-Id: <1150911809.2537.7.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.461 tagged_above=-999 required=2 tests=[AWL=0.003, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.461 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Mingw build of CVS ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:42:38 -0000 Le mercredi 21 juin 2006 à 17:09 +0000, M. Renee Hopkins a écrit : > Greetings all, > > I am now building ekiga from cvs with the mingw tools on linux with some > success, thanks to help from the list developers and patches. > > Most all features seem to be working. However, my builds don't detect the > videoforwindows devices even though other ekiga.exe (not mine) versions > correctly see the camera. > > Any ideas for missing switches on compile before I began greping through > pwlib? > I'm not an expert of the win32 build, but the first guess would be that the pwlib plugins are not compiled in. > I'm rather new to the code so any help is appreciated. > > Congrads to all developers on great work, > MR > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Thu Jun 1 02:40:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F28C93B00EB for ; Thu, 1 Jun 2006 02:40:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10407-03 for ; Thu, 1 Jun 2006 02:40:07 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 9FA173B00CB for ; Thu, 1 Jun 2006 02:40:06 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id DE1A2496FC for ; Thu, 1 Jun 2006 08:23:55 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15636-08 for ; Thu, 1 Jun 2006 08:23:54 +0200 (CEST) Received: from [172.16.100.156] (tcts.fpms.ac.be [193.190.194.194]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 0CBC0496FB for ; Thu, 1 Jun 2006 08:23:54 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <447DF183.3090300@cs.stanford.edu> References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-15 Date: Thu, 01 Jun 2006 08:41:01 +0200 Message-Id: <1149144061.2457.4.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 06:40:10 -0000 Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > I'd imagine it would work on win32, but don't know. > Probably. > I'll work on the patches. > > Where's the right place to add required libraries like openGL? In configure.in. > configure.in seems to be autogenerated by something, but whatever it is > doesn't seem to be in the CVS snapshot... > configure.in is in the CVS snapshot. > Thanks, > > -Dan > > Julien PUYDT wrote: > > > Dan Sandberg a écrit : > > > >> How should we proceed? I could just send you an updated gui/main.cpp > >> file... > > > > > > I'd like to see patches instead of full files, preferably independant > > on each others. > > > > There's also the question of the portability of this : since you > > mention SDL, I guess this will work great on win32 too ? > > > > Snark > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From hoglet@solit.se Thu Jun 1 09:09:47 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 90B2B3B017F for ; Thu, 1 Jun 2006 09:09:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04710-03 for ; Thu, 1 Jun 2006 09:09:45 -0400 (EDT) Received: from aurian.solit.se (unknown [82.182.216.174]) by menubar.gnome.org (Postfix) with ESMTP id 63B703B0134 for ; Thu, 1 Jun 2006 09:09:45 -0400 (EDT) Received: from ip76.kassjo.se ([85.11.28.76] helo=localhost.localdomain) by aurian.solit.se with asmtp (Exim 3.35 #1 (Debian)) id 1Flmvj-0004Et-00 for ; Thu, 01 Jun 2006 15:09:39 +0200 Date: Thu, 1 Jun 2006 15:09:38 +0200 From: Kent Asplund To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Re: Ekiga branched Message-Id: <20060601150938.fcdea791.hoglet@solit.se> In-Reply-To: <1148209984.2488.26.camel@golgoth01> References: <1147894199.7225.2.camel@golgoth01> <1148207277.6654.0.camel@frobisher.madeley.id.au> <1148209984.2488.26.camel@golgoth01> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: ej spam, SpamAssassin (resultat=-4.4, krav 5, IN_REP_TO -4.43) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.832 tagged_above=-999 required=2 tests=[AWL=-0.510, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142] X-Spam-Score: -1.832 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:09:47 -0000 --Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 21 May 2006 13:13:04 +0200 Damien Sandras wrote: > Le dimanche 21 mai 2006 =E0 18:27 +0800, Davyd Madeley a =E9crit : > > On Wed, 2006-05-17 at 21:29 +0200, Damien Sandras wrote: > >=20 > > > I have created a new branch named "gnome-2-14" for Ekiga from the > > > current CVS HEAD. > >=20 > > What are your exciting plans for the next Ekiga? > >=20 >=20 > Most of the plans are on http://wiki.ekiga.org, but I would summarize it > by those big features : > - New user interface I have some problems selling Ekiga to my wife an mother-in-law because it lacks the list of contacts you are about to implement. Another detail is the "contact" button that they did not see as intuitive. Exchanging the button to a green phone handle (red when calling in progress) would make it more alike others and therefore easier to accept. Greetings /Kent --=20 Killing time murders opportunities. --Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEfucS4WZLcIH5l3kRAm+MAJ95cAJ7mAiuBBLrCdfk7vNFTiLv7ACeKWZd 6tzVdWbow84O8RfCFvm51AU= =lD5w -----END PGP SIGNATURE----- --Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ-- From jpuydt@free.fr Thu Jun 1 09:20:42 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 792AE3B01C4 for ; Thu, 1 Jun 2006 09:20:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05042-09 for ; Thu, 1 Jun 2006 09:20:38 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 505C93B01E3 for ; Thu, 1 Jun 2006 09:20:37 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-30-82-253-132-170.adsl.proxad.net [82.253.132.170]) by smtp1-g19.free.fr (Postfix) with ESMTP id DA3499ADFF for ; Thu, 1 Jun 2006 15:20:35 +0200 (CEST) Message-ID: <447EE9BE.5030005@free.fr> Date: Thu, 01 Jun 2006 15:21:02 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Re: Ekiga branched References: <1147894199.7225.2.camel@golgoth01> <1148207277.6654.0.camel@frobisher.madeley.id.au> <1148209984.2488.26.camel@golgoth01> <20060601150938.fcdea791.hoglet@solit.se> In-Reply-To: <20060601150938.fcdea791.hoglet@solit.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599] X-Spam-Score: -2.561 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:20:42 -0000 Kent Asplund a écrit : > Exchanging the button to a green phone handle (red when calling in > progress) would make it more alike others and therefore easier to > accept. The classic case of "your flying car lacks a spare wheel!" ;-) Snark From jan.schampera@web.de Thu Jun 1 12:03:48 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B922E3B0E4B for ; Thu, 1 Jun 2006 12:03:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18635-04 for ; Thu, 1 Jun 2006 12:03:47 -0400 (EDT) Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by menubar.gnome.org (Postfix) with ESMTP id EBE813B0E61 for ; Thu, 1 Jun 2006 12:01:39 -0400 (EDT) Received: from fwd29.aul.t-online.de by mailout05.sul.t-online.com with smtp id 1FlpcA-0003xH-07; Thu, 01 Jun 2006 18:01:38 +0200 Received: from mail.home.thebonsai.de (VypBOcZSYex2PaURfsq4FLxwkOKh2FKpRdjn4Nur7iMG3ImbsTH1w4@[84.147.102.147]) by fwd29.sul.t-online.de with esmtp id 1FlpO1-0yxMBM0; Thu, 1 Jun 2006 17:47:01 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id E08C06B173 for ; Thu, 1 Jun 2006 17:47:00 +0200 (CEST) Date: Thu, 1 Jun 2006 17:44:27 +0200 From: Jan Schampera To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode Message-ID: <20060601174427.48266dee@localhost.localdomain> In-Reply-To: <447DE4E2.7040204@cs.stanford.edu> References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> Organization: private X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: VypBOcZSYex2PaURfsq4FLxwkOKh2FKpRdjn4Nur7iMG3ImbsTH1w4@t-dialin.net X-TOI-MSGID: e6494e3b-869b-447f-a832-f769a200d3af X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.942 tagged_above=-999 required=2 tests=[AWL=0.656, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.942 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:03:48 -0000 On Wed, 31 May 2006 11:48:02 -0700 Dan Sandberg wrote: > 2) Replace the SDL/GTK/GDK calls that do the full screen resizing with > OpenGL ones. [ This is done, needs to be integrated ] Guess that's the key I searched for, when I measured those performance problems. Something that is "usually" installed on the user's machines and that has more power then GDK/SDL (I was afraid to raise yet another exotic dependancy, but OpenGL seems fair enough). J. -- "Be liberal in what you accept, and conservative in what you send." - J. B. Postel, master of the net. From siti@orcon.net.nz Fri Jun 2 05:53:55 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5C8803B10AE for ; Fri, 2 Jun 2006 05:53:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15897-03 for ; Fri, 2 Jun 2006 05:53:53 -0400 (EDT) Received: from dbmail-mx4.orcon.co.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 1A8E13B0EB6 for ; Fri, 2 Jun 2006 05:53:52 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx4.orcon.co.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k529rnLs032645 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 2 Jun 2006 21:53:50 +1200 From: Stephen Cook To: GnomeMeeting development mailing list Content-Type: text/plain Date: Fri, 02 Jun 2006 21:55:24 +1200 Message-Id: <1149242124.4509.17.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.2/1506/Fri Jun 2 16:01:20 2006 on dbmail-mx4.orcon.co.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: Subject: [GnomeMeeting-devel-list] IAX2 In Ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 09:53:55 -0000 Hi, I haven't introduced myself here before, I am Stephen Cook (siti). My proposal for implementing IAX2 in ekiga got accepted with google's summer of code. To give an update (I'll try and keep you guys regularly posted as to what's happening, any problems etc.). Currently I have been looking at the code to gain an understanding of ekiga and opal's code and design. Also obviously checking out the IAX2 code in opal :). From what I have seen and got working, I will work on getting IAX2 going in ekiga first. The main part of this will obviously involve writing a gnome meeting endpoint for IAX2. One key problem I have identified is the accounts code. The protocols are tightly integrated with how it works. I could either refactor this code to loosen the integration or hack iax2 support in there and refactor it later ;). The advantage of this refactored will be when someone wants to add Xmpp/libjingle support, or some other protocol down the track. Well, please tell me your thoughts and comments on this project. -Stephen From x@cs.stanford.edu Fri Jun 2 06:04:24 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0CBE83B0EB6 for ; Fri, 2 Jun 2006 06:04:24 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16680-02 for ; Fri, 2 Jun 2006 06:04:22 -0400 (EDT) Received: from smtp102.plus.mail.mud.yahoo.com (smtp102.plus.mail.mud.yahoo.com [68.142.206.235]) by menubar.gnome.org (Postfix) with SMTP id 1A3583B0490 for ; Fri, 2 Jun 2006 06:04:22 -0400 (EDT) Received: (qmail 57482 invoked from network); 2 Jun 2006 10:04:21 -0000 Received: from unknown (HELO ?192.168.2.47?) (dan?sandberg@71.138.128.214 with plain) by smtp102.plus.mail.mud.yahoo.com with SMTP; 2 Jun 2006 10:04:20 -0000 Message-ID: <44800CFA.5090800@cs.stanford.edu> Date: Fri, 02 Jun 2006 03:03:38 -0700 From: Dan Sandberg User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> In-Reply-To: <1149144061.2457.4.camel@golgoth01> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.808 tagged_above=-999 required=2 tests=[AWL=-0.593, BAYES_00=-2.599, SPF_SOFTFAIL=1.384] X-Spam-Score: -1.808 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 10:04:24 -0000 So configure.in is hand-generated? Surprising. 1) How exactly do I add the opengl ( libgl ) library? 2) Xrandr is mentioned in the Makefile, but is not in configure.in. How exactly does it get put into the Makefile? 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I didn't want to code against a moving target. Thanks, -Dan Damien Sandras wrote: >Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > > >>I'd imagine it would work on win32, but don't know. >> >> >> > >Probably. > > > >>I'll work on the patches. >> >>Where's the right place to add required libraries like openGL? >> >> > >In configure.in. > > > >>configure.in seems to be autogenerated by something, but whatever it is >>doesn't seem to be in the CVS snapshot... >> >> >> > >configure.in is in the CVS snapshot. > > > > >>Thanks, >> >>-Dan >> >>Julien PUYDT wrote: >> >> >> >>>Dan Sandberg a écrit : >>> >>> >>> >>>>How should we proceed? I could just send you an updated gui/main.cpp >>>>file... >>>> >>>> >>>I'd like to see patches instead of full files, preferably independant >>>on each others. >>> >>>There's also the question of the portability of this : since you >>>mention SDL, I guess this will work great on win32 too ? >>> >>>Snark >>>_______________________________________________ >>>Gnomemeeting-devel-list mailing list >>>Gnomemeeting-devel-list@gnome.org >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list >>> >>> >>> >>_______________________________________________ >>Gnomemeeting-devel-list mailing list >>Gnomemeeting-devel-list@gnome.org >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list >> >> From dsandras@seconix.com Fri Jun 2 07:06:22 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9B2253B0407 for ; Fri, 2 Jun 2006 07:06:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20694-02 for ; Fri, 2 Jun 2006 07:06:20 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 830933B0490 for ; Fri, 2 Jun 2006 07:06:20 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 3567C4974A for ; Fri, 2 Jun 2006 12:49:55 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03852-06 for ; Fri, 2 Jun 2006 12:49:51 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 5D9BD49749 for ; Fri, 2 Jun 2006 12:49:51 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <1149242124.4509.17.camel@siti> References: <1149242124.4509.17.camel@siti> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 02 Jun 2006 13:06:14 +0200 Message-Id: <1149246374.2966.25.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:06:22 -0000 Le vendredi 02 juin 2006 à 21:55 +1200, Stephen Cook a écrit : > Hi, > > I haven't introduced myself here before, I am Stephen Cook (siti). My > proposal for implementing IAX2 in ekiga got accepted with google's > summer of code. > > To give an update (I'll try and keep you guys regularly posted as to > what's happening, any problems etc.). > > Currently I have been looking at the code to gain an understanding of > ekiga and opal's code and design. Also obviously checking out the IAX2 > code in opal :). From what I have seen and got working, I will work on > getting IAX2 going in ekiga first. The main part of this will obviously > involve writing a gnome meeting endpoint for IAX2. > I would say that the main part will be to write / finish the IAX2 code in OPAL, either new code, or reusing the current code so that all features that you see in SIP and H.323 are also available for IAX2. Your first project will be to look the limitations of the current code and write a document showing what features you have tested, what work is required to complete them, and what new work is required for new features (Call Hold, Call Transfer, Registering, Call Forward, ...). Writing the endpoint in Ekiga is the last part of the project once the code in OPAL is full functional. Ekiga only contains high-level code. > One key problem I have identified is the accounts code. The protocols > are tightly integrated with how it works. I could either refactor this > code to loosen the integration or hack iax2 support in there and > refactor it later ;). The advantage of this refactored will be when > someone wants to add Xmpp/libjingle support, or some other protocol down > the track. > I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and finally perhaps to a refactoring of the accounts code as it is not the primary purpose of the Google SoC :) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Fri Jun 2 07:08:01 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 243E83B0407 for ; Fri, 2 Jun 2006 07:08:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20781-05 for ; Fri, 2 Jun 2006 07:07:58 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 6C7333B10B6 for ; Fri, 2 Jun 2006 07:07:58 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 5426B49753 for ; Fri, 2 Jun 2006 12:51:33 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06419-06 for ; Fri, 2 Jun 2006 12:51:18 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id EF0D549750 for ; Fri, 2 Jun 2006 12:51:17 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44800CFA.5090800@cs.stanford.edu> References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 02 Jun 2006 13:07:41 +0200 Message-Id: <1149246461.2966.28.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:08:01 -0000 Le vendredi 02 juin 2006 à 03:03 -0700, Dan Sandberg a écrit : > So configure.in is hand-generated? Surprising. > That's te way it works. You write configure.in and configure is generated from there. I guess you are confusing things here. > 1) How exactly do I add the opengl ( libgl ) library? > By writing autconf code in configure.in. No idea exactly how it should be done. > 2) Xrandr is mentioned in the Makefile, but is not in configure.in. How > exactly does it get put into the Makefile? > Probably by an external library that we are using. > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I didn't want > to code against a moving target. > Yes. It is even OK if you do not provide the configure.in code, but only the OpenGL Ekiga code. > Thanks, > > -Dan > > Damien Sandras wrote: > > >Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > > > > > >>I'd imagine it would work on win32, but don't know. > >> > >> > >> > > > >Probably. > > > > > > > >>I'll work on the patches. > >> > >>Where's the right place to add required libraries like openGL? > >> > >> > > > >In configure.in. > > > > > > > >>configure.in seems to be autogenerated by something, but whatever it is > >>doesn't seem to be in the CVS snapshot... > >> > >> > >> > > > >configure.in is in the CVS snapshot. > > > > > > > > > >>Thanks, > >> > >>-Dan > >> > >>Julien PUYDT wrote: > >> > >> > >> > >>>Dan Sandberg a écrit : > >>> > >>> > >>> > >>>>How should we proceed? I could just send you an updated gui/main.cpp > >>>>file... > >>>> > >>>> > >>>I'd like to see patches instead of full files, preferably independant > >>>on each others. > >>> > >>>There's also the question of the portability of this : since you > >>>mention SDL, I guess this will work great on win32 too ? > >>> > >>>Snark > >>>_______________________________________________ > >>>Gnomemeeting-devel-list mailing list > >>>Gnomemeeting-devel-list@gnome.org > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > >>> > >>> > >>> > >>_______________________________________________ > >>Gnomemeeting-devel-list mailing list > >>Gnomemeeting-devel-list@gnome.org > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > >> > >> > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From jpuydt@free.fr Fri Jun 2 09:55:37 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 35E163B0A0B for ; Fri, 2 Jun 2006 09:55:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30481-03 for ; Fri, 2 Jun 2006 09:55:35 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id DF18F3B0468 for ; Fri, 2 Jun 2006 09:55:34 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-30-82-253-132-170.adsl.proxad.net [82.253.132.170]) by smtp6-g19.free.fr (Postfix) with ESMTP id D0F23225C9 for ; Fri, 2 Jun 2006 15:55:31 +0200 (CEST) Message-ID: <44804375.6090107@free.fr> Date: Fri, 02 Jun 2006 15:56:05 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga References: <1149242124.4509.17.camel@siti> <1149246374.2966.25.camel@golgoth01> In-Reply-To: <1149246374.2966.25.camel@golgoth01> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599] X-Spam-Score: -2.561 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 13:55:37 -0000 Damien Sandras a écrit : > I would say that the main part will be to write / finish the IAX2 code > in OPAL, either new code, or reusing the current code so that all > features that you see in SIP and H.323 are also available for IAX2. > > Your first project will be to look the limitations of the current code > and write a document showing what features you have tested, what work is > required to complete them, and what new work is required for new > features (Call Hold, Call Transfer, Registering, Call Forward, ...). > > Writing the endpoint in Ekiga is the last part of the project once the > code in OPAL is full functional. Ekiga only contains high-level code. I don't fully agree with you: writing low-level code all summer long then finally writing the upper-level code, will lead to a non-working feature :-/ Having a least minimal functionality in ekiga would be nice to test the low-level regularly, and see it improving. >> One key problem I have identified is the accounts code. The protocols >> are tightly integrated with how it works. I could either refactor this >> code to loosen the integration or hack iax2 support in there and >> refactor it later ;). The advantage of this refactored will be when >> someone wants to add Xmpp/libjingle support, or some other protocol down >> the track. > > I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and > finally perhaps to a refactoring of the accounts code as it is not the > primary purpose of the Google SoC :) Indeed, the purpose is the IAX2 support, not refactoring the code. I would say that hardcoding the IAX2 account setup in the code would be enough for the SoC. Making it work in the ui in the accounts would be bonus if you had the time, or would be a work to do afterwards. Snark From dsandras@seconix.com Fri Jun 2 10:34:17 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C28113B045D for ; Fri, 2 Jun 2006 10:34:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00352-08 for ; Fri, 2 Jun 2006 10:34:16 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id CE7FF3B0478 for ; Fri, 2 Jun 2006 10:34:15 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 0EFE1496C7 for ; Fri, 2 Jun 2006 16:17:49 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08222-10 for ; Fri, 2 Jun 2006 16:17:42 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 3C897496C6 for ; Fri, 2 Jun 2006 16:17:42 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44804375.6090107@free.fr> References: <1149242124.4509.17.camel@siti> <1149246374.2966.25.camel@golgoth01> <44804375.6090107@free.fr> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 02 Jun 2006 16:34:27 +0200 Message-Id: <1149258867.8383.10.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 14:34:17 -0000 Le vendredi 02 juin 2006 à 15:56 +0200, Julien PUYDT a écrit : > Damien Sandras a écrit : > > I would say that the main part will be to write / finish the IAX2 code > > in OPAL, either new code, or reusing the current code so that all > > features that you see in SIP and H.323 are also available for IAX2. > > > > Your first project will be to look the limitations of the current code > > and write a document showing what features you have tested, what work is > > required to complete them, and what new work is required for new > > features (Call Hold, Call Transfer, Registering, Call Forward, ...). > > > > Writing the endpoint in Ekiga is the last part of the project once the > > code in OPAL is full functional. Ekiga only contains high-level code. > > I don't fully agree with you: writing low-level code all summer long > then finally writing the upper-level code, will lead to a non-working > feature :-/ I agree with you, but you can not start writing the EndPoint if there is no code behind it ;) > > Having a least minimal functionality in ekiga would be nice to test the > low-level regularly, and see it improving. > > >> One key problem I have identified is the accounts code. The protocols > >> are tightly integrated with how it works. I could either refactor this > >> code to loosen the integration or hack iax2 support in there and > >> refactor it later ;). The advantage of this refactored will be when > >> someone wants to add Xmpp/libjingle support, or some other protocol down > >> the track. > > > > I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and > > finally perhaps to a refactoring of the accounts code as it is not the > > primary purpose of the Google SoC :) > > Indeed, the purpose is the IAX2 support, not refactoring the code. I > would say that hardcoding the IAX2 account setup in the code would be > enough for the SoC. > > Making it work in the ui in the accounts would be bonus if you had the > time, or would be a work to do afterwards. > Exactly. > Snark > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From t.schorpp@gmx.de Fri Jun 2 11:06:17 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 63A943B02F7 for ; Fri, 2 Jun 2006 11:06:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02214-08 for ; Fri, 2 Jun 2006 11:06:10 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by menubar.gnome.org (Postfix) with SMTP id 7B6603B0421 for ; Fri, 2 Jun 2006 11:06:09 -0400 (EDT) Received: (qmail invoked by alias); 02 Jun 2006 15:06:08 -0000 Received: from p85.212.150.108.tisdip.tiscali.de (EHLO [192.168.1.100]) [85.212.150.108] by mail.gmx.net (mp001) with SMTP; 02 Jun 2006 17:06:08 +0200 X-Authenticated: #17142692 Message-ID: <448053DE.1010406@gmx.de> Date: Fri, 02 Jun 2006 17:06:06 +0200 From: thomas schorpp User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1 X-Accept-Language: de, en-us MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Bad review about Ekiga References: <1148993400.2400.77.camel@golgoth01> In-Reply-To: <1148993400.2400.77.camel@golgoth01> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.476 tagged_above=-999 required=2 tests=[AWL=-0.011, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] X-Spam-Score: -2.476 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: t.schorpp@gmx.de, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 15:06:17 -0000 Damien Sandras wrote: > http://linux.softpedia.com/progViewUserReviews/156167.html > > This software is a descendant of the former "gnome-meeting" software. It > comes bundled with its own SIP service but claims to work with others. > Unfortunately it has inherited not only the GUI from gnome-meeting but > also the habit to crash every other minute without apparent reason. So I > never got to really test it yet. > > The developers might be better off not making the same mistake as they > did with gnome-meeting and should try to fix all the bugs instead of > adding more crashing bells and whistles. Bad? Bad yes: for marketing. You cant just say this commenter were just too stupid to get the right libs together. Bad no: for development. says You need better CM: - suggest the devs and QA people, users, agree on a certain range of gui libs versions. - suggest meeting with distro maintainers and tight the deps found above to avoid lib/binary inconsistencies. - improve exception handling and fault tolerance on the outside interfaces. ? y tom From craigs@postincrement.com Fri Jun 2 19:57:21 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CDB2A3B11E3 for ; Fri, 2 Jun 2006 19:57:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32469-02 for ; Fri, 2 Jun 2006 19:57:18 -0400 (EDT) Received: from bastion.southeren.com (unknown [220.244.81.10]) by menubar.gnome.org (Postfix) with ESMTP id 870583B11CC for ; Fri, 2 Jun 2006 19:57:17 -0400 (EDT) Received: from [10.0.2.13] (rapido.southeren.com [10.0.2.13]) by bastion.southeren.com (8.12.8/8.12.8) with ESMTP id k52NteJG016237; Sat, 3 Jun 2006 09:55:40 +1000 Date: Sat, 03 Jun 2006 09:55:43 +1000 From: Craig Southeren To: Stephen Cook , GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga In-Reply-To: <1149242124.4509.17.camel@siti> References: <1149242124.4509.17.camel@siti> Message-Id: <20060603095331.79CD.CRAIGS@postincrement.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Becky! ver. 2.11.02 [en] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.939 tagged_above=-999 required=2 tests=[AWL=-0.482, BAYES_00=-2.599, SPF_FAIL=1.142] X-Spam-Score: -1.939 X-Spam-Level: Cc: Derek Smithies X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 23:57:22 -0000 On Fri, 02 Jun 2006 21:55:24 +1200 Stephen Cook wrote: > Hi, >=20 > I haven't introduced myself here before, I am Stephen Cook (siti). My > proposal for implementing IAX2 in ekiga got accepted with google's > summer of code. >=20 > To give an update (I'll try and keep you guys regularly posted as to > what's happening, any problems etc.). >=20 > Currently I have been looking at the code to gain an understanding of > ekiga and opal's code and design. Also obviously checking out the IAX2 > code in opal :). From what I have seen and got working, I will work on > getting IAX2 going in ekiga first. The main part of this will obviously > involve writing a gnome meeting endpoint for IAX2. >=20 > One key problem I have identified is the accounts code. The protocols > are tightly integrated with how it works. I could either refactor this > code to loosen the integration or hack iax2 support in there and > refactor it later ;). The advantage of this refactored will be when > someone wants to add Xmpp/libjingle support, or some other protocol down > the track. >=20 > Well, please tell me your thoughts and comments on this project. As a New Zealander, you are uniquely placed to communicate with the author of the OPAL IAX2 code, Derek Smithies, who is a fellow Kiwi! I am sure that you will be able to get the OPAL IAX2 code working with Ekiga in no time at all with his help.=20 If you have any questions, please contact me directly. Craig ----------------------------------------------------------------------- Craig Southeren Post Increment =96 VoIP Consulting and Software craigs@postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren@hotmail.com Mobile: +61 417231046 =20 "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting From hoglet@solit.se Sat Jun 3 03:46:01 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9178F3B04E8 for ; Sat, 3 Jun 2006 03:46:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19488-05 for ; Sat, 3 Jun 2006 03:45:59 -0400 (EDT) Received: from aurian.solit.se (unknown [82.182.216.174]) by menubar.gnome.org (Postfix) with ESMTP id 9DD3C3B0505 for ; Sat, 3 Jun 2006 03:45:59 -0400 (EDT) Received: from ip76.kassjo.se ([85.11.28.76] helo=localhost.localdomain) by aurian.solit.se with asmtp (Exim 3.35 #1 (Debian)) id 1FmQpW-0006J7-00 for ; Sat, 03 Jun 2006 09:45:54 +0200 Date: Sat, 3 Jun 2006 09:45:50 +0200 From: Kent Asplund To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Bad review about Ekiga Message-Id: <20060603094550.0e1ff8aa.hoglet@solit.se> In-Reply-To: <1148993400.2400.77.camel@golgoth01> References: <1148993400.2400.77.camel@golgoth01> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: ej spam, SpamAssassin (resultat=-4.4, krav 5, IN_REP_TO -4.43) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.898 tagged_above=-999 required=2 tests=[AWL=-1.435, BAYES_20=-0.74, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142] X-Spam-Score: -0.898 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 07:46:01 -0000 --Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 30 May 2006 14:50:00 +0200 Damien Sandras wrote: > http://linux.softpedia.com/progViewUserReviews/156167.html >=20 > This software is a descendant of the former "gnome-meeting" software. It > comes bundled with its own SIP service but claims to work with others. > Unfortunately it has inherited not only the GUI from gnome-meeting but > also the habit to crash every other minute without apparent reason. So I > never got to really test it yet. >=20 > The developers might be better off not making the same mistake as they > did with gnome-meeting and should try to fix all the bugs instead of > adding more crashing bells and whistles. I have never had a crash and the program was easy to setup. I have had some problem but they have been outside of Ekiga (siproxd and firewall) Ekiga has som distance to go to "get finished" but it is still THE BEST PROGRAM AROUND! Subjectively of course :) Waiting patiently for 2.2 /Hoglet --=20 Go ahead... make my day. -- Dirty Harry --Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEgT4x4WZLcIH5l3kRApw3AJ9yPgdPoUSeKGniD1w0w0cMTXajRACfWaDG 2YUvSTxFnaSeD8q0uWWv6zE= =2nFl -----END PGP SIGNATURE----- --Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny-- From hoglet@solit.se Sat Jun 3 03:54:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C25A43B05C8 for ; Sat, 3 Jun 2006 03:54:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19755-10 for ; Sat, 3 Jun 2006 03:54:38 -0400 (EDT) Received: from aurian.solit.se (unknown [82.182.216.174]) by menubar.gnome.org (Postfix) with ESMTP id B980A3B04F9 for ; Sat, 3 Jun 2006 03:54:38 -0400 (EDT) Received: from ip76.kassjo.se ([85.11.28.76] helo=localhost.localdomain) by aurian.solit.se with asmtp (Exim 3.35 #1 (Debian)) id 1FmQxt-0006L4-00 for ; Sat, 03 Jun 2006 09:54:33 +0200 Date: Sat, 3 Jun 2006 09:54:33 +0200 From: Kent Asplund To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Re: Ekiga branched Message-Id: <20060603095433.82461abf.hoglet@solit.se> In-Reply-To: <447EE9BE.5030005@free.fr> References: <1147894199.7225.2.camel@golgoth01> <1148207277.6654.0.camel@frobisher.madeley.id.au> <1148209984.2488.26.camel@golgoth01> <20060601150938.fcdea791.hoglet@solit.se> <447EE9BE.5030005@free.fr> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: ej spam, SpamAssassin (resultat=-4.4, krav 5, IN_REP_TO -4.43) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.764 tagged_above=-999 required=2 tests=[AWL=-0.519, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142, TW_KT=0.077] X-Spam-Score: -1.764 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 07:54:39 -0000 --Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 01 Jun 2006 15:21:02 +0200 Julien PUYDT wrote: > Kent Asplund a =E9crit : > > Exchanging the button to a green phone handle (red when calling in > > progress) would make it more alike others and therefore easier to > > accept. >=20 > The classic case of "your flying car lacks a spare wheel!" ;-) I'm taking the risk of seeming to be completely without humour. No, it is more a case of having a car with automatic gearbox and instead of having a lever you have a button for changing direction.=20 It works perfektly OK but people will think that it is a strange car and choose another one. (I think Citro=EBn had this problem) My wife just said "it is made for nerds not humans" Greetings /Hoglet the nerd --=20 I don't know anything about music. In my line you don't have to. -- Elvis Presley --Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEgUA54WZLcIH5l3kRAiYpAJ4/lkEYFVjWRQrYSvn7D9XmkU+6FgCgiejD m2Sp2AVqfZZHzT5TaBCVu5I= =OH96 -----END PGP SIGNATURE----- --Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ-- From devel@tootai.net Sat Jun 3 11:12:15 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3EF583B05AE for ; Sat, 3 Jun 2006 11:12:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11557-03 for ; Sat, 3 Jun 2006 11:12:10 -0400 (EDT) Received: from mail1.tootai.net (ns1.tootai.net [82.231.69.24]) by menubar.gnome.org (Postfix) with ESMTP id A02F63B0348 for ; Sat, 3 Jun 2006 11:12:09 -0400 (EDT) Received: from [192.168.0.17] (unknown [192.168.0.17]) by mail1.tootai.net (Postfix) with ESMTP id E2ACD398BA0 for ; Sat, 3 Jun 2006 17:12:06 +0200 (CEST) Message-ID: <4481A6AF.2060703@tootai.net> Date: Sat, 03 Jun 2006 17:11:43 +0200 From: Daniel Huhardeaux Organization: TOOTAi User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: GnomeMeeting development mailing list Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: Subject: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 15:12:15 -0000 Resent as it didn't pass at the first try (too big, I cut the begining of logs) Hi all, Ekiga behind a firewall is registering to an asterisk server which is on internet. The sip user is authorized with gsm,ulaw,alaw on asterisk side. When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is started, connection is showed with PCMU (why not GSM?), see the traffic in/out (~6 kB) but have no audio. I hangup the call, the hangup info is shown in the toolbar, PCMU disappear in codec and immediately after, traffic in/out continue with 0/0, icon in KDE Toolbar show Ekiga on line. The only solution I have is to kill Ekiga. If I deactivate GSM codec, everything is fine. Below you will find a d4 output from the call. [...] 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 OpalUDP Ended connect, selecting 82.231.69.24:35065 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP Queueing PDU: 1 INVITE <407> 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP Waiting for PDU on udp$213.203.241.243:5060 2006/06/02 13:12:32.901 0:10.661 SIP Handler:8520268 SIP PDU handler thread started. 2006/06/02 13:12:32.902 0:10.662 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:32.902 0:10.663 SIP Handler:8520268 SIP Handling PDU 1 INVITE <407> (with transaction) 2006/06/02 13:12:32.903 0:10.663 SIP Handler:8520268 SIP Transaction 1 INVITE completed. 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP Sending PDU on udp$213.203.241.243:5060 ACK sip:800@sip.tootai.net SIP/2.0 CSeq: 1 ACK Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bK803b125b-96f0-da11-8388-000ea6217592;rport From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: ;tag=as315809c6 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 70 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP Received Proxy Authentication Required response 2006/06/02 13:12:32.906 0:10.666 SIP Handler:8520268 SIP Transaction 2 INVITE created. 2006/06/02 13:12:32.906 0:10.667 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:33.090 0:10.850 SIP Handler:8520268 RTP_UDP Session 1 created: 82.231.69.24:35010-35011 ssrc=703395120 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 RTP Adding session RTP_UDP 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 SIP Using RTP payload [pt=101] for NTE 2006/06/02 13:12:33.100 0:10.860 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k H.261(QCIF) H.261(CIF) YUV420P RGB32 RGB24 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 2 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 2 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 SIP IsMediaBypassPossible: session 2 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:33.281 0:11.041 SIP Handler:8520268 RTP_UDP Session 2 created: 82.231.69.24:35014-35015 ssrc=2454563097 2006/06/02 13:12:33.282 0:11.042 SIP Handler:8520268 RTP Adding session RTP_UDP 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k H.261(QCIF) H.261(CIF) YUV420P RGB32 RGB24 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 SIP Adding authentication information 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP Sending PDU on udp$213.203.241.243:5060 INVITE sip:800@sip.tootai.net SIP/2.0 Date: Fri, 02 Jun 2006 11:12:32 GMT CSeq: 2 INVITE Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;rport User-Agent: Ekiga/2.0.1-20060521-01 From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: Contact: Proxy-Authorization: Digest username="104", realm="sip.tootai.net", nonce="12d01d5d", uri="sip:800@sip.tootai.net", response="60b65ec9045130eab45495d3c65fbc5e", algorithm=md5 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Type: application/sdp Content-Length: 302 Max-Forwards: 70 v=0 o=- 1149246753 1149246753 IN IP4 82.231.69.24 s=Opal SIP Session c=IN IP4 82.231.69.24 t=0 0 m=audio 35010 RTP/AVP 101 3 0 8 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 m=video 35014 RTP/AVP 31 a=rtpmap:31 H261/90000 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP PDU Received on udp$213.203.241.243:5060 SIP/2.0 100 Trying CSeq: 2 INVITE Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 User-Agent: Asterisk PBX From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP Queueing PDU: 2 INVITE <100> 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP Waiting for PDU on udp$213.203.241.243:5060 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP Handling PDU 2 INVITE <100> (with transaction) 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP Transaction 2 INVITE proceeding. 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Set targetAddress to sip:800@213.203.241.243 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Received Trying response 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP Media session port=7166 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP Adding media session with 2 formats 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP Unknown media attribute silenceSupp:off - - - - 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SIP PDU Received on udp$213.203.241.243:5060 SIP/2.0 200 OK CSeq: 2 INVITE Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 User-Agent: Asterisk PBX From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: ;tag=as5d2831d1 Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Type: application/sdp Content-Length: 221 v=0 o=root 26912 26912 IN IP4 213.203.241.243 s=session c=IN IP4 213.203.241.243 t=0 0 m=audio 7166 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP Queueing PDU: 2 INVITE <200> 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP Waiting for PDU on udp$213.203.241.243:5060 2006/06/02 13:12:33.388 0:11.148 SIP Handler:8520268 SIP Handling PDU 2 INVITE <200> (with transaction) 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP Transaction 2 INVITE completed. 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP Set targetAddress to sip:800@213.203.241.243 2006/06/02 13:12:33.390 0:11.150 SIP Handler:8520268 SIP Adding authentication information 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP Adjusting transport to address udp$213.203.241.243:5060 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP Sending PDU on udp$213.203.241.243:5060 ACK sip:800@213.203.241.243 SIP/2.0 CSeq: 2 ACK Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bK6e2ca15b-96f0-da11-8388-000ea6217592;rport From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: ;tag=as5d2831d1 Contact: Proxy-Authorization: Digest username="104", realm="sip.tootai.net", nonce="12d01d5d", uri="sip:800@213.203.241.243", response="059defd67706254552a5c23eada565b5", algorithm=md5 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 70 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP Received INVITE OK response 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 SIP RTP payload type PCMU matched to codec G.711-uLaw-64k 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 OpalCon OpenSourceMediaStream for session 1 on Call[1]-EP[Default] 2006/06/02 13:12:33.398 0:11.158 SIP Handler:8520268 OpalCon Selected media stream PCM-16 -> G.711-uLaw-64k 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 Call PatchMediaStreams Call[1]-EP[Default] 2006/06/02 13:12:34.196 0:11.957 SIP Handler:8520268 OpalCon OpenSinkMediaStream Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session=1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon OpenSinkMediaStream, selected PCM-16 -> G.711-uLaw-64k 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:34.197 0:11.958 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Patch Added sink from PCM-16 Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 16 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 to G.711-uLaw-64k Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 8 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Codec G711-uLaw-64k encoder created 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Patch Added media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k using transcoder PCM-16->G.711-uLaw-64k 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Media Audio source data size set to 320 bytes and 2 buffers. 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call GetOtherPartyConnection Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon OpenSourceMediaStream for session 1 on Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon Selected media stream G.711-uLaw-64k -> PCM-16 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 Call PatchMediaStreams Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon OpenSinkMediaStream Call[1]-EP[Default] session=1 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon OpenSinkMediaStream, selected G.711-uLaw-64k -> PCM-16 2006/06/02 13:12:34.513 0:12.274 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:34.514 0:12.274 SIP Handler:8520268 Patch Added sink from G.711-uLaw-64k Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 8 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 to PCM-16 Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 16 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Codec G711-uLaw-64k decoder created 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Media Audio sink data size set to 320 bytes and 2 buffers. 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Patch Added media stream sink OpalAudioMediaStream-Sink-PCM-16 using transcoder G.711-uLaw-64k->PCM-16 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.525 0:12.285 SIP Handler:8520268 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.527 0:12.287 SIP Handler:8520268 RTP_UDP SetRemoteSocketInfo: session=1 data channel, new=213.203.241.243:7166, local=82.231.69.24:35010-35011, remote=0.0.0.0:0-0 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 SIP Could not find SDP media description for Video 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 OpalMan OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 Call OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 PCSS SetConnected() 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 GMPCSSEndpoint PCSS connection established 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 GMManager Will establish the connection 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 OpalMan OnEstablished Call[1]-EP[Default] 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 Call OnEstablished Call[1]-EP[Default] 2006/06/02 13:12:34.540 0:12.300 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[Default] G.711-uLaw-64k 2006/06/02 13:12:34.541 0:12.301 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k 2006/06/02 13:12:34.542 0:12.302 SIP Handler:8520268 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.543 0:12.303 SIP Handler:8520268 Call OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] G.711-uLaw-64k 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[Default] 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k 2006/06/02 13:12:34.552 0:12.312 SIP Handler:8520268 Call OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k 2006/06/02 13:12:34.553 0:12.313 Media Patch:8175708 Patch Thread started for Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:34.556 0:12.316 SIP Handler:8520268 Media Starting thread Media Patch:8175708 2006/06/02 13:12:34.557 0:12.317 Media Patch:8527348 Patch Thread started for Patch OpalRTPMediaStream-Source-G.711-uLaw-64k -> OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:34.568 0:12.329 Media Patch:8527348 RTP Jitter buffer created: size=101 delay=160-4000/160 (20ms) obj=0x8526b30 2006/06/02 13:12:34.572 0:12.333 RTP Jitter:8526b30 RTP Jitter RTP receive thread started: 0x8526b30 2006/06/02 13:12:34.574 0:12.334 RTP Jitter:8526b30 RTP First receive data: ver=2 pt=GSM psz=33 m=0 x=0 seq=39915 ts=160 src=824302623 ccnt=0 2006/06/02 13:12:34.580 0:12.341 SIP Handler:8520268 Media Starting thread Media Patch:8527348 2006/06/02 13:12:34.581 0:12.341 SIP Handler:8520268 OpalCon Media stream threads started. 2006/06/02 13:12:34.582 0:12.342 SIP Handler:8520268 OpalCon Media stream threads started. 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP Found existing session 2 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 GMManager Will establish the connection 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 OpalMan OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.607 0:12.367 SIP Handler:8520268 Call OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.610 0:12.371 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:34.648 0:12.408 Media Patch:8527348 RTP Jitter buffer length exceeded 2006/06/02 13:12:34.649 0:12.409 Media Patch:8527348 RTP Jitter buffer length exceed was prior to first write. Not increasing buffer size 2006/06/02 13:12:35.277 0:13.037 Media Patch:8175708 RTP First sent data: ver=2 pt=PCMU psz=160 m=1 x=0 seq=1460 ts=0 src=703395120 ccnt=0 2006/06/02 13:12:35.608 0:13.368 Housekeeper RTP Found existing session 1 2006/06/02 13:12:35.609 0:13.369 Housekeeper RTP Found existing session 2 2006/06/02 13:12:36.137 0:13.898 RTP Jitter:8526b30 RTP Receive statistics: packets=101 octets=3714 lost=0 tooLate=0 order=0 avgTime=15 maxTime=1556 minTime=0 jitter=16 maxJitter=188 2006/06/02 13:12:36.573 0:14.333 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (9760) 2006/06/02 13:12:36.614 0:14.374 Housekeeper RTP Found existing session 1 2006/06/02 13:12:36.615 0:14.375 Housekeeper RTP Found existing session 2 2006/06/02 13:12:36.974 0:14.734 RTP Jitter:8526b30 RTP Jitter buffer continuously full, throwing away entire buffer. 2006/06/02 13:12:36.995 0:14.756 RTP Jitter:8526b30 RTP Jitter buffer full, threw away 21 oldest frames 2006/06/02 13:12:37.374 0:15.134 RTP Jitter:8526b30 RTP Receive statistics: packets=201 octets=19714 lost=0 tooLate=0 order=0 avgTime=12 maxTime=23 minTime=0 jitter=0 maxJitter=188 2006/06/02 13:12:37.620 0:15.380 Housekeeper RTP Found existing session 1 2006/06/02 13:12:37.621 0:15.381 Housekeeper RTP Found existing session 2 2006/06/02 13:12:37.820 0:15.580 Media Patch:8175708 RTP Transmit statistics: packets=101 octets=16160 avgTime=25 maxTime=48 minTime=23 2006/06/02 13:12:38.624 0:16.384 Housekeeper RTP Found existing session 1 2006/06/02 13:12:38.625 0:16.385 Housekeeper RTP Found existing session 2 2006/06/02 13:12:38.993 0:16.753 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (29120) 2006/06/02 13:12:39.374 0:17.134 RTP Jitter:8526b30 RTP Receive statistics: packets=301 octets=35714 lost=0 tooLate=0 order=0 avgTime=20 maxTime=26 minTime=14 jitter=1 maxJitter=188 2006/06/02 13:12:39.395 0:17.155 RTP Jitter:8526b30 RTP Jitter buffer continuously full, throwing away entire buffer. 2006/06/02 13:12:39.415 0:17.176 RTP Jitter:8526b30 RTP Jitter buffer full, threw away 21 oldest frames 2006/06/02 13:12:39.632 0:17.392 Housekeeper RTP Found existing session 1 2006/06/02 13:12:39.633 0:17.393 Housekeeper RTP Found existing session 2 2006/06/02 13:12:40.384 0:18.144 Media Patch:8175708 RTP Transmit statistics: packets=201 octets=32160 avgTime=25 maxTime=44 minTime=22 2006/06/02 13:12:40.640 0:18.400 Housekeeper RTP Found existing session 1 2006/06/02 13:12:40.641 0:18.401 Housekeeper RTP Found existing session 2 2006/06/02 13:12:41.373 0:19.133 RTP Jitter:8526b30 RTP Receive statistics: packets=401 octets=51714 lost=0 tooLate=0 order=0 avgTime=19 maxTime=26 minTime=13 jitter=1 maxJitter=188 2006/06/02 13:12:41.413 0:19.173 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (48480) 2006/06/02 13:12:41.648 0:19.424 Housekeeper RTP Found existing session 1 2006/06/02 13:12:41.665 0:19.425 Housekeeper RTP Found existing session 2 2006/06/02 13:12:41.813 0:19.573 RTP Jitter:8526b30 RTP Jitter buffer continuously full, throwing away entire buffer. 2006/06/02 13:12:41.833 0:19.593 RTP Jitter:8526b30 RTP Jitter buffer full, threw away 21 oldest frames 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP Found existing session 1 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP Found existing session 2 2006/06/02 13:12:42.920 0:20.680 Media Patch:8175708 RTP Transmit statistics: packets=301 octets=48160 avgTime=25 maxTime=49 minTime=22 2006/06/02 13:12:43.378 0:21.139 RTP Jitter:8526b30 RTP Receive statistics: packets=501 octets=67714 lost=0 tooLate=0 order=0 avgTime=20 maxTime=27 minTime=12 jitter=1 maxJitter=188 2006/06/02 13:12:43.696 0:21.457 Housekeeper RTP Found existing session 1 2006/06/02 13:12:43.697 0:21.457 Housekeeper RTP Found existing session 2 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot Call Clearing Call[1] reason=EndedByLocalUser 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot OpalCon Releasing Call[1]-EP[Default] 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon Call end reason for Default set to EndedByLocalUser 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon SetPhase from EstablishedPhase to ReleasingPhase 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon Releasing Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon Call end reason for fa44075b-96f0-da11-8388-000ea6217592@nomade set to EndedByLocalUser 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon SetPhase from EstablishedPhase to ReleasingPhase 2006/06/02 13:12:43.820 0:21.581 OnRelease:856e8a0 OpalCon OnReleased Call[1]-EP[Default] 2006/06/02 13:12:43.822 0:21.583 OnRelease:856e8a0 Media Closing raw media stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.824 0:21.584 OnRelease:856e8a0 Media Closing stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.825 0:21.585 OnRelease:856e8a0 Media Disconnecting OpalAudioMediaStream-Source-PCM-16 from patch thread Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.827 0:21.587 OnRelease:856e8a0 Patch Closing media patch Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.829 0:21.589 OnRelease:856e8a0 Media Closing raw media stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.830 0:21.590 OnRelease:856e8a0 Media Closing stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.831 0:21.591 OnRelease:84f8c00 SIP OnReleased: Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade], phase = ReleasingPhase 2006/06/02 13:12:43.833 0:21.593 OnRelease:84f8c00 OpalCon SetPhase from ReleasingPhase to ReleasingPhase 2006/06/02 13:12:43.834 0:21.594 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (67840) 2006/06/02 13:12:43.836 0:21.596 OnRelease:84f8c00 SIP Transaction 4 BYE created. 2006/06/02 13:12:43.842 0:21.603 OnRelease:84f8c00 Media Closing RTP for OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.844 0:21.604 OnRelease:84f8c00 RTP_UDP Session 1, Shutting down write. 2006/06/02 13:12:43.845 0:21.605 OnRelease:84f8c00 Media Closing stream OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.846 0:21.606 OnRelease:84f8c00 Media Disconnecting OpalRTPMediaStream-Sink-G.711-uLaw-64k from patch thread Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.848 0:21.609 OnRelease:84f8c00 Patch Removing media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.855 0:21.626 OnRelease:84f8c00 Media Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.867 0:21.627 OnRelease:84f8c00 RTP_UDP Session 1, Shutting down read. 2006/06/02 13:12:43.868 0:21.628 OnRelease:84f8c00 Media Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.869 0:21.630 OnRelease:84f8c00 Media Disconnecting OpalRTPMediaStream-Source-G.711-uLaw-64k from patch thread Patch OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.893 0:21.653 Media Patch:8175708 Patch Thread ended for Patch OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.893 0:21.653 OnRelease:84f8c00 Patch Closing media patch Patch OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.916 0:21.676 RTP Jitter:8526b30 RTP_UDP Session 1, Read shutdown. 2006/06/02 13:12:43.917 0:21.677 RTP Jitter:8526b30 RTP Jitter RTP receive thread ended 2006/06/02 13:12:43.917 0:21.677 OnRelease:84f8c00 Media Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.918 0:21.678 OnRelease:84f8c00 RTP_UDP Session 1, Shutting down read. 2006/06/02 13:12:43.919 0:21.679 OnRelease:84f8c00 Media Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.922 0:21.683 OnRelease:856e8a0 Patch Waiting for media patch thread to stop Patch OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.926 0:21.686 OnRelease:856e8a0 Patch Media patch thread Patch OpalAudioMediaStream-Source-PCM-16 destroyed. 2006/06/02 13:12:43.930 0:21.691 OnRelease:856e8a0 Media Closing raw media stream OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:43.932 0:21.693 OnRelease:856e8a0 Media Closing stream OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:43.933 0:21.694 OnRelease:856e8a0 Media Disconnecting OpalAudioMediaStream-Sink-PCM-16 from patch thread Patch OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.956 0:21.717 OnRelease:856e8a0 Patch Removing media stream sink OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP Found existing session 1 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP Found existing session 2 2006/06/02 13:12:45.696 0:23.456 Housekeeper RTP Found existing session 1 2006/06/02 13:12:45.697 0:23.457 Housekeeper RTP Found existing session 2 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP Found existing session 1 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP Found existing session 2 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP Found existing session 1 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP Found existing session 2 2006/06/02 13:12:48.708 0:26.468 Housekeeper RTP Found existing session 1 2006/06/02 13:12:48.709 0:26.469 Housekeeper RTP Found existing session 2 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP Found existing session 1 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP Found existing session 2 2006/06/02 13:12:50.712 0:28.473 Housekeeper RTP Found existing session 1 2006/06/02 13:12:50.713 0:28.473 Housekeeper RTP Found existing session 2 2006/06/02 13:12:51.716 0:29.477 Housekeeper RTP Found existing session 1 2006/06/02 13:12:51.717 0:29.477 Housekeeper RTP Found existing session 2 2006/06/02 13:12:52.716 0:30.477 Housekeeper RTP Found existing session 1 2006/06/02 13:12:52.717 0:30.477 Housekeeper RTP Found existing session 2 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP Found existing session 1 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP Found existing session 2 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP Found existing session 1 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP Found existing session 2 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP Found existing session 1 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP Found existing session 2 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP Found existing session 1 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP Found existing session 2 2006/06/02 13:12:57.733 0:35.493 Housekeeper RTP Found existing session 1 2006/06/02 13:12:57.734 0:35.494 Housekeeper RTP Found existing session 2 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP Found existing session 1 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP Found existing session 2 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP Found existing session 1 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP Found existing session 2 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP Found existing session 1 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP Found existing session 2 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP Found existing session 1 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP Found existing session 2 2006/06/02 13:13:02.777 0:40.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:02.778 0:40.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP Found existing session 2 2006/06/02 13:13:04.369 0:42.129 Housekeeper SIP Set state Terminated_Success for transaction 1 INVITE 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP Found existing session 2 2006/06/02 13:13:05.777 0:43.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:05.777 0:43.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:06.613 0:44.374 Housekeeper SIP Set state Terminated_Success for transaction 2 INVITE 2006/06/02 13:13:06.777 0:44.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:06.778 0:44.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:07.777 0:45.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:07.778 0:45.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP Found existing session 2 Processus arrêté -- Daniel From dsandras@seconix.com Sat Jun 3 13:58:00 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 184373B06A7 for ; Sat, 3 Jun 2006 13:58:00 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20355-03 for ; Sat, 3 Jun 2006 13:57:57 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 19BB03B036E for ; Sat, 3 Jun 2006 13:57:56 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id BC1A4493FD; Sat, 3 Jun 2006 19:41:15 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13551-03; Sat, 3 Jun 2006 19:41:05 +0200 (CEST) Received: from d51A5F203.access.telenet.be (d51A5F203.access.telenet.be [81.165.242.3]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id BC664493EE; Sat, 3 Jun 2006 19:41:05 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <20060603095331.79CD.CRAIGS@postincrement.com> References: <1149242124.4509.17.camel@siti> <20060603095331.79CD.CRAIGS@postincrement.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Sat, 03 Jun 2006 19:57:45 +0200 Message-Id: <1149357465.2414.30.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: Cc: Derek Smithies X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 17:58:00 -0000 Le samedi 03 juin 2006 à 09:55 +1000, Craig Southeren a écrit : > On Fri, 02 Jun 2006 21:55:24 +1200 > Stephen Cook wrote: > > > Hi, > > > > I haven't introduced myself here before, I am Stephen Cook (siti). My > > proposal for implementing IAX2 in ekiga got accepted with google's > > summer of code. > > > > To give an update (I'll try and keep you guys regularly posted as to > > what's happening, any problems etc.). > > > > Currently I have been looking at the code to gain an understanding of > > ekiga and opal's code and design. Also obviously checking out the IAX2 > > code in opal :). From what I have seen and got working, I will work on > > getting IAX2 going in ekiga first. The main part of this will obviously > > involve writing a gnome meeting endpoint for IAX2. > > > > One key problem I have identified is the accounts code. The protocols > > are tightly integrated with how it works. I could either refactor this > > code to loosen the integration or hack iax2 support in there and > > refactor it later ;). The advantage of this refactored will be when > > someone wants to add Xmpp/libjingle support, or some other protocol down > > the track. > > > > Well, please tell me your thoughts and comments on this project. > > As a New Zealander, you are uniquely placed to communicate with the > author of the OPAL IAX2 code, Derek Smithies, who is a fellow Kiwi! I am > sure that you will be able to get the OPAL IAX2 code working with Ekiga > in no time at all with his help. > > If you have any questions, please contact me directly. > Craig, I do not think moving to an offline conversation with Stephen is a good idea. Julien and myself are supposed to mentor the project. Your help is of course welcome, but we have to be kept informed. Notice also that the project is not only about making IAX2 work with Ekiga. -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Sat Jun 3 14:01:08 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 59C003B01BB for ; Sat, 3 Jun 2006 14:01:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20343-10 for ; Sat, 3 Jun 2006 14:01:02 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id BA0863B04B1 for ; Sat, 3 Jun 2006 14:01:01 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 1184A496A8 for ; Sat, 3 Jun 2006 19:44:21 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13551-04 for ; Sat, 3 Jun 2006 19:44:12 +0200 (CEST) Received: from d51A5F203.access.telenet.be (d51A5F203.access.telenet.be [81.165.242.3]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 993CE49685 for ; Sat, 3 Jun 2006 19:44:07 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <4481A6AF.2060703@tootai.net> References: <4481A6AF.2060703@tootai.net> Content-Type: text/plain; charset=ISO-8859-15 Date: Sat, 03 Jun 2006 20:00:48 +0200 Message-Id: <1149357648.2414.34.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 18:01:08 -0000 Hi, Le samedi 03 juin 2006 à 17:11 +0200, Daniel Huhardeaux a écrit : > Resent as it didn't pass at the first try (too big, I cut the begining > of logs) > > Hi all, > > Ekiga behind a firewall is registering to an asterisk server which is on > internet. The sip user is authorized with gsm,ulaw,alaw on asterisk side. > > When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is > started, connection is showed with PCMU (why not GSM?), see the traffic > in/out (~6 kB) but have no audio. > Asterisk answers with 200 OK indicating that the call should be done with PCMU. > I hangup the call, the hangup info is shown in the toolbar, PCMU > disappear in codec and immediately after, traffic in/out continue with > 0/0, icon in KDE Toolbar show Ekiga on line. The only solution I have is > to kill Ekiga. > Please try with 2.0.2. Craig has done work in CVS and things are potentially broken. If the problem persists once plugins support is in CVS, please report again. > If I deactivate GSM codec, everything is fine. Below you will find a d4 > output from the call. > I do not think activating GSM or not has any influence. The problem is probably something else. > > [...] > 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 OpalUDP > Ended connect, selecting 82.231.69.24:35065 > 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP > Queueing PDU: 1 INVITE <407> > 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP > Waiting for PDU on udp$213.203.241.243:5060 > 2006/06/02 13:12:32.901 0:10.661 SIP Handler:8520268 SIP PDU > handler thread started. > 2006/06/02 13:12:32.902 0:10.662 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:32.902 0:10.663 SIP Handler:8520268 SIP > Handling PDU 1 INVITE <407> (with transaction) > 2006/06/02 13:12:32.903 0:10.663 SIP Handler:8520268 SIP > Transaction 1 INVITE completed. > 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP > Sending PDU on udp$213.203.241.243:5060 > ACK sip:800@sip.tootai.net SIP/2.0 > CSeq: 1 ACK > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bK803b125b-96f0-da11-8388-000ea6217592;rport > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: ;tag=as315809c6 > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE > Content-Length: 0 > Max-Forwards: 70 > > > 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP > Received Proxy Authentication Required response > 2006/06/02 13:12:32.906 0:10.666 SIP Handler:8520268 SIP > Transaction 2 INVITE created. > 2006/06/02 13:12:32.906 0:10.667 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:33.090 0:10.850 SIP Handler:8520268 RTP_UDP > Session 1 created: 82.231.69.24:35010-35011 ssrc=703395120 > 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 RTP > Adding session RTP_UDP > 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 SIP > Using RTP payload [pt=101] for NTE > 2006/06/02 13:12:33.100 0:10.860 SIP Handler:8520268 Call > GetMediaFormats for > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > GSM-06.10 > G.711-uLaw-64k > G.711-ALaw-64k > H.261(QCIF) > H.261(CIF) > YUV420P > RGB32 > RGB24 > > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 2 > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 2 > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 2 > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:33.281 0:11.041 SIP Handler:8520268 RTP_UDP > Session 2 created: 82.231.69.24:35014-35015 ssrc=2454563097 > 2006/06/02 13:12:33.282 0:11.042 SIP Handler:8520268 RTP > Adding session RTP_UDP > 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 Call > GetMediaFormats for > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > GSM-06.10 > G.711-uLaw-64k > G.711-ALaw-64k > H.261(QCIF) > H.261(CIF) > YUV420P > RGB32 > RGB24 > > 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 SIP > Adding authentication information > 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP > Sending PDU on udp$213.203.241.243:5060 > INVITE sip:800@sip.tootai.net SIP/2.0 > Date: Fri, 02 Jun 2006 11:12:32 GMT > CSeq: 2 INVITE > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;rport > User-Agent: Ekiga/2.0.1-20060521-01 > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: > Contact: > Proxy-Authorization: Digest username="104", realm="sip.tootai.net", > nonce="12d01d5d", uri="sip:800@sip.tootai.net", > response="60b65ec9045130eab45495d3c65fbc5e", algorithm=md5 > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE > Content-Type: application/sdp > Content-Length: 302 > Max-Forwards: 70 > > v=0 > o=- 1149246753 1149246753 IN IP4 82.231.69.24 > s=Opal SIP Session > c=IN IP4 82.231.69.24 > t=0 0 > m=audio 35010 RTP/AVP 101 3 0 8 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=rtpmap:3 GSM/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > m=video 35014 RTP/AVP 31 > a=rtpmap:31 H261/90000 > > 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP PDU > Received on udp$213.203.241.243:5060 > SIP/2.0 100 Trying > CSeq: 2 INVITE > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 > User-Agent: Asterisk PBX > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: > Contact: > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > Content-Length: 0 > > > 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP > Queueing PDU: 2 INVITE <100> > 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP > Waiting for PDU on udp$213.203.241.243:5060 > 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP > Handling PDU 2 INVITE <100> (with transaction) > 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP > Transaction 2 INVITE proceeding. > 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Set > targetAddress to sip:800@213.203.241.243 > 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP > Received Trying response > 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP > Media session port=7166 > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP > Adding media session with 2 formats > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP > Unknown media attribute silenceSupp:off - - - - > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SIP PDU > Received on udp$213.203.241.243:5060 > SIP/2.0 200 OK > CSeq: 2 INVITE > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 > User-Agent: Asterisk PBX > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: ;tag=as5d2831d1 > Contact: > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > Content-Type: application/sdp > Content-Length: 221 > > v=0 > o=root 26912 26912 IN IP4 213.203.241.243 > s=session > c=IN IP4 213.203.241.243 > t=0 0 > m=audio 7166 RTP/AVP 0 101 > a=rtpmap:0 PCMU/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=silenceSupp:off - - - - > > 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP > Queueing PDU: 2 INVITE <200> > 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP > Waiting for PDU on udp$213.203.241.243:5060 > 2006/06/02 13:12:33.388 0:11.148 SIP Handler:8520268 SIP > Handling PDU 2 INVITE <200> (with transaction) > 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP > Transaction 2 INVITE completed. > 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP Set > targetAddress to sip:800@213.203.241.243 > 2006/06/02 13:12:33.390 0:11.150 SIP Handler:8520268 SIP > Adding authentication information > 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP > Adjusting transport to address udp$213.203.241.243:5060 > 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP > Sending PDU on udp$213.203.241.243:5060 > ACK sip:800@213.203.241.243 SIP/2.0 > CSeq: 2 ACK > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bK6e2ca15b-96f0-da11-8388-000ea6217592;rport > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: ;tag=as5d2831d1 > Contact: > Proxy-Authorization: Digest username="104", realm="sip.tootai.net", > nonce="12d01d5d", uri="sip:800@213.203.241.243", > response="059defd67706254552a5c23eada565b5", algorithm=md5 > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE > Content-Length: 0 > Max-Forwards: 70 > > > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP > Received INVITE OK response > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 SIP RTP > payload type PCMU matched to codec G.711-uLaw-64k > 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k > 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 OpalCon > OpenSourceMediaStream for session 1 on Call[1]-EP[Default] > 2006/06/02 13:12:33.398 0:11.158 SIP Handler:8520268 OpalCon > Selected media stream PCM-16 -> G.711-uLaw-64k > 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 OpalMan > OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 Call > PatchMediaStreams Call[1]-EP[Default] > 2006/06/02 13:12:34.196 0:11.957 SIP Handler:8520268 OpalCon > OpenSinkMediaStream > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session=1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon > OpenSinkMediaStream, selected PCM-16 -> G.711-uLaw-64k > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:34.197 0:11.958 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 OpalMan > OnOpenMediaStream > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Patch > Added sink > from PCM-16 > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 16 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > to G.711-uLaw-64k > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 8 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > > 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Codec > G711-uLaw-64k encoder created > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Patch > Added media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k using > transcoder PCM-16->G.711-uLaw-64k > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Media > Audio source data size set to 320 bytes and 2 buffers. > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call > GetOtherPartyConnection > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon > OpenSourceMediaStream for session 1 on > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon > Selected media stream G.711-uLaw-64k -> PCM-16 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalMan > OnOpenMediaStream > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 Call > PatchMediaStreams > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon > OpenSinkMediaStream Call[1]-EP[Default] session=1 > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon > OpenSinkMediaStream, selected G.711-uLaw-64k -> PCM-16 > 2006/06/02 13:12:34.513 0:12.274 SIP Handler:8520268 OpalMan > OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:34.514 0:12.274 SIP Handler:8520268 Patch > Added sink > from G.711-uLaw-64k > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 8 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > to PCM-16 > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 16 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Codec > G711-uLaw-64k decoder created > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Media > Audio sink data size set to 320 bytes and 2 buffers. > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Patch > Added media stream sink OpalAudioMediaStream-Sink-PCM-16 using > transcoder G.711-uLaw-64k->PCM-16 > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.525 0:12.285 SIP Handler:8520268 OpalCon > OpenSourceMediaStream (already opened) for session 1 on > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.527 0:12.287 SIP Handler:8520268 RTP_UDP > SetRemoteSocketInfo: session=1 data channel, new=213.203.241.243:7166, > local=82.231.69.24:35010-35011, remote=0.0.0.0:0-0 > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 SIP > Could not find SDP media description for Video > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 OpalMan > OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 Call > OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 PCSS > SetConnected() > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 > GMPCSSEndpoint PCSS connection established > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 > GMManager Will establish the connection > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 OpalMan > OnEstablished Call[1]-EP[Default] > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 Call > OnEstablished Call[1]-EP[Default] > 2006/06/02 13:12:34.540 0:12.300 SIP Handler:8520268 Call > GetMediaFormats for Call[1]-EP[Default] > G.711-uLaw-64k > > 2006/06/02 13:12:34.541 0:12.301 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k > 2006/06/02 13:12:34.542 0:12.302 SIP Handler:8520268 OpalCon > OpenSourceMediaStream (already opened) for session 1 on > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.543 0:12.303 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call > GetMediaFormats for > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > G.711-uLaw-64k > > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 OpalCon > OpenSourceMediaStream (already opened) for session 1 on > Call[1]-EP[Default] > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k > 2006/06/02 13:12:34.552 0:12.312 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k > 2006/06/02 13:12:34.553 0:12.313 Media Patch:8175708 Patch > Thread started for Patch OpalAudioMediaStream-Source-PCM-16 -> > OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:34.556 0:12.316 SIP Handler:8520268 Media > Starting thread Media Patch:8175708 > 2006/06/02 13:12:34.557 0:12.317 Media Patch:8527348 Patch > Thread started for Patch OpalRTPMediaStream-Source-G.711-uLaw-64k -> > OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:34.568 0:12.329 Media Patch:8527348 RTP > Jitter buffer created: size=101 delay=160-4000/160 (20ms) obj=0x8526b30 > 2006/06/02 13:12:34.572 0:12.333 RTP Jitter:8526b30 RTP > Jitter RTP receive thread started: 0x8526b30 > 2006/06/02 13:12:34.574 0:12.334 RTP Jitter:8526b30 RTP > First receive data: ver=2 pt=GSM psz=33 m=0 x=0 seq=39915 ts=160 > src=824302623 ccnt=0 > 2006/06/02 13:12:34.580 0:12.341 SIP Handler:8520268 Media > Starting thread Media Patch:8527348 > 2006/06/02 13:12:34.581 0:12.341 SIP Handler:8520268 OpalCon > Media stream threads started. > 2006/06/02 13:12:34.582 0:12.342 SIP Handler:8520268 OpalCon > Media stream threads started. > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP > Found existing session 2 > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 > GMManager Will establish the connection > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 OpalMan > OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.607 0:12.367 SIP Handler:8520268 Call > OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.610 0:12.371 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:34.648 0:12.408 Media Patch:8527348 RTP > Jitter buffer length exceeded > 2006/06/02 13:12:34.649 0:12.409 Media Patch:8527348 RTP > Jitter buffer length exceed was prior to first write. Not increasing > buffer size > 2006/06/02 13:12:35.277 0:13.037 Media Patch:8175708 RTP > First sent data: ver=2 pt=PCMU psz=160 m=1 x=0 seq=1460 ts=0 > src=703395120 ccnt=0 > 2006/06/02 13:12:35.608 0:13.368 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:35.609 0:13.369 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:36.137 0:13.898 RTP Jitter:8526b30 RTP > Receive statistics: packets=101 octets=3714 lost=0 tooLate=0 order=0 > avgTime=15 maxTime=1556 minTime=0 jitter=16 maxJitter=188 > 2006/06/02 13:12:36.573 0:14.333 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (9760) > 2006/06/02 13:12:36.614 0:14.374 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:36.615 0:14.375 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:36.974 0:14.734 RTP Jitter:8526b30 RTP > Jitter buffer continuously full, throwing away entire buffer. > 2006/06/02 13:12:36.995 0:14.756 RTP Jitter:8526b30 RTP > Jitter buffer full, threw away 21 oldest frames > 2006/06/02 13:12:37.374 0:15.134 RTP Jitter:8526b30 RTP > Receive statistics: packets=201 octets=19714 lost=0 tooLate=0 order=0 > avgTime=12 maxTime=23 minTime=0 jitter=0 maxJitter=188 > 2006/06/02 13:12:37.620 0:15.380 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:37.621 0:15.381 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:37.820 0:15.580 Media Patch:8175708 RTP > Transmit statistics: packets=101 octets=16160 avgTime=25 maxTime=48 > minTime=23 > 2006/06/02 13:12:38.624 0:16.384 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:38.625 0:16.385 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:38.993 0:16.753 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (29120) > 2006/06/02 13:12:39.374 0:17.134 RTP Jitter:8526b30 RTP > Receive statistics: packets=301 octets=35714 lost=0 tooLate=0 order=0 > avgTime=20 maxTime=26 minTime=14 jitter=1 maxJitter=188 > 2006/06/02 13:12:39.395 0:17.155 RTP Jitter:8526b30 RTP > Jitter buffer continuously full, throwing away entire buffer. > 2006/06/02 13:12:39.415 0:17.176 RTP Jitter:8526b30 RTP > Jitter buffer full, threw away 21 oldest frames > 2006/06/02 13:12:39.632 0:17.392 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:39.633 0:17.393 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:40.384 0:18.144 Media Patch:8175708 RTP > Transmit statistics: packets=201 octets=32160 avgTime=25 maxTime=44 > minTime=22 > 2006/06/02 13:12:40.640 0:18.400 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:40.641 0:18.401 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:41.373 0:19.133 RTP Jitter:8526b30 RTP > Receive statistics: packets=401 octets=51714 lost=0 tooLate=0 order=0 > avgTime=19 maxTime=26 minTime=13 jitter=1 maxJitter=188 > 2006/06/02 13:12:41.413 0:19.173 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (48480) > 2006/06/02 13:12:41.648 0:19.424 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:41.665 0:19.425 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:41.813 0:19.573 RTP Jitter:8526b30 RTP > Jitter buffer continuously full, throwing away entire buffer. > 2006/06/02 13:12:41.833 0:19.593 RTP Jitter:8526b30 RTP > Jitter buffer full, threw away 21 oldest frames > 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:42.920 0:20.680 Media Patch:8175708 RTP > Transmit statistics: packets=301 octets=48160 avgTime=25 maxTime=49 > minTime=22 > 2006/06/02 13:12:43.378 0:21.139 RTP Jitter:8526b30 RTP > Receive statistics: packets=501 octets=67714 lost=0 tooLate=0 order=0 > avgTime=20 maxTime=27 minTime=12 jitter=1 maxJitter=188 > 2006/06/02 13:12:43.696 0:21.457 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:43.697 0:21.457 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot Call > Clearing Call[1] reason=EndedByLocalUser > 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot OpalCon > Releasing Call[1]-EP[Default] > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > Call end reason for Default set to EndedByLocalUser > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > SetPhase from EstablishedPhase to ReleasingPhase > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > Releasing Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > Call end reason for fa44075b-96f0-da11-8388-000ea6217592@nomade set to > EndedByLocalUser > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > SetPhase from EstablishedPhase to ReleasingPhase > 2006/06/02 13:12:43.820 0:21.581 OnRelease:856e8a0 OpalCon > OnReleased Call[1]-EP[Default] > 2006/06/02 13:12:43.822 0:21.583 OnRelease:856e8a0 Media > Closing raw media stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.824 0:21.584 OnRelease:856e8a0 Media > Closing stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.825 0:21.585 OnRelease:856e8a0 Media > Disconnecting OpalAudioMediaStream-Source-PCM-16 from patch thread Patch > OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.827 0:21.587 OnRelease:856e8a0 Patch > Closing media patch Patch OpalAudioMediaStream-Source-PCM-16 -> > OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.829 0:21.589 OnRelease:856e8a0 Media > Closing raw media stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.830 0:21.590 OnRelease:856e8a0 Media > Closing stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.831 0:21.591 OnRelease:84f8c00 SIP > OnReleased: > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade], phase = > ReleasingPhase > 2006/06/02 13:12:43.833 0:21.593 OnRelease:84f8c00 OpalCon > SetPhase from ReleasingPhase to ReleasingPhase > 2006/06/02 13:12:43.834 0:21.594 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (67840) > 2006/06/02 13:12:43.836 0:21.596 OnRelease:84f8c00 SIP > Transaction 4 BYE created. > 2006/06/02 13:12:43.842 0:21.603 OnRelease:84f8c00 Media > Closing RTP for OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.844 0:21.604 OnRelease:84f8c00 RTP_UDP > Session 1, Shutting down write. > 2006/06/02 13:12:43.845 0:21.605 OnRelease:84f8c00 Media > Closing stream OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.846 0:21.606 OnRelease:84f8c00 Media > Disconnecting OpalRTPMediaStream-Sink-G.711-uLaw-64k from patch thread > Patch OpalAudioMediaStream-Source-PCM-16 -> > OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.848 0:21.609 OnRelease:84f8c00 Patch > Removing media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.855 0:21.626 OnRelease:84f8c00 Media > Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.867 0:21.627 OnRelease:84f8c00 RTP_UDP > Session 1, Shutting down read. > 2006/06/02 13:12:43.868 0:21.628 OnRelease:84f8c00 Media > Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.869 0:21.630 OnRelease:84f8c00 Media > Disconnecting OpalRTPMediaStream-Source-G.711-uLaw-64k from patch thread > Patch OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.893 0:21.653 Media Patch:8175708 Patch > Thread ended for Patch OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.893 0:21.653 OnRelease:84f8c00 Patch > Closing media patch Patch OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.916 0:21.676 RTP Jitter:8526b30 RTP_UDP > Session 1, Read shutdown. > 2006/06/02 13:12:43.917 0:21.677 RTP Jitter:8526b30 RTP > Jitter RTP receive thread ended > 2006/06/02 13:12:43.917 0:21.677 OnRelease:84f8c00 Media > Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.918 0:21.678 OnRelease:84f8c00 RTP_UDP > Session 1, Shutting down read. > 2006/06/02 13:12:43.919 0:21.679 OnRelease:84f8c00 Media > Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.922 0:21.683 OnRelease:856e8a0 Patch > Waiting for media patch thread to stop Patch > OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.926 0:21.686 OnRelease:856e8a0 Patch > Media patch thread Patch OpalAudioMediaStream-Source-PCM-16 destroyed. > 2006/06/02 13:12:43.930 0:21.691 OnRelease:856e8a0 Media > Closing raw media stream OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:43.932 0:21.693 OnRelease:856e8a0 Media > Closing stream OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:43.933 0:21.694 OnRelease:856e8a0 Media > Disconnecting OpalAudioMediaStream-Sink-PCM-16 from patch thread Patch > OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.956 0:21.717 OnRelease:856e8a0 Patch > Removing media stream sink OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:45.696 0:23.456 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:45.697 0:23.457 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:48.708 0:26.468 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:48.709 0:26.469 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:50.712 0:28.473 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:50.713 0:28.473 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:51.716 0:29.477 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:51.717 0:29.477 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:52.716 0:30.477 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:52.717 0:30.477 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:57.733 0:35.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:57.734 0:35.494 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:02.777 0:40.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:02.778 0:40.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:04.369 0:42.129 Housekeeper SIP Set > state Terminated_Success for transaction 1 INVITE > 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:05.777 0:43.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:05.777 0:43.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:06.613 0:44.374 Housekeeper SIP Set > state Terminated_Success for transaction 2 INVITE > 2006/06/02 13:13:06.777 0:44.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:06.778 0:44.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:07.777 0:45.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:07.778 0:45.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP > Found existing session 2 > Processus arrêté > -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From devel@tootai.net Sat Jun 3 19:25:05 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EBBDB3B06DD for ; Sat, 3 Jun 2006 19:24:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02787-06 for ; Sat, 3 Jun 2006 19:24:40 -0400 (EDT) Received: from mail1.tootai.net (ns1.tootai.net [82.231.69.24]) by menubar.gnome.org (Postfix) with ESMTP id 16D123B0756 for ; Sat, 3 Jun 2006 19:24:35 -0400 (EDT) Received: from [192.168.0.17] (unknown [192.168.0.17]) by mail1.tootai.net (Postfix) with ESMTP id 9C142398B99 for ; Sun, 4 Jun 2006 01:24:35 +0200 (CEST) Message-ID: <44821A19.10001@tootai.net> Date: Sun, 04 Jun 2006 01:24:09 +0200 From: Daniel Huhardeaux Organization: TOOTAi User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 References: <4481A6AF.2060703@tootai.net> <1149357648.2414.34.camel@golgoth01> In-Reply-To: <1149357648.2414.34.camel@golgoth01> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[AWL=0.000, BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 23:25:05 -0000 Damien Sandras wrote: > [...] >> When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is >> started, connection is showed with PCMU (why not GSM?), see the traffic >> in/out (~6 kB) but have no audio. >> >> > > Asterisk answers with 200 OK indicating that the call should be done > with PCMU. > Ok, but as GSM has my preference in Ekiga as well as in asterisk, the call should be done in GSM > [...] > > Please try with 2.0.2. Craig has done work in CVS and things are > potentially broken. If the problem persists once plugins support is in > CVS, please report again. > I use the Ekiga snapshot SID version which don't provide newest version as the one mentioned :-( Kilian? BTW, asterisk is 1.2-r16008 from 29/03/2006 - SVN stable. > > >> If I deactivate GSM codec, everything is fine. Below you will find a d4 >> output from the call. >> >> > > I do not think activating GSM or not has any influence. The problem is > probably something else. > I would like to believe you, but this problem happends only with GSM codec. -- Daniel From ebischoff@nerim.net Sun Jun 4 11:52:03 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C970B3B011B for ; Sun, 4 Jun 2006 11:52:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26992-10 for ; Sun, 4 Jun 2006 11:52:01 -0400 (EDT) Received: from mallaury.nerim.net (smtp-100-sunday.noc.nerim.net [62.4.17.100]) by menubar.gnome.org (Postfix) with ESMTP id 9601A3B00CE for ; Sun, 4 Jun 2006 11:52:01 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by mallaury.nerim.net (Postfix) with ESMTP id 32E474F399 for ; Sun, 4 Jun 2006 17:51:50 +0200 (CEST) From: =?iso-8859-1?q?=C9ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Sun, 4 Jun 2006 17:52:11 +0200 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606041752.12228.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.535 tagged_above=-999 required=2 tests=[AWL=0.064, BAYES_00=-2.599] X-Spam-Score: -2.535 X-Spam-Level: Subject: [GnomeMeeting-devel-list] KDE address book support in Ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 15:52:04 -0000 (this message has already been sent by mistake on gnomemeeting-list a few=20 hours ago, sorry for the crossposting) Hi everyone, A small notice to let you know that I am working on adding support for KDE= =20 Address Book (kab) to Ekiga. I already have some early "proof of concept"=20 code working (see screenshot at=20 http://opensource.bureau-cornavin.com/ekiga/screenshot.png). KDE Address Book is an application of its own, but it's also a library that= is=20 used by most KDE applications (KMail, Kontact, KPilot, Kopete, ...), and al= so=20 by third-party applications like OpenOffice.org. It can use several=20 "resources" for its addresses: local VCard files, remote LDAP servers, etc. Before anyone does the remark : YES it would be better if Evolution/GNOME a= nd=20 KDE shared the same address book library. But currently we have to live wit= h=20 this situation... There are two issues that currently slow me down a bit: 1) Ekiga's address book model distinguishes between "local" and "remote"=20 address books. This makes little sense for kab which can transparently use= =20 both local and remote resources. In a first time, my code will act as a=20 "local" address book, just like Evolution address book. 2) KDE address book currently has no field for SIP nor H323 addresses. I am= =20 currently trying to contact Will Stephenson (KDE) who added support for Sky= pe=20 addresses to see how we could do that cleanly. Of course, this functionality will remain optional and require no library f= or=20 those who can live without it :-). Any suggestion, wish, encouragement, criticism, and/or offer for help is=20 welcome. Hoping that helps, =2D-=20 =C9ric From jpuydt@free.fr Sun Jun 4 12:08:13 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C97F03B009F; Sun, 4 Jun 2006 12:08:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28175-05; Sun, 4 Jun 2006 12:08:00 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 880B03B0187; Sun, 4 Jun 2006 12:08:00 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-54-82-251-83-65.adsl.proxad.net [82.251.83.65]) by smtp5-g19.free.fr (Postfix) with ESMTP id 3EBD2250F8; Sun, 4 Jun 2006 18:07:59 +0200 (CEST) Message-ID: <44830581.8080503@free.fr> Date: Sun, 04 Jun 2006 18:08:33 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting mailing list , GnomeMeeting development mailing list References: <200606041116.31785.ebischoff@nerim.net> In-Reply-To: <200606041116.31785.ebischoff@nerim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: Cc: Subject: [GnomeMeeting-devel-list] Re: [GnomeMeeting-list] KDE address book support in Ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 16:08:14 -0000 Éric Bischoff a écrit : > A small notice to let you know that I am working on adding support for KDE > Address Book (kab) to Ekiga. I already have some early "proof of concept" > code working (see screenshot at > http://opensource.bureau-cornavin.com/ekiga/screenshot.png). I know :-) > KDE Address Book is an application of its own, but it's also a library that is > used by most KDE applications (KMail, Kontact, KPilot, Kopete, ...), and also > by third-party applications like OpenOffice.org. It can use several > "resources" for its addresses: local VCard files, remote LDAP servers, etc. Nice. > Before anyone does the remark : YES it would be better if Evolution/GNOME and > KDE shared the same address book library. But currently we have to live with > this situation... Indeed. > There are two issues that currently slow me down a bit: > > 1) Ekiga's address book model distinguishes between "local" and "remote" > address books. This makes little sense for kab which can transparently use > both local and remote resources. In a first time, my code will act as a > "local" address book, just like Evolution address book. I'm refactoring the addressbook ; and I don't like that distinction either. I'm still trying to convince Damien and Jan my ideas can fly. I think Jan is already beginning to see where I go ; Damien hasn't had the time to dive into it. > 2) KDE address book currently has no field for SIP nor H323 addresses. I am > currently trying to contact Will Stephenson (KDE) who added support for Skype > addresses to see how we could do that cleanly. Ok. > Of course, this functionality will remain optional and require no library for > those who can live without it :-). Ok too. We'll go with a --enable-kde at compile time. Then later on we'll see if it's possible to do something at runtime. > Any suggestion, wish, encouragement, criticism, and/or offer for help is > welcome. * Suggestion: use -devel-list ;-) * Wish: what you have written will work well with what I have in mind * Encouragement: I like the idea very much, and appreciate your working on ekiga * Criticism: couldn't you do that either long before or just after the re-architecturing? ;-) * Offer for help: uh... I'm refactoring, and it may help (the api I ask from "addressbooks" is much lighter). Snark on #ekiga From ebischoff@nerim.net Sun Jun 4 12:36:03 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6EBCD3B00E9 for ; Sun, 4 Jun 2006 12:36:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29967-09 for ; Sun, 4 Jun 2006 12:36:02 -0400 (EDT) Received: from kraid.nerim.net (smtp-100-sunday.nerim.net [62.4.16.100]) by menubar.gnome.org (Postfix) with ESMTP id 16E7B3B009F for ; Sun, 4 Jun 2006 12:36:01 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id C772E40E31 for ; Sun, 4 Jun 2006 18:35:59 +0200 (CEST) From: =?iso-8859-1?q?=C9ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Re: [GnomeMeeting-list] KDE address book support in Ekiga Date: Sun, 4 Jun 2006 18:36:11 +0200 User-Agent: KMail/1.8.2 References: <200606041116.31785.ebischoff@nerim.net> <44830581.8080503@free.fr> In-Reply-To: <44830581.8080503@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606041836.12390.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.553 tagged_above=-999 required=2 tests=[AWL=0.046, BAYES_00=-2.599] X-Spam-Score: -2.553 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 16:36:03 -0000 Le Dimanche 4 Juin 2006 18:08, Julien PUYDT a =E9crit=A0: > I know :-) I know you know ;-). > I'm refactoring the addressbook ; and I don't like that distinction > either. I'm still trying to convince Damien and Jan my ideas can fly. I > think Jan is already beginning to see where I go ; Damien hasn't had the > time to dive into it. Okay, I have not written much code yet, so there will be no problem to adap= t=20 it to your new layout, whatever it will be. > Ok too. We'll go with a --enable-kde at compile time. Then later on > we'll see if it's possible to do something at runtime. Yes, I was figuring out something like that. > * Suggestion: use -devel-list ;-) Yup, sorry... :-/ > * Wish: what you have written will work well with what I have in mind See above, I have not written much yet, and it's "obvious" code anyway, so= =20 there's no problem even if I have to restart from scratch. > * Encouragement: I like the idea very much, and appreciate your working > on ekiga Thank you for the warm welcome, Julien :-). > * Criticism: couldn't you do that either long before or just after the > re-architecturing? ;-) No. Did you hear about Murphy's law ? ;-) > * Offer for help: uh... I'm refactoring, and it may help (the api I ask > from "addressbooks" is much lighter). Indeed. =2D-=20 =C9ric From dsandras@seconix.com Mon Jun 5 15:24:19 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 115A33B038A for ; Mon, 5 Jun 2006 15:24:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24872-10 for ; Mon, 5 Jun 2006 15:24:15 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 482C73B0420 for ; Mon, 5 Jun 2006 15:24:15 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 73E6049870 for ; Mon, 5 Jun 2006 21:07:08 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23599-08 for ; Mon, 5 Jun 2006 21:06:52 +0200 (CEST) Received: from [192.168.0.161] (39.128-245-81.adsl-dyn.isp.belgacom.be [81.245.128.39]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 4C3C84986E for ; Mon, 5 Jun 2006 21:06:52 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44821A19.10001@tootai.net> References: <4481A6AF.2060703@tootai.net> <1149357648.2414.34.camel@golgoth01> <44821A19.10001@tootai.net> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 05 Jun 2006 21:24:50 +0200 Message-Id: <1149535490.2508.3.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.455 tagged_above=-999 required=2 tests=[AWL=0.009, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.455 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 19:24:19 -0000 Le dimanche 04 juin 2006 à 01:24 +0200, Daniel Huhardeaux a écrit : > Damien Sandras wrote: > > [...] > >> When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is > >> started, connection is showed with PCMU (why not GSM?), see the traffic > >> in/out (~6 kB) but have no audio. > >> > >> > > > > Asterisk answers with 200 OK indicating that the call should be done > > with PCMU. > > > Ok, but as GSM has my preference in Ekiga as well as in asterisk, the > call should be done in GSM I agree, but if you look at the 200 OK sent by Asterisk, GSM is not part of it, while it is part of the INVITE sent by Ekiga. > > I do not think activating GSM or not has any influence. The problem is > > probably something else. > > > I would like to believe you, but this problem happends only with GSM codec. Is there some way I could reproduce it here? -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Mon Jun 5 17:45:53 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 776D43B03A0; Mon, 5 Jun 2006 17:45:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02457-06; Mon, 5 Jun 2006 17:45:52 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 22F123B0295; Mon, 5 Jun 2006 17:45:52 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 8C0904984F; Mon, 5 Jun 2006 23:28:44 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29850-10; Mon, 5 Jun 2006 23:28:37 +0200 (CEST) Received: from [192.168.0.161] (39.128-245-81.adsl-dyn.isp.belgacom.be [81.245.128.39]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 089E44984C; Mon, 5 Jun 2006 23:28:36 +0200 (CEST) From: Damien Sandras To: gnomemeeting-list@gnome.org Content-Type: text/plain Date: Mon, 05 Jun 2006 23:46:32 +0200 Message-Id: <1149543992.2508.40.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.455 tagged_above=-999 required=2 tests=[AWL=0.009, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.455 X-Spam-Level: Cc: gnomemeeting-devel-list@gnome.org Subject: [GnomeMeeting-devel-list] Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 21:45:53 -0000 Hello to all, Ekiga 2.0.2 is available on http://www.ekiga.org More packages will be added as they are released. Thanks a lot to all supporters of the project! -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From simon@mungewell.org Mon Jun 5 18:20:27 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1BD3C3B0389 for ; Mon, 5 Jun 2006 18:20:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04790-06 for ; Mon, 5 Jun 2006 18:20:25 -0400 (EDT) Received: from pd3mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by menubar.gnome.org (Postfix) with ESMTP id 864BD3B04F7 for ; Mon, 5 Jun 2006 18:20:25 -0400 (EDT) Received: from pd3mr3so.prod.shaw.ca (pd3mr3so-qfe3.prod.shaw.ca [10.0.141.179]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0E00FK5RE0KD10@l-daemon> for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:20:24 -0600 (MDT) Received: from pn2ml4so.prod.shaw.ca ([10.0.121.148]) by pd3mr3so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0E002HJRE0FOB0@pd3mr3so.prod.shaw.ca> for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:20:24 -0600 (MDT) Received: from slone.mungewell.org ([68.146.98.7]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0E00GPGRE0XH60@l-daemon> for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:20:24 -0600 (MDT) Received: from simon by slone.mungewell.org with local (Exim 4.61) (envelope-from ) id 1FnNDw-0002Wd-6Y for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:07:00 -0600 Date: Mon, 05 Jun 2006 16:07:00 -0600 From: simon Subject: Re: [GnomeMeeting-devel-list] Ekiga 2.0.2 In-reply-to: <1149543992.2508.40.camel@golgoth01> To: GnomeMeeting development mailing list Message-id: <20060605220700.GA9699@mungewell.org> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline References: <1149543992.2508.40.camel@golgoth01> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[AWL=-0.000, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 22:20:27 -0000 On Mon, Jun 05, 2006 at 11:46:32PM +0200, Damien Sandras wrote: > Hello to all, > > > Ekiga 2.0.2 is available on http://www.ekiga.org > Woo Woo another release party! What only a '.' release - oh, guess we'll have to share a can of Pop ;-) Seriously though, Thanks to Damien and all the other developers. Simon From siti@orcon.net.nz Tue Jun 6 05:25:31 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5963D3B00EF for ; Tue, 6 Jun 2006 05:25:31 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29810-06 for ; Tue, 6 Jun 2006 05:25:29 -0400 (EDT) Received: from dbmail-mx2.orcon.net.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id AB0663B00E2 for ; Tue, 6 Jun 2006 05:25:28 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx2.orcon.net.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k569PFih007843 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Jun 2006 21:25:16 +1200 Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Stephen Cook To: Derek Smithies In-Reply-To: References: Content-Type: text/plain Date: Tue, 06 Jun 2006 21:25:24 +1200 Message-Id: <1149585924.16149.8.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx2.orcon.net.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.532 tagged_above=-999 required=2 tests=[AWL=0.068, BAYES_00=-2.599] X-Spam-Score: -2.532 X-Spam-Level: Cc: GnomeMeeting development mailing list X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 09:25:31 -0000 On Tue, 2006-06-06 at 10:32 +1200, Derek Smithies wrote: > Hi, > Ok, just back from a long weekend (three days of not touching a computer) > and back into things. > > Stephen, I saw some comment from you on this topic at: > > http://siti.geek.nz/web/content/blogsection/4/26/ > > interesting - very interesting.. > > hey - now that is a coincidence. > I studied at Canterbury University also. Well that's cool :) Could you send me a private email with an instant messaging address that you use. BTW Damien and others we will keep as much information on the mailing list. To give you guys an update I have IAX2 calls going in ekiga although it needs a lot of work :). Then obviously the improvements to IAX2 in opal... > > > ============== > > Craig, I do not think moving to an offline conversation with Stephen is > > a good idea. Julien and myself are supposed to mentor the project. Your > > help is of course welcome, but we have to be kept informed. > Sorry Damien, but there will be a lot of offline comment. > I suspect that Stephen and I live in the same city. Sending a CC of phone > conversations etc will not be easy. > > I will endeavour though to keep you informed of what is happening, and we > can move everything forward towards the nirvana of iax2, sip, and h323 in > gnomemeeting. > > > =========================== > > Stephen, > > I am really happy to work with you on IAX2 - really happy. This > would be great for the project. It should be a good learning experience for me and I am sure it'll be good fun :) From dsandras@seconix.com Tue Jun 6 05:29:32 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 40D9E3B0A68 for ; Tue, 6 Jun 2006 05:29:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30841-02 for ; Tue, 6 Jun 2006 05:29:30 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 9F34C3B0A5C for ; Tue, 6 Jun 2006 05:29:30 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id DDF8E493CB; Tue, 6 Jun 2006 11:12:16 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30209-02; Tue, 6 Jun 2006 11:11:57 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 679F9492DA; Tue, 6 Jun 2006 11:11:57 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: Stephen Cook In-Reply-To: <1149585924.16149.8.camel@siti> References: <1149585924.16149.8.camel@siti> Content-Type: text/plain; charset=ISO-8859-15 Date: Tue, 06 Jun 2006 11:29:17 +0200 Message-Id: <1149586157.2470.27.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Cc: Derek Smithies , GnomeMeeting development mailing list X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 09:29:32 -0000 Le mardi 06 juin 2006 à 21:25 +1200, Stephen Cook a écrit : > On Tue, 2006-06-06 at 10:32 +1200, Derek Smithies wrote: > > Hi, > > Ok, just back from a long weekend (three days of not touching a computer) > > and back into things. > > > > Stephen, I saw some comment from you on this topic at: > > > > http://siti.geek.nz/web/content/blogsection/4/26/ > > > > interesting - very interesting.. > > > > hey - now that is a coincidence. > > I studied at Canterbury University also. > Well that's cool :) > > Could you send me a private email with an instant messaging address that > you use. > > BTW Damien and others we will keep as much information on the mailing > list. > > To give you guys an update I have IAX2 calls going in ekiga although it > needs a lot of work :). Then obviously the improvements to IAX2 in > opal... > Excellent ;-) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From jpuydt@free.fr Tue Jun 6 06:41:15 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 18B6B3B00E0 for ; Tue, 6 Jun 2006 06:41:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10263-10 for ; Tue, 6 Jun 2006 06:41:14 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id BD54A3B00D2 for ; Tue, 6 Jun 2006 06:41:13 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-57-82-249-29-56.adsl.proxad.net [82.249.29.56]) by smtp1-g19.free.fr (Postfix) with ESMTP id 909369AAC7 for ; Tue, 6 Jun 2006 12:41:12 +0200 (CEST) Message-ID: <44855BEC.1040306@free.fr> Date: Tue, 06 Jun 2006 12:41:48 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga References: <1149585924.16149.8.camel@siti> In-Reply-To: <1149585924.16149.8.camel@siti> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.585 tagged_above=-999 required=2 tests=[AWL=0.014, BAYES_00=-2.599] X-Spam-Score: -2.585 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 10:41:15 -0000 Stephen Cook a écrit : > Could you send me a private email with an instant messaging address that > you use. > > BTW Damien and others we will keep as much information on the mailing > list. > > To give you guys an update I have IAX2 calls going in ekiga although it > needs a lot of work :). Then obviously the improvements to IAX2 in > opal... This sounds great :-) Do all codecs work ok ? Could you make a short list of what is lacking, so your progress can easily be seen ? :-) Snark From siti@orcon.net.nz Tue Jun 6 08:02:29 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0E2D93B008B for ; Tue, 6 Jun 2006 08:02:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19082-05 for ; Tue, 6 Jun 2006 08:02:18 -0400 (EDT) Received: from dbmail-mx3.orcon.co.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 7C3DD3B0A9D for ; Tue, 6 Jun 2006 08:01:24 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx3.orcon.co.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k56C17Ej021180 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 7 Jun 2006 00:01:12 +1200 Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Stephen Cook To: GnomeMeeting development mailing list In-Reply-To: <44855BEC.1040306@free.fr> References: <1149585924.16149.8.camel@siti> <44855BEC.1040306@free.fr> Content-Type: text/plain; charset=utf-8 Date: Wed, 07 Jun 2006 00:01:17 +1200 Message-Id: <1149595277.17468.7.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx3.orcon.co.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.495 tagged_above=-999 required=2 tests=[AWL=-0.031, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.495 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 12:02:29 -0000 On Tue, 2006-06-06 at 12:41 +0200, Julien PUYDT wrote: > Stephen Cook a écrit : > > Could you send me a private email with an instant messaging address that > > you use. > > > > BTW Damien and others we will keep as much information on the mailing > > list. > > > > To give you guys an update I have IAX2 calls going in ekiga although it > > needs a lot of work :). Then obviously the improvements to IAX2 in > > opal... > > This sounds great :-) > > Do all codecs work ok ? I have only tried ULAW > > Could you make a short list of what is lacking, so your progress can > easily be seen ? In Ekiga: * Url handler for IAX2 * If I have time in the future -- Refactor protocol components in ekiga In Iax2: * Call Hold * Transfer Calls * Register > > :-) > > Snark > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list From jan.schampera@web.de Tue Jun 6 11:41:54 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 300F43B00A7 for ; Tue, 6 Jun 2006 11:41:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01645-10 for ; Tue, 6 Jun 2006 11:41:52 -0400 (EDT) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by menubar.gnome.org (Postfix) with ESMTP id 5016E3B0117 for ; Tue, 6 Jun 2006 11:41:52 -0400 (EDT) Received: from fwd28.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1Fndgj-000497-06; Tue, 06 Jun 2006 17:41:49 +0200 Received: from mail.home.thebonsai.de (SxWWnGZHgenZylg6UcgKDR7M2nKdws-wslY10mn82PtIepb06FcVZ4@[84.147.103.162]) by fwd28.sul.t-online.de with esmtp id 1Fndgc-1VKS9o0; Tue, 6 Jun 2006 17:41:42 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id B18576B0FF for ; Tue, 6 Jun 2006 17:41:40 +0200 (CEST) Date: Tue, 6 Jun 2006 17:37:41 +0200 From: Jan Schampera To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga Message-ID: <20060606173741.7739fbf0@localhost.localdomain> In-Reply-To: <1149595277.17468.7.camel@siti> References: <1149585924.16149.8.camel@siti> <44855BEC.1040306@free.fr> <1149595277.17468.7.camel@siti> Organization: private X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: SxWWnGZHgenZylg6UcgKDR7M2nKdws-wslY10mn82PtIepb06FcVZ4@t-dialin.net X-TOI-MSGID: d621850d-8c24-4c96-bc80-424b3278e7ee X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.966 tagged_above=-999 required=2 tests=[AWL=0.632, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.966 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 15:41:54 -0000 On Wed, 07 Jun 2006 00:01:17 +1200 Stephen Cook wrote: > In Ekiga: > * Url handler for IAX2 > * If I have time in the future -- Refactor protocol components in > ekiga > > In Iax2: > * Call Hold > * Transfer Calls > * Register I X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C93A63B023C for ; Tue, 6 Jun 2006 18:32:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26160-07 for ; Tue, 6 Jun 2006 18:32:35 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by menubar.gnome.org (Postfix) with ESMTP id EE5BE3B0124 for ; Tue, 6 Jun 2006 18:32:34 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x31so57152pye for ; Tue, 06 Jun 2006 15:32:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=PWNZjwnHiPmpdYl2MsXZ9YZF9d4xYPXUg1ADy6s6gr7kpZpuMn+pMk4SiPqw6G91hexsOp1xDFUNDwMZyQ+X01mIY9TDqR0zrylP3BBJTKYCjcgQm4+vLCMe9AVXFuvgQ8NYOFrWwmRpr+zSS1OaVc2h2FssBRFPxlSabyu06bg= Received: by 10.35.76.9 with SMTP id d9mr79929pyl; Tue, 06 Jun 2006 15:32:33 -0700 (PDT) Received: by 10.35.9.3 with HTTP; Tue, 6 Jun 2006 15:32:33 -0700 (PDT) Message-ID: <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> Date: Tue, 6 Jun 2006 18:32:33 -0400 From: "mcquaid mcquaid" To: "GnomeMeeting development mailing list" Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode In-Reply-To: <1149246461.2966.28.camel@golgoth01> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7731_6834590.1149633153798" References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> <1149246461.2966.28.camel@golgoth01> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.041 tagged_above=-999 required=2 tests=[AWL=0.062, BAYES_00=-2.599, HTML_40_50=0.496, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.041 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 22:32:38 -0000 ------=_Part_7731_6834590.1149633153798 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Just a user, I'm curious as to why the trend of throwing opengl at everything. On one hand I think it's really cool, but this isn't like xgl where we want wobbly windows or something, just accelerated video. Isn't that what hardware video overlay is for? It takes a large burden off the cpu for video playback. Would benefit more people as some don't have prope= r opengl drivers. On 6/2/06, Damien Sandras wrote: > > Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit : > > So configure.in is hand-generated? Surprising. > > > > That's te way it works. You write configure.in and configure is > generated from there. I guess you are confusing things here. > > > 1) How exactly do I add the opengl ( libgl ) library? > > > > By writing autconf code in configure.in. No idea exactly how it should > be done. > > > 2) Xrandr is mentioned in the Makefile, but is not in configure.in. Ho= w > > exactly does it get put into the Makefile? > > > > Probably by an external library that we are using. > > > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I didn't wan= t > > to code against a moving target. > > > > Yes. It is even OK if you do not provide the configure.in code, but only > the OpenGL Ekiga code. > > > Thanks, > > > > -Dan > > > > Damien Sandras wrote: > > > > >Le mercredi 31 mai 2006 =E0 12:41 -0700, Dan Sandberg a =E9crit : > > > > > > > > >>I'd imagine it would work on win32, but don't know. > > >> > > >> > > >> > > > > > >Probably. > > > > > > > > > > > >>I'll work on the patches. > > >> > > >>Where's the right place to add required libraries like openGL? > > >> > > >> > > > > > >In configure.in. > > > > > > > > > > > >>configure.in seems to be autogenerated by something, but whatever it > is > > >>doesn't seem to be in the CVS snapshot... > > >> > > >> > > >> > > > > > >configure.in is in the CVS snapshot. > > > > > > > > > > > > > > >>Thanks, > > >> > > >>-Dan > > >> > > >>Julien PUYDT wrote: > > >> > > >> > > >> > > >>>Dan Sandberg a =E9crit : > > >>> > > >>> > > >>> > > >>>>How should we proceed? I could just send you an updated > gui/main.cpp > > >>>>file... > > >>>> > > >>>> > > >>>I'd like to see patches instead of full files, preferably independan= t > > >>>on each others. > > >>> > > >>>There's also the question of the portability of this : since you > > >>>mention SDL, I guess this will work great on win32 too ? > > >>> > > >>>Snark > > >>>_______________________________________________ > > >>>Gnomemeeting-devel-list mailing list > > >>>Gnomemeeting-devel-list@gnome.org > > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >>> > > >>> > > >>> > > >>_______________________________________________ > > >>Gnomemeeting-devel-list mailing list > > >>Gnomemeeting-devel-list@gnome.org > > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >> > > >> > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > -- > _ Damien Sandras > (o- > //\ Ekiga Softphone: http://www.ekiga.org/ > v_/_ FOSDEM 2006 : http://www.fosdem.org/ > SIP Phone : sip:dsandras@ekiga.net > sip:600000@ekiga.net > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > ------=_Part_7731_6834590.1149633153798 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Just a user, I'm curious as to why the trend of throwing opengl at everythi= ng.  On one hand I think it's really cool, but this isn't like xgl whe= re we want wobbly windows or something, just accelerated video.  Isn't= that what hardware video overlay is for?  It takes a large burden off= the cpu for video playback.  Would benefit more people as some don't = have proper opengl drivers.

On 6/2/06, Damien Sandras <dsand= ras@seconix.com> wrote:
Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit :
> = So configure.in is hand-generated? = ; Surprising.
>

That's te way it works. You write configure.in and configure is
generated from there. I guess you are = confusing things here.

> 1) How exactly do I add the opengl ( lib= gl ) library?
>

By writing autconf code in configure.in. No idea exactly how it should
be done.

> 2) = Xrandr is mentioned in the Makefile, but is not in configure.in.  How
> exactly does it get put in= to the Makefile?
>

Probably by an external library that we are using.

&= gt; 3) Is it ok if I send in a patch that is for Ekiga 2.0.1?  I = didn't want
> to code against a moving target.
>

Yes. It= is even OK if you do not provide the=20 configure.in code, but only
the Open= GL Ekiga code.

> Thanks,
>
> -Dan
>
> Dam= ien Sandras wrote:
>
> >Le mercredi 31 mai 2006 =E0 12:41 -0= 700, Dan Sandberg a =E9crit :
> >
> >
> >>I'd imagine it would work on win= 32, but don't know.
> >>
> >>
> >>
&= gt; >
> >Probably.
> >
> >
> >
> >>I'll work on the patches.
> >>
> >>Whe= re's the right place to add required libraries like openGL?
> >>= ;
> >>
> >
> >In configure.in.
> >
> >
> >
> >>configure.in seems to be autogenerated by= something, but whatever it is
> >>doesn't seem to be in the CV= S snapshot...
> >>
> >>
> >>
> >
> &g= t;configure.in is in the CVS snapshot.<= br>> >
> >
> >
> >
> >>Thanks,
> >>
> >>-Dan
> >>
> >>Jul= ien PUYDT wrote:
> >>
> >>
> >>
>= >>>Dan Sandberg a =E9crit :
> >>>
> >>= >
> >>>
> >>>>How should we proceed? &= nbsp;I could just send you an updated gui/main.cpp
> >>>>= file...
> >>>>
> >>>>
> >>&= gt;I'd like to see patches instead of full files, preferably independant
> >>>on each others.
> >>>
> >>&= gt;There's also the question of the portability of this : since you
>= >>>mention SDL, I guess this will work great on win32 too ?
> >>>
> >>>Snark
> >>>___________= ____________________________________
> >>>Gnomemeeting-devel= -list mailing list
> >>> Gnomemeeting-devel-list@gnome.org
> >>>http://mail.gnome= .org/mailman/listinfo/gnomemeeting-devel-list
> >>>
> >>>
> >>>
> >>____________________= ___________________________
> >>Gnomemeeting-devel-list mailing= list
> >> Gnomemeeting-devel-list@gnome.org
> >>http://mail.gnome.org= /mailman/listinfo/gnomemeeting-devel-list
> >>
> >= >
>
> _______________________________________________
> Gn= omemeeting-devel-list mailing list
> Gnomemeeting-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
-- _      Damien Sandras
(o-
//\ &n= bsp;   Ekiga Softphone: http://= www.ekiga.org/
v_/_    FOSDEM 2006  &n= bsp; : http://www.fosdem.org/
       &nb= sp;SIP Phone      : sip:dsandras@ekiga.net
    &nbs= p;            &= nbsp;       sip:600000@ekiga.net

____________________________________= ___________
Gnomemeeting-devel-list mailing list
Gnomemeeting-devel-list@gnome.org
http://mail.= gnome.org/mailman/listinfo/gnomemeeting-devel-list

------=_Part_7731_6834590.1149633153798-- From x@cs.stanford.edu Tue Jun 6 18:47:00 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5D25C3B036D for ; Tue, 6 Jun 2006 18:46:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26984-04 for ; Tue, 6 Jun 2006 18:46:56 -0400 (EDT) Received: from smtp104.plus.mail.mud.yahoo.com (smtp104.plus.mail.mud.yahoo.com [68.142.206.237]) by menubar.gnome.org (Postfix) with SMTP id 502483B0124 for ; Tue, 6 Jun 2006 18:46:56 -0400 (EDT) Received: (qmail 87952 invoked from network); 6 Jun 2006 22:46:55 -0000 Received: from unknown (HELO ?192.168.2.47?) (dan?sandberg@71.138.128.214 with plain) by smtp104.plus.mail.mud.yahoo.com with SMTP; 6 Jun 2006 22:46:54 -0000 Message-ID: <448605B0.6080504@cs.stanford.edu> Date: Tue, 06 Jun 2006 15:46:08 -0700 From: Dan Sandberg User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> <1149246461.2966.28.camel@golgoth01> <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> In-Reply-To: <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.808 tagged_above=-999 required=2 tests=[AWL=-0.593, BAYES_00=-2.599, SPF_SOFTFAIL=1.384] X-Spam-Score: -1.808 X-Spam-Level: Cc: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 22:47:00 -0000 I could be wrong, but I believe that video overlay moves the data direct from a capture card to the video card, bypassing the CPU. Since we're trying to display images that come from over the network, there's no way to bypass the CPU. And doing a nice looking resize from 176x144 to 640x480 is quite slow. Then you have to copy the whole 640x480 image to the display card, which is slow. With OpenGL you just copy the 176x144 image to the video card, and have it do the resize. Cheers, -Dan mcquaid mcquaid wrote: > Just a user, I'm curious as to why the trend of throwing opengl at > everything. On one hand I think it's really cool, but this isn't like > xgl where we want wobbly windows or something, just accelerated > video. Isn't that what hardware video overlay is for? It takes a > large burden off the cpu for video playback. Would benefit more > people as some don't have proper opengl drivers. > > On 6/2/06, *Damien Sandras* > wrote: > > Le vendredi 02 juin 2006 à 03:03 -0700, Dan Sandberg a écrit : > > So configure.in is > hand-generated? Surprising. > > > > That's te way it works. You write configure.in > and configure is > generated from there. I guess you are confusing things here. > > > 1) How exactly do I add the opengl ( libgl ) library? > > > > By writing autconf code in configure.in . No > idea exactly how it should > be done. > > > 2) Xrandr is mentioned in the Makefile, but is not in > configure.in . How > > exactly does it get put into the Makefile? > > > > Probably by an external library that we are using. > > > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I > didn't want > > to code against a moving target. > > > > Yes. It is even OK if you do not provide the configure.in > code, but only > the OpenGL Ekiga code. > > > Thanks, > > > > -Dan > > > > Damien Sandras wrote: > > > > >Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > > > > > > > > >>I'd imagine it would work on win32, but don't know. > > >> > > >> > > >> > > > > > >Probably. > > > > > > > > > > > >>I'll work on the patches. > > >> > > >>Where's the right place to add required libraries like openGL? > > >> > > >> > > > > > >In configure.in . > > > > > > > > > > > >>configure.in seems to be autogenerated > by something, but whatever it is > > >>doesn't seem to be in the CVS snapshot... > > >> > > >> > > >> > > > > > >configure.in is in the CVS snapshot. > > > > > > > > > > > > > > >>Thanks, > > >> > > >>-Dan > > >> > > >>Julien PUYDT wrote: > > >> > > >> > > >> > > >>>Dan Sandberg a écrit : > > >>> > > >>> > > >>> > > >>>>How should we proceed? I could just send you an updated > gui/main.cpp > > >>>>file... > > >>>> > > >>>> > > >>>I'd like to see patches instead of full files, preferably > independant > > >>>on each others. > > >>> > > >>>There's also the question of the portability of this : since you > > >>>mention SDL, I guess this will work great on win32 too ? > > >>> > > >>>Snark > > >>>_______________________________________________ > > >>>Gnomemeeting-devel-list mailing list > > >>> Gnomemeeting-devel-list@gnome.org > > > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >>> > > >>> > > >>> > > >>_______________________________________________ > > >>Gnomemeeting-devel-list mailing list > > >> Gnomemeeting-devel-list@gnome.org > > > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >> > > >> > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > -- > _ Damien Sandras > (o- > //\ Ekiga Softphone: http://www.ekiga.org/ > v_/_ FOSDEM 2006 : http://www.fosdem.org/ > SIP Phone : sip:dsandras@ekiga.net > > sip:600000@ekiga.net > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > From mcquaidster@gmail.com Tue Jun 6 19:15:44 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1CB1D3B0100 for ; Tue, 6 Jun 2006 19:15:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28543-05 for ; Tue, 6 Jun 2006 19:15:41 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id 15D153B033F for ; Tue, 6 Jun 2006 19:15:40 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x31so65185pye for ; Tue, 06 Jun 2006 16:15:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Mcduoi+u93PszObMtVWeXgYeQW4VI1eW7YkgZ+7d03TZ67OjKeE6aoo507wYkIOly9icd2mdZ2fuDTkH7FKrnfSoGo+jOXhxLaobIUCU6gQdxyXgRqVTPVs16J/2P3hFDJ8K1ELtr1xuKRWtdbXceWGlDpZn2R3lxDak1f6E47c= Received: by 10.35.40.10 with SMTP id s10mr72093pyj; Tue, 06 Jun 2006 16:15:39 -0700 (PDT) Received: by 10.35.9.3 with HTTP; Tue, 6 Jun 2006 16:15:39 -0700 (PDT) Message-ID: <58a398810606061615s6a801fected291a67dbb85214@mail.gmail.com> Date: Tue, 6 Jun 2006 19:15:39 -0400 From: "mcquaid mcquaid" To: "Dan Sandberg" Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode In-Reply-To: <448605B0.6080504@cs.stanford.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8108_3516387.1149635739799" References: <447CCA43.3@stdout.at> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> <1149246461.2966.28.camel@golgoth01> <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> <448605B0.6080504@cs.stanford.edu> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.242 tagged_above=-999 required=2 tests=[AWL=0.223, BAYES_00=-2.599, HTML_50_60=0.134, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.242 X-Spam-Level: Cc: GnomeMeeting development mailing list X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 23:15:44 -0000 ------=_Part_8108_3516387.1149635739799 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hmm, again I don't know much about this but I think what you describe can b= e handled by hardware video overlay. Just a quick googling has this about hardware video overlay at the zoomplayer's website: http://www.inmatrix.com/zplayer/highlights/vidrender.shtml *The Video Overlay:* > At around 1995, when MPEG1 (VCD) playback started to become popular on th= e > PC, the actual processing power of the PC was not quite strong enough to > play such content. The display card manufacturers at the time came up wit= h a > solution called "The Video Overlay". The Video Overlay is a special hardw= are > on the display card which is used to perform several video-display featur= es > in hardware (Stretching, Color-Space Conversion, etc...), thus allowing > smooth playback of video at no cost to the CPU. It does go on to say that video rendering via dx9 (and thus I assume opengl) provide better image quality and don't suffer from some multimonitor issues with video overlay. Afaik, only one display can have hardware overlay so that's what he's referring to there. But, for the most part, it sounds like hardware overlay would be a nice solution as well that just about everyone would benefit from as again, ther= e are still a lot of people without good opengl in linux but most probably functional hardware overlay. Maybe an option for both? On 6/6/06, Dan Sandberg wrote: > > I could be wrong, but I believe that video overlay moves the data direct > from a capture card to the video card, bypassing the CPU. Since we're > trying to display images that come from over the network, there's no way > to bypass the CPU. And doing a nice looking resize from 176x144 to > 640x480 is quite slow. Then you have to copy the whole 640x480 image to > the display card, which is slow. With OpenGL you just copy the 176x144 > image to the video card, and have it do the resize. > > Cheers, > > -Dan > > mcquaid mcquaid wrote: > > Just a user, I'm curious as to why the trend of throwing opengl at > > everything. On one hand I think it's really cool, but this isn't like > > xgl where we want wobbly windows or something, just accelerated > > video. Isn't that what hardware video overlay is for? It takes a > > large burden off the cpu for video playback. Would benefit more > > people as some don't have proper opengl drivers. > > > > On 6/2/06, *Damien Sandras* > > wrote: > > > > Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit : > > > So configure.in is > > hand-generated? Surprising. > > > > > > > That's te way it works. You write configure.in > > and configure is > > generated from there. I guess you are confusing things here. > > > > > 1) How exactly do I add the opengl ( libgl ) library? > > > > > > > By writing autconf code in configure.in . No > > idea exactly how it should > > be done. > > > > > 2) Xrandr is mentioned in the Makefile, but is not in > > configure.in . How > > > exactly does it get put into the Makefile? > > > > > > > Probably by an external library that we are using. > > > > > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I > > didn't want > > > to code against a moving target. > > > > > > > Yes. It is even OK if you do not provide the configure.in > > code, but only > > the OpenGL Ekiga code. > > > > > Thanks, > > > > > > -Dan > > > > > > Damien Sandras wrote: > > > > > > >Le mercredi 31 mai 2006 =E0 12:41 -0700, Dan Sandberg a =E9crit = : > > > > > > > > > > > >>I'd imagine it would work on win32, but don't know. > > > >> > > > >> > > > >> > > > > > > > >Probably. > > > > > > > > > > > > > > > >>I'll work on the patches. > > > >> > > > >>Where's the right place to add required libraries like openGL? > > > >> > > > >> > > > > > > > >In configure.in . > > > > > > > > > > > > > > > >>configure.in seems to be autogenerated > > by something, but whatever it is > > > >>doesn't seem to be in the CVS snapshot... > > > >> > > > >> > > > >> > > > > > > > >configure.in is in the CVS snapshot. > > > > > > > > > > > > > > > > > > > >>Thanks, > > > >> > > > >>-Dan > > > >> > > > >>Julien PUYDT wrote: > > > >> > > > >> > > > >> > > > >>>Dan Sandberg a =E9crit : > > > >>> > > > >>> > > > >>> > > > >>>>How should we proceed? I could just send you an updated > > gui/main.cpp > > > >>>>file... > > > >>>> > > > >>>> > > > >>>I'd like to see patches instead of full files, preferably > > independant > > > >>>on each others. > > > >>> > > > >>>There's also the question of the portability of this : since > you > > > >>>mention SDL, I guess this will work great on win32 too ? > > > >>> > > > >>>Snark > > > >>>_______________________________________________ > > > >>>Gnomemeeting-devel-list mailing list > > > >>> Gnomemeeting-devel-list@gnome.org > > > > > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > >>> > > > >>> > > > >>> > > > >>_______________________________________________ > > > >>Gnomemeeting-devel-list mailing list > > > >> Gnomemeeting-devel-list@gnome.org > > > > > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > >> > > > >> > > > > > > _______________________________________________ > > > Gnomemeeting-devel-list mailing list > > > Gnomemeeting-devel-list@gnome.org > > > > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > -- > > _ Damien Sandras > > (o- > > //\ Ekiga Softphone: http://www.ekiga.org/ > > v_/_ FOSDEM 2006 : http://www.fosdem.org/ > > SIP Phone : sip:dsandras@ekiga.net > > > > sip:600000@ekiga.net > > > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > ------=_Part_8108_3516387.1149635739799 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hmm, again I don't know much about this but I think what you describe can b= e handled by
hardware video overlay.

Just a quick googling has t= his about hardware video overlay at the zoomplayer's website:

http://www.inmatrix.com/zplayer/highlights/vidrender.shtml

The Video Overlay:
At around 1995, when MPEG1 (VCD) playback started to become popular on the = PC, the actual processing power of the PC was not quite strong enough to play such content. The display card manufacturers a= t the time came up with a solution called "The Video Overlay". The Video Overlay is a special hardware on = the display card which is used to perform several video-display features in hardware (Stretching, Color-Space Conversion, etc...), thus all= owing smooth playback of video at no cost to the CPU.


It does go on to say  that video rend= ering via dx9 (and thus I assume opengl)  provide better image quality= and don't suffer from some multimonitor issues with video overlay.
Afai= k, only one display can have hardware overlay so that's what he's referring= to there.

But, for the most part, it sounds like hardware overlay would be a = nice solution as well that just about everyone would benefit from as again,= there are still a lot of people without good opengl in linux but most prob= ably functional hardware overlay.

Maybe an option for both? 

On 6/6/06, Dan Sandberg <<= a href=3D"mailto:x@cs.stanford.edu">x@cs.stanford.edu> wrote:=
I could be wrong, but I believe that video overlay moves the data directfrom a capture card to the video card, bypassing the CPU.  Since= we're
trying to display images that come from over the network, there's= no way
to bypass the CPU.  And doing a nice looking resize from 176x= 144 to
640x480 is quite slow.  Then you have to copy the whole= 640x480 image to
the display card, which is slow.  With OpenG= L you just copy the 176x144
image to the video card, and have it do the resize.

Cheers,
<= br>-Dan

mcquaid mcquaid wrote:
> Just a user, I'm curious as t= o why the trend of throwing opengl at
> everything.  On one= hand I think it's really cool, but this isn't like
> xgl where we want wobbly windows or something, just accelerated> video.  Isn't that what hardware video overlay is for? = ; It takes a
> large burden off the cpu for video playback. = ; Would benefit more
> people as some don't have proper opengl drivers.
>
> On 6/= 2/06, *Damien Sandras* <dsandras= @seconix.com
> <mailto: dsandras@seconix.com>> wrote:
>
>   &n= bsp; Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit :
= >     > So config= ure.in < http://configure.in> is
>     hand-generat= ed?  Surprising.
>     >
>
= >     That's te way it works. You write configure.in
>     < http://configure.in> and configure is
>    = ; generated from there. I guess you are confusing things here.
>
&= gt;     > 1) How exactly do I add the opengl ( libgl= ) library?
>     >
>
>     By writing autconf code in configure.in <http:= //configure.in>. No
>     idea exactly how= it should
>     be done.
>
>     > 2) Xrandr is mentioned in the Makefile, b= ut is not in
>     configure.in <http://configure.in<= /a>>.  How
>     > exactly does i= t get put into the Makefile?
>     >
>
>   &nbs= p; Probably by an external library that we are using.
>
> =     > 3) Is it ok if I send in a patch that is for Ekiga = 2.0.1?  I
>     didn't want
>&nbs= p;    > to code against a moving target.
>     >
>
>   &nbs= p; Yes. It is even OK if you do not provide the configure.in
>     <http://configure.in> code, but only
>     the OpenGL Ekiga code.
>
> &n= bsp;   > Thanks,
>     >
>&= nbsp;    > -Dan
>     >
&= gt;     > Damien Sandras wrote:
>  &= nbsp;  >
>     > >Le mercredi 31 ma= i 2006 =E0 12:41 -0700, Dan Sandberg a =E9crit :
>     > >
>     = > >
>     > >>I'd imagine it would= work on win32, but don't know.
>     > >&g= t;
>     > >>
>   &= nbsp; > >>
>     > >
>     > >Probably.
>  &nbs= p;  > >
>     > >
> &= nbsp;   > >
>     > >>I'= ll work on the patches.
>     > >>
&g= t;     > >>Where's the right place to add requ= ired libraries like openGL?
>     > >>
>   &nb= sp; > >>
>     > >
> &n= bsp;   > >In configure.in <http://configure.in>.
>=      > >
>     > >
>     = > >
>     > >>configure.in <http://con= figure.in> seems to be autogenerated
>    = by something, but whatever it is
>     > >>doesn't seem to be in the CVS= snapshot...
>     > >>
> &nb= sp;   > >>
>     > >>=
>     > >
>     = > >configure.in <http://configure.in> is in = the CVS snapshot.
>     > >
> &n= bsp;   > >
>     > >
>= ;     > >
>     > &g= t;>Thanks,
>     > >>
>     > >>-Dan
>   = ;  > >>
>     > >>Julien P= UYDT wrote:
>     > >>
> &nbs= p;   > >>
>     > >><= br>>     > >>>Dan Sandberg a =E9crit :
>     > >>>
>   = ;  > >>>
>     > >>>=
>     > >>>>How should we proceed= ?  I could just send you an updated
>   &nbs= p; gui/main.cpp
>     > >>>>file..= .
>     > >>>>
>  &= nbsp;  > >>>>
>     > >= >>I'd like to see patches instead of full files, preferably
>&n= bsp;    independant
>     > >= ;>>on each others.
>     > >>>
>   = ;  > >>>There's also the question of the portability of th= is : since you
>     > >>>mention SDL= , I guess this will work great on win32 too ?
>   &nbs= p; > >>>
>     > >>>Snark
>  =    > >>>_____________________________________________= __
>     > >>>Gnomemeeting-devel-list= mailing list
>     > >>> Gnomemeeting-devel-list@gnome.org
>     <m= ailto:Gnomemeeting-dev= el-list@gnome.org>
>     > >>>= http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>&= nbsp;    > >>>
>     &= gt; >>>
>     > >>>
>&= nbsp;    > >>______________________________________= _________
>     > >>Gnomemeeting-devel-list maili= ng list
>     > >> Gnomemeeting-devel-list@gnome.org
&g= t;     <mailto: Gnomemeeting-devel-list@gnome.org>
>     &= gt; >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list<= /a>
>     > >>
>     > >>
>   &nb= sp; >
>     > _____________________________= __________________
>     > Gnomemeeting-devel-= list mailing list
>     > Gnomemeeting-devel-list@gnome.org
>     <m= ailto:Gnomemeeting-dev= el-list@gnome.org>
>     > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>&= nbsp;    --
>     _  &nb= sp;   Damien Sandras
>     (o-
= >     //\     Ekiga Softphone: <= a href=3D"http://www.ekiga.org/">http://www.ekiga.org/
>     v_/_    FOSDEM 200= 6    : http://www.fo= sdem.org/
>         =     SIP Phone      : sip:dsandras@ekiga.net
> =     <mailto: sip:dsandr= as@ekiga.net>
>        = ;            &n= bsp;         sip:600000@ekiga.net
>   &n= bsp; <mailto: sip:600000@ekiga.net>
>= ;
>     _________________________________________= ______
>     Gnomemeeting-devel-list mailing list=
>     Gnomemeeting-devel-list@gnome.org
>     <m= ailto:Gnomemeeting-dev= el-list@gnome.org>
>     http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>&= nbsp;    <http://mail.gnome.org/mailman/listinfo/gnomemee= ting-devel-list >
>
>
> ----------------------------------------------= --------------------------
>
> ________________________________= _______________
> Gnomemeeting-devel-list mailing list
> Gnomemeeting-devel-list@gnome.org
> http://mail.gnome.org/mailman= /listinfo/gnomemeeting-devel-list
>

------=_Part_8108_3516387.1149635739799-- From stefan@watri.org.au Wed Jun 7 00:39:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 26FE33B0B45 for ; Wed, 7 Jun 2006 00:39:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12142-08 for ; Wed, 7 Jun 2006 00:39:13 -0400 (EDT) Received: from asclepius.uwa.edu.au (asclepius.uwa.edu.au [130.95.128.56]) by menubar.gnome.org (Postfix) with ESMTP id 1153F3B022D for ; Wed, 7 Jun 2006 00:39:11 -0400 (EDT) Received: from asclepius.kas (localhost.localdomain [127.0.0.1]) by asclepius.uwa.edu.au (Postfix) with SMTP id 9EF11184629 for ; Wed, 7 Jun 2006 12:39:05 +0800 (WST) Received: from asclepius (localhost.localdomain [127.0.0.1]) by asclepius.prekas (Postfix) with SMTP id 7CB52188123 for ; Wed, 7 Jun 2006 12:39:05 +0800 (WST) X-UWA-Client-IP: 130.95.28.15 (UWA) Received: from ns1.watri.uwa.edu.au (ns1.watri.org.au [130.95.28.15]) by asclepius.extinput (Postfix) with ESMTP id 6CCE5188174 for ; Wed, 7 Jun 2006 12:39:05 +0800 (WST) Received: from gluttony (gluttony.watri.org.au [130.95.29.76]) by ns1.watri.uwa.edu.au (8.13.1/8.13.1) with ESMTP id k574d4dE023954 for ; Wed, 7 Jun 2006 12:39:04 +0800 (WST) Message-Id: <200606070439.k574d4dE023954@ns1.watri.uwa.edu.au> From: =?iso-8859-1?Q?Stefan_Br=FCns?= To: "'GnomeMeeting development mailing list'" Subject: RE: [GnomeMeeting-devel-list] Full Screen Mode Date: Wed, 7 Jun 2006 12:41:40 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <448605B0.6080504@cs.stanford.edu> Thread-Index: AcaJu2+MfoUGcqUFRii2sxvr70Y3NQALgJIg X-SpamTest-Info: Profile: Formal (387/060606) X-SpamTest-Info: Profile: Detect Hard [UCS 290904] X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking Spam - Subject (UCS) [02-08-04] X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.176 tagged_above=-999 required=2 tests=[AWL=-1.125, BAYES_40=-0.185, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] X-Spam-Score: -1.176 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 04:39:16 -0000 > -----Original Message----- > From: gnomemeeting-devel-list-bounces@gnome.org > [mailto:gnomemeeting-devel-list-bounces@gnome.org] On Behalf > Of Dan Sandberg > Sent: Wednesday, 7 June 2006 6:46 AM > To: GnomeMeeting development mailing list > Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode > > I could be wrong, but I believe that video overlay moves the > data direct > >from a capture card to the video card, bypassing the CPU. > Since we're > trying to display images that come from over the network, > there's no way > to bypass the CPU. And doing a nice looking resize from 176x144 to > 640x480 is quite slow. Then you have to copy the whole > 640x480 image to > the display card, which is slow. With OpenGL you just copy > the 176x144 > image to the video card, and have it do the resize. Just to clarify some things: Video overlay over XV support scaling in hardware, and colorspace transforms. Unfortunately, most graphic cards support only one overlay at a time. In case you only have a single video, this is fine, but as soon as you have multiple (local/remote, maybe conference anytime in the future), you have to do the compositing before uploading the image to the card. In case of Picture in Picture, this means that you a) Scale the to be small video down, compose it into the large one, and upload the composed image. Drawback: Also the small image may end up as large as an unscaled CIF image, it will have a lower resolution, due to the downscaling. or b) Scale the to be large image up, and compose the small image into it. Also the small image will have its full resolution (it may be a CIF (352x288) image on a 1024x768 or larger screen), the upscaling of the large image adds a lot of burden to the CPU and memory transfers. On the other hand, if you use OpenGL textures, you have all the benefits: - You can upload every video to a different texture, every video ends up on the screen with all the available resolution, all the scaling is done on the GPU (which is very efficient for this). - Most cards support YUV colorspaces for textures, so color transform can be done on the card. - As the different videos stream end up on different textures, you may have the local video with full 25fps framerate, and the remote with something like 10fps. - Superimposing any text (Chat, callers name, new incoming call ...) comes down to putting the text into just another texture. This may be easily alpha blended, with full screen resolution (if you superimpose text on the video directly, you can only use the videos resolution, and edges may look really strange due to the UV subsampling). - You may due almost arbitrary transforms on the video, without burdening the CPU (have a look at the Conference feature of iChat AV to see what I mean). Greetings, Stefan From t.schorpp@gmx.de Wed Jun 7 03:35:24 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 125143B0C5F for ; Wed, 7 Jun 2006 03:35:24 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23077-04 for ; Wed, 7 Jun 2006 03:35:22 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by menubar.gnome.org (Postfix) with SMTP id 544083B0368 for ; Wed, 7 Jun 2006 03:35:21 -0400 (EDT) Received: (qmail invoked by alias); 07 Jun 2006 07:35:19 -0000 Received: from p85.212.144.48.tisdip.tiscali.de (EHLO [192.168.1.100]) [85.212.144.48] by mail.gmx.net (mp029) with SMTP; 07 Jun 2006 09:35:19 +0200 X-Authenticated: #17142692 Message-ID: <448681B6.5000204@gmx.de> Date: Wed, 07 Jun 2006 09:35:18 +0200 From: thomas schorpp User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1 X-Accept-Language: de, en-us MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode References: <200606070439.k574d4dE023954@ns1.watri.uwa.edu.au> In-Reply-To: <200606070439.k574d4dE023954@ns1.watri.uwa.edu.au> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.476 tagged_above=-999 required=2 tests=[AWL=-0.011, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] X-Spam-Score: -2.476 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: t.schorpp@gmx.de, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 07:35:24 -0000 Stefan Brüns wrote: >>-----Original Message----- >>From: gnomemeeting-devel-list-bounces@gnome.org >>[mailto:gnomemeeting-devel-list-bounces@gnome.org] On Behalf >>Of Dan Sandberg >>Sent: Wednesday, 7 June 2006 6:46 AM >>To: GnomeMeeting development mailing list >>Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode >> >>I could be wrong, but I believe that video overlay moves the >>data direct >>>from a capture card to the video card, bypassing the CPU. >>Since we're >>trying to display images that come from over the network, >>there's no way >>to bypass the CPU. And doing a nice looking resize from 176x144 to >>640x480 is quite slow. Then you have to copy the whole >>640x480 image to >>the display card, which is slow. With OpenGL you just copy >>the 176x144 >>image to the video card, and have it do the resize. > > > Just to clarify some things: > > Video overlay over XV support scaling in hardware, and colorspace > transforms. are You sure? ive some display apps here which can switch between XV and "real overlay". kvdr, tvtime, xawtv... XV can use significant high cpu load in my experience here... > > Unfortunately, most graphic cards support only one overlay at a time. not sure about this, too. all the chips i had since ati mach64 supported at least 2 overlays at a time. kvdr supports even up to 4 overlays(?) on modern cards respectively. http://www.s.netic.de/gfiala/ > In > case you only have a single video, this is fine, but as soon as you have > multiple (local/remote, maybe conference anytime in the future), you have to > do the compositing before uploading the image to the card. In case of > Picture in Picture, this means that you > > a) Scale the to be small video down, compose it into the large one, and > upload the composed image. Drawback: Also the small image may end up as > large as an unscaled CIF image, it will have a lower resolution, due to the > downscaling. > > or > b) Scale the to be large image up, and compose the small image into it. Also > the small image will have its full resolution (it may be a CIF (352x288) > image on a 1024x768 or larger screen), the upscaling of the large image adds > a lot of burden to the CPU and memory transfers. > > On the other hand, if you use OpenGL textures, you have all the benefits: > - You can upload every video to a different texture, every video ends up on > the screen with all the available resolution, all the scaling is done on the > GPU (which is very efficient for this). > - Most cards support YUV colorspaces for textures, so color transform can be > done on the card. > - As the different videos stream end up on different textures, you may have > the local video with full 25fps framerate, and the remote with something > like 10fps. > - Superimposing any text (Chat, callers name, new incoming call ...) comes > down to putting the text into just another texture. This may be easily alpha > blended, with full screen resolution (if you superimpose text on the video > directly, you can only use the videos resolution, and edges may look really > strange due to the UV subsampling). > - You may due almost arbitrary transforms on the video, without burdening > the CPU (have a look at the Conference feature of iChat AV to see what I > mean). > > Greetings, > is there no standard "network video class" for the application layer somewhere? > Stefan tom From jpuydt@free.fr Wed Jun 7 07:50:57 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 57F3B3B030A for ; Wed, 7 Jun 2006 07:50:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08294-07 for ; Wed, 7 Jun 2006 07:50:54 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id 565043B03D0 for ; Wed, 7 Jun 2006 07:50:54 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp3-g19.free.fr (Postfix) with ESMTP id 26AE4498B4 for ; Wed, 7 Jun 2006 13:50:53 +0200 (CEST) Message-ID: <4486BDD0.9050805@free.fr> Date: Wed, 07 Jun 2006 13:51:44 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.845 tagged_above=-999 required=2 tests=[AWL=-0.735, BAYES_05=-1.11] X-Spam-Score: -1.845 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Refactoring of the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 11:50:57 -0000 Hi, after some discussions, it seems my initial ideas just don't fly. I don't consider them as a full failure, but they certainly are 80% so. I has in particular a long (private) discussion with Éric Bischoff, which allowed me to test my ideas on a newcomer. :-) Snark From jpuydt@free.fr Wed Jun 7 08:02:38 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A3A943B0CA0 for ; Wed, 7 Jun 2006 08:02:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09379-09 for ; Wed, 7 Jun 2006 08:02:30 -0400 (EDT) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by menubar.gnome.org (Postfix) with ESMTP id 0A6253B0CFE for ; Wed, 7 Jun 2006 08:01:42 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp2-g19.free.fr (Postfix) with ESMTP id 9A1E973329 for ; Wed, 7 Jun 2006 14:01:41 +0200 (CEST) Message-ID: <4486C05B.9080200@free.fr> Date: Wed, 07 Jun 2006 14:02:35 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> In-Reply-To: <4486BDD0.9050805@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:02:38 -0000 Julien PUYDT a écrit : > Notice that I forgot the conclusion : back to blackboard :-) Snark From pbrobinson@gmail.com Wed Jun 7 08:05:53 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D7E343B0C89 for ; Wed, 7 Jun 2006 08:05:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09667-03 for ; Wed, 7 Jun 2006 08:05:53 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by menubar.gnome.org (Postfix) with ESMTP id 33FD03B0C35 for ; Wed, 7 Jun 2006 08:05:52 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id q2so283058uge for ; Wed, 07 Jun 2006 05:05:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=G9St54usrU1EqN6hzRVdcsL0b9E6Bqxv3H4s4TGGxDEm0S9y4VTy4J2/S9c86GUzX86KIkPRd3gDHRfgFY6rCHfD2mYVgjzsw18dl0V8Ib8+WG4xy7/jO5pBwQEky1I69/GeIoNY6Q1nIE7TBp9rIFYmsHkPs+aO3lXDh5BJAzE= Received: by 10.67.89.5 with SMTP id r5mr423228ugl; Wed, 07 Jun 2006 05:05:51 -0700 (PDT) Received: by 10.67.25.6 with HTTP; Wed, 7 Jun 2006 05:05:51 -0700 (PDT) Message-ID: <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> Date: Wed, 7 Jun 2006 13:05:51 +0100 From: "Peter Robinson" To: "GnomeMeeting development mailing list" Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code In-Reply-To: <4486C05B.9080200@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4486BDD0.9050805@free.fr> <4486C05B.9080200@free.fr> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.56 tagged_above=-999 required=2 tests=[AWL=-0.518, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.56 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:05:54 -0000 > Julien PUYDT a =E9crit : > > > > Notice that I forgot the conclusion : back to blackboard :-) So are there any ideas running around that blackboard as of yet? Peter From jpuydt@free.fr Wed Jun 7 08:22:36 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CBE393B08CC for ; Wed, 7 Jun 2006 08:22:36 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10857-05 for ; Wed, 7 Jun 2006 08:22:35 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 97D9B3B0CDC for ; Wed, 7 Jun 2006 08:22:35 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp5-g19.free.fr (Postfix) with ESMTP id 65742275AC for ; Wed, 7 Jun 2006 14:22:34 +0200 (CEST) Message-ID: <4486C53D.2080306@free.fr> Date: Wed, 07 Jun 2006 14:23:25 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> In-Reply-To: <4486BDD0.9050805@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:22:37 -0000 Ok, so let's see what the constraints are. 1) the already available addressbooks must fit in the new scheme ; 2) the future kde addressbooks must find their place easily ; 3) searching should be dead-easy ; 4) the future "live" contacts must find their place easily ; 5) the backend-frontend frontier should be clear enough to allow for easy DBUS exporting 6) Damien wants it fast. Yes, going back to the blackboard isn't the best way to achieve 6... Snark From jpuydt@free.fr Wed Jun 7 08:52:53 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 92FD63B03C4 for ; Wed, 7 Jun 2006 08:52:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12995-08 for ; Wed, 7 Jun 2006 08:52:50 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id D0F7E3B0C97 for ; Wed, 7 Jun 2006 08:52:49 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp3-g19.free.fr (Postfix) with ESMTP id AEAAC497A1 for ; Wed, 7 Jun 2006 14:52:48 +0200 (CEST) Message-ID: <4486CC54.9090206@free.fr> Date: Wed, 07 Jun 2006 14:53:40 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <4486C05B.9080200@free.fr> <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> In-Reply-To: <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:52:53 -0000 Peter Robinson a écrit : > So are there any ideas running around that blackboard as of yet? Plenty. Snark From ebischoff@nerim.net Wed Jun 7 09:43:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C57F03B03C1 for ; Wed, 7 Jun 2006 09:43:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17343-08 for ; Wed, 7 Jun 2006 09:43:14 -0400 (EDT) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by menubar.gnome.org (Postfix) with ESMTP id BB8E53B03F1 for ; Wed, 7 Jun 2006 09:43:13 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 09C7C40FD8 for ; Wed, 7 Jun 2006 15:43:11 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Wed, 7 Jun 2006 15:43:21 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <4486C53D.2080306@free.fr> In-Reply-To: <4486C53D.2080306@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606071543.22163.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.562 tagged_above=-999 required=2 tests=[AWL=0.037, BAYES_00=-2.599] X-Spam-Score: -2.562 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 13:43:16 -0000 Le Mercredi 7 Juin 2006 14:23, Julien PUYDT a =C3=A9crit=C2=A0: > Yes, going back to the blackboard isn't the best way to achieve 6... You don't go black to the blackboard with no experience ;-). In pecular, I have been proposing a framework for address book "drivers" li= ke: class EkigaAddressBook { public: virtual gchar *name() const =3D 0; virtual const EkigaContact *firstContact() =3D 0; virtual const EkigaContact *nextContact() =3D 0; }; class EkigaContact { public: virtual boolean hasName() const =3D 0; virtual gchar *name() const =3D 0; virtual boolean hasTelephone() const =3D 0; virtual gchar *telephone() const =3D 0; etc... }; class EkigaEvolutionAddressBook : public EkigaAddressBook { public: virtual gchar *name() const; virtual const EkigaContact *firstContact(); virtual const EkigaContact *nextContact(); }; class EkigaEvolutionContact : public EkigaContact { public: virtual boolean hasName() const; virtual gchar *name() const; virtual boolean hasTelephone() const; virtual gchar *telephone() const; etc... }; Comments and flames welcome. =2D-=20 =C3=89ric From jpuydt@free.fr Wed Jun 7 13:58:31 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6343F3B0BC1 for ; Wed, 7 Jun 2006 13:58:31 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02884-04 for ; Wed, 7 Jun 2006 13:58:23 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 55DA13B069F for ; Wed, 7 Jun 2006 13:58:19 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp1-g19.free.fr (Postfix) with ESMTP id E2BA8911A6 for ; Wed, 7 Jun 2006 19:58:17 +0200 (CEST) Message-ID: <4486F76C.7060301@free.fr> Date: Wed, 07 Jun 2006 17:57:32 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <4486C53D.2080306@free.fr> <200606071543.22163.ebischoff@nerim.net> In-Reply-To: <200606071543.22163.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 17:58:31 -0000 Éric Bischoff a écrit : > Le Mercredi 7 Juin 2006 14:23, Julien PUYDT a écrit : >> Yes, going back to the blackboard isn't the best way to achieve 6... > > You don't go black to the blackboard with no experience ;-). Of course no :-) > In pecular, I have been proposing a framework for address book "drivers" like: > > class EkigaAddressBook > { > public: > virtual gchar *name() const = 0; > virtual const EkigaContact *firstContact() = 0; > virtual const EkigaContact *nextContact() = 0; > }; I don't like your first/next idea. If I take an XMPP roster in ekiga, connect to the same account from another program, and add a contact there, the XMPP roster will do a roster push, which your api doesn't handle. A much better approach IMNSHO, when it comes to keeping track of a list of contacts, is the following pseudo-code api : - get the current list of contacts ; - notify/signal me when a new one appears. There are two ways to handle the removing of a contact from such a list: (i) either the book tells you the contact has been removed ; (ii) or the contact itself tells you so. Both can be handled by a notification/signal. My first tests used the second way to do so, but now I think the first is better : the signal tells you both the book and the contact. > class EkigaContact > { > public: > virtual boolean hasName() const = 0; > virtual gchar *name() const = 0; > > virtual boolean hasTelephone() const = 0; > virtual gchar *telephone() const = 0; > > etc... > }; Bad. :-) First, you don't handle the case where several telephone numbers are available. Then if you begin to put /everything/ in the *base* class, that will end badly. A base class should only have the most basic capabilities, not all of them. > Comments and flames welcome. As a last comment, I will repoint the two arguments I have to prefer a GObject solution to a C++ solution : 1) the GObject will nicely live and die in the glib mainloop, so we won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere ; 2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame /dev/null). Snark From jpuydt@free.fr Wed Jun 7 14:30:54 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6C9E83B0255 for ; Wed, 7 Jun 2006 14:30:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04954-09 for ; Wed, 7 Jun 2006 14:30:52 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 15D9C3B0135 for ; Wed, 7 Jun 2006 14:30:52 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp5-g19.free.fr (Postfix) with ESMTP id E116F2766C for ; Wed, 7 Jun 2006 20:30:50 +0200 (CEST) Message-ID: <44871B92.9090703@free.fr> Date: Wed, 07 Jun 2006 20:31:46 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <4486C05B.9080200@free.fr> <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> <4486CC54.9090206@free.fr> In-Reply-To: <4486CC54.9090206@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 18:30:54 -0000 Julien PUYDT a écrit : > Plenty. Ok, here are a few. First of all, Éric convinced me the "no common class for contacts" was bad. So the main organization should probably be the following : - at the upper level, there are sources of addressbooks (avahi, e-d-s, kab, call history, xmpp...) ; - those sources give access to addressbooks ; - those addressbooks contain contacts. Now the question is detailing what is done where :-) Snark From ebischoff@nerim.net Wed Jun 7 14:33:56 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E21DC3B027D for ; Wed, 7 Jun 2006 14:33:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05177-06 for ; Wed, 7 Jun 2006 14:33:54 -0400 (EDT) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by menubar.gnome.org (Postfix) with ESMTP id 360A33B0135 for ; Wed, 7 Jun 2006 14:33:53 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 7CB2240E26 for ; Wed, 7 Jun 2006 20:33:50 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Wed, 7 Jun 2006 20:33:52 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606071543.22163.ebischoff@nerim.net> <4486F76C.7060301@free.fr> In-Reply-To: <4486F76C.7060301@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606072033.54523.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.569 tagged_above=-999 required=2 tests=[AWL=0.030, BAYES_00=-2.599] X-Spam-Score: -2.569 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 18:33:56 -0000 Le Mercredi 7 Juin 2006 17:57, Julien PUYDT a =C3=A9crit=C2=A0: > A much better approach IMNSHO, when it comes to keeping track of a list > of contacts, is the following pseudo-code api : > - get the current list of contacts ; > - notify/signal me when a new one appears. I am not sure that the Evolution, LDAP or KAddressBook drivers will all be= =20 able to wake up when a new contact is created. The contact can be created=20 asynchronously by another user on another machine on some LDAP server far=20 away on a network that is broken half of the time, for example. So even the= =20 underlying Evolution / LDAP / KAddressBook libraries might not know. =46urthermore, keeping a list all contacts in memory can have a high cost i= n=20 memory usage. > There are two ways to handle the removing of a contact from such a list: > (i) either the book tells you the contact has been removed ; > (ii) or the contact itself tells you so. > Both can be handled by a notification/signal. My first tests used the > second way to do so, but now I think the first is better : the signal > tells you both the book and the contact. Is that such a problem if the driver loops over an older version of the lis= t? > First, you don't handle the case where several telephone numbers are > available. Yeah, yeah. That was just an example. > Then if you begin to put /everything/ in the *base* class, that will end > badly. A base class should only have the most basic capabilities, not > all of them. Well, most address books are expected to deliver names and telephone=20 numbers ,-). But if you don't want to code hooks that return NULL all the=20 time for properties that do not exist (which I can understand), there's an= =20 easy and clean variant: class EkigaContact { public: enum property { name, telephone, street, ... }; virtual bool hasProperty(property p) const =3D 0; gchar *value(property p) const =3D 0; }; So contact->value(street) returns the street address and if contact->hasProperty(street) is true. > As a last comment, I will repoint the two arguments I have to prefer a > GObject solution to a C++ solution : Well, that's the kind of debate that can typically end up in a religious=20 war ;-), but: 1) why reinvent the wheel? C++ has mechanisms for object programming, it's= =20 rather strange to reimplement them in C; 2) such choices tie Ekiga more deeply into GNOME libraries (okay, it's a GN= OME=20 project. But...) > 1) the GObject will nicely live and die in the glib mainloop, so we > won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere= ; > 2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga > more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame > /dev/null). GBUS is indeed a nice invention ;-). =2D-=20 =C3=89ric From jpuydt@free.fr Wed Jun 7 15:29:48 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 91CC53B027D for ; Wed, 7 Jun 2006 15:29:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08481-05 for ; Wed, 7 Jun 2006 15:29:45 -0400 (EDT) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by menubar.gnome.org (Postfix) with ESMTP id 54DB33B0546 for ; Wed, 7 Jun 2006 15:29:45 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp2-g19.free.fr (Postfix) with ESMTP id 2EC0A6FECE for ; Wed, 7 Jun 2006 21:29:44 +0200 (CEST) Message-ID: <4487295A.9060506@free.fr> Date: Wed, 07 Jun 2006 21:30:34 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606071543.22163.ebischoff@nerim.net> <4486F76C.7060301@free.fr> <200606072033.54523.ebischoff@nerim.net> In-Reply-To: <200606072033.54523.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 19:29:48 -0000 Éric Bischoff a écrit : > Le Mercredi 7 Juin 2006 17:57, Julien PUYDT a écrit : >> A much better approach IMNSHO, when it comes to keeping track of a list >> of contacts, is the following pseudo-code api : >> - get the current list of contacts ; >> - notify/signal me when a new one appears. > > I am not sure that the Evolution, LDAP or KAddressBook drivers will all be > able to wake up when a new contact is created. The contact can be created > asynchronously by another user on another machine on some LDAP server far > away on a network that is broken half of the time, for example. So even the > underlying Evolution / LDAP / KAddressBook libraries might not know. Well, for those what I propose still works : - they get a list of contacts (and emit the "contact-added" signal for each) ; - when they are refreshed, they remove all their contacts, and get the new list of contacts. And what I propose works also for XMPP rosters, which are dynamically updated. > Furthermore, keeping a list all contacts in memory can have a high cost in > memory usage. Indeed, some books shouldn't treat "get the list of contacts" litterally. That is why they shouldn't be too stupid :-) >> There are two ways to handle the removing of a contact from such a list: >> (i) either the book tells you the contact has been removed ; >> (ii) or the contact itself tells you so. >> Both can be handled by a notification/signal. My first tests used the >> second way to do so, but now I think the first is better : the signal >> tells you both the book and the contact. > > Is that such a problem if the driver loops over an older version of the list? To do what ? It is not a problem if the list of users on ekiga.net isn't updated live. But it certainly is if your XMPP roster isn't ! >> First, you don't handle the case where several telephone numbers are >> available. > > Yeah, yeah. That was just an example. :-) >> Then if you begin to put /everything/ in the *base* class, that will end >> badly. A base class should only have the most basic capabilities, not >> all of them. > > Well, most address books are expected to deliver names and telephone > numbers ,-). But if you don't want to code hooks that return NULL all the > time for properties that do not exist (which I can understand), there's an > easy and clean variant: > class EkigaContact > { > public: > enum property { name, telephone, street, ... }; > > virtual bool hasProperty(property p) const = 0; > gchar *value(property p) const = 0; > }; Eh... this looks like GObject properties! >> As a last comment, I will repoint the two arguments I have to prefer a >> GObject solution to a C++ solution : > > Well, that's the kind of debate that can typically end up in a religious > war ;-), but: > 1) why reinvent the wheel? C++ has mechanisms for object programming, it's > rather strange to reimplement them in C; > 2) such choices tie Ekiga more deeply into GNOME libraries (okay, it's a GNOME > project. But...) glib/gobject isn't gnome. It isn't even graphical. >> 1) the GObject will nicely live and die in the glib mainloop, so we >> won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere ; >> 2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga >> more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame >> /dev/null). > > GBUS is indeed a nice invention ;-). DBUS, not GBUS. Snark From ebischoff@nerim.net Wed Jun 7 17:05:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 354B63B00A5 for ; Wed, 7 Jun 2006 17:05:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14677-05 for ; Wed, 7 Jun 2006 17:05:13 -0400 (EDT) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by menubar.gnome.org (Postfix) with ESMTP id CB5F43B0135 for ; Wed, 7 Jun 2006 17:05:12 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 1E15A437B0 for ; Wed, 7 Jun 2006 22:52:51 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Wed, 7 Jun 2006 22:53:00 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606072033.54523.ebischoff@nerim.net> <4487295A.9060506@free.fr> In-Reply-To: <4487295A.9060506@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606072253.01820.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.573 tagged_above=-999 required=2 tests=[AWL=0.026, BAYES_00=-2.599] X-Spam-Score: -2.573 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 21:05:17 -0000 Le Mercredi 7 Juin 2006 21:30, Julien PUYDT a =C3=A9crit=C2=A0: > > I am not sure that the Evolution, LDAP or KAddressBook drivers will all > > be able to wake up when a new contact is created. The contact can be > > created asynchronously by another user on another machine on some LDAP > > server far away on a network that is broken half of the time, for > > example. So even the underlying Evolution / LDAP / KAddressBook librari= es > > might not know. > > Well, for those what I propose still works : > - they get a list of contacts (and emit the "contact-added" signal for > each) ; > - when they are refreshed, they remove all their contacts, and get the > new list of contacts. What makes you think that they get "refreshed" at some point? > And what I propose works also for XMPP rosters, which are dynamically > updated. Promise, I will look someday what a "XMPP roster" is ;-). > > Furthermore, keeping a list all contacts in memory can have a high cost > > in memory usage. > > Indeed, some books shouldn't treat "get the list of contacts" > litterally. That is why they shouldn't be too stupid :-) Then you must some kind of evolved caching mechanism in your driver. That's= =20 sounds overcomplicated and hard to code to me. If you simply loop through t= he=20 contacts, you can just get the information you need and display it. > > Is that such a problem if the driver loops over an older version of the > > list? > > To do what ? It is not a problem if the list of users on ekiga.net isn't > updated live. But it certainly is if your XMPP roster isn't ! If you convinced me of one thing, it's that I need to look at the definitio= n=20 of these SNMP toasters ;-). > > class EkigaContact > > { > > public: > > enum property { name, telephone, street, ... }; > > > > virtual bool hasProperty(property p) const =3D 0; > > gchar *value(property p) const =3D 0; > > }; > > Eh... this looks like GObject properties! Indeed! Excepted that you are just using the possibilities of the programmi= ng=20 language, not of some library. At this point, I must do some clarification: I am a newcomer to Ekiga and perfectly aware of the fact that I might ignor= e a=20 lot of things about the past and the possible future of this software. I am= a=20 complete ignorant of GNOME and its libraries. I do not know anything about= =20 the multithreading problems that Julien has to deal with. I am not here to= =20 slow down Julien, nor to get my views adopted. I will be more than happy to= =20 adapt my code to *any* API that Julien will bring up. And to shut my big=20 mouth up if anyone ask me to ;-). > glib/gobject isn't gnome. It isn't even graphical. Okay, to me who comes from the KDE world, it's the same thing, it starts wi= th=20 "g" ;-). > > GBUS is indeed a nice invention ;-). > > DBUS, not GBUS. Yes, sorry for the many typos... :-/ =2D-=20 =C3=89ric From jan.schampera@web.de Wed Jun 7 23:13:06 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7395E3B043B for ; Wed, 7 Jun 2006 23:13:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02368-03 for ; Wed, 7 Jun 2006 23:13:03 -0400 (EDT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by menubar.gnome.org (Postfix) with ESMTP id 6D4823B012E for ; Wed, 7 Jun 2006 23:13:03 -0400 (EDT) Received: from fwd35.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1FoAxC-0004rd-00; Thu, 08 Jun 2006 05:13:02 +0200 Received: from mail.home.thebonsai.de (Z2ab0kZBZewL1AHEQWezyBxMlAJSeayZbCOT8jbF9IKQFlf7QKn1Ul@[84.147.102.15]) by fwd35.sul.t-online.de with esmtp id 1FoAx4-1YpxqK0; Thu, 8 Jun 2006 05:12:54 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id 8DF136B173 for ; Thu, 8 Jun 2006 05:12:52 +0200 (CEST) Date: Thu, 8 Jun 2006 05:08:28 +0200 From: Jan Schampera To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Message-ID: <20060608050828.37d3ac08@localhost.localdomain> In-Reply-To: <200606072253.01820.ebischoff@nerim.net> References: <4486BDD0.9050805@free.fr> <200606072033.54523.ebischoff@nerim.net> <4487295A.9060506@free.fr> <200606072253.01820.ebischoff@nerim.net> Organization: private X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-ID: Z2ab0kZBZewL1AHEQWezyBxMlAJSeayZbCOT8jbF9IKQFlf7QKn1Ul@t-dialin.net X-TOI-MSGID: c2323eec-2b6b-468d-b9e5-6ee93ecdce82 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.971 tagged_above=-999 required=2 tests=[AWL=0.627, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.971 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 03:13:06 -0000 On Wed, 7 Jun 2006 22:53:00 +0200 =C3=89ric Bischoff wrote: > (GLib vs OOP) > Indeed! Excepted that you are just using the possibilities of the > programming language, not of some library. Please note, regardless all other arguments, that an own C++-object system will be totally independant of the used framework. In case we leave GTK and GLib some day, the OOP approach won't need any changes. The GObject approach would need either an equivalent in the new framework, or a rewrite to (finally) OOP. Beside that, I tend to say "a matter of taste". J. --=20 dreaming in digital living in realtime thinking in binary talking in IP WELCOME TO OUR WORLD From jpuydt@free.fr Thu Jun 8 04:39:27 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8DA623B05CC for ; Thu, 8 Jun 2006 04:39:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19858-03 for ; Thu, 8 Jun 2006 04:39:24 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id D38EA3B0E0F for ; Thu, 8 Jun 2006 04:39:23 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp6-g19.free.fr (Postfix) with ESMTP id A778922647 for ; Thu, 8 Jun 2006 10:39:22 +0200 (CEST) Message-ID: <4487E272.80605@free.fr> Date: Thu, 08 Jun 2006 10:40:18 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606072033.54523.ebischoff@nerim.net> <4487295A.9060506@free.fr> <200606072253.01820.ebischoff@nerim.net> In-Reply-To: <200606072253.01820.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 08:39:27 -0000 Éric Bischoff a écrit : > Le Mercredi 7 Juin 2006 21:30, Julien PUYDT a écrit : >>> I am not sure that the Evolution, LDAP or KAddressBook drivers will all >>> be able to wake up when a new contact is created. The contact can be >>> created asynchronously by another user on another machine on some LDAP >>> server far away on a network that is broken half of the time, for >>> example. So even the underlying Evolution / LDAP / KAddressBook libraries >>> might not know. >> Well, for those what I propose still works : >> - they get a list of contacts (and emit the "contact-added" signal for >> each) ; >> - when they are refreshed, they remove all their contacts, and get the >> new list of contacts. > > What makes you think that they get "refreshed" at some point? The user triggers the "refresh" action :-) >> And what I propose works also for XMPP rosters, which are dynamically >> updated. > > Promise, I will look someday what a "XMPP roster" is ;-). Perhaps you know what a "jabber roster" is? http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html >>> Furthermore, keeping a list all contacts in memory can have a high cost >>> in memory usage. >> Indeed, some books shouldn't treat "get the list of contacts" >> litterally. That is why they shouldn't be too stupid :-) > > Then you must some kind of evolved caching mechanism in your driver. That's > sounds overcomplicated and hard to code to me. If you simply loop through the > contacts, you can just get the information you need and display it. I don't think a trivial proxying counts as an "evolved caching mechanism" :-) >>> Is that such a problem if the driver loops over an older version of the >>> list? >> To do what ? It is not a problem if the list of users on ekiga.net isn't >> updated live. But it certainly is if your XMPP roster isn't ! > > If you convinced me of one thing, it's that I need to look at the definition > of these SNMP toasters ;-). Who's toast ? ;-) >>> class EkigaContact >>> { >>> public: >>> enum property { name, telephone, street, ... }; >>> >>> virtual bool hasProperty(property p) const = 0; >>> gchar *value(property p) const = 0; >>> }; >> Eh... this looks like GObject properties! > > Indeed! Excepted that you are just using the possibilities of the programming > language, not of some library. Can you add properties to the enum when inheriting ? > At this point, I must do some clarification: > > I am a newcomer to Ekiga and perfectly aware of the fact that I might ignore a > lot of things about the past and the possible future of this software. I am a > complete ignorant of GNOME and its libraries. I do not know anything about > the multithreading problems that Julien has to deal with. I am not here to > slow down Julien, nor to get my views adopted. I will be more than happy to > adapt my code to *any* API that Julien will bring up. And to shut my big > mouth up if anyone ask me to ;-). Yes, yes, no problem. I'm happy to have feedback :-) >> glib/gobject isn't gnome. It isn't even graphical. > > Okay, to me who comes from the KDE world, it's the same thing, it starts with > "g" ;-). glib, gobject & gtk+ already make ekiga run on win32. >>> GBUS is indeed a nice invention ;-). >> DBUS, not GBUS. > > Yes, sorry for the many typos... :-/ Eh... that one was pretty bad for someone who has something against g-letter words ;-) Snark From ebischoff@nerim.net Thu Jun 8 04:49:09 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DA33D3B013D for ; Thu, 8 Jun 2006 04:49:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20394-06 for ; Thu, 8 Jun 2006 04:49:08 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id 682F73B05A7 for ; Thu, 8 Jun 2006 04:49:07 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 6666B41095 for ; Thu, 8 Jun 2006 10:49:06 +0200 (CEST) From: =?iso-8859-15?q?=C9ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 10:49:15 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <20060608050828.37d3ac08@localhost.localdomain> In-Reply-To: <20060608050828.37d3ac08@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606081049.16046.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.577 tagged_above=-999 required=2 tests=[AWL=0.022, BAYES_00=-2.599] X-Spam-Score: -2.577 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 08:49:10 -0000 Le Jeudi 8 Juin 2006 05:08, Jan Schampera a =E9crit=A0: > > Indeed! Excepted that you are just using the possibilities of the > > programming language, not of some library. > > Please note, regardless all other arguments, that an own C++-object > system will be totally independant of the used framework. In case we > leave GTK and GLib some day, the OOP approach won't need any changes. > > The GObject approach would need either an equivalent in the new > framework, or a rewrite to (finally) OOP. Yes. That was precisely my point. > Beside that, I tend to say "a matter of taste". Yes. Sometimes programming has to do with aesthetics. Compare: =3D=3D=3D GObject way =3D=3D=3D struct _GmBook { GObject parent; }; struct _GmBookClass { GObjectClass parent; const gchar *(*get_name)(GmBook *self); }; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D with: =3D=3D=3D C++ way =3D=3D=3D class GmBook { public: virtual get_name() const; } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D My tastes tell me that second code, besides from being much shorter, has mo= re=20 "beauty" than the first one. But as you say, tastes are a very personal=20 thing. =2D-=20 =C9ric From jpuydt@free.fr Thu Jun 8 05:09:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C38A43B04E8 for ; Thu, 8 Jun 2006 05:09:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21821-03 for ; Thu, 8 Jun 2006 05:09:15 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 32ECF3B0505 for ; Thu, 8 Jun 2006 05:09:15 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp5-g19.free.fr (Postfix) with ESMTP id BD9EA275B9 for ; Thu, 8 Jun 2006 11:09:13 +0200 (CEST) Message-ID: <4487E971.8070602@free.fr> Date: Thu, 08 Jun 2006 11:10:09 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <20060608050828.37d3ac08@localhost.localdomain> <200606081049.16046.ebischoff@nerim.net> In-Reply-To: <200606081049.16046.ebischoff@nerim.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 09:09:16 -0000 Éric Bischoff a écrit : > Le Jeudi 8 Juin 2006 05:08, Jan Schampera a écrit : >>> Indeed! Excepted that you are just using the possibilities of the >>> programming language, not of some library. >> Please note, regardless all other arguments, that an own C++-object >> system will be totally independant of the used framework. In case we >> leave GTK and GLib some day, the OOP approach won't need any changes. >> >> The GObject approach would need either an equivalent in the new >> framework, or a rewrite to (finally) OOP. > > Yes. That was precisely my point. > >> Beside that, I tend to say "a matter of taste". > > Yes. Sometimes programming has to do with aesthetics. Compare: > > === GObject way === > struct _GmBook { > GObject parent; > }; > > struct _GmBookClass { > GObjectClass parent; > > const gchar *(*get_name)(GmBook *self); > }; > ================== > > with: > > === C++ way === > class GmBook { > public: > virtual get_name() const; > } > ================== > > My tastes tell me that second code, besides from being much shorter, has more > "beauty" than the first one. But as you say, tastes are a very personal > thing. My experience is that when it comes to export the object on DBUS, you're better off with a gobject than with a C++ object. One has some introspection, the other doesn't. I prefer working a little harder upfront, then have an easy life, than writing easy code then feel miserable :-) Snark From ebischoff@nerim.net Thu Jun 8 05:22:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C67273B0598 for ; Thu, 8 Jun 2006 05:22:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22528-04 for ; Thu, 8 Jun 2006 05:22:07 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id D66F33B0B13 for ; Thu, 8 Jun 2006 05:22:06 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 4966F40FBF for ; Thu, 8 Jun 2006 11:22:05 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 11:22:09 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <4487E272.80605@free.fr> In-Reply-To: <4487E272.80605@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606081122.11835.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.579 tagged_above=-999 required=2 tests=[AWL=0.020, BAYES_00=-2.599] X-Spam-Score: -2.579 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 09:22:11 -0000 Le Jeudi 8 Juin 2006 10:40, Julien PUYDT a =C3=A9crit=C2=A0: > > What makes you think that they get "refreshed" at some point? > > The user triggers the "refresh" action :-) Then you loop again through the address book contacts ;-). No need to keep = a=20 copy of the contacts for that. > > Promise, I will look someday what a "XMPP roster" is ;-). > > Perhaps you know what a "jabber roster" is? > http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html No, and this article does not contain the word "roster" :-(. > > Then you must some kind of evolved caching mechanism in your driver. > > That's sounds overcomplicated and hard to code to me. If you simply loop > > through the contacts, you can just get the information you need and > > display it. > > I don't think a trivial proxying counts as an "evolved caching > mechanism" :-) I told you in private that I had a very lazy concept of programming ;-). > Who's toast ? ;-) ;-). > Can you add properties to the enum when inheriting ? Yes: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D class Repas { public: enum plat { nouilles, riz, patates, pain }; virtual void mange(plat p) =3D 0; }; class BonRepas : public Repas { public: enum bonPlat { caviar =3D pain + 1, langouste, foiegras, saumon }; virtual void mange(plat p); }; void BonRepas::mange(plat p) { if ((bonPlat) p =3D=3D langouste) printf("Miam!\n"); } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D With anonymous enums you should even be able to get rid of the casts. But=20 named enums make the code clearer. > Yes, yes, no problem. I'm happy to have feedback :-) Thanks for your openess, Julien :-). > glib, gobject & gtk+ already make ekiga run on win32. I know. But I think it is always good to remove references to libraries if = you=20 do not really need them. > Eh... that one was pretty bad for someone who has something against > g-letter words ;-) I have nothing against, I am just ignorant ;-). =2D-=20 =C3=89ric From conrad_videokonferenz@gmx.de Thu Jun 8 06:04:43 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7A1F63B0CF2 for ; Thu, 8 Jun 2006 06:04:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24863-06 for ; Thu, 8 Jun 2006 06:04:41 -0400 (EDT) Received: from vz17136.evanzo-server.de (vz17136.evanzo-server.de [62.140.17.136]) by menubar.gnome.org (Postfix) with ESMTP id E081B3B05CC for ; Thu, 8 Jun 2006 06:04:40 -0400 (EDT) Received: from c133075.adsl.hansenet.de (c133075.adsl.hansenet.de [213.39.133.75]) (authenticated bits=0) by vz17136.evanzo-server.de (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id k58A4cTf030082 for ; Thu, 8 Jun 2006 12:04:39 +0200 From: Conrad Beckert To: gnomemeeting-devel-list@gnome.org Date: Thu, 8 Jun 2006 10:02:37 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606081002.37875.conrad_videokonferenz@gmx.de> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.106 tagged_above=-999 required=2 tests=[AWL=-1.138, BAYES_05=-1.11, SPF_FAIL=1.142] X-Spam-Score: -1.106 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 10:04:45 -0000 Hi, has anybody an idea where the Debian packages for Ekiga 2.0.2 (or the corresponding CVS versions) are? The last version I can install using apt-get a couple of days old (May 25 - or somethin) - at least this is a version with the nonfunctional German locale. (defaults to English) What's up? Conrad From jpuydt@free.fr Thu Jun 8 06:59:27 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 483C83B0ED8 for ; Thu, 8 Jun 2006 06:59:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27917-10 for ; Thu, 8 Jun 2006 06:59:15 -0400 (EDT) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by menubar.gnome.org (Postfix) with ESMTP id 1C5223B0630 for ; Thu, 8 Jun 2006 06:59:12 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp4-g19.free.fr (Postfix) with ESMTP id A681254974 for ; Thu, 8 Jun 2006 12:59:10 +0200 (CEST) Message-ID: <44880335.3060401@free.fr> Date: Thu, 08 Jun 2006 13:00:05 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <4487E272.80605@free.fr> <200606081122.11835.ebischoff@nerim.net> In-Reply-To: <200606081122.11835.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 10:59:27 -0000 Éric Bischoff a écrit : > Le Jeudi 8 Juin 2006 10:40, Julien PUYDT a écrit : >>> What makes you think that they get "refreshed" at some point? >> The user triggers the "refresh" action :-) > > Then you loop again through the address book contacts ;-). No need to keep a > copy of the contacts for that. You will need to keep a copy to show them to the user anyway. And notice that a same contact could be shown at several places through the user interface! >>> Promise, I will look someday what a "XMPP roster" is ;-). >> Perhaps you know what a "jabber roster" is? >> http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html > > No, and this article does not contain the word "roster" :-(. The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish them from 'live' contacts. The situation is that you may have jc@jabber.lat in your roster, with the information that the name is "Julius Caesar", and belongs to the groups "Politicians" and "Jokers". But when he connects from his pda, he will show up as jc@jabber.lat/pda, and will neither be able to do VoIP, nor receive XHTML messages. When he is home, he connects from his computer as jc@jabber.lat/home, and will be able to do both. Now he goes to work, from where he shows up as jc@jabber.lat/work, which can do XHTML messaging, but not VoIP. >> Yes, yes, no problem. I'm happy to have feedback :-) > > Thanks for your openess, Julien :-). No problem. More brains means better solutions :-) >> glib, gobject & gtk+ already make ekiga run on win32. > > I know. But I think it is always good to remove references to libraries if you > do not really need them. Well, glib is nice. The main problem KDE problem have with it is that it begins with a 'g' and is already used in GNOME. :-) Snark From ebischoff@nerim.net Thu Jun 8 09:37:50 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CE2BD3B03A6 for ; Thu, 8 Jun 2006 09:37:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08027-03 for ; Thu, 8 Jun 2006 09:37:49 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id 549EB3B0622 for ; Thu, 8 Jun 2006 09:37:48 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 1D58441027 for ; Thu, 8 Jun 2006 15:37:45 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 15:37:53 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606081122.11835.ebischoff@nerim.net> <44880335.3060401@free.fr> In-Reply-To: <44880335.3060401@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606081537.55137.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.504 tagged_above=-999 required=2 tests=[AWL=-0.059, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077] X-Spam-Score: -2.504 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 13:37:51 -0000 Le Jeudi 8 Juin 2006 13:00, Julien PUYDT a =C3=A9crit=C2=A0: > > Then you loop again through the address book contacts ;-). No need to > > keep a copy of the contacts for that. > > You will need to keep a copy to show them to the user anyway. Keeping contacts in memory is not the same at all as keeping an image of wh= at=20 Ekiga has to display of them. The GUI needs basically a list of strings to= =20 display, not the potentially complex data structure of an address book=20 contact. Having one of these complex structures in memory at a time is enough IMHO. Should it be only for performance reasons: when the user scrolls down the l= ist=20 by one contact, it is much quicker to retreive data from a prepared list of= =20 strings than from the contact itself. > And notice=20 > that a same contact could be shown at several places through the user > interface! Yes, and perharps displayed in different ways. > > No, and this article does not contain the word "roster" :-(. > > The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish > them from 'live' contacts. > > The situation is that you may have jc@jabber.lat in your roster, with > the information that the name is "Julius Caesar", and belongs to the > groups "Politicians" and "Jokers". But when he connects from his pda, he > will show up as jc@jabber.lat/pda, and will neither be able to do VoIP, > nor receive XHTML messages. When he is home, he connects from his > computer as jc@jabber.lat/home, and will be able to do both. Now he goes > to work, from where he shows up as jc@jabber.lat/work, which can do > XHTML messaging, but not VoIP. Aha. > > Thanks for your openess, Julien :-). > > No problem. More brains means better solutions :-) Yes, indeed. I hope my advice brings something constructive. As I told you = in=20 private, you keep it or throw it, it's your decision. > > I know. But I think it is always good to remove references to libraries > > if you do not really need them. > > Well, glib is nice. The main problem KDE problem have with it is that it > begins with a 'g' and is already used in GNOME. :-) Do not believe that. We are not religious people. For example, we are very= =20 happy sharing libxml with GNOME. Even though there is already a XML API in= =20 Qt! Just because libxml rocks... (oh yeah, there's no "g" in libxml... ;-) ) We already share libxml, desktop files, DocBook documentation, DBUS=20 communication, po translation memories, and many, many other things. Cool=20 apps like Ekiga can run in a KDE environment. Cool apps like ... errr...=20 KEuroCalc ;-) can run in a GNOME environment. And in fact I know that many= =20 people do that. In fact, the more we will be able to share with you, the happier we will be= =2E I=20 can ensure you that this has always been what we said, even during private= =20 discussions at KDE meetings. I do not know why we do not share glib. I have my ideas about that, but it'= s=20 just personal assumptions ;-). =2D-=20 =C3=89ric From jpuydt@free.fr Thu Jun 8 15:02:29 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6459F3B0F68 for ; Thu, 8 Jun 2006 15:02:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30195-09 for ; Thu, 8 Jun 2006 15:02:28 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id 1D6653B035A for ; Thu, 8 Jun 2006 15:02:28 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp6-g19.free.fr (Postfix) with ESMTP id A118022783 for ; Thu, 8 Jun 2006 21:02:23 +0200 (CEST) Message-ID: <4488747B.6080906@free.fr> Date: Thu, 08 Jun 2006 21:03:23 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606081122.11835.ebischoff@nerim.net> <44880335.3060401@free.fr> <200606081537.55137.ebischoff@nerim.net> In-Reply-To: <200606081537.55137.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.512 tagged_above=-999 required=2 tests=[AWL=-0.067, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077] X-Spam-Score: -2.512 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:02:29 -0000 Éric Bischoff a écrit : >> You will need to keep a copy to show them to the user anyway. > > Keeping contacts in memory is not the same at all as keeping an image of what > Ekiga has to display of them. The GUI needs basically a list of strings to > display, not the potentially complex data structure of an address book > contact. > > Having one of these complex structures in memory at a time is enough IMHO. Not at all. And it won't allow you to update informations like presence easily. > Should it be only for performance reasons: when the user scrolls down the list > by one contact, it is much quicker to retreive data from a prepared list of > strings than from the contact itself. The contact isn't that much more than strings... >> And notice >> that a same contact could be shown at several places through the user >> interface! > > Yes, and perharps displayed in different ways. Yes, that too. >>> No, and this article does not contain the word "roster" :-(. >> The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish >> them from 'live' contacts. >> >> The situation is that you may have jc@jabber.lat in your roster, with >> the information that the name is "Julius Caesar", and belongs to the >> groups "Politicians" and "Jokers". But when he connects from his pda, he >> will show up as jc@jabber.lat/pda, and will neither be able to do VoIP, >> nor receive XHTML messages. When he is home, he connects from his >> computer as jc@jabber.lat/home, and will be able to do both. Now he goes >> to work, from where he shows up as jc@jabber.lat/work, which can do >> XHTML messaging, but not VoIP. > > Aha. Yes, it's that bad :-/ >>> Thanks for your openess, Julien :-). >> No problem. More brains means better solutions :-) > > Yes, indeed. I hope my advice brings something constructive. As I told you in > private, you keep it or throw it, it's your decision. Last time you wrote that I ended throwing both your ideas and mines ;-) >>> I know. But I think it is always good to remove references to libraries >>> if you do not really need them. >> Well, glib is nice. The main problem KDE problem have with it is that it >> begins with a 'g' and is already used in GNOME. :-) > > Do not believe that. We are not religious people. For example, we are very > happy sharing libxml with GNOME. Even though there is already a XML API in > Qt! Just because libxml rocks... > > (oh yeah, there's no "g" in libxml... ;-) ) > > We already share libxml, desktop files, DocBook documentation, DBUS > communication, po translation memories, and many, many other things. Cool > apps like Ekiga can run in a KDE environment. Cool apps like ... errr... > KEuroCalc ;-) can run in a GNOME environment. And in fact I know that many > people do that. What is KEuroCalc ? > In fact, the more we will be able to share with you, the happier we will be. I > can ensure you that this has always been what we said, even during private > discussions at KDE meetings. This is why it's so important to have a good DBUS component. And this is made easier by using glib-object :-) > I do not know why we do not share glib. I have my ideas about that, but it's > just personal assumptions ;-). I can make a few guesses : 1) it does things that QT does ; 2) it does things that C++ STL does. Snark From ebischoff@nerim.net Thu Jun 8 15:38:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D9F313B054E for ; Thu, 8 Jun 2006 15:38:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32745-08 for ; Thu, 8 Jun 2006 15:38:37 -0400 (EDT) Received: from mallaury.nerim.net (smtp-104-thursday.noc.nerim.net [62.4.17.104]) by menubar.gnome.org (Postfix) with ESMTP id 3976E3B000E for ; Thu, 8 Jun 2006 15:38:35 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by mallaury.nerim.net (Postfix) with ESMTP id 1ED2F4F3A4 for ; Thu, 8 Jun 2006 21:38:22 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 21:38:46 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606081537.55137.ebischoff@nerim.net> <4488747B.6080906@free.fr> In-Reply-To: <4488747B.6080906@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606082138.46648.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.576 tagged_above=-999 required=2 tests=[AWL=0.023, BAYES_00=-2.599] X-Spam-Score: -2.576 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:38:40 -0000 Le Jeudi 8 Juin 2006 21:03, Julien PUYDT a =C3=A9crit=C2=A0: > > We already share libxml, desktop files, DocBook documentation, DBUS > > communication, po translation memories, and many, many other things. Co= ol > > apps like Ekiga can run in a KDE environment. Cool apps like ... errr... > > KEuroCalc ;-) can run in a GNOME environment. And in fact I know that > > many people do that. > > What is KEuroCalc ? Mentioning it was merely a joke: it's a small KDE app that I wrote. http://opensource.bureau-cornavin.com/keurocalc/ ;-) > > I do not know why we do not share glib. I have my ideas about that, but > > it's just personal assumptions ;-). > > I can make a few guesses : > 1) it does things that QT does ; > 2) it does things that C++ STL does. Exactly the same guesses as me ;-). It even does things that C++ _alone_ do= es. Best, =2D-=20 =C3=89ric From ph.l@libertysurf.fr Thu Jun 8 15:47:49 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9705F3B1039 for ; Thu, 8 Jun 2006 15:47:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00870-02 for ; Thu, 8 Jun 2006 15:47:38 -0400 (EDT) Received: from smtp4.mail.easynet.fr (smarthost169.mail.easynet.fr [212.180.1.169]) by menubar.gnome.org (Postfix) with ESMTP id 527163B1020 for ; Thu, 8 Jun 2006 15:47:35 -0400 (EDT) Received: from asi-236.asi256ip.easynet.fr ([212.180.39.236] helo=[145.111.24.1]) by smtp4.mail.easynet.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FoQUy-0004IP-Fg for gnomemeeting-devel-list@gnome.org; Thu, 08 Jun 2006 21:48:56 +0200 Message-ID: <44887ECE.9040902@libertysurf.fr> Date: Thu, 08 Jun 2006 21:47:26 +0200 From: Philippe Lefevre User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: gnomemeeting-devel-list@gnome.org References: <20060608160031.473BF3B0FB3@menubar.gnome.org> In-Reply-To: <20060608160031.473BF3B0FB3@menubar.gnome.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.436 tagged_above=-999 required=2 tests=[AWL=-0.853, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, TW_BX=0.077, TW_IB=0.077, TW_RW=0.077, TW_WX=0.077] X-Spam-Score: -1.436 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ekiga under windows X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ph.l@libertysurf.fr, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:47:49 -0000 Hello, Today I tried to install ekiga on my PC under XP and I never get anything to work :'( You'll find bellow what I did. I can do some other tests if it may in any help. PhiL My PC is running Windows XP SP1 1G memory. I installed GTK 2.0 (version 2.8.9.0) installed under C:\Program Files\Fichiers communs\GTK\2.0 and Ekiga (downloaded from CVS June 8, 2006) installed under C:\Program Files\Ekiga CYGWIN and MSYS are installed too with XP : nothing happen, no log (empty file even with -d 4 option) with MSYS : same issue $ echo $PATH .:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32: /c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/oracle9/bin:/c/oracle8/bin: /i/progicil/orawin2:/i/progicil/orawin2/bin: /c/Program Files/Microsoft SQL Server/80/Tools/BINN: /c/Program Files/Fichiers communs/GTK/2.0/bin:/c/php5: /c/php5/ext:/c/Program Files/MySQL/MySQL Server 5.0/bin: /c/bin:/c/cygdrive/c/cygwin/bin:/c/cygdrive/c/cygwin/sbin:/c/oracle9/bin: /c/oracle8/bin:/i/progicil/orawin2:/i/progicil/orawin2/bin: /c/Program Files/Ekiga:/c/caml/bin PHL@BORG /c/program files/ekiga $ ./ekiga.exe 1>log 2>&1 Log is empty $ ls -rwxr-xr-x 1 PHL Administ 7934464 May 16 05:26 ekiga.exe -rw-r--r-- 1 PHL Administ 1231950 May 16 05:26 ekiga.schemas -rwxr-xr-x 1 PHL Administ 44032 May 16 05:26 liblber.dll -rwxr-xr-x 1 PHL Administ 188416 May 16 05:26 libldap_r.dll -rwxr-xr-x 1 PHL Administ 1276928 May 16 05:26 libxml2-2.dll drwxr-xr-x 70 PHL Administ 0 Jun 8 09:52 locale -rw-r--r-- 1 PHL Administ 0 Jun 8 13:30 log Using GDB in a cygdrive environment : $ gdb ekiga.exe GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) (gdb) run Starting program: /cygdrive/c/Program Files/Ekiga/ekiga.exe Program received signal SIGSEGV, Segmentation fault. Program received signal SIGSEGV, Segmentation fault. Program exited with code 0200. You can't do that without a process to debug. (gdb) bt No stack. (gdb) From jpuydt@free.fr Thu Jun 8 15:50:47 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 143943B027F for ; Thu, 8 Jun 2006 15:50:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01017-01 for ; Thu, 8 Jun 2006 15:50:46 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id E67403B021A for ; Thu, 8 Jun 2006 15:50:45 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp3-g19.free.fr (Postfix) with ESMTP id C567B4901D; Thu, 8 Jun 2006 21:50:43 +0200 (CEST) Message-ID: <44887FCD.7040300@free.fr> Date: Thu, 08 Jun 2006 21:51:41 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: ph.l@libertysurf.fr, GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Ekiga under windows References: <20060608160031.473BF3B0FB3@menubar.gnome.org> <44887ECE.9040902@libertysurf.fr> In-Reply-To: <44887ECE.9040902@libertysurf.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.434 tagged_above=-999 required=2 tests=[AWL=-0.143, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077, TW_RW=0.077, TW_WX=0.077] X-Spam-Score: -2.434 X-Spam-Level: Cc: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:50:47 -0000 Philippe Lefevre a écrit : > Today I tried to install ekiga on my PC under XP and I never get > anything to work :'( Yes, we don't have a nice installer yet. > I installed GTK 2.0 (version 2.8.9.0) installed under > C:\Program Files\Fichiers communs\GTK\2.0 I'm wondering if that is recent enough. > CYGWIN and MSYS are installed too Unnecessary. > $ ls > -rwxr-xr-x 1 PHL Administ 7934464 May 16 05:26 ekiga.exe > -rw-r--r-- 1 PHL Administ 1231950 May 16 05:26 ekiga.schemas > -rwxr-xr-x 1 PHL Administ 44032 May 16 05:26 liblber.dll > -rwxr-xr-x 1 PHL Administ 188416 May 16 05:26 libldap_r.dll > -rwxr-xr-x 1 PHL Administ 1276928 May 16 05:26 libxml2-2.dll > drwxr-xr-x 70 PHL Administ 0 Jun 8 09:52 locale > -rw-r--r-- 1 PHL Administ 0 Jun 8 13:30 log No libSDL.dll or some such ? :-/ Snark From ph.l@libertysurf.fr Thu Jun 8 16:43:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 40F853B00EA for ; Thu, 8 Jun 2006 16:43:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04211-07 for ; Thu, 8 Jun 2006 16:43:38 -0400 (EDT) Received: from smtp3.mail.easynet.fr (smarthost168.mail.easynet.fr [212.180.1.168]) by menubar.gnome.org (Postfix) with ESMTP id 52BD23B000E for ; Thu, 8 Jun 2006 16:43:37 -0400 (EDT) Received: from asi-236.asi256ip.easynet.fr ([212.180.39.236] helo=[145.111.24.1]) by smtp3.mail.easynet.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FoRMF-0007kr-6F; Thu, 08 Jun 2006 22:43:59 +0200 Message-ID: <44888BF6.8020906@libertysurf.fr> Date: Thu, 08 Jun 2006 22:43:34 +0200 From: Philippe Lefevre User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: Julien PUYDT , gnomemeeting-devel-list@gnome.org References: <20060608160031.473BF3B0FB3@menubar.gnome.org> <44887ECE.9040902@libertysurf.fr> <44887FCD.7040300@free.fr> In-Reply-To: <44887FCD.7040300@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.283 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077, TW_RW=0.077, TW_WX=0.077] X-Spam-Score: -2.283 X-Spam-Level: Cc: Subject: [GnomeMeeting-devel-list] Re : Ekiga under windows X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ph.l@libertysurf.fr, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 20:43:39 -0000 Julien PUYDT a écrit : > Philippe Lefevre a écrit : > >> Today I tried to install ekiga on my PC under XP and I never get >> anything to work :'( > > > Yes, we don't have a nice installer yet. No pb, unzip works well for now. > >> I installed GTK 2.0 (version 2.8.9.0) installed under >> C:\Program Files\Fichiers communs\GTK\2.0 > > > I'm wondering if that is recent enough. > 2.8.9.0 is the latest stable version but there is a 2.8.15 too dated from March (still unstable ?) >> CYGWIN and MSYS are installed too > > > Unnecessary. > Of course. It's just to use dbg. (I installed it for other things anyway) >> $ ls >> -rwxr-xr-x 1 PHL Administ 7934464 May 16 05:26 ekiga.exe >> -rw-r--r-- 1 PHL Administ 1231950 May 16 05:26 ekiga.schemas >> -rwxr-xr-x 1 PHL Administ 44032 May 16 05:26 liblber.dll >> -rwxr-xr-x 1 PHL Administ 188416 May 16 05:26 libldap_r.dll >> -rwxr-xr-x 1 PHL Administ 1276928 May 16 05:26 libxml2-2.dll >> drwxr-xr-x 70 PHL Administ 0 Jun 8 09:52 locale >> -rw-r--r-- 1 PHL Administ 0 Jun 8 13:30 log > > > No libSDL.dll or some such ? :-/ > Sorry I don't think so. I will check tomorrow (it is on my PC at work) But, I just check the zip file... there is no libSDL (or name close to that) into it. > Snark > Thanks Julien. From mcquaidster@gmail.com Thu Jun 8 17:09:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DF4253B0622 for ; Thu, 8 Jun 2006 17:09:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05835-02 for ; Thu, 8 Jun 2006 17:09:06 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id 76D583B0F9D for ; Thu, 8 Jun 2006 17:09:06 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id z74so693545pyg for ; Thu, 08 Jun 2006 14:09:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=HVNAtak5n7Z91wpmXr/Qu5ON4YhH7Q4dCf+4y5GUbTwwY23VOAXrmjBMj7263bIU8fqFePgmvS6HIFqN59D2Jy6YmXM2xD1V+aMpky/Ed9jdEhbQxbJYZUEi6YN6vk99BkQspxK0SEsZWjsxDvHu3Rk9O5hKBW5HcpVNrhkyGCo= Received: by 10.35.63.2 with SMTP id q2mr2928428pyk; Thu, 08 Jun 2006 14:09:05 -0700 (PDT) Received: by 10.35.31.2 with HTTP; Thu, 8 Jun 2006 14:09:05 -0700 (PDT) Message-ID: <58a398810606081409o3026d11cnd9f5f3a16b0243e@mail.gmail.com> Date: Thu, 8 Jun 2006 17:09:05 -0400 From: "mcquaid mcquaid" To: "GnomeMeeting development mailing list" In-Reply-To: <58a398810606061625x7684427q73db38225fa398dc@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10127_1193274.1149800945207" References: <58a398810606061625x7684427q73db38225fa398dc@mail.gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.359 tagged_above=-999 required=2 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.359 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Re: no audio on incoming calls. X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 21:09:10 -0000 ------=_Part_10127_1193274.1149800945207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Can I get any assistance on this or is there something else I should be providing? I can get other voip apps like linphone working but I can't get ekiga to transmit audio either way on incoming calls. Not sure if it's any help but asterisk seems to behave in the same manner. With asterisk I again could make outgoing call fine, but for incoming it would route calls to my local sipphone, but no audio either way. On 6/6/06, mcquaid mcquaid wrote: > > I have tried ekiga from time to time, and now using the latest cvs, I > still have the same problem. > > On outgoing calls, audio transmits both ways without issue. > > When receiving a call, no audio is transmitted either way. > > I realize it'll probably be considered a firewall issue, but linphone has > always worked for me and I have never setup stun or a nat traversal method > in linphone. I'd prefer to use ekiga instead of linphone. > > Here is the output of an incoming call that lasts until ekiga reports > 'remote user cleared the call'. > > I tried ekiga lastest cvs as I read about 2.02 hoping this might have been > resolved. > > > > ------=_Part_10127_1193274.1149800945207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Can I get any assistance on this or is there something else I should be providing?  I can get other voip apps like linphone working but I can't get ekiga to transmit audio either way on incoming calls.  Not sure if it's any help but asterisk seems to behave in the same manner.  With asterisk I again could make outgoing call fine, but for incoming it would route calls to my local sipphone, but no audio either way.

On 6/6/06, mcquaid mcquaid <mcquaidster@gmail.com> wrote:
I have tried ekiga from time to time, and now using the latest cvs, I still have the same problem.

On outgoing calls, audio transmits both ways without issue.

When receiving a call, no audio is transmitted either way.

I realize it'll probably be considered a firewall issue, but linphone has always worked for me and I have never setup stun or a nat traversal method in linphone.  I'd prefer to use ekiga instead of linphone.

Here is the output of an incoming call that lasts until ekiga reports 'remote user cleared the call'.

I tried ekiga lastest cvs as I read about 2.02 hoping this might have been resolved.




------=_Part_10127_1193274.1149800945207-- From dsandras@seconix.com Fri Jun 9 03:56:41 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5D27B3B006E for ; Fri, 9 Jun 2006 03:56:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05479-07 for ; Fri, 9 Jun 2006 03:56:39 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 62A113B017E for ; Fri, 9 Jun 2006 03:56:39 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 2E8E349758 for ; Fri, 9 Jun 2006 09:38:49 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16204-09 for ; Fri, 9 Jun 2006 09:38:42 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 6559949755 for ; Fri, 9 Jun 2006 09:38:42 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Re: no audio on incoming calls. From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <58a398810606081409o3026d11cnd9f5f3a16b0243e@mail.gmail.com> References: <58a398810606061625x7684427q73db38225fa398dc@mail.gmail.com> <58a398810606081409o3026d11cnd9f5f3a16b0243e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 09 Jun 2006 09:56:30 +0200 Message-Id: <1149839790.3351.0.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 07:56:41 -0000 You should provide a debug 4 output. Le jeudi 08 juin 2006 à 17:09 -0400, mcquaid mcquaid a écrit : > Can I get any assistance on this or is there something else I should > be providing? I can get other voip apps like linphone working but I > can't get ekiga to transmit audio either way on incoming calls. Not > sure if it's any help but asterisk seems to behave in the same manner. > With asterisk I again could make outgoing call fine, but for incoming > it would route calls to my local sipphone, but no audio either way. > > On 6/6/06, mcquaid mcquaid wrote: > I have tried ekiga from time to time, and now using the latest > cvs, I still have the same problem. > > On outgoing calls, audio transmits both ways without issue. > > When receiving a call, no audio is transmitted either way. > > I realize it'll probably be considered a firewall issue, but > linphone has always worked for me and I have never setup stun > or a nat traversal method in linphone. I'd prefer to use > ekiga instead of linphone. > > Here is the output of an incoming call that lasts until ekiga > reports 'remote user cleared the call'. > > I tried ekiga lastest cvs as I read about 2.02 hoping this > might have been resolved. > > > > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From ph.l@libertysurf.fr Sat Jun 10 12:49:37 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 174BA3B01B8 for ; Sat, 10 Jun 2006 12:49:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15518-01 for ; Sat, 10 Jun 2006 12:49:36 -0400 (EDT) Received: from smtp4.mail.easynet.fr (smarthost169.mail.easynet.fr [212.180.1.169]) by menubar.gnome.org (Postfix) with ESMTP id C9C343B032B for ; Sat, 10 Jun 2006 12:49:35 -0400 (EDT) Received: from asi-236.asi256ip.easynet.fr ([212.180.39.236] helo=[145.111.24.1]) by smtp4.mail.easynet.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Fp6fr-0001ZY-Dc for gnomemeeting-devel-list@gnome.org; Sat, 10 Jun 2006 18:50:59 +0200 Message-ID: <448AF812.4010106@libertysurf.fr> Date: Sat, 10 Jun 2006 18:49:22 +0200 From: Philippe Lefevre User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: GnomeMeeting devel list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.839 tagged_above=-999 required=2 tests=[AWL=-1.437, BAYES_05=-1.11, DNS_FROM_RFC_POST=1.708] X-Spam-Score: -0.839 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ekiga 2.0.2 Ubuntu packages X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 16:49:37 -0000 Hi all, For a few days I'm looking for Ekiga 2.0.2 for ubuntu packages @ http://www.ekiga.org but there are no link available yet. Is this normal ? Thanks. PhiL From mathiaschulze@gmail.com Sun Jun 11 10:47:28 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7E1CC3B00B0 for ; Sun, 11 Jun 2006 10:47:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14779-09 for ; Sun, 11 Jun 2006 10:47:27 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by menubar.gnome.org (Postfix) with ESMTP id 6898E3B0084 for ; Sun, 11 Jun 2006 10:47:27 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id 9so1563867nzo for ; Sun, 11 Jun 2006 07:46:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=RdwAYw0jPdY9iOC0Sf+iOKQJ9I7YfnL/kWXyEPnc+Cr+QIVa1sKM88ZdFWngpOkudGwRUvtt1Aw9vAL7lpvseD6hTwpLtjhbhu306m/DpJDRigRtWN/PSaYRcSohSjgiAaMN7SNdOXCHLIjQ0ZzdPpKX46kbgKn0qo2/Dg4UYbo= Received: by 10.37.2.45 with SMTP id e45mr7180725nzi; Sun, 11 Jun 2006 07:46:45 -0700 (PDT) Received: from vaio ( [71.98.110.104]) by mx.gmail.com with ESMTP id 37sm151203nzf.2006.06.11.07.46.44; Sun, 11 Jun 2006 07:46:45 -0700 (PDT) From: Mathias Schulze To: gnomemeeting-devel-list@gnome.org Content-Type: text/plain Date: Sun, 11 Jun 2006 10:46:43 -0400 Message-Id: <1150037203.24558.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.821 tagged_above=-999 required=2 tests=[AWL=-0.779, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.821 X-Spam-Level: Subject: [GnomeMeeting-devel-list] alsa default device X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 14:47:28 -0000 Hello, I would like to make Ekiga automatically use my USB Headset whenever it is plugged in. It is no problem to switch the default device to the headset by a udev rule. But Ekiga seems to ignore any changes of the default device after start-up. I think if the default device is selected Ekiga should check the current default device immediately before starting the conversation. So if someone calls I can plug in the USB headset and accept the call. An example of a program which seems to do this is the gnome music player "Listen". An even better solution (but maybe too much work?) could be if Ekiga pops up a request whenever a new audio device appears to ask the user if this device should be used. Such request appears e.g. under Ubuntu in the control panel. Thanks for Ekiga, it's really great! Mathias From dsandras@seconix.com Mon Jun 12 04:46:20 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EDE963B00D8 for ; Mon, 12 Jun 2006 04:46:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26328-09 for ; Mon, 12 Jun 2006 04:46:16 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id B27083B009D for ; Mon, 12 Jun 2006 04:46:16 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 8BE0B83C22 for ; Mon, 12 Jun 2006 10:26:53 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29245-09 for ; Mon, 12 Jun 2006 10:26:48 +0200 (CEST) Received: from [192.168.0.161] (157.137-245-81.adsl-dyn.isp.belgacom.be [81.245.137.157]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id BF7E583C1F for ; Mon, 12 Jun 2006 10:26:48 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Ekiga 2.0.2 Ubuntu packages From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <448AF812.4010106@libertysurf.fr> References: <448AF812.4010106@libertysurf.fr> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 12 Jun 2006 10:46:31 +0200 Message-Id: <1150101991.2505.12.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 08:46:20 -0000 Le samedi 10 juin 2006 à 18:49 +0200, Philippe Lefevre a écrit : > Hi all, > For a few days I'm looking for Ekiga 2.0.2 for ubuntu packages @ > http://www.ekiga.org > but there are no link available yet. Is this normal ? They are coming soon... -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Mon Jun 12 08:26:32 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 96E503B0061 for ; Mon, 12 Jun 2006 08:26:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01773-10 for ; Mon, 12 Jun 2006 08:26:29 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 0BDDA3B000D for ; Mon, 12 Jun 2006 08:26:28 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id A4ACC83C24 for ; Mon, 12 Jun 2006 13:43:24 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15346-08 for ; Mon, 12 Jun 2006 13:43:15 +0200 (CEST) Received: from [192.168.0.161] (157.137-245-81.adsl-dyn.isp.belgacom.be [81.245.137.157]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 3FB8E83C22 for ; Mon, 12 Jun 2006 13:43:15 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] alsa default device From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <1150037203.24558.24.camel@localhost.localdomain> References: <1150037203.24558.24.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 12 Jun 2006 14:03:41 +0200 Message-Id: <1150113821.7909.5.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 12:26:32 -0000 Hi, Le dimanche 11 juin 2006 à 10:46 -0400, Mathias Schulze a écrit : > Hello, > > I would like to make Ekiga automatically use my USB Headset whenever it > is plugged in. It is no problem to switch the default device to the > headset by a udev rule. But Ekiga seems to ignore any changes of the > default device after start-up. > It is most probably due to ALSA and libasound if I understand correctly what you mean. If you change from "USB Headset" to "Soundcard" or to "Default", Ekiga will work correctly. However, you probably mean that you want to select "Default" as device in Ekiga and that "Default" will be linked to the USB headset or to the soundcard depending if the headset is plugged in or not. For Ekiga, it is transparent. Ekiga simply open the "Default" device when playing sounds. If the "Default" device is linked in real time to the USB headset while Ekiga is running, and if it still uses the sound card, then it means that libasound already mapped the default device to the soundcard when starting the application and doesn't accept changing it. So I would say that I'm 100% confident it is an ALSA limitation. However, I tried here changing the settings of my default device through .asoundrc when Ekiga is running and it works. > I think if the default device is selected Ekiga should check the current > default device immediately before starting the conversation. So if > someone calls I can plug in the USB headset and accept the call. > An example of a program which seems to do this is the gnome music player > "Listen". It is transparent for Ekiga. Ekiga opens the "Default" device whatever it is through ALSA. > > An even better solution (but maybe too much work?) could be if Ekiga > pops up a request whenever a new audio device appears to ask the user if > this device should be used. Such request appears e.g. under Ubuntu in > the control panel. It is planned in the future through HAL. > > Thanks for Ekiga, it's really great! > Mathias > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Mon Jun 12 17:23:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 441F03B01DB for ; Mon, 12 Jun 2006 17:23:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31653-03 for ; Mon, 12 Jun 2006 17:23:08 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 994B13B0010 for ; Mon, 12 Jun 2006 17:23:08 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 666F683C23 for ; Mon, 12 Jun 2006 23:01:22 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19698-06 for ; Mon, 12 Jun 2006 23:01:18 +0200 (CEST) Received: from [192.168.0.161] (157.137-245-81.adsl-dyn.isp.belgacom.be [81.245.137.157]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id AFAEE83C22 for ; Mon, 12 Jun 2006 23:01:18 +0200 (CEST) From: Damien Sandras To: gnomemeeting-devel-list@gnome.org Content-Type: text/plain Date: Mon, 12 Jun 2006 23:24:02 +0200 Message-Id: <1150147442.11823.2.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Subject: [GnomeMeeting-devel-list] New user interface : first stubs X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 21:23:10 -0000 Hi to all, I committed the first stubs of the new user interface. Please do not criticize too much as it is work in progress and it is in the very early stages of development. Julien is working on big changes too, but that should have no impact on the user interface. In the next few weeks, I will work more on : - the user interface - sip support (integrate Craig's changes) And finally work on a roster. Enjoy, -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From jpuydt@free.fr Tue Jun 13 13:58:03 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 530F33B03CF for ; Tue, 13 Jun 2006 13:58:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01110-02 for ; Tue, 13 Jun 2006 13:58:01 -0400 (EDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by menubar.gnome.org (Postfix) with ESMTP id EC4F23B00DB for ; Tue, 13 Jun 2006 13:58:00 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by postfix1-c.free.fr (Postfix) with ESMTP id 91A4B1CF1DC3 for ; Tue, 13 Jun 2006 17:47:25 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-32-82-254-24-205.adsl.proxad.net [82.254.24.205]) by smtp6-g19.free.fr (Postfix) with ESMTP id CD69E2286C for ; Tue, 13 Jun 2006 18:42:21 +0200 (CEST) Message-ID: <448EC473.7060800@free.fr> Date: Tue, 13 Jun 2006 15:58:11 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <448B2A40.5060600@free.fr> <20060612174347.5181a8f9@localhost.localdomain> <448DABA7.4060103@free.fr> <200606130951.56969.ebischoff@nerim.net> In-Reply-To: <200606130951.56969.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.567 tagged_above=-999 required=2 tests=[AWL=0.032, BAYES_00=-2.599] X-Spam-Score: -2.567 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 17:58:03 -0000 Hi, in private mails (with quite big attachments since I provided some sample stupid code), Éric Bischoff found my code not that explicit concerning what I have in mind. Since I would like to keep things as opened as possible, I drop my text here :-) Let's see if I can manage to give useful ideas. ***** BIG WORDS Model - View - Controller ***** VIEWING (GENERIC) We need to be able to present a book to the user. For that, the view needs to have a list of contacts (no, a single contact definitely isn't enough!). So we need a function call to get a list of contacts. The problem is that this list will change during time (new contacts added, others removed, presence changed, status message changed, and the list goes on). So the view will need to be notified about it. Hence the idea that the book will have "contact-added" and "contact-removed" signals, and the contacts a "updated" signal. In addition to that, there is an interesting special case to handle : you have a contact in a book, and this contact shows up in a search result. When you remove the contact from the book, we want to make it disappear from the list too. Hence a "removed" signal for contacts. Now this is all nice, but what can we do if an addressbook contains millions of entries ? And if a search gives thousands of results ? In such cases, my stance is that the low level code should do something about it, since it is the one giving the problem. How can the high level code cope correctly with the situation anyway ? Only the low level code can say "Eh, I already made two hundred contacts go through the wire for that search, perhaps I should make it easy!". The question to really ask, and to which I have no satisfactory answer is: "How do me make the low level tell the high level it had to cut the list ?". ***** VIEWING (CONTACTS) The contacts should contain enough to be viewed from a generic view in the contacts window, and be shown in a search result. That won't prevent some other parts of the code to make a better use of them. For example, in the contact window we will probably be able to see a contact's title and description, but not its detailed presence, while the main window will contain a much better and more specific view for the live contacts. ***** CONTROLLING (GENERIC) Now, we want to be able to act on our objects ; say rename a book or a contact, subscribe/unsubscribe to its presence, etc. The best thing to do is to be able to get menus for each of them. Notice the plural: we will certainly to have at least menu in the menu bar and a popup menu. The first bad news about such menus is that they won't be generic : they will depend heavily on the specific type of object (no rename for avahi contacts, subscribe/unsubscribe only for XMPP contacts...). So we will certainly need some sort of shared actions that will be basic bricks for building menu (like the shared-actions.[ch] of my first round of proposals), that each implementation will mix as it sees fit. The second bad news about them is that they won't be static either. They will have to update themselves following the object they are attached to. Say your nice XMPP contact is connected with a client which has VoIP support, but now connects with a no-VoIP client, and disconnects the first : we want the "Call" menuitem to disappear to reflect this. So my proposition (no code yet) is that those menus will be obtained by subclassing of GtkMenu, register to get signals from the contact/book they are attached to, and use that to keep themselves up to date. ***** CONTROLLING (CONTACTS) Let's try to be more specific: in avahi-contact-menu.h, we would have: GtkWidget *avahi_contact_menu_new (AvahiContact *contact); and in gm-contact.h: GtkWidget *gm_contact_get_menu_new (GmContact *contact); This later function would be different in each implementation, which allows for example the avahi_contact_get_menu_new implementation to call avahi_contact_menu_new. The high level code called a generic function, but got access to a very specific implementation, which knows the full api of the specific contact, and hence will provide the best service. ***** CONTROLLING (BOOKS) Perhaps the menu shouldn't be attached to the book himself, but to its view. That would allow to place things such as "Show offline contacts" in it. Mostly the idea would be to have controllers for both the model-as-model and its view-as-model. ***** ABOUT EVOLUTION-DATA-SERVER The evolution-data-server api looks pretty good -- except that it seems to mainly handle static vcard-based contacts, where I would like to be able to handle things like. For example, we find a nice contacts-changed signal, but in the EBookView api... not in the EBook api, which seems strange. ***** ABOUT LIBGAIM I shriek everytime I read/think about that comment in blist.h (just before the declaration of struct _GaimBuddy) : "A buddy. This contains everything Gaim will ever need to know about someone on the buddy list. Everything." (sic). and that one (before the declaration of struct _GaimContact) : "A contact. This contains everything Gaim will ever need to know about a contact." and that one (before the declaration of struct _GaimGroup) : "A group. This contains everything Gaim will ever need to know about a group." Notice that the comment before struct _GaimChat, although very similar, isn't so bad in my eye :-) Notice too that although I find the way it is done inelegant, it still is very good and efficient to get the job done, and contains quite an impressive list of good ideas. (And it's more portable as ekiga, gasp!) ***** ABOUT LIBGALAGO Why, why, oh why does it contain a GalagoList api which looks so much like a GList but isn't !? Apart from that, I would say it looks nice, but is out of scope for what we want to do right now : it doesn't deal with addressbooks, but with persons as single. "Using" it would be nice at some point. ***** LAST WORDS Congratulations, comments and flames welcome, but flames will end in /dev/null. Snark From jpuydt@free.fr Thu Jun 15 04:55:35 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7B51D3B008E for ; Thu, 15 Jun 2006 04:55:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24192-02 for ; Thu, 15 Jun 2006 04:55:31 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id C36A43B00CA for ; Thu, 15 Jun 2006 04:55:30 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp3-g19.free.fr (Postfix) with ESMTP id 26E1F496DD for ; Thu, 15 Jun 2006 10:54:59 +0200 (CEST) Message-ID: <4491205F.5070708@free.fr> Date: Thu, 15 Jun 2006 10:54:55 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.369 tagged_above=-999 required=2 tests=[AWL=0.230, BAYES_00=-2.599] X-Spam-Score: -2.369 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 08:55:35 -0000 Hi, in private mails (with quite big attachments since I provided some sample stupid code), Éric Bischoff found my code not that explicit concerning what I have in mind. Since I would like to keep things as opened as possible, I drop my text here :-) Let's see if I can manage to give useful ideas. ***** BIG WORDS Model - View - Controller ***** VIEWING (GENERIC) We need to be able to present a book to the user. For that, the view needs to have a list of contacts (no, a single contact definitely isn't enough!). So we need a function call to get a list of contacts. The problem is that this list will change during time (new contacts added, others removed, presence changed, status message changed, and the list goes on). So the view will need to be notified about it. Hence the idea that the book will have "contact-added" and "contact-removed" signals, and the contacts a "updated" signal. In addition to that, there is an interesting special case to handle : you have a contact in a book, and this contact shows up in a search result. When you remove the contact from the book, we want to make it disappear from the list too. Hence a "removed" signal for contacts. Now this is all nice, but what can we do if an addressbook contains millions of entries ? And if a search gives thousands of results ? In such cases, my stance is that the low level code should do something about it, since it is the one giving the problem. How can the high level code cope correctly with the situation anyway ? Only the low level code can say "Eh, I already made two hundred contacts go through the wire for that search, perhaps I should make it easy!". The question to really ask, and to which I have no satisfactory answer is: "How do me make the low level tell the high level it had to cut the list ?". ***** VIEWING (CONTACTS) The contacts should contain enough to be viewed from a generic view in the contacts window, and be shown in a search result. That won't prevent some other parts of the code to make a better use of them. For example, in the contact window we will probably be able to see a contact's title and description, but not its detailed presence, while the main window will contain a much better and more specific view for the live contacts. ***** CONTROLLING (GENERIC) Now, we want to be able to act on our objects ; say rename a book or a contact, subscribe/unsubscribe to its presence, etc. The best thing to do is to be able to get menus for each of them. Notice the plural: we will certainly to have at least menu in the menu bar and a popup menu. The first bad news about such menus is that they won't be generic : they will depend heavily on the specific type of object (no rename for avahi contacts, subscribe/unsubscribe only for XMPP contacts...). So we will certainly need some sort of shared actions that will be basic bricks for building menu (like the shared-actions.[ch] of my first round of proposals), that each implementation will mix as it sees fit. The second bad news about them is that they won't be static either. They will have to update themselves following the object they are attached to. Say your nice XMPP contact is connected with a client which has VoIP support, but now connects with a no-VoIP client, and disconnects the first : we want the "Call" menuitem to disappear to reflect this. So my proposition (no code yet) is that those menus will be obtained by subclassing of GtkMenu, register to get signals from the contact/book they are attached to, and use that to keep themselves up to date. ***** CONTROLLING (CONTACTS) Let's try to be more specific: in avahi-contact-menu.h, we would have: GtkWidget *avahi_contact_menu_new (AvahiContact *contact); and in gm-contact.h: GtkWidget *gm_contact_get_menu_new (GmContact *contact); This later function would be different in each implementation, which allows for example the avahi_contact_get_menu_new implementation to call avahi_contact_menu_new. The high level code called a generic function, but got access to a very specific implementation, which knows the full api of the specific contact, and hence will provide the best service. ***** CONTROLLING (BOOKS) Perhaps the menu shouldn't be attached to the book himself, but to its view. That would allow to place things such as "Show offline contacts" in it. Mostly the idea would be to have controllers for both the model-as-model and its view-as-model. ***** ABOUT EVOLUTION-DATA-SERVER The evolution-data-server api looks pretty good -- except that it seems to mainly handle static vcard-based contacts, where I would like to be able to handle things like. For example, we find a nice contacts-changed signal, but in the EBookView api... not in the EBook api, which seems strange. ***** ABOUT LIBGAIM I shriek everytime I read/think about that comment in blist.h (just before the declaration of struct _GaimBuddy) : "A buddy. This contains everything Gaim will ever need to know about someone on the buddy list. Everything." (sic). and that one (before the declaration of struct _GaimContact) : "A contact. This contains everything Gaim will ever need to know about a contact." and that one (before the declaration of struct _GaimGroup) : "A group. This contains everything Gaim will ever need to know about a group." Notice that the comment before struct _GaimChat, although very similar, isn't so bad in my eye :-) Notice too that although I find the way it is done inelegant, it still is very good and efficient to get the job done, and contains quite an impressive list of good ideas. (And it's more portable as ekiga, gasp!) ***** ABOUT LIBGALAGO Why, why, oh why does it contain a GalagoList api which looks so much like a GList but isn't !? Apart from that, I would say it looks nice, but is out of scope for what we want to do right now : it doesn't deal with addressbooks, but with persons as single. "Using" it would be nice at some point. ***** LAST WORDS Congratulations, comments and flames welcome, but flames will end in /dev/null. Snark PS: this message is already two or three days old... but got stuck. From ebischoff@nerim.net Thu Jun 15 07:18:00 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 98B4A3B032E for ; Thu, 15 Jun 2006 07:18:00 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01896-02 for ; Thu, 15 Jun 2006 07:17:57 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id 2C6AF3B0488 for ; Thu, 15 Jun 2006 07:17:56 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 3CBA240F45 for ; Thu, 15 Jun 2006 13:17:52 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Thu, 15 Jun 2006 13:18:05 +0200 User-Agent: KMail/1.8.2 References: <4491205F.5070708@free.fr> In-Reply-To: <4491205F.5070708@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606151318.05338.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.578 tagged_above=-999 required=2 tests=[AWL=0.021, BAYES_00=-2.599] X-Spam-Score: -2.578 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 11:18:01 -0000 Hi Julien, and thanks for this nice document. That looks like a good basis for thinkin= g=20 aloud :-). Le Jeudi 15 Juin 2006 10:54, Julien PUYDT a =C3=A9crit=C2=A0: > ***** BIG WORDS > > Model - View - Controller Excellent basis. > ***** VIEWING (GENERIC) > > We need to be able to present a book to the user. For that, the view > needs to have a list of contacts (no, a single contact definitely isn't > enough!). So we need a function call to get a list of contacts. In this paragraph I will assume that you mean "the view needs a list of all= =20 contacts from the address book driver". If it is not what you mean, please= =20 ignore this paragraph... The view needs to display, say, 10 contects at a time. No need to keep a li= st=20 of all contacts in memory. All we "need" is a function that gets _one_ contact from the driver. The vi= ew=20 can then use this information to keep the list of the 10 contacts that it=20 currently displays. > The problem is that this list will change during time (new contacts > added, others removed, presence changed, status message changed, and the > list goes on). So the view will need to be notified about it. Hence the > idea that the book will have "contact-added" and "contact-removed" > signals, and the contacts a "updated" signal. > In addition to that, there is an interesting special case to handle : > you have a contact in a book, and this contact shows up in a search > result. When you remove the contact from the book, we want to make it > disappear from the list too. Hence a "removed" signal for contacts. While this sounds cool, I am not sure that this will be possible in some=20 circumstances. The underlying address book (evolution, KDE address book, LD= AP=20 server, Zeroconf, ...) might not have the mechanisms to send such a signal. I can imagine situations where some users on machine A update a LDAP server= on=20 machine B while Ekiga runs on machine C, with the network connection betwee= n=20 B and C being temporarily broken. Will an update message come up to the=20 driver, and if yes when and how? Please notice that I do not know LDAP well and that such mechanisms might=20 exist. Should that be the case, please ignore these paragraphs. What do I propose instead? To be less ambitious, and have an address book t= hat=20 only pulls the data from the data source. If the user does not press=20 "refresh", then he/she might have outdated information. If he/she presses=20 "refresh", then the addresses are fetched again from the source. > Now this is all nice, but what can we do if an addressbook contains > millions of entries ? And if a search gives thousands of results ? In > such cases, my stance is that the low level code should do something > about it, since it is the one giving the problem. I do not like that repartition of tasks. Let me take an example. When you write an operating system, you write: =2D disk drivers (the low level code that does physical read and write from and to the hard disk) =2D a filesystem (the high level code that gathers individual sectors into files, handles a cache, etc) The low level code should not be bothered with handling the disk cache. Oka= y,=20 the problem comes from the disk driver, because it does slow access to the= =20 medium. That does not mean that it's not another component, the filesystem,= =20 that can solve it. Why this repartition of tasks? Because the performance problem is a problem= =20 that can be shared by many disk drivers. Therefore, the solution can be put= =20 in common in the high level code. > How can the high level > code cope correctly with the situation anyway ? Only the low level code > can say "Eh, I already made two hundred contacts go through the wire for > that search, perhaps I should make it easy!". Why transfer 200 contacts when the view knows that it needs only 10? > The question to really ask, and to which I have no satisfactory answer > is: "How do me make the low level tell the high level it had to cut the > list ?". The views know that contacts 301 to 309 are displayed. It's the view that=20 knows where to cut. In fact, there's nothing to cut, since all the view doe= s=20 is ask the driver for the contects it needs. > ***** VIEWING (CONTACTS) > > The contacts should contain enough to be viewed from a generic view in > the contacts window, and be shown in a search result. That won't prevent > some other parts of the code to make a better use of them. > > For example, in the contact window we will probably be able to see a > contact's title and description, but not its detailed presence, while > the main window will contain a much better and more specific view for > the live contacts. You say that the "contact" class must have _enough_ information to be used= =20 both in situation A and in sitation B. It would be better to have _different_ "contact" classes for situations "A"= =20 and "B". The list of contacts could just manage a name, a company and a phone number= =2E=20 The search result could handle much more detailed information. In other words, there's no need to put all the model's data into the views'= =20 data. Each view can handle the data it needs. > ***** CONTROLLING (GENERIC) > > Now, we want to be able to act on our objects ; say rename a book or a > contact, subscribe/unsubscribe to its presence, etc. > > The best thing to do is to be able to get menus for each of them. Notice > the plural: we will certainly to have at least menu in the menu bar and > a popup menu. > > The first bad news about such menus is that they won't be generic : they > will depend heavily on the specific type of object (no rename for avahi > contacts, subscribe/unsubscribe only for XMPP contacts...). So we will > certainly need some sort of shared actions that will be basic bricks for > building menu (like the shared-actions.[ch] of my first round of > proposals), that each implementation will mix as it sees fit. I assume here that an 'implementation" is one of the address book drivers, = and=20 that you mean that the drivers will be in charge of building menus. If thos= e=20 assumptions are wrong, the paragraph below does not apply, please just igno= re=20 it. Just the same as a hard disk driver does not display menus to the user, I=20 think that the address book drivers in Ekiga should not be responsible for= =20 user interaction. The high level code should be responsible for that. Of course the contents = of=20 the various menus depends on the address book capabilities. That's why the= =20 API between the driver and the high level code should include "query=20 capabilities functions:" class addressBook { virtual bool isReadOnly() =3D 0; virtual bool canSubscribeContacts() =3D 0; ... }; > The second bad news about them is that they won't be static either. They > will have to update themselves following the object they are attached > to. Say your nice XMPP contact is connected with a client which has VoIP > support, but now connects with a no-VoIP client, and disconnects the > first : we want the "Call" menuitem to disappear to reflect this. > > So my proposition (no code yet) is that those menus will be obtained by > subclassing of GtkMenu, register to get signals from the contact/book > they are attached to, and use that to keep themselves up to date. In your example, a signal is not needed. Knowing that there is no VoIP number in the current contact is enough. > ***** CONTROLLING (CONTACTS) > > Let's try to be more specific: > in avahi-contact-menu.h, we would have: > GtkWidget *avahi_contact_menu_new (AvahiContact *contact); > and in gm-contact.h: > GtkWidget *gm_contact_get_menu_new (GmContact *contact); > > This later function would be different in each implementation, which > allows for example the avahi_contact_get_menu_new implementation to call > avahi_contact_menu_new. The high level code called a generic function, > but got access to a very specific implementation, which knows the full > api of the specific contact, and hence will provide the best service. Again, this logic should be in the high-level code and needs not be=20 avahi-specific. What exactly should be presented to the user could be=20 determined from querying the address book for its capabilities. > ***** CONTROLLING (BOOKS) > > Perhaps the menu shouldn't be attached to the book himself, but to its > view. That would allow to place things such as "Show offline contacts" > in it. Mostly the idea would be to have controllers for both the > model-as-model and its view-as-model. Agree. > ***** ABOUT EVOLUTION-DATA-SERVER > > The evolution-data-server api looks pretty good -- except that it seems > to mainly handle static vcard-based contacts, where I would like to be > able to handle things like. > > For example, we find a nice contacts-changed signal, but in the > EBookView api... not in the EBook api, which seems strange. > > ***** ABOUT LIBGAIM > > I shriek everytime I read/think about that comment in blist.h (just > before the declaration of struct _GaimBuddy) : > "A buddy. This contains everything Gaim will ever need to know about > someone on the buddy list. Everything." (sic). > and that one (before the declaration of struct _GaimContact) : > "A contact. This contains everything Gaim will ever need to know about > a contact." > and that one (before the declaration of struct _GaimGroup) : > "A group. This contains everything Gaim will ever need to know about a > group." > > Notice that the comment before struct _GaimChat, although very similar, > isn't so bad in my eye :-) > > Notice too that although I find the way it is done inelegant, it still > is very good and efficient to get the job done, and contains quite an > impressive list of good ideas. (And it's more portable as ekiga, gasp!) > > ***** ABOUT LIBGALAGO > > Why, why, oh why does it contain a GalagoList api which looks so much > like a GList but isn't !? > > Apart from that, I would say it looks nice, but is out of scope for what > we want to do right now : it doesn't deal with addressbooks, but with > persons as single. > > "Using" it would be nice at some point. > > ***** LAST WORDS > > Congratulations, comments and flames welcome, but flames will end in > /dev/null. It definitly deserves congratulations. You forgot to mention one of your ni= ce=20 ideas, that it that it should be possible to search in several address book= s=20 at a time. =46or the comments, please note that my comments are based on a lot of=20 assumptions and guesses. In particular, I assume that you have in mind a=20 different assignment of tasks of the various software layers than the one=20 that I would like to see. If those assumptions reveal wrong, then of course= =20 my comments do not make much sense. If I did not misinterpret your thoughts, you have a very lazy view of the=20 high-level code. It's software that sits down and waits for signals to act.= =20 Somehow, the high level code provides "services" to the drivers. The driver= s=20 are the ones who understand what's going on. I have the opposite view: the address book drivers are simple and stupid.=20 Their main task is to go and fetch the requested contacts. The high level=20 code has an active attitude: it queries the drivers for contacts, it querie= s=20 the drivers capabilities, it displays the contact windows, it handles the=20 menues... The high level code has the real intelligence. I hope that helps, =2D-=20 Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m=C3=A9dire." (Le concombre masqu=C3=A9, Mandriva) From kk@verfaction.de Thu Jun 15 10:03:55 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C686B3B0336 for ; Thu, 15 Jun 2006 10:03:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15471-01 for ; Thu, 15 Jun 2006 10:03:54 -0400 (EDT) Received: from mx.verfaction.de (mx.verfaction.de [212.9.177.23]) by menubar.gnome.org (Postfix) with ESMTP id 779793B00CE for ; Thu, 15 Jun 2006 10:03:54 -0400 (EDT) Received: from erebos.verfaction.de ([2001:14b0:201:7357::1] helo=homemx.verfaction.de ident=Debian-exim) by mx.verfaction.de with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FqsRp-0003kA-3Z for gnomemeeting-devel-list@gnome.org; Thu, 15 Jun 2006 16:03:52 +0200 Received: from ganymede.kk.de ([192.168.7.10]) by homemx.verfaction.de with esmtp (Exim 4.50) id 1FqsRk-0000ld-Dw for gnomemeeting-devel-list@gnome.org; Thu, 15 Jun 2006 16:03:48 +0200 From: Kilian Krause To: GnomeMeeting development mailing list In-Reply-To: <200606081002.37875.conrad_videokonferenz@gmx.de> References: <200606081002.37875.conrad_videokonferenz@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aitPD1cXT483JdjYdYcu" Date: Thu, 15 Jun 2006 16:03:43 +0200 Message-Id: <1150380224.6599.22.camel@ganymede.verfaction.de> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-SA-Exim-Connect-IP: 2001:14b0:201:7357::1 X-SA-Exim-Mail-From: kk@verfaction.de X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 14:03:56 -0000 --=-aitPD1cXT483JdjYdYcu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hey Conrad, Am Donnerstag, den 08.06.2006, 10:02 +0000 schrieb Conrad Beckert: > has anybody an idea where the Debian packages for Ekiga 2.0.2 (or the=20 > corresponding CVS versions) are? on their way. > The last version I can install using apt-get a couple of days old (May 25= - or=20 > somethin) - at least this is a version with the nonfunctional German loc= ale.=20 > (defaults to English) >=20 > What's up? /me is having a sheer lack of time and thus it took me a while to get everything polished and fixed just like i love to have it. =3D) Everything should be back to normal as of tonight (eventually sarge cvs snaps and win32 will remain for the weekend - we'll see) --=20 Best regards, Kilian --=-aitPD1cXT483JdjYdYcu Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEkWi/vdkzt4X+wX8RAnZ/AJoCW2qvo1l8kFsAJzogWEPKv73LUACZAZk6 n6VWZ1JiCCXnGNsq5yEsLwU= =VwN+ -----END PGP SIGNATURE----- --=-aitPD1cXT483JdjYdYcu-- From jpuydt@free.fr Thu Jun 15 11:41:17 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D25F23B0616 for ; Thu, 15 Jun 2006 11:41:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20025-08 for ; Thu, 15 Jun 2006 11:41:15 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id 8BF5B3B041B for ; Thu, 15 Jun 2006 11:41:14 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp6-g19.free.fr (Postfix) with ESMTP id 3FD8B227D9 for ; Thu, 15 Jun 2006 17:40:32 +0200 (CEST) Message-ID: <44917F71.10408@free.fr> Date: Thu, 15 Jun 2006 17:40:33 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> In-Reply-To: <200606151318.05338.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.337 tagged_above=-999 required=2 tests=[AWL=0.185, BAYES_00=-2.599, TW_AV=0.077] X-Spam-Score: -2.337 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:41:18 -0000 Éric Bischoff a écrit : >> ***** VIEWING (GENERIC) >> >> We need to be able to present a book to the user. For that, the view >> needs to have a list of contacts (no, a single contact definitely isn't >> enough!). So we need a function call to get a list of contacts. > > In this paragraph I will assume that you mean "the view needs a list of all > contacts from the address book driver". If it is not what you mean, please > ignore this paragraph... Well, all contacts may be asking too much. I expect drivers to keep things sane. > The view needs to display, say, 10 contects at a time. No need to keep a list > of all contacts in memory. > > All we "need" is a function that gets _one_ contact from the driver. The view > can then use this information to keep the list of the 10 contacts that it > currently displays. Blah. If you're gonna loop on a list of contacts anyway, then get the list at once. Saying "I get only the 10 I need" is nice, but how do you tell the driver which they are ? Especially a roster XMPP generally comes as a single roster push you ask for when connecting, then little update pushes. >> The problem is that this list will change during time (new contacts >> added, others removed, presence changed, status message changed, and the >> list goes on). So the view will need to be notified about it. Hence the >> idea that the book will have "contact-added" and "contact-removed" >> signals, and the contacts a "updated" signal. >> In addition to that, there is an interesting special case to handle : >> you have a contact in a book, and this contact shows up in a search >> result. When you remove the contact from the book, we want to make it >> disappear from the list too. Hence a "removed" signal for contacts. > > While this sounds cool, I am not sure that this will be possible in some > circumstances. The underlying address book (evolution, KDE address book, LDAP > server, Zeroconf, ...) might not have the mechanisms to send such a signal. No problem : then they don't. Let's take the avahi book. It will probably update the list of users regularly (and have some action to update *now*). How will it work ? Well, it will populate a cache with those contacts, and on updating, flush it ("contact-removed" emitted on all of them), then repopulate it ("contact-added"). > I can imagine situations where some users on machine A update a LDAP server on > machine B while Ekiga runs on machine C, with the network connection between > B and C being temporarily broken. Will an update message come up to the > driver, and if yes when and how? If the backend doesn't give incremental changes, that still fits in my design. > What do I propose instead? To be less ambitious, and have an address book that > only pulls the data from the data source. If the user does not press > "refresh", then he/she might have outdated information. If he/she presses > "refresh", then the addresses are fetched again from the source. Bad. If the backend gives incremental changes, you don't handle it. Such a design works only for the most simple backends. >> Now this is all nice, but what can we do if an addressbook contains >> millions of entries ? And if a search gives thousands of results ? In >> such cases, my stance is that the low level code should do something >> about it, since it is the one giving the problem. > > I do not like that repartition of tasks. > > Let me take an example. When you write an operating system, you write: > - disk drivers > (the low level code that does physical read and write from and to > the hard disk) > - a filesystem > (the high level code that gathers individual sectors into files, > handles a cache, etc) > > The low level code should not be bothered with handling the disk cache. Okay, > the problem comes from the disk driver, because it does slow access to the > medium. That does not mean that it's not another component, the filesystem, > that can solve it. > > Why this repartition of tasks? Because the performance problem is a problem > that can be shared by many disk drivers. Therefore, the solution can be put > in common in the high level code. Your file manager doesn't handle the filesystems itself : they all present the same interface, and take care of caching themselves. I want the addressbook manager to be *high* level. If some caching is needed between the addressbook manager and the backend, I want the driver to take care of it. In fact, I implemented a SearchBook to take care of presenting all search results (whatever the book), and it's certainly desirable to provide a CachedBook, which will avoid code duplication. >> How can the high level >> code cope correctly with the situation anyway ? Only the low level code >> can say "Eh, I already made two hundred contacts go through the wire for >> that search, perhaps I should make it easy!". > > Why transfer 200 contacts when the view knows that it needs only 10? The view may show only ten at the same time on the screen, but the mouse wheel makes it so easy to go through all of the 200, that it wouldn't be wise to have them ready. If there are several thousands, that's more annoying. >> The question to really ask, and to which I have no satisfactory answer >> is: "How do me make the low level tell the high level it had to cut the >> list ?". > > The views know that contacts 301 to 309 are displayed. It's the view that > knows where to cut. In fact, there's nothing to cut, since all the view does > is ask the driver for the contects it needs. How do you number the contacts in a sane way? >> ***** VIEWING (CONTACTS) >> >> The contacts should contain enough to be viewed from a generic view in >> the contacts window, and be shown in a search result. That won't prevent >> some other parts of the code to make a better use of them. >> >> For example, in the contact window we will probably be able to see a >> contact's title and description, but not its detailed presence, while >> the main window will contain a much better and more specific view for >> the live contacts. > > You say that the "contact" class must have _enough_ information to be used > both in situation A and in sitation B. > > It would be better to have _different_ "contact" classes for situations "A" > and "B". Of course there will be. I was discussing the base class. > The list of contacts could just manage a name, a company and a phone number. I would put the following : 1) a title (generally the name) 2) a description (for example a location, a status message, etc) 3) an icon > The search result could handle much more detailed information. Of course it cannot. Your search result is a book which needs to be able to show avahi contacts, sip contacts, call history contacts, etc... so it can only show the contacts as generic. > In other words, there's no need to put all the model's data into the views' > data. Each view can handle the data it needs. The view which is specific to an addressbook, of course can show the data from the specific contact associated to it. But the generic view can only show generic information. >> ***** CONTROLLING (GENERIC) >> >> Now, we want to be able to act on our objects ; say rename a book or a >> contact, subscribe/unsubscribe to its presence, etc. >> >> The best thing to do is to be able to get menus for each of them. Notice >> the plural: we will certainly to have at least menu in the menu bar and >> a popup menu. >> >> The first bad news about such menus is that they won't be generic : they >> will depend heavily on the specific type of object (no rename for avahi >> contacts, subscribe/unsubscribe only for XMPP contacts...). So we will >> certainly need some sort of shared actions that will be basic bricks for >> building menu (like the shared-actions.[ch] of my first round of >> proposals), that each implementation will mix as it sees fit. > > I assume here that an 'implementation" is one of the address book drivers, and > that you mean that the drivers will be in charge of building menus. If those > assumptions are wrong, the paragraph below does not apply, please just ignore > it. Yes, that's precisely that. > Just the same as a hard disk driver does not display menus to the user, I > think that the address book drivers in Ekiga should not be responsible for > user interaction The menu is supposed to contain actions which are specific to the given contact, book or view. Hence it must be created by code which is specific to that contact, book or view. It cannot be done by the generic code. > The high level code should be responsible for that. Of course the contents of > the various menus depends on the address book capabilities. That's why the > API between the driver and the high level code should include "query > capabilities functions:" > > class addressBook > { > virtual bool isReadOnly() = 0; > virtual bool canSubscribeContacts() = 0; > ... > }; No, that is wrong and I already explained why. Putting everything in the base class is bad. >> The second bad news about them is that they won't be static either. They >> will have to update themselves following the object they are attached >> to. Say your nice XMPP contact is connected with a client which has VoIP >> support, but now connects with a no-VoIP client, and disconnects the >> first : we want the "Call" menuitem to disappear to reflect this. >> >> So my proposition (no code yet) is that those menus will be obtained by >> subclassing of GtkMenu, register to get signals from the contact/book >> they are attached to, and use that to keep themselves up to date. > > In your example, a signal is not needed. > > Knowing that there is no VoIP number in the current contact is enough. That is wrong. The same contact could update itself and gain it. Or update itself and lose it. >> ***** CONTROLLING (CONTACTS) >> >> Let's try to be more specific: >> in avahi-contact-menu.h, we would have: >> GtkWidget *avahi_contact_menu_new (AvahiContact *contact); >> and in gm-contact.h: >> GtkWidget *gm_contact_get_menu_new (GmContact *contact); >> >> This later function would be different in each implementation, which >> allows for example the avahi_contact_get_menu_new implementation to call >> avahi_contact_menu_new. The high level code called a generic function, >> but got access to a very specific implementation, which knows the full >> api of the specific contact, and hence will provide the best service. > > Again, this logic should be in the high-level code and needs not be > avahi-specific. What exactly should be presented to the user could be > determined from querying the address book for its capabilities. Which means : 1) *all* of the addressbooks would by default have *all* the possible apis for such capability by default, with a isAbleToDoFoo function for each Foo capability ; 2) if an addressbook needs a new capability, we'll have to modify the base addressbook to add it in for it ; it won't just be a matter for the new code to add only what is necessary for itself in its own files. >> ***** CONTROLLING (BOOKS) >> >> Perhaps the menu shouldn't be attached to the book himself, but to its >> view. That would allow to place things such as "Show offline contacts" >> in it. Mostly the idea would be to have controllers for both the >> model-as-model and its view-as-model. > > Agree. Nice. >> Congratulations, comments and flames welcome, but flames will end in >> /dev/null. > > It definitly deserves congratulations. You forgot to mention one of your nice > ideas, that it that it should be possible to search in several address books > at a time. Well, that is the main side-effect of having a base class for contacts. > For the comments, please note that my comments are based on a lot of > assumptions and guesses. In particular, I assume that you have in mind a > different assignment of tasks of the various software layers than the one > that I would like to see. If those assumptions reveal wrong, then of course > my comments do not make much sense. I think you are focused on an addressbook as something both very big and very static, which explains many of our divergences. > If I did not misinterpret your thoughts, you have a very lazy view of the > high-level code. It's software that sits down and waits for signals to act. > Somehow, the high level code provides "services" to the drivers. The drivers > are the ones who understand what's going on. Yes, that's it. The high-level code doesn't know what an AvahiContact or EDSContact is ; it only knows avbout GmContact. That means it cannot do fancy things with them, and has to call functions on them to do anything interesting. > I have the opposite view: the address book drivers are simple and stupid. > Their main task is to go and fetch the requested contacts. The high level > code has an active attitude: it queries the drivers for contacts, it queries > the drivers capabilities, it displays the contact windows, it handles the > menues... The high level code has the real intelligence. Your high level code is very complex, and has to be modified heavily anytime we add a new type of addressbook with new capabilities. Anytime you want to do something, you should ask yourself the question: "Who knows how to do it?". You want to send a message to a contact ? Who knows if it's even possible, and how to do it ? The contact itself! Hence this should be handled by the contact. Of course, as-is that would mean a lot of code duplication. That's where we can use a toolbox ; of which you had an example in the first round of sample code I sent in private. To make it explicit for the -devel- readers, this sample code had a function: void shared_action_rename (GObject *obj); so any object which could be renamed, had only to: - have a "name" property ; - provide an action which trigerred that function on itself. the function handled showing a nice dialog to rename the function. The idea is that of course quite a few objects will have common capabilities ; but instead of putting them all in the high level code and clutter it with functions and conditional, I want to provide the bricks which the low-level code will use to build a specific and well-fit system. Snark From ebischoff@nerim.net Thu Jun 15 14:27:54 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1F1163B04C0 for ; Thu, 15 Jun 2006 14:27:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27103-03 for ; Thu, 15 Jun 2006 14:27:51 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id E36E93B0412 for ; Thu, 15 Jun 2006 14:27:50 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 25E1340F90 for ; Thu, 15 Jun 2006 20:26:36 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Thu, 15 Jun 2006 20:26:49 +0200 User-Agent: KMail/1.8.2 References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> <44917F71.10408@free.fr> In-Reply-To: <44917F71.10408@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606152026.49639.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.533 tagged_above=-999 required=2 tests=[AWL=-0.011, BAYES_00=-2.599, SUBJECT_EXCESS_QP=0, TW_AV=0.077] X-Spam-Score: -2.533 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] =?utf-8?q?Ideas_and_considerations_for_?= =?utf-8?q?the=09addressbook_code?= X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 18:27:54 -0000 Le Jeudi 15 Juin 2006 17:40, Julien PUYDT a =C3=A9crit=C2=A0: > Saying "I get only the 10 I need" is nice, but how do you tell the > driver which they are ? There are several ways to acheive that. It could be contact numbers. Or it= =20 could be some data kept internally inside the driver. It could be a void *.= =20 Etc. > > While this sounds cool, I am not sure that this will be possible in some > > circumstances. The underlying address book (evolution, KDE address book, > > LDAP server, Zeroconf, ...) might not have the mechanisms to send such a > > signal. > > No problem : then they don't. OK. So that should not be a requirement, and certainly not a mechanism at t= he=20 core of the system. Just a nice plus. > > Why transfer 200 contacts when the view knows that it needs only 10? > > The view may show only ten at the same time on the screen, but the mouse > wheel makes it so easy to go through all of the 200, that it wouldn't be > wise to have them ready. Yes. You could have a few spare contacts before and after the user's view.= =20 This algorithm is rather common. > If there are several thousands, that's more annoying. Okay. Let's simulate your algorithm, or what I have understood of it. The user views a search selection of contacts named "Tom". His/her window=20 should contain contacts Tom Smith (#1032), Tom Jones (#2050) and Tom Doe=20 (#3172). The high level software asks the driver "get me all contacts". Aft= er=20 a relatively long time, the driver is wise and stops at contact 200. It=20 returns a list with contacts 1, 2, 3, etc, up to 200. The high level softwa= re=20 searches for Tom's in the list and finds none, since the Tom's have numbers= =20 1032, 2050 and 3172. The returned list is useless, and the window remains=20 blank. I know that it cannot be _that_ bad and that I certainly misunderstood=20 something. But what? > > The views know that contacts 301 to 309 are displayed. It's the view th= at > > knows where to cut. In fact, there's nothing to cut, since all the view > > does is ask the driver for the contects it needs. > > How do you number the contacts in a sane way? These numbers are here for the demonstration. I agree that numbers probably= =20 are not so well adapted to real address books. You could use "markers". I think that all address books use contact UIDs. A= =20 given UID could be used to mark the place where the address book stopped=20 "last time". =46or most usage you do not even need anything. Most operation is sequentia= l.=20 Take for example searching. Usually you browse all records and only keep in= =20 the result list the ones that match. > I would put the following : > 1) a title (generally the name) > 2) a description (for example a location, a status message, etc) > 3) an icon Yes, we are discussing principles. Details can be arranged later. > > The search result could handle much more detailed information. > > Of course it cannot. Your search result is a book which needs to be able > to show avahi contacts, sip contacts, call history contacts, etc... so > it can only show the contacts as generic. Why would you be unable to display detailed information about objects which= =20 you only know as generic? while (genericContact =3D nextContact()) { if (genericContact->book()->canSubscribeContacts()) proposeSubscription(genericContact); ... } > The view which is specific to an addressbook, of course can show the > data from the specific contact associated to it. But the generic view > can only show generic information. Wrong ;-). Not shown in the code sample above, but that's also the whole point of virt= ual=20 methods. > The menu is supposed to contain actions which are specific to the given > contact, book or view. Hence it must be created by code which is > specific to that contact, book or view. It cannot be done by the generic > code. ;-) > > class addressBook > > { > > virtual bool isReadOnly() =3D 0; > > virtual bool canSubscribeContacts() =3D 0; > > ... > > }; > > No, that is wrong and I already explained why. Putting everything in the > base class is bad. Do you realize that the above is not an implementation? It's just an API=20 definition. Those are pure virtual methods. Everything is implemented in th= e=20 derived subclasses. Such style of coding is very classical, good, C++ (or java). > > In your example, a signal is not needed. > > > > Knowing that there is no VoIP number in the current contact is enough. > > That is wrong. The same contact could update itself and gain it. Or > update itself and lose it. I should have added "at a given time". > Which means : > 1) *all* of the addressbooks would by default have *all* the possible > apis for such capability by default, with a isAbleToDoFoo function for > each Foo capability ; No. Defining pure virtual functions in the base class does not mean that yo= u=20 implement a function in the derived class. If it can't do something, and le= ts=20 the engine know it, then it can't ;-). > 2) if an addressbook needs a new capability, we'll have to modify the > base addressbook to add it in for it ; it won't just be a matter for the > new code to add only what is necessary for itself in its own files. Wrong again, C++ comes with programming techniques that permit to locate th= e=20 real implementations in the derived classes. > > It definitly deserves congratulations. You forgot to mention one of your > > nice ideas, that it that it should be possible to search in several > > address books at a time. > > Well, that is the main side-effect of having a base class for contacts. ;-) > I think you are focused on an addressbook as something both very big and > very static, which explains many of our divergences. I think that we are both wrong here ;-). An address book could be big (whic= h=20 you underestimated), and it could be moving (which I underestimated). > Yes, that's it. The high-level code doesn't know what an AvahiContact or > EDSContact is ; it only knows avbout GmContact. That means it cannot do > fancy things with them, and has to call functions on them to do anything > interesting. I have a view that is not so far away. The book just knows contacts. Virtua= l=20 methods and subclassing both the book and the contacts does the rest. > Your high level code is very complex, and has to be modified heavily > anytime we add a new type of addressbook with new capabilities. Yes, but much more generic. And if the same capability exists in a second address book, the code is=20 already written. > Of course, as-is that would mean a lot of code duplication. That's where > we can use a toolbox ; of which you had an example in the first round of > sample code I sent in private. Ah, you too you can see the duplication problem with your method ;-). A tool box... Sounds like a C library ;-). I think that we basically foresee the same problems, but you want to do the= m=20 in the procedural, C way, and I would like them to be done in the=20 object-oriented, C++ way. > To make it explicit for the -devel- readers, this sample code had a > function: > void shared_action_rename (GObject *obj); > so any object which could be renamed, had only to: > - have a "name" property ; > - provide an action which trigerred that function on itself. > the function handled showing a nice dialog to rename the function. Yup. You see functions where I see methods ;-). > The idea is that of course quite a few objects will have common > capabilities ; but instead of putting them all in the high level code > and clutter it with functions and conditional, Yes, that would be the logical consequence if we were in C. We are not. We= =20 have virtual methods. > I want to provide the=20 > bricks which the low-level code will use to build a specific and > well-fit system. You will end up with an engine doing about nothing, and all the work to be= =20 reimplemented again and again in the drivers. Plus painfully shared code in= =20 the "toolbox" to avoid almost identical code where it can be avoided. That'= s=20 typical procedural approach. =2D-=20 Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m=C3=A9dire." (Le concombre masqu=C3=A9, Mandriva) From jpuydt@free.fr Thu Jun 15 16:46:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 4F0A43B01FF for ; Thu, 15 Jun 2006 16:46:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32671-05 for ; Thu, 15 Jun 2006 16:46:37 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 91ADA3B00D0 for ; Thu, 15 Jun 2006 16:46:36 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp1-g19.free.fr (Postfix) with ESMTP id 743AD9A39A for ; Thu, 15 Jun 2006 22:46:01 +0200 (CEST) Message-ID: <4491C708.3060203@free.fr> Date: Thu, 15 Jun 2006 22:46:00 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> <44917F71.10408@free.fr> <200606152026.49639.ebischoff@nerim.net> In-Reply-To: <200606152026.49639.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.342 tagged_above=-999 required=2 tests=[AWL=0.180, BAYES_00=-2.599, TW_AV=0.077] X-Spam-Score: -2.342 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 20:46:39 -0000 Éric Bischoff a écrit : > Le Jeudi 15 Juin 2006 17:40, Julien PUYDT a écrit : >> Saying "I get only the 10 I need" is nice, but how do you tell the >> driver which they are ? > > There are several ways to acheive that. It could be contact numbers. Or it > could be some data kept internally inside the driver. It could be a void *. > Etc. Well, then you reduced the question: "How do I tell the driver which contacts I want?" to: "How do I tell the driver which identifiers I want?" I don't find this impressive. >>> While this sounds cool, I am not sure that this will be possible in some >>> circumstances. The underlying address book (evolution, KDE address book, >>> LDAP server, Zeroconf, ...) might not have the mechanisms to send such a >>> signal. >> No problem : then they don't. > > OK. So that should not be a requirement, and certainly not a mechanism at the > core of the system. Just a nice plus. It *must* be at the core of the system. We _do_ want to update the live data when it changes. >>> Why transfer 200 contacts when the view knows that it needs only 10? >> The view may show only ten at the same time on the screen, but the mouse >> wheel makes it so easy to go through all of the 200, that it wouldn't be >> wise to have them ready. > > Yes. You could have a few spare contacts before and after the user's view. > This algorithm is rather common. What do "before" and "after" mean ? >> If there are several thousands, that's more annoying. > > Okay. Let's simulate your algorithm, or what I have understood of it. > > The user views a search selection of contacts named "Tom". His/her window > should contain contacts Tom Smith (#1032), Tom Jones (#2050) and Tom Doe > (#3172). The high level software asks the driver "get me all contacts". After > a relatively long time, the driver is wise and stops at contact 200. It > returns a list with contacts 1, 2, 3, etc, up to 200. The high level software > searches for Tom's in the list and finds none, since the Tom's have numbers > 1032, 2050 and 3172. The returned list is useless, and the window remains > blank. > > I know that it cannot be _that_ bad and that I certainly misunderstood > something. But what? I certainly have issues with big books, and must find some satisfying way to handle them. But doing function calls to walk on a list where I could get the list and walk it myself directly, is definitely wrong. >>> The views know that contacts 301 to 309 are displayed. It's the view that >>> knows where to cut. In fact, there's nothing to cut, since all the view >>> does is ask the driver for the contects it needs. >> How do you number the contacts in a sane way? > > These numbers are here for the demonstration. I agree that numbers probably > are not so well adapted to real address books. > > You could use "markers". I think that all address books use contact UIDs. A > given UID could be used to mark the place where the address book stopped > "last time". Notice that the only place where you call the _get_contacts function is when you first populate the book. The rest of the time you don't want to know. > For most usage you do not even need anything. Most operation is sequential. > Take for example searching. Usually you browse all records and only keep in > the result list the ones that match. Most operations are sequential when the book is static. When your contacts go online/offline/whatever, that certainly is random access, and I can tell you a first/current/next approach doesn't fly in such a situation. >>> The search result could handle much more detailed information. >> Of course it cannot. Your search result is a book which needs to be able >> to show avahi contacts, sip contacts, call history contacts, etc... so >> it can only show the contacts as generic. > > Why would you be unable to display detailed information about objects which > you only know as generic? > > while (genericContact = nextContact()) > { > if (genericContact->book()->canSubscribeContacts()) > proposeSubscription(genericContact); > ... > } Yes, of course. You put everything at the high level, something which I already stressed was very very bad. Let's try an example. A text editor will just access files. It won't wonder if they are local or remote, it won't wonder about where the data really is on disk, need caching, etc. This is the job of the low-level system. The text editor doesn't have functions and tests to handle all of the various situations possible. High level is high, it doesn't take mud baths with the details, it doesn't handle them. It delegates them to the low level. >> The view which is specific to an addressbook, of course can show the >> data from the specific contact associated to it. But the generic view >> can only show generic information. > > Wrong ;-). Partially wrong. The generic view can indeed get access to some specific features (like the menus I explained). But it certainly *must* not get them by handling *all* possible situations. >>> class addressBook >>> { >>> virtual bool isReadOnly() = 0; >>> virtual bool canSubscribeContacts() = 0; >>> ... >>> }; >> No, that is wrong and I already explained why. Putting everything in the >> base class is bad. > > Do you realize that the above is not an implementation? It's just an API > definition. Those are pure virtual methods. Everything is implemented in the > derived subclasses. > > Such style of coding is very classical, good, C++ (or java). Such style of coding is not classical, is bad and evil. I see abstractions layers everywhere to hide the details of the lower level, and you want to push those details high up the stack. >>> In your example, a signal is not needed. >>> >>> Knowing that there is no VoIP number in the current contact is enough. >> That is wrong. The same contact could update itself and gain it. Or >> update itself and lose it. > > I should have added "at a given time". > >> Which means : >> 1) *all* of the addressbooks would by default have *all* the possible >> apis for such capability by default, with a isAbleToDoFoo function for >> each Foo capability ; > > No. Defining pure virtual functions in the base class does not mean that you > implement a function in the derived class. If it can't do something, and lets > the engine know it, then it can't ;-). You push all the code to the high level, and never really abstract. That is very wrong. >> 2) if an addressbook needs a new capability, we'll have to modify the >> base addressbook to add it in for it ; it won't just be a matter for the >> new code to add only what is necessary for itself in its own files. > > Wrong again, C++ comes with programming techniques that permit to locate the > real implementations in the derived classes. If I add a new addressbook type with a Foo capability, your designs says I have to modify the base class and add: bool canDoFoo (); void pleaseDoFooThisWay (...); void pleaseDoFooThisOtherWay (...); void etcFoo (...) (with all the virtual pure syntactic crap needed) My idea of right design is that if the new addressbook is the only one needing Foo, it will handle it himself (through a specific api that its view and controller will know and use). >> I think you are focused on an addressbook as something both very big and >> very static, which explains many of our divergences. > > I think that we are both wrong here ;-). An address book could be big (which > you underestimated), and it could be moving (which I underestimated). I agree I have issues seeing how to do things *properly* with a very large addressbook. >> Yes, that's it. The high-level code doesn't know what an AvahiContact or >> EDSContact is ; it only knows avbout GmContact. That means it cannot do >> fancy things with them, and has to call functions on them to do anything >> interesting. > > I have a view that is not so far away. The book just knows contacts. Virtual > methods and subclassing both the book and the contacts does the rest. > >> Your high level code is very complex, and has to be modified heavily >> anytime we add a new type of addressbook with new capabilities. > > Yes, but much more generic. It isn't much more generic. It is an awful and indigest mix of all the specific implementations. > And if the same capability exists in a second address book, the code is > already written. Not really. >> Of course, as-is that would mean a lot of code duplication. That's where >> we can use a toolbox ; of which you had an example in the first round of >> sample code I sent in private. > > Ah, you too you can see the duplication problem with your method ;-). > > A tool box... Sounds like a C library ;-). Which are very useful and allow to abstract common work at a lower layer and not take care of it ourselves way up. > I think that we basically foresee the same problems, but you want to do them > in the procedural, C way, and I would like them to be done in the > object-oriented, C++ way. Your view isn't OO, and isn't C++. >> To make it explicit for the -devel- readers, this sample code had a >> function: >> void shared_action_rename (GObject *obj); >> so any object which could be renamed, had only to: >> - have a "name" property ; >> - provide an action which trigerred that function on itself. >> the function handled showing a nice dialog to rename the function. > > Yup. You see functions where I see methods ;-). I see functions spread in maintainable files, with well-separated features and responsibility. You see functions named "methods" stuffed into the same poor base class, which has to handle everything and the rest, and where the limits between everything is blurred. Where I say function and do: gm_contact_do_foo (contact, arguments); you say method and to: contact->do_foo (arguments); which I agree is shorter, but isn't the magical solution you think it is! :-) >> The idea is that of course quite a few objects will have common >> capabilities ; but instead of putting them all in the high level code >> and clutter it with functions and conditional, > > Yes, that would be the logical consequence if we were in C. We are not. We > have virtual methods. You *do* have isReadOnly and canSubscribeContacts, which you will use to do the ifs I said where very wrong, and you will do so at the high level, which is precisely the place where details shouldn't be handled! It isn't a case of leaky abstraction, it is a case of no-abstraction! >> I want to provide the >> bricks which the low-level code will use to build a specific and >> well-fit system. > > You will end up with an engine doing about nothing, and all the work to be > reimplemented again and again in the drivers. Plus painfully shared code in > the "toolbox" to avoid almost identical code where it can be avoided. That's > typical procedural approach. I generally end up with nice layers of functions doing almost nothing, with clean api between the layer, ensuring the code will be pretty maintainable. See lib/gmconf/ for example. We have a nice api in gmconf.h, and an implementation in gmconf-glib.c, which is layered in the same file, with lowlevel functions doing some work, and higher level doing another. Not everything done at the same final level. When I wrote that code, the goal was to make gconf (the gnome configuration management system) optional, so the port to win32 would be easier. I wrote a generic api to handle things, then two implementations *hidden* behind it. Well, at least we both agree I don't handle the case of very large addressbooks very well :-/ Snark From jpuydt@free.fr Fri Jun 16 11:44:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AC28C3B0005 for ; Fri, 16 Jun 2006 11:44:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01534-04 for ; Fri, 16 Jun 2006 11:44:08 -0400 (EDT) Received: from postfix2-c.free.fr (postfix2-c.free.fr [213.228.0.80]) by menubar.gnome.org (Postfix) with ESMTP id E28BA3B0007 for ; Fri, 16 Jun 2006 11:44:07 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by postfix2-c.free.fr (Postfix) with ESMTP id E4AFC458B6CE for ; Fri, 16 Jun 2006 16:07:32 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp6-g19.free.fr (Postfix) with ESMTP id DF5BD2265E for ; Fri, 16 Jun 2006 17:02:28 +0200 (CEST) Message-ID: <4492B888.8060206@free.fr> Date: Fri, 16 Jun 2006 15:56:24 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> In-Reply-To: <4491205F.5070708@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.382 tagged_above=-999 required=2 tests=[AWL=0.217, BAYES_00=-2.599] X-Spam-Score: -2.382 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 15:44:10 -0000 Julien PUYDT a écrit : > ***** ABOUT EVOLUTION-DATA-SERVER > > The evolution-data-server api looks pretty good -- except that it seems > to mainly handle static vcard-based contacts, where I would like to be > able to handle things like. Hmmm... this sentence should have ended with "able to handle things like live contacts with presence (SIP and XMPP)". On the subject of big addressbook handling, I must say what evolution-data-server does is quite nice : they run a query (EQuery) on a book (EBook), which gives them a view of the result (EBookView). That means that they can easily do a partial view of an addressbook, since they control what is seen! While this organisation doesn't suffer from the problem Éric pointed out, it has still a problem : how does one just "search" ? I mean, if your api is "search a book => get a view", how does one make a search which encompasses all books? Snark PS: notice that the current addressbook code happily tries to get all contacts, whatever the size of the addressbook -- and even not asynchronously! From jpuydt@free.fr Sat Jun 17 03:08:50 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 27E423B03CB for ; Sat, 17 Jun 2006 03:08:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11317-07 for ; Sat, 17 Jun 2006 03:08:48 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 068E83B00DE for ; Sat, 17 Jun 2006 03:08:47 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-57-82-249-55-125.adsl.proxad.net [82.249.55.125]) by smtp1-g19.free.fr (Postfix) with ESMTP id CE8E69AA70 for ; Sat, 17 Jun 2006 09:07:34 +0200 (CEST) Message-ID: <4493AA32.5030602@free.fr> Date: Sat, 17 Jun 2006 09:07:30 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> In-Reply-To: <4492B888.8060206@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.586 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599] X-Spam-Score: -2.586 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 07:08:50 -0000 Julien PUYDT a écrit : > While this organisation doesn't suffer from the problem Éric pointed > out, it has still a problem : how does one just "search" ? I mean, if > your api is "search a book => get a view", how does one make a search > which encompasses all books? Ok, I think I'm on something : let's a book have a simple api, where on one side: 1) a book can return a view for itself, which means the view becomes specific, and hence can handle the case of big addressbooks ; 2) a full search function, which will return a new book, restricted to the the search ; again this book has its view, which will handle the case of big searches ; 3) a restricted search function, which will return say at most a hundred contacts matching the string ; this one allows to make a search on all the books, since we are assured we won't be drowned by the number. This organisation would allow a clean approach for the view on a single addressbook, while still having the possibility to have a working "Find a contact" button. Does that looks nicer ? Snark From ebischoff@nerim.net Sat Jun 17 05:24:05 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id ACD5F3B038B for ; Sat, 17 Jun 2006 05:24:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15888-07 for ; Sat, 17 Jun 2006 05:24:02 -0400 (EDT) Received: from kellthuzad.dmz.nerim.net (smtp-dmz-236-saturday.dmz.nerim.net [195.5.254.236]) by menubar.gnome.org (Postfix) with ESMTP id 2C81F3B0809 for ; Sat, 17 Jun 2006 05:24:01 -0400 (EDT) Received: from kraid.nerim.net (smtp-106-saturday.nerim.net [62.4.16.106]) by kellthuzad.dmz.nerim.net (Postfix) with ESMTP id 9BD1139D6B for ; Sat, 17 Jun 2006 11:23:14 +0200 (CEST) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 5A4A940E35 for ; Sat, 17 Jun 2006 11:22:48 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Sat, 17 Jun 2006 11:22:59 +0200 User-Agent: KMail/1.8.2 References: <4491205F.5070708@free.fr> <200606152026.49639.ebischoff@nerim.net> <4491C708.3060203@free.fr> In-Reply-To: <4491C708.3060203@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606171123.00082.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.51 tagged_above=-999 required=2 tests=[AWL=0.089, BAYES_00=-2.599] X-Spam-Score: -2.51 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 09:24:05 -0000 Le Jeudi 15 Juin 2006 22:46, Julien PUYDT a =C3=A9crit=C2=A0: > > OK. So that should not be a requirement, and certainly not a mechanism = at > > the core of the system. Just a nice plus. > > It *must* be at the core of the system. We _do_ want to update the live > data when it changes. Sorry, that was not clear. By "at the core" I meant "necessary for the addr= ess=20 books to work". > > Yes. You could have a few spare contacts before and after the user's > > view. This algorithm is rather common. > > What do "before" and "after" mean ? Records just before and after the ones that are displayed in sequential ord= er. > > I know that it cannot be _that_ bad and that I certainly misunderstood > > something. But what? > > I certainly have issues with big books, and must find some satisfying > way to handle them. But doing function calls to walk on a list where I > could get the list and walk it myself directly, is definitely wrong. What is wrong is to see that as a list ;-). > Most operations are sequential when the book is static. When your > contacts go online/offline/whatever, that certainly is random access, > and I can tell you a first/current/next approach doesn't fly in such a > situation. I would not say "not fly" but it certainly becomes much more acrobatic, I=20 agree. > If I add a new addressbook type with a Foo capability, your designs says > I have to modify the base class and add: > > bool canDoFoo (); > void pleaseDoFooThisWay (...); > void pleaseDoFooThisOtherWay (...); > void etcFoo (...) > (with all the virtual pure syntactic crap needed) This "crap" is a lightweight modification since it is only one function=20 declaration. No implementation. That is done in the subclasses, if necessar= y. > My idea of right design is that if the new addressbook is the only one > needing Foo, it will handle it himself (through a specific api that its > view and controller will know and use). Okay. Perharps the our differences in opinion is not that much on the=20 programming design, but more on what the software has to do. To me, an address book is just an address book, they are not that different= =20 one from the other. Ekiga need to dig through them to show names, categorie= s=20 and to pick up SIP numbers to call the people. I see a relatively homogeneo= us=20 user interface, with more or less the same appearance (if not exactly the=20 same) for the various address books. I have a "unifying" vision. To you, all address books have very strong pecularities and the software ha= s=20 to adapt a lot to each of them, to take them to the maximum of their=20 possibilities. The user will get different display, different menues, and=20 even different functionality. That explains why you want to put everything in the "drivers", while I want= to=20 put a lot of common logic in the "engine". > > I think that we are both wrong here ;-). An address book could be big > > (which you underestimated), and it could be moving (which I > > underestimated). > > I agree I have issues seeing how to do things *properly* with a very > large addressbook. Yes, and I have certainly underestimated the "dynamic" aspect :-(. > Your view isn't OO, and isn't C++. Come on ;-). > You see functions named "methods" stuffed into the same poor base class, No. Again and again, the base class only has declarations. It sees an=20 abstraction of what the address book is. In every C++ book, you can see examples like this class vehicle { virtual void accelerate(int a) =3D 0; ... }; class car : public vehicle { virtual void accelerate(int a); ... }; class plane : public vehicle { virtual void accelerate(int a); ... }; Planes and cars have very different ways to accelerate. Planes can't brake = and=20 cars can't fly, but such designs are clean and very popular. > Well, at least we both agree I don't handle the case of very large > addressbooks very well :-/ Yes, this discussion is not pointless :-). And at the end if you are more comfortable with libraries of C functions th= an=20 with subclassing and virtual functions, it's no problem. After all, it's yo= u=20 who are going to be doing the dirty work (and I think we all thank you for= =20 that!). =2D-=20 Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m=C3=A9dire." (Le concombre masqu=C3=A9, Mandriva) From jpuydt@free.fr Sat Jun 17 15:09:04 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2976B3B0144 for ; Sat, 17 Jun 2006 15:09:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04217-02 for ; Sat, 17 Jun 2006 15:08:59 -0400 (EDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by menubar.gnome.org (Postfix) with ESMTP id BC2893B019D for ; Sat, 17 Jun 2006 15:07:46 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-c.free.fr (Postfix) with ESMTP id 4C9DC1D0C42D for ; Sat, 17 Jun 2006 20:06:22 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-57-82-249-55-125.adsl.proxad.net [82.249.55.125]) by smtp5-g19.free.fr (Postfix) with ESMTP id B65BC26C83 for ; Sat, 17 Jun 2006 21:05:51 +0200 (CEST) Message-ID: <4494528F.2040804@free.fr> Date: Sat, 17 Jun 2006 21:05:51 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <200606152026.49639.ebischoff@nerim.net> <4491C708.3060203@free.fr> <200606171123.00082.ebischoff@nerim.net> In-Reply-To: <200606171123.00082.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.584 tagged_above=-999 required=2 tests=[AWL=0.015, BAYES_00=-2.599] X-Spam-Score: -2.584 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 19:09:04 -0000 Éric Bischoff a écrit : >>> Yes. You could have a few spare contacts before and after the user's >>> view. This algorithm is rather common. >> What do "before" and "after" mean ? > > Records just before and after the ones that are displayed in sequential order. Sequential hurts. >>> I know that it cannot be _that_ bad and that I certainly misunderstood >>> something. But what? >> I certainly have issues with big books, and must find some satisfying >> way to handle them. But doing function calls to walk on a list where I >> could get the list and walk it myself directly, is definitely wrong. > > What is wrong is to see that as a list ;-). Indeed. >> If I add a new addressbook type with a Foo capability, your designs says >> I have to modify the base class and add: >> >> bool canDoFoo (); >> void pleaseDoFooThisWay (...); >> void pleaseDoFooThisOtherWay (...); >> void etcFoo (...) >> (with all the virtual pure syntactic crap needed) > > This "crap" is a lightweight modification since it is only one function > declaration. No implementation. That is done in the subclasses, if necessary. Notice that I used "crap" to describe the syntactic need in C++ to add "virtual" and "= 0" everywhere. And your "lightweight modification" still involves modifying the base class anytime a child class needs something! >> My idea of right design is that if the new addressbook is the only one >> needing Foo, it will handle it himself (through a specific api that its >> view and controller will know and use). > > Okay. Perharps the our differences in opinion is not that much on the > programming design, but more on what the software has to do. > > To me, an address book is just an address book, they are not that different > one from the other. Ekiga need to dig through them to show names, categories > and to pick up SIP numbers to call the people. I see a relatively homogeneous > user interface, with more or less the same appearance (if not exactly the > same) for the various address books. I have a "unifying" vision. > > To you, all address books have very strong pecularities and the software has > to adapt a lot to each of them, to take them to the maximum of their > possibilities. The user will get different display, different menues, and > even different functionality. Well, look at what we have to put already in the addressbooks: - evolution-data-server addressbooks ; - avahi contacts ; - history contacts ; - speeddials. And the future holds : - SIP contacts ; - XMPP contacts. > That explains why you want to put everything in the "drivers", while I want to > put a lot of common logic in the "engine". Your high level is what I call low level : it handles all of the details! >> Your view isn't OO, and isn't C++. > > Come on ;-). > >> You see functions named "methods" stuffed into the same poor base class, > > No. Again and again, the base class only has declarations. It sees an > abstraction of what the address book is. You're still stuffing that in the base class, which is awful. Does the QWidget class have all the methods of all its child already declared? > In every C++ book, you can see examples like this > > class vehicle { > virtual void accelerate(int a) = 0; > ... > }; > > class car : public vehicle { > virtual void accelerate(int a); > ... > }; > > class plane : public vehicle { > virtual void accelerate(int a); > ... > }; > Planes and cars have very different ways to accelerate. Planes can't brake and > cars can't fly, but such designs are clean and very popular. They all accelerate, and that is the reason why having an accelerate method is put as a requirement in the base class. Anyway I since made another proposition which I find neater ; I'm eagerly waiting for your comments on it :-) Snark From siti@orcon.net.nz Sat Jun 17 16:21:14 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 166443B02D7 for ; Sat, 17 Jun 2006 16:21:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06960-02 for ; Sat, 17 Jun 2006 16:21:11 -0400 (EDT) Received: from dbmail-mx3.orcon.co.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 420E03B0769 for ; Sat, 17 Jun 2006 16:21:10 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx3.orcon.co.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k5HKBcBi027983 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 18 Jun 2006 08:11:39 +1200 From: Stephen Cook To: GnomeMeeting development mailing list Content-Type: text/plain Date: Sun, 18 Jun 2006 08:11:38 +1200 Message-Id: <1150575098.10433.5.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx3.orcon.co.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.484 tagged_above=-999 required=2 tests=[AWL=-0.020, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.484 X-Spam-Level: Subject: [GnomeMeeting-devel-list] IAX2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 20:21:14 -0000 Hello, It's been a long time I gave you guys an update. In IAX2 in opal I have got music on hold going which is nice :). I will be doing registration next as this is probably the most important feature for users. Also I have not run in to any stability problems with IAX2. My iax2/ekiga integration is working well as a tester with my asterisk server. It basically has all the functionality there but needs more integration and bug/quirky fixes. Also some refactoring in the future would be nice depending if I get time or not... From jan.schampera@web.de Sat Jun 17 23:26:05 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 973DD3B0089 for ; Sat, 17 Jun 2006 23:26:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21686-02 for ; Sat, 17 Jun 2006 23:26:04 -0400 (EDT) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by menubar.gnome.org (Postfix) with ESMTP id 718E83B0080 for ; Sat, 17 Jun 2006 23:26:04 -0400 (EDT) Received: from fwd28.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1Frm9f-0005mL-03; Sun, 18 Jun 2006 03:32:47 +0200 Received: from mail.home.thebonsai.de (Ee3Yp-Z-ge9I5Mahsz3ULnxaW3DaPSfdXF9f7jCM5sjCj+WYBVPHwg@[84.147.75.32]) by fwd28.sul.t-online.de with esmtp id 1Frm9c-1vtsA40; Sun, 18 Jun 2006 03:32:44 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id 610F16B154 for ; Sun, 18 Jun 2006 03:32:43 +0200 (CEST) Date: Sun, 18 Jun 2006 03:32:42 +0200 From: Jan Schampera To: gnomemeeting-devel-list@gnome.org Message-ID: <20060618033242.5cce3d15@localhost.localdomain> In-Reply-To: <4493AA32.5030602@free.fr> References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> <4493AA32.5030602@free.fr> Organization: private X-Mailer: Sylpheed-Claws 2.2.0 (GTK+ 2.8.18; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: Ee3Yp-Z-ge9I5Mahsz3ULnxaW3DaPSfdXF9f7jCM5sjCj+WYBVPHwg@t-dialin.net X-TOI-MSGID: d12d82d7-adb7-47a8-a0ce-a3a4ced5117e X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.982 tagged_above=-999 required=2 tests=[AWL=0.616, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.982 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 03:26:05 -0000 On Sat, 17 Jun 2006 09:07:30 +0200 Julien PUYDT wrote: > 1) a book can return a view for itself, which means the view becomes > specific, and hence can handle the case of big addressbooks ; And which view would such a book return by default? > 2) a full search function, which will return a new book, restricted > to the the search ; again this book has its view, which will handle > the case of big searches ; ACK > 3) a restricted search function, which will return say at most a > hundred contacts matching the string ; this one allows to make a > search on all the books, since we are assured we won't be drowned by > the number. > Does that looks nicer ? Yip. J. -- God is real... unless declared as integer. From jpuydt@free.fr Sun Jun 18 06:22:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8B7533B09FC for ; Sun, 18 Jun 2006 06:22:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18409-03 for ; Sun, 18 Jun 2006 06:22:08 -0400 (EDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by menubar.gnome.org (Postfix) with ESMTP id 03CAF3B0956 for ; Sun, 18 Jun 2006 06:22:07 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-c.free.fr (Postfix) with ESMTP id B13A21D0A67F for ; Sun, 18 Jun 2006 11:20:11 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-30-82-253-152-157.adsl.proxad.net [82.253.152.157]) by smtp5-g19.free.fr (Postfix) with ESMTP id 8697F270B8 for ; Sun, 18 Jun 2006 12:19:37 +0200 (CEST) Message-ID: <449528BF.3020104@free.fr> Date: Sun, 18 Jun 2006 12:19:43 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> <4493AA32.5030602@free.fr> <20060618033242.5cce3d15@localhost.localdomain> In-Reply-To: <20060618033242.5cce3d15@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 10:22:10 -0000 Jan Schampera a écrit : >> 1) a book can return a view for itself, which means the view becomes >> specific, and hence can handle the case of big addressbooks ; > And which view would such a book return by default? No default view. I think there should be a GmFullBook class (from which all books which can be displayed fully), and an associated GmFullBookView class, which would then be default for the children. >> Does that looks nicer ? > Yip. Nice. I'm writing some code to showcase things... may take long since I lack time those days :-/ Snark From dsandras@seconix.com Sun Jun 18 15:32:22 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 425673B0114 for ; Sun, 18 Jun 2006 15:32:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08600-02 for ; Sun, 18 Jun 2006 15:32:19 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 178373B0009 for ; Sun, 18 Jun 2006 15:32:18 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id EF61583C26 for ; Sun, 18 Jun 2006 21:11:21 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03870-02 for ; Sun, 18 Jun 2006 21:11:15 +0200 (CEST) Received: from [192.168.0.161] (206-158.242.81.adsl.skynet.be [81.242.158.206]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 657C683C23 for ; Sun, 18 Jun 2006 21:11:15 +0200 (CEST) From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <1150575098.10433.5.camel@siti> References: <1150575098.10433.5.camel@siti> Content-Type: text/plain; charset=ISO-8859-15 Date: Sun, 18 Jun 2006 21:31:27 +0200 Message-Id: <1150659087.2477.3.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.256 tagged_above=-999 required=2 tests=[AWL=0.208, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.256 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] IAX2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 19:32:22 -0000 Le dimanche 18 juin 2006 à 08:11 +1200, Stephen Cook a écrit : > Hello, > > It's been a long time I gave you guys an update. > > In IAX2 in opal I have got music on hold going which is nice :). I will > be doing registration next as this is probably the most important > feature for users. Also I have not run in to any stability problems > with IAX2. > > My iax2/ekiga integration is working well as a tester with my asterisk > server. It basically has all the functionality there but needs more > integration and bug/quirky fixes. Also some refactoring in the future > would be nice depending if I get time or not... Hi, I've seen Derek committed some code from you. I think it is important that you keep a repository with your patches so that we really know what you have fixed/added for Google SoC. (Actually, I should see the patches, even though it is perfectly acceptable that Derek commits them). Thank you, -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From gcgagd-gnomemeeting-devel-list@m.gmane.org Sun Jun 18 16:15:08 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8DDA23B0114 for ; Sun, 18 Jun 2006 16:15:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09248-09 for ; Sun, 18 Jun 2006 16:15:07 -0400 (EDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by menubar.gnome.org (Postfix) with ESMTP id 662BD3B00B2 for ; Sun, 18 Jun 2006 16:15:07 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Fs3eO-0006gT-LO for gnomemeeting-devel-list@gnome.org; Sun, 18 Jun 2006 22:13:40 +0200 Received: from jupiter.physics.ubc.ca ([142.103.234.78]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Jun 2006 22:13:40 +0200 Received: from johan_brn by jupiter.physics.ubc.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Jun 2006 22:13:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gnomemeeting-devel-list@gnome.org From: Johan Brannlund Date: Sun, 18 Jun 2006 13:13:29 -0700 Lines: 22 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: jupiter.physics.ubc.ca User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux)) Sender: news X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.752 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_YAHOO_RCVD=1.849, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.752 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Main window size X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 20:15:08 -0000 I posted the below as a wishlist bug, but apparently the developers prefer carrying out the discussion on this mailing list. This is what I wrote: "I just tried the 20060615 cvs snapshot of ekiga, and it's getting better all the time. I have a small request though: I don't use video, which means that the main window is much bigger than it has to be. Would it be possible to add a resizing widget, or to automatically make the window smaller when video is disabled?" Damien also added the following comment: "I would also say that it will look less bigger when having a contacts list. :) " ... which I don't quite understand. At least in my snapshot, the contacts are in a separate window. Regards, Johan From siti@orcon.net.nz Sun Jun 18 21:23:06 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 415B73B0387 for ; Sun, 18 Jun 2006 21:23:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18559-06 for ; Sun, 18 Jun 2006 21:23:01 -0400 (EDT) Received: from dbmail-mx2.orcon.net.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 66E1B3B0196 for ; Sun, 18 Jun 2006 21:23:01 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx2.orcon.net.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k5J1Lujn017301 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 19 Jun 2006 13:21:57 +1200 From: Stephen Cook To: GnomeMeeting development mailing list In-Reply-To: <1150659087.2477.3.camel@golgoth01> References: <1150575098.10433.5.camel@siti> <1150659087.2477.3.camel@golgoth01> Content-Type: text/plain; charset=utf-8 Date: Mon, 19 Jun 2006 13:21:55 +1200 Message-Id: <1150680115.31741.1.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx2.orcon.net.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.547 tagged_above=-999 required=2 tests=[AWL=0.052, BAYES_00=-2.599] X-Spam-Score: -2.547 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] IAX2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 01:23:06 -0000 On Sun, 2006-06-18 at 21:31 +0200, Damien Sandras wrote: > Le dimanche 18 juin 2006 à 08:11 +1200, Stephen Cook a écrit : > > Hello, > > > > It's been a long time I gave you guys an update. > > > > In IAX2 in opal I have got music on hold going which is nice :). I will > > be doing registration next as this is probably the most important > > feature for users. Also I have not run in to any stability problems > > with IAX2. > > > > My iax2/ekiga integration is working well as a tester with my asterisk > > server. It basically has all the functionality there but needs more > > integration and bug/quirky fixes. Also some refactoring in the future > > would be nice depending if I get time or not... > > Hi, > > > I've seen Derek committed some code from you. > > I think it is important that you keep a repository with your patches so > that we really know what you have fixed/added for Google SoC. > (Actually, I should see the patches, even though it is perfectly > acceptable that Derek commits them). I'll try and get you to review them first. I'll also put the patches on my website and give you guys a link soon. > > Thank you, From jpuydt@free.fr Mon Jun 19 01:26:43 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E9CF83B09E1 for ; Mon, 19 Jun 2006 01:26:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25898-10 for ; Mon, 19 Jun 2006 01:26:41 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 737143B03C7 for ; Mon, 19 Jun 2006 01:26:41 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-60-82-254-197-114.adsl.proxad.net [82.254.197.114]) by smtp1-g19.free.fr (Postfix) with ESMTP id C5B1D10170 for ; Mon, 19 Jun 2006 07:25:07 +0200 (CEST) Message-ID: <44963539.6080309@free.fr> Date: Mon, 19 Jun 2006 07:25:13 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.567 tagged_above=-999 required=2 tests=[AWL=0.032, BAYES_00=-2.599] X-Spam-Score: -2.567 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Main window size X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 05:26:43 -0000 Johan Brannlund a écrit : > I posted the below as a wishlist bug, but apparently the developers prefer > carrying out the discussion on this mailing list. This is what I wrote: Well, bug reports are nice for a beta or a stable release ; during the development cycle, discussing on the -devel- mailing-list is better (especially right at the beginning). :-) > "I just tried the 20060615 cvs snapshot of ekiga, and it's getting better > all the time. I have a small request though: I don't use video, which > means that the main window is much bigger than it has to be. > > Would it be possible to add a resizing widget, or to automatically make the > window smaller when video is disabled?" > > Damien also added the following comment: > > "I would also say that it will look less bigger when having a contacts > list. :) " > > ... which I don't quite understand. At least in my snapshot, the contacts > are in a separate window. He means that you should see some of your contacts in the main window in the future, with presence information about them. Snark From dsandras@seconix.com Mon Jun 19 04:55:21 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 539283B00A5 for ; Mon, 19 Jun 2006 04:55:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01183-02 for ; Mon, 19 Jun 2006 04:55:13 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id CCC843B0004 for ; Mon, 19 Jun 2006 04:55:11 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id D5FC083C1F for ; Mon, 19 Jun 2006 10:34:14 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32316-06 for ; Mon, 19 Jun 2006 10:34:11 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 694B183C1A for ; Mon, 19 Jun 2006 10:34:11 +0200 (CEST) From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44963539.6080309@free.fr> References: <44963539.6080309@free.fr> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 19 Jun 2006 10:54:04 +0200 Message-Id: <1150707244.2904.2.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Main window size X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 08:55:21 -0000 Le lundi 19 juin 2006 à 07:25 +0200, Julien PUYDT a écrit : > Johan Brannlund a écrit : > > I posted the below as a wishlist bug, but apparently the developers prefer > > carrying out the discussion on this mailing list. This is what I wrote: > > Well, bug reports are nice for a beta or a stable release ; during the > development cycle, discussing on the -devel- mailing-list is better > (especially right at the beginning). :-) > Yes, because it is a work in progress. So it will change with time, and get improved. No worries :) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From firstone5@hotmail.com Wed Jun 21 13:09:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C9A9D3B02A4 for ; Wed, 21 Jun 2006 13:09:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23702-03 for ; Wed, 21 Jun 2006 13:09:09 -0400 (EDT) Received: from hotmail.com (bay101-f15.bay101.hotmail.com [64.4.56.25]) by menubar.gnome.org (Postfix) with ESMTP id C2B763B01C1 for ; Wed, 21 Jun 2006 13:09:09 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Jun 2006 10:09:08 -0700 Message-ID: Received: from 64.4.56.200 by by101fd.bay101.hotmail.msn.com with HTTP; Wed, 21 Jun 2006 17:09:07 GMT X-Originating-IP: [69.245.3.192] X-Originating-Email: [firstone5@hotmail.com] X-Sender: firstone5@hotmail.com From: "M. Renee Hopkins" To: gnomemeeting-devel-list@gnome.org Date: Wed, 21 Jun 2006 17:09:07 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 21 Jun 2006 17:09:08.0863 (UTC) FILETIME=[68BD40F0:01C69555] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=0.607 tagged_above=-999 required=2 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: 0.607 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Mingw build of CVS ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:09:11 -0000 Greetings all, I am now building ekiga from cvs with the mingw tools on linux with some success, thanks to help from the list developers and patches. Most all features seem to be working. However, my builds don't detect the videoforwindows devices even though other ekiga.exe (not mine) versions correctly see the camera. Any ideas for missing switches on compile before I began greping through pwlib? I'm rather new to the code so any help is appreciated. Congrads to all developers on great work, MR From dsandras@seconix.com Wed Jun 21 13:42:37 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C742A3B05E9 for ; Wed, 21 Jun 2006 13:42:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25791-05 for ; Wed, 21 Jun 2006 13:42:36 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 0647C3B00B0 for ; Wed, 21 Jun 2006 13:42:35 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id AC0EF83C1C for ; Wed, 21 Jun 2006 19:22:12 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05950-02 for ; Wed, 21 Jun 2006 19:22:11 +0200 (CEST) Received: from [192.168.0.161] (185.1-247-81.adsl-dyn.isp.belgacom.be [81.247.1.185]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id C5DD783C1B for ; Wed, 21 Jun 2006 19:22:10 +0200 (CEST) From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-15 Date: Wed, 21 Jun 2006 19:43:29 +0200 Message-Id: <1150911809.2537.7.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.461 tagged_above=-999 required=2 tests=[AWL=0.003, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.461 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Mingw build of CVS ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:42:38 -0000 Le mercredi 21 juin 2006 à 17:09 +0000, M. Renee Hopkins a écrit : > Greetings all, > > I am now building ekiga from cvs with the mingw tools on linux with some > success, thanks to help from the list developers and patches. > > Most all features seem to be working. However, my builds don't detect the > videoforwindows devices even though other ekiga.exe (not mine) versions > correctly see the camera. > > Any ideas for missing switches on compile before I began greping through > pwlib? > I'm not an expert of the win32 build, but the first guess would be that the pwlib plugins are not compiled in. > I'm rather new to the code so any help is appreciated. > > Congrads to all developers on great work, > MR > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From tonim@telefonica.net Wed Jun 28 04:13:24 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9083D3B0079 for ; Wed, 28 Jun 2006 04:13:24 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31830-06 for ; Wed, 28 Jun 2006 04:13:23 -0400 (EDT) Received: from lothlorienng.sisman.info (157.Red-83-58-24.dynamicIP.rima-tde.net [83.58.24.157]) by menubar.gnome.org (Postfix) with ESMTP id C1F293B0002 for ; Wed, 28 Jun 2006 04:13:22 -0400 (EDT) Received: from gandalf.sisman.info (gandalf.sisman.info [192.168.16.201]) by lothlorienng.sisman.info (Postfix) with ESMTP id B33D71D8437 for ; Wed, 28 Jun 2006 08:18:54 +0200 (CEST) From: Toni Moreno To: gnomemeeting-devel-list@gnome.org In-Reply-To: <1150680115.31741.1.camel@siti> References: <1150575098.10433.5.camel@siti> <1150659087.2477.3.camel@golgoth01> <1150680115.31741.1.camel@siti> Content-Type: text/plain Date: Wed, 28 Jun 2006 08:09:46 +0200 Message-Id: <1151474986.5988.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: Yes, score=2.597 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046, SPF_NEUTRAL=1.069] X-Spam-Score: 2.597 X-Spam-Level: ** X-Spam-Flag: YES Subject: [GnomeMeeting-devel-list] A bit OFF-TOPIC, but usefull X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 08:13:24 -0000 I have found a report of skype, which shows the huge network activity it has (apart from voice network usage). Interesting to pinpoint differences between Skype & Ekiga, or other VoIP hardware phones. Enjoy, and excuse me the off-topic. http://www.ja.net/development/voip/skype&janet.pdf -- Toni Moreno From lurch@gmx.li Thu Jun 29 03:50:09 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A67023B011E for ; Thu, 29 Jun 2006 03:50:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26540-04 for ; Thu, 29 Jun 2006 03:50:02 -0400 (EDT) Received: from asclepius.uwa.edu.au (unknown [130.95.128.56]) by menubar.gnome.org (Postfix) with ESMTP id 6733A3B04C2 for ; Thu, 29 Jun 2006 03:50:01 -0400 (EDT) Received: from asclepius.kas (localhost.localdomain [127.0.0.1]) by asclepius.uwa.edu.au (Postfix) with SMTP id E6028183A6F for ; Thu, 29 Jun 2006 15:49:45 +0800 (WST) Received: from asclepius (localhost.localdomain [127.0.0.1]) by asclepius.prekas (Postfix) with SMTP id CC7321841AD for ; Thu, 29 Jun 2006 15:49:45 +0800 (WST) X-UWA-Client-IP: 130.95.28.15 (UWA) Received: from ns1.watri.uwa.edu.au (ns1.watri.org.au [130.95.28.15]) by asclepius.extinput (Postfix) with ESMTP id B3012183CC9 for ; Thu, 29 Jun 2006 15:49:45 +0800 (WST) Received: from [130.95.29.76] (gluttony.watri.org.au [130.95.29.76]) by ns1.watri.uwa.edu.au (8.13.1/8.13.1) with ESMTP id k5T7nflM013861 for ; Thu, 29 Jun 2006 15:49:44 +0800 (WST) Message-ID: <44A386D4.8040708@gmx.li> Date: Thu, 29 Jun 2006 15:52:52 +0800 From: =?ISO-8859-1?Q?Stefan_Br=FCns?= User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <200606081002.37875.conrad_videokonferenz@gmx.de> <1150380224.6599.22.camel@ganymede.verfaction.de> In-Reply-To: <1150380224.6599.22.camel@ganymede.verfaction.de> Content-Type: multipart/mixed; boundary="------------030008030501050603080306" X-SpamTest-Info: Profile: Formal (405/060628) X-SpamTest-Info: Profile: Detect Hard [UCS 290904] X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking Spam - Subject (UCS) [02-08-04] X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.358 tagged_above=-999 required=2 tests=[AWL=-0.036, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142] X-Spam-Score: -1.358 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 07:50:09 -0000 This is a multi-part message in MIME format. --------------030008030501050603080306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> The last version I can install using apt-get a couple of days old (May 25 - or >> somethin) - at least this is a version with the nonfunctional German locale. >> (defaults to English) >> >> What's up? > > > /me is having a sheer lack of time and thus it took me a while to get > everything polished and fixed just like i love to have it. =) > Everything should be back to normal as of tonight (eventually sarge cvs > snaps and win32 will remain for the weekend - we'll see) I think I have found the problem with the missing tranlations - it is caused by the recent change from the ALL_LINGUAS variable to the po/LINGUAS file. Patch attached. @Kilian: can you try the patch and submit it upstream, if successfull? Lurchi --------------030008030501050603080306 Content-Type: text/plain; name="configure_in_fix_all_linguas.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="configure_in_fix_all_linguas.diff" --- configure.in_orig 2006-06-29 07:59:40.000000000 +0200 +++ configure.in 2006-06-29 09:10:08.000000000 +0200 @@ -527,7 +527,8 @@ dnl Support for internationalization dnl ######################################################################## AC_SUBST([CONFIG_STATUS_DEPENDENCIES],['$(top_srcdir)/po/LINGUAS']) -ALL_LINGUAS="`grep -v '^#' "$srcdir/po/LINGUAS"`" +# ALL_LINGUAS="`grep -v '^#' "$srcdir/po/LINGUAS"`" +ALL_LINGUAS="`sed -ne '/\#.*/ d; H; $ {x; s/^\\n//g; s/\\n/ /g; p}' "$srcdir/po/LINGUAS"`" GETTEXT_PACKAGE=AC_PACKAGE_NAME AC_SUBST(GETTEXT_PACKAGE) --------------030008030501050603080306-- From jpuydt@free.fr Thu Jun 29 06:15:38 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0617C3B050F for ; Thu, 29 Jun 2006 06:15:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03057-05 for ; Thu, 29 Jun 2006 06:15:36 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 17C0C3B02CE for ; Thu, 29 Jun 2006 06:15:36 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-61-82-250-109-134.adsl.proxad.net [82.250.109.134]) by smtp5-g19.free.fr (Postfix) with ESMTP id 08B3E27766 for ; Thu, 29 Jun 2006 12:15:34 +0200 (CEST) Message-ID: <44A3A865.7000201@free.fr> Date: Thu, 29 Jun 2006 12:16:05 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <200606081002.37875.conrad_videokonferenz@gmx.de> <1150380224.6599.22.camel@ganymede.verfaction.de> <44A386D4.8040708@gmx.li> In-Reply-To: <44A386D4.8040708@gmx.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.596 tagged_above=-999 required=2 tests=[AWL=0.003, BAYES_00=-2.599] X-Spam-Score: -2.596 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 10:15:38 -0000 Stefan Brüns a écrit : > @Kilian: can you try the patch and submit it upstream, if successfull? You can call me "Snark", you know ;-) Snark From jpuydt@free.fr Thu Jun 29 06:20:46 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5F2F33B0286 for ; Thu, 29 Jun 2006 06:20:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03470-04 for ; Thu, 29 Jun 2006 06:20:45 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 5A2F43B01CE for ; Thu, 29 Jun 2006 06:20:45 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-61-82-250-109-134.adsl.proxad.net [82.250.109.134]) by smtp5-g19.free.fr (Postfix) with ESMTP id 4DBBF2765B for ; Thu, 29 Jun 2006 12:20:44 +0200 (CEST) Message-ID: <44A3A99B.8030605@free.fr> Date: Thu, 29 Jun 2006 12:21:15 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <200606081002.37875.conrad_videokonferenz@gmx.de> <1150380224.6599.22.camel@ganymede.verfaction.de> <44A386D4.8040708@gmx.li> <44A3A865.7000201@free.fr> In-Reply-To: <44A3A865.7000201@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.596 tagged_above=-999 required=2 tests=[AWL=0.003, BAYES_00=-2.599] X-Spam-Score: -2.596 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 10:20:46 -0000 Julien PUYDT a écrit : > Stefan Brüns a écrit : >> @Kilian: can you try the patch and submit it upstream, if successfull? > > You can call me "Snark", you know ;-) Hmmmm... which "upstream" are we talking about ? :-) /me should read before answering ;-) Snark From dsandras@seconix.com Thu Jun 1 02:40:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F28C93B00EB for ; Thu, 1 Jun 2006 02:40:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10407-03 for ; Thu, 1 Jun 2006 02:40:07 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 9FA173B00CB for ; Thu, 1 Jun 2006 02:40:06 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id DE1A2496FC for ; Thu, 1 Jun 2006 08:23:55 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15636-08 for ; Thu, 1 Jun 2006 08:23:54 +0200 (CEST) Received: from [172.16.100.156] (tcts.fpms.ac.be [193.190.194.194]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 0CBC0496FB for ; Thu, 1 Jun 2006 08:23:54 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <447DF183.3090300@cs.stanford.edu> References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-15 Date: Thu, 01 Jun 2006 08:41:01 +0200 Message-Id: <1149144061.2457.4.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 06:40:10 -0000 Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > I'd imagine it would work on win32, but don't know. > Probably. > I'll work on the patches. > > Where's the right place to add required libraries like openGL? In configure.in. > configure.in seems to be autogenerated by something, but whatever it is > doesn't seem to be in the CVS snapshot... > configure.in is in the CVS snapshot. > Thanks, > > -Dan > > Julien PUYDT wrote: > > > Dan Sandberg a écrit : > > > >> How should we proceed? I could just send you an updated gui/main.cpp > >> file... > > > > > > I'd like to see patches instead of full files, preferably independant > > on each others. > > > > There's also the question of the portability of this : since you > > mention SDL, I guess this will work great on win32 too ? > > > > Snark > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From hoglet@solit.se Thu Jun 1 09:09:47 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 90B2B3B017F for ; Thu, 1 Jun 2006 09:09:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04710-03 for ; Thu, 1 Jun 2006 09:09:45 -0400 (EDT) Received: from aurian.solit.se (unknown [82.182.216.174]) by menubar.gnome.org (Postfix) with ESMTP id 63B703B0134 for ; Thu, 1 Jun 2006 09:09:45 -0400 (EDT) Received: from ip76.kassjo.se ([85.11.28.76] helo=localhost.localdomain) by aurian.solit.se with asmtp (Exim 3.35 #1 (Debian)) id 1Flmvj-0004Et-00 for ; Thu, 01 Jun 2006 15:09:39 +0200 Date: Thu, 1 Jun 2006 15:09:38 +0200 From: Kent Asplund To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Re: Ekiga branched Message-Id: <20060601150938.fcdea791.hoglet@solit.se> In-Reply-To: <1148209984.2488.26.camel@golgoth01> References: <1147894199.7225.2.camel@golgoth01> <1148207277.6654.0.camel@frobisher.madeley.id.au> <1148209984.2488.26.camel@golgoth01> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: ej spam, SpamAssassin (resultat=-4.4, krav 5, IN_REP_TO -4.43) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.832 tagged_above=-999 required=2 tests=[AWL=-0.510, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142] X-Spam-Score: -1.832 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:09:47 -0000 --Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 21 May 2006 13:13:04 +0200 Damien Sandras wrote: > Le dimanche 21 mai 2006 =E0 18:27 +0800, Davyd Madeley a =E9crit : > > On Wed, 2006-05-17 at 21:29 +0200, Damien Sandras wrote: > >=20 > > > I have created a new branch named "gnome-2-14" for Ekiga from the > > > current CVS HEAD. > >=20 > > What are your exciting plans for the next Ekiga? > >=20 >=20 > Most of the plans are on http://wiki.ekiga.org, but I would summarize it > by those big features : > - New user interface I have some problems selling Ekiga to my wife an mother-in-law because it lacks the list of contacts you are about to implement. Another detail is the "contact" button that they did not see as intuitive. Exchanging the button to a green phone handle (red when calling in progress) would make it more alike others and therefore easier to accept. Greetings /Kent --=20 Killing time murders opportunities. --Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEfucS4WZLcIH5l3kRAm+MAJ95cAJ7mAiuBBLrCdfk7vNFTiLv7ACeKWZd 6tzVdWbow84O8RfCFvm51AU= =lD5w -----END PGP SIGNATURE----- --Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ-- From jpuydt@free.fr Thu Jun 1 09:20:42 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 792AE3B01C4 for ; Thu, 1 Jun 2006 09:20:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05042-09 for ; Thu, 1 Jun 2006 09:20:38 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 505C93B01E3 for ; Thu, 1 Jun 2006 09:20:37 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-30-82-253-132-170.adsl.proxad.net [82.253.132.170]) by smtp1-g19.free.fr (Postfix) with ESMTP id DA3499ADFF for ; Thu, 1 Jun 2006 15:20:35 +0200 (CEST) Message-ID: <447EE9BE.5030005@free.fr> Date: Thu, 01 Jun 2006 15:21:02 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Re: Ekiga branched References: <1147894199.7225.2.camel@golgoth01> <1148207277.6654.0.camel@frobisher.madeley.id.au> <1148209984.2488.26.camel@golgoth01> <20060601150938.fcdea791.hoglet@solit.se> In-Reply-To: <20060601150938.fcdea791.hoglet@solit.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599] X-Spam-Score: -2.561 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:20:42 -0000 Kent Asplund a écrit : > Exchanging the button to a green phone handle (red when calling in > progress) would make it more alike others and therefore easier to > accept. The classic case of "your flying car lacks a spare wheel!" ;-) Snark From jan.schampera@web.de Thu Jun 1 12:03:48 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B922E3B0E4B for ; Thu, 1 Jun 2006 12:03:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18635-04 for ; Thu, 1 Jun 2006 12:03:47 -0400 (EDT) Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by menubar.gnome.org (Postfix) with ESMTP id EBE813B0E61 for ; Thu, 1 Jun 2006 12:01:39 -0400 (EDT) Received: from fwd29.aul.t-online.de by mailout05.sul.t-online.com with smtp id 1FlpcA-0003xH-07; Thu, 01 Jun 2006 18:01:38 +0200 Received: from mail.home.thebonsai.de (VypBOcZSYex2PaURfsq4FLxwkOKh2FKpRdjn4Nur7iMG3ImbsTH1w4@[84.147.102.147]) by fwd29.sul.t-online.de with esmtp id 1FlpO1-0yxMBM0; Thu, 1 Jun 2006 17:47:01 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id E08C06B173 for ; Thu, 1 Jun 2006 17:47:00 +0200 (CEST) Date: Thu, 1 Jun 2006 17:44:27 +0200 From: Jan Schampera To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode Message-ID: <20060601174427.48266dee@localhost.localdomain> In-Reply-To: <447DE4E2.7040204@cs.stanford.edu> References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> Organization: private X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: VypBOcZSYex2PaURfsq4FLxwkOKh2FKpRdjn4Nur7iMG3ImbsTH1w4@t-dialin.net X-TOI-MSGID: e6494e3b-869b-447f-a832-f769a200d3af X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.942 tagged_above=-999 required=2 tests=[AWL=0.656, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.942 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:03:48 -0000 On Wed, 31 May 2006 11:48:02 -0700 Dan Sandberg wrote: > 2) Replace the SDL/GTK/GDK calls that do the full screen resizing with > OpenGL ones. [ This is done, needs to be integrated ] Guess that's the key I searched for, when I measured those performance problems. Something that is "usually" installed on the user's machines and that has more power then GDK/SDL (I was afraid to raise yet another exotic dependancy, but OpenGL seems fair enough). J. -- "Be liberal in what you accept, and conservative in what you send." - J. B. Postel, master of the net. From siti@orcon.net.nz Fri Jun 2 05:53:55 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5C8803B10AE for ; Fri, 2 Jun 2006 05:53:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15897-03 for ; Fri, 2 Jun 2006 05:53:53 -0400 (EDT) Received: from dbmail-mx4.orcon.co.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 1A8E13B0EB6 for ; Fri, 2 Jun 2006 05:53:52 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx4.orcon.co.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k529rnLs032645 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 2 Jun 2006 21:53:50 +1200 From: Stephen Cook To: GnomeMeeting development mailing list Content-Type: text/plain Date: Fri, 02 Jun 2006 21:55:24 +1200 Message-Id: <1149242124.4509.17.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.2/1506/Fri Jun 2 16:01:20 2006 on dbmail-mx4.orcon.co.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: Subject: [GnomeMeeting-devel-list] IAX2 In Ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 09:53:55 -0000 Hi, I haven't introduced myself here before, I am Stephen Cook (siti). My proposal for implementing IAX2 in ekiga got accepted with google's summer of code. To give an update (I'll try and keep you guys regularly posted as to what's happening, any problems etc.). Currently I have been looking at the code to gain an understanding of ekiga and opal's code and design. Also obviously checking out the IAX2 code in opal :). From what I have seen and got working, I will work on getting IAX2 going in ekiga first. The main part of this will obviously involve writing a gnome meeting endpoint for IAX2. One key problem I have identified is the accounts code. The protocols are tightly integrated with how it works. I could either refactor this code to loosen the integration or hack iax2 support in there and refactor it later ;). The advantage of this refactored will be when someone wants to add Xmpp/libjingle support, or some other protocol down the track. Well, please tell me your thoughts and comments on this project. -Stephen From x@cs.stanford.edu Fri Jun 2 06:04:24 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0CBE83B0EB6 for ; Fri, 2 Jun 2006 06:04:24 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16680-02 for ; Fri, 2 Jun 2006 06:04:22 -0400 (EDT) Received: from smtp102.plus.mail.mud.yahoo.com (smtp102.plus.mail.mud.yahoo.com [68.142.206.235]) by menubar.gnome.org (Postfix) with SMTP id 1A3583B0490 for ; Fri, 2 Jun 2006 06:04:22 -0400 (EDT) Received: (qmail 57482 invoked from network); 2 Jun 2006 10:04:21 -0000 Received: from unknown (HELO ?192.168.2.47?) (dan?sandberg@71.138.128.214 with plain) by smtp102.plus.mail.mud.yahoo.com with SMTP; 2 Jun 2006 10:04:20 -0000 Message-ID: <44800CFA.5090800@cs.stanford.edu> Date: Fri, 02 Jun 2006 03:03:38 -0700 From: Dan Sandberg User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> In-Reply-To: <1149144061.2457.4.camel@golgoth01> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.808 tagged_above=-999 required=2 tests=[AWL=-0.593, BAYES_00=-2.599, SPF_SOFTFAIL=1.384] X-Spam-Score: -1.808 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 10:04:24 -0000 So configure.in is hand-generated? Surprising. 1) How exactly do I add the opengl ( libgl ) library? 2) Xrandr is mentioned in the Makefile, but is not in configure.in. How exactly does it get put into the Makefile? 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I didn't want to code against a moving target. Thanks, -Dan Damien Sandras wrote: >Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > > >>I'd imagine it would work on win32, but don't know. >> >> >> > >Probably. > > > >>I'll work on the patches. >> >>Where's the right place to add required libraries like openGL? >> >> > >In configure.in. > > > >>configure.in seems to be autogenerated by something, but whatever it is >>doesn't seem to be in the CVS snapshot... >> >> >> > >configure.in is in the CVS snapshot. > > > > >>Thanks, >> >>-Dan >> >>Julien PUYDT wrote: >> >> >> >>>Dan Sandberg a écrit : >>> >>> >>> >>>>How should we proceed? I could just send you an updated gui/main.cpp >>>>file... >>>> >>>> >>>I'd like to see patches instead of full files, preferably independant >>>on each others. >>> >>>There's also the question of the portability of this : since you >>>mention SDL, I guess this will work great on win32 too ? >>> >>>Snark >>>_______________________________________________ >>>Gnomemeeting-devel-list mailing list >>>Gnomemeeting-devel-list@gnome.org >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list >>> >>> >>> >>_______________________________________________ >>Gnomemeeting-devel-list mailing list >>Gnomemeeting-devel-list@gnome.org >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list >> >> From dsandras@seconix.com Fri Jun 2 07:06:22 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9B2253B0407 for ; Fri, 2 Jun 2006 07:06:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20694-02 for ; Fri, 2 Jun 2006 07:06:20 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 830933B0490 for ; Fri, 2 Jun 2006 07:06:20 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 3567C4974A for ; Fri, 2 Jun 2006 12:49:55 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03852-06 for ; Fri, 2 Jun 2006 12:49:51 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 5D9BD49749 for ; Fri, 2 Jun 2006 12:49:51 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <1149242124.4509.17.camel@siti> References: <1149242124.4509.17.camel@siti> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 02 Jun 2006 13:06:14 +0200 Message-Id: <1149246374.2966.25.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:06:22 -0000 Le vendredi 02 juin 2006 à 21:55 +1200, Stephen Cook a écrit : > Hi, > > I haven't introduced myself here before, I am Stephen Cook (siti). My > proposal for implementing IAX2 in ekiga got accepted with google's > summer of code. > > To give an update (I'll try and keep you guys regularly posted as to > what's happening, any problems etc.). > > Currently I have been looking at the code to gain an understanding of > ekiga and opal's code and design. Also obviously checking out the IAX2 > code in opal :). From what I have seen and got working, I will work on > getting IAX2 going in ekiga first. The main part of this will obviously > involve writing a gnome meeting endpoint for IAX2. > I would say that the main part will be to write / finish the IAX2 code in OPAL, either new code, or reusing the current code so that all features that you see in SIP and H.323 are also available for IAX2. Your first project will be to look the limitations of the current code and write a document showing what features you have tested, what work is required to complete them, and what new work is required for new features (Call Hold, Call Transfer, Registering, Call Forward, ...). Writing the endpoint in Ekiga is the last part of the project once the code in OPAL is full functional. Ekiga only contains high-level code. > One key problem I have identified is the accounts code. The protocols > are tightly integrated with how it works. I could either refactor this > code to loosen the integration or hack iax2 support in there and > refactor it later ;). The advantage of this refactored will be when > someone wants to add Xmpp/libjingle support, or some other protocol down > the track. > I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and finally perhaps to a refactoring of the accounts code as it is not the primary purpose of the Google SoC :) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Fri Jun 2 07:08:01 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 243E83B0407 for ; Fri, 2 Jun 2006 07:08:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20781-05 for ; Fri, 2 Jun 2006 07:07:58 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 6C7333B10B6 for ; Fri, 2 Jun 2006 07:07:58 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 5426B49753 for ; Fri, 2 Jun 2006 12:51:33 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06419-06 for ; Fri, 2 Jun 2006 12:51:18 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id EF0D549750 for ; Fri, 2 Jun 2006 12:51:17 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44800CFA.5090800@cs.stanford.edu> References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 02 Jun 2006 13:07:41 +0200 Message-Id: <1149246461.2966.28.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:08:01 -0000 Le vendredi 02 juin 2006 à 03:03 -0700, Dan Sandberg a écrit : > So configure.in is hand-generated? Surprising. > That's te way it works. You write configure.in and configure is generated from there. I guess you are confusing things here. > 1) How exactly do I add the opengl ( libgl ) library? > By writing autconf code in configure.in. No idea exactly how it should be done. > 2) Xrandr is mentioned in the Makefile, but is not in configure.in. How > exactly does it get put into the Makefile? > Probably by an external library that we are using. > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I didn't want > to code against a moving target. > Yes. It is even OK if you do not provide the configure.in code, but only the OpenGL Ekiga code. > Thanks, > > -Dan > > Damien Sandras wrote: > > >Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > > > > > >>I'd imagine it would work on win32, but don't know. > >> > >> > >> > > > >Probably. > > > > > > > >>I'll work on the patches. > >> > >>Where's the right place to add required libraries like openGL? > >> > >> > > > >In configure.in. > > > > > > > >>configure.in seems to be autogenerated by something, but whatever it is > >>doesn't seem to be in the CVS snapshot... > >> > >> > >> > > > >configure.in is in the CVS snapshot. > > > > > > > > > >>Thanks, > >> > >>-Dan > >> > >>Julien PUYDT wrote: > >> > >> > >> > >>>Dan Sandberg a écrit : > >>> > >>> > >>> > >>>>How should we proceed? I could just send you an updated gui/main.cpp > >>>>file... > >>>> > >>>> > >>>I'd like to see patches instead of full files, preferably independant > >>>on each others. > >>> > >>>There's also the question of the portability of this : since you > >>>mention SDL, I guess this will work great on win32 too ? > >>> > >>>Snark > >>>_______________________________________________ > >>>Gnomemeeting-devel-list mailing list > >>>Gnomemeeting-devel-list@gnome.org > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > >>> > >>> > >>> > >>_______________________________________________ > >>Gnomemeeting-devel-list mailing list > >>Gnomemeeting-devel-list@gnome.org > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > >> > >> > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From jpuydt@free.fr Fri Jun 2 09:55:37 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 35E163B0A0B for ; Fri, 2 Jun 2006 09:55:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30481-03 for ; Fri, 2 Jun 2006 09:55:35 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id DF18F3B0468 for ; Fri, 2 Jun 2006 09:55:34 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-30-82-253-132-170.adsl.proxad.net [82.253.132.170]) by smtp6-g19.free.fr (Postfix) with ESMTP id D0F23225C9 for ; Fri, 2 Jun 2006 15:55:31 +0200 (CEST) Message-ID: <44804375.6090107@free.fr> Date: Fri, 02 Jun 2006 15:56:05 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga References: <1149242124.4509.17.camel@siti> <1149246374.2966.25.camel@golgoth01> In-Reply-To: <1149246374.2966.25.camel@golgoth01> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599] X-Spam-Score: -2.561 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 13:55:37 -0000 Damien Sandras a écrit : > I would say that the main part will be to write / finish the IAX2 code > in OPAL, either new code, or reusing the current code so that all > features that you see in SIP and H.323 are also available for IAX2. > > Your first project will be to look the limitations of the current code > and write a document showing what features you have tested, what work is > required to complete them, and what new work is required for new > features (Call Hold, Call Transfer, Registering, Call Forward, ...). > > Writing the endpoint in Ekiga is the last part of the project once the > code in OPAL is full functional. Ekiga only contains high-level code. I don't fully agree with you: writing low-level code all summer long then finally writing the upper-level code, will lead to a non-working feature :-/ Having a least minimal functionality in ekiga would be nice to test the low-level regularly, and see it improving. >> One key problem I have identified is the accounts code. The protocols >> are tightly integrated with how it works. I could either refactor this >> code to loosen the integration or hack iax2 support in there and >> refactor it later ;). The advantage of this refactored will be when >> someone wants to add Xmpp/libjingle support, or some other protocol down >> the track. > > I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and > finally perhaps to a refactoring of the accounts code as it is not the > primary purpose of the Google SoC :) Indeed, the purpose is the IAX2 support, not refactoring the code. I would say that hardcoding the IAX2 account setup in the code would be enough for the SoC. Making it work in the ui in the accounts would be bonus if you had the time, or would be a work to do afterwards. Snark From dsandras@seconix.com Fri Jun 2 10:34:17 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C28113B045D for ; Fri, 2 Jun 2006 10:34:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00352-08 for ; Fri, 2 Jun 2006 10:34:16 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id CE7FF3B0478 for ; Fri, 2 Jun 2006 10:34:15 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 0EFE1496C7 for ; Fri, 2 Jun 2006 16:17:49 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08222-10 for ; Fri, 2 Jun 2006 16:17:42 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 3C897496C6 for ; Fri, 2 Jun 2006 16:17:42 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44804375.6090107@free.fr> References: <1149242124.4509.17.camel@siti> <1149246374.2966.25.camel@golgoth01> <44804375.6090107@free.fr> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 02 Jun 2006 16:34:27 +0200 Message-Id: <1149258867.8383.10.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 14:34:17 -0000 Le vendredi 02 juin 2006 à 15:56 +0200, Julien PUYDT a écrit : > Damien Sandras a écrit : > > I would say that the main part will be to write / finish the IAX2 code > > in OPAL, either new code, or reusing the current code so that all > > features that you see in SIP and H.323 are also available for IAX2. > > > > Your first project will be to look the limitations of the current code > > and write a document showing what features you have tested, what work is > > required to complete them, and what new work is required for new > > features (Call Hold, Call Transfer, Registering, Call Forward, ...). > > > > Writing the endpoint in Ekiga is the last part of the project once the > > code in OPAL is full functional. Ekiga only contains high-level code. > > I don't fully agree with you: writing low-level code all summer long > then finally writing the upper-level code, will lead to a non-working > feature :-/ I agree with you, but you can not start writing the EndPoint if there is no code behind it ;) > > Having a least minimal functionality in ekiga would be nice to test the > low-level regularly, and see it improving. > > >> One key problem I have identified is the accounts code. The protocols > >> are tightly integrated with how it works. I could either refactor this > >> code to loosen the integration or hack iax2 support in there and > >> refactor it later ;). The advantage of this refactored will be when > >> someone wants to add Xmpp/libjingle support, or some other protocol down > >> the track. > > > > I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and > > finally perhaps to a refactoring of the accounts code as it is not the > > primary purpose of the Google SoC :) > > Indeed, the purpose is the IAX2 support, not refactoring the code. I > would say that hardcoding the IAX2 account setup in the code would be > enough for the SoC. > > Making it work in the ui in the accounts would be bonus if you had the > time, or would be a work to do afterwards. > Exactly. > Snark > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From t.schorpp@gmx.de Fri Jun 2 11:06:17 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 63A943B02F7 for ; Fri, 2 Jun 2006 11:06:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02214-08 for ; Fri, 2 Jun 2006 11:06:10 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by menubar.gnome.org (Postfix) with SMTP id 7B6603B0421 for ; Fri, 2 Jun 2006 11:06:09 -0400 (EDT) Received: (qmail invoked by alias); 02 Jun 2006 15:06:08 -0000 Received: from p85.212.150.108.tisdip.tiscali.de (EHLO [192.168.1.100]) [85.212.150.108] by mail.gmx.net (mp001) with SMTP; 02 Jun 2006 17:06:08 +0200 X-Authenticated: #17142692 Message-ID: <448053DE.1010406@gmx.de> Date: Fri, 02 Jun 2006 17:06:06 +0200 From: thomas schorpp User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1 X-Accept-Language: de, en-us MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Bad review about Ekiga References: <1148993400.2400.77.camel@golgoth01> In-Reply-To: <1148993400.2400.77.camel@golgoth01> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.476 tagged_above=-999 required=2 tests=[AWL=-0.011, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] X-Spam-Score: -2.476 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: t.schorpp@gmx.de, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 15:06:17 -0000 Damien Sandras wrote: > http://linux.softpedia.com/progViewUserReviews/156167.html > > This software is a descendant of the former "gnome-meeting" software. It > comes bundled with its own SIP service but claims to work with others. > Unfortunately it has inherited not only the GUI from gnome-meeting but > also the habit to crash every other minute without apparent reason. So I > never got to really test it yet. > > The developers might be better off not making the same mistake as they > did with gnome-meeting and should try to fix all the bugs instead of > adding more crashing bells and whistles. Bad? Bad yes: for marketing. You cant just say this commenter were just too stupid to get the right libs together. Bad no: for development. says You need better CM: - suggest the devs and QA people, users, agree on a certain range of gui libs versions. - suggest meeting with distro maintainers and tight the deps found above to avoid lib/binary inconsistencies. - improve exception handling and fault tolerance on the outside interfaces. ? y tom From craigs@postincrement.com Fri Jun 2 19:57:21 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CDB2A3B11E3 for ; Fri, 2 Jun 2006 19:57:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32469-02 for ; Fri, 2 Jun 2006 19:57:18 -0400 (EDT) Received: from bastion.southeren.com (unknown [220.244.81.10]) by menubar.gnome.org (Postfix) with ESMTP id 870583B11CC for ; Fri, 2 Jun 2006 19:57:17 -0400 (EDT) Received: from [10.0.2.13] (rapido.southeren.com [10.0.2.13]) by bastion.southeren.com (8.12.8/8.12.8) with ESMTP id k52NteJG016237; Sat, 3 Jun 2006 09:55:40 +1000 Date: Sat, 03 Jun 2006 09:55:43 +1000 From: Craig Southeren To: Stephen Cook , GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga In-Reply-To: <1149242124.4509.17.camel@siti> References: <1149242124.4509.17.camel@siti> Message-Id: <20060603095331.79CD.CRAIGS@postincrement.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Becky! ver. 2.11.02 [en] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.939 tagged_above=-999 required=2 tests=[AWL=-0.482, BAYES_00=-2.599, SPF_FAIL=1.142] X-Spam-Score: -1.939 X-Spam-Level: Cc: Derek Smithies X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 23:57:22 -0000 On Fri, 02 Jun 2006 21:55:24 +1200 Stephen Cook wrote: > Hi, >=20 > I haven't introduced myself here before, I am Stephen Cook (siti). My > proposal for implementing IAX2 in ekiga got accepted with google's > summer of code. >=20 > To give an update (I'll try and keep you guys regularly posted as to > what's happening, any problems etc.). >=20 > Currently I have been looking at the code to gain an understanding of > ekiga and opal's code and design. Also obviously checking out the IAX2 > code in opal :). From what I have seen and got working, I will work on > getting IAX2 going in ekiga first. The main part of this will obviously > involve writing a gnome meeting endpoint for IAX2. >=20 > One key problem I have identified is the accounts code. The protocols > are tightly integrated with how it works. I could either refactor this > code to loosen the integration or hack iax2 support in there and > refactor it later ;). The advantage of this refactored will be when > someone wants to add Xmpp/libjingle support, or some other protocol down > the track. >=20 > Well, please tell me your thoughts and comments on this project. As a New Zealander, you are uniquely placed to communicate with the author of the OPAL IAX2 code, Derek Smithies, who is a fellow Kiwi! I am sure that you will be able to get the OPAL IAX2 code working with Ekiga in no time at all with his help.=20 If you have any questions, please contact me directly. Craig ----------------------------------------------------------------------- Craig Southeren Post Increment =96 VoIP Consulting and Software craigs@postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren@hotmail.com Mobile: +61 417231046 =20 "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting From hoglet@solit.se Sat Jun 3 03:46:01 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9178F3B04E8 for ; Sat, 3 Jun 2006 03:46:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19488-05 for ; Sat, 3 Jun 2006 03:45:59 -0400 (EDT) Received: from aurian.solit.se (unknown [82.182.216.174]) by menubar.gnome.org (Postfix) with ESMTP id 9DD3C3B0505 for ; Sat, 3 Jun 2006 03:45:59 -0400 (EDT) Received: from ip76.kassjo.se ([85.11.28.76] helo=localhost.localdomain) by aurian.solit.se with asmtp (Exim 3.35 #1 (Debian)) id 1FmQpW-0006J7-00 for ; Sat, 03 Jun 2006 09:45:54 +0200 Date: Sat, 3 Jun 2006 09:45:50 +0200 From: Kent Asplund To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Bad review about Ekiga Message-Id: <20060603094550.0e1ff8aa.hoglet@solit.se> In-Reply-To: <1148993400.2400.77.camel@golgoth01> References: <1148993400.2400.77.camel@golgoth01> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: ej spam, SpamAssassin (resultat=-4.4, krav 5, IN_REP_TO -4.43) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.898 tagged_above=-999 required=2 tests=[AWL=-1.435, BAYES_20=-0.74, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142] X-Spam-Score: -0.898 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 07:46:01 -0000 --Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 30 May 2006 14:50:00 +0200 Damien Sandras wrote: > http://linux.softpedia.com/progViewUserReviews/156167.html >=20 > This software is a descendant of the former "gnome-meeting" software. It > comes bundled with its own SIP service but claims to work with others. > Unfortunately it has inherited not only the GUI from gnome-meeting but > also the habit to crash every other minute without apparent reason. So I > never got to really test it yet. >=20 > The developers might be better off not making the same mistake as they > did with gnome-meeting and should try to fix all the bugs instead of > adding more crashing bells and whistles. I have never had a crash and the program was easy to setup. I have had some problem but they have been outside of Ekiga (siproxd and firewall) Ekiga has som distance to go to "get finished" but it is still THE BEST PROGRAM AROUND! Subjectively of course :) Waiting patiently for 2.2 /Hoglet --=20 Go ahead... make my day. -- Dirty Harry --Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEgT4x4WZLcIH5l3kRApw3AJ9yPgdPoUSeKGniD1w0w0cMTXajRACfWaDG 2YUvSTxFnaSeD8q0uWWv6zE= =2nFl -----END PGP SIGNATURE----- --Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny-- From hoglet@solit.se Sat Jun 3 03:54:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C25A43B05C8 for ; Sat, 3 Jun 2006 03:54:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19755-10 for ; Sat, 3 Jun 2006 03:54:38 -0400 (EDT) Received: from aurian.solit.se (unknown [82.182.216.174]) by menubar.gnome.org (Postfix) with ESMTP id B980A3B04F9 for ; Sat, 3 Jun 2006 03:54:38 -0400 (EDT) Received: from ip76.kassjo.se ([85.11.28.76] helo=localhost.localdomain) by aurian.solit.se with asmtp (Exim 3.35 #1 (Debian)) id 1FmQxt-0006L4-00 for ; Sat, 03 Jun 2006 09:54:33 +0200 Date: Sat, 3 Jun 2006 09:54:33 +0200 From: Kent Asplund To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Re: Ekiga branched Message-Id: <20060603095433.82461abf.hoglet@solit.se> In-Reply-To: <447EE9BE.5030005@free.fr> References: <1147894199.7225.2.camel@golgoth01> <1148207277.6654.0.camel@frobisher.madeley.id.au> <1148209984.2488.26.camel@golgoth01> <20060601150938.fcdea791.hoglet@solit.se> <447EE9BE.5030005@free.fr> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: ej spam, SpamAssassin (resultat=-4.4, krav 5, IN_REP_TO -4.43) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.764 tagged_above=-999 required=2 tests=[AWL=-0.519, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142, TW_KT=0.077] X-Spam-Score: -1.764 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 07:54:39 -0000 --Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 01 Jun 2006 15:21:02 +0200 Julien PUYDT wrote: > Kent Asplund a =E9crit : > > Exchanging the button to a green phone handle (red when calling in > > progress) would make it more alike others and therefore easier to > > accept. >=20 > The classic case of "your flying car lacks a spare wheel!" ;-) I'm taking the risk of seeming to be completely without humour. No, it is more a case of having a car with automatic gearbox and instead of having a lever you have a button for changing direction.=20 It works perfektly OK but people will think that it is a strange car and choose another one. (I think Citro=EBn had this problem) My wife just said "it is made for nerds not humans" Greetings /Hoglet the nerd --=20 I don't know anything about music. In my line you don't have to. -- Elvis Presley --Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEgUA54WZLcIH5l3kRAiYpAJ4/lkEYFVjWRQrYSvn7D9XmkU+6FgCgiejD m2Sp2AVqfZZHzT5TaBCVu5I= =OH96 -----END PGP SIGNATURE----- --Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ-- From devel@tootai.net Sat Jun 3 11:12:15 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3EF583B05AE for ; Sat, 3 Jun 2006 11:12:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11557-03 for ; Sat, 3 Jun 2006 11:12:10 -0400 (EDT) Received: from mail1.tootai.net (ns1.tootai.net [82.231.69.24]) by menubar.gnome.org (Postfix) with ESMTP id A02F63B0348 for ; Sat, 3 Jun 2006 11:12:09 -0400 (EDT) Received: from [192.168.0.17] (unknown [192.168.0.17]) by mail1.tootai.net (Postfix) with ESMTP id E2ACD398BA0 for ; Sat, 3 Jun 2006 17:12:06 +0200 (CEST) Message-ID: <4481A6AF.2060703@tootai.net> Date: Sat, 03 Jun 2006 17:11:43 +0200 From: Daniel Huhardeaux Organization: TOOTAi User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: GnomeMeeting development mailing list Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: Subject: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 15:12:15 -0000 Resent as it didn't pass at the first try (too big, I cut the begining of logs) Hi all, Ekiga behind a firewall is registering to an asterisk server which is on internet. The sip user is authorized with gsm,ulaw,alaw on asterisk side. When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is started, connection is showed with PCMU (why not GSM?), see the traffic in/out (~6 kB) but have no audio. I hangup the call, the hangup info is shown in the toolbar, PCMU disappear in codec and immediately after, traffic in/out continue with 0/0, icon in KDE Toolbar show Ekiga on line. The only solution I have is to kill Ekiga. If I deactivate GSM codec, everything is fine. Below you will find a d4 output from the call. [...] 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 OpalUDP Ended connect, selecting 82.231.69.24:35065 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP Queueing PDU: 1 INVITE <407> 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP Waiting for PDU on udp$213.203.241.243:5060 2006/06/02 13:12:32.901 0:10.661 SIP Handler:8520268 SIP PDU handler thread started. 2006/06/02 13:12:32.902 0:10.662 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:32.902 0:10.663 SIP Handler:8520268 SIP Handling PDU 1 INVITE <407> (with transaction) 2006/06/02 13:12:32.903 0:10.663 SIP Handler:8520268 SIP Transaction 1 INVITE completed. 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP Sending PDU on udp$213.203.241.243:5060 ACK sip:800@sip.tootai.net SIP/2.0 CSeq: 1 ACK Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bK803b125b-96f0-da11-8388-000ea6217592;rport From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: ;tag=as315809c6 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 70 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP Received Proxy Authentication Required response 2006/06/02 13:12:32.906 0:10.666 SIP Handler:8520268 SIP Transaction 2 INVITE created. 2006/06/02 13:12:32.906 0:10.667 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:33.090 0:10.850 SIP Handler:8520268 RTP_UDP Session 1 created: 82.231.69.24:35010-35011 ssrc=703395120 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 RTP Adding session RTP_UDP 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 SIP Using RTP payload [pt=101] for NTE 2006/06/02 13:12:33.100 0:10.860 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k H.261(QCIF) H.261(CIF) YUV420P RGB32 RGB24 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 2 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 2 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 SIP IsMediaBypassPossible: session 2 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:33.281 0:11.041 SIP Handler:8520268 RTP_UDP Session 2 created: 82.231.69.24:35014-35015 ssrc=2454563097 2006/06/02 13:12:33.282 0:11.042 SIP Handler:8520268 RTP Adding session RTP_UDP 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k H.261(QCIF) H.261(CIF) YUV420P RGB32 RGB24 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 SIP Adding authentication information 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP Sending PDU on udp$213.203.241.243:5060 INVITE sip:800@sip.tootai.net SIP/2.0 Date: Fri, 02 Jun 2006 11:12:32 GMT CSeq: 2 INVITE Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;rport User-Agent: Ekiga/2.0.1-20060521-01 From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: Contact: Proxy-Authorization: Digest username="104", realm="sip.tootai.net", nonce="12d01d5d", uri="sip:800@sip.tootai.net", response="60b65ec9045130eab45495d3c65fbc5e", algorithm=md5 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Type: application/sdp Content-Length: 302 Max-Forwards: 70 v=0 o=- 1149246753 1149246753 IN IP4 82.231.69.24 s=Opal SIP Session c=IN IP4 82.231.69.24 t=0 0 m=audio 35010 RTP/AVP 101 3 0 8 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 m=video 35014 RTP/AVP 31 a=rtpmap:31 H261/90000 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP PDU Received on udp$213.203.241.243:5060 SIP/2.0 100 Trying CSeq: 2 INVITE Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 User-Agent: Asterisk PBX From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP Queueing PDU: 2 INVITE <100> 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP Waiting for PDU on udp$213.203.241.243:5060 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP Handling PDU 2 INVITE <100> (with transaction) 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP Transaction 2 INVITE proceeding. 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Set targetAddress to sip:800@213.203.241.243 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Received Trying response 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP Media session port=7166 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP Adding media session with 2 formats 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP Unknown media attribute silenceSupp:off - - - - 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SIP PDU Received on udp$213.203.241.243:5060 SIP/2.0 200 OK CSeq: 2 INVITE Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 User-Agent: Asterisk PBX From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: ;tag=as5d2831d1 Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Type: application/sdp Content-Length: 221 v=0 o=root 26912 26912 IN IP4 213.203.241.243 s=session c=IN IP4 213.203.241.243 t=0 0 m=audio 7166 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP Queueing PDU: 2 INVITE <200> 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP Waiting for PDU on udp$213.203.241.243:5060 2006/06/02 13:12:33.388 0:11.148 SIP Handler:8520268 SIP Handling PDU 2 INVITE <200> (with transaction) 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP Transaction 2 INVITE completed. 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP Set targetAddress to sip:800@213.203.241.243 2006/06/02 13:12:33.390 0:11.150 SIP Handler:8520268 SIP Adding authentication information 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP Adjusting transport to address udp$213.203.241.243:5060 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP Sending PDU on udp$213.203.241.243:5060 ACK sip:800@213.203.241.243 SIP/2.0 CSeq: 2 ACK Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bK6e2ca15b-96f0-da11-8388-000ea6217592;rport From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: ;tag=as5d2831d1 Contact: Proxy-Authorization: Digest username="104", realm="sip.tootai.net", nonce="12d01d5d", uri="sip:800@213.203.241.243", response="059defd67706254552a5c23eada565b5", algorithm=md5 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 70 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP Received INVITE OK response 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 SIP RTP payload type PCMU matched to codec G.711-uLaw-64k 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 OpalCon OpenSourceMediaStream for session 1 on Call[1]-EP[Default] 2006/06/02 13:12:33.398 0:11.158 SIP Handler:8520268 OpalCon Selected media stream PCM-16 -> G.711-uLaw-64k 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 Call PatchMediaStreams Call[1]-EP[Default] 2006/06/02 13:12:34.196 0:11.957 SIP Handler:8520268 OpalCon OpenSinkMediaStream Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session=1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon OpenSinkMediaStream, selected PCM-16 -> G.711-uLaw-64k 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:34.197 0:11.958 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Patch Added sink from PCM-16 Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 16 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 to G.711-uLaw-64k Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 8 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Codec G711-uLaw-64k encoder created 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Patch Added media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k using transcoder PCM-16->G.711-uLaw-64k 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Media Audio source data size set to 320 bytes and 2 buffers. 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call GetOtherPartyConnection Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon OpenSourceMediaStream for session 1 on Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon Selected media stream G.711-uLaw-64k -> PCM-16 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 Call PatchMediaStreams Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon OpenSinkMediaStream Call[1]-EP[Default] session=1 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon OpenSinkMediaStream, selected G.711-uLaw-64k -> PCM-16 2006/06/02 13:12:34.513 0:12.274 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:34.514 0:12.274 SIP Handler:8520268 Patch Added sink from G.711-uLaw-64k Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 8 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 to PCM-16 Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 16 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Codec G711-uLaw-64k decoder created 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Media Audio sink data size set to 320 bytes and 2 buffers. 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Patch Added media stream sink OpalAudioMediaStream-Sink-PCM-16 using transcoder G.711-uLaw-64k->PCM-16 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.525 0:12.285 SIP Handler:8520268 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.527 0:12.287 SIP Handler:8520268 RTP_UDP SetRemoteSocketInfo: session=1 data channel, new=213.203.241.243:7166, local=82.231.69.24:35010-35011, remote=0.0.0.0:0-0 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 SIP Could not find SDP media description for Video 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 OpalMan OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 Call OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 PCSS SetConnected() 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 GMPCSSEndpoint PCSS connection established 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 GMManager Will establish the connection 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 OpalMan OnEstablished Call[1]-EP[Default] 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 Call OnEstablished Call[1]-EP[Default] 2006/06/02 13:12:34.540 0:12.300 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[Default] G.711-uLaw-64k 2006/06/02 13:12:34.541 0:12.301 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k 2006/06/02 13:12:34.542 0:12.302 SIP Handler:8520268 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.543 0:12.303 SIP Handler:8520268 Call OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] G.711-uLaw-64k 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[Default] 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k 2006/06/02 13:12:34.552 0:12.312 SIP Handler:8520268 Call OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k 2006/06/02 13:12:34.553 0:12.313 Media Patch:8175708 Patch Thread started for Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:34.556 0:12.316 SIP Handler:8520268 Media Starting thread Media Patch:8175708 2006/06/02 13:12:34.557 0:12.317 Media Patch:8527348 Patch Thread started for Patch OpalRTPMediaStream-Source-G.711-uLaw-64k -> OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:34.568 0:12.329 Media Patch:8527348 RTP Jitter buffer created: size=101 delay=160-4000/160 (20ms) obj=0x8526b30 2006/06/02 13:12:34.572 0:12.333 RTP Jitter:8526b30 RTP Jitter RTP receive thread started: 0x8526b30 2006/06/02 13:12:34.574 0:12.334 RTP Jitter:8526b30 RTP First receive data: ver=2 pt=GSM psz=33 m=0 x=0 seq=39915 ts=160 src=824302623 ccnt=0 2006/06/02 13:12:34.580 0:12.341 SIP Handler:8520268 Media Starting thread Media Patch:8527348 2006/06/02 13:12:34.581 0:12.341 SIP Handler:8520268 OpalCon Media stream threads started. 2006/06/02 13:12:34.582 0:12.342 SIP Handler:8520268 OpalCon Media stream threads started. 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP Found existing session 2 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 GMManager Will establish the connection 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 OpalMan OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.607 0:12.367 SIP Handler:8520268 Call OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.610 0:12.371 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:34.648 0:12.408 Media Patch:8527348 RTP Jitter buffer length exceeded 2006/06/02 13:12:34.649 0:12.409 Media Patch:8527348 RTP Jitter buffer length exceed was prior to first write. Not increasing buffer size 2006/06/02 13:12:35.277 0:13.037 Media Patch:8175708 RTP First sent data: ver=2 pt=PCMU psz=160 m=1 x=0 seq=1460 ts=0 src=703395120 ccnt=0 2006/06/02 13:12:35.608 0:13.368 Housekeeper RTP Found existing session 1 2006/06/02 13:12:35.609 0:13.369 Housekeeper RTP Found existing session 2 2006/06/02 13:12:36.137 0:13.898 RTP Jitter:8526b30 RTP Receive statistics: packets=101 octets=3714 lost=0 tooLate=0 order=0 avgTime=15 maxTime=1556 minTime=0 jitter=16 maxJitter=188 2006/06/02 13:12:36.573 0:14.333 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (9760) 2006/06/02 13:12:36.614 0:14.374 Housekeeper RTP Found existing session 1 2006/06/02 13:12:36.615 0:14.375 Housekeeper RTP Found existing session 2 2006/06/02 13:12:36.974 0:14.734 RTP Jitter:8526b30 RTP Jitter buffer continuously full, throwing away entire buffer. 2006/06/02 13:12:36.995 0:14.756 RTP Jitter:8526b30 RTP Jitter buffer full, threw away 21 oldest frames 2006/06/02 13:12:37.374 0:15.134 RTP Jitter:8526b30 RTP Receive statistics: packets=201 octets=19714 lost=0 tooLate=0 order=0 avgTime=12 maxTime=23 minTime=0 jitter=0 maxJitter=188 2006/06/02 13:12:37.620 0:15.380 Housekeeper RTP Found existing session 1 2006/06/02 13:12:37.621 0:15.381 Housekeeper RTP Found existing session 2 2006/06/02 13:12:37.820 0:15.580 Media Patch:8175708 RTP Transmit statistics: packets=101 octets=16160 avgTime=25 maxTime=48 minTime=23 2006/06/02 13:12:38.624 0:16.384 Housekeeper RTP Found existing session 1 2006/06/02 13:12:38.625 0:16.385 Housekeeper RTP Found existing session 2 2006/06/02 13:12:38.993 0:16.753 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (29120) 2006/06/02 13:12:39.374 0:17.134 RTP Jitter:8526b30 RTP Receive statistics: packets=301 octets=35714 lost=0 tooLate=0 order=0 avgTime=20 maxTime=26 minTime=14 jitter=1 maxJitter=188 2006/06/02 13:12:39.395 0:17.155 RTP Jitter:8526b30 RTP Jitter buffer continuously full, throwing away entire buffer. 2006/06/02 13:12:39.415 0:17.176 RTP Jitter:8526b30 RTP Jitter buffer full, threw away 21 oldest frames 2006/06/02 13:12:39.632 0:17.392 Housekeeper RTP Found existing session 1 2006/06/02 13:12:39.633 0:17.393 Housekeeper RTP Found existing session 2 2006/06/02 13:12:40.384 0:18.144 Media Patch:8175708 RTP Transmit statistics: packets=201 octets=32160 avgTime=25 maxTime=44 minTime=22 2006/06/02 13:12:40.640 0:18.400 Housekeeper RTP Found existing session 1 2006/06/02 13:12:40.641 0:18.401 Housekeeper RTP Found existing session 2 2006/06/02 13:12:41.373 0:19.133 RTP Jitter:8526b30 RTP Receive statistics: packets=401 octets=51714 lost=0 tooLate=0 order=0 avgTime=19 maxTime=26 minTime=13 jitter=1 maxJitter=188 2006/06/02 13:12:41.413 0:19.173 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (48480) 2006/06/02 13:12:41.648 0:19.424 Housekeeper RTP Found existing session 1 2006/06/02 13:12:41.665 0:19.425 Housekeeper RTP Found existing session 2 2006/06/02 13:12:41.813 0:19.573 RTP Jitter:8526b30 RTP Jitter buffer continuously full, throwing away entire buffer. 2006/06/02 13:12:41.833 0:19.593 RTP Jitter:8526b30 RTP Jitter buffer full, threw away 21 oldest frames 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP Found existing session 1 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP Found existing session 2 2006/06/02 13:12:42.920 0:20.680 Media Patch:8175708 RTP Transmit statistics: packets=301 octets=48160 avgTime=25 maxTime=49 minTime=22 2006/06/02 13:12:43.378 0:21.139 RTP Jitter:8526b30 RTP Receive statistics: packets=501 octets=67714 lost=0 tooLate=0 order=0 avgTime=20 maxTime=27 minTime=12 jitter=1 maxJitter=188 2006/06/02 13:12:43.696 0:21.457 Housekeeper RTP Found existing session 1 2006/06/02 13:12:43.697 0:21.457 Housekeeper RTP Found existing session 2 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot Call Clearing Call[1] reason=EndedByLocalUser 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot OpalCon Releasing Call[1]-EP[Default] 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon Call end reason for Default set to EndedByLocalUser 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon SetPhase from EstablishedPhase to ReleasingPhase 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon Releasing Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon Call end reason for fa44075b-96f0-da11-8388-000ea6217592@nomade set to EndedByLocalUser 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon SetPhase from EstablishedPhase to ReleasingPhase 2006/06/02 13:12:43.820 0:21.581 OnRelease:856e8a0 OpalCon OnReleased Call[1]-EP[Default] 2006/06/02 13:12:43.822 0:21.583 OnRelease:856e8a0 Media Closing raw media stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.824 0:21.584 OnRelease:856e8a0 Media Closing stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.825 0:21.585 OnRelease:856e8a0 Media Disconnecting OpalAudioMediaStream-Source-PCM-16 from patch thread Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.827 0:21.587 OnRelease:856e8a0 Patch Closing media patch Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.829 0:21.589 OnRelease:856e8a0 Media Closing raw media stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.830 0:21.590 OnRelease:856e8a0 Media Closing stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.831 0:21.591 OnRelease:84f8c00 SIP OnReleased: Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade], phase = ReleasingPhase 2006/06/02 13:12:43.833 0:21.593 OnRelease:84f8c00 OpalCon SetPhase from ReleasingPhase to ReleasingPhase 2006/06/02 13:12:43.834 0:21.594 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (67840) 2006/06/02 13:12:43.836 0:21.596 OnRelease:84f8c00 SIP Transaction 4 BYE created. 2006/06/02 13:12:43.842 0:21.603 OnRelease:84f8c00 Media Closing RTP for OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.844 0:21.604 OnRelease:84f8c00 RTP_UDP Session 1, Shutting down write. 2006/06/02 13:12:43.845 0:21.605 OnRelease:84f8c00 Media Closing stream OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.846 0:21.606 OnRelease:84f8c00 Media Disconnecting OpalRTPMediaStream-Sink-G.711-uLaw-64k from patch thread Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.848 0:21.609 OnRelease:84f8c00 Patch Removing media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.855 0:21.626 OnRelease:84f8c00 Media Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.867 0:21.627 OnRelease:84f8c00 RTP_UDP Session 1, Shutting down read. 2006/06/02 13:12:43.868 0:21.628 OnRelease:84f8c00 Media Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.869 0:21.630 OnRelease:84f8c00 Media Disconnecting OpalRTPMediaStream-Source-G.711-uLaw-64k from patch thread Patch OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.893 0:21.653 Media Patch:8175708 Patch Thread ended for Patch OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.893 0:21.653 OnRelease:84f8c00 Patch Closing media patch Patch OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.916 0:21.676 RTP Jitter:8526b30 RTP_UDP Session 1, Read shutdown. 2006/06/02 13:12:43.917 0:21.677 RTP Jitter:8526b30 RTP Jitter RTP receive thread ended 2006/06/02 13:12:43.917 0:21.677 OnRelease:84f8c00 Media Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.918 0:21.678 OnRelease:84f8c00 RTP_UDP Session 1, Shutting down read. 2006/06/02 13:12:43.919 0:21.679 OnRelease:84f8c00 Media Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.922 0:21.683 OnRelease:856e8a0 Patch Waiting for media patch thread to stop Patch OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.926 0:21.686 OnRelease:856e8a0 Patch Media patch thread Patch OpalAudioMediaStream-Source-PCM-16 destroyed. 2006/06/02 13:12:43.930 0:21.691 OnRelease:856e8a0 Media Closing raw media stream OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:43.932 0:21.693 OnRelease:856e8a0 Media Closing stream OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:43.933 0:21.694 OnRelease:856e8a0 Media Disconnecting OpalAudioMediaStream-Sink-PCM-16 from patch thread Patch OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.956 0:21.717 OnRelease:856e8a0 Patch Removing media stream sink OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP Found existing session 1 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP Found existing session 2 2006/06/02 13:12:45.696 0:23.456 Housekeeper RTP Found existing session 1 2006/06/02 13:12:45.697 0:23.457 Housekeeper RTP Found existing session 2 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP Found existing session 1 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP Found existing session 2 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP Found existing session 1 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP Found existing session 2 2006/06/02 13:12:48.708 0:26.468 Housekeeper RTP Found existing session 1 2006/06/02 13:12:48.709 0:26.469 Housekeeper RTP Found existing session 2 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP Found existing session 1 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP Found existing session 2 2006/06/02 13:12:50.712 0:28.473 Housekeeper RTP Found existing session 1 2006/06/02 13:12:50.713 0:28.473 Housekeeper RTP Found existing session 2 2006/06/02 13:12:51.716 0:29.477 Housekeeper RTP Found existing session 1 2006/06/02 13:12:51.717 0:29.477 Housekeeper RTP Found existing session 2 2006/06/02 13:12:52.716 0:30.477 Housekeeper RTP Found existing session 1 2006/06/02 13:12:52.717 0:30.477 Housekeeper RTP Found existing session 2 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP Found existing session 1 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP Found existing session 2 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP Found existing session 1 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP Found existing session 2 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP Found existing session 1 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP Found existing session 2 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP Found existing session 1 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP Found existing session 2 2006/06/02 13:12:57.733 0:35.493 Housekeeper RTP Found existing session 1 2006/06/02 13:12:57.734 0:35.494 Housekeeper RTP Found existing session 2 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP Found existing session 1 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP Found existing session 2 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP Found existing session 1 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP Found existing session 2 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP Found existing session 1 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP Found existing session 2 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP Found existing session 1 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP Found existing session 2 2006/06/02 13:13:02.777 0:40.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:02.778 0:40.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP Found existing session 2 2006/06/02 13:13:04.369 0:42.129 Housekeeper SIP Set state Terminated_Success for transaction 1 INVITE 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP Found existing session 2 2006/06/02 13:13:05.777 0:43.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:05.777 0:43.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:06.613 0:44.374 Housekeeper SIP Set state Terminated_Success for transaction 2 INVITE 2006/06/02 13:13:06.777 0:44.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:06.778 0:44.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:07.777 0:45.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:07.778 0:45.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP Found existing session 2 Processus arrêté -- Daniel From dsandras@seconix.com Sat Jun 3 13:58:00 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 184373B06A7 for ; Sat, 3 Jun 2006 13:58:00 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20355-03 for ; Sat, 3 Jun 2006 13:57:57 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 19BB03B036E for ; Sat, 3 Jun 2006 13:57:56 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id BC1A4493FD; Sat, 3 Jun 2006 19:41:15 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13551-03; Sat, 3 Jun 2006 19:41:05 +0200 (CEST) Received: from d51A5F203.access.telenet.be (d51A5F203.access.telenet.be [81.165.242.3]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id BC664493EE; Sat, 3 Jun 2006 19:41:05 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <20060603095331.79CD.CRAIGS@postincrement.com> References: <1149242124.4509.17.camel@siti> <20060603095331.79CD.CRAIGS@postincrement.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Sat, 03 Jun 2006 19:57:45 +0200 Message-Id: <1149357465.2414.30.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: Cc: Derek Smithies X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 17:58:00 -0000 Le samedi 03 juin 2006 à 09:55 +1000, Craig Southeren a écrit : > On Fri, 02 Jun 2006 21:55:24 +1200 > Stephen Cook wrote: > > > Hi, > > > > I haven't introduced myself here before, I am Stephen Cook (siti). My > > proposal for implementing IAX2 in ekiga got accepted with google's > > summer of code. > > > > To give an update (I'll try and keep you guys regularly posted as to > > what's happening, any problems etc.). > > > > Currently I have been looking at the code to gain an understanding of > > ekiga and opal's code and design. Also obviously checking out the IAX2 > > code in opal :). From what I have seen and got working, I will work on > > getting IAX2 going in ekiga first. The main part of this will obviously > > involve writing a gnome meeting endpoint for IAX2. > > > > One key problem I have identified is the accounts code. The protocols > > are tightly integrated with how it works. I could either refactor this > > code to loosen the integration or hack iax2 support in there and > > refactor it later ;). The advantage of this refactored will be when > > someone wants to add Xmpp/libjingle support, or some other protocol down > > the track. > > > > Well, please tell me your thoughts and comments on this project. > > As a New Zealander, you are uniquely placed to communicate with the > author of the OPAL IAX2 code, Derek Smithies, who is a fellow Kiwi! I am > sure that you will be able to get the OPAL IAX2 code working with Ekiga > in no time at all with his help. > > If you have any questions, please contact me directly. > Craig, I do not think moving to an offline conversation with Stephen is a good idea. Julien and myself are supposed to mentor the project. Your help is of course welcome, but we have to be kept informed. Notice also that the project is not only about making IAX2 work with Ekiga. -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Sat Jun 3 14:01:08 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 59C003B01BB for ; Sat, 3 Jun 2006 14:01:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20343-10 for ; Sat, 3 Jun 2006 14:01:02 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id BA0863B04B1 for ; Sat, 3 Jun 2006 14:01:01 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 1184A496A8 for ; Sat, 3 Jun 2006 19:44:21 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13551-04 for ; Sat, 3 Jun 2006 19:44:12 +0200 (CEST) Received: from d51A5F203.access.telenet.be (d51A5F203.access.telenet.be [81.165.242.3]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 993CE49685 for ; Sat, 3 Jun 2006 19:44:07 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <4481A6AF.2060703@tootai.net> References: <4481A6AF.2060703@tootai.net> Content-Type: text/plain; charset=ISO-8859-15 Date: Sat, 03 Jun 2006 20:00:48 +0200 Message-Id: <1149357648.2414.34.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 18:01:08 -0000 Hi, Le samedi 03 juin 2006 à 17:11 +0200, Daniel Huhardeaux a écrit : > Resent as it didn't pass at the first try (too big, I cut the begining > of logs) > > Hi all, > > Ekiga behind a firewall is registering to an asterisk server which is on > internet. The sip user is authorized with gsm,ulaw,alaw on asterisk side. > > When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is > started, connection is showed with PCMU (why not GSM?), see the traffic > in/out (~6 kB) but have no audio. > Asterisk answers with 200 OK indicating that the call should be done with PCMU. > I hangup the call, the hangup info is shown in the toolbar, PCMU > disappear in codec and immediately after, traffic in/out continue with > 0/0, icon in KDE Toolbar show Ekiga on line. The only solution I have is > to kill Ekiga. > Please try with 2.0.2. Craig has done work in CVS and things are potentially broken. If the problem persists once plugins support is in CVS, please report again. > If I deactivate GSM codec, everything is fine. Below you will find a d4 > output from the call. > I do not think activating GSM or not has any influence. The problem is probably something else. > > [...] > 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 OpalUDP > Ended connect, selecting 82.231.69.24:35065 > 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP > Queueing PDU: 1 INVITE <407> > 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP > Waiting for PDU on udp$213.203.241.243:5060 > 2006/06/02 13:12:32.901 0:10.661 SIP Handler:8520268 SIP PDU > handler thread started. > 2006/06/02 13:12:32.902 0:10.662 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:32.902 0:10.663 SIP Handler:8520268 SIP > Handling PDU 1 INVITE <407> (with transaction) > 2006/06/02 13:12:32.903 0:10.663 SIP Handler:8520268 SIP > Transaction 1 INVITE completed. > 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP > Sending PDU on udp$213.203.241.243:5060 > ACK sip:800@sip.tootai.net SIP/2.0 > CSeq: 1 ACK > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bK803b125b-96f0-da11-8388-000ea6217592;rport > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: ;tag=as315809c6 > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE > Content-Length: 0 > Max-Forwards: 70 > > > 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP > Received Proxy Authentication Required response > 2006/06/02 13:12:32.906 0:10.666 SIP Handler:8520268 SIP > Transaction 2 INVITE created. > 2006/06/02 13:12:32.906 0:10.667 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:33.090 0:10.850 SIP Handler:8520268 RTP_UDP > Session 1 created: 82.231.69.24:35010-35011 ssrc=703395120 > 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 RTP > Adding session RTP_UDP > 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 SIP > Using RTP payload [pt=101] for NTE > 2006/06/02 13:12:33.100 0:10.860 SIP Handler:8520268 Call > GetMediaFormats for > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > GSM-06.10 > G.711-uLaw-64k > G.711-ALaw-64k > H.261(QCIF) > H.261(CIF) > YUV420P > RGB32 > RGB24 > > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 2 > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 2 > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 2 > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:33.281 0:11.041 SIP Handler:8520268 RTP_UDP > Session 2 created: 82.231.69.24:35014-35015 ssrc=2454563097 > 2006/06/02 13:12:33.282 0:11.042 SIP Handler:8520268 RTP > Adding session RTP_UDP > 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 Call > GetMediaFormats for > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > GSM-06.10 > G.711-uLaw-64k > G.711-ALaw-64k > H.261(QCIF) > H.261(CIF) > YUV420P > RGB32 > RGB24 > > 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 SIP > Adding authentication information > 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP > Sending PDU on udp$213.203.241.243:5060 > INVITE sip:800@sip.tootai.net SIP/2.0 > Date: Fri, 02 Jun 2006 11:12:32 GMT > CSeq: 2 INVITE > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;rport > User-Agent: Ekiga/2.0.1-20060521-01 > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: > Contact: > Proxy-Authorization: Digest username="104", realm="sip.tootai.net", > nonce="12d01d5d", uri="sip:800@sip.tootai.net", > response="60b65ec9045130eab45495d3c65fbc5e", algorithm=md5 > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE > Content-Type: application/sdp > Content-Length: 302 > Max-Forwards: 70 > > v=0 > o=- 1149246753 1149246753 IN IP4 82.231.69.24 > s=Opal SIP Session > c=IN IP4 82.231.69.24 > t=0 0 > m=audio 35010 RTP/AVP 101 3 0 8 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=rtpmap:3 GSM/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > m=video 35014 RTP/AVP 31 > a=rtpmap:31 H261/90000 > > 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP PDU > Received on udp$213.203.241.243:5060 > SIP/2.0 100 Trying > CSeq: 2 INVITE > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 > User-Agent: Asterisk PBX > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: > Contact: > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > Content-Length: 0 > > > 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP > Queueing PDU: 2 INVITE <100> > 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP > Waiting for PDU on udp$213.203.241.243:5060 > 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP > Handling PDU 2 INVITE <100> (with transaction) > 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP > Transaction 2 INVITE proceeding. > 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Set > targetAddress to sip:800@213.203.241.243 > 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP > Received Trying response > 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP > Media session port=7166 > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP > Adding media session with 2 formats > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP > Unknown media attribute silenceSupp:off - - - - > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SIP PDU > Received on udp$213.203.241.243:5060 > SIP/2.0 200 OK > CSeq: 2 INVITE > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 > User-Agent: Asterisk PBX > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: ;tag=as5d2831d1 > Contact: > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > Content-Type: application/sdp > Content-Length: 221 > > v=0 > o=root 26912 26912 IN IP4 213.203.241.243 > s=session > c=IN IP4 213.203.241.243 > t=0 0 > m=audio 7166 RTP/AVP 0 101 > a=rtpmap:0 PCMU/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=silenceSupp:off - - - - > > 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP > Queueing PDU: 2 INVITE <200> > 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP > Waiting for PDU on udp$213.203.241.243:5060 > 2006/06/02 13:12:33.388 0:11.148 SIP Handler:8520268 SIP > Handling PDU 2 INVITE <200> (with transaction) > 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP > Transaction 2 INVITE completed. > 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP Set > targetAddress to sip:800@213.203.241.243 > 2006/06/02 13:12:33.390 0:11.150 SIP Handler:8520268 SIP > Adding authentication information > 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP > Adjusting transport to address udp$213.203.241.243:5060 > 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP > Sending PDU on udp$213.203.241.243:5060 > ACK sip:800@213.203.241.243 SIP/2.0 > CSeq: 2 ACK > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bK6e2ca15b-96f0-da11-8388-000ea6217592;rport > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: ;tag=as5d2831d1 > Contact: > Proxy-Authorization: Digest username="104", realm="sip.tootai.net", > nonce="12d01d5d", uri="sip:800@213.203.241.243", > response="059defd67706254552a5c23eada565b5", algorithm=md5 > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE > Content-Length: 0 > Max-Forwards: 70 > > > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP > Received INVITE OK response > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 SIP RTP > payload type PCMU matched to codec G.711-uLaw-64k > 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k > 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 OpalCon > OpenSourceMediaStream for session 1 on Call[1]-EP[Default] > 2006/06/02 13:12:33.398 0:11.158 SIP Handler:8520268 OpalCon > Selected media stream PCM-16 -> G.711-uLaw-64k > 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 OpalMan > OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 Call > PatchMediaStreams Call[1]-EP[Default] > 2006/06/02 13:12:34.196 0:11.957 SIP Handler:8520268 OpalCon > OpenSinkMediaStream > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session=1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon > OpenSinkMediaStream, selected PCM-16 -> G.711-uLaw-64k > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:34.197 0:11.958 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 OpalMan > OnOpenMediaStream > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Patch > Added sink > from PCM-16 > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 16 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > to G.711-uLaw-64k > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 8 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > > 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Codec > G711-uLaw-64k encoder created > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Patch > Added media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k using > transcoder PCM-16->G.711-uLaw-64k > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Media > Audio source data size set to 320 bytes and 2 buffers. > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call > GetOtherPartyConnection > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon > OpenSourceMediaStream for session 1 on > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon > Selected media stream G.711-uLaw-64k -> PCM-16 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalMan > OnOpenMediaStream > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 Call > PatchMediaStreams > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon > OpenSinkMediaStream Call[1]-EP[Default] session=1 > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon > OpenSinkMediaStream, selected G.711-uLaw-64k -> PCM-16 > 2006/06/02 13:12:34.513 0:12.274 SIP Handler:8520268 OpalMan > OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:34.514 0:12.274 SIP Handler:8520268 Patch > Added sink > from G.711-uLaw-64k > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 8 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > to PCM-16 > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 16 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Codec > G711-uLaw-64k decoder created > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Media > Audio sink data size set to 320 bytes and 2 buffers. > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Patch > Added media stream sink OpalAudioMediaStream-Sink-PCM-16 using > transcoder G.711-uLaw-64k->PCM-16 > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.525 0:12.285 SIP Handler:8520268 OpalCon > OpenSourceMediaStream (already opened) for session 1 on > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.527 0:12.287 SIP Handler:8520268 RTP_UDP > SetRemoteSocketInfo: session=1 data channel, new=213.203.241.243:7166, > local=82.231.69.24:35010-35011, remote=0.0.0.0:0-0 > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 SIP > Could not find SDP media description for Video > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 OpalMan > OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 Call > OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 PCSS > SetConnected() > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 > GMPCSSEndpoint PCSS connection established > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 > GMManager Will establish the connection > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 OpalMan > OnEstablished Call[1]-EP[Default] > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 Call > OnEstablished Call[1]-EP[Default] > 2006/06/02 13:12:34.540 0:12.300 SIP Handler:8520268 Call > GetMediaFormats for Call[1]-EP[Default] > G.711-uLaw-64k > > 2006/06/02 13:12:34.541 0:12.301 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k > 2006/06/02 13:12:34.542 0:12.302 SIP Handler:8520268 OpalCon > OpenSourceMediaStream (already opened) for session 1 on > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.543 0:12.303 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call > GetMediaFormats for > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > G.711-uLaw-64k > > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 OpalCon > OpenSourceMediaStream (already opened) for session 1 on > Call[1]-EP[Default] > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k > 2006/06/02 13:12:34.552 0:12.312 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k > 2006/06/02 13:12:34.553 0:12.313 Media Patch:8175708 Patch > Thread started for Patch OpalAudioMediaStream-Source-PCM-16 -> > OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:34.556 0:12.316 SIP Handler:8520268 Media > Starting thread Media Patch:8175708 > 2006/06/02 13:12:34.557 0:12.317 Media Patch:8527348 Patch > Thread started for Patch OpalRTPMediaStream-Source-G.711-uLaw-64k -> > OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:34.568 0:12.329 Media Patch:8527348 RTP > Jitter buffer created: size=101 delay=160-4000/160 (20ms) obj=0x8526b30 > 2006/06/02 13:12:34.572 0:12.333 RTP Jitter:8526b30 RTP > Jitter RTP receive thread started: 0x8526b30 > 2006/06/02 13:12:34.574 0:12.334 RTP Jitter:8526b30 RTP > First receive data: ver=2 pt=GSM psz=33 m=0 x=0 seq=39915 ts=160 > src=824302623 ccnt=0 > 2006/06/02 13:12:34.580 0:12.341 SIP Handler:8520268 Media > Starting thread Media Patch:8527348 > 2006/06/02 13:12:34.581 0:12.341 SIP Handler:8520268 OpalCon > Media stream threads started. > 2006/06/02 13:12:34.582 0:12.342 SIP Handler:8520268 OpalCon > Media stream threads started. > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP > Found existing session 2 > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 > GMManager Will establish the connection > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 OpalMan > OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.607 0:12.367 SIP Handler:8520268 Call > OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.610 0:12.371 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:34.648 0:12.408 Media Patch:8527348 RTP > Jitter buffer length exceeded > 2006/06/02 13:12:34.649 0:12.409 Media Patch:8527348 RTP > Jitter buffer length exceed was prior to first write. Not increasing > buffer size > 2006/06/02 13:12:35.277 0:13.037 Media Patch:8175708 RTP > First sent data: ver=2 pt=PCMU psz=160 m=1 x=0 seq=1460 ts=0 > src=703395120 ccnt=0 > 2006/06/02 13:12:35.608 0:13.368 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:35.609 0:13.369 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:36.137 0:13.898 RTP Jitter:8526b30 RTP > Receive statistics: packets=101 octets=3714 lost=0 tooLate=0 order=0 > avgTime=15 maxTime=1556 minTime=0 jitter=16 maxJitter=188 > 2006/06/02 13:12:36.573 0:14.333 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (9760) > 2006/06/02 13:12:36.614 0:14.374 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:36.615 0:14.375 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:36.974 0:14.734 RTP Jitter:8526b30 RTP > Jitter buffer continuously full, throwing away entire buffer. > 2006/06/02 13:12:36.995 0:14.756 RTP Jitter:8526b30 RTP > Jitter buffer full, threw away 21 oldest frames > 2006/06/02 13:12:37.374 0:15.134 RTP Jitter:8526b30 RTP > Receive statistics: packets=201 octets=19714 lost=0 tooLate=0 order=0 > avgTime=12 maxTime=23 minTime=0 jitter=0 maxJitter=188 > 2006/06/02 13:12:37.620 0:15.380 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:37.621 0:15.381 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:37.820 0:15.580 Media Patch:8175708 RTP > Transmit statistics: packets=101 octets=16160 avgTime=25 maxTime=48 > minTime=23 > 2006/06/02 13:12:38.624 0:16.384 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:38.625 0:16.385 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:38.993 0:16.753 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (29120) > 2006/06/02 13:12:39.374 0:17.134 RTP Jitter:8526b30 RTP > Receive statistics: packets=301 octets=35714 lost=0 tooLate=0 order=0 > avgTime=20 maxTime=26 minTime=14 jitter=1 maxJitter=188 > 2006/06/02 13:12:39.395 0:17.155 RTP Jitter:8526b30 RTP > Jitter buffer continuously full, throwing away entire buffer. > 2006/06/02 13:12:39.415 0:17.176 RTP Jitter:8526b30 RTP > Jitter buffer full, threw away 21 oldest frames > 2006/06/02 13:12:39.632 0:17.392 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:39.633 0:17.393 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:40.384 0:18.144 Media Patch:8175708 RTP > Transmit statistics: packets=201 octets=32160 avgTime=25 maxTime=44 > minTime=22 > 2006/06/02 13:12:40.640 0:18.400 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:40.641 0:18.401 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:41.373 0:19.133 RTP Jitter:8526b30 RTP > Receive statistics: packets=401 octets=51714 lost=0 tooLate=0 order=0 > avgTime=19 maxTime=26 minTime=13 jitter=1 maxJitter=188 > 2006/06/02 13:12:41.413 0:19.173 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (48480) > 2006/06/02 13:12:41.648 0:19.424 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:41.665 0:19.425 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:41.813 0:19.573 RTP Jitter:8526b30 RTP > Jitter buffer continuously full, throwing away entire buffer. > 2006/06/02 13:12:41.833 0:19.593 RTP Jitter:8526b30 RTP > Jitter buffer full, threw away 21 oldest frames > 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:42.920 0:20.680 Media Patch:8175708 RTP > Transmit statistics: packets=301 octets=48160 avgTime=25 maxTime=49 > minTime=22 > 2006/06/02 13:12:43.378 0:21.139 RTP Jitter:8526b30 RTP > Receive statistics: packets=501 octets=67714 lost=0 tooLate=0 order=0 > avgTime=20 maxTime=27 minTime=12 jitter=1 maxJitter=188 > 2006/06/02 13:12:43.696 0:21.457 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:43.697 0:21.457 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot Call > Clearing Call[1] reason=EndedByLocalUser > 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot OpalCon > Releasing Call[1]-EP[Default] > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > Call end reason for Default set to EndedByLocalUser > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > SetPhase from EstablishedPhase to ReleasingPhase > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > Releasing Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > Call end reason for fa44075b-96f0-da11-8388-000ea6217592@nomade set to > EndedByLocalUser > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > SetPhase from EstablishedPhase to ReleasingPhase > 2006/06/02 13:12:43.820 0:21.581 OnRelease:856e8a0 OpalCon > OnReleased Call[1]-EP[Default] > 2006/06/02 13:12:43.822 0:21.583 OnRelease:856e8a0 Media > Closing raw media stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.824 0:21.584 OnRelease:856e8a0 Media > Closing stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.825 0:21.585 OnRelease:856e8a0 Media > Disconnecting OpalAudioMediaStream-Source-PCM-16 from patch thread Patch > OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.827 0:21.587 OnRelease:856e8a0 Patch > Closing media patch Patch OpalAudioMediaStream-Source-PCM-16 -> > OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.829 0:21.589 OnRelease:856e8a0 Media > Closing raw media stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.830 0:21.590 OnRelease:856e8a0 Media > Closing stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.831 0:21.591 OnRelease:84f8c00 SIP > OnReleased: > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade], phase = > ReleasingPhase > 2006/06/02 13:12:43.833 0:21.593 OnRelease:84f8c00 OpalCon > SetPhase from ReleasingPhase to ReleasingPhase > 2006/06/02 13:12:43.834 0:21.594 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (67840) > 2006/06/02 13:12:43.836 0:21.596 OnRelease:84f8c00 SIP > Transaction 4 BYE created. > 2006/06/02 13:12:43.842 0:21.603 OnRelease:84f8c00 Media > Closing RTP for OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.844 0:21.604 OnRelease:84f8c00 RTP_UDP > Session 1, Shutting down write. > 2006/06/02 13:12:43.845 0:21.605 OnRelease:84f8c00 Media > Closing stream OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.846 0:21.606 OnRelease:84f8c00 Media > Disconnecting OpalRTPMediaStream-Sink-G.711-uLaw-64k from patch thread > Patch OpalAudioMediaStream-Source-PCM-16 -> > OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.848 0:21.609 OnRelease:84f8c00 Patch > Removing media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.855 0:21.626 OnRelease:84f8c00 Media > Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.867 0:21.627 OnRelease:84f8c00 RTP_UDP > Session 1, Shutting down read. > 2006/06/02 13:12:43.868 0:21.628 OnRelease:84f8c00 Media > Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.869 0:21.630 OnRelease:84f8c00 Media > Disconnecting OpalRTPMediaStream-Source-G.711-uLaw-64k from patch thread > Patch OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.893 0:21.653 Media Patch:8175708 Patch > Thread ended for Patch OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.893 0:21.653 OnRelease:84f8c00 Patch > Closing media patch Patch OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.916 0:21.676 RTP Jitter:8526b30 RTP_UDP > Session 1, Read shutdown. > 2006/06/02 13:12:43.917 0:21.677 RTP Jitter:8526b30 RTP > Jitter RTP receive thread ended > 2006/06/02 13:12:43.917 0:21.677 OnRelease:84f8c00 Media > Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.918 0:21.678 OnRelease:84f8c00 RTP_UDP > Session 1, Shutting down read. > 2006/06/02 13:12:43.919 0:21.679 OnRelease:84f8c00 Media > Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.922 0:21.683 OnRelease:856e8a0 Patch > Waiting for media patch thread to stop Patch > OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.926 0:21.686 OnRelease:856e8a0 Patch > Media patch thread Patch OpalAudioMediaStream-Source-PCM-16 destroyed. > 2006/06/02 13:12:43.930 0:21.691 OnRelease:856e8a0 Media > Closing raw media stream OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:43.932 0:21.693 OnRelease:856e8a0 Media > Closing stream OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:43.933 0:21.694 OnRelease:856e8a0 Media > Disconnecting OpalAudioMediaStream-Sink-PCM-16 from patch thread Patch > OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.956 0:21.717 OnRelease:856e8a0 Patch > Removing media stream sink OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:45.696 0:23.456 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:45.697 0:23.457 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:48.708 0:26.468 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:48.709 0:26.469 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:50.712 0:28.473 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:50.713 0:28.473 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:51.716 0:29.477 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:51.717 0:29.477 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:52.716 0:30.477 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:52.717 0:30.477 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:57.733 0:35.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:57.734 0:35.494 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:02.777 0:40.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:02.778 0:40.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:04.369 0:42.129 Housekeeper SIP Set > state Terminated_Success for transaction 1 INVITE > 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:05.777 0:43.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:05.777 0:43.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:06.613 0:44.374 Housekeeper SIP Set > state Terminated_Success for transaction 2 INVITE > 2006/06/02 13:13:06.777 0:44.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:06.778 0:44.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:07.777 0:45.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:07.778 0:45.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP > Found existing session 2 > Processus arrêté > -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From devel@tootai.net Sat Jun 3 19:25:05 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EBBDB3B06DD for ; Sat, 3 Jun 2006 19:24:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02787-06 for ; Sat, 3 Jun 2006 19:24:40 -0400 (EDT) Received: from mail1.tootai.net (ns1.tootai.net [82.231.69.24]) by menubar.gnome.org (Postfix) with ESMTP id 16D123B0756 for ; Sat, 3 Jun 2006 19:24:35 -0400 (EDT) Received: from [192.168.0.17] (unknown [192.168.0.17]) by mail1.tootai.net (Postfix) with ESMTP id 9C142398B99 for ; Sun, 4 Jun 2006 01:24:35 +0200 (CEST) Message-ID: <44821A19.10001@tootai.net> Date: Sun, 04 Jun 2006 01:24:09 +0200 From: Daniel Huhardeaux Organization: TOOTAi User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 References: <4481A6AF.2060703@tootai.net> <1149357648.2414.34.camel@golgoth01> In-Reply-To: <1149357648.2414.34.camel@golgoth01> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[AWL=0.000, BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 23:25:05 -0000 Damien Sandras wrote: > [...] >> When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is >> started, connection is showed with PCMU (why not GSM?), see the traffic >> in/out (~6 kB) but have no audio. >> >> > > Asterisk answers with 200 OK indicating that the call should be done > with PCMU. > Ok, but as GSM has my preference in Ekiga as well as in asterisk, the call should be done in GSM > [...] > > Please try with 2.0.2. Craig has done work in CVS and things are > potentially broken. If the problem persists once plugins support is in > CVS, please report again. > I use the Ekiga snapshot SID version which don't provide newest version as the one mentioned :-( Kilian? BTW, asterisk is 1.2-r16008 from 29/03/2006 - SVN stable. > > >> If I deactivate GSM codec, everything is fine. Below you will find a d4 >> output from the call. >> >> > > I do not think activating GSM or not has any influence. The problem is > probably something else. > I would like to believe you, but this problem happends only with GSM codec. -- Daniel From ebischoff@nerim.net Sun Jun 4 11:52:03 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C970B3B011B for ; Sun, 4 Jun 2006 11:52:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26992-10 for ; Sun, 4 Jun 2006 11:52:01 -0400 (EDT) Received: from mallaury.nerim.net (smtp-100-sunday.noc.nerim.net [62.4.17.100]) by menubar.gnome.org (Postfix) with ESMTP id 9601A3B00CE for ; Sun, 4 Jun 2006 11:52:01 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by mallaury.nerim.net (Postfix) with ESMTP id 32E474F399 for ; Sun, 4 Jun 2006 17:51:50 +0200 (CEST) From: =?iso-8859-1?q?=C9ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Sun, 4 Jun 2006 17:52:11 +0200 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606041752.12228.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.535 tagged_above=-999 required=2 tests=[AWL=0.064, BAYES_00=-2.599] X-Spam-Score: -2.535 X-Spam-Level: Subject: [GnomeMeeting-devel-list] KDE address book support in Ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 15:52:04 -0000 (this message has already been sent by mistake on gnomemeeting-list a few=20 hours ago, sorry for the crossposting) Hi everyone, A small notice to let you know that I am working on adding support for KDE= =20 Address Book (kab) to Ekiga. I already have some early "proof of concept"=20 code working (see screenshot at=20 http://opensource.bureau-cornavin.com/ekiga/screenshot.png). KDE Address Book is an application of its own, but it's also a library that= is=20 used by most KDE applications (KMail, Kontact, KPilot, Kopete, ...), and al= so=20 by third-party applications like OpenOffice.org. It can use several=20 "resources" for its addresses: local VCard files, remote LDAP servers, etc. Before anyone does the remark : YES it would be better if Evolution/GNOME a= nd=20 KDE shared the same address book library. But currently we have to live wit= h=20 this situation... There are two issues that currently slow me down a bit: 1) Ekiga's address book model distinguishes between "local" and "remote"=20 address books. This makes little sense for kab which can transparently use= =20 both local and remote resources. In a first time, my code will act as a=20 "local" address book, just like Evolution address book. 2) KDE address book currently has no field for SIP nor H323 addresses. I am= =20 currently trying to contact Will Stephenson (KDE) who added support for Sky= pe=20 addresses to see how we could do that cleanly. Of course, this functionality will remain optional and require no library f= or=20 those who can live without it :-). Any suggestion, wish, encouragement, criticism, and/or offer for help is=20 welcome. Hoping that helps, =2D-=20 =C9ric From jpuydt@free.fr Sun Jun 4 12:08:13 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C97F03B009F; Sun, 4 Jun 2006 12:08:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28175-05; Sun, 4 Jun 2006 12:08:00 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 880B03B0187; Sun, 4 Jun 2006 12:08:00 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-54-82-251-83-65.adsl.proxad.net [82.251.83.65]) by smtp5-g19.free.fr (Postfix) with ESMTP id 3EBD2250F8; Sun, 4 Jun 2006 18:07:59 +0200 (CEST) Message-ID: <44830581.8080503@free.fr> Date: Sun, 04 Jun 2006 18:08:33 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting mailing list , GnomeMeeting development mailing list References: <200606041116.31785.ebischoff@nerim.net> In-Reply-To: <200606041116.31785.ebischoff@nerim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: Cc: Subject: [GnomeMeeting-devel-list] Re: [GnomeMeeting-list] KDE address book support in Ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 16:08:14 -0000 Éric Bischoff a écrit : > A small notice to let you know that I am working on adding support for KDE > Address Book (kab) to Ekiga. I already have some early "proof of concept" > code working (see screenshot at > http://opensource.bureau-cornavin.com/ekiga/screenshot.png). I know :-) > KDE Address Book is an application of its own, but it's also a library that is > used by most KDE applications (KMail, Kontact, KPilot, Kopete, ...), and also > by third-party applications like OpenOffice.org. It can use several > "resources" for its addresses: local VCard files, remote LDAP servers, etc. Nice. > Before anyone does the remark : YES it would be better if Evolution/GNOME and > KDE shared the same address book library. But currently we have to live with > this situation... Indeed. > There are two issues that currently slow me down a bit: > > 1) Ekiga's address book model distinguishes between "local" and "remote" > address books. This makes little sense for kab which can transparently use > both local and remote resources. In a first time, my code will act as a > "local" address book, just like Evolution address book. I'm refactoring the addressbook ; and I don't like that distinction either. I'm still trying to convince Damien and Jan my ideas can fly. I think Jan is already beginning to see where I go ; Damien hasn't had the time to dive into it. > 2) KDE address book currently has no field for SIP nor H323 addresses. I am > currently trying to contact Will Stephenson (KDE) who added support for Skype > addresses to see how we could do that cleanly. Ok. > Of course, this functionality will remain optional and require no library for > those who can live without it :-). Ok too. We'll go with a --enable-kde at compile time. Then later on we'll see if it's possible to do something at runtime. > Any suggestion, wish, encouragement, criticism, and/or offer for help is > welcome. * Suggestion: use -devel-list ;-) * Wish: what you have written will work well with what I have in mind * Encouragement: I like the idea very much, and appreciate your working on ekiga * Criticism: couldn't you do that either long before or just after the re-architecturing? ;-) * Offer for help: uh... I'm refactoring, and it may help (the api I ask from "addressbooks" is much lighter). Snark on #ekiga From ebischoff@nerim.net Sun Jun 4 12:36:03 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6EBCD3B00E9 for ; Sun, 4 Jun 2006 12:36:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29967-09 for ; Sun, 4 Jun 2006 12:36:02 -0400 (EDT) Received: from kraid.nerim.net (smtp-100-sunday.nerim.net [62.4.16.100]) by menubar.gnome.org (Postfix) with ESMTP id 16E7B3B009F for ; Sun, 4 Jun 2006 12:36:01 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id C772E40E31 for ; Sun, 4 Jun 2006 18:35:59 +0200 (CEST) From: =?iso-8859-1?q?=C9ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Re: [GnomeMeeting-list] KDE address book support in Ekiga Date: Sun, 4 Jun 2006 18:36:11 +0200 User-Agent: KMail/1.8.2 References: <200606041116.31785.ebischoff@nerim.net> <44830581.8080503@free.fr> In-Reply-To: <44830581.8080503@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606041836.12390.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.553 tagged_above=-999 required=2 tests=[AWL=0.046, BAYES_00=-2.599] X-Spam-Score: -2.553 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 16:36:03 -0000 Le Dimanche 4 Juin 2006 18:08, Julien PUYDT a =E9crit=A0: > I know :-) I know you know ;-). > I'm refactoring the addressbook ; and I don't like that distinction > either. I'm still trying to convince Damien and Jan my ideas can fly. I > think Jan is already beginning to see where I go ; Damien hasn't had the > time to dive into it. Okay, I have not written much code yet, so there will be no problem to adap= t=20 it to your new layout, whatever it will be. > Ok too. We'll go with a --enable-kde at compile time. Then later on > we'll see if it's possible to do something at runtime. Yes, I was figuring out something like that. > * Suggestion: use -devel-list ;-) Yup, sorry... :-/ > * Wish: what you have written will work well with what I have in mind See above, I have not written much yet, and it's "obvious" code anyway, so= =20 there's no problem even if I have to restart from scratch. > * Encouragement: I like the idea very much, and appreciate your working > on ekiga Thank you for the warm welcome, Julien :-). > * Criticism: couldn't you do that either long before or just after the > re-architecturing? ;-) No. Did you hear about Murphy's law ? ;-) > * Offer for help: uh... I'm refactoring, and it may help (the api I ask > from "addressbooks" is much lighter). Indeed. =2D-=20 =C9ric From dsandras@seconix.com Mon Jun 5 15:24:19 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 115A33B038A for ; Mon, 5 Jun 2006 15:24:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24872-10 for ; Mon, 5 Jun 2006 15:24:15 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 482C73B0420 for ; Mon, 5 Jun 2006 15:24:15 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 73E6049870 for ; Mon, 5 Jun 2006 21:07:08 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23599-08 for ; Mon, 5 Jun 2006 21:06:52 +0200 (CEST) Received: from [192.168.0.161] (39.128-245-81.adsl-dyn.isp.belgacom.be [81.245.128.39]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 4C3C84986E for ; Mon, 5 Jun 2006 21:06:52 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44821A19.10001@tootai.net> References: <4481A6AF.2060703@tootai.net> <1149357648.2414.34.camel@golgoth01> <44821A19.10001@tootai.net> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 05 Jun 2006 21:24:50 +0200 Message-Id: <1149535490.2508.3.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.455 tagged_above=-999 required=2 tests=[AWL=0.009, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.455 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 19:24:19 -0000 Le dimanche 04 juin 2006 à 01:24 +0200, Daniel Huhardeaux a écrit : > Damien Sandras wrote: > > [...] > >> When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is > >> started, connection is showed with PCMU (why not GSM?), see the traffic > >> in/out (~6 kB) but have no audio. > >> > >> > > > > Asterisk answers with 200 OK indicating that the call should be done > > with PCMU. > > > Ok, but as GSM has my preference in Ekiga as well as in asterisk, the > call should be done in GSM I agree, but if you look at the 200 OK sent by Asterisk, GSM is not part of it, while it is part of the INVITE sent by Ekiga. > > I do not think activating GSM or not has any influence. The problem is > > probably something else. > > > I would like to believe you, but this problem happends only with GSM codec. Is there some way I could reproduce it here? -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Mon Jun 5 17:45:53 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 776D43B03A0; Mon, 5 Jun 2006 17:45:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02457-06; Mon, 5 Jun 2006 17:45:52 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 22F123B0295; Mon, 5 Jun 2006 17:45:52 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 8C0904984F; Mon, 5 Jun 2006 23:28:44 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29850-10; Mon, 5 Jun 2006 23:28:37 +0200 (CEST) Received: from [192.168.0.161] (39.128-245-81.adsl-dyn.isp.belgacom.be [81.245.128.39]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 089E44984C; Mon, 5 Jun 2006 23:28:36 +0200 (CEST) From: Damien Sandras To: gnomemeeting-list@gnome.org Content-Type: text/plain Date: Mon, 05 Jun 2006 23:46:32 +0200 Message-Id: <1149543992.2508.40.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.455 tagged_above=-999 required=2 tests=[AWL=0.009, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.455 X-Spam-Level: Cc: gnomemeeting-devel-list@gnome.org Subject: [GnomeMeeting-devel-list] Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 21:45:53 -0000 Hello to all, Ekiga 2.0.2 is available on http://www.ekiga.org More packages will be added as they are released. Thanks a lot to all supporters of the project! -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From simon@mungewell.org Mon Jun 5 18:20:27 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1BD3C3B0389 for ; Mon, 5 Jun 2006 18:20:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04790-06 for ; Mon, 5 Jun 2006 18:20:25 -0400 (EDT) Received: from pd3mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by menubar.gnome.org (Postfix) with ESMTP id 864BD3B04F7 for ; Mon, 5 Jun 2006 18:20:25 -0400 (EDT) Received: from pd3mr3so.prod.shaw.ca (pd3mr3so-qfe3.prod.shaw.ca [10.0.141.179]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0E00FK5RE0KD10@l-daemon> for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:20:24 -0600 (MDT) Received: from pn2ml4so.prod.shaw.ca ([10.0.121.148]) by pd3mr3so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0E002HJRE0FOB0@pd3mr3so.prod.shaw.ca> for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:20:24 -0600 (MDT) Received: from slone.mungewell.org ([68.146.98.7]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0E00GPGRE0XH60@l-daemon> for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:20:24 -0600 (MDT) Received: from simon by slone.mungewell.org with local (Exim 4.61) (envelope-from ) id 1FnNDw-0002Wd-6Y for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:07:00 -0600 Date: Mon, 05 Jun 2006 16:07:00 -0600 From: simon Subject: Re: [GnomeMeeting-devel-list] Ekiga 2.0.2 In-reply-to: <1149543992.2508.40.camel@golgoth01> To: GnomeMeeting development mailing list Message-id: <20060605220700.GA9699@mungewell.org> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline References: <1149543992.2508.40.camel@golgoth01> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[AWL=-0.000, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 22:20:27 -0000 On Mon, Jun 05, 2006 at 11:46:32PM +0200, Damien Sandras wrote: > Hello to all, > > > Ekiga 2.0.2 is available on http://www.ekiga.org > Woo Woo another release party! What only a '.' release - oh, guess we'll have to share a can of Pop ;-) Seriously though, Thanks to Damien and all the other developers. Simon From siti@orcon.net.nz Tue Jun 6 05:25:31 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5963D3B00EF for ; Tue, 6 Jun 2006 05:25:31 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29810-06 for ; Tue, 6 Jun 2006 05:25:29 -0400 (EDT) Received: from dbmail-mx2.orcon.net.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id AB0663B00E2 for ; Tue, 6 Jun 2006 05:25:28 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx2.orcon.net.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k569PFih007843 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Jun 2006 21:25:16 +1200 Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Stephen Cook To: Derek Smithies In-Reply-To: References: Content-Type: text/plain Date: Tue, 06 Jun 2006 21:25:24 +1200 Message-Id: <1149585924.16149.8.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx2.orcon.net.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.532 tagged_above=-999 required=2 tests=[AWL=0.068, BAYES_00=-2.599] X-Spam-Score: -2.532 X-Spam-Level: Cc: GnomeMeeting development mailing list X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 09:25:31 -0000 On Tue, 2006-06-06 at 10:32 +1200, Derek Smithies wrote: > Hi, > Ok, just back from a long weekend (three days of not touching a computer) > and back into things. > > Stephen, I saw some comment from you on this topic at: > > http://siti.geek.nz/web/content/blogsection/4/26/ > > interesting - very interesting.. > > hey - now that is a coincidence. > I studied at Canterbury University also. Well that's cool :) Could you send me a private email with an instant messaging address that you use. BTW Damien and others we will keep as much information on the mailing list. To give you guys an update I have IAX2 calls going in ekiga although it needs a lot of work :). Then obviously the improvements to IAX2 in opal... > > > ============== > > Craig, I do not think moving to an offline conversation with Stephen is > > a good idea. Julien and myself are supposed to mentor the project. Your > > help is of course welcome, but we have to be kept informed. > Sorry Damien, but there will be a lot of offline comment. > I suspect that Stephen and I live in the same city. Sending a CC of phone > conversations etc will not be easy. > > I will endeavour though to keep you informed of what is happening, and we > can move everything forward towards the nirvana of iax2, sip, and h323 in > gnomemeeting. > > > =========================== > > Stephen, > > I am really happy to work with you on IAX2 - really happy. This > would be great for the project. It should be a good learning experience for me and I am sure it'll be good fun :) From dsandras@seconix.com Tue Jun 6 05:29:32 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 40D9E3B0A68 for ; Tue, 6 Jun 2006 05:29:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30841-02 for ; Tue, 6 Jun 2006 05:29:30 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 9F34C3B0A5C for ; Tue, 6 Jun 2006 05:29:30 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id DDF8E493CB; Tue, 6 Jun 2006 11:12:16 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30209-02; Tue, 6 Jun 2006 11:11:57 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 679F9492DA; Tue, 6 Jun 2006 11:11:57 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: Stephen Cook In-Reply-To: <1149585924.16149.8.camel@siti> References: <1149585924.16149.8.camel@siti> Content-Type: text/plain; charset=ISO-8859-15 Date: Tue, 06 Jun 2006 11:29:17 +0200 Message-Id: <1149586157.2470.27.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Cc: Derek Smithies , GnomeMeeting development mailing list X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 09:29:32 -0000 Le mardi 06 juin 2006 à 21:25 +1200, Stephen Cook a écrit : > On Tue, 2006-06-06 at 10:32 +1200, Derek Smithies wrote: > > Hi, > > Ok, just back from a long weekend (three days of not touching a computer) > > and back into things. > > > > Stephen, I saw some comment from you on this topic at: > > > > http://siti.geek.nz/web/content/blogsection/4/26/ > > > > interesting - very interesting.. > > > > hey - now that is a coincidence. > > I studied at Canterbury University also. > Well that's cool :) > > Could you send me a private email with an instant messaging address that > you use. > > BTW Damien and others we will keep as much information on the mailing > list. > > To give you guys an update I have IAX2 calls going in ekiga although it > needs a lot of work :). Then obviously the improvements to IAX2 in > opal... > Excellent ;-) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From jpuydt@free.fr Tue Jun 6 06:41:15 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 18B6B3B00E0 for ; Tue, 6 Jun 2006 06:41:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10263-10 for ; Tue, 6 Jun 2006 06:41:14 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id BD54A3B00D2 for ; Tue, 6 Jun 2006 06:41:13 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-57-82-249-29-56.adsl.proxad.net [82.249.29.56]) by smtp1-g19.free.fr (Postfix) with ESMTP id 909369AAC7 for ; Tue, 6 Jun 2006 12:41:12 +0200 (CEST) Message-ID: <44855BEC.1040306@free.fr> Date: Tue, 06 Jun 2006 12:41:48 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga References: <1149585924.16149.8.camel@siti> In-Reply-To: <1149585924.16149.8.camel@siti> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.585 tagged_above=-999 required=2 tests=[AWL=0.014, BAYES_00=-2.599] X-Spam-Score: -2.585 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 10:41:15 -0000 Stephen Cook a écrit : > Could you send me a private email with an instant messaging address that > you use. > > BTW Damien and others we will keep as much information on the mailing > list. > > To give you guys an update I have IAX2 calls going in ekiga although it > needs a lot of work :). Then obviously the improvements to IAX2 in > opal... This sounds great :-) Do all codecs work ok ? Could you make a short list of what is lacking, so your progress can easily be seen ? :-) Snark From siti@orcon.net.nz Tue Jun 6 08:02:29 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0E2D93B008B for ; Tue, 6 Jun 2006 08:02:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19082-05 for ; Tue, 6 Jun 2006 08:02:18 -0400 (EDT) Received: from dbmail-mx3.orcon.co.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 7C3DD3B0A9D for ; Tue, 6 Jun 2006 08:01:24 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx3.orcon.co.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k56C17Ej021180 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 7 Jun 2006 00:01:12 +1200 Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Stephen Cook To: GnomeMeeting development mailing list In-Reply-To: <44855BEC.1040306@free.fr> References: <1149585924.16149.8.camel@siti> <44855BEC.1040306@free.fr> Content-Type: text/plain; charset=utf-8 Date: Wed, 07 Jun 2006 00:01:17 +1200 Message-Id: <1149595277.17468.7.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx3.orcon.co.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.495 tagged_above=-999 required=2 tests=[AWL=-0.031, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.495 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 12:02:29 -0000 On Tue, 2006-06-06 at 12:41 +0200, Julien PUYDT wrote: > Stephen Cook a écrit : > > Could you send me a private email with an instant messaging address that > > you use. > > > > BTW Damien and others we will keep as much information on the mailing > > list. > > > > To give you guys an update I have IAX2 calls going in ekiga although it > > needs a lot of work :). Then obviously the improvements to IAX2 in > > opal... > > This sounds great :-) > > Do all codecs work ok ? I have only tried ULAW > > Could you make a short list of what is lacking, so your progress can > easily be seen ? In Ekiga: * Url handler for IAX2 * If I have time in the future -- Refactor protocol components in ekiga In Iax2: * Call Hold * Transfer Calls * Register > > :-) > > Snark > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list From jan.schampera@web.de Tue Jun 6 11:41:54 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 300F43B00A7 for ; Tue, 6 Jun 2006 11:41:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01645-10 for ; Tue, 6 Jun 2006 11:41:52 -0400 (EDT) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by menubar.gnome.org (Postfix) with ESMTP id 5016E3B0117 for ; Tue, 6 Jun 2006 11:41:52 -0400 (EDT) Received: from fwd28.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1Fndgj-000497-06; Tue, 06 Jun 2006 17:41:49 +0200 Received: from mail.home.thebonsai.de (SxWWnGZHgenZylg6UcgKDR7M2nKdws-wslY10mn82PtIepb06FcVZ4@[84.147.103.162]) by fwd28.sul.t-online.de with esmtp id 1Fndgc-1VKS9o0; Tue, 6 Jun 2006 17:41:42 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id B18576B0FF for ; Tue, 6 Jun 2006 17:41:40 +0200 (CEST) Date: Tue, 6 Jun 2006 17:37:41 +0200 From: Jan Schampera To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga Message-ID: <20060606173741.7739fbf0@localhost.localdomain> In-Reply-To: <1149595277.17468.7.camel@siti> References: <1149585924.16149.8.camel@siti> <44855BEC.1040306@free.fr> <1149595277.17468.7.camel@siti> Organization: private X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: SxWWnGZHgenZylg6UcgKDR7M2nKdws-wslY10mn82PtIepb06FcVZ4@t-dialin.net X-TOI-MSGID: d621850d-8c24-4c96-bc80-424b3278e7ee X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.966 tagged_above=-999 required=2 tests=[AWL=0.632, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.966 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 15:41:54 -0000 On Wed, 07 Jun 2006 00:01:17 +1200 Stephen Cook wrote: > In Ekiga: > * Url handler for IAX2 > * If I have time in the future -- Refactor protocol components in > ekiga > > In Iax2: > * Call Hold > * Transfer Calls > * Register I X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C93A63B023C for ; Tue, 6 Jun 2006 18:32:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26160-07 for ; Tue, 6 Jun 2006 18:32:35 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by menubar.gnome.org (Postfix) with ESMTP id EE5BE3B0124 for ; Tue, 6 Jun 2006 18:32:34 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x31so57152pye for ; Tue, 06 Jun 2006 15:32:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=PWNZjwnHiPmpdYl2MsXZ9YZF9d4xYPXUg1ADy6s6gr7kpZpuMn+pMk4SiPqw6G91hexsOp1xDFUNDwMZyQ+X01mIY9TDqR0zrylP3BBJTKYCjcgQm4+vLCMe9AVXFuvgQ8NYOFrWwmRpr+zSS1OaVc2h2FssBRFPxlSabyu06bg= Received: by 10.35.76.9 with SMTP id d9mr79929pyl; Tue, 06 Jun 2006 15:32:33 -0700 (PDT) Received: by 10.35.9.3 with HTTP; Tue, 6 Jun 2006 15:32:33 -0700 (PDT) Message-ID: <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> Date: Tue, 6 Jun 2006 18:32:33 -0400 From: "mcquaid mcquaid" To: "GnomeMeeting development mailing list" Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode In-Reply-To: <1149246461.2966.28.camel@golgoth01> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7731_6834590.1149633153798" References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> <1149246461.2966.28.camel@golgoth01> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.041 tagged_above=-999 required=2 tests=[AWL=0.062, BAYES_00=-2.599, HTML_40_50=0.496, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.041 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 22:32:38 -0000 ------=_Part_7731_6834590.1149633153798 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Just a user, I'm curious as to why the trend of throwing opengl at everything. On one hand I think it's really cool, but this isn't like xgl where we want wobbly windows or something, just accelerated video. Isn't that what hardware video overlay is for? It takes a large burden off the cpu for video playback. Would benefit more people as some don't have prope= r opengl drivers. On 6/2/06, Damien Sandras wrote: > > Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit : > > So configure.in is hand-generated? Surprising. > > > > That's te way it works. You write configure.in and configure is > generated from there. I guess you are confusing things here. > > > 1) How exactly do I add the opengl ( libgl ) library? > > > > By writing autconf code in configure.in. No idea exactly how it should > be done. > > > 2) Xrandr is mentioned in the Makefile, but is not in configure.in. Ho= w > > exactly does it get put into the Makefile? > > > > Probably by an external library that we are using. > > > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I didn't wan= t > > to code against a moving target. > > > > Yes. It is even OK if you do not provide the configure.in code, but only > the OpenGL Ekiga code. > > > Thanks, > > > > -Dan > > > > Damien Sandras wrote: > > > > >Le mercredi 31 mai 2006 =E0 12:41 -0700, Dan Sandberg a =E9crit : > > > > > > > > >>I'd imagine it would work on win32, but don't know. > > >> > > >> > > >> > > > > > >Probably. > > > > > > > > > > > >>I'll work on the patches. > > >> > > >>Where's the right place to add required libraries like openGL? > > >> > > >> > > > > > >In configure.in. > > > > > > > > > > > >>configure.in seems to be autogenerated by something, but whatever it > is > > >>doesn't seem to be in the CVS snapshot... > > >> > > >> > > >> > > > > > >configure.in is in the CVS snapshot. > > > > > > > > > > > > > > >>Thanks, > > >> > > >>-Dan > > >> > > >>Julien PUYDT wrote: > > >> > > >> > > >> > > >>>Dan Sandberg a =E9crit : > > >>> > > >>> > > >>> > > >>>>How should we proceed? I could just send you an updated > gui/main.cpp > > >>>>file... > > >>>> > > >>>> > > >>>I'd like to see patches instead of full files, preferably independan= t > > >>>on each others. > > >>> > > >>>There's also the question of the portability of this : since you > > >>>mention SDL, I guess this will work great on win32 too ? > > >>> > > >>>Snark > > >>>_______________________________________________ > > >>>Gnomemeeting-devel-list mailing list > > >>>Gnomemeeting-devel-list@gnome.org > > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >>> > > >>> > > >>> > > >>_______________________________________________ > > >>Gnomemeeting-devel-list mailing list > > >>Gnomemeeting-devel-list@gnome.org > > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >> > > >> > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > -- > _ Damien Sandras > (o- > //\ Ekiga Softphone: http://www.ekiga.org/ > v_/_ FOSDEM 2006 : http://www.fosdem.org/ > SIP Phone : sip:dsandras@ekiga.net > sip:600000@ekiga.net > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > ------=_Part_7731_6834590.1149633153798 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Just a user, I'm curious as to why the trend of throwing opengl at everythi= ng.  On one hand I think it's really cool, but this isn't like xgl whe= re we want wobbly windows or something, just accelerated video.  Isn't= that what hardware video overlay is for?  It takes a large burden off= the cpu for video playback.  Would benefit more people as some don't = have proper opengl drivers.

On 6/2/06, Damien Sandras <dsand= ras@seconix.com> wrote:
Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit :
> = So configure.in is hand-generated? = ; Surprising.
>

That's te way it works. You write configure.in and configure is
generated from there. I guess you are = confusing things here.

> 1) How exactly do I add the opengl ( lib= gl ) library?
>

By writing autconf code in configure.in. No idea exactly how it should
be done.

> 2) = Xrandr is mentioned in the Makefile, but is not in configure.in.  How
> exactly does it get put in= to the Makefile?
>

Probably by an external library that we are using.

&= gt; 3) Is it ok if I send in a patch that is for Ekiga 2.0.1?  I = didn't want
> to code against a moving target.
>

Yes. It= is even OK if you do not provide the=20 configure.in code, but only
the Open= GL Ekiga code.

> Thanks,
>
> -Dan
>
> Dam= ien Sandras wrote:
>
> >Le mercredi 31 mai 2006 =E0 12:41 -0= 700, Dan Sandberg a =E9crit :
> >
> >
> >>I'd imagine it would work on win= 32, but don't know.
> >>
> >>
> >>
&= gt; >
> >Probably.
> >
> >
> >
> >>I'll work on the patches.
> >>
> >>Whe= re's the right place to add required libraries like openGL?
> >>= ;
> >>
> >
> >In configure.in.
> >
> >
> >
> >>configure.in seems to be autogenerated by= something, but whatever it is
> >>doesn't seem to be in the CV= S snapshot...
> >>
> >>
> >>
> >
> &g= t;configure.in is in the CVS snapshot.<= br>> >
> >
> >
> >
> >>Thanks,
> >>
> >>-Dan
> >>
> >>Jul= ien PUYDT wrote:
> >>
> >>
> >>
>= >>>Dan Sandberg a =E9crit :
> >>>
> >>= >
> >>>
> >>>>How should we proceed? &= nbsp;I could just send you an updated gui/main.cpp
> >>>>= file...
> >>>>
> >>>>
> >>&= gt;I'd like to see patches instead of full files, preferably independant
> >>>on each others.
> >>>
> >>&= gt;There's also the question of the portability of this : since you
>= >>>mention SDL, I guess this will work great on win32 too ?
> >>>
> >>>Snark
> >>>___________= ____________________________________
> >>>Gnomemeeting-devel= -list mailing list
> >>> Gnomemeeting-devel-list@gnome.org
> >>>http://mail.gnome= .org/mailman/listinfo/gnomemeeting-devel-list
> >>>
> >>>
> >>>
> >>____________________= ___________________________
> >>Gnomemeeting-devel-list mailing= list
> >> Gnomemeeting-devel-list@gnome.org
> >>http://mail.gnome.org= /mailman/listinfo/gnomemeeting-devel-list
> >>
> >= >
>
> _______________________________________________
> Gn= omemeeting-devel-list mailing list
> Gnomemeeting-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
-- _      Damien Sandras
(o-
//\ &n= bsp;   Ekiga Softphone: http://= www.ekiga.org/
v_/_    FOSDEM 2006  &n= bsp; : http://www.fosdem.org/
       &nb= sp;SIP Phone      : sip:dsandras@ekiga.net
    &nbs= p;            &= nbsp;       sip:600000@ekiga.net

____________________________________= ___________
Gnomemeeting-devel-list mailing list
Gnomemeeting-devel-list@gnome.org
http://mail.= gnome.org/mailman/listinfo/gnomemeeting-devel-list

------=_Part_7731_6834590.1149633153798-- From x@cs.stanford.edu Tue Jun 6 18:47:00 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5D25C3B036D for ; Tue, 6 Jun 2006 18:46:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26984-04 for ; Tue, 6 Jun 2006 18:46:56 -0400 (EDT) Received: from smtp104.plus.mail.mud.yahoo.com (smtp104.plus.mail.mud.yahoo.com [68.142.206.237]) by menubar.gnome.org (Postfix) with SMTP id 502483B0124 for ; Tue, 6 Jun 2006 18:46:56 -0400 (EDT) Received: (qmail 87952 invoked from network); 6 Jun 2006 22:46:55 -0000 Received: from unknown (HELO ?192.168.2.47?) (dan?sandberg@71.138.128.214 with plain) by smtp104.plus.mail.mud.yahoo.com with SMTP; 6 Jun 2006 22:46:54 -0000 Message-ID: <448605B0.6080504@cs.stanford.edu> Date: Tue, 06 Jun 2006 15:46:08 -0700 From: Dan Sandberg User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> <1149246461.2966.28.camel@golgoth01> <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> In-Reply-To: <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.808 tagged_above=-999 required=2 tests=[AWL=-0.593, BAYES_00=-2.599, SPF_SOFTFAIL=1.384] X-Spam-Score: -1.808 X-Spam-Level: Cc: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 22:47:00 -0000 I could be wrong, but I believe that video overlay moves the data direct from a capture card to the video card, bypassing the CPU. Since we're trying to display images that come from over the network, there's no way to bypass the CPU. And doing a nice looking resize from 176x144 to 640x480 is quite slow. Then you have to copy the whole 640x480 image to the display card, which is slow. With OpenGL you just copy the 176x144 image to the video card, and have it do the resize. Cheers, -Dan mcquaid mcquaid wrote: > Just a user, I'm curious as to why the trend of throwing opengl at > everything. On one hand I think it's really cool, but this isn't like > xgl where we want wobbly windows or something, just accelerated > video. Isn't that what hardware video overlay is for? It takes a > large burden off the cpu for video playback. Would benefit more > people as some don't have proper opengl drivers. > > On 6/2/06, *Damien Sandras* > wrote: > > Le vendredi 02 juin 2006 à 03:03 -0700, Dan Sandberg a écrit : > > So configure.in is > hand-generated? Surprising. > > > > That's te way it works. You write configure.in > and configure is > generated from there. I guess you are confusing things here. > > > 1) How exactly do I add the opengl ( libgl ) library? > > > > By writing autconf code in configure.in . No > idea exactly how it should > be done. > > > 2) Xrandr is mentioned in the Makefile, but is not in > configure.in . How > > exactly does it get put into the Makefile? > > > > Probably by an external library that we are using. > > > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I > didn't want > > to code against a moving target. > > > > Yes. It is even OK if you do not provide the configure.in > code, but only > the OpenGL Ekiga code. > > > Thanks, > > > > -Dan > > > > Damien Sandras wrote: > > > > >Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > > > > > > > > >>I'd imagine it would work on win32, but don't know. > > >> > > >> > > >> > > > > > >Probably. > > > > > > > > > > > >>I'll work on the patches. > > >> > > >>Where's the right place to add required libraries like openGL? > > >> > > >> > > > > > >In configure.in . > > > > > > > > > > > >>configure.in seems to be autogenerated > by something, but whatever it is > > >>doesn't seem to be in the CVS snapshot... > > >> > > >> > > >> > > > > > >configure.in is in the CVS snapshot. > > > > > > > > > > > > > > >>Thanks, > > >> > > >>-Dan > > >> > > >>Julien PUYDT wrote: > > >> > > >> > > >> > > >>>Dan Sandberg a écrit : > > >>> > > >>> > > >>> > > >>>>How should we proceed? I could just send you an updated > gui/main.cpp > > >>>>file... > > >>>> > > >>>> > > >>>I'd like to see patches instead of full files, preferably > independant > > >>>on each others. > > >>> > > >>>There's also the question of the portability of this : since you > > >>>mention SDL, I guess this will work great on win32 too ? > > >>> > > >>>Snark > > >>>_______________________________________________ > > >>>Gnomemeeting-devel-list mailing list > > >>> Gnomemeeting-devel-list@gnome.org > > > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >>> > > >>> > > >>> > > >>_______________________________________________ > > >>Gnomemeeting-devel-list mailing list > > >> Gnomemeeting-devel-list@gnome.org > > > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >> > > >> > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > -- > _ Damien Sandras > (o- > //\ Ekiga Softphone: http://www.ekiga.org/ > v_/_ FOSDEM 2006 : http://www.fosdem.org/ > SIP Phone : sip:dsandras@ekiga.net > > sip:600000@ekiga.net > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > From mcquaidster@gmail.com Tue Jun 6 19:15:44 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1CB1D3B0100 for ; Tue, 6 Jun 2006 19:15:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28543-05 for ; Tue, 6 Jun 2006 19:15:41 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id 15D153B033F for ; Tue, 6 Jun 2006 19:15:40 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x31so65185pye for ; Tue, 06 Jun 2006 16:15:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Mcduoi+u93PszObMtVWeXgYeQW4VI1eW7YkgZ+7d03TZ67OjKeE6aoo507wYkIOly9icd2mdZ2fuDTkH7FKrnfSoGo+jOXhxLaobIUCU6gQdxyXgRqVTPVs16J/2P3hFDJ8K1ELtr1xuKRWtdbXceWGlDpZn2R3lxDak1f6E47c= Received: by 10.35.40.10 with SMTP id s10mr72093pyj; Tue, 06 Jun 2006 16:15:39 -0700 (PDT) Received: by 10.35.9.3 with HTTP; Tue, 6 Jun 2006 16:15:39 -0700 (PDT) Message-ID: <58a398810606061615s6a801fected291a67dbb85214@mail.gmail.com> Date: Tue, 6 Jun 2006 19:15:39 -0400 From: "mcquaid mcquaid" To: "Dan Sandberg" Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode In-Reply-To: <448605B0.6080504@cs.stanford.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8108_3516387.1149635739799" References: <447CCA43.3@stdout.at> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> <1149246461.2966.28.camel@golgoth01> <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> <448605B0.6080504@cs.stanford.edu> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.242 tagged_above=-999 required=2 tests=[AWL=0.223, BAYES_00=-2.599, HTML_50_60=0.134, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.242 X-Spam-Level: Cc: GnomeMeeting development mailing list X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 23:15:44 -0000 ------=_Part_8108_3516387.1149635739799 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hmm, again I don't know much about this but I think what you describe can b= e handled by hardware video overlay. Just a quick googling has this about hardware video overlay at the zoomplayer's website: http://www.inmatrix.com/zplayer/highlights/vidrender.shtml *The Video Overlay:* > At around 1995, when MPEG1 (VCD) playback started to become popular on th= e > PC, the actual processing power of the PC was not quite strong enough to > play such content. The display card manufacturers at the time came up wit= h a > solution called "The Video Overlay". The Video Overlay is a special hardw= are > on the display card which is used to perform several video-display featur= es > in hardware (Stretching, Color-Space Conversion, etc...), thus allowing > smooth playback of video at no cost to the CPU. It does go on to say that video rendering via dx9 (and thus I assume opengl) provide better image quality and don't suffer from some multimonitor issues with video overlay. Afaik, only one display can have hardware overlay so that's what he's referring to there. But, for the most part, it sounds like hardware overlay would be a nice solution as well that just about everyone would benefit from as again, ther= e are still a lot of people without good opengl in linux but most probably functional hardware overlay. Maybe an option for both? On 6/6/06, Dan Sandberg wrote: > > I could be wrong, but I believe that video overlay moves the data direct > from a capture card to the video card, bypassing the CPU. Since we're > trying to display images that come from over the network, there's no way > to bypass the CPU. And doing a nice looking resize from 176x144 to > 640x480 is quite slow. Then you have to copy the whole 640x480 image to > the display card, which is slow. With OpenGL you just copy the 176x144 > image to the video card, and have it do the resize. > > Cheers, > > -Dan > > mcquaid mcquaid wrote: > > Just a user, I'm curious as to why the trend of throwing opengl at > > everything. On one hand I think it's really cool, but this isn't like > > xgl where we want wobbly windows or something, just accelerated > > video. Isn't that what hardware video overlay is for? It takes a > > large burden off the cpu for video playback. Would benefit more > > people as some don't have proper opengl drivers. > > > > On 6/2/06, *Damien Sandras* > > wrote: > > > > Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit : > > > So configure.in is > > hand-generated? Surprising. > > > > > > > That's te way it works. You write configure.in > > and configure is > > generated from there. I guess you are confusing things here. > > > > > 1) How exactly do I add the opengl ( libgl ) library? > > > > > > > By writing autconf code in configure.in . No > > idea exactly how it should > > be done. > > > > > 2) Xrandr is mentioned in the Makefile, but is not in > > configure.in . How > > > exactly does it get put into the Makefile? > > > > > > > Probably by an external library that we are using. > > > > > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I > > didn't want > > > to code against a moving target. > > > > > > > Yes. It is even OK if you do not provide the configure.in > > code, but only > > the OpenGL Ekiga code. > > > > > Thanks, > > > > > > -Dan > > > > > > Damien Sandras wrote: > > > > > > >Le mercredi 31 mai 2006 =E0 12:41 -0700, Dan Sandberg a =E9crit = : > > > > > > > > > > > >>I'd imagine it would work on win32, but don't know. > > > >> > > > >> > > > >> > > > > > > > >Probably. > > > > > > > > > > > > > > > >>I'll work on the patches. > > > >> > > > >>Where's the right place to add required libraries like openGL? > > > >> > > > >> > > > > > > > >In configure.in . > > > > > > > > > > > > > > > >>configure.in seems to be autogenerated > > by something, but whatever it is > > > >>doesn't seem to be in the CVS snapshot... > > > >> > > > >> > > > >> > > > > > > > >configure.in is in the CVS snapshot. > > > > > > > > > > > > > > > > > > > >>Thanks, > > > >> > > > >>-Dan > > > >> > > > >>Julien PUYDT wrote: > > > >> > > > >> > > > >> > > > >>>Dan Sandberg a =E9crit : > > > >>> > > > >>> > > > >>> > > > >>>>How should we proceed? I could just send you an updated > > gui/main.cpp > > > >>>>file... > > > >>>> > > > >>>> > > > >>>I'd like to see patches instead of full files, preferably > > independant > > > >>>on each others. > > > >>> > > > >>>There's also the question of the portability of this : since > you > > > >>>mention SDL, I guess this will work great on win32 too ? > > > >>> > > > >>>Snark > > > >>>_______________________________________________ > > > >>>Gnomemeeting-devel-list mailing list > > > >>> Gnomemeeting-devel-list@gnome.org > > > > > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > >>> > > > >>> > > > >>> > > > >>_______________________________________________ > > > >>Gnomemeeting-devel-list mailing list > > > >> Gnomemeeting-devel-list@gnome.org > > > > > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > >> > > > >> > > > > > > _______________________________________________ > > > Gnomemeeting-devel-list mailing list > > > Gnomemeeting-devel-list@gnome.org > > > > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > -- > > _ Damien Sandras > > (o- > > //\ Ekiga Softphone: http://www.ekiga.org/ > > v_/_ FOSDEM 2006 : http://www.fosdem.org/ > > SIP Phone : sip:dsandras@ekiga.net > > > > sip:600000@ekiga.net > > > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > ------=_Part_8108_3516387.1149635739799 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hmm, again I don't know much about this but I think what you describe can b= e handled by
hardware video overlay.

Just a quick googling has t= his about hardware video overlay at the zoomplayer's website:

http://www.inmatrix.com/zplayer/highlights/vidrender.shtml

The Video Overlay:
At around 1995, when MPEG1 (VCD) playback started to become popular on the = PC, the actual processing power of the PC was not quite strong enough to play such content. The display card manufacturers a= t the time came up with a solution called "The Video Overlay". The Video Overlay is a special hardware on = the display card which is used to perform several video-display features in hardware (Stretching, Color-Space Conversion, etc...), thus all= owing smooth playback of video at no cost to the CPU.


It does go on to say  that video rend= ering via dx9 (and thus I assume opengl)  provide better image quality= and don't suffer from some multimonitor issues with video overlay.
Afai= k, only one display can have hardware overlay so that's what he's referring= to there.

But, for the most part, it sounds like hardware overlay would be a = nice solution as well that just about everyone would benefit from as again,= there are still a lot of people without good opengl in linux but most prob= ably functional hardware overlay.

Maybe an option for both? 

On 6/6/06, Dan Sandberg <<= a href=3D"mailto:x@cs.stanford.edu">x@cs.stanford.edu> wrote:=
I could be wrong, but I believe that video overlay moves the data directfrom a capture card to the video card, bypassing the CPU.  Since= we're
trying to display images that come from over the network, there's= no way
to bypass the CPU.  And doing a nice looking resize from 176x= 144 to
640x480 is quite slow.  Then you have to copy the whole= 640x480 image to
the display card, which is slow.  With OpenG= L you just copy the 176x144
image to the video card, and have it do the resize.

Cheers,
<= br>-Dan

mcquaid mcquaid wrote:
> Just a user, I'm curious as t= o why the trend of throwing opengl at
> everything.  On one= hand I think it's really cool, but this isn't like
> xgl where we want wobbly windows or something, just accelerated> video.  Isn't that what hardware video overlay is for? = ; It takes a
> large burden off the cpu for video playback. = ; Would benefit more
> people as some don't have proper opengl drivers.
>
> On 6/= 2/06, *Damien Sandras* <dsandras= @seconix.com
> <mailto: dsandras@seconix.com>> wrote:
>
>   &n= bsp; Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit :
= >     > So config= ure.in < http://configure.in> is
>     hand-generat= ed?  Surprising.
>     >
>
= >     That's te way it works. You write configure.in
>     < http://configure.in> and configure is
>    = ; generated from there. I guess you are confusing things here.
>
&= gt;     > 1) How exactly do I add the opengl ( libgl= ) library?
>     >
>
>     By writing autconf code in configure.in <http:= //configure.in>. No
>     idea exactly how= it should
>     be done.
>
>     > 2) Xrandr is mentioned in the Makefile, b= ut is not in
>     configure.in <http://configure.in<= /a>>.  How
>     > exactly does i= t get put into the Makefile?
>     >
>
>   &nbs= p; Probably by an external library that we are using.
>
> =     > 3) Is it ok if I send in a patch that is for Ekiga = 2.0.1?  I
>     didn't want
>&nbs= p;    > to code against a moving target.
>     >
>
>   &nbs= p; Yes. It is even OK if you do not provide the configure.in
>     <http://configure.in> code, but only
>     the OpenGL Ekiga code.
>
> &n= bsp;   > Thanks,
>     >
>&= nbsp;    > -Dan
>     >
&= gt;     > Damien Sandras wrote:
>  &= nbsp;  >
>     > >Le mercredi 31 ma= i 2006 =E0 12:41 -0700, Dan Sandberg a =E9crit :
>     > >
>     = > >
>     > >>I'd imagine it would= work on win32, but don't know.
>     > >&g= t;
>     > >>
>   &= nbsp; > >>
>     > >
>     > >Probably.
>  &nbs= p;  > >
>     > >
> &= nbsp;   > >
>     > >>I'= ll work on the patches.
>     > >>
&g= t;     > >>Where's the right place to add requ= ired libraries like openGL?
>     > >>
>   &nb= sp; > >>
>     > >
> &n= bsp;   > >In configure.in <http://configure.in>.
>=      > >
>     > >
>     = > >
>     > >>configure.in <http://con= figure.in> seems to be autogenerated
>    = by something, but whatever it is
>     > >>doesn't seem to be in the CVS= snapshot...
>     > >>
> &nb= sp;   > >>
>     > >>=
>     > >
>     = > >configure.in <http://configure.in> is in = the CVS snapshot.
>     > >
> &n= bsp;   > >
>     > >
>= ;     > >
>     > &g= t;>Thanks,
>     > >>
>     > >>-Dan
>   = ;  > >>
>     > >>Julien P= UYDT wrote:
>     > >>
> &nbs= p;   > >>
>     > >><= br>>     > >>>Dan Sandberg a =E9crit :
>     > >>>
>   = ;  > >>>
>     > >>>=
>     > >>>>How should we proceed= ?  I could just send you an updated
>   &nbs= p; gui/main.cpp
>     > >>>>file..= .
>     > >>>>
>  &= nbsp;  > >>>>
>     > >= >>I'd like to see patches instead of full files, preferably
>&n= bsp;    independant
>     > >= ;>>on each others.
>     > >>>
>   = ;  > >>>There's also the question of the portability of th= is : since you
>     > >>>mention SDL= , I guess this will work great on win32 too ?
>   &nbs= p; > >>>
>     > >>>Snark
>  =    > >>>_____________________________________________= __
>     > >>>Gnomemeeting-devel-list= mailing list
>     > >>> Gnomemeeting-devel-list@gnome.org
>     <m= ailto:Gnomemeeting-dev= el-list@gnome.org>
>     > >>>= http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>&= nbsp;    > >>>
>     &= gt; >>>
>     > >>>
>&= nbsp;    > >>______________________________________= _________
>     > >>Gnomemeeting-devel-list maili= ng list
>     > >> Gnomemeeting-devel-list@gnome.org
&g= t;     <mailto: Gnomemeeting-devel-list@gnome.org>
>     &= gt; >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list<= /a>
>     > >>
>     > >>
>   &nb= sp; >
>     > _____________________________= __________________
>     > Gnomemeeting-devel-= list mailing list
>     > Gnomemeeting-devel-list@gnome.org
>     <m= ailto:Gnomemeeting-dev= el-list@gnome.org>
>     > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>&= nbsp;    --
>     _  &nb= sp;   Damien Sandras
>     (o-
= >     //\     Ekiga Softphone: <= a href=3D"http://www.ekiga.org/">http://www.ekiga.org/
>     v_/_    FOSDEM 200= 6    : http://www.fo= sdem.org/
>         =     SIP Phone      : sip:dsandras@ekiga.net
> =     <mailto: sip:dsandr= as@ekiga.net>
>        = ;            &n= bsp;         sip:600000@ekiga.net
>   &n= bsp; <mailto: sip:600000@ekiga.net>
>= ;
>     _________________________________________= ______
>     Gnomemeeting-devel-list mailing list=
>     Gnomemeeting-devel-list@gnome.org
>     <m= ailto:Gnomemeeting-dev= el-list@gnome.org>
>     http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>&= nbsp;    <http://mail.gnome.org/mailman/listinfo/gnomemee= ting-devel-list >
>
>
> ----------------------------------------------= --------------------------
>
> ________________________________= _______________
> Gnomemeeting-devel-list mailing list
> Gnomemeeting-devel-list@gnome.org
> http://mail.gnome.org/mailman= /listinfo/gnomemeeting-devel-list
>

------=_Part_8108_3516387.1149635739799-- From stefan@watri.org.au Wed Jun 7 00:39:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 26FE33B0B45 for ; Wed, 7 Jun 2006 00:39:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12142-08 for ; Wed, 7 Jun 2006 00:39:13 -0400 (EDT) Received: from asclepius.uwa.edu.au (asclepius.uwa.edu.au [130.95.128.56]) by menubar.gnome.org (Postfix) with ESMTP id 1153F3B022D for ; Wed, 7 Jun 2006 00:39:11 -0400 (EDT) Received: from asclepius.kas (localhost.localdomain [127.0.0.1]) by asclepius.uwa.edu.au (Postfix) with SMTP id 9EF11184629 for ; Wed, 7 Jun 2006 12:39:05 +0800 (WST) Received: from asclepius (localhost.localdomain [127.0.0.1]) by asclepius.prekas (Postfix) with SMTP id 7CB52188123 for ; Wed, 7 Jun 2006 12:39:05 +0800 (WST) X-UWA-Client-IP: 130.95.28.15 (UWA) Received: from ns1.watri.uwa.edu.au (ns1.watri.org.au [130.95.28.15]) by asclepius.extinput (Postfix) with ESMTP id 6CCE5188174 for ; Wed, 7 Jun 2006 12:39:05 +0800 (WST) Received: from gluttony (gluttony.watri.org.au [130.95.29.76]) by ns1.watri.uwa.edu.au (8.13.1/8.13.1) with ESMTP id k574d4dE023954 for ; Wed, 7 Jun 2006 12:39:04 +0800 (WST) Message-Id: <200606070439.k574d4dE023954@ns1.watri.uwa.edu.au> From: =?iso-8859-1?Q?Stefan_Br=FCns?= To: "'GnomeMeeting development mailing list'" Subject: RE: [GnomeMeeting-devel-list] Full Screen Mode Date: Wed, 7 Jun 2006 12:41:40 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <448605B0.6080504@cs.stanford.edu> Thread-Index: AcaJu2+MfoUGcqUFRii2sxvr70Y3NQALgJIg X-SpamTest-Info: Profile: Formal (387/060606) X-SpamTest-Info: Profile: Detect Hard [UCS 290904] X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking Spam - Subject (UCS) [02-08-04] X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.176 tagged_above=-999 required=2 tests=[AWL=-1.125, BAYES_40=-0.185, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] X-Spam-Score: -1.176 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 04:39:16 -0000 > -----Original Message----- > From: gnomemeeting-devel-list-bounces@gnome.org > [mailto:gnomemeeting-devel-list-bounces@gnome.org] On Behalf > Of Dan Sandberg > Sent: Wednesday, 7 June 2006 6:46 AM > To: GnomeMeeting development mailing list > Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode > > I could be wrong, but I believe that video overlay moves the > data direct > >from a capture card to the video card, bypassing the CPU. > Since we're > trying to display images that come from over the network, > there's no way > to bypass the CPU. And doing a nice looking resize from 176x144 to > 640x480 is quite slow. Then you have to copy the whole > 640x480 image to > the display card, which is slow. With OpenGL you just copy > the 176x144 > image to the video card, and have it do the resize. Just to clarify some things: Video overlay over XV support scaling in hardware, and colorspace transforms. Unfortunately, most graphic cards support only one overlay at a time. In case you only have a single video, this is fine, but as soon as you have multiple (local/remote, maybe conference anytime in the future), you have to do the compositing before uploading the image to the card. In case of Picture in Picture, this means that you a) Scale the to be small video down, compose it into the large one, and upload the composed image. Drawback: Also the small image may end up as large as an unscaled CIF image, it will have a lower resolution, due to the downscaling. or b) Scale the to be large image up, and compose the small image into it. Also the small image will have its full resolution (it may be a CIF (352x288) image on a 1024x768 or larger screen), the upscaling of the large image adds a lot of burden to the CPU and memory transfers. On the other hand, if you use OpenGL textures, you have all the benefits: - You can upload every video to a different texture, every video ends up on the screen with all the available resolution, all the scaling is done on the GPU (which is very efficient for this). - Most cards support YUV colorspaces for textures, so color transform can be done on the card. - As the different videos stream end up on different textures, you may have the local video with full 25fps framerate, and the remote with something like 10fps. - Superimposing any text (Chat, callers name, new incoming call ...) comes down to putting the text into just another texture. This may be easily alpha blended, with full screen resolution (if you superimpose text on the video directly, you can only use the videos resolution, and edges may look really strange due to the UV subsampling). - You may due almost arbitrary transforms on the video, without burdening the CPU (have a look at the Conference feature of iChat AV to see what I mean). Greetings, Stefan From t.schorpp@gmx.de Wed Jun 7 03:35:24 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 125143B0C5F for ; Wed, 7 Jun 2006 03:35:24 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23077-04 for ; Wed, 7 Jun 2006 03:35:22 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by menubar.gnome.org (Postfix) with SMTP id 544083B0368 for ; Wed, 7 Jun 2006 03:35:21 -0400 (EDT) Received: (qmail invoked by alias); 07 Jun 2006 07:35:19 -0000 Received: from p85.212.144.48.tisdip.tiscali.de (EHLO [192.168.1.100]) [85.212.144.48] by mail.gmx.net (mp029) with SMTP; 07 Jun 2006 09:35:19 +0200 X-Authenticated: #17142692 Message-ID: <448681B6.5000204@gmx.de> Date: Wed, 07 Jun 2006 09:35:18 +0200 From: thomas schorpp User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1 X-Accept-Language: de, en-us MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode References: <200606070439.k574d4dE023954@ns1.watri.uwa.edu.au> In-Reply-To: <200606070439.k574d4dE023954@ns1.watri.uwa.edu.au> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.476 tagged_above=-999 required=2 tests=[AWL=-0.011, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] X-Spam-Score: -2.476 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: t.schorpp@gmx.de, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 07:35:24 -0000 Stefan Brüns wrote: >>-----Original Message----- >>From: gnomemeeting-devel-list-bounces@gnome.org >>[mailto:gnomemeeting-devel-list-bounces@gnome.org] On Behalf >>Of Dan Sandberg >>Sent: Wednesday, 7 June 2006 6:46 AM >>To: GnomeMeeting development mailing list >>Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode >> >>I could be wrong, but I believe that video overlay moves the >>data direct >>>from a capture card to the video card, bypassing the CPU. >>Since we're >>trying to display images that come from over the network, >>there's no way >>to bypass the CPU. And doing a nice looking resize from 176x144 to >>640x480 is quite slow. Then you have to copy the whole >>640x480 image to >>the display card, which is slow. With OpenGL you just copy >>the 176x144 >>image to the video card, and have it do the resize. > > > Just to clarify some things: > > Video overlay over XV support scaling in hardware, and colorspace > transforms. are You sure? ive some display apps here which can switch between XV and "real overlay". kvdr, tvtime, xawtv... XV can use significant high cpu load in my experience here... > > Unfortunately, most graphic cards support only one overlay at a time. not sure about this, too. all the chips i had since ati mach64 supported at least 2 overlays at a time. kvdr supports even up to 4 overlays(?) on modern cards respectively. http://www.s.netic.de/gfiala/ > In > case you only have a single video, this is fine, but as soon as you have > multiple (local/remote, maybe conference anytime in the future), you have to > do the compositing before uploading the image to the card. In case of > Picture in Picture, this means that you > > a) Scale the to be small video down, compose it into the large one, and > upload the composed image. Drawback: Also the small image may end up as > large as an unscaled CIF image, it will have a lower resolution, due to the > downscaling. > > or > b) Scale the to be large image up, and compose the small image into it. Also > the small image will have its full resolution (it may be a CIF (352x288) > image on a 1024x768 or larger screen), the upscaling of the large image adds > a lot of burden to the CPU and memory transfers. > > On the other hand, if you use OpenGL textures, you have all the benefits: > - You can upload every video to a different texture, every video ends up on > the screen with all the available resolution, all the scaling is done on the > GPU (which is very efficient for this). > - Most cards support YUV colorspaces for textures, so color transform can be > done on the card. > - As the different videos stream end up on different textures, you may have > the local video with full 25fps framerate, and the remote with something > like 10fps. > - Superimposing any text (Chat, callers name, new incoming call ...) comes > down to putting the text into just another texture. This may be easily alpha > blended, with full screen resolution (if you superimpose text on the video > directly, you can only use the videos resolution, and edges may look really > strange due to the UV subsampling). > - You may due almost arbitrary transforms on the video, without burdening > the CPU (have a look at the Conference feature of iChat AV to see what I > mean). > > Greetings, > is there no standard "network video class" for the application layer somewhere? > Stefan tom From jpuydt@free.fr Wed Jun 7 07:50:57 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 57F3B3B030A for ; Wed, 7 Jun 2006 07:50:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08294-07 for ; Wed, 7 Jun 2006 07:50:54 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id 565043B03D0 for ; Wed, 7 Jun 2006 07:50:54 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp3-g19.free.fr (Postfix) with ESMTP id 26AE4498B4 for ; Wed, 7 Jun 2006 13:50:53 +0200 (CEST) Message-ID: <4486BDD0.9050805@free.fr> Date: Wed, 07 Jun 2006 13:51:44 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.845 tagged_above=-999 required=2 tests=[AWL=-0.735, BAYES_05=-1.11] X-Spam-Score: -1.845 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Refactoring of the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 11:50:57 -0000 Hi, after some discussions, it seems my initial ideas just don't fly. I don't consider them as a full failure, but they certainly are 80% so. I has in particular a long (private) discussion with Éric Bischoff, which allowed me to test my ideas on a newcomer. :-) Snark From jpuydt@free.fr Wed Jun 7 08:02:38 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A3A943B0CA0 for ; Wed, 7 Jun 2006 08:02:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09379-09 for ; Wed, 7 Jun 2006 08:02:30 -0400 (EDT) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by menubar.gnome.org (Postfix) with ESMTP id 0A6253B0CFE for ; Wed, 7 Jun 2006 08:01:42 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp2-g19.free.fr (Postfix) with ESMTP id 9A1E973329 for ; Wed, 7 Jun 2006 14:01:41 +0200 (CEST) Message-ID: <4486C05B.9080200@free.fr> Date: Wed, 07 Jun 2006 14:02:35 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> In-Reply-To: <4486BDD0.9050805@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:02:38 -0000 Julien PUYDT a écrit : > Notice that I forgot the conclusion : back to blackboard :-) Snark From pbrobinson@gmail.com Wed Jun 7 08:05:53 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D7E343B0C89 for ; Wed, 7 Jun 2006 08:05:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09667-03 for ; Wed, 7 Jun 2006 08:05:53 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by menubar.gnome.org (Postfix) with ESMTP id 33FD03B0C35 for ; Wed, 7 Jun 2006 08:05:52 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id q2so283058uge for ; Wed, 07 Jun 2006 05:05:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=G9St54usrU1EqN6hzRVdcsL0b9E6Bqxv3H4s4TGGxDEm0S9y4VTy4J2/S9c86GUzX86KIkPRd3gDHRfgFY6rCHfD2mYVgjzsw18dl0V8Ib8+WG4xy7/jO5pBwQEky1I69/GeIoNY6Q1nIE7TBp9rIFYmsHkPs+aO3lXDh5BJAzE= Received: by 10.67.89.5 with SMTP id r5mr423228ugl; Wed, 07 Jun 2006 05:05:51 -0700 (PDT) Received: by 10.67.25.6 with HTTP; Wed, 7 Jun 2006 05:05:51 -0700 (PDT) Message-ID: <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> Date: Wed, 7 Jun 2006 13:05:51 +0100 From: "Peter Robinson" To: "GnomeMeeting development mailing list" Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code In-Reply-To: <4486C05B.9080200@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4486BDD0.9050805@free.fr> <4486C05B.9080200@free.fr> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.56 tagged_above=-999 required=2 tests=[AWL=-0.518, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.56 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:05:54 -0000 > Julien PUYDT a =E9crit : > > > > Notice that I forgot the conclusion : back to blackboard :-) So are there any ideas running around that blackboard as of yet? Peter From jpuydt@free.fr Wed Jun 7 08:22:36 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CBE393B08CC for ; Wed, 7 Jun 2006 08:22:36 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10857-05 for ; Wed, 7 Jun 2006 08:22:35 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 97D9B3B0CDC for ; Wed, 7 Jun 2006 08:22:35 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp5-g19.free.fr (Postfix) with ESMTP id 65742275AC for ; Wed, 7 Jun 2006 14:22:34 +0200 (CEST) Message-ID: <4486C53D.2080306@free.fr> Date: Wed, 07 Jun 2006 14:23:25 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> In-Reply-To: <4486BDD0.9050805@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:22:37 -0000 Ok, so let's see what the constraints are. 1) the already available addressbooks must fit in the new scheme ; 2) the future kde addressbooks must find their place easily ; 3) searching should be dead-easy ; 4) the future "live" contacts must find their place easily ; 5) the backend-frontend frontier should be clear enough to allow for easy DBUS exporting 6) Damien wants it fast. Yes, going back to the blackboard isn't the best way to achieve 6... Snark From jpuydt@free.fr Wed Jun 7 08:52:53 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 92FD63B03C4 for ; Wed, 7 Jun 2006 08:52:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12995-08 for ; Wed, 7 Jun 2006 08:52:50 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id D0F7E3B0C97 for ; Wed, 7 Jun 2006 08:52:49 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp3-g19.free.fr (Postfix) with ESMTP id AEAAC497A1 for ; Wed, 7 Jun 2006 14:52:48 +0200 (CEST) Message-ID: <4486CC54.9090206@free.fr> Date: Wed, 07 Jun 2006 14:53:40 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <4486C05B.9080200@free.fr> <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> In-Reply-To: <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:52:53 -0000 Peter Robinson a écrit : > So are there any ideas running around that blackboard as of yet? Plenty. Snark From ebischoff@nerim.net Wed Jun 7 09:43:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C57F03B03C1 for ; Wed, 7 Jun 2006 09:43:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17343-08 for ; Wed, 7 Jun 2006 09:43:14 -0400 (EDT) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by menubar.gnome.org (Postfix) with ESMTP id BB8E53B03F1 for ; Wed, 7 Jun 2006 09:43:13 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 09C7C40FD8 for ; Wed, 7 Jun 2006 15:43:11 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Wed, 7 Jun 2006 15:43:21 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <4486C53D.2080306@free.fr> In-Reply-To: <4486C53D.2080306@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606071543.22163.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.562 tagged_above=-999 required=2 tests=[AWL=0.037, BAYES_00=-2.599] X-Spam-Score: -2.562 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 13:43:16 -0000 Le Mercredi 7 Juin 2006 14:23, Julien PUYDT a =C3=A9crit=C2=A0: > Yes, going back to the blackboard isn't the best way to achieve 6... You don't go black to the blackboard with no experience ;-). In pecular, I have been proposing a framework for address book "drivers" li= ke: class EkigaAddressBook { public: virtual gchar *name() const =3D 0; virtual const EkigaContact *firstContact() =3D 0; virtual const EkigaContact *nextContact() =3D 0; }; class EkigaContact { public: virtual boolean hasName() const =3D 0; virtual gchar *name() const =3D 0; virtual boolean hasTelephone() const =3D 0; virtual gchar *telephone() const =3D 0; etc... }; class EkigaEvolutionAddressBook : public EkigaAddressBook { public: virtual gchar *name() const; virtual const EkigaContact *firstContact(); virtual const EkigaContact *nextContact(); }; class EkigaEvolutionContact : public EkigaContact { public: virtual boolean hasName() const; virtual gchar *name() const; virtual boolean hasTelephone() const; virtual gchar *telephone() const; etc... }; Comments and flames welcome. =2D-=20 =C3=89ric From jpuydt@free.fr Wed Jun 7 13:58:31 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6343F3B0BC1 for ; Wed, 7 Jun 2006 13:58:31 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02884-04 for ; Wed, 7 Jun 2006 13:58:23 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 55DA13B069F for ; Wed, 7 Jun 2006 13:58:19 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp1-g19.free.fr (Postfix) with ESMTP id E2BA8911A6 for ; Wed, 7 Jun 2006 19:58:17 +0200 (CEST) Message-ID: <4486F76C.7060301@free.fr> Date: Wed, 07 Jun 2006 17:57:32 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <4486C53D.2080306@free.fr> <200606071543.22163.ebischoff@nerim.net> In-Reply-To: <200606071543.22163.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 17:58:31 -0000 Éric Bischoff a écrit : > Le Mercredi 7 Juin 2006 14:23, Julien PUYDT a écrit : >> Yes, going back to the blackboard isn't the best way to achieve 6... > > You don't go black to the blackboard with no experience ;-). Of course no :-) > In pecular, I have been proposing a framework for address book "drivers" like: > > class EkigaAddressBook > { > public: > virtual gchar *name() const = 0; > virtual const EkigaContact *firstContact() = 0; > virtual const EkigaContact *nextContact() = 0; > }; I don't like your first/next idea. If I take an XMPP roster in ekiga, connect to the same account from another program, and add a contact there, the XMPP roster will do a roster push, which your api doesn't handle. A much better approach IMNSHO, when it comes to keeping track of a list of contacts, is the following pseudo-code api : - get the current list of contacts ; - notify/signal me when a new one appears. There are two ways to handle the removing of a contact from such a list: (i) either the book tells you the contact has been removed ; (ii) or the contact itself tells you so. Both can be handled by a notification/signal. My first tests used the second way to do so, but now I think the first is better : the signal tells you both the book and the contact. > class EkigaContact > { > public: > virtual boolean hasName() const = 0; > virtual gchar *name() const = 0; > > virtual boolean hasTelephone() const = 0; > virtual gchar *telephone() const = 0; > > etc... > }; Bad. :-) First, you don't handle the case where several telephone numbers are available. Then if you begin to put /everything/ in the *base* class, that will end badly. A base class should only have the most basic capabilities, not all of them. > Comments and flames welcome. As a last comment, I will repoint the two arguments I have to prefer a GObject solution to a C++ solution : 1) the GObject will nicely live and die in the glib mainloop, so we won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere ; 2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame /dev/null). Snark From jpuydt@free.fr Wed Jun 7 14:30:54 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6C9E83B0255 for ; Wed, 7 Jun 2006 14:30:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04954-09 for ; Wed, 7 Jun 2006 14:30:52 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 15D9C3B0135 for ; Wed, 7 Jun 2006 14:30:52 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp5-g19.free.fr (Postfix) with ESMTP id E116F2766C for ; Wed, 7 Jun 2006 20:30:50 +0200 (CEST) Message-ID: <44871B92.9090703@free.fr> Date: Wed, 07 Jun 2006 20:31:46 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <4486C05B.9080200@free.fr> <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> <4486CC54.9090206@free.fr> In-Reply-To: <4486CC54.9090206@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 18:30:54 -0000 Julien PUYDT a écrit : > Plenty. Ok, here are a few. First of all, Éric convinced me the "no common class for contacts" was bad. So the main organization should probably be the following : - at the upper level, there are sources of addressbooks (avahi, e-d-s, kab, call history, xmpp...) ; - those sources give access to addressbooks ; - those addressbooks contain contacts. Now the question is detailing what is done where :-) Snark From ebischoff@nerim.net Wed Jun 7 14:33:56 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E21DC3B027D for ; Wed, 7 Jun 2006 14:33:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05177-06 for ; Wed, 7 Jun 2006 14:33:54 -0400 (EDT) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by menubar.gnome.org (Postfix) with ESMTP id 360A33B0135 for ; Wed, 7 Jun 2006 14:33:53 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 7CB2240E26 for ; Wed, 7 Jun 2006 20:33:50 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Wed, 7 Jun 2006 20:33:52 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606071543.22163.ebischoff@nerim.net> <4486F76C.7060301@free.fr> In-Reply-To: <4486F76C.7060301@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606072033.54523.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.569 tagged_above=-999 required=2 tests=[AWL=0.030, BAYES_00=-2.599] X-Spam-Score: -2.569 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 18:33:56 -0000 Le Mercredi 7 Juin 2006 17:57, Julien PUYDT a =C3=A9crit=C2=A0: > A much better approach IMNSHO, when it comes to keeping track of a list > of contacts, is the following pseudo-code api : > - get the current list of contacts ; > - notify/signal me when a new one appears. I am not sure that the Evolution, LDAP or KAddressBook drivers will all be= =20 able to wake up when a new contact is created. The contact can be created=20 asynchronously by another user on another machine on some LDAP server far=20 away on a network that is broken half of the time, for example. So even the= =20 underlying Evolution / LDAP / KAddressBook libraries might not know. =46urthermore, keeping a list all contacts in memory can have a high cost i= n=20 memory usage. > There are two ways to handle the removing of a contact from such a list: > (i) either the book tells you the contact has been removed ; > (ii) or the contact itself tells you so. > Both can be handled by a notification/signal. My first tests used the > second way to do so, but now I think the first is better : the signal > tells you both the book and the contact. Is that such a problem if the driver loops over an older version of the lis= t? > First, you don't handle the case where several telephone numbers are > available. Yeah, yeah. That was just an example. > Then if you begin to put /everything/ in the *base* class, that will end > badly. A base class should only have the most basic capabilities, not > all of them. Well, most address books are expected to deliver names and telephone=20 numbers ,-). But if you don't want to code hooks that return NULL all the=20 time for properties that do not exist (which I can understand), there's an= =20 easy and clean variant: class EkigaContact { public: enum property { name, telephone, street, ... }; virtual bool hasProperty(property p) const =3D 0; gchar *value(property p) const =3D 0; }; So contact->value(street) returns the street address and if contact->hasProperty(street) is true. > As a last comment, I will repoint the two arguments I have to prefer a > GObject solution to a C++ solution : Well, that's the kind of debate that can typically end up in a religious=20 war ;-), but: 1) why reinvent the wheel? C++ has mechanisms for object programming, it's= =20 rather strange to reimplement them in C; 2) such choices tie Ekiga more deeply into GNOME libraries (okay, it's a GN= OME=20 project. But...) > 1) the GObject will nicely live and die in the glib mainloop, so we > won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere= ; > 2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga > more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame > /dev/null). GBUS is indeed a nice invention ;-). =2D-=20 =C3=89ric From jpuydt@free.fr Wed Jun 7 15:29:48 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 91CC53B027D for ; Wed, 7 Jun 2006 15:29:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08481-05 for ; Wed, 7 Jun 2006 15:29:45 -0400 (EDT) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by menubar.gnome.org (Postfix) with ESMTP id 54DB33B0546 for ; Wed, 7 Jun 2006 15:29:45 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp2-g19.free.fr (Postfix) with ESMTP id 2EC0A6FECE for ; Wed, 7 Jun 2006 21:29:44 +0200 (CEST) Message-ID: <4487295A.9060506@free.fr> Date: Wed, 07 Jun 2006 21:30:34 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606071543.22163.ebischoff@nerim.net> <4486F76C.7060301@free.fr> <200606072033.54523.ebischoff@nerim.net> In-Reply-To: <200606072033.54523.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 19:29:48 -0000 Éric Bischoff a écrit : > Le Mercredi 7 Juin 2006 17:57, Julien PUYDT a écrit : >> A much better approach IMNSHO, when it comes to keeping track of a list >> of contacts, is the following pseudo-code api : >> - get the current list of contacts ; >> - notify/signal me when a new one appears. > > I am not sure that the Evolution, LDAP or KAddressBook drivers will all be > able to wake up when a new contact is created. The contact can be created > asynchronously by another user on another machine on some LDAP server far > away on a network that is broken half of the time, for example. So even the > underlying Evolution / LDAP / KAddressBook libraries might not know. Well, for those what I propose still works : - they get a list of contacts (and emit the "contact-added" signal for each) ; - when they are refreshed, they remove all their contacts, and get the new list of contacts. And what I propose works also for XMPP rosters, which are dynamically updated. > Furthermore, keeping a list all contacts in memory can have a high cost in > memory usage. Indeed, some books shouldn't treat "get the list of contacts" litterally. That is why they shouldn't be too stupid :-) >> There are two ways to handle the removing of a contact from such a list: >> (i) either the book tells you the contact has been removed ; >> (ii) or the contact itself tells you so. >> Both can be handled by a notification/signal. My first tests used the >> second way to do so, but now I think the first is better : the signal >> tells you both the book and the contact. > > Is that such a problem if the driver loops over an older version of the list? To do what ? It is not a problem if the list of users on ekiga.net isn't updated live. But it certainly is if your XMPP roster isn't ! >> First, you don't handle the case where several telephone numbers are >> available. > > Yeah, yeah. That was just an example. :-) >> Then if you begin to put /everything/ in the *base* class, that will end >> badly. A base class should only have the most basic capabilities, not >> all of them. > > Well, most address books are expected to deliver names and telephone > numbers ,-). But if you don't want to code hooks that return NULL all the > time for properties that do not exist (which I can understand), there's an > easy and clean variant: > class EkigaContact > { > public: > enum property { name, telephone, street, ... }; > > virtual bool hasProperty(property p) const = 0; > gchar *value(property p) const = 0; > }; Eh... this looks like GObject properties! >> As a last comment, I will repoint the two arguments I have to prefer a >> GObject solution to a C++ solution : > > Well, that's the kind of debate that can typically end up in a religious > war ;-), but: > 1) why reinvent the wheel? C++ has mechanisms for object programming, it's > rather strange to reimplement them in C; > 2) such choices tie Ekiga more deeply into GNOME libraries (okay, it's a GNOME > project. But...) glib/gobject isn't gnome. It isn't even graphical. >> 1) the GObject will nicely live and die in the glib mainloop, so we >> won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere ; >> 2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga >> more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame >> /dev/null). > > GBUS is indeed a nice invention ;-). DBUS, not GBUS. Snark From ebischoff@nerim.net Wed Jun 7 17:05:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 354B63B00A5 for ; Wed, 7 Jun 2006 17:05:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14677-05 for ; Wed, 7 Jun 2006 17:05:13 -0400 (EDT) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by menubar.gnome.org (Postfix) with ESMTP id CB5F43B0135 for ; Wed, 7 Jun 2006 17:05:12 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 1E15A437B0 for ; Wed, 7 Jun 2006 22:52:51 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Wed, 7 Jun 2006 22:53:00 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606072033.54523.ebischoff@nerim.net> <4487295A.9060506@free.fr> In-Reply-To: <4487295A.9060506@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606072253.01820.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.573 tagged_above=-999 required=2 tests=[AWL=0.026, BAYES_00=-2.599] X-Spam-Score: -2.573 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 21:05:17 -0000 Le Mercredi 7 Juin 2006 21:30, Julien PUYDT a =C3=A9crit=C2=A0: > > I am not sure that the Evolution, LDAP or KAddressBook drivers will all > > be able to wake up when a new contact is created. The contact can be > > created asynchronously by another user on another machine on some LDAP > > server far away on a network that is broken half of the time, for > > example. So even the underlying Evolution / LDAP / KAddressBook librari= es > > might not know. > > Well, for those what I propose still works : > - they get a list of contacts (and emit the "contact-added" signal for > each) ; > - when they are refreshed, they remove all their contacts, and get the > new list of contacts. What makes you think that they get "refreshed" at some point? > And what I propose works also for XMPP rosters, which are dynamically > updated. Promise, I will look someday what a "XMPP roster" is ;-). > > Furthermore, keeping a list all contacts in memory can have a high cost > > in memory usage. > > Indeed, some books shouldn't treat "get the list of contacts" > litterally. That is why they shouldn't be too stupid :-) Then you must some kind of evolved caching mechanism in your driver. That's= =20 sounds overcomplicated and hard to code to me. If you simply loop through t= he=20 contacts, you can just get the information you need and display it. > > Is that such a problem if the driver loops over an older version of the > > list? > > To do what ? It is not a problem if the list of users on ekiga.net isn't > updated live. But it certainly is if your XMPP roster isn't ! If you convinced me of one thing, it's that I need to look at the definitio= n=20 of these SNMP toasters ;-). > > class EkigaContact > > { > > public: > > enum property { name, telephone, street, ... }; > > > > virtual bool hasProperty(property p) const =3D 0; > > gchar *value(property p) const =3D 0; > > }; > > Eh... this looks like GObject properties! Indeed! Excepted that you are just using the possibilities of the programmi= ng=20 language, not of some library. At this point, I must do some clarification: I am a newcomer to Ekiga and perfectly aware of the fact that I might ignor= e a=20 lot of things about the past and the possible future of this software. I am= a=20 complete ignorant of GNOME and its libraries. I do not know anything about= =20 the multithreading problems that Julien has to deal with. I am not here to= =20 slow down Julien, nor to get my views adopted. I will be more than happy to= =20 adapt my code to *any* API that Julien will bring up. And to shut my big=20 mouth up if anyone ask me to ;-). > glib/gobject isn't gnome. It isn't even graphical. Okay, to me who comes from the KDE world, it's the same thing, it starts wi= th=20 "g" ;-). > > GBUS is indeed a nice invention ;-). > > DBUS, not GBUS. Yes, sorry for the many typos... :-/ =2D-=20 =C3=89ric From jan.schampera@web.de Wed Jun 7 23:13:06 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7395E3B043B for ; Wed, 7 Jun 2006 23:13:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02368-03 for ; Wed, 7 Jun 2006 23:13:03 -0400 (EDT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by menubar.gnome.org (Postfix) with ESMTP id 6D4823B012E for ; Wed, 7 Jun 2006 23:13:03 -0400 (EDT) Received: from fwd35.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1FoAxC-0004rd-00; Thu, 08 Jun 2006 05:13:02 +0200 Received: from mail.home.thebonsai.de (Z2ab0kZBZewL1AHEQWezyBxMlAJSeayZbCOT8jbF9IKQFlf7QKn1Ul@[84.147.102.15]) by fwd35.sul.t-online.de with esmtp id 1FoAx4-1YpxqK0; Thu, 8 Jun 2006 05:12:54 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id 8DF136B173 for ; Thu, 8 Jun 2006 05:12:52 +0200 (CEST) Date: Thu, 8 Jun 2006 05:08:28 +0200 From: Jan Schampera To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Message-ID: <20060608050828.37d3ac08@localhost.localdomain> In-Reply-To: <200606072253.01820.ebischoff@nerim.net> References: <4486BDD0.9050805@free.fr> <200606072033.54523.ebischoff@nerim.net> <4487295A.9060506@free.fr> <200606072253.01820.ebischoff@nerim.net> Organization: private X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-ID: Z2ab0kZBZewL1AHEQWezyBxMlAJSeayZbCOT8jbF9IKQFlf7QKn1Ul@t-dialin.net X-TOI-MSGID: c2323eec-2b6b-468d-b9e5-6ee93ecdce82 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.971 tagged_above=-999 required=2 tests=[AWL=0.627, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.971 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 03:13:06 -0000 On Wed, 7 Jun 2006 22:53:00 +0200 =C3=89ric Bischoff wrote: > (GLib vs OOP) > Indeed! Excepted that you are just using the possibilities of the > programming language, not of some library. Please note, regardless all other arguments, that an own C++-object system will be totally independant of the used framework. In case we leave GTK and GLib some day, the OOP approach won't need any changes. The GObject approach would need either an equivalent in the new framework, or a rewrite to (finally) OOP. Beside that, I tend to say "a matter of taste". J. --=20 dreaming in digital living in realtime thinking in binary talking in IP WELCOME TO OUR WORLD From jpuydt@free.fr Thu Jun 8 04:39:27 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8DA623B05CC for ; Thu, 8 Jun 2006 04:39:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19858-03 for ; Thu, 8 Jun 2006 04:39:24 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id D38EA3B0E0F for ; Thu, 8 Jun 2006 04:39:23 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp6-g19.free.fr (Postfix) with ESMTP id A778922647 for ; Thu, 8 Jun 2006 10:39:22 +0200 (CEST) Message-ID: <4487E272.80605@free.fr> Date: Thu, 08 Jun 2006 10:40:18 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606072033.54523.ebischoff@nerim.net> <4487295A.9060506@free.fr> <200606072253.01820.ebischoff@nerim.net> In-Reply-To: <200606072253.01820.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 08:39:27 -0000 Éric Bischoff a écrit : > Le Mercredi 7 Juin 2006 21:30, Julien PUYDT a écrit : >>> I am not sure that the Evolution, LDAP or KAddressBook drivers will all >>> be able to wake up when a new contact is created. The contact can be >>> created asynchronously by another user on another machine on some LDAP >>> server far away on a network that is broken half of the time, for >>> example. So even the underlying Evolution / LDAP / KAddressBook libraries >>> might not know. >> Well, for those what I propose still works : >> - they get a list of contacts (and emit the "contact-added" signal for >> each) ; >> - when they are refreshed, they remove all their contacts, and get the >> new list of contacts. > > What makes you think that they get "refreshed" at some point? The user triggers the "refresh" action :-) >> And what I propose works also for XMPP rosters, which are dynamically >> updated. > > Promise, I will look someday what a "XMPP roster" is ;-). Perhaps you know what a "jabber roster" is? http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html >>> Furthermore, keeping a list all contacts in memory can have a high cost >>> in memory usage. >> Indeed, some books shouldn't treat "get the list of contacts" >> litterally. That is why they shouldn't be too stupid :-) > > Then you must some kind of evolved caching mechanism in your driver. That's > sounds overcomplicated and hard to code to me. If you simply loop through the > contacts, you can just get the information you need and display it. I don't think a trivial proxying counts as an "evolved caching mechanism" :-) >>> Is that such a problem if the driver loops over an older version of the >>> list? >> To do what ? It is not a problem if the list of users on ekiga.net isn't >> updated live. But it certainly is if your XMPP roster isn't ! > > If you convinced me of one thing, it's that I need to look at the definition > of these SNMP toasters ;-). Who's toast ? ;-) >>> class EkigaContact >>> { >>> public: >>> enum property { name, telephone, street, ... }; >>> >>> virtual bool hasProperty(property p) const = 0; >>> gchar *value(property p) const = 0; >>> }; >> Eh... this looks like GObject properties! > > Indeed! Excepted that you are just using the possibilities of the programming > language, not of some library. Can you add properties to the enum when inheriting ? > At this point, I must do some clarification: > > I am a newcomer to Ekiga and perfectly aware of the fact that I might ignore a > lot of things about the past and the possible future of this software. I am a > complete ignorant of GNOME and its libraries. I do not know anything about > the multithreading problems that Julien has to deal with. I am not here to > slow down Julien, nor to get my views adopted. I will be more than happy to > adapt my code to *any* API that Julien will bring up. And to shut my big > mouth up if anyone ask me to ;-). Yes, yes, no problem. I'm happy to have feedback :-) >> glib/gobject isn't gnome. It isn't even graphical. > > Okay, to me who comes from the KDE world, it's the same thing, it starts with > "g" ;-). glib, gobject & gtk+ already make ekiga run on win32. >>> GBUS is indeed a nice invention ;-). >> DBUS, not GBUS. > > Yes, sorry for the many typos... :-/ Eh... that one was pretty bad for someone who has something against g-letter words ;-) Snark From ebischoff@nerim.net Thu Jun 8 04:49:09 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DA33D3B013D for ; Thu, 8 Jun 2006 04:49:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20394-06 for ; Thu, 8 Jun 2006 04:49:08 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id 682F73B05A7 for ; Thu, 8 Jun 2006 04:49:07 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 6666B41095 for ; Thu, 8 Jun 2006 10:49:06 +0200 (CEST) From: =?iso-8859-15?q?=C9ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 10:49:15 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <20060608050828.37d3ac08@localhost.localdomain> In-Reply-To: <20060608050828.37d3ac08@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606081049.16046.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.577 tagged_above=-999 required=2 tests=[AWL=0.022, BAYES_00=-2.599] X-Spam-Score: -2.577 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 08:49:10 -0000 Le Jeudi 8 Juin 2006 05:08, Jan Schampera a =E9crit=A0: > > Indeed! Excepted that you are just using the possibilities of the > > programming language, not of some library. > > Please note, regardless all other arguments, that an own C++-object > system will be totally independant of the used framework. In case we > leave GTK and GLib some day, the OOP approach won't need any changes. > > The GObject approach would need either an equivalent in the new > framework, or a rewrite to (finally) OOP. Yes. That was precisely my point. > Beside that, I tend to say "a matter of taste". Yes. Sometimes programming has to do with aesthetics. Compare: =3D=3D=3D GObject way =3D=3D=3D struct _GmBook { GObject parent; }; struct _GmBookClass { GObjectClass parent; const gchar *(*get_name)(GmBook *self); }; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D with: =3D=3D=3D C++ way =3D=3D=3D class GmBook { public: virtual get_name() const; } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D My tastes tell me that second code, besides from being much shorter, has mo= re=20 "beauty" than the first one. But as you say, tastes are a very personal=20 thing. =2D-=20 =C9ric From jpuydt@free.fr Thu Jun 8 05:09:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C38A43B04E8 for ; Thu, 8 Jun 2006 05:09:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21821-03 for ; Thu, 8 Jun 2006 05:09:15 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 32ECF3B0505 for ; Thu, 8 Jun 2006 05:09:15 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp5-g19.free.fr (Postfix) with ESMTP id BD9EA275B9 for ; Thu, 8 Jun 2006 11:09:13 +0200 (CEST) Message-ID: <4487E971.8070602@free.fr> Date: Thu, 08 Jun 2006 11:10:09 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <20060608050828.37d3ac08@localhost.localdomain> <200606081049.16046.ebischoff@nerim.net> In-Reply-To: <200606081049.16046.ebischoff@nerim.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 09:09:16 -0000 Éric Bischoff a écrit : > Le Jeudi 8 Juin 2006 05:08, Jan Schampera a écrit : >>> Indeed! Excepted that you are just using the possibilities of the >>> programming language, not of some library. >> Please note, regardless all other arguments, that an own C++-object >> system will be totally independant of the used framework. In case we >> leave GTK and GLib some day, the OOP approach won't need any changes. >> >> The GObject approach would need either an equivalent in the new >> framework, or a rewrite to (finally) OOP. > > Yes. That was precisely my point. > >> Beside that, I tend to say "a matter of taste". > > Yes. Sometimes programming has to do with aesthetics. Compare: > > === GObject way === > struct _GmBook { > GObject parent; > }; > > struct _GmBookClass { > GObjectClass parent; > > const gchar *(*get_name)(GmBook *self); > }; > ================== > > with: > > === C++ way === > class GmBook { > public: > virtual get_name() const; > } > ================== > > My tastes tell me that second code, besides from being much shorter, has more > "beauty" than the first one. But as you say, tastes are a very personal > thing. My experience is that when it comes to export the object on DBUS, you're better off with a gobject than with a C++ object. One has some introspection, the other doesn't. I prefer working a little harder upfront, then have an easy life, than writing easy code then feel miserable :-) Snark From ebischoff@nerim.net Thu Jun 8 05:22:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C67273B0598 for ; Thu, 8 Jun 2006 05:22:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22528-04 for ; Thu, 8 Jun 2006 05:22:07 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id D66F33B0B13 for ; Thu, 8 Jun 2006 05:22:06 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 4966F40FBF for ; Thu, 8 Jun 2006 11:22:05 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 11:22:09 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <4487E272.80605@free.fr> In-Reply-To: <4487E272.80605@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606081122.11835.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.579 tagged_above=-999 required=2 tests=[AWL=0.020, BAYES_00=-2.599] X-Spam-Score: -2.579 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 09:22:11 -0000 Le Jeudi 8 Juin 2006 10:40, Julien PUYDT a =C3=A9crit=C2=A0: > > What makes you think that they get "refreshed" at some point? > > The user triggers the "refresh" action :-) Then you loop again through the address book contacts ;-). No need to keep = a=20 copy of the contacts for that. > > Promise, I will look someday what a "XMPP roster" is ;-). > > Perhaps you know what a "jabber roster" is? > http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html No, and this article does not contain the word "roster" :-(. > > Then you must some kind of evolved caching mechanism in your driver. > > That's sounds overcomplicated and hard to code to me. If you simply loop > > through the contacts, you can just get the information you need and > > display it. > > I don't think a trivial proxying counts as an "evolved caching > mechanism" :-) I told you in private that I had a very lazy concept of programming ;-). > Who's toast ? ;-) ;-). > Can you add properties to the enum when inheriting ? Yes: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D class Repas { public: enum plat { nouilles, riz, patates, pain }; virtual void mange(plat p) =3D 0; }; class BonRepas : public Repas { public: enum bonPlat { caviar =3D pain + 1, langouste, foiegras, saumon }; virtual void mange(plat p); }; void BonRepas::mange(plat p) { if ((bonPlat) p =3D=3D langouste) printf("Miam!\n"); } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D With anonymous enums you should even be able to get rid of the casts. But=20 named enums make the code clearer. > Yes, yes, no problem. I'm happy to have feedback :-) Thanks for your openess, Julien :-). > glib, gobject & gtk+ already make ekiga run on win32. I know. But I think it is always good to remove references to libraries if = you=20 do not really need them. > Eh... that one was pretty bad for someone who has something against > g-letter words ;-) I have nothing against, I am just ignorant ;-). =2D-=20 =C3=89ric From conrad_videokonferenz@gmx.de Thu Jun 8 06:04:43 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7A1F63B0CF2 for ; Thu, 8 Jun 2006 06:04:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24863-06 for ; Thu, 8 Jun 2006 06:04:41 -0400 (EDT) Received: from vz17136.evanzo-server.de (vz17136.evanzo-server.de [62.140.17.136]) by menubar.gnome.org (Postfix) with ESMTP id E081B3B05CC for ; Thu, 8 Jun 2006 06:04:40 -0400 (EDT) Received: from c133075.adsl.hansenet.de (c133075.adsl.hansenet.de [213.39.133.75]) (authenticated bits=0) by vz17136.evanzo-server.de (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id k58A4cTf030082 for ; Thu, 8 Jun 2006 12:04:39 +0200 From: Conrad Beckert To: gnomemeeting-devel-list@gnome.org Date: Thu, 8 Jun 2006 10:02:37 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606081002.37875.conrad_videokonferenz@gmx.de> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.106 tagged_above=-999 required=2 tests=[AWL=-1.138, BAYES_05=-1.11, SPF_FAIL=1.142] X-Spam-Score: -1.106 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 10:04:45 -0000 Hi, has anybody an idea where the Debian packages for Ekiga 2.0.2 (or the corresponding CVS versions) are? The last version I can install using apt-get a couple of days old (May 25 - or somethin) - at least this is a version with the nonfunctional German locale. (defaults to English) What's up? Conrad From jpuydt@free.fr Thu Jun 8 06:59:27 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 483C83B0ED8 for ; Thu, 8 Jun 2006 06:59:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27917-10 for ; Thu, 8 Jun 2006 06:59:15 -0400 (EDT) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by menubar.gnome.org (Postfix) with ESMTP id 1C5223B0630 for ; Thu, 8 Jun 2006 06:59:12 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp4-g19.free.fr (Postfix) with ESMTP id A681254974 for ; Thu, 8 Jun 2006 12:59:10 +0200 (CEST) Message-ID: <44880335.3060401@free.fr> Date: Thu, 08 Jun 2006 13:00:05 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <4487E272.80605@free.fr> <200606081122.11835.ebischoff@nerim.net> In-Reply-To: <200606081122.11835.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 10:59:27 -0000 Éric Bischoff a écrit : > Le Jeudi 8 Juin 2006 10:40, Julien PUYDT a écrit : >>> What makes you think that they get "refreshed" at some point? >> The user triggers the "refresh" action :-) > > Then you loop again through the address book contacts ;-). No need to keep a > copy of the contacts for that. You will need to keep a copy to show them to the user anyway. And notice that a same contact could be shown at several places through the user interface! >>> Promise, I will look someday what a "XMPP roster" is ;-). >> Perhaps you know what a "jabber roster" is? >> http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html > > No, and this article does not contain the word "roster" :-(. The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish them from 'live' contacts. The situation is that you may have jc@jabber.lat in your roster, with the information that the name is "Julius Caesar", and belongs to the groups "Politicians" and "Jokers". But when he connects from his pda, he will show up as jc@jabber.lat/pda, and will neither be able to do VoIP, nor receive XHTML messages. When he is home, he connects from his computer as jc@jabber.lat/home, and will be able to do both. Now he goes to work, from where he shows up as jc@jabber.lat/work, which can do XHTML messaging, but not VoIP. >> Yes, yes, no problem. I'm happy to have feedback :-) > > Thanks for your openess, Julien :-). No problem. More brains means better solutions :-) >> glib, gobject & gtk+ already make ekiga run on win32. > > I know. But I think it is always good to remove references to libraries if you > do not really need them. Well, glib is nice. The main problem KDE problem have with it is that it begins with a 'g' and is already used in GNOME. :-) Snark From ebischoff@nerim.net Thu Jun 8 09:37:50 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CE2BD3B03A6 for ; Thu, 8 Jun 2006 09:37:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08027-03 for ; Thu, 8 Jun 2006 09:37:49 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id 549EB3B0622 for ; Thu, 8 Jun 2006 09:37:48 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 1D58441027 for ; Thu, 8 Jun 2006 15:37:45 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 15:37:53 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606081122.11835.ebischoff@nerim.net> <44880335.3060401@free.fr> In-Reply-To: <44880335.3060401@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606081537.55137.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.504 tagged_above=-999 required=2 tests=[AWL=-0.059, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077] X-Spam-Score: -2.504 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 13:37:51 -0000 Le Jeudi 8 Juin 2006 13:00, Julien PUYDT a =C3=A9crit=C2=A0: > > Then you loop again through the address book contacts ;-). No need to > > keep a copy of the contacts for that. > > You will need to keep a copy to show them to the user anyway. Keeping contacts in memory is not the same at all as keeping an image of wh= at=20 Ekiga has to display of them. The GUI needs basically a list of strings to= =20 display, not the potentially complex data structure of an address book=20 contact. Having one of these complex structures in memory at a time is enough IMHO. Should it be only for performance reasons: when the user scrolls down the l= ist=20 by one contact, it is much quicker to retreive data from a prepared list of= =20 strings than from the contact itself. > And notice=20 > that a same contact could be shown at several places through the user > interface! Yes, and perharps displayed in different ways. > > No, and this article does not contain the word "roster" :-(. > > The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish > them from 'live' contacts. > > The situation is that you may have jc@jabber.lat in your roster, with > the information that the name is "Julius Caesar", and belongs to the > groups "Politicians" and "Jokers". But when he connects from his pda, he > will show up as jc@jabber.lat/pda, and will neither be able to do VoIP, > nor receive XHTML messages. When he is home, he connects from his > computer as jc@jabber.lat/home, and will be able to do both. Now he goes > to work, from where he shows up as jc@jabber.lat/work, which can do > XHTML messaging, but not VoIP. Aha. > > Thanks for your openess, Julien :-). > > No problem. More brains means better solutions :-) Yes, indeed. I hope my advice brings something constructive. As I told you = in=20 private, you keep it or throw it, it's your decision. > > I know. But I think it is always good to remove references to libraries > > if you do not really need them. > > Well, glib is nice. The main problem KDE problem have with it is that it > begins with a 'g' and is already used in GNOME. :-) Do not believe that. We are not religious people. For example, we are very= =20 happy sharing libxml with GNOME. Even though there is already a XML API in= =20 Qt! Just because libxml rocks... (oh yeah, there's no "g" in libxml... ;-) ) We already share libxml, desktop files, DocBook documentation, DBUS=20 communication, po translation memories, and many, many other things. Cool=20 apps like Ekiga can run in a KDE environment. Cool apps like ... errr...=20 KEuroCalc ;-) can run in a GNOME environment. And in fact I know that many= =20 people do that. In fact, the more we will be able to share with you, the happier we will be= =2E I=20 can ensure you that this has always been what we said, even during private= =20 discussions at KDE meetings. I do not know why we do not share glib. I have my ideas about that, but it'= s=20 just personal assumptions ;-). =2D-=20 =C3=89ric From jpuydt@free.fr Thu Jun 8 15:02:29 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6459F3B0F68 for ; Thu, 8 Jun 2006 15:02:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30195-09 for ; Thu, 8 Jun 2006 15:02:28 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id 1D6653B035A for ; Thu, 8 Jun 2006 15:02:28 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp6-g19.free.fr (Postfix) with ESMTP id A118022783 for ; Thu, 8 Jun 2006 21:02:23 +0200 (CEST) Message-ID: <4488747B.6080906@free.fr> Date: Thu, 08 Jun 2006 21:03:23 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606081122.11835.ebischoff@nerim.net> <44880335.3060401@free.fr> <200606081537.55137.ebischoff@nerim.net> In-Reply-To: <200606081537.55137.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.512 tagged_above=-999 required=2 tests=[AWL=-0.067, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077] X-Spam-Score: -2.512 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:02:29 -0000 Éric Bischoff a écrit : >> You will need to keep a copy to show them to the user anyway. > > Keeping contacts in memory is not the same at all as keeping an image of what > Ekiga has to display of them. The GUI needs basically a list of strings to > display, not the potentially complex data structure of an address book > contact. > > Having one of these complex structures in memory at a time is enough IMHO. Not at all. And it won't allow you to update informations like presence easily. > Should it be only for performance reasons: when the user scrolls down the list > by one contact, it is much quicker to retreive data from a prepared list of > strings than from the contact itself. The contact isn't that much more than strings... >> And notice >> that a same contact could be shown at several places through the user >> interface! > > Yes, and perharps displayed in different ways. Yes, that too. >>> No, and this article does not contain the word "roster" :-(. >> The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish >> them from 'live' contacts. >> >> The situation is that you may have jc@jabber.lat in your roster, with >> the information that the name is "Julius Caesar", and belongs to the >> groups "Politicians" and "Jokers". But when he connects from his pda, he >> will show up as jc@jabber.lat/pda, and will neither be able to do VoIP, >> nor receive XHTML messages. When he is home, he connects from his >> computer as jc@jabber.lat/home, and will be able to do both. Now he goes >> to work, from where he shows up as jc@jabber.lat/work, which can do >> XHTML messaging, but not VoIP. > > Aha. Yes, it's that bad :-/ >>> Thanks for your openess, Julien :-). >> No problem. More brains means better solutions :-) > > Yes, indeed. I hope my advice brings something constructive. As I told you in > private, you keep it or throw it, it's your decision. Last time you wrote that I ended throwing both your ideas and mines ;-) >>> I know. But I think it is always good to remove references to libraries >>> if you do not really need them. >> Well, glib is nice. The main problem KDE problem have with it is that it >> begins with a 'g' and is already used in GNOME. :-) > > Do not believe that. We are not religious people. For example, we are very > happy sharing libxml with GNOME. Even though there is already a XML API in > Qt! Just because libxml rocks... > > (oh yeah, there's no "g" in libxml... ;-) ) > > We already share libxml, desktop files, DocBook documentation, DBUS > communication, po translation memories, and many, many other things. Cool > apps like Ekiga can run in a KDE environment. Cool apps like ... errr... > KEuroCalc ;-) can run in a GNOME environment. And in fact I know that many > people do that. What is KEuroCalc ? > In fact, the more we will be able to share with you, the happier we will be. I > can ensure you that this has always been what we said, even during private > discussions at KDE meetings. This is why it's so important to have a good DBUS component. And this is made easier by using glib-object :-) > I do not know why we do not share glib. I have my ideas about that, but it's > just personal assumptions ;-). I can make a few guesses : 1) it does things that QT does ; 2) it does things that C++ STL does. Snark From ebischoff@nerim.net Thu Jun 8 15:38:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D9F313B054E for ; Thu, 8 Jun 2006 15:38:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32745-08 for ; Thu, 8 Jun 2006 15:38:37 -0400 (EDT) Received: from mallaury.nerim.net (smtp-104-thursday.noc.nerim.net [62.4.17.104]) by menubar.gnome.org (Postfix) with ESMTP id 3976E3B000E for ; Thu, 8 Jun 2006 15:38:35 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by mallaury.nerim.net (Postfix) with ESMTP id 1ED2F4F3A4 for ; Thu, 8 Jun 2006 21:38:22 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 21:38:46 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606081537.55137.ebischoff@nerim.net> <4488747B.6080906@free.fr> In-Reply-To: <4488747B.6080906@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606082138.46648.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.576 tagged_above=-999 required=2 tests=[AWL=0.023, BAYES_00=-2.599] X-Spam-Score: -2.576 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:38:40 -0000 Le Jeudi 8 Juin 2006 21:03, Julien PUYDT a =C3=A9crit=C2=A0: > > We already share libxml, desktop files, DocBook documentation, DBUS > > communication, po translation memories, and many, many other things. Co= ol > > apps like Ekiga can run in a KDE environment. Cool apps like ... errr... > > KEuroCalc ;-) can run in a GNOME environment. And in fact I know that > > many people do that. > > What is KEuroCalc ? Mentioning it was merely a joke: it's a small KDE app that I wrote. http://opensource.bureau-cornavin.com/keurocalc/ ;-) > > I do not know why we do not share glib. I have my ideas about that, but > > it's just personal assumptions ;-). > > I can make a few guesses : > 1) it does things that QT does ; > 2) it does things that C++ STL does. Exactly the same guesses as me ;-). It even does things that C++ _alone_ do= es. Best, =2D-=20 =C3=89ric From ph.l@libertysurf.fr Thu Jun 8 15:47:49 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9705F3B1039 for ; Thu, 8 Jun 2006 15:47:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00870-02 for ; Thu, 8 Jun 2006 15:47:38 -0400 (EDT) Received: from smtp4.mail.easynet.fr (smarthost169.mail.easynet.fr [212.180.1.169]) by menubar.gnome.org (Postfix) with ESMTP id 527163B1020 for ; Thu, 8 Jun 2006 15:47:35 -0400 (EDT) Received: from asi-236.asi256ip.easynet.fr ([212.180.39.236] helo=[145.111.24.1]) by smtp4.mail.easynet.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FoQUy-0004IP-Fg for gnomemeeting-devel-list@gnome.org; Thu, 08 Jun 2006 21:48:56 +0200 Message-ID: <44887ECE.9040902@libertysurf.fr> Date: Thu, 08 Jun 2006 21:47:26 +0200 From: Philippe Lefevre User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: gnomemeeting-devel-list@gnome.org References: <20060608160031.473BF3B0FB3@menubar.gnome.org> In-Reply-To: <20060608160031.473BF3B0FB3@menubar.gnome.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.436 tagged_above=-999 required=2 tests=[AWL=-0.853, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, TW_BX=0.077, TW_IB=0.077, TW_RW=0.077, TW_WX=0.077] X-Spam-Score: -1.436 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ekiga under windows X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ph.l@libertysurf.fr, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:47:49 -0000 Hello, Today I tried to install ekiga on my PC under XP and I never get anything to work :'( You'll find bellow what I did. I can do some other tests if it may in any help. PhiL My PC is running Windows XP SP1 1G memory. I installed GTK 2.0 (version 2.8.9.0) installed under C:\Program Files\Fichiers communs\GTK\2.0 and Ekiga (downloaded from CVS June 8, 2006) installed under C:\Program Files\Ekiga CYGWIN and MSYS are installed too with XP : nothing happen, no log (empty file even with -d 4 option) with MSYS : same issue $ echo $PATH .:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32: /c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/oracle9/bin:/c/oracle8/bin: /i/progicil/orawin2:/i/progicil/orawin2/bin: /c/Program Files/Microsoft SQL Server/80/Tools/BINN: /c/Program Files/Fichiers communs/GTK/2.0/bin:/c/php5: /c/php5/ext:/c/Program Files/MySQL/MySQL Server 5.0/bin: /c/bin:/c/cygdrive/c/cygwin/bin:/c/cygdrive/c/cygwin/sbin:/c/oracle9/bin: /c/oracle8/bin:/i/progicil/orawin2:/i/progicil/orawin2/bin: /c/Program Files/Ekiga:/c/caml/bin PHL@BORG /c/program files/ekiga $ ./ekiga.exe 1>log 2>&1 Log is empty $ ls -rwxr-xr-x 1 PHL Administ 7934464 May 16 05:26 ekiga.exe -rw-r--r-- 1 PHL Administ 1231950 May 16 05:26 ekiga.schemas -rwxr-xr-x 1 PHL Administ 44032 May 16 05:26 liblber.dll -rwxr-xr-x 1 PHL Administ 188416 May 16 05:26 libldap_r.dll -rwxr-xr-x 1 PHL Administ 1276928 May 16 05:26 libxml2-2.dll drwxr-xr-x 70 PHL Administ 0 Jun 8 09:52 locale -rw-r--r-- 1 PHL Administ 0 Jun 8 13:30 log Using GDB in a cygdrive environment : $ gdb ekiga.exe GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) (gdb) run Starting program: /cygdrive/c/Program Files/Ekiga/ekiga.exe Program received signal SIGSEGV, Segmentation fault. Program received signal SIGSEGV, Segmentation fault. Program exited with code 0200. You can't do that without a process to debug. (gdb) bt No stack. (gdb) From jpuydt@free.fr Thu Jun 8 15:50:47 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 143943B027F for ; Thu, 8 Jun 2006 15:50:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01017-01 for ; Thu, 8 Jun 2006 15:50:46 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id E67403B021A for ; Thu, 8 Jun 2006 15:50:45 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp3-g19.free.fr (Postfix) with ESMTP id C567B4901D; Thu, 8 Jun 2006 21:50:43 +0200 (CEST) Message-ID: <44887FCD.7040300@free.fr> Date: Thu, 08 Jun 2006 21:51:41 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: ph.l@libertysurf.fr, GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Ekiga under windows References: <20060608160031.473BF3B0FB3@menubar.gnome.org> <44887ECE.9040902@libertysurf.fr> In-Reply-To: <44887ECE.9040902@libertysurf.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.434 tagged_above=-999 required=2 tests=[AWL=-0.143, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077, TW_RW=0.077, TW_WX=0.077] X-Spam-Score: -2.434 X-Spam-Level: Cc: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:50:47 -0000 Philippe Lefevre a écrit : > Today I tried to install ekiga on my PC under XP and I never get > anything to work :'( Yes, we don't have a nice installer yet. > I installed GTK 2.0 (version 2.8.9.0) installed under > C:\Program Files\Fichiers communs\GTK\2.0 I'm wondering if that is recent enough. > CYGWIN and MSYS are installed too Unnecessary. > $ ls > -rwxr-xr-x 1 PHL Administ 7934464 May 16 05:26 ekiga.exe > -rw-r--r-- 1 PHL Administ 1231950 May 16 05:26 ekiga.schemas > -rwxr-xr-x 1 PHL Administ 44032 May 16 05:26 liblber.dll > -rwxr-xr-x 1 PHL Administ 188416 May 16 05:26 libldap_r.dll > -rwxr-xr-x 1 PHL Administ 1276928 May 16 05:26 libxml2-2.dll > drwxr-xr-x 70 PHL Administ 0 Jun 8 09:52 locale > -rw-r--r-- 1 PHL Administ 0 Jun 8 13:30 log No libSDL.dll or some such ? :-/ Snark From ph.l@libertysurf.fr Thu Jun 8 16:43:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 40F853B00EA for ; Thu, 8 Jun 2006 16:43:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04211-07 for ; Thu, 8 Jun 2006 16:43:38 -0400 (EDT) Received: from smtp3.mail.easynet.fr (smarthost168.mail.easynet.fr [212.180.1.168]) by menubar.gnome.org (Postfix) with ESMTP id 52BD23B000E for ; Thu, 8 Jun 2006 16:43:37 -0400 (EDT) Received: from asi-236.asi256ip.easynet.fr ([212.180.39.236] helo=[145.111.24.1]) by smtp3.mail.easynet.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FoRMF-0007kr-6F; Thu, 08 Jun 2006 22:43:59 +0200 Message-ID: <44888BF6.8020906@libertysurf.fr> Date: Thu, 08 Jun 2006 22:43:34 +0200 From: Philippe Lefevre User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: Julien PUYDT , gnomemeeting-devel-list@gnome.org References: <20060608160031.473BF3B0FB3@menubar.gnome.org> <44887ECE.9040902@libertysurf.fr> <44887FCD.7040300@free.fr> In-Reply-To: <44887FCD.7040300@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.283 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077, TW_RW=0.077, TW_WX=0.077] X-Spam-Score: -2.283 X-Spam-Level: Cc: Subject: [GnomeMeeting-devel-list] Re : Ekiga under windows X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ph.l@libertysurf.fr, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 20:43:39 -0000 Julien PUYDT a écrit : > Philippe Lefevre a écrit : > >> Today I tried to install ekiga on my PC under XP and I never get >> anything to work :'( > > > Yes, we don't have a nice installer yet. No pb, unzip works well for now. > >> I installed GTK 2.0 (version 2.8.9.0) installed under >> C:\Program Files\Fichiers communs\GTK\2.0 > > > I'm wondering if that is recent enough. > 2.8.9.0 is the latest stable version but there is a 2.8.15 too dated from March (still unstable ?) >> CYGWIN and MSYS are installed too > > > Unnecessary. > Of course. It's just to use dbg. (I installed it for other things anyway) >> $ ls >> -rwxr-xr-x 1 PHL Administ 7934464 May 16 05:26 ekiga.exe >> -rw-r--r-- 1 PHL Administ 1231950 May 16 05:26 ekiga.schemas >> -rwxr-xr-x 1 PHL Administ 44032 May 16 05:26 liblber.dll >> -rwxr-xr-x 1 PHL Administ 188416 May 16 05:26 libldap_r.dll >> -rwxr-xr-x 1 PHL Administ 1276928 May 16 05:26 libxml2-2.dll >> drwxr-xr-x 70 PHL Administ 0 Jun 8 09:52 locale >> -rw-r--r-- 1 PHL Administ 0 Jun 8 13:30 log > > > No libSDL.dll or some such ? :-/ > Sorry I don't think so. I will check tomorrow (it is on my PC at work) But, I just check the zip file... there is no libSDL (or name close to that) into it. > Snark > Thanks Julien. From mcquaidster@gmail.com Thu Jun 8 17:09:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DF4253B0622 for ; Thu, 8 Jun 2006 17:09:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05835-02 for ; Thu, 8 Jun 2006 17:09:06 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id 76D583B0F9D for ; Thu, 8 Jun 2006 17:09:06 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id z74so693545pyg for ; Thu, 08 Jun 2006 14:09:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=HVNAtak5n7Z91wpmXr/Qu5ON4YhH7Q4dCf+4y5GUbTwwY23VOAXrmjBMj7263bIU8fqFePgmvS6HIFqN59D2Jy6YmXM2xD1V+aMpky/Ed9jdEhbQxbJYZUEi6YN6vk99BkQspxK0SEsZWjsxDvHu3Rk9O5hKBW5HcpVNrhkyGCo= Received: by 10.35.63.2 with SMTP id q2mr2928428pyk; Thu, 08 Jun 2006 14:09:05 -0700 (PDT) Received: by 10.35.31.2 with HTTP; Thu, 8 Jun 2006 14:09:05 -0700 (PDT) Message-ID: <58a398810606081409o3026d11cnd9f5f3a16b0243e@mail.gmail.com> Date: Thu, 8 Jun 2006 17:09:05 -0400 From: "mcquaid mcquaid" To: "GnomeMeeting development mailing list" In-Reply-To: <58a398810606061625x7684427q73db38225fa398dc@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10127_1193274.1149800945207" References: <58a398810606061625x7684427q73db38225fa398dc@mail.gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.359 tagged_above=-999 required=2 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.359 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Re: no audio on incoming calls. X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 21:09:10 -0000 ------=_Part_10127_1193274.1149800945207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Can I get any assistance on this or is there something else I should be providing? I can get other voip apps like linphone working but I can't get ekiga to transmit audio either way on incoming calls. Not sure if it's any help but asterisk seems to behave in the same manner. With asterisk I again could make outgoing call fine, but for incoming it would route calls to my local sipphone, but no audio either way. On 6/6/06, mcquaid mcquaid wrote: > > I have tried ekiga from time to time, and now using the latest cvs, I > still have the same problem. > > On outgoing calls, audio transmits both ways without issue. > > When receiving a call, no audio is transmitted either way. > > I realize it'll probably be considered a firewall issue, but linphone has > always worked for me and I have never setup stun or a nat traversal method > in linphone. I'd prefer to use ekiga instead of linphone. > > Here is the output of an incoming call that lasts until ekiga reports > 'remote user cleared the call'. > > I tried ekiga lastest cvs as I read about 2.02 hoping this might have been > resolved. > > > > ------=_Part_10127_1193274.1149800945207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Can I get any assistance on this or is there something else I should be providing?  I can get other voip apps like linphone working but I can't get ekiga to transmit audio either way on incoming calls.  Not sure if it's any help but asterisk seems to behave in the same manner.  With asterisk I again could make outgoing call fine, but for incoming it would route calls to my local sipphone, but no audio either way.

On 6/6/06, mcquaid mcquaid <mcquaidster@gmail.com> wrote:
I have tried ekiga from time to time, and now using the latest cvs, I still have the same problem.

On outgoing calls, audio transmits both ways without issue.

When receiving a call, no audio is transmitted either way.

I realize it'll probably be considered a firewall issue, but linphone has always worked for me and I have never setup stun or a nat traversal method in linphone.  I'd prefer to use ekiga instead of linphone.

Here is the output of an incoming call that lasts until ekiga reports 'remote user cleared the call'.

I tried ekiga lastest cvs as I read about 2.02 hoping this might have been resolved.




------=_Part_10127_1193274.1149800945207-- From dsandras@seconix.com Fri Jun 9 03:56:41 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5D27B3B006E for ; Fri, 9 Jun 2006 03:56:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05479-07 for ; Fri, 9 Jun 2006 03:56:39 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 62A113B017E for ; Fri, 9 Jun 2006 03:56:39 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 2E8E349758 for ; Fri, 9 Jun 2006 09:38:49 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16204-09 for ; Fri, 9 Jun 2006 09:38:42 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 6559949755 for ; Fri, 9 Jun 2006 09:38:42 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Re: no audio on incoming calls. From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <58a398810606081409o3026d11cnd9f5f3a16b0243e@mail.gmail.com> References: <58a398810606061625x7684427q73db38225fa398dc@mail.gmail.com> <58a398810606081409o3026d11cnd9f5f3a16b0243e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 09 Jun 2006 09:56:30 +0200 Message-Id: <1149839790.3351.0.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 07:56:41 -0000 You should provide a debug 4 output. Le jeudi 08 juin 2006 à 17:09 -0400, mcquaid mcquaid a écrit : > Can I get any assistance on this or is there something else I should > be providing? I can get other voip apps like linphone working but I > can't get ekiga to transmit audio either way on incoming calls. Not > sure if it's any help but asterisk seems to behave in the same manner. > With asterisk I again could make outgoing call fine, but for incoming > it would route calls to my local sipphone, but no audio either way. > > On 6/6/06, mcquaid mcquaid wrote: > I have tried ekiga from time to time, and now using the latest > cvs, I still have the same problem. > > On outgoing calls, audio transmits both ways without issue. > > When receiving a call, no audio is transmitted either way. > > I realize it'll probably be considered a firewall issue, but > linphone has always worked for me and I have never setup stun > or a nat traversal method in linphone. I'd prefer to use > ekiga instead of linphone. > > Here is the output of an incoming call that lasts until ekiga > reports 'remote user cleared the call'. > > I tried ekiga lastest cvs as I read about 2.02 hoping this > might have been resolved. > > > > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From ph.l@libertysurf.fr Sat Jun 10 12:49:37 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 174BA3B01B8 for ; Sat, 10 Jun 2006 12:49:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15518-01 for ; Sat, 10 Jun 2006 12:49:36 -0400 (EDT) Received: from smtp4.mail.easynet.fr (smarthost169.mail.easynet.fr [212.180.1.169]) by menubar.gnome.org (Postfix) with ESMTP id C9C343B032B for ; Sat, 10 Jun 2006 12:49:35 -0400 (EDT) Received: from asi-236.asi256ip.easynet.fr ([212.180.39.236] helo=[145.111.24.1]) by smtp4.mail.easynet.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Fp6fr-0001ZY-Dc for gnomemeeting-devel-list@gnome.org; Sat, 10 Jun 2006 18:50:59 +0200 Message-ID: <448AF812.4010106@libertysurf.fr> Date: Sat, 10 Jun 2006 18:49:22 +0200 From: Philippe Lefevre User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: GnomeMeeting devel list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.839 tagged_above=-999 required=2 tests=[AWL=-1.437, BAYES_05=-1.11, DNS_FROM_RFC_POST=1.708] X-Spam-Score: -0.839 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ekiga 2.0.2 Ubuntu packages X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 16:49:37 -0000 Hi all, For a few days I'm looking for Ekiga 2.0.2 for ubuntu packages @ http://www.ekiga.org but there are no link available yet. Is this normal ? Thanks. PhiL From mathiaschulze@gmail.com Sun Jun 11 10:47:28 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7E1CC3B00B0 for ; Sun, 11 Jun 2006 10:47:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14779-09 for ; Sun, 11 Jun 2006 10:47:27 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by menubar.gnome.org (Postfix) with ESMTP id 6898E3B0084 for ; Sun, 11 Jun 2006 10:47:27 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id 9so1563867nzo for ; Sun, 11 Jun 2006 07:46:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=RdwAYw0jPdY9iOC0Sf+iOKQJ9I7YfnL/kWXyEPnc+Cr+QIVa1sKM88ZdFWngpOkudGwRUvtt1Aw9vAL7lpvseD6hTwpLtjhbhu306m/DpJDRigRtWN/PSaYRcSohSjgiAaMN7SNdOXCHLIjQ0ZzdPpKX46kbgKn0qo2/Dg4UYbo= Received: by 10.37.2.45 with SMTP id e45mr7180725nzi; Sun, 11 Jun 2006 07:46:45 -0700 (PDT) Received: from vaio ( [71.98.110.104]) by mx.gmail.com with ESMTP id 37sm151203nzf.2006.06.11.07.46.44; Sun, 11 Jun 2006 07:46:45 -0700 (PDT) From: Mathias Schulze To: gnomemeeting-devel-list@gnome.org Content-Type: text/plain Date: Sun, 11 Jun 2006 10:46:43 -0400 Message-Id: <1150037203.24558.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.821 tagged_above=-999 required=2 tests=[AWL=-0.779, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.821 X-Spam-Level: Subject: [GnomeMeeting-devel-list] alsa default device X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 14:47:28 -0000 Hello, I would like to make Ekiga automatically use my USB Headset whenever it is plugged in. It is no problem to switch the default device to the headset by a udev rule. But Ekiga seems to ignore any changes of the default device after start-up. I think if the default device is selected Ekiga should check the current default device immediately before starting the conversation. So if someone calls I can plug in the USB headset and accept the call. An example of a program which seems to do this is the gnome music player "Listen". An even better solution (but maybe too much work?) could be if Ekiga pops up a request whenever a new audio device appears to ask the user if this device should be used. Such request appears e.g. under Ubuntu in the control panel. Thanks for Ekiga, it's really great! Mathias From dsandras@seconix.com Mon Jun 12 04:46:20 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EDE963B00D8 for ; Mon, 12 Jun 2006 04:46:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26328-09 for ; Mon, 12 Jun 2006 04:46:16 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id B27083B009D for ; Mon, 12 Jun 2006 04:46:16 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 8BE0B83C22 for ; Mon, 12 Jun 2006 10:26:53 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29245-09 for ; Mon, 12 Jun 2006 10:26:48 +0200 (CEST) Received: from [192.168.0.161] (157.137-245-81.adsl-dyn.isp.belgacom.be [81.245.137.157]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id BF7E583C1F for ; Mon, 12 Jun 2006 10:26:48 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Ekiga 2.0.2 Ubuntu packages From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <448AF812.4010106@libertysurf.fr> References: <448AF812.4010106@libertysurf.fr> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 12 Jun 2006 10:46:31 +0200 Message-Id: <1150101991.2505.12.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 08:46:20 -0000 Le samedi 10 juin 2006 à 18:49 +0200, Philippe Lefevre a écrit : > Hi all, > For a few days I'm looking for Ekiga 2.0.2 for ubuntu packages @ > http://www.ekiga.org > but there are no link available yet. Is this normal ? They are coming soon... -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Mon Jun 12 08:26:32 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 96E503B0061 for ; Mon, 12 Jun 2006 08:26:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01773-10 for ; Mon, 12 Jun 2006 08:26:29 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 0BDDA3B000D for ; Mon, 12 Jun 2006 08:26:28 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id A4ACC83C24 for ; Mon, 12 Jun 2006 13:43:24 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15346-08 for ; Mon, 12 Jun 2006 13:43:15 +0200 (CEST) Received: from [192.168.0.161] (157.137-245-81.adsl-dyn.isp.belgacom.be [81.245.137.157]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 3FB8E83C22 for ; Mon, 12 Jun 2006 13:43:15 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] alsa default device From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <1150037203.24558.24.camel@localhost.localdomain> References: <1150037203.24558.24.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 12 Jun 2006 14:03:41 +0200 Message-Id: <1150113821.7909.5.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 12:26:32 -0000 Hi, Le dimanche 11 juin 2006 à 10:46 -0400, Mathias Schulze a écrit : > Hello, > > I would like to make Ekiga automatically use my USB Headset whenever it > is plugged in. It is no problem to switch the default device to the > headset by a udev rule. But Ekiga seems to ignore any changes of the > default device after start-up. > It is most probably due to ALSA and libasound if I understand correctly what you mean. If you change from "USB Headset" to "Soundcard" or to "Default", Ekiga will work correctly. However, you probably mean that you want to select "Default" as device in Ekiga and that "Default" will be linked to the USB headset or to the soundcard depending if the headset is plugged in or not. For Ekiga, it is transparent. Ekiga simply open the "Default" device when playing sounds. If the "Default" device is linked in real time to the USB headset while Ekiga is running, and if it still uses the sound card, then it means that libasound already mapped the default device to the soundcard when starting the application and doesn't accept changing it. So I would say that I'm 100% confident it is an ALSA limitation. However, I tried here changing the settings of my default device through .asoundrc when Ekiga is running and it works. > I think if the default device is selected Ekiga should check the current > default device immediately before starting the conversation. So if > someone calls I can plug in the USB headset and accept the call. > An example of a program which seems to do this is the gnome music player > "Listen". It is transparent for Ekiga. Ekiga opens the "Default" device whatever it is through ALSA. > > An even better solution (but maybe too much work?) could be if Ekiga > pops up a request whenever a new audio device appears to ask the user if > this device should be used. Such request appears e.g. under Ubuntu in > the control panel. It is planned in the future through HAL. > > Thanks for Ekiga, it's really great! > Mathias > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Mon Jun 12 17:23:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 441F03B01DB for ; Mon, 12 Jun 2006 17:23:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31653-03 for ; Mon, 12 Jun 2006 17:23:08 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 994B13B0010 for ; Mon, 12 Jun 2006 17:23:08 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 666F683C23 for ; Mon, 12 Jun 2006 23:01:22 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19698-06 for ; Mon, 12 Jun 2006 23:01:18 +0200 (CEST) Received: from [192.168.0.161] (157.137-245-81.adsl-dyn.isp.belgacom.be [81.245.137.157]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id AFAEE83C22 for ; Mon, 12 Jun 2006 23:01:18 +0200 (CEST) From: Damien Sandras To: gnomemeeting-devel-list@gnome.org Content-Type: text/plain Date: Mon, 12 Jun 2006 23:24:02 +0200 Message-Id: <1150147442.11823.2.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Subject: [GnomeMeeting-devel-list] New user interface : first stubs X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 21:23:10 -0000 Hi to all, I committed the first stubs of the new user interface. Please do not criticize too much as it is work in progress and it is in the very early stages of development. Julien is working on big changes too, but that should have no impact on the user interface. In the next few weeks, I will work more on : - the user interface - sip support (integrate Craig's changes) And finally work on a roster. Enjoy, -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From jpuydt@free.fr Tue Jun 13 13:58:03 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 530F33B03CF for ; Tue, 13 Jun 2006 13:58:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01110-02 for ; Tue, 13 Jun 2006 13:58:01 -0400 (EDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by menubar.gnome.org (Postfix) with ESMTP id EC4F23B00DB for ; Tue, 13 Jun 2006 13:58:00 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by postfix1-c.free.fr (Postfix) with ESMTP id 91A4B1CF1DC3 for ; Tue, 13 Jun 2006 17:47:25 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-32-82-254-24-205.adsl.proxad.net [82.254.24.205]) by smtp6-g19.free.fr (Postfix) with ESMTP id CD69E2286C for ; Tue, 13 Jun 2006 18:42:21 +0200 (CEST) Message-ID: <448EC473.7060800@free.fr> Date: Tue, 13 Jun 2006 15:58:11 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <448B2A40.5060600@free.fr> <20060612174347.5181a8f9@localhost.localdomain> <448DABA7.4060103@free.fr> <200606130951.56969.ebischoff@nerim.net> In-Reply-To: <200606130951.56969.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.567 tagged_above=-999 required=2 tests=[AWL=0.032, BAYES_00=-2.599] X-Spam-Score: -2.567 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 17:58:03 -0000 Hi, in private mails (with quite big attachments since I provided some sample stupid code), Éric Bischoff found my code not that explicit concerning what I have in mind. Since I would like to keep things as opened as possible, I drop my text here :-) Let's see if I can manage to give useful ideas. ***** BIG WORDS Model - View - Controller ***** VIEWING (GENERIC) We need to be able to present a book to the user. For that, the view needs to have a list of contacts (no, a single contact definitely isn't enough!). So we need a function call to get a list of contacts. The problem is that this list will change during time (new contacts added, others removed, presence changed, status message changed, and the list goes on). So the view will need to be notified about it. Hence the idea that the book will have "contact-added" and "contact-removed" signals, and the contacts a "updated" signal. In addition to that, there is an interesting special case to handle : you have a contact in a book, and this contact shows up in a search result. When you remove the contact from the book, we want to make it disappear from the list too. Hence a "removed" signal for contacts. Now this is all nice, but what can we do if an addressbook contains millions of entries ? And if a search gives thousands of results ? In such cases, my stance is that the low level code should do something about it, since it is the one giving the problem. How can the high level code cope correctly with the situation anyway ? Only the low level code can say "Eh, I already made two hundred contacts go through the wire for that search, perhaps I should make it easy!". The question to really ask, and to which I have no satisfactory answer is: "How do me make the low level tell the high level it had to cut the list ?". ***** VIEWING (CONTACTS) The contacts should contain enough to be viewed from a generic view in the contacts window, and be shown in a search result. That won't prevent some other parts of the code to make a better use of them. For example, in the contact window we will probably be able to see a contact's title and description, but not its detailed presence, while the main window will contain a much better and more specific view for the live contacts. ***** CONTROLLING (GENERIC) Now, we want to be able to act on our objects ; say rename a book or a contact, subscribe/unsubscribe to its presence, etc. The best thing to do is to be able to get menus for each of them. Notice the plural: we will certainly to have at least menu in the menu bar and a popup menu. The first bad news about such menus is that they won't be generic : they will depend heavily on the specific type of object (no rename for avahi contacts, subscribe/unsubscribe only for XMPP contacts...). So we will certainly need some sort of shared actions that will be basic bricks for building menu (like the shared-actions.[ch] of my first round of proposals), that each implementation will mix as it sees fit. The second bad news about them is that they won't be static either. They will have to update themselves following the object they are attached to. Say your nice XMPP contact is connected with a client which has VoIP support, but now connects with a no-VoIP client, and disconnects the first : we want the "Call" menuitem to disappear to reflect this. So my proposition (no code yet) is that those menus will be obtained by subclassing of GtkMenu, register to get signals from the contact/book they are attached to, and use that to keep themselves up to date. ***** CONTROLLING (CONTACTS) Let's try to be more specific: in avahi-contact-menu.h, we would have: GtkWidget *avahi_contact_menu_new (AvahiContact *contact); and in gm-contact.h: GtkWidget *gm_contact_get_menu_new (GmContact *contact); This later function would be different in each implementation, which allows for example the avahi_contact_get_menu_new implementation to call avahi_contact_menu_new. The high level code called a generic function, but got access to a very specific implementation, which knows the full api of the specific contact, and hence will provide the best service. ***** CONTROLLING (BOOKS) Perhaps the menu shouldn't be attached to the book himself, but to its view. That would allow to place things such as "Show offline contacts" in it. Mostly the idea would be to have controllers for both the model-as-model and its view-as-model. ***** ABOUT EVOLUTION-DATA-SERVER The evolution-data-server api looks pretty good -- except that it seems to mainly handle static vcard-based contacts, where I would like to be able to handle things like. For example, we find a nice contacts-changed signal, but in the EBookView api... not in the EBook api, which seems strange. ***** ABOUT LIBGAIM I shriek everytime I read/think about that comment in blist.h (just before the declaration of struct _GaimBuddy) : "A buddy. This contains everything Gaim will ever need to know about someone on the buddy list. Everything." (sic). and that one (before the declaration of struct _GaimContact) : "A contact. This contains everything Gaim will ever need to know about a contact." and that one (before the declaration of struct _GaimGroup) : "A group. This contains everything Gaim will ever need to know about a group." Notice that the comment before struct _GaimChat, although very similar, isn't so bad in my eye :-) Notice too that although I find the way it is done inelegant, it still is very good and efficient to get the job done, and contains quite an impressive list of good ideas. (And it's more portable as ekiga, gasp!) ***** ABOUT LIBGALAGO Why, why, oh why does it contain a GalagoList api which looks so much like a GList but isn't !? Apart from that, I would say it looks nice, but is out of scope for what we want to do right now : it doesn't deal with addressbooks, but with persons as single. "Using" it would be nice at some point. ***** LAST WORDS Congratulations, comments and flames welcome, but flames will end in /dev/null. Snark From jpuydt@free.fr Thu Jun 15 04:55:35 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7B51D3B008E for ; Thu, 15 Jun 2006 04:55:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24192-02 for ; Thu, 15 Jun 2006 04:55:31 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id C36A43B00CA for ; Thu, 15 Jun 2006 04:55:30 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp3-g19.free.fr (Postfix) with ESMTP id 26E1F496DD for ; Thu, 15 Jun 2006 10:54:59 +0200 (CEST) Message-ID: <4491205F.5070708@free.fr> Date: Thu, 15 Jun 2006 10:54:55 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.369 tagged_above=-999 required=2 tests=[AWL=0.230, BAYES_00=-2.599] X-Spam-Score: -2.369 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 08:55:35 -0000 Hi, in private mails (with quite big attachments since I provided some sample stupid code), Éric Bischoff found my code not that explicit concerning what I have in mind. Since I would like to keep things as opened as possible, I drop my text here :-) Let's see if I can manage to give useful ideas. ***** BIG WORDS Model - View - Controller ***** VIEWING (GENERIC) We need to be able to present a book to the user. For that, the view needs to have a list of contacts (no, a single contact definitely isn't enough!). So we need a function call to get a list of contacts. The problem is that this list will change during time (new contacts added, others removed, presence changed, status message changed, and the list goes on). So the view will need to be notified about it. Hence the idea that the book will have "contact-added" and "contact-removed" signals, and the contacts a "updated" signal. In addition to that, there is an interesting special case to handle : you have a contact in a book, and this contact shows up in a search result. When you remove the contact from the book, we want to make it disappear from the list too. Hence a "removed" signal for contacts. Now this is all nice, but what can we do if an addressbook contains millions of entries ? And if a search gives thousands of results ? In such cases, my stance is that the low level code should do something about it, since it is the one giving the problem. How can the high level code cope correctly with the situation anyway ? Only the low level code can say "Eh, I already made two hundred contacts go through the wire for that search, perhaps I should make it easy!". The question to really ask, and to which I have no satisfactory answer is: "How do me make the low level tell the high level it had to cut the list ?". ***** VIEWING (CONTACTS) The contacts should contain enough to be viewed from a generic view in the contacts window, and be shown in a search result. That won't prevent some other parts of the code to make a better use of them. For example, in the contact window we will probably be able to see a contact's title and description, but not its detailed presence, while the main window will contain a much better and more specific view for the live contacts. ***** CONTROLLING (GENERIC) Now, we want to be able to act on our objects ; say rename a book or a contact, subscribe/unsubscribe to its presence, etc. The best thing to do is to be able to get menus for each of them. Notice the plural: we will certainly to have at least menu in the menu bar and a popup menu. The first bad news about such menus is that they won't be generic : they will depend heavily on the specific type of object (no rename for avahi contacts, subscribe/unsubscribe only for XMPP contacts...). So we will certainly need some sort of shared actions that will be basic bricks for building menu (like the shared-actions.[ch] of my first round of proposals), that each implementation will mix as it sees fit. The second bad news about them is that they won't be static either. They will have to update themselves following the object they are attached to. Say your nice XMPP contact is connected with a client which has VoIP support, but now connects with a no-VoIP client, and disconnects the first : we want the "Call" menuitem to disappear to reflect this. So my proposition (no code yet) is that those menus will be obtained by subclassing of GtkMenu, register to get signals from the contact/book they are attached to, and use that to keep themselves up to date. ***** CONTROLLING (CONTACTS) Let's try to be more specific: in avahi-contact-menu.h, we would have: GtkWidget *avahi_contact_menu_new (AvahiContact *contact); and in gm-contact.h: GtkWidget *gm_contact_get_menu_new (GmContact *contact); This later function would be different in each implementation, which allows for example the avahi_contact_get_menu_new implementation to call avahi_contact_menu_new. The high level code called a generic function, but got access to a very specific implementation, which knows the full api of the specific contact, and hence will provide the best service. ***** CONTROLLING (BOOKS) Perhaps the menu shouldn't be attached to the book himself, but to its view. That would allow to place things such as "Show offline contacts" in it. Mostly the idea would be to have controllers for both the model-as-model and its view-as-model. ***** ABOUT EVOLUTION-DATA-SERVER The evolution-data-server api looks pretty good -- except that it seems to mainly handle static vcard-based contacts, where I would like to be able to handle things like. For example, we find a nice contacts-changed signal, but in the EBookView api... not in the EBook api, which seems strange. ***** ABOUT LIBGAIM I shriek everytime I read/think about that comment in blist.h (just before the declaration of struct _GaimBuddy) : "A buddy. This contains everything Gaim will ever need to know about someone on the buddy list. Everything." (sic). and that one (before the declaration of struct _GaimContact) : "A contact. This contains everything Gaim will ever need to know about a contact." and that one (before the declaration of struct _GaimGroup) : "A group. This contains everything Gaim will ever need to know about a group." Notice that the comment before struct _GaimChat, although very similar, isn't so bad in my eye :-) Notice too that although I find the way it is done inelegant, it still is very good and efficient to get the job done, and contains quite an impressive list of good ideas. (And it's more portable as ekiga, gasp!) ***** ABOUT LIBGALAGO Why, why, oh why does it contain a GalagoList api which looks so much like a GList but isn't !? Apart from that, I would say it looks nice, but is out of scope for what we want to do right now : it doesn't deal with addressbooks, but with persons as single. "Using" it would be nice at some point. ***** LAST WORDS Congratulations, comments and flames welcome, but flames will end in /dev/null. Snark PS: this message is already two or three days old... but got stuck. From ebischoff@nerim.net Thu Jun 15 07:18:00 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 98B4A3B032E for ; Thu, 15 Jun 2006 07:18:00 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01896-02 for ; Thu, 15 Jun 2006 07:17:57 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id 2C6AF3B0488 for ; Thu, 15 Jun 2006 07:17:56 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 3CBA240F45 for ; Thu, 15 Jun 2006 13:17:52 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Thu, 15 Jun 2006 13:18:05 +0200 User-Agent: KMail/1.8.2 References: <4491205F.5070708@free.fr> In-Reply-To: <4491205F.5070708@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606151318.05338.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.578 tagged_above=-999 required=2 tests=[AWL=0.021, BAYES_00=-2.599] X-Spam-Score: -2.578 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 11:18:01 -0000 Hi Julien, and thanks for this nice document. That looks like a good basis for thinkin= g=20 aloud :-). Le Jeudi 15 Juin 2006 10:54, Julien PUYDT a =C3=A9crit=C2=A0: > ***** BIG WORDS > > Model - View - Controller Excellent basis. > ***** VIEWING (GENERIC) > > We need to be able to present a book to the user. For that, the view > needs to have a list of contacts (no, a single contact definitely isn't > enough!). So we need a function call to get a list of contacts. In this paragraph I will assume that you mean "the view needs a list of all= =20 contacts from the address book driver". If it is not what you mean, please= =20 ignore this paragraph... The view needs to display, say, 10 contects at a time. No need to keep a li= st=20 of all contacts in memory. All we "need" is a function that gets _one_ contact from the driver. The vi= ew=20 can then use this information to keep the list of the 10 contacts that it=20 currently displays. > The problem is that this list will change during time (new contacts > added, others removed, presence changed, status message changed, and the > list goes on). So the view will need to be notified about it. Hence the > idea that the book will have "contact-added" and "contact-removed" > signals, and the contacts a "updated" signal. > In addition to that, there is an interesting special case to handle : > you have a contact in a book, and this contact shows up in a search > result. When you remove the contact from the book, we want to make it > disappear from the list too. Hence a "removed" signal for contacts. While this sounds cool, I am not sure that this will be possible in some=20 circumstances. The underlying address book (evolution, KDE address book, LD= AP=20 server, Zeroconf, ...) might not have the mechanisms to send such a signal. I can imagine situations where some users on machine A update a LDAP server= on=20 machine B while Ekiga runs on machine C, with the network connection betwee= n=20 B and C being temporarily broken. Will an update message come up to the=20 driver, and if yes when and how? Please notice that I do not know LDAP well and that such mechanisms might=20 exist. Should that be the case, please ignore these paragraphs. What do I propose instead? To be less ambitious, and have an address book t= hat=20 only pulls the data from the data source. If the user does not press=20 "refresh", then he/she might have outdated information. If he/she presses=20 "refresh", then the addresses are fetched again from the source. > Now this is all nice, but what can we do if an addressbook contains > millions of entries ? And if a search gives thousands of results ? In > such cases, my stance is that the low level code should do something > about it, since it is the one giving the problem. I do not like that repartition of tasks. Let me take an example. When you write an operating system, you write: =2D disk drivers (the low level code that does physical read and write from and to the hard disk) =2D a filesystem (the high level code that gathers individual sectors into files, handles a cache, etc) The low level code should not be bothered with handling the disk cache. Oka= y,=20 the problem comes from the disk driver, because it does slow access to the= =20 medium. That does not mean that it's not another component, the filesystem,= =20 that can solve it. Why this repartition of tasks? Because the performance problem is a problem= =20 that can be shared by many disk drivers. Therefore, the solution can be put= =20 in common in the high level code. > How can the high level > code cope correctly with the situation anyway ? Only the low level code > can say "Eh, I already made two hundred contacts go through the wire for > that search, perhaps I should make it easy!". Why transfer 200 contacts when the view knows that it needs only 10? > The question to really ask, and to which I have no satisfactory answer > is: "How do me make the low level tell the high level it had to cut the > list ?". The views know that contacts 301 to 309 are displayed. It's the view that=20 knows where to cut. In fact, there's nothing to cut, since all the view doe= s=20 is ask the driver for the contects it needs. > ***** VIEWING (CONTACTS) > > The contacts should contain enough to be viewed from a generic view in > the contacts window, and be shown in a search result. That won't prevent > some other parts of the code to make a better use of them. > > For example, in the contact window we will probably be able to see a > contact's title and description, but not its detailed presence, while > the main window will contain a much better and more specific view for > the live contacts. You say that the "contact" class must have _enough_ information to be used= =20 both in situation A and in sitation B. It would be better to have _different_ "contact" classes for situations "A"= =20 and "B". The list of contacts could just manage a name, a company and a phone number= =2E=20 The search result could handle much more detailed information. In other words, there's no need to put all the model's data into the views'= =20 data. Each view can handle the data it needs. > ***** CONTROLLING (GENERIC) > > Now, we want to be able to act on our objects ; say rename a book or a > contact, subscribe/unsubscribe to its presence, etc. > > The best thing to do is to be able to get menus for each of them. Notice > the plural: we will certainly to have at least menu in the menu bar and > a popup menu. > > The first bad news about such menus is that they won't be generic : they > will depend heavily on the specific type of object (no rename for avahi > contacts, subscribe/unsubscribe only for XMPP contacts...). So we will > certainly need some sort of shared actions that will be basic bricks for > building menu (like the shared-actions.[ch] of my first round of > proposals), that each implementation will mix as it sees fit. I assume here that an 'implementation" is one of the address book drivers, = and=20 that you mean that the drivers will be in charge of building menus. If thos= e=20 assumptions are wrong, the paragraph below does not apply, please just igno= re=20 it. Just the same as a hard disk driver does not display menus to the user, I=20 think that the address book drivers in Ekiga should not be responsible for= =20 user interaction. The high level code should be responsible for that. Of course the contents = of=20 the various menus depends on the address book capabilities. That's why the= =20 API between the driver and the high level code should include "query=20 capabilities functions:" class addressBook { virtual bool isReadOnly() =3D 0; virtual bool canSubscribeContacts() =3D 0; ... }; > The second bad news about them is that they won't be static either. They > will have to update themselves following the object they are attached > to. Say your nice XMPP contact is connected with a client which has VoIP > support, but now connects with a no-VoIP client, and disconnects the > first : we want the "Call" menuitem to disappear to reflect this. > > So my proposition (no code yet) is that those menus will be obtained by > subclassing of GtkMenu, register to get signals from the contact/book > they are attached to, and use that to keep themselves up to date. In your example, a signal is not needed. Knowing that there is no VoIP number in the current contact is enough. > ***** CONTROLLING (CONTACTS) > > Let's try to be more specific: > in avahi-contact-menu.h, we would have: > GtkWidget *avahi_contact_menu_new (AvahiContact *contact); > and in gm-contact.h: > GtkWidget *gm_contact_get_menu_new (GmContact *contact); > > This later function would be different in each implementation, which > allows for example the avahi_contact_get_menu_new implementation to call > avahi_contact_menu_new. The high level code called a generic function, > but got access to a very specific implementation, which knows the full > api of the specific contact, and hence will provide the best service. Again, this logic should be in the high-level code and needs not be=20 avahi-specific. What exactly should be presented to the user could be=20 determined from querying the address book for its capabilities. > ***** CONTROLLING (BOOKS) > > Perhaps the menu shouldn't be attached to the book himself, but to its > view. That would allow to place things such as "Show offline contacts" > in it. Mostly the idea would be to have controllers for both the > model-as-model and its view-as-model. Agree. > ***** ABOUT EVOLUTION-DATA-SERVER > > The evolution-data-server api looks pretty good -- except that it seems > to mainly handle static vcard-based contacts, where I would like to be > able to handle things like. > > For example, we find a nice contacts-changed signal, but in the > EBookView api... not in the EBook api, which seems strange. > > ***** ABOUT LIBGAIM > > I shriek everytime I read/think about that comment in blist.h (just > before the declaration of struct _GaimBuddy) : > "A buddy. This contains everything Gaim will ever need to know about > someone on the buddy list. Everything." (sic). > and that one (before the declaration of struct _GaimContact) : > "A contact. This contains everything Gaim will ever need to know about > a contact." > and that one (before the declaration of struct _GaimGroup) : > "A group. This contains everything Gaim will ever need to know about a > group." > > Notice that the comment before struct _GaimChat, although very similar, > isn't so bad in my eye :-) > > Notice too that although I find the way it is done inelegant, it still > is very good and efficient to get the job done, and contains quite an > impressive list of good ideas. (And it's more portable as ekiga, gasp!) > > ***** ABOUT LIBGALAGO > > Why, why, oh why does it contain a GalagoList api which looks so much > like a GList but isn't !? > > Apart from that, I would say it looks nice, but is out of scope for what > we want to do right now : it doesn't deal with addressbooks, but with > persons as single. > > "Using" it would be nice at some point. > > ***** LAST WORDS > > Congratulations, comments and flames welcome, but flames will end in > /dev/null. It definitly deserves congratulations. You forgot to mention one of your ni= ce=20 ideas, that it that it should be possible to search in several address book= s=20 at a time. =46or the comments, please note that my comments are based on a lot of=20 assumptions and guesses. In particular, I assume that you have in mind a=20 different assignment of tasks of the various software layers than the one=20 that I would like to see. If those assumptions reveal wrong, then of course= =20 my comments do not make much sense. If I did not misinterpret your thoughts, you have a very lazy view of the=20 high-level code. It's software that sits down and waits for signals to act.= =20 Somehow, the high level code provides "services" to the drivers. The driver= s=20 are the ones who understand what's going on. I have the opposite view: the address book drivers are simple and stupid.=20 Their main task is to go and fetch the requested contacts. The high level=20 code has an active attitude: it queries the drivers for contacts, it querie= s=20 the drivers capabilities, it displays the contact windows, it handles the=20 menues... The high level code has the real intelligence. I hope that helps, =2D-=20 Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m=C3=A9dire." (Le concombre masqu=C3=A9, Mandriva) From kk@verfaction.de Thu Jun 15 10:03:55 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C686B3B0336 for ; Thu, 15 Jun 2006 10:03:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15471-01 for ; Thu, 15 Jun 2006 10:03:54 -0400 (EDT) Received: from mx.verfaction.de (mx.verfaction.de [212.9.177.23]) by menubar.gnome.org (Postfix) with ESMTP id 779793B00CE for ; Thu, 15 Jun 2006 10:03:54 -0400 (EDT) Received: from erebos.verfaction.de ([2001:14b0:201:7357::1] helo=homemx.verfaction.de ident=Debian-exim) by mx.verfaction.de with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FqsRp-0003kA-3Z for gnomemeeting-devel-list@gnome.org; Thu, 15 Jun 2006 16:03:52 +0200 Received: from ganymede.kk.de ([192.168.7.10]) by homemx.verfaction.de with esmtp (Exim 4.50) id 1FqsRk-0000ld-Dw for gnomemeeting-devel-list@gnome.org; Thu, 15 Jun 2006 16:03:48 +0200 From: Kilian Krause To: GnomeMeeting development mailing list In-Reply-To: <200606081002.37875.conrad_videokonferenz@gmx.de> References: <200606081002.37875.conrad_videokonferenz@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aitPD1cXT483JdjYdYcu" Date: Thu, 15 Jun 2006 16:03:43 +0200 Message-Id: <1150380224.6599.22.camel@ganymede.verfaction.de> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-SA-Exim-Connect-IP: 2001:14b0:201:7357::1 X-SA-Exim-Mail-From: kk@verfaction.de X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 14:03:56 -0000 --=-aitPD1cXT483JdjYdYcu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hey Conrad, Am Donnerstag, den 08.06.2006, 10:02 +0000 schrieb Conrad Beckert: > has anybody an idea where the Debian packages for Ekiga 2.0.2 (or the=20 > corresponding CVS versions) are? on their way. > The last version I can install using apt-get a couple of days old (May 25= - or=20 > somethin) - at least this is a version with the nonfunctional German loc= ale.=20 > (defaults to English) >=20 > What's up? /me is having a sheer lack of time and thus it took me a while to get everything polished and fixed just like i love to have it. =3D) Everything should be back to normal as of tonight (eventually sarge cvs snaps and win32 will remain for the weekend - we'll see) --=20 Best regards, Kilian --=-aitPD1cXT483JdjYdYcu Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEkWi/vdkzt4X+wX8RAnZ/AJoCW2qvo1l8kFsAJzogWEPKv73LUACZAZk6 n6VWZ1JiCCXnGNsq5yEsLwU= =VwN+ -----END PGP SIGNATURE----- --=-aitPD1cXT483JdjYdYcu-- From jpuydt@free.fr Thu Jun 15 11:41:17 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D25F23B0616 for ; Thu, 15 Jun 2006 11:41:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20025-08 for ; Thu, 15 Jun 2006 11:41:15 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id 8BF5B3B041B for ; Thu, 15 Jun 2006 11:41:14 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp6-g19.free.fr (Postfix) with ESMTP id 3FD8B227D9 for ; Thu, 15 Jun 2006 17:40:32 +0200 (CEST) Message-ID: <44917F71.10408@free.fr> Date: Thu, 15 Jun 2006 17:40:33 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> In-Reply-To: <200606151318.05338.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.337 tagged_above=-999 required=2 tests=[AWL=0.185, BAYES_00=-2.599, TW_AV=0.077] X-Spam-Score: -2.337 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:41:18 -0000 Éric Bischoff a écrit : >> ***** VIEWING (GENERIC) >> >> We need to be able to present a book to the user. For that, the view >> needs to have a list of contacts (no, a single contact definitely isn't >> enough!). So we need a function call to get a list of contacts. > > In this paragraph I will assume that you mean "the view needs a list of all > contacts from the address book driver". If it is not what you mean, please > ignore this paragraph... Well, all contacts may be asking too much. I expect drivers to keep things sane. > The view needs to display, say, 10 contects at a time. No need to keep a list > of all contacts in memory. > > All we "need" is a function that gets _one_ contact from the driver. The view > can then use this information to keep the list of the 10 contacts that it > currently displays. Blah. If you're gonna loop on a list of contacts anyway, then get the list at once. Saying "I get only the 10 I need" is nice, but how do you tell the driver which they are ? Especially a roster XMPP generally comes as a single roster push you ask for when connecting, then little update pushes. >> The problem is that this list will change during time (new contacts >> added, others removed, presence changed, status message changed, and the >> list goes on). So the view will need to be notified about it. Hence the >> idea that the book will have "contact-added" and "contact-removed" >> signals, and the contacts a "updated" signal. >> In addition to that, there is an interesting special case to handle : >> you have a contact in a book, and this contact shows up in a search >> result. When you remove the contact from the book, we want to make it >> disappear from the list too. Hence a "removed" signal for contacts. > > While this sounds cool, I am not sure that this will be possible in some > circumstances. The underlying address book (evolution, KDE address book, LDAP > server, Zeroconf, ...) might not have the mechanisms to send such a signal. No problem : then they don't. Let's take the avahi book. It will probably update the list of users regularly (and have some action to update *now*). How will it work ? Well, it will populate a cache with those contacts, and on updating, flush it ("contact-removed" emitted on all of them), then repopulate it ("contact-added"). > I can imagine situations where some users on machine A update a LDAP server on > machine B while Ekiga runs on machine C, with the network connection between > B and C being temporarily broken. Will an update message come up to the > driver, and if yes when and how? If the backend doesn't give incremental changes, that still fits in my design. > What do I propose instead? To be less ambitious, and have an address book that > only pulls the data from the data source. If the user does not press > "refresh", then he/she might have outdated information. If he/she presses > "refresh", then the addresses are fetched again from the source. Bad. If the backend gives incremental changes, you don't handle it. Such a design works only for the most simple backends. >> Now this is all nice, but what can we do if an addressbook contains >> millions of entries ? And if a search gives thousands of results ? In >> such cases, my stance is that the low level code should do something >> about it, since it is the one giving the problem. > > I do not like that repartition of tasks. > > Let me take an example. When you write an operating system, you write: > - disk drivers > (the low level code that does physical read and write from and to > the hard disk) > - a filesystem > (the high level code that gathers individual sectors into files, > handles a cache, etc) > > The low level code should not be bothered with handling the disk cache. Okay, > the problem comes from the disk driver, because it does slow access to the > medium. That does not mean that it's not another component, the filesystem, > that can solve it. > > Why this repartition of tasks? Because the performance problem is a problem > that can be shared by many disk drivers. Therefore, the solution can be put > in common in the high level code. Your file manager doesn't handle the filesystems itself : they all present the same interface, and take care of caching themselves. I want the addressbook manager to be *high* level. If some caching is needed between the addressbook manager and the backend, I want the driver to take care of it. In fact, I implemented a SearchBook to take care of presenting all search results (whatever the book), and it's certainly desirable to provide a CachedBook, which will avoid code duplication. >> How can the high level >> code cope correctly with the situation anyway ? Only the low level code >> can say "Eh, I already made two hundred contacts go through the wire for >> that search, perhaps I should make it easy!". > > Why transfer 200 contacts when the view knows that it needs only 10? The view may show only ten at the same time on the screen, but the mouse wheel makes it so easy to go through all of the 200, that it wouldn't be wise to have them ready. If there are several thousands, that's more annoying. >> The question to really ask, and to which I have no satisfactory answer >> is: "How do me make the low level tell the high level it had to cut the >> list ?". > > The views know that contacts 301 to 309 are displayed. It's the view that > knows where to cut. In fact, there's nothing to cut, since all the view does > is ask the driver for the contects it needs. How do you number the contacts in a sane way? >> ***** VIEWING (CONTACTS) >> >> The contacts should contain enough to be viewed from a generic view in >> the contacts window, and be shown in a search result. That won't prevent >> some other parts of the code to make a better use of them. >> >> For example, in the contact window we will probably be able to see a >> contact's title and description, but not its detailed presence, while >> the main window will contain a much better and more specific view for >> the live contacts. > > You say that the "contact" class must have _enough_ information to be used > both in situation A and in sitation B. > > It would be better to have _different_ "contact" classes for situations "A" > and "B". Of course there will be. I was discussing the base class. > The list of contacts could just manage a name, a company and a phone number. I would put the following : 1) a title (generally the name) 2) a description (for example a location, a status message, etc) 3) an icon > The search result could handle much more detailed information. Of course it cannot. Your search result is a book which needs to be able to show avahi contacts, sip contacts, call history contacts, etc... so it can only show the contacts as generic. > In other words, there's no need to put all the model's data into the views' > data. Each view can handle the data it needs. The view which is specific to an addressbook, of course can show the data from the specific contact associated to it. But the generic view can only show generic information. >> ***** CONTROLLING (GENERIC) >> >> Now, we want to be able to act on our objects ; say rename a book or a >> contact, subscribe/unsubscribe to its presence, etc. >> >> The best thing to do is to be able to get menus for each of them. Notice >> the plural: we will certainly to have at least menu in the menu bar and >> a popup menu. >> >> The first bad news about such menus is that they won't be generic : they >> will depend heavily on the specific type of object (no rename for avahi >> contacts, subscribe/unsubscribe only for XMPP contacts...). So we will >> certainly need some sort of shared actions that will be basic bricks for >> building menu (like the shared-actions.[ch] of my first round of >> proposals), that each implementation will mix as it sees fit. > > I assume here that an 'implementation" is one of the address book drivers, and > that you mean that the drivers will be in charge of building menus. If those > assumptions are wrong, the paragraph below does not apply, please just ignore > it. Yes, that's precisely that. > Just the same as a hard disk driver does not display menus to the user, I > think that the address book drivers in Ekiga should not be responsible for > user interaction The menu is supposed to contain actions which are specific to the given contact, book or view. Hence it must be created by code which is specific to that contact, book or view. It cannot be done by the generic code. > The high level code should be responsible for that. Of course the contents of > the various menus depends on the address book capabilities. That's why the > API between the driver and the high level code should include "query > capabilities functions:" > > class addressBook > { > virtual bool isReadOnly() = 0; > virtual bool canSubscribeContacts() = 0; > ... > }; No, that is wrong and I already explained why. Putting everything in the base class is bad. >> The second bad news about them is that they won't be static either. They >> will have to update themselves following the object they are attached >> to. Say your nice XMPP contact is connected with a client which has VoIP >> support, but now connects with a no-VoIP client, and disconnects the >> first : we want the "Call" menuitem to disappear to reflect this. >> >> So my proposition (no code yet) is that those menus will be obtained by >> subclassing of GtkMenu, register to get signals from the contact/book >> they are attached to, and use that to keep themselves up to date. > > In your example, a signal is not needed. > > Knowing that there is no VoIP number in the current contact is enough. That is wrong. The same contact could update itself and gain it. Or update itself and lose it. >> ***** CONTROLLING (CONTACTS) >> >> Let's try to be more specific: >> in avahi-contact-menu.h, we would have: >> GtkWidget *avahi_contact_menu_new (AvahiContact *contact); >> and in gm-contact.h: >> GtkWidget *gm_contact_get_menu_new (GmContact *contact); >> >> This later function would be different in each implementation, which >> allows for example the avahi_contact_get_menu_new implementation to call >> avahi_contact_menu_new. The high level code called a generic function, >> but got access to a very specific implementation, which knows the full >> api of the specific contact, and hence will provide the best service. > > Again, this logic should be in the high-level code and needs not be > avahi-specific. What exactly should be presented to the user could be > determined from querying the address book for its capabilities. Which means : 1) *all* of the addressbooks would by default have *all* the possible apis for such capability by default, with a isAbleToDoFoo function for each Foo capability ; 2) if an addressbook needs a new capability, we'll have to modify the base addressbook to add it in for it ; it won't just be a matter for the new code to add only what is necessary for itself in its own files. >> ***** CONTROLLING (BOOKS) >> >> Perhaps the menu shouldn't be attached to the book himself, but to its >> view. That would allow to place things such as "Show offline contacts" >> in it. Mostly the idea would be to have controllers for both the >> model-as-model and its view-as-model. > > Agree. Nice. >> Congratulations, comments and flames welcome, but flames will end in >> /dev/null. > > It definitly deserves congratulations. You forgot to mention one of your nice > ideas, that it that it should be possible to search in several address books > at a time. Well, that is the main side-effect of having a base class for contacts. > For the comments, please note that my comments are based on a lot of > assumptions and guesses. In particular, I assume that you have in mind a > different assignment of tasks of the various software layers than the one > that I would like to see. If those assumptions reveal wrong, then of course > my comments do not make much sense. I think you are focused on an addressbook as something both very big and very static, which explains many of our divergences. > If I did not misinterpret your thoughts, you have a very lazy view of the > high-level code. It's software that sits down and waits for signals to act. > Somehow, the high level code provides "services" to the drivers. The drivers > are the ones who understand what's going on. Yes, that's it. The high-level code doesn't know what an AvahiContact or EDSContact is ; it only knows avbout GmContact. That means it cannot do fancy things with them, and has to call functions on them to do anything interesting. > I have the opposite view: the address book drivers are simple and stupid. > Their main task is to go and fetch the requested contacts. The high level > code has an active attitude: it queries the drivers for contacts, it queries > the drivers capabilities, it displays the contact windows, it handles the > menues... The high level code has the real intelligence. Your high level code is very complex, and has to be modified heavily anytime we add a new type of addressbook with new capabilities. Anytime you want to do something, you should ask yourself the question: "Who knows how to do it?". You want to send a message to a contact ? Who knows if it's even possible, and how to do it ? The contact itself! Hence this should be handled by the contact. Of course, as-is that would mean a lot of code duplication. That's where we can use a toolbox ; of which you had an example in the first round of sample code I sent in private. To make it explicit for the -devel- readers, this sample code had a function: void shared_action_rename (GObject *obj); so any object which could be renamed, had only to: - have a "name" property ; - provide an action which trigerred that function on itself. the function handled showing a nice dialog to rename the function. The idea is that of course quite a few objects will have common capabilities ; but instead of putting them all in the high level code and clutter it with functions and conditional, I want to provide the bricks which the low-level code will use to build a specific and well-fit system. Snark From ebischoff@nerim.net Thu Jun 15 14:27:54 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1F1163B04C0 for ; Thu, 15 Jun 2006 14:27:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27103-03 for ; Thu, 15 Jun 2006 14:27:51 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id E36E93B0412 for ; Thu, 15 Jun 2006 14:27:50 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 25E1340F90 for ; Thu, 15 Jun 2006 20:26:36 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Thu, 15 Jun 2006 20:26:49 +0200 User-Agent: KMail/1.8.2 References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> <44917F71.10408@free.fr> In-Reply-To: <44917F71.10408@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606152026.49639.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.533 tagged_above=-999 required=2 tests=[AWL=-0.011, BAYES_00=-2.599, SUBJECT_EXCESS_QP=0, TW_AV=0.077] X-Spam-Score: -2.533 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] =?utf-8?q?Ideas_and_considerations_for_?= =?utf-8?q?the=09addressbook_code?= X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 18:27:54 -0000 Le Jeudi 15 Juin 2006 17:40, Julien PUYDT a =C3=A9crit=C2=A0: > Saying "I get only the 10 I need" is nice, but how do you tell the > driver which they are ? There are several ways to acheive that. It could be contact numbers. Or it= =20 could be some data kept internally inside the driver. It could be a void *.= =20 Etc. > > While this sounds cool, I am not sure that this will be possible in some > > circumstances. The underlying address book (evolution, KDE address book, > > LDAP server, Zeroconf, ...) might not have the mechanisms to send such a > > signal. > > No problem : then they don't. OK. So that should not be a requirement, and certainly not a mechanism at t= he=20 core of the system. Just a nice plus. > > Why transfer 200 contacts when the view knows that it needs only 10? > > The view may show only ten at the same time on the screen, but the mouse > wheel makes it so easy to go through all of the 200, that it wouldn't be > wise to have them ready. Yes. You could have a few spare contacts before and after the user's view.= =20 This algorithm is rather common. > If there are several thousands, that's more annoying. Okay. Let's simulate your algorithm, or what I have understood of it. The user views a search selection of contacts named "Tom". His/her window=20 should contain contacts Tom Smith (#1032), Tom Jones (#2050) and Tom Doe=20 (#3172). The high level software asks the driver "get me all contacts". Aft= er=20 a relatively long time, the driver is wise and stops at contact 200. It=20 returns a list with contacts 1, 2, 3, etc, up to 200. The high level softwa= re=20 searches for Tom's in the list and finds none, since the Tom's have numbers= =20 1032, 2050 and 3172. The returned list is useless, and the window remains=20 blank. I know that it cannot be _that_ bad and that I certainly misunderstood=20 something. But what? > > The views know that contacts 301 to 309 are displayed. It's the view th= at > > knows where to cut. In fact, there's nothing to cut, since all the view > > does is ask the driver for the contects it needs. > > How do you number the contacts in a sane way? These numbers are here for the demonstration. I agree that numbers probably= =20 are not so well adapted to real address books. You could use "markers". I think that all address books use contact UIDs. A= =20 given UID could be used to mark the place where the address book stopped=20 "last time". =46or most usage you do not even need anything. Most operation is sequentia= l.=20 Take for example searching. Usually you browse all records and only keep in= =20 the result list the ones that match. > I would put the following : > 1) a title (generally the name) > 2) a description (for example a location, a status message, etc) > 3) an icon Yes, we are discussing principles. Details can be arranged later. > > The search result could handle much more detailed information. > > Of course it cannot. Your search result is a book which needs to be able > to show avahi contacts, sip contacts, call history contacts, etc... so > it can only show the contacts as generic. Why would you be unable to display detailed information about objects which= =20 you only know as generic? while (genericContact =3D nextContact()) { if (genericContact->book()->canSubscribeContacts()) proposeSubscription(genericContact); ... } > The view which is specific to an addressbook, of course can show the > data from the specific contact associated to it. But the generic view > can only show generic information. Wrong ;-). Not shown in the code sample above, but that's also the whole point of virt= ual=20 methods. > The menu is supposed to contain actions which are specific to the given > contact, book or view. Hence it must be created by code which is > specific to that contact, book or view. It cannot be done by the generic > code. ;-) > > class addressBook > > { > > virtual bool isReadOnly() =3D 0; > > virtual bool canSubscribeContacts() =3D 0; > > ... > > }; > > No, that is wrong and I already explained why. Putting everything in the > base class is bad. Do you realize that the above is not an implementation? It's just an API=20 definition. Those are pure virtual methods. Everything is implemented in th= e=20 derived subclasses. Such style of coding is very classical, good, C++ (or java). > > In your example, a signal is not needed. > > > > Knowing that there is no VoIP number in the current contact is enough. > > That is wrong. The same contact could update itself and gain it. Or > update itself and lose it. I should have added "at a given time". > Which means : > 1) *all* of the addressbooks would by default have *all* the possible > apis for such capability by default, with a isAbleToDoFoo function for > each Foo capability ; No. Defining pure virtual functions in the base class does not mean that yo= u=20 implement a function in the derived class. If it can't do something, and le= ts=20 the engine know it, then it can't ;-). > 2) if an addressbook needs a new capability, we'll have to modify the > base addressbook to add it in for it ; it won't just be a matter for the > new code to add only what is necessary for itself in its own files. Wrong again, C++ comes with programming techniques that permit to locate th= e=20 real implementations in the derived classes. > > It definitly deserves congratulations. You forgot to mention one of your > > nice ideas, that it that it should be possible to search in several > > address books at a time. > > Well, that is the main side-effect of having a base class for contacts. ;-) > I think you are focused on an addressbook as something both very big and > very static, which explains many of our divergences. I think that we are both wrong here ;-). An address book could be big (whic= h=20 you underestimated), and it could be moving (which I underestimated). > Yes, that's it. The high-level code doesn't know what an AvahiContact or > EDSContact is ; it only knows avbout GmContact. That means it cannot do > fancy things with them, and has to call functions on them to do anything > interesting. I have a view that is not so far away. The book just knows contacts. Virtua= l=20 methods and subclassing both the book and the contacts does the rest. > Your high level code is very complex, and has to be modified heavily > anytime we add a new type of addressbook with new capabilities. Yes, but much more generic. And if the same capability exists in a second address book, the code is=20 already written. > Of course, as-is that would mean a lot of code duplication. That's where > we can use a toolbox ; of which you had an example in the first round of > sample code I sent in private. Ah, you too you can see the duplication problem with your method ;-). A tool box... Sounds like a C library ;-). I think that we basically foresee the same problems, but you want to do the= m=20 in the procedural, C way, and I would like them to be done in the=20 object-oriented, C++ way. > To make it explicit for the -devel- readers, this sample code had a > function: > void shared_action_rename (GObject *obj); > so any object which could be renamed, had only to: > - have a "name" property ; > - provide an action which trigerred that function on itself. > the function handled showing a nice dialog to rename the function. Yup. You see functions where I see methods ;-). > The idea is that of course quite a few objects will have common > capabilities ; but instead of putting them all in the high level code > and clutter it with functions and conditional, Yes, that would be the logical consequence if we were in C. We are not. We= =20 have virtual methods. > I want to provide the=20 > bricks which the low-level code will use to build a specific and > well-fit system. You will end up with an engine doing about nothing, and all the work to be= =20 reimplemented again and again in the drivers. Plus painfully shared code in= =20 the "toolbox" to avoid almost identical code where it can be avoided. That'= s=20 typical procedural approach. =2D-=20 Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m=C3=A9dire." (Le concombre masqu=C3=A9, Mandriva) From jpuydt@free.fr Thu Jun 15 16:46:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 4F0A43B01FF for ; Thu, 15 Jun 2006 16:46:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32671-05 for ; Thu, 15 Jun 2006 16:46:37 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 91ADA3B00D0 for ; Thu, 15 Jun 2006 16:46:36 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp1-g19.free.fr (Postfix) with ESMTP id 743AD9A39A for ; Thu, 15 Jun 2006 22:46:01 +0200 (CEST) Message-ID: <4491C708.3060203@free.fr> Date: Thu, 15 Jun 2006 22:46:00 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> <44917F71.10408@free.fr> <200606152026.49639.ebischoff@nerim.net> In-Reply-To: <200606152026.49639.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.342 tagged_above=-999 required=2 tests=[AWL=0.180, BAYES_00=-2.599, TW_AV=0.077] X-Spam-Score: -2.342 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 20:46:39 -0000 Éric Bischoff a écrit : > Le Jeudi 15 Juin 2006 17:40, Julien PUYDT a écrit : >> Saying "I get only the 10 I need" is nice, but how do you tell the >> driver which they are ? > > There are several ways to acheive that. It could be contact numbers. Or it > could be some data kept internally inside the driver. It could be a void *. > Etc. Well, then you reduced the question: "How do I tell the driver which contacts I want?" to: "How do I tell the driver which identifiers I want?" I don't find this impressive. >>> While this sounds cool, I am not sure that this will be possible in some >>> circumstances. The underlying address book (evolution, KDE address book, >>> LDAP server, Zeroconf, ...) might not have the mechanisms to send such a >>> signal. >> No problem : then they don't. > > OK. So that should not be a requirement, and certainly not a mechanism at the > core of the system. Just a nice plus. It *must* be at the core of the system. We _do_ want to update the live data when it changes. >>> Why transfer 200 contacts when the view knows that it needs only 10? >> The view may show only ten at the same time on the screen, but the mouse >> wheel makes it so easy to go through all of the 200, that it wouldn't be >> wise to have them ready. > > Yes. You could have a few spare contacts before and after the user's view. > This algorithm is rather common. What do "before" and "after" mean ? >> If there are several thousands, that's more annoying. > > Okay. Let's simulate your algorithm, or what I have understood of it. > > The user views a search selection of contacts named "Tom". His/her window > should contain contacts Tom Smith (#1032), Tom Jones (#2050) and Tom Doe > (#3172). The high level software asks the driver "get me all contacts". After > a relatively long time, the driver is wise and stops at contact 200. It > returns a list with contacts 1, 2, 3, etc, up to 200. The high level software > searches for Tom's in the list and finds none, since the Tom's have numbers > 1032, 2050 and 3172. The returned list is useless, and the window remains > blank. > > I know that it cannot be _that_ bad and that I certainly misunderstood > something. But what? I certainly have issues with big books, and must find some satisfying way to handle them. But doing function calls to walk on a list where I could get the list and walk it myself directly, is definitely wrong. >>> The views know that contacts 301 to 309 are displayed. It's the view that >>> knows where to cut. In fact, there's nothing to cut, since all the view >>> does is ask the driver for the contects it needs. >> How do you number the contacts in a sane way? > > These numbers are here for the demonstration. I agree that numbers probably > are not so well adapted to real address books. > > You could use "markers". I think that all address books use contact UIDs. A > given UID could be used to mark the place where the address book stopped > "last time". Notice that the only place where you call the _get_contacts function is when you first populate the book. The rest of the time you don't want to know. > For most usage you do not even need anything. Most operation is sequential. > Take for example searching. Usually you browse all records and only keep in > the result list the ones that match. Most operations are sequential when the book is static. When your contacts go online/offline/whatever, that certainly is random access, and I can tell you a first/current/next approach doesn't fly in such a situation. >>> The search result could handle much more detailed information. >> Of course it cannot. Your search result is a book which needs to be able >> to show avahi contacts, sip contacts, call history contacts, etc... so >> it can only show the contacts as generic. > > Why would you be unable to display detailed information about objects which > you only know as generic? > > while (genericContact = nextContact()) > { > if (genericContact->book()->canSubscribeContacts()) > proposeSubscription(genericContact); > ... > } Yes, of course. You put everything at the high level, something which I already stressed was very very bad. Let's try an example. A text editor will just access files. It won't wonder if they are local or remote, it won't wonder about where the data really is on disk, need caching, etc. This is the job of the low-level system. The text editor doesn't have functions and tests to handle all of the various situations possible. High level is high, it doesn't take mud baths with the details, it doesn't handle them. It delegates them to the low level. >> The view which is specific to an addressbook, of course can show the >> data from the specific contact associated to it. But the generic view >> can only show generic information. > > Wrong ;-). Partially wrong. The generic view can indeed get access to some specific features (like the menus I explained). But it certainly *must* not get them by handling *all* possible situations. >>> class addressBook >>> { >>> virtual bool isReadOnly() = 0; >>> virtual bool canSubscribeContacts() = 0; >>> ... >>> }; >> No, that is wrong and I already explained why. Putting everything in the >> base class is bad. > > Do you realize that the above is not an implementation? It's just an API > definition. Those are pure virtual methods. Everything is implemented in the > derived subclasses. > > Such style of coding is very classical, good, C++ (or java). Such style of coding is not classical, is bad and evil. I see abstractions layers everywhere to hide the details of the lower level, and you want to push those details high up the stack. >>> In your example, a signal is not needed. >>> >>> Knowing that there is no VoIP number in the current contact is enough. >> That is wrong. The same contact could update itself and gain it. Or >> update itself and lose it. > > I should have added "at a given time". > >> Which means : >> 1) *all* of the addressbooks would by default have *all* the possible >> apis for such capability by default, with a isAbleToDoFoo function for >> each Foo capability ; > > No. Defining pure virtual functions in the base class does not mean that you > implement a function in the derived class. If it can't do something, and lets > the engine know it, then it can't ;-). You push all the code to the high level, and never really abstract. That is very wrong. >> 2) if an addressbook needs a new capability, we'll have to modify the >> base addressbook to add it in for it ; it won't just be a matter for the >> new code to add only what is necessary for itself in its own files. > > Wrong again, C++ comes with programming techniques that permit to locate the > real implementations in the derived classes. If I add a new addressbook type with a Foo capability, your designs says I have to modify the base class and add: bool canDoFoo (); void pleaseDoFooThisWay (...); void pleaseDoFooThisOtherWay (...); void etcFoo (...) (with all the virtual pure syntactic crap needed) My idea of right design is that if the new addressbook is the only one needing Foo, it will handle it himself (through a specific api that its view and controller will know and use). >> I think you are focused on an addressbook as something both very big and >> very static, which explains many of our divergences. > > I think that we are both wrong here ;-). An address book could be big (which > you underestimated), and it could be moving (which I underestimated). I agree I have issues seeing how to do things *properly* with a very large addressbook. >> Yes, that's it. The high-level code doesn't know what an AvahiContact or >> EDSContact is ; it only knows avbout GmContact. That means it cannot do >> fancy things with them, and has to call functions on them to do anything >> interesting. > > I have a view that is not so far away. The book just knows contacts. Virtual > methods and subclassing both the book and the contacts does the rest. > >> Your high level code is very complex, and has to be modified heavily >> anytime we add a new type of addressbook with new capabilities. > > Yes, but much more generic. It isn't much more generic. It is an awful and indigest mix of all the specific implementations. > And if the same capability exists in a second address book, the code is > already written. Not really. >> Of course, as-is that would mean a lot of code duplication. That's where >> we can use a toolbox ; of which you had an example in the first round of >> sample code I sent in private. > > Ah, you too you can see the duplication problem with your method ;-). > > A tool box... Sounds like a C library ;-). Which are very useful and allow to abstract common work at a lower layer and not take care of it ourselves way up. > I think that we basically foresee the same problems, but you want to do them > in the procedural, C way, and I would like them to be done in the > object-oriented, C++ way. Your view isn't OO, and isn't C++. >> To make it explicit for the -devel- readers, this sample code had a >> function: >> void shared_action_rename (GObject *obj); >> so any object which could be renamed, had only to: >> - have a "name" property ; >> - provide an action which trigerred that function on itself. >> the function handled showing a nice dialog to rename the function. > > Yup. You see functions where I see methods ;-). I see functions spread in maintainable files, with well-separated features and responsibility. You see functions named "methods" stuffed into the same poor base class, which has to handle everything and the rest, and where the limits between everything is blurred. Where I say function and do: gm_contact_do_foo (contact, arguments); you say method and to: contact->do_foo (arguments); which I agree is shorter, but isn't the magical solution you think it is! :-) >> The idea is that of course quite a few objects will have common >> capabilities ; but instead of putting them all in the high level code >> and clutter it with functions and conditional, > > Yes, that would be the logical consequence if we were in C. We are not. We > have virtual methods. You *do* have isReadOnly and canSubscribeContacts, which you will use to do the ifs I said where very wrong, and you will do so at the high level, which is precisely the place where details shouldn't be handled! It isn't a case of leaky abstraction, it is a case of no-abstraction! >> I want to provide the >> bricks which the low-level code will use to build a specific and >> well-fit system. > > You will end up with an engine doing about nothing, and all the work to be > reimplemented again and again in the drivers. Plus painfully shared code in > the "toolbox" to avoid almost identical code where it can be avoided. That's > typical procedural approach. I generally end up with nice layers of functions doing almost nothing, with clean api between the layer, ensuring the code will be pretty maintainable. See lib/gmconf/ for example. We have a nice api in gmconf.h, and an implementation in gmconf-glib.c, which is layered in the same file, with lowlevel functions doing some work, and higher level doing another. Not everything done at the same final level. When I wrote that code, the goal was to make gconf (the gnome configuration management system) optional, so the port to win32 would be easier. I wrote a generic api to handle things, then two implementations *hidden* behind it. Well, at least we both agree I don't handle the case of very large addressbooks very well :-/ Snark From jpuydt@free.fr Fri Jun 16 11:44:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AC28C3B0005 for ; Fri, 16 Jun 2006 11:44:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01534-04 for ; Fri, 16 Jun 2006 11:44:08 -0400 (EDT) Received: from postfix2-c.free.fr (postfix2-c.free.fr [213.228.0.80]) by menubar.gnome.org (Postfix) with ESMTP id E28BA3B0007 for ; Fri, 16 Jun 2006 11:44:07 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by postfix2-c.free.fr (Postfix) with ESMTP id E4AFC458B6CE for ; Fri, 16 Jun 2006 16:07:32 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp6-g19.free.fr (Postfix) with ESMTP id DF5BD2265E for ; Fri, 16 Jun 2006 17:02:28 +0200 (CEST) Message-ID: <4492B888.8060206@free.fr> Date: Fri, 16 Jun 2006 15:56:24 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> In-Reply-To: <4491205F.5070708@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.382 tagged_above=-999 required=2 tests=[AWL=0.217, BAYES_00=-2.599] X-Spam-Score: -2.382 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 15:44:10 -0000 Julien PUYDT a écrit : > ***** ABOUT EVOLUTION-DATA-SERVER > > The evolution-data-server api looks pretty good -- except that it seems > to mainly handle static vcard-based contacts, where I would like to be > able to handle things like. Hmmm... this sentence should have ended with "able to handle things like live contacts with presence (SIP and XMPP)". On the subject of big addressbook handling, I must say what evolution-data-server does is quite nice : they run a query (EQuery) on a book (EBook), which gives them a view of the result (EBookView). That means that they can easily do a partial view of an addressbook, since they control what is seen! While this organisation doesn't suffer from the problem Éric pointed out, it has still a problem : how does one just "search" ? I mean, if your api is "search a book => get a view", how does one make a search which encompasses all books? Snark PS: notice that the current addressbook code happily tries to get all contacts, whatever the size of the addressbook -- and even not asynchronously! From jpuydt@free.fr Sat Jun 17 03:08:50 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 27E423B03CB for ; Sat, 17 Jun 2006 03:08:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11317-07 for ; Sat, 17 Jun 2006 03:08:48 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 068E83B00DE for ; Sat, 17 Jun 2006 03:08:47 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-57-82-249-55-125.adsl.proxad.net [82.249.55.125]) by smtp1-g19.free.fr (Postfix) with ESMTP id CE8E69AA70 for ; Sat, 17 Jun 2006 09:07:34 +0200 (CEST) Message-ID: <4493AA32.5030602@free.fr> Date: Sat, 17 Jun 2006 09:07:30 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> In-Reply-To: <4492B888.8060206@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.586 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599] X-Spam-Score: -2.586 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 07:08:50 -0000 Julien PUYDT a écrit : > While this organisation doesn't suffer from the problem Éric pointed > out, it has still a problem : how does one just "search" ? I mean, if > your api is "search a book => get a view", how does one make a search > which encompasses all books? Ok, I think I'm on something : let's a book have a simple api, where on one side: 1) a book can return a view for itself, which means the view becomes specific, and hence can handle the case of big addressbooks ; 2) a full search function, which will return a new book, restricted to the the search ; again this book has its view, which will handle the case of big searches ; 3) a restricted search function, which will return say at most a hundred contacts matching the string ; this one allows to make a search on all the books, since we are assured we won't be drowned by the number. This organisation would allow a clean approach for the view on a single addressbook, while still having the possibility to have a working "Find a contact" button. Does that looks nicer ? Snark From ebischoff@nerim.net Sat Jun 17 05:24:05 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id ACD5F3B038B for ; Sat, 17 Jun 2006 05:24:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15888-07 for ; Sat, 17 Jun 2006 05:24:02 -0400 (EDT) Received: from kellthuzad.dmz.nerim.net (smtp-dmz-236-saturday.dmz.nerim.net [195.5.254.236]) by menubar.gnome.org (Postfix) with ESMTP id 2C81F3B0809 for ; Sat, 17 Jun 2006 05:24:01 -0400 (EDT) Received: from kraid.nerim.net (smtp-106-saturday.nerim.net [62.4.16.106]) by kellthuzad.dmz.nerim.net (Postfix) with ESMTP id 9BD1139D6B for ; Sat, 17 Jun 2006 11:23:14 +0200 (CEST) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 5A4A940E35 for ; Sat, 17 Jun 2006 11:22:48 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Sat, 17 Jun 2006 11:22:59 +0200 User-Agent: KMail/1.8.2 References: <4491205F.5070708@free.fr> <200606152026.49639.ebischoff@nerim.net> <4491C708.3060203@free.fr> In-Reply-To: <4491C708.3060203@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606171123.00082.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.51 tagged_above=-999 required=2 tests=[AWL=0.089, BAYES_00=-2.599] X-Spam-Score: -2.51 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 09:24:05 -0000 Le Jeudi 15 Juin 2006 22:46, Julien PUYDT a =C3=A9crit=C2=A0: > > OK. So that should not be a requirement, and certainly not a mechanism = at > > the core of the system. Just a nice plus. > > It *must* be at the core of the system. We _do_ want to update the live > data when it changes. Sorry, that was not clear. By "at the core" I meant "necessary for the addr= ess=20 books to work". > > Yes. You could have a few spare contacts before and after the user's > > view. This algorithm is rather common. > > What do "before" and "after" mean ? Records just before and after the ones that are displayed in sequential ord= er. > > I know that it cannot be _that_ bad and that I certainly misunderstood > > something. But what? > > I certainly have issues with big books, and must find some satisfying > way to handle them. But doing function calls to walk on a list where I > could get the list and walk it myself directly, is definitely wrong. What is wrong is to see that as a list ;-). > Most operations are sequential when the book is static. When your > contacts go online/offline/whatever, that certainly is random access, > and I can tell you a first/current/next approach doesn't fly in such a > situation. I would not say "not fly" but it certainly becomes much more acrobatic, I=20 agree. > If I add a new addressbook type with a Foo capability, your designs says > I have to modify the base class and add: > > bool canDoFoo (); > void pleaseDoFooThisWay (...); > void pleaseDoFooThisOtherWay (...); > void etcFoo (...) > (with all the virtual pure syntactic crap needed) This "crap" is a lightweight modification since it is only one function=20 declaration. No implementation. That is done in the subclasses, if necessar= y. > My idea of right design is that if the new addressbook is the only one > needing Foo, it will handle it himself (through a specific api that its > view and controller will know and use). Okay. Perharps the our differences in opinion is not that much on the=20 programming design, but more on what the software has to do. To me, an address book is just an address book, they are not that different= =20 one from the other. Ekiga need to dig through them to show names, categorie= s=20 and to pick up SIP numbers to call the people. I see a relatively homogeneo= us=20 user interface, with more or less the same appearance (if not exactly the=20 same) for the various address books. I have a "unifying" vision. To you, all address books have very strong pecularities and the software ha= s=20 to adapt a lot to each of them, to take them to the maximum of their=20 possibilities. The user will get different display, different menues, and=20 even different functionality. That explains why you want to put everything in the "drivers", while I want= to=20 put a lot of common logic in the "engine". > > I think that we are both wrong here ;-). An address book could be big > > (which you underestimated), and it could be moving (which I > > underestimated). > > I agree I have issues seeing how to do things *properly* with a very > large addressbook. Yes, and I have certainly underestimated the "dynamic" aspect :-(. > Your view isn't OO, and isn't C++. Come on ;-). > You see functions named "methods" stuffed into the same poor base class, No. Again and again, the base class only has declarations. It sees an=20 abstraction of what the address book is. In every C++ book, you can see examples like this class vehicle { virtual void accelerate(int a) =3D 0; ... }; class car : public vehicle { virtual void accelerate(int a); ... }; class plane : public vehicle { virtual void accelerate(int a); ... }; Planes and cars have very different ways to accelerate. Planes can't brake = and=20 cars can't fly, but such designs are clean and very popular. > Well, at least we both agree I don't handle the case of very large > addressbooks very well :-/ Yes, this discussion is not pointless :-). And at the end if you are more comfortable with libraries of C functions th= an=20 with subclassing and virtual functions, it's no problem. After all, it's yo= u=20 who are going to be doing the dirty work (and I think we all thank you for= =20 that!). =2D-=20 Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m=C3=A9dire." (Le concombre masqu=C3=A9, Mandriva) From jpuydt@free.fr Sat Jun 17 15:09:04 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2976B3B0144 for ; Sat, 17 Jun 2006 15:09:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04217-02 for ; Sat, 17 Jun 2006 15:08:59 -0400 (EDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by menubar.gnome.org (Postfix) with ESMTP id BC2893B019D for ; Sat, 17 Jun 2006 15:07:46 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-c.free.fr (Postfix) with ESMTP id 4C9DC1D0C42D for ; Sat, 17 Jun 2006 20:06:22 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-57-82-249-55-125.adsl.proxad.net [82.249.55.125]) by smtp5-g19.free.fr (Postfix) with ESMTP id B65BC26C83 for ; Sat, 17 Jun 2006 21:05:51 +0200 (CEST) Message-ID: <4494528F.2040804@free.fr> Date: Sat, 17 Jun 2006 21:05:51 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <200606152026.49639.ebischoff@nerim.net> <4491C708.3060203@free.fr> <200606171123.00082.ebischoff@nerim.net> In-Reply-To: <200606171123.00082.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.584 tagged_above=-999 required=2 tests=[AWL=0.015, BAYES_00=-2.599] X-Spam-Score: -2.584 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 19:09:04 -0000 Éric Bischoff a écrit : >>> Yes. You could have a few spare contacts before and after the user's >>> view. This algorithm is rather common. >> What do "before" and "after" mean ? > > Records just before and after the ones that are displayed in sequential order. Sequential hurts. >>> I know that it cannot be _that_ bad and that I certainly misunderstood >>> something. But what? >> I certainly have issues with big books, and must find some satisfying >> way to handle them. But doing function calls to walk on a list where I >> could get the list and walk it myself directly, is definitely wrong. > > What is wrong is to see that as a list ;-). Indeed. >> If I add a new addressbook type with a Foo capability, your designs says >> I have to modify the base class and add: >> >> bool canDoFoo (); >> void pleaseDoFooThisWay (...); >> void pleaseDoFooThisOtherWay (...); >> void etcFoo (...) >> (with all the virtual pure syntactic crap needed) > > This "crap" is a lightweight modification since it is only one function > declaration. No implementation. That is done in the subclasses, if necessary. Notice that I used "crap" to describe the syntactic need in C++ to add "virtual" and "= 0" everywhere. And your "lightweight modification" still involves modifying the base class anytime a child class needs something! >> My idea of right design is that if the new addressbook is the only one >> needing Foo, it will handle it himself (through a specific api that its >> view and controller will know and use). > > Okay. Perharps the our differences in opinion is not that much on the > programming design, but more on what the software has to do. > > To me, an address book is just an address book, they are not that different > one from the other. Ekiga need to dig through them to show names, categories > and to pick up SIP numbers to call the people. I see a relatively homogeneous > user interface, with more or less the same appearance (if not exactly the > same) for the various address books. I have a "unifying" vision. > > To you, all address books have very strong pecularities and the software has > to adapt a lot to each of them, to take them to the maximum of their > possibilities. The user will get different display, different menues, and > even different functionality. Well, look at what we have to put already in the addressbooks: - evolution-data-server addressbooks ; - avahi contacts ; - history contacts ; - speeddials. And the future holds : - SIP contacts ; - XMPP contacts. > That explains why you want to put everything in the "drivers", while I want to > put a lot of common logic in the "engine". Your high level is what I call low level : it handles all of the details! >> Your view isn't OO, and isn't C++. > > Come on ;-). > >> You see functions named "methods" stuffed into the same poor base class, > > No. Again and again, the base class only has declarations. It sees an > abstraction of what the address book is. You're still stuffing that in the base class, which is awful. Does the QWidget class have all the methods of all its child already declared? > In every C++ book, you can see examples like this > > class vehicle { > virtual void accelerate(int a) = 0; > ... > }; > > class car : public vehicle { > virtual void accelerate(int a); > ... > }; > > class plane : public vehicle { > virtual void accelerate(int a); > ... > }; > Planes and cars have very different ways to accelerate. Planes can't brake and > cars can't fly, but such designs are clean and very popular. They all accelerate, and that is the reason why having an accelerate method is put as a requirement in the base class. Anyway I since made another proposition which I find neater ; I'm eagerly waiting for your comments on it :-) Snark From siti@orcon.net.nz Sat Jun 17 16:21:14 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 166443B02D7 for ; Sat, 17 Jun 2006 16:21:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06960-02 for ; Sat, 17 Jun 2006 16:21:11 -0400 (EDT) Received: from dbmail-mx3.orcon.co.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 420E03B0769 for ; Sat, 17 Jun 2006 16:21:10 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx3.orcon.co.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k5HKBcBi027983 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 18 Jun 2006 08:11:39 +1200 From: Stephen Cook To: GnomeMeeting development mailing list Content-Type: text/plain Date: Sun, 18 Jun 2006 08:11:38 +1200 Message-Id: <1150575098.10433.5.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx3.orcon.co.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.484 tagged_above=-999 required=2 tests=[AWL=-0.020, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.484 X-Spam-Level: Subject: [GnomeMeeting-devel-list] IAX2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 20:21:14 -0000 Hello, It's been a long time I gave you guys an update. In IAX2 in opal I have got music on hold going which is nice :). I will be doing registration next as this is probably the most important feature for users. Also I have not run in to any stability problems with IAX2. My iax2/ekiga integration is working well as a tester with my asterisk server. It basically has all the functionality there but needs more integration and bug/quirky fixes. Also some refactoring in the future would be nice depending if I get time or not... From jan.schampera@web.de Sat Jun 17 23:26:05 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 973DD3B0089 for ; Sat, 17 Jun 2006 23:26:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21686-02 for ; Sat, 17 Jun 2006 23:26:04 -0400 (EDT) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by menubar.gnome.org (Postfix) with ESMTP id 718E83B0080 for ; Sat, 17 Jun 2006 23:26:04 -0400 (EDT) Received: from fwd28.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1Frm9f-0005mL-03; Sun, 18 Jun 2006 03:32:47 +0200 Received: from mail.home.thebonsai.de (Ee3Yp-Z-ge9I5Mahsz3ULnxaW3DaPSfdXF9f7jCM5sjCj+WYBVPHwg@[84.147.75.32]) by fwd28.sul.t-online.de with esmtp id 1Frm9c-1vtsA40; Sun, 18 Jun 2006 03:32:44 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id 610F16B154 for ; Sun, 18 Jun 2006 03:32:43 +0200 (CEST) Date: Sun, 18 Jun 2006 03:32:42 +0200 From: Jan Schampera To: gnomemeeting-devel-list@gnome.org Message-ID: <20060618033242.5cce3d15@localhost.localdomain> In-Reply-To: <4493AA32.5030602@free.fr> References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> <4493AA32.5030602@free.fr> Organization: private X-Mailer: Sylpheed-Claws 2.2.0 (GTK+ 2.8.18; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: Ee3Yp-Z-ge9I5Mahsz3ULnxaW3DaPSfdXF9f7jCM5sjCj+WYBVPHwg@t-dialin.net X-TOI-MSGID: d12d82d7-adb7-47a8-a0ce-a3a4ced5117e X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.982 tagged_above=-999 required=2 tests=[AWL=0.616, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.982 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 03:26:05 -0000 On Sat, 17 Jun 2006 09:07:30 +0200 Julien PUYDT wrote: > 1) a book can return a view for itself, which means the view becomes > specific, and hence can handle the case of big addressbooks ; And which view would such a book return by default? > 2) a full search function, which will return a new book, restricted > to the the search ; again this book has its view, which will handle > the case of big searches ; ACK > 3) a restricted search function, which will return say at most a > hundred contacts matching the string ; this one allows to make a > search on all the books, since we are assured we won't be drowned by > the number. > Does that looks nicer ? Yip. J. -- God is real... unless declared as integer. From jpuydt@free.fr Sun Jun 18 06:22:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8B7533B09FC for ; Sun, 18 Jun 2006 06:22:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18409-03 for ; Sun, 18 Jun 2006 06:22:08 -0400 (EDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by menubar.gnome.org (Postfix) with ESMTP id 03CAF3B0956 for ; Sun, 18 Jun 2006 06:22:07 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-c.free.fr (Postfix) with ESMTP id B13A21D0A67F for ; Sun, 18 Jun 2006 11:20:11 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-30-82-253-152-157.adsl.proxad.net [82.253.152.157]) by smtp5-g19.free.fr (Postfix) with ESMTP id 8697F270B8 for ; Sun, 18 Jun 2006 12:19:37 +0200 (CEST) Message-ID: <449528BF.3020104@free.fr> Date: Sun, 18 Jun 2006 12:19:43 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> <4493AA32.5030602@free.fr> <20060618033242.5cce3d15@localhost.localdomain> In-Reply-To: <20060618033242.5cce3d15@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 10:22:10 -0000 Jan Schampera a écrit : >> 1) a book can return a view for itself, which means the view becomes >> specific, and hence can handle the case of big addressbooks ; > And which view would such a book return by default? No default view. I think there should be a GmFullBook class (from which all books which can be displayed fully), and an associated GmFullBookView class, which would then be default for the children. >> Does that looks nicer ? > Yip. Nice. I'm writing some code to showcase things... may take long since I lack time those days :-/ Snark From dsandras@seconix.com Sun Jun 18 15:32:22 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 425673B0114 for ; Sun, 18 Jun 2006 15:32:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08600-02 for ; Sun, 18 Jun 2006 15:32:19 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 178373B0009 for ; Sun, 18 Jun 2006 15:32:18 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id EF61583C26 for ; Sun, 18 Jun 2006 21:11:21 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03870-02 for ; Sun, 18 Jun 2006 21:11:15 +0200 (CEST) Received: from [192.168.0.161] (206-158.242.81.adsl.skynet.be [81.242.158.206]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 657C683C23 for ; Sun, 18 Jun 2006 21:11:15 +0200 (CEST) From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <1150575098.10433.5.camel@siti> References: <1150575098.10433.5.camel@siti> Content-Type: text/plain; charset=ISO-8859-15 Date: Sun, 18 Jun 2006 21:31:27 +0200 Message-Id: <1150659087.2477.3.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.256 tagged_above=-999 required=2 tests=[AWL=0.208, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.256 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] IAX2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 19:32:22 -0000 Le dimanche 18 juin 2006 à 08:11 +1200, Stephen Cook a écrit : > Hello, > > It's been a long time I gave you guys an update. > > In IAX2 in opal I have got music on hold going which is nice :). I will > be doing registration next as this is probably the most important > feature for users. Also I have not run in to any stability problems > with IAX2. > > My iax2/ekiga integration is working well as a tester with my asterisk > server. It basically has all the functionality there but needs more > integration and bug/quirky fixes. Also some refactoring in the future > would be nice depending if I get time or not... Hi, I've seen Derek committed some code from you. I think it is important that you keep a repository with your patches so that we really know what you have fixed/added for Google SoC. (Actually, I should see the patches, even though it is perfectly acceptable that Derek commits them). Thank you, -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From gcgagd-gnomemeeting-devel-list@m.gmane.org Sun Jun 18 16:15:08 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8DDA23B0114 for ; Sun, 18 Jun 2006 16:15:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09248-09 for ; Sun, 18 Jun 2006 16:15:07 -0400 (EDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by menubar.gnome.org (Postfix) with ESMTP id 662BD3B00B2 for ; Sun, 18 Jun 2006 16:15:07 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Fs3eO-0006gT-LO for gnomemeeting-devel-list@gnome.org; Sun, 18 Jun 2006 22:13:40 +0200 Received: from jupiter.physics.ubc.ca ([142.103.234.78]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Jun 2006 22:13:40 +0200 Received: from johan_brn by jupiter.physics.ubc.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Jun 2006 22:13:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gnomemeeting-devel-list@gnome.org From: Johan Brannlund Date: Sun, 18 Jun 2006 13:13:29 -0700 Lines: 22 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: jupiter.physics.ubc.ca User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux)) Sender: news X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.752 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_YAHOO_RCVD=1.849, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.752 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Main window size X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 20:15:08 -0000 I posted the below as a wishlist bug, but apparently the developers prefer carrying out the discussion on this mailing list. This is what I wrote: "I just tried the 20060615 cvs snapshot of ekiga, and it's getting better all the time. I have a small request though: I don't use video, which means that the main window is much bigger than it has to be. Would it be possible to add a resizing widget, or to automatically make the window smaller when video is disabled?" Damien also added the following comment: "I would also say that it will look less bigger when having a contacts list. :) " ... which I don't quite understand. At least in my snapshot, the contacts are in a separate window. Regards, Johan From siti@orcon.net.nz Sun Jun 18 21:23:06 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 415B73B0387 for ; Sun, 18 Jun 2006 21:23:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18559-06 for ; Sun, 18 Jun 2006 21:23:01 -0400 (EDT) Received: from dbmail-mx2.orcon.net.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 66E1B3B0196 for ; Sun, 18 Jun 2006 21:23:01 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx2.orcon.net.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k5J1Lujn017301 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 19 Jun 2006 13:21:57 +1200 From: Stephen Cook To: GnomeMeeting development mailing list In-Reply-To: <1150659087.2477.3.camel@golgoth01> References: <1150575098.10433.5.camel@siti> <1150659087.2477.3.camel@golgoth01> Content-Type: text/plain; charset=utf-8 Date: Mon, 19 Jun 2006 13:21:55 +1200 Message-Id: <1150680115.31741.1.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx2.orcon.net.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.547 tagged_above=-999 required=2 tests=[AWL=0.052, BAYES_00=-2.599] X-Spam-Score: -2.547 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] IAX2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 01:23:06 -0000 On Sun, 2006-06-18 at 21:31 +0200, Damien Sandras wrote: > Le dimanche 18 juin 2006 à 08:11 +1200, Stephen Cook a écrit : > > Hello, > > > > It's been a long time I gave you guys an update. > > > > In IAX2 in opal I have got music on hold going which is nice :). I will > > be doing registration next as this is probably the most important > > feature for users. Also I have not run in to any stability problems > > with IAX2. > > > > My iax2/ekiga integration is working well as a tester with my asterisk > > server. It basically has all the functionality there but needs more > > integration and bug/quirky fixes. Also some refactoring in the future > > would be nice depending if I get time or not... > > Hi, > > > I've seen Derek committed some code from you. > > I think it is important that you keep a repository with your patches so > that we really know what you have fixed/added for Google SoC. > (Actually, I should see the patches, even though it is perfectly > acceptable that Derek commits them). I'll try and get you to review them first. I'll also put the patches on my website and give you guys a link soon. > > Thank you, From jpuydt@free.fr Mon Jun 19 01:26:43 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E9CF83B09E1 for ; Mon, 19 Jun 2006 01:26:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25898-10 for ; Mon, 19 Jun 2006 01:26:41 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 737143B03C7 for ; Mon, 19 Jun 2006 01:26:41 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-60-82-254-197-114.adsl.proxad.net [82.254.197.114]) by smtp1-g19.free.fr (Postfix) with ESMTP id C5B1D10170 for ; Mon, 19 Jun 2006 07:25:07 +0200 (CEST) Message-ID: <44963539.6080309@free.fr> Date: Mon, 19 Jun 2006 07:25:13 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.567 tagged_above=-999 required=2 tests=[AWL=0.032, BAYES_00=-2.599] X-Spam-Score: -2.567 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Main window size X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 05:26:43 -0000 Johan Brannlund a écrit : > I posted the below as a wishlist bug, but apparently the developers prefer > carrying out the discussion on this mailing list. This is what I wrote: Well, bug reports are nice for a beta or a stable release ; during the development cycle, discussing on the -devel- mailing-list is better (especially right at the beginning). :-) > "I just tried the 20060615 cvs snapshot of ekiga, and it's getting better > all the time. I have a small request though: I don't use video, which > means that the main window is much bigger than it has to be. > > Would it be possible to add a resizing widget, or to automatically make the > window smaller when video is disabled?" > > Damien also added the following comment: > > "I would also say that it will look less bigger when having a contacts > list. :) " > > ... which I don't quite understand. At least in my snapshot, the contacts > are in a separate window. He means that you should see some of your contacts in the main window in the future, with presence information about them. Snark From dsandras@seconix.com Mon Jun 19 04:55:21 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 539283B00A5 for ; Mon, 19 Jun 2006 04:55:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01183-02 for ; Mon, 19 Jun 2006 04:55:13 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id CCC843B0004 for ; Mon, 19 Jun 2006 04:55:11 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id D5FC083C1F for ; Mon, 19 Jun 2006 10:34:14 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32316-06 for ; Mon, 19 Jun 2006 10:34:11 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 694B183C1A for ; Mon, 19 Jun 2006 10:34:11 +0200 (CEST) From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44963539.6080309@free.fr> References: <44963539.6080309@free.fr> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 19 Jun 2006 10:54:04 +0200 Message-Id: <1150707244.2904.2.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Main window size X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 08:55:21 -0000 Le lundi 19 juin 2006 à 07:25 +0200, Julien PUYDT a écrit : > Johan Brannlund a écrit : > > I posted the below as a wishlist bug, but apparently the developers prefer > > carrying out the discussion on this mailing list. This is what I wrote: > > Well, bug reports are nice for a beta or a stable release ; during the > development cycle, discussing on the -devel- mailing-list is better > (especially right at the beginning). :-) > Yes, because it is a work in progress. So it will change with time, and get improved. No worries :) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From firstone5@hotmail.com Wed Jun 21 13:09:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C9A9D3B02A4 for ; Wed, 21 Jun 2006 13:09:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23702-03 for ; Wed, 21 Jun 2006 13:09:09 -0400 (EDT) Received: from hotmail.com (bay101-f15.bay101.hotmail.com [64.4.56.25]) by menubar.gnome.org (Postfix) with ESMTP id C2B763B01C1 for ; Wed, 21 Jun 2006 13:09:09 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Jun 2006 10:09:08 -0700 Message-ID: Received: from 64.4.56.200 by by101fd.bay101.hotmail.msn.com with HTTP; Wed, 21 Jun 2006 17:09:07 GMT X-Originating-IP: [69.245.3.192] X-Originating-Email: [firstone5@hotmail.com] X-Sender: firstone5@hotmail.com From: "M. Renee Hopkins" To: gnomemeeting-devel-list@gnome.org Date: Wed, 21 Jun 2006 17:09:07 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 21 Jun 2006 17:09:08.0863 (UTC) FILETIME=[68BD40F0:01C69555] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=0.607 tagged_above=-999 required=2 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: 0.607 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Mingw build of CVS ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:09:11 -0000 Greetings all, I am now building ekiga from cvs with the mingw tools on linux with some success, thanks to help from the list developers and patches. Most all features seem to be working. However, my builds don't detect the videoforwindows devices even though other ekiga.exe (not mine) versions correctly see the camera. Any ideas for missing switches on compile before I began greping through pwlib? I'm rather new to the code so any help is appreciated. Congrads to all developers on great work, MR From dsandras@seconix.com Wed Jun 21 13:42:37 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C742A3B05E9 for ; Wed, 21 Jun 2006 13:42:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25791-05 for ; Wed, 21 Jun 2006 13:42:36 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 0647C3B00B0 for ; Wed, 21 Jun 2006 13:42:35 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id AC0EF83C1C for ; Wed, 21 Jun 2006 19:22:12 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05950-02 for ; Wed, 21 Jun 2006 19:22:11 +0200 (CEST) Received: from [192.168.0.161] (185.1-247-81.adsl-dyn.isp.belgacom.be [81.247.1.185]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id C5DD783C1B for ; Wed, 21 Jun 2006 19:22:10 +0200 (CEST) From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-15 Date: Wed, 21 Jun 2006 19:43:29 +0200 Message-Id: <1150911809.2537.7.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.461 tagged_above=-999 required=2 tests=[AWL=0.003, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.461 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Mingw build of CVS ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:42:38 -0000 Le mercredi 21 juin 2006 à 17:09 +0000, M. Renee Hopkins a écrit : > Greetings all, > > I am now building ekiga from cvs with the mingw tools on linux with some > success, thanks to help from the list developers and patches. > > Most all features seem to be working. However, my builds don't detect the > videoforwindows devices even though other ekiga.exe (not mine) versions > correctly see the camera. > > Any ideas for missing switches on compile before I began greping through > pwlib? > I'm not an expert of the win32 build, but the first guess would be that the pwlib plugins are not compiled in. > I'm rather new to the code so any help is appreciated. > > Congrads to all developers on great work, > MR > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From tonim@telefonica.net Wed Jun 28 04:13:24 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9083D3B0079 for ; Wed, 28 Jun 2006 04:13:24 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31830-06 for ; Wed, 28 Jun 2006 04:13:23 -0400 (EDT) Received: from lothlorienng.sisman.info (157.Red-83-58-24.dynamicIP.rima-tde.net [83.58.24.157]) by menubar.gnome.org (Postfix) with ESMTP id C1F293B0002 for ; Wed, 28 Jun 2006 04:13:22 -0400 (EDT) Received: from gandalf.sisman.info (gandalf.sisman.info [192.168.16.201]) by lothlorienng.sisman.info (Postfix) with ESMTP id B33D71D8437 for ; Wed, 28 Jun 2006 08:18:54 +0200 (CEST) From: Toni Moreno To: gnomemeeting-devel-list@gnome.org In-Reply-To: <1150680115.31741.1.camel@siti> References: <1150575098.10433.5.camel@siti> <1150659087.2477.3.camel@golgoth01> <1150680115.31741.1.camel@siti> Content-Type: text/plain Date: Wed, 28 Jun 2006 08:09:46 +0200 Message-Id: <1151474986.5988.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: Yes, score=2.597 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046, SPF_NEUTRAL=1.069] X-Spam-Score: 2.597 X-Spam-Level: ** X-Spam-Flag: YES Subject: [GnomeMeeting-devel-list] A bit OFF-TOPIC, but usefull X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 08:13:24 -0000 I have found a report of skype, which shows the huge network activity it has (apart from voice network usage). Interesting to pinpoint differences between Skype & Ekiga, or other VoIP hardware phones. Enjoy, and excuse me the off-topic. http://www.ja.net/development/voip/skype&janet.pdf -- Toni Moreno From lurch@gmx.li Thu Jun 29 03:50:09 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A67023B011E for ; Thu, 29 Jun 2006 03:50:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26540-04 for ; Thu, 29 Jun 2006 03:50:02 -0400 (EDT) Received: from asclepius.uwa.edu.au (unknown [130.95.128.56]) by menubar.gnome.org (Postfix) with ESMTP id 6733A3B04C2 for ; Thu, 29 Jun 2006 03:50:01 -0400 (EDT) Received: from asclepius.kas (localhost.localdomain [127.0.0.1]) by asclepius.uwa.edu.au (Postfix) with SMTP id E6028183A6F for ; Thu, 29 Jun 2006 15:49:45 +0800 (WST) Received: from asclepius (localhost.localdomain [127.0.0.1]) by asclepius.prekas (Postfix) with SMTP id CC7321841AD for ; Thu, 29 Jun 2006 15:49:45 +0800 (WST) X-UWA-Client-IP: 130.95.28.15 (UWA) Received: from ns1.watri.uwa.edu.au (ns1.watri.org.au [130.95.28.15]) by asclepius.extinput (Postfix) with ESMTP id B3012183CC9 for ; Thu, 29 Jun 2006 15:49:45 +0800 (WST) Received: from [130.95.29.76] (gluttony.watri.org.au [130.95.29.76]) by ns1.watri.uwa.edu.au (8.13.1/8.13.1) with ESMTP id k5T7nflM013861 for ; Thu, 29 Jun 2006 15:49:44 +0800 (WST) Message-ID: <44A386D4.8040708@gmx.li> Date: Thu, 29 Jun 2006 15:52:52 +0800 From: =?ISO-8859-1?Q?Stefan_Br=FCns?= User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <200606081002.37875.conrad_videokonferenz@gmx.de> <1150380224.6599.22.camel@ganymede.verfaction.de> In-Reply-To: <1150380224.6599.22.camel@ganymede.verfaction.de> Content-Type: multipart/mixed; boundary="------------030008030501050603080306" X-SpamTest-Info: Profile: Formal (405/060628) X-SpamTest-Info: Profile: Detect Hard [UCS 290904] X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking Spam - Subject (UCS) [02-08-04] X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.358 tagged_above=-999 required=2 tests=[AWL=-0.036, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142] X-Spam-Score: -1.358 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 07:50:09 -0000 This is a multi-part message in MIME format. --------------030008030501050603080306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> The last version I can install using apt-get a couple of days old (May 25 - or >> somethin) - at least this is a version with the nonfunctional German locale. >> (defaults to English) >> >> What's up? > > > /me is having a sheer lack of time and thus it took me a while to get > everything polished and fixed just like i love to have it. =) > Everything should be back to normal as of tonight (eventually sarge cvs > snaps and win32 will remain for the weekend - we'll see) I think I have found the problem with the missing tranlations - it is caused by the recent change from the ALL_LINGUAS variable to the po/LINGUAS file. Patch attached. @Kilian: can you try the patch and submit it upstream, if successfull? Lurchi --------------030008030501050603080306 Content-Type: text/plain; name="configure_in_fix_all_linguas.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="configure_in_fix_all_linguas.diff" --- configure.in_orig 2006-06-29 07:59:40.000000000 +0200 +++ configure.in 2006-06-29 09:10:08.000000000 +0200 @@ -527,7 +527,8 @@ dnl Support for internationalization dnl ######################################################################## AC_SUBST([CONFIG_STATUS_DEPENDENCIES],['$(top_srcdir)/po/LINGUAS']) -ALL_LINGUAS="`grep -v '^#' "$srcdir/po/LINGUAS"`" +# ALL_LINGUAS="`grep -v '^#' "$srcdir/po/LINGUAS"`" +ALL_LINGUAS="`sed -ne '/\#.*/ d; H; $ {x; s/^\\n//g; s/\\n/ /g; p}' "$srcdir/po/LINGUAS"`" GETTEXT_PACKAGE=AC_PACKAGE_NAME AC_SUBST(GETTEXT_PACKAGE) --------------030008030501050603080306-- From jpuydt@free.fr Thu Jun 29 06:15:38 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0617C3B050F for ; Thu, 29 Jun 2006 06:15:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03057-05 for ; Thu, 29 Jun 2006 06:15:36 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 17C0C3B02CE for ; Thu, 29 Jun 2006 06:15:36 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-61-82-250-109-134.adsl.proxad.net [82.250.109.134]) by smtp5-g19.free.fr (Postfix) with ESMTP id 08B3E27766 for ; Thu, 29 Jun 2006 12:15:34 +0200 (CEST) Message-ID: <44A3A865.7000201@free.fr> Date: Thu, 29 Jun 2006 12:16:05 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <200606081002.37875.conrad_videokonferenz@gmx.de> <1150380224.6599.22.camel@ganymede.verfaction.de> <44A386D4.8040708@gmx.li> In-Reply-To: <44A386D4.8040708@gmx.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.596 tagged_above=-999 required=2 tests=[AWL=0.003, BAYES_00=-2.599] X-Spam-Score: -2.596 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 10:15:38 -0000 Stefan Brüns a écrit : > @Kilian: can you try the patch and submit it upstream, if successfull? You can call me "Snark", you know ;-) Snark From jpuydt@free.fr Thu Jun 29 06:20:46 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5F2F33B0286 for ; Thu, 29 Jun 2006 06:20:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03470-04 for ; Thu, 29 Jun 2006 06:20:45 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 5A2F43B01CE for ; Thu, 29 Jun 2006 06:20:45 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-61-82-250-109-134.adsl.proxad.net [82.250.109.134]) by smtp5-g19.free.fr (Postfix) with ESMTP id 4DBBF2765B for ; Thu, 29 Jun 2006 12:20:44 +0200 (CEST) Message-ID: <44A3A99B.8030605@free.fr> Date: Thu, 29 Jun 2006 12:21:15 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <200606081002.37875.conrad_videokonferenz@gmx.de> <1150380224.6599.22.camel@ganymede.verfaction.de> <44A386D4.8040708@gmx.li> <44A3A865.7000201@free.fr> In-Reply-To: <44A3A865.7000201@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.596 tagged_above=-999 required=2 tests=[AWL=0.003, BAYES_00=-2.599] X-Spam-Score: -2.596 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 10:20:46 -0000 Julien PUYDT a écrit : > Stefan Brüns a écrit : >> @Kilian: can you try the patch and submit it upstream, if successfull? > > You can call me "Snark", you know ;-) Hmmmm... which "upstream" are we talking about ? :-) /me should read before answering ;-) Snark From dsandras@seconix.com Thu Jun 1 02:40:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F28C93B00EB for ; Thu, 1 Jun 2006 02:40:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10407-03 for ; Thu, 1 Jun 2006 02:40:07 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 9FA173B00CB for ; Thu, 1 Jun 2006 02:40:06 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id DE1A2496FC for ; Thu, 1 Jun 2006 08:23:55 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15636-08 for ; Thu, 1 Jun 2006 08:23:54 +0200 (CEST) Received: from [172.16.100.156] (tcts.fpms.ac.be [193.190.194.194]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 0CBC0496FB for ; Thu, 1 Jun 2006 08:23:54 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <447DF183.3090300@cs.stanford.edu> References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-15 Date: Thu, 01 Jun 2006 08:41:01 +0200 Message-Id: <1149144061.2457.4.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 06:40:10 -0000 Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > I'd imagine it would work on win32, but don't know. > Probably. > I'll work on the patches. > > Where's the right place to add required libraries like openGL? In configure.in. > configure.in seems to be autogenerated by something, but whatever it is > doesn't seem to be in the CVS snapshot... > configure.in is in the CVS snapshot. > Thanks, > > -Dan > > Julien PUYDT wrote: > > > Dan Sandberg a écrit : > > > >> How should we proceed? I could just send you an updated gui/main.cpp > >> file... > > > > > > I'd like to see patches instead of full files, preferably independant > > on each others. > > > > There's also the question of the portability of this : since you > > mention SDL, I guess this will work great on win32 too ? > > > > Snark > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From hoglet@solit.se Thu Jun 1 09:09:47 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 90B2B3B017F for ; Thu, 1 Jun 2006 09:09:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04710-03 for ; Thu, 1 Jun 2006 09:09:45 -0400 (EDT) Received: from aurian.solit.se (unknown [82.182.216.174]) by menubar.gnome.org (Postfix) with ESMTP id 63B703B0134 for ; Thu, 1 Jun 2006 09:09:45 -0400 (EDT) Received: from ip76.kassjo.se ([85.11.28.76] helo=localhost.localdomain) by aurian.solit.se with asmtp (Exim 3.35 #1 (Debian)) id 1Flmvj-0004Et-00 for ; Thu, 01 Jun 2006 15:09:39 +0200 Date: Thu, 1 Jun 2006 15:09:38 +0200 From: Kent Asplund To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Re: Ekiga branched Message-Id: <20060601150938.fcdea791.hoglet@solit.se> In-Reply-To: <1148209984.2488.26.camel@golgoth01> References: <1147894199.7225.2.camel@golgoth01> <1148207277.6654.0.camel@frobisher.madeley.id.au> <1148209984.2488.26.camel@golgoth01> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: ej spam, SpamAssassin (resultat=-4.4, krav 5, IN_REP_TO -4.43) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.832 tagged_above=-999 required=2 tests=[AWL=-0.510, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142] X-Spam-Score: -1.832 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:09:47 -0000 --Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 21 May 2006 13:13:04 +0200 Damien Sandras wrote: > Le dimanche 21 mai 2006 =E0 18:27 +0800, Davyd Madeley a =E9crit : > > On Wed, 2006-05-17 at 21:29 +0200, Damien Sandras wrote: > >=20 > > > I have created a new branch named "gnome-2-14" for Ekiga from the > > > current CVS HEAD. > >=20 > > What are your exciting plans for the next Ekiga? > >=20 >=20 > Most of the plans are on http://wiki.ekiga.org, but I would summarize it > by those big features : > - New user interface I have some problems selling Ekiga to my wife an mother-in-law because it lacks the list of contacts you are about to implement. Another detail is the "contact" button that they did not see as intuitive. Exchanging the button to a green phone handle (red when calling in progress) would make it more alike others and therefore easier to accept. Greetings /Kent --=20 Killing time murders opportunities. --Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEfucS4WZLcIH5l3kRAm+MAJ95cAJ7mAiuBBLrCdfk7vNFTiLv7ACeKWZd 6tzVdWbow84O8RfCFvm51AU= =lD5w -----END PGP SIGNATURE----- --Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ-- From jpuydt@free.fr Thu Jun 1 09:20:42 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 792AE3B01C4 for ; Thu, 1 Jun 2006 09:20:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05042-09 for ; Thu, 1 Jun 2006 09:20:38 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 505C93B01E3 for ; Thu, 1 Jun 2006 09:20:37 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-30-82-253-132-170.adsl.proxad.net [82.253.132.170]) by smtp1-g19.free.fr (Postfix) with ESMTP id DA3499ADFF for ; Thu, 1 Jun 2006 15:20:35 +0200 (CEST) Message-ID: <447EE9BE.5030005@free.fr> Date: Thu, 01 Jun 2006 15:21:02 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Re: Ekiga branched References: <1147894199.7225.2.camel@golgoth01> <1148207277.6654.0.camel@frobisher.madeley.id.au> <1148209984.2488.26.camel@golgoth01> <20060601150938.fcdea791.hoglet@solit.se> In-Reply-To: <20060601150938.fcdea791.hoglet@solit.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599] X-Spam-Score: -2.561 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:20:42 -0000 Kent Asplund a écrit : > Exchanging the button to a green phone handle (red when calling in > progress) would make it more alike others and therefore easier to > accept. The classic case of "your flying car lacks a spare wheel!" ;-) Snark From jan.schampera@web.de Thu Jun 1 12:03:48 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B922E3B0E4B for ; Thu, 1 Jun 2006 12:03:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18635-04 for ; Thu, 1 Jun 2006 12:03:47 -0400 (EDT) Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by menubar.gnome.org (Postfix) with ESMTP id EBE813B0E61 for ; Thu, 1 Jun 2006 12:01:39 -0400 (EDT) Received: from fwd29.aul.t-online.de by mailout05.sul.t-online.com with smtp id 1FlpcA-0003xH-07; Thu, 01 Jun 2006 18:01:38 +0200 Received: from mail.home.thebonsai.de (VypBOcZSYex2PaURfsq4FLxwkOKh2FKpRdjn4Nur7iMG3ImbsTH1w4@[84.147.102.147]) by fwd29.sul.t-online.de with esmtp id 1FlpO1-0yxMBM0; Thu, 1 Jun 2006 17:47:01 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id E08C06B173 for ; Thu, 1 Jun 2006 17:47:00 +0200 (CEST) Date: Thu, 1 Jun 2006 17:44:27 +0200 From: Jan Schampera To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode Message-ID: <20060601174427.48266dee@localhost.localdomain> In-Reply-To: <447DE4E2.7040204@cs.stanford.edu> References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> Organization: private X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: VypBOcZSYex2PaURfsq4FLxwkOKh2FKpRdjn4Nur7iMG3ImbsTH1w4@t-dialin.net X-TOI-MSGID: e6494e3b-869b-447f-a832-f769a200d3af X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.942 tagged_above=-999 required=2 tests=[AWL=0.656, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.942 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:03:48 -0000 On Wed, 31 May 2006 11:48:02 -0700 Dan Sandberg wrote: > 2) Replace the SDL/GTK/GDK calls that do the full screen resizing with > OpenGL ones. [ This is done, needs to be integrated ] Guess that's the key I searched for, when I measured those performance problems. Something that is "usually" installed on the user's machines and that has more power then GDK/SDL (I was afraid to raise yet another exotic dependancy, but OpenGL seems fair enough). J. -- "Be liberal in what you accept, and conservative in what you send." - J. B. Postel, master of the net. From siti@orcon.net.nz Fri Jun 2 05:53:55 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5C8803B10AE for ; Fri, 2 Jun 2006 05:53:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15897-03 for ; Fri, 2 Jun 2006 05:53:53 -0400 (EDT) Received: from dbmail-mx4.orcon.co.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 1A8E13B0EB6 for ; Fri, 2 Jun 2006 05:53:52 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx4.orcon.co.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k529rnLs032645 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 2 Jun 2006 21:53:50 +1200 From: Stephen Cook To: GnomeMeeting development mailing list Content-Type: text/plain Date: Fri, 02 Jun 2006 21:55:24 +1200 Message-Id: <1149242124.4509.17.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.2/1506/Fri Jun 2 16:01:20 2006 on dbmail-mx4.orcon.co.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: Subject: [GnomeMeeting-devel-list] IAX2 In Ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 09:53:55 -0000 Hi, I haven't introduced myself here before, I am Stephen Cook (siti). My proposal for implementing IAX2 in ekiga got accepted with google's summer of code. To give an update (I'll try and keep you guys regularly posted as to what's happening, any problems etc.). Currently I have been looking at the code to gain an understanding of ekiga and opal's code and design. Also obviously checking out the IAX2 code in opal :). From what I have seen and got working, I will work on getting IAX2 going in ekiga first. The main part of this will obviously involve writing a gnome meeting endpoint for IAX2. One key problem I have identified is the accounts code. The protocols are tightly integrated with how it works. I could either refactor this code to loosen the integration or hack iax2 support in there and refactor it later ;). The advantage of this refactored will be when someone wants to add Xmpp/libjingle support, or some other protocol down the track. Well, please tell me your thoughts and comments on this project. -Stephen From x@cs.stanford.edu Fri Jun 2 06:04:24 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0CBE83B0EB6 for ; Fri, 2 Jun 2006 06:04:24 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16680-02 for ; Fri, 2 Jun 2006 06:04:22 -0400 (EDT) Received: from smtp102.plus.mail.mud.yahoo.com (smtp102.plus.mail.mud.yahoo.com [68.142.206.235]) by menubar.gnome.org (Postfix) with SMTP id 1A3583B0490 for ; Fri, 2 Jun 2006 06:04:22 -0400 (EDT) Received: (qmail 57482 invoked from network); 2 Jun 2006 10:04:21 -0000 Received: from unknown (HELO ?192.168.2.47?) (dan?sandberg@71.138.128.214 with plain) by smtp102.plus.mail.mud.yahoo.com with SMTP; 2 Jun 2006 10:04:20 -0000 Message-ID: <44800CFA.5090800@cs.stanford.edu> Date: Fri, 02 Jun 2006 03:03:38 -0700 From: Dan Sandberg User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> In-Reply-To: <1149144061.2457.4.camel@golgoth01> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.808 tagged_above=-999 required=2 tests=[AWL=-0.593, BAYES_00=-2.599, SPF_SOFTFAIL=1.384] X-Spam-Score: -1.808 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 10:04:24 -0000 So configure.in is hand-generated? Surprising. 1) How exactly do I add the opengl ( libgl ) library? 2) Xrandr is mentioned in the Makefile, but is not in configure.in. How exactly does it get put into the Makefile? 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I didn't want to code against a moving target. Thanks, -Dan Damien Sandras wrote: >Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > > >>I'd imagine it would work on win32, but don't know. >> >> >> > >Probably. > > > >>I'll work on the patches. >> >>Where's the right place to add required libraries like openGL? >> >> > >In configure.in. > > > >>configure.in seems to be autogenerated by something, but whatever it is >>doesn't seem to be in the CVS snapshot... >> >> >> > >configure.in is in the CVS snapshot. > > > > >>Thanks, >> >>-Dan >> >>Julien PUYDT wrote: >> >> >> >>>Dan Sandberg a écrit : >>> >>> >>> >>>>How should we proceed? I could just send you an updated gui/main.cpp >>>>file... >>>> >>>> >>>I'd like to see patches instead of full files, preferably independant >>>on each others. >>> >>>There's also the question of the portability of this : since you >>>mention SDL, I guess this will work great on win32 too ? >>> >>>Snark >>>_______________________________________________ >>>Gnomemeeting-devel-list mailing list >>>Gnomemeeting-devel-list@gnome.org >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list >>> >>> >>> >>_______________________________________________ >>Gnomemeeting-devel-list mailing list >>Gnomemeeting-devel-list@gnome.org >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list >> >> From dsandras@seconix.com Fri Jun 2 07:06:22 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9B2253B0407 for ; Fri, 2 Jun 2006 07:06:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20694-02 for ; Fri, 2 Jun 2006 07:06:20 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 830933B0490 for ; Fri, 2 Jun 2006 07:06:20 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 3567C4974A for ; Fri, 2 Jun 2006 12:49:55 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03852-06 for ; Fri, 2 Jun 2006 12:49:51 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 5D9BD49749 for ; Fri, 2 Jun 2006 12:49:51 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <1149242124.4509.17.camel@siti> References: <1149242124.4509.17.camel@siti> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 02 Jun 2006 13:06:14 +0200 Message-Id: <1149246374.2966.25.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:06:22 -0000 Le vendredi 02 juin 2006 à 21:55 +1200, Stephen Cook a écrit : > Hi, > > I haven't introduced myself here before, I am Stephen Cook (siti). My > proposal for implementing IAX2 in ekiga got accepted with google's > summer of code. > > To give an update (I'll try and keep you guys regularly posted as to > what's happening, any problems etc.). > > Currently I have been looking at the code to gain an understanding of > ekiga and opal's code and design. Also obviously checking out the IAX2 > code in opal :). From what I have seen and got working, I will work on > getting IAX2 going in ekiga first. The main part of this will obviously > involve writing a gnome meeting endpoint for IAX2. > I would say that the main part will be to write / finish the IAX2 code in OPAL, either new code, or reusing the current code so that all features that you see in SIP and H.323 are also available for IAX2. Your first project will be to look the limitations of the current code and write a document showing what features you have tested, what work is required to complete them, and what new work is required for new features (Call Hold, Call Transfer, Registering, Call Forward, ...). Writing the endpoint in Ekiga is the last part of the project once the code in OPAL is full functional. Ekiga only contains high-level code. > One key problem I have identified is the accounts code. The protocols > are tightly integrated with how it works. I could either refactor this > code to loosen the integration or hack iax2 support in there and > refactor it later ;). The advantage of this refactored will be when > someone wants to add Xmpp/libjingle support, or some other protocol down > the track. > I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and finally perhaps to a refactoring of the accounts code as it is not the primary purpose of the Google SoC :) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Fri Jun 2 07:08:01 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 243E83B0407 for ; Fri, 2 Jun 2006 07:08:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20781-05 for ; Fri, 2 Jun 2006 07:07:58 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 6C7333B10B6 for ; Fri, 2 Jun 2006 07:07:58 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 5426B49753 for ; Fri, 2 Jun 2006 12:51:33 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06419-06 for ; Fri, 2 Jun 2006 12:51:18 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id EF0D549750 for ; Fri, 2 Jun 2006 12:51:17 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44800CFA.5090800@cs.stanford.edu> References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 02 Jun 2006 13:07:41 +0200 Message-Id: <1149246461.2966.28.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:08:01 -0000 Le vendredi 02 juin 2006 à 03:03 -0700, Dan Sandberg a écrit : > So configure.in is hand-generated? Surprising. > That's te way it works. You write configure.in and configure is generated from there. I guess you are confusing things here. > 1) How exactly do I add the opengl ( libgl ) library? > By writing autconf code in configure.in. No idea exactly how it should be done. > 2) Xrandr is mentioned in the Makefile, but is not in configure.in. How > exactly does it get put into the Makefile? > Probably by an external library that we are using. > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I didn't want > to code against a moving target. > Yes. It is even OK if you do not provide the configure.in code, but only the OpenGL Ekiga code. > Thanks, > > -Dan > > Damien Sandras wrote: > > >Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > > > > > >>I'd imagine it would work on win32, but don't know. > >> > >> > >> > > > >Probably. > > > > > > > >>I'll work on the patches. > >> > >>Where's the right place to add required libraries like openGL? > >> > >> > > > >In configure.in. > > > > > > > >>configure.in seems to be autogenerated by something, but whatever it is > >>doesn't seem to be in the CVS snapshot... > >> > >> > >> > > > >configure.in is in the CVS snapshot. > > > > > > > > > >>Thanks, > >> > >>-Dan > >> > >>Julien PUYDT wrote: > >> > >> > >> > >>>Dan Sandberg a écrit : > >>> > >>> > >>> > >>>>How should we proceed? I could just send you an updated gui/main.cpp > >>>>file... > >>>> > >>>> > >>>I'd like to see patches instead of full files, preferably independant > >>>on each others. > >>> > >>>There's also the question of the portability of this : since you > >>>mention SDL, I guess this will work great on win32 too ? > >>> > >>>Snark > >>>_______________________________________________ > >>>Gnomemeeting-devel-list mailing list > >>>Gnomemeeting-devel-list@gnome.org > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > >>> > >>> > >>> > >>_______________________________________________ > >>Gnomemeeting-devel-list mailing list > >>Gnomemeeting-devel-list@gnome.org > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > >> > >> > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From jpuydt@free.fr Fri Jun 2 09:55:37 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 35E163B0A0B for ; Fri, 2 Jun 2006 09:55:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30481-03 for ; Fri, 2 Jun 2006 09:55:35 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id DF18F3B0468 for ; Fri, 2 Jun 2006 09:55:34 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-30-82-253-132-170.adsl.proxad.net [82.253.132.170]) by smtp6-g19.free.fr (Postfix) with ESMTP id D0F23225C9 for ; Fri, 2 Jun 2006 15:55:31 +0200 (CEST) Message-ID: <44804375.6090107@free.fr> Date: Fri, 02 Jun 2006 15:56:05 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga References: <1149242124.4509.17.camel@siti> <1149246374.2966.25.camel@golgoth01> In-Reply-To: <1149246374.2966.25.camel@golgoth01> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599] X-Spam-Score: -2.561 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 13:55:37 -0000 Damien Sandras a écrit : > I would say that the main part will be to write / finish the IAX2 code > in OPAL, either new code, or reusing the current code so that all > features that you see in SIP and H.323 are also available for IAX2. > > Your first project will be to look the limitations of the current code > and write a document showing what features you have tested, what work is > required to complete them, and what new work is required for new > features (Call Hold, Call Transfer, Registering, Call Forward, ...). > > Writing the endpoint in Ekiga is the last part of the project once the > code in OPAL is full functional. Ekiga only contains high-level code. I don't fully agree with you: writing low-level code all summer long then finally writing the upper-level code, will lead to a non-working feature :-/ Having a least minimal functionality in ekiga would be nice to test the low-level regularly, and see it improving. >> One key problem I have identified is the accounts code. The protocols >> are tightly integrated with how it works. I could either refactor this >> code to loosen the integration or hack iax2 support in there and >> refactor it later ;). The advantage of this refactored will be when >> someone wants to add Xmpp/libjingle support, or some other protocol down >> the track. > > I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and > finally perhaps to a refactoring of the accounts code as it is not the > primary purpose of the Google SoC :) Indeed, the purpose is the IAX2 support, not refactoring the code. I would say that hardcoding the IAX2 account setup in the code would be enough for the SoC. Making it work in the ui in the accounts would be bonus if you had the time, or would be a work to do afterwards. Snark From dsandras@seconix.com Fri Jun 2 10:34:17 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C28113B045D for ; Fri, 2 Jun 2006 10:34:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00352-08 for ; Fri, 2 Jun 2006 10:34:16 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id CE7FF3B0478 for ; Fri, 2 Jun 2006 10:34:15 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 0EFE1496C7 for ; Fri, 2 Jun 2006 16:17:49 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08222-10 for ; Fri, 2 Jun 2006 16:17:42 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 3C897496C6 for ; Fri, 2 Jun 2006 16:17:42 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44804375.6090107@free.fr> References: <1149242124.4509.17.camel@siti> <1149246374.2966.25.camel@golgoth01> <44804375.6090107@free.fr> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 02 Jun 2006 16:34:27 +0200 Message-Id: <1149258867.8383.10.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 14:34:17 -0000 Le vendredi 02 juin 2006 à 15:56 +0200, Julien PUYDT a écrit : > Damien Sandras a écrit : > > I would say that the main part will be to write / finish the IAX2 code > > in OPAL, either new code, or reusing the current code so that all > > features that you see in SIP and H.323 are also available for IAX2. > > > > Your first project will be to look the limitations of the current code > > and write a document showing what features you have tested, what work is > > required to complete them, and what new work is required for new > > features (Call Hold, Call Transfer, Registering, Call Forward, ...). > > > > Writing the endpoint in Ekiga is the last part of the project once the > > code in OPAL is full functional. Ekiga only contains high-level code. > > I don't fully agree with you: writing low-level code all summer long > then finally writing the upper-level code, will lead to a non-working > feature :-/ I agree with you, but you can not start writing the EndPoint if there is no code behind it ;) > > Having a least minimal functionality in ekiga would be nice to test the > low-level regularly, and see it improving. > > >> One key problem I have identified is the accounts code. The protocols > >> are tightly integrated with how it works. I could either refactor this > >> code to loosen the integration or hack iax2 support in there and > >> refactor it later ;). The advantage of this refactored will be when > >> someone wants to add Xmpp/libjingle support, or some other protocol down > >> the track. > > > > I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and > > finally perhaps to a refactoring of the accounts code as it is not the > > primary purpose of the Google SoC :) > > Indeed, the purpose is the IAX2 support, not refactoring the code. I > would say that hardcoding the IAX2 account setup in the code would be > enough for the SoC. > > Making it work in the ui in the accounts would be bonus if you had the > time, or would be a work to do afterwards. > Exactly. > Snark > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From t.schorpp@gmx.de Fri Jun 2 11:06:17 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 63A943B02F7 for ; Fri, 2 Jun 2006 11:06:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02214-08 for ; Fri, 2 Jun 2006 11:06:10 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by menubar.gnome.org (Postfix) with SMTP id 7B6603B0421 for ; Fri, 2 Jun 2006 11:06:09 -0400 (EDT) Received: (qmail invoked by alias); 02 Jun 2006 15:06:08 -0000 Received: from p85.212.150.108.tisdip.tiscali.de (EHLO [192.168.1.100]) [85.212.150.108] by mail.gmx.net (mp001) with SMTP; 02 Jun 2006 17:06:08 +0200 X-Authenticated: #17142692 Message-ID: <448053DE.1010406@gmx.de> Date: Fri, 02 Jun 2006 17:06:06 +0200 From: thomas schorpp User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1 X-Accept-Language: de, en-us MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Bad review about Ekiga References: <1148993400.2400.77.camel@golgoth01> In-Reply-To: <1148993400.2400.77.camel@golgoth01> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.476 tagged_above=-999 required=2 tests=[AWL=-0.011, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] X-Spam-Score: -2.476 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: t.schorpp@gmx.de, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 15:06:17 -0000 Damien Sandras wrote: > http://linux.softpedia.com/progViewUserReviews/156167.html > > This software is a descendant of the former "gnome-meeting" software. It > comes bundled with its own SIP service but claims to work with others. > Unfortunately it has inherited not only the GUI from gnome-meeting but > also the habit to crash every other minute without apparent reason. So I > never got to really test it yet. > > The developers might be better off not making the same mistake as they > did with gnome-meeting and should try to fix all the bugs instead of > adding more crashing bells and whistles. Bad? Bad yes: for marketing. You cant just say this commenter were just too stupid to get the right libs together. Bad no: for development. says You need better CM: - suggest the devs and QA people, users, agree on a certain range of gui libs versions. - suggest meeting with distro maintainers and tight the deps found above to avoid lib/binary inconsistencies. - improve exception handling and fault tolerance on the outside interfaces. ? y tom From craigs@postincrement.com Fri Jun 2 19:57:21 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CDB2A3B11E3 for ; Fri, 2 Jun 2006 19:57:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32469-02 for ; Fri, 2 Jun 2006 19:57:18 -0400 (EDT) Received: from bastion.southeren.com (unknown [220.244.81.10]) by menubar.gnome.org (Postfix) with ESMTP id 870583B11CC for ; Fri, 2 Jun 2006 19:57:17 -0400 (EDT) Received: from [10.0.2.13] (rapido.southeren.com [10.0.2.13]) by bastion.southeren.com (8.12.8/8.12.8) with ESMTP id k52NteJG016237; Sat, 3 Jun 2006 09:55:40 +1000 Date: Sat, 03 Jun 2006 09:55:43 +1000 From: Craig Southeren To: Stephen Cook , GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga In-Reply-To: <1149242124.4509.17.camel@siti> References: <1149242124.4509.17.camel@siti> Message-Id: <20060603095331.79CD.CRAIGS@postincrement.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Becky! ver. 2.11.02 [en] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.939 tagged_above=-999 required=2 tests=[AWL=-0.482, BAYES_00=-2.599, SPF_FAIL=1.142] X-Spam-Score: -1.939 X-Spam-Level: Cc: Derek Smithies X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 23:57:22 -0000 On Fri, 02 Jun 2006 21:55:24 +1200 Stephen Cook wrote: > Hi, >=20 > I haven't introduced myself here before, I am Stephen Cook (siti). My > proposal for implementing IAX2 in ekiga got accepted with google's > summer of code. >=20 > To give an update (I'll try and keep you guys regularly posted as to > what's happening, any problems etc.). >=20 > Currently I have been looking at the code to gain an understanding of > ekiga and opal's code and design. Also obviously checking out the IAX2 > code in opal :). From what I have seen and got working, I will work on > getting IAX2 going in ekiga first. The main part of this will obviously > involve writing a gnome meeting endpoint for IAX2. >=20 > One key problem I have identified is the accounts code. The protocols > are tightly integrated with how it works. I could either refactor this > code to loosen the integration or hack iax2 support in there and > refactor it later ;). The advantage of this refactored will be when > someone wants to add Xmpp/libjingle support, or some other protocol down > the track. >=20 > Well, please tell me your thoughts and comments on this project. As a New Zealander, you are uniquely placed to communicate with the author of the OPAL IAX2 code, Derek Smithies, who is a fellow Kiwi! I am sure that you will be able to get the OPAL IAX2 code working with Ekiga in no time at all with his help.=20 If you have any questions, please contact me directly. Craig ----------------------------------------------------------------------- Craig Southeren Post Increment =96 VoIP Consulting and Software craigs@postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren@hotmail.com Mobile: +61 417231046 =20 "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting From hoglet@solit.se Sat Jun 3 03:46:01 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9178F3B04E8 for ; Sat, 3 Jun 2006 03:46:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19488-05 for ; Sat, 3 Jun 2006 03:45:59 -0400 (EDT) Received: from aurian.solit.se (unknown [82.182.216.174]) by menubar.gnome.org (Postfix) with ESMTP id 9DD3C3B0505 for ; Sat, 3 Jun 2006 03:45:59 -0400 (EDT) Received: from ip76.kassjo.se ([85.11.28.76] helo=localhost.localdomain) by aurian.solit.se with asmtp (Exim 3.35 #1 (Debian)) id 1FmQpW-0006J7-00 for ; Sat, 03 Jun 2006 09:45:54 +0200 Date: Sat, 3 Jun 2006 09:45:50 +0200 From: Kent Asplund To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Bad review about Ekiga Message-Id: <20060603094550.0e1ff8aa.hoglet@solit.se> In-Reply-To: <1148993400.2400.77.camel@golgoth01> References: <1148993400.2400.77.camel@golgoth01> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: ej spam, SpamAssassin (resultat=-4.4, krav 5, IN_REP_TO -4.43) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.898 tagged_above=-999 required=2 tests=[AWL=-1.435, BAYES_20=-0.74, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142] X-Spam-Score: -0.898 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 07:46:01 -0000 --Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 30 May 2006 14:50:00 +0200 Damien Sandras wrote: > http://linux.softpedia.com/progViewUserReviews/156167.html >=20 > This software is a descendant of the former "gnome-meeting" software. It > comes bundled with its own SIP service but claims to work with others. > Unfortunately it has inherited not only the GUI from gnome-meeting but > also the habit to crash every other minute without apparent reason. So I > never got to really test it yet. >=20 > The developers might be better off not making the same mistake as they > did with gnome-meeting and should try to fix all the bugs instead of > adding more crashing bells and whistles. I have never had a crash and the program was easy to setup. I have had some problem but they have been outside of Ekiga (siproxd and firewall) Ekiga has som distance to go to "get finished" but it is still THE BEST PROGRAM AROUND! Subjectively of course :) Waiting patiently for 2.2 /Hoglet --=20 Go ahead... make my day. -- Dirty Harry --Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEgT4x4WZLcIH5l3kRApw3AJ9yPgdPoUSeKGniD1w0w0cMTXajRACfWaDG 2YUvSTxFnaSeD8q0uWWv6zE= =2nFl -----END PGP SIGNATURE----- --Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny-- From hoglet@solit.se Sat Jun 3 03:54:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C25A43B05C8 for ; Sat, 3 Jun 2006 03:54:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19755-10 for ; Sat, 3 Jun 2006 03:54:38 -0400 (EDT) Received: from aurian.solit.se (unknown [82.182.216.174]) by menubar.gnome.org (Postfix) with ESMTP id B980A3B04F9 for ; Sat, 3 Jun 2006 03:54:38 -0400 (EDT) Received: from ip76.kassjo.se ([85.11.28.76] helo=localhost.localdomain) by aurian.solit.se with asmtp (Exim 3.35 #1 (Debian)) id 1FmQxt-0006L4-00 for ; Sat, 03 Jun 2006 09:54:33 +0200 Date: Sat, 3 Jun 2006 09:54:33 +0200 From: Kent Asplund To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Re: Ekiga branched Message-Id: <20060603095433.82461abf.hoglet@solit.se> In-Reply-To: <447EE9BE.5030005@free.fr> References: <1147894199.7225.2.camel@golgoth01> <1148207277.6654.0.camel@frobisher.madeley.id.au> <1148209984.2488.26.camel@golgoth01> <20060601150938.fcdea791.hoglet@solit.se> <447EE9BE.5030005@free.fr> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: ej spam, SpamAssassin (resultat=-4.4, krav 5, IN_REP_TO -4.43) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.764 tagged_above=-999 required=2 tests=[AWL=-0.519, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142, TW_KT=0.077] X-Spam-Score: -1.764 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 07:54:39 -0000 --Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 01 Jun 2006 15:21:02 +0200 Julien PUYDT wrote: > Kent Asplund a =E9crit : > > Exchanging the button to a green phone handle (red when calling in > > progress) would make it more alike others and therefore easier to > > accept. >=20 > The classic case of "your flying car lacks a spare wheel!" ;-) I'm taking the risk of seeming to be completely without humour. No, it is more a case of having a car with automatic gearbox and instead of having a lever you have a button for changing direction.=20 It works perfektly OK but people will think that it is a strange car and choose another one. (I think Citro=EBn had this problem) My wife just said "it is made for nerds not humans" Greetings /Hoglet the nerd --=20 I don't know anything about music. In my line you don't have to. -- Elvis Presley --Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEgUA54WZLcIH5l3kRAiYpAJ4/lkEYFVjWRQrYSvn7D9XmkU+6FgCgiejD m2Sp2AVqfZZHzT5TaBCVu5I= =OH96 -----END PGP SIGNATURE----- --Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ-- From devel@tootai.net Sat Jun 3 11:12:15 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3EF583B05AE for ; Sat, 3 Jun 2006 11:12:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11557-03 for ; Sat, 3 Jun 2006 11:12:10 -0400 (EDT) Received: from mail1.tootai.net (ns1.tootai.net [82.231.69.24]) by menubar.gnome.org (Postfix) with ESMTP id A02F63B0348 for ; Sat, 3 Jun 2006 11:12:09 -0400 (EDT) Received: from [192.168.0.17] (unknown [192.168.0.17]) by mail1.tootai.net (Postfix) with ESMTP id E2ACD398BA0 for ; Sat, 3 Jun 2006 17:12:06 +0200 (CEST) Message-ID: <4481A6AF.2060703@tootai.net> Date: Sat, 03 Jun 2006 17:11:43 +0200 From: Daniel Huhardeaux Organization: TOOTAi User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: GnomeMeeting development mailing list Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: Subject: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 15:12:15 -0000 Resent as it didn't pass at the first try (too big, I cut the begining of logs) Hi all, Ekiga behind a firewall is registering to an asterisk server which is on internet. The sip user is authorized with gsm,ulaw,alaw on asterisk side. When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is started, connection is showed with PCMU (why not GSM?), see the traffic in/out (~6 kB) but have no audio. I hangup the call, the hangup info is shown in the toolbar, PCMU disappear in codec and immediately after, traffic in/out continue with 0/0, icon in KDE Toolbar show Ekiga on line. The only solution I have is to kill Ekiga. If I deactivate GSM codec, everything is fine. Below you will find a d4 output from the call. [...] 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 OpalUDP Ended connect, selecting 82.231.69.24:35065 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP Queueing PDU: 1 INVITE <407> 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP Waiting for PDU on udp$213.203.241.243:5060 2006/06/02 13:12:32.901 0:10.661 SIP Handler:8520268 SIP PDU handler thread started. 2006/06/02 13:12:32.902 0:10.662 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:32.902 0:10.663 SIP Handler:8520268 SIP Handling PDU 1 INVITE <407> (with transaction) 2006/06/02 13:12:32.903 0:10.663 SIP Handler:8520268 SIP Transaction 1 INVITE completed. 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP Sending PDU on udp$213.203.241.243:5060 ACK sip:800@sip.tootai.net SIP/2.0 CSeq: 1 ACK Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bK803b125b-96f0-da11-8388-000ea6217592;rport From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: ;tag=as315809c6 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 70 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP Received Proxy Authentication Required response 2006/06/02 13:12:32.906 0:10.666 SIP Handler:8520268 SIP Transaction 2 INVITE created. 2006/06/02 13:12:32.906 0:10.667 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:33.090 0:10.850 SIP Handler:8520268 RTP_UDP Session 1 created: 82.231.69.24:35010-35011 ssrc=703395120 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 RTP Adding session RTP_UDP 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 SIP Using RTP payload [pt=101] for NTE 2006/06/02 13:12:33.100 0:10.860 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k H.261(QCIF) H.261(CIF) YUV420P RGB32 RGB24 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 2 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 2 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 SIP IsMediaBypassPossible: session 2 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:33.281 0:11.041 SIP Handler:8520268 RTP_UDP Session 2 created: 82.231.69.24:35014-35015 ssrc=2454563097 2006/06/02 13:12:33.282 0:11.042 SIP Handler:8520268 RTP Adding session RTP_UDP 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k H.261(QCIF) H.261(CIF) YUV420P RGB32 RGB24 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 SIP Adding authentication information 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP Sending PDU on udp$213.203.241.243:5060 INVITE sip:800@sip.tootai.net SIP/2.0 Date: Fri, 02 Jun 2006 11:12:32 GMT CSeq: 2 INVITE Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;rport User-Agent: Ekiga/2.0.1-20060521-01 From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: Contact: Proxy-Authorization: Digest username="104", realm="sip.tootai.net", nonce="12d01d5d", uri="sip:800@sip.tootai.net", response="60b65ec9045130eab45495d3c65fbc5e", algorithm=md5 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Type: application/sdp Content-Length: 302 Max-Forwards: 70 v=0 o=- 1149246753 1149246753 IN IP4 82.231.69.24 s=Opal SIP Session c=IN IP4 82.231.69.24 t=0 0 m=audio 35010 RTP/AVP 101 3 0 8 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 m=video 35014 RTP/AVP 31 a=rtpmap:31 H261/90000 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP PDU Received on udp$213.203.241.243:5060 SIP/2.0 100 Trying CSeq: 2 INVITE Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 User-Agent: Asterisk PBX From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP Queueing PDU: 2 INVITE <100> 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP Waiting for PDU on udp$213.203.241.243:5060 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP Handling PDU 2 INVITE <100> (with transaction) 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP Transaction 2 INVITE proceeding. 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Set targetAddress to sip:800@213.203.241.243 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Received Trying response 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP Media session port=7166 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP Adding media session with 2 formats 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP Unknown media attribute silenceSupp:off - - - - 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SIP PDU Received on udp$213.203.241.243:5060 SIP/2.0 200 OK CSeq: 2 INVITE Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 User-Agent: Asterisk PBX From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: ;tag=as5d2831d1 Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Type: application/sdp Content-Length: 221 v=0 o=root 26912 26912 IN IP4 213.203.241.243 s=session c=IN IP4 213.203.241.243 t=0 0 m=audio 7166 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP Queueing PDU: 2 INVITE <200> 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP Waiting for PDU on udp$213.203.241.243:5060 2006/06/02 13:12:33.388 0:11.148 SIP Handler:8520268 SIP Handling PDU 2 INVITE <200> (with transaction) 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP Transaction 2 INVITE completed. 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP Set targetAddress to sip:800@213.203.241.243 2006/06/02 13:12:33.390 0:11.150 SIP Handler:8520268 SIP Adding authentication information 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP Adjusting transport to address udp$213.203.241.243:5060 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP Sending PDU on udp$213.203.241.243:5060 ACK sip:800@213.203.241.243 SIP/2.0 CSeq: 2 ACK Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bK6e2ca15b-96f0-da11-8388-000ea6217592;rport From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: ;tag=as5d2831d1 Contact: Proxy-Authorization: Digest username="104", realm="sip.tootai.net", nonce="12d01d5d", uri="sip:800@213.203.241.243", response="059defd67706254552a5c23eada565b5", algorithm=md5 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 70 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP Received INVITE OK response 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 SIP RTP payload type PCMU matched to codec G.711-uLaw-64k 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 OpalCon OpenSourceMediaStream for session 1 on Call[1]-EP[Default] 2006/06/02 13:12:33.398 0:11.158 SIP Handler:8520268 OpalCon Selected media stream PCM-16 -> G.711-uLaw-64k 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 Call PatchMediaStreams Call[1]-EP[Default] 2006/06/02 13:12:34.196 0:11.957 SIP Handler:8520268 OpalCon OpenSinkMediaStream Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session=1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon OpenSinkMediaStream, selected PCM-16 -> G.711-uLaw-64k 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:34.197 0:11.958 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Patch Added sink from PCM-16 Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 16 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 to G.711-uLaw-64k Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 8 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Codec G711-uLaw-64k encoder created 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Patch Added media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k using transcoder PCM-16->G.711-uLaw-64k 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Media Audio source data size set to 320 bytes and 2 buffers. 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call GetOtherPartyConnection Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon OpenSourceMediaStream for session 1 on Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon Selected media stream G.711-uLaw-64k -> PCM-16 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 Call PatchMediaStreams Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon OpenSinkMediaStream Call[1]-EP[Default] session=1 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon OpenSinkMediaStream, selected G.711-uLaw-64k -> PCM-16 2006/06/02 13:12:34.513 0:12.274 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:34.514 0:12.274 SIP Handler:8520268 Patch Added sink from G.711-uLaw-64k Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 8 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 to PCM-16 Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 16 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Codec G711-uLaw-64k decoder created 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Media Audio sink data size set to 320 bytes and 2 buffers. 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Patch Added media stream sink OpalAudioMediaStream-Sink-PCM-16 using transcoder G.711-uLaw-64k->PCM-16 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.525 0:12.285 SIP Handler:8520268 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.527 0:12.287 SIP Handler:8520268 RTP_UDP SetRemoteSocketInfo: session=1 data channel, new=213.203.241.243:7166, local=82.231.69.24:35010-35011, remote=0.0.0.0:0-0 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 SIP Could not find SDP media description for Video 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 OpalMan OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 Call OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 PCSS SetConnected() 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 GMPCSSEndpoint PCSS connection established 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 GMManager Will establish the connection 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 OpalMan OnEstablished Call[1]-EP[Default] 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 Call OnEstablished Call[1]-EP[Default] 2006/06/02 13:12:34.540 0:12.300 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[Default] G.711-uLaw-64k 2006/06/02 13:12:34.541 0:12.301 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k 2006/06/02 13:12:34.542 0:12.302 SIP Handler:8520268 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.543 0:12.303 SIP Handler:8520268 Call OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] G.711-uLaw-64k 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[Default] 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k 2006/06/02 13:12:34.552 0:12.312 SIP Handler:8520268 Call OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k 2006/06/02 13:12:34.553 0:12.313 Media Patch:8175708 Patch Thread started for Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:34.556 0:12.316 SIP Handler:8520268 Media Starting thread Media Patch:8175708 2006/06/02 13:12:34.557 0:12.317 Media Patch:8527348 Patch Thread started for Patch OpalRTPMediaStream-Source-G.711-uLaw-64k -> OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:34.568 0:12.329 Media Patch:8527348 RTP Jitter buffer created: size=101 delay=160-4000/160 (20ms) obj=0x8526b30 2006/06/02 13:12:34.572 0:12.333 RTP Jitter:8526b30 RTP Jitter RTP receive thread started: 0x8526b30 2006/06/02 13:12:34.574 0:12.334 RTP Jitter:8526b30 RTP First receive data: ver=2 pt=GSM psz=33 m=0 x=0 seq=39915 ts=160 src=824302623 ccnt=0 2006/06/02 13:12:34.580 0:12.341 SIP Handler:8520268 Media Starting thread Media Patch:8527348 2006/06/02 13:12:34.581 0:12.341 SIP Handler:8520268 OpalCon Media stream threads started. 2006/06/02 13:12:34.582 0:12.342 SIP Handler:8520268 OpalCon Media stream threads started. 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP Found existing session 2 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 GMManager Will establish the connection 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 OpalMan OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.607 0:12.367 SIP Handler:8520268 Call OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.610 0:12.371 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:34.648 0:12.408 Media Patch:8527348 RTP Jitter buffer length exceeded 2006/06/02 13:12:34.649 0:12.409 Media Patch:8527348 RTP Jitter buffer length exceed was prior to first write. Not increasing buffer size 2006/06/02 13:12:35.277 0:13.037 Media Patch:8175708 RTP First sent data: ver=2 pt=PCMU psz=160 m=1 x=0 seq=1460 ts=0 src=703395120 ccnt=0 2006/06/02 13:12:35.608 0:13.368 Housekeeper RTP Found existing session 1 2006/06/02 13:12:35.609 0:13.369 Housekeeper RTP Found existing session 2 2006/06/02 13:12:36.137 0:13.898 RTP Jitter:8526b30 RTP Receive statistics: packets=101 octets=3714 lost=0 tooLate=0 order=0 avgTime=15 maxTime=1556 minTime=0 jitter=16 maxJitter=188 2006/06/02 13:12:36.573 0:14.333 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (9760) 2006/06/02 13:12:36.614 0:14.374 Housekeeper RTP Found existing session 1 2006/06/02 13:12:36.615 0:14.375 Housekeeper RTP Found existing session 2 2006/06/02 13:12:36.974 0:14.734 RTP Jitter:8526b30 RTP Jitter buffer continuously full, throwing away entire buffer. 2006/06/02 13:12:36.995 0:14.756 RTP Jitter:8526b30 RTP Jitter buffer full, threw away 21 oldest frames 2006/06/02 13:12:37.374 0:15.134 RTP Jitter:8526b30 RTP Receive statistics: packets=201 octets=19714 lost=0 tooLate=0 order=0 avgTime=12 maxTime=23 minTime=0 jitter=0 maxJitter=188 2006/06/02 13:12:37.620 0:15.380 Housekeeper RTP Found existing session 1 2006/06/02 13:12:37.621 0:15.381 Housekeeper RTP Found existing session 2 2006/06/02 13:12:37.820 0:15.580 Media Patch:8175708 RTP Transmit statistics: packets=101 octets=16160 avgTime=25 maxTime=48 minTime=23 2006/06/02 13:12:38.624 0:16.384 Housekeeper RTP Found existing session 1 2006/06/02 13:12:38.625 0:16.385 Housekeeper RTP Found existing session 2 2006/06/02 13:12:38.993 0:16.753 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (29120) 2006/06/02 13:12:39.374 0:17.134 RTP Jitter:8526b30 RTP Receive statistics: packets=301 octets=35714 lost=0 tooLate=0 order=0 avgTime=20 maxTime=26 minTime=14 jitter=1 maxJitter=188 2006/06/02 13:12:39.395 0:17.155 RTP Jitter:8526b30 RTP Jitter buffer continuously full, throwing away entire buffer. 2006/06/02 13:12:39.415 0:17.176 RTP Jitter:8526b30 RTP Jitter buffer full, threw away 21 oldest frames 2006/06/02 13:12:39.632 0:17.392 Housekeeper RTP Found existing session 1 2006/06/02 13:12:39.633 0:17.393 Housekeeper RTP Found existing session 2 2006/06/02 13:12:40.384 0:18.144 Media Patch:8175708 RTP Transmit statistics: packets=201 octets=32160 avgTime=25 maxTime=44 minTime=22 2006/06/02 13:12:40.640 0:18.400 Housekeeper RTP Found existing session 1 2006/06/02 13:12:40.641 0:18.401 Housekeeper RTP Found existing session 2 2006/06/02 13:12:41.373 0:19.133 RTP Jitter:8526b30 RTP Receive statistics: packets=401 octets=51714 lost=0 tooLate=0 order=0 avgTime=19 maxTime=26 minTime=13 jitter=1 maxJitter=188 2006/06/02 13:12:41.413 0:19.173 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (48480) 2006/06/02 13:12:41.648 0:19.424 Housekeeper RTP Found existing session 1 2006/06/02 13:12:41.665 0:19.425 Housekeeper RTP Found existing session 2 2006/06/02 13:12:41.813 0:19.573 RTP Jitter:8526b30 RTP Jitter buffer continuously full, throwing away entire buffer. 2006/06/02 13:12:41.833 0:19.593 RTP Jitter:8526b30 RTP Jitter buffer full, threw away 21 oldest frames 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP Found existing session 1 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP Found existing session 2 2006/06/02 13:12:42.920 0:20.680 Media Patch:8175708 RTP Transmit statistics: packets=301 octets=48160 avgTime=25 maxTime=49 minTime=22 2006/06/02 13:12:43.378 0:21.139 RTP Jitter:8526b30 RTP Receive statistics: packets=501 octets=67714 lost=0 tooLate=0 order=0 avgTime=20 maxTime=27 minTime=12 jitter=1 maxJitter=188 2006/06/02 13:12:43.696 0:21.457 Housekeeper RTP Found existing session 1 2006/06/02 13:12:43.697 0:21.457 Housekeeper RTP Found existing session 2 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot Call Clearing Call[1] reason=EndedByLocalUser 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot OpalCon Releasing Call[1]-EP[Default] 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon Call end reason for Default set to EndedByLocalUser 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon SetPhase from EstablishedPhase to ReleasingPhase 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon Releasing Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon Call end reason for fa44075b-96f0-da11-8388-000ea6217592@nomade set to EndedByLocalUser 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon SetPhase from EstablishedPhase to ReleasingPhase 2006/06/02 13:12:43.820 0:21.581 OnRelease:856e8a0 OpalCon OnReleased Call[1]-EP[Default] 2006/06/02 13:12:43.822 0:21.583 OnRelease:856e8a0 Media Closing raw media stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.824 0:21.584 OnRelease:856e8a0 Media Closing stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.825 0:21.585 OnRelease:856e8a0 Media Disconnecting OpalAudioMediaStream-Source-PCM-16 from patch thread Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.827 0:21.587 OnRelease:856e8a0 Patch Closing media patch Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.829 0:21.589 OnRelease:856e8a0 Media Closing raw media stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.830 0:21.590 OnRelease:856e8a0 Media Closing stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.831 0:21.591 OnRelease:84f8c00 SIP OnReleased: Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade], phase = ReleasingPhase 2006/06/02 13:12:43.833 0:21.593 OnRelease:84f8c00 OpalCon SetPhase from ReleasingPhase to ReleasingPhase 2006/06/02 13:12:43.834 0:21.594 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (67840) 2006/06/02 13:12:43.836 0:21.596 OnRelease:84f8c00 SIP Transaction 4 BYE created. 2006/06/02 13:12:43.842 0:21.603 OnRelease:84f8c00 Media Closing RTP for OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.844 0:21.604 OnRelease:84f8c00 RTP_UDP Session 1, Shutting down write. 2006/06/02 13:12:43.845 0:21.605 OnRelease:84f8c00 Media Closing stream OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.846 0:21.606 OnRelease:84f8c00 Media Disconnecting OpalRTPMediaStream-Sink-G.711-uLaw-64k from patch thread Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.848 0:21.609 OnRelease:84f8c00 Patch Removing media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.855 0:21.626 OnRelease:84f8c00 Media Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.867 0:21.627 OnRelease:84f8c00 RTP_UDP Session 1, Shutting down read. 2006/06/02 13:12:43.868 0:21.628 OnRelease:84f8c00 Media Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.869 0:21.630 OnRelease:84f8c00 Media Disconnecting OpalRTPMediaStream-Source-G.711-uLaw-64k from patch thread Patch OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.893 0:21.653 Media Patch:8175708 Patch Thread ended for Patch OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.893 0:21.653 OnRelease:84f8c00 Patch Closing media patch Patch OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.916 0:21.676 RTP Jitter:8526b30 RTP_UDP Session 1, Read shutdown. 2006/06/02 13:12:43.917 0:21.677 RTP Jitter:8526b30 RTP Jitter RTP receive thread ended 2006/06/02 13:12:43.917 0:21.677 OnRelease:84f8c00 Media Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.918 0:21.678 OnRelease:84f8c00 RTP_UDP Session 1, Shutting down read. 2006/06/02 13:12:43.919 0:21.679 OnRelease:84f8c00 Media Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.922 0:21.683 OnRelease:856e8a0 Patch Waiting for media patch thread to stop Patch OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.926 0:21.686 OnRelease:856e8a0 Patch Media patch thread Patch OpalAudioMediaStream-Source-PCM-16 destroyed. 2006/06/02 13:12:43.930 0:21.691 OnRelease:856e8a0 Media Closing raw media stream OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:43.932 0:21.693 OnRelease:856e8a0 Media Closing stream OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:43.933 0:21.694 OnRelease:856e8a0 Media Disconnecting OpalAudioMediaStream-Sink-PCM-16 from patch thread Patch OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.956 0:21.717 OnRelease:856e8a0 Patch Removing media stream sink OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP Found existing session 1 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP Found existing session 2 2006/06/02 13:12:45.696 0:23.456 Housekeeper RTP Found existing session 1 2006/06/02 13:12:45.697 0:23.457 Housekeeper RTP Found existing session 2 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP Found existing session 1 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP Found existing session 2 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP Found existing session 1 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP Found existing session 2 2006/06/02 13:12:48.708 0:26.468 Housekeeper RTP Found existing session 1 2006/06/02 13:12:48.709 0:26.469 Housekeeper RTP Found existing session 2 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP Found existing session 1 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP Found existing session 2 2006/06/02 13:12:50.712 0:28.473 Housekeeper RTP Found existing session 1 2006/06/02 13:12:50.713 0:28.473 Housekeeper RTP Found existing session 2 2006/06/02 13:12:51.716 0:29.477 Housekeeper RTP Found existing session 1 2006/06/02 13:12:51.717 0:29.477 Housekeeper RTP Found existing session 2 2006/06/02 13:12:52.716 0:30.477 Housekeeper RTP Found existing session 1 2006/06/02 13:12:52.717 0:30.477 Housekeeper RTP Found existing session 2 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP Found existing session 1 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP Found existing session 2 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP Found existing session 1 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP Found existing session 2 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP Found existing session 1 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP Found existing session 2 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP Found existing session 1 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP Found existing session 2 2006/06/02 13:12:57.733 0:35.493 Housekeeper RTP Found existing session 1 2006/06/02 13:12:57.734 0:35.494 Housekeeper RTP Found existing session 2 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP Found existing session 1 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP Found existing session 2 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP Found existing session 1 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP Found existing session 2 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP Found existing session 1 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP Found existing session 2 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP Found existing session 1 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP Found existing session 2 2006/06/02 13:13:02.777 0:40.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:02.778 0:40.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP Found existing session 2 2006/06/02 13:13:04.369 0:42.129 Housekeeper SIP Set state Terminated_Success for transaction 1 INVITE 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP Found existing session 2 2006/06/02 13:13:05.777 0:43.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:05.777 0:43.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:06.613 0:44.374 Housekeeper SIP Set state Terminated_Success for transaction 2 INVITE 2006/06/02 13:13:06.777 0:44.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:06.778 0:44.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:07.777 0:45.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:07.778 0:45.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP Found existing session 2 Processus arrêté -- Daniel From dsandras@seconix.com Sat Jun 3 13:58:00 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 184373B06A7 for ; Sat, 3 Jun 2006 13:58:00 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20355-03 for ; Sat, 3 Jun 2006 13:57:57 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 19BB03B036E for ; Sat, 3 Jun 2006 13:57:56 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id BC1A4493FD; Sat, 3 Jun 2006 19:41:15 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13551-03; Sat, 3 Jun 2006 19:41:05 +0200 (CEST) Received: from d51A5F203.access.telenet.be (d51A5F203.access.telenet.be [81.165.242.3]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id BC664493EE; Sat, 3 Jun 2006 19:41:05 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <20060603095331.79CD.CRAIGS@postincrement.com> References: <1149242124.4509.17.camel@siti> <20060603095331.79CD.CRAIGS@postincrement.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Sat, 03 Jun 2006 19:57:45 +0200 Message-Id: <1149357465.2414.30.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: Cc: Derek Smithies X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 17:58:00 -0000 Le samedi 03 juin 2006 à 09:55 +1000, Craig Southeren a écrit : > On Fri, 02 Jun 2006 21:55:24 +1200 > Stephen Cook wrote: > > > Hi, > > > > I haven't introduced myself here before, I am Stephen Cook (siti). My > > proposal for implementing IAX2 in ekiga got accepted with google's > > summer of code. > > > > To give an update (I'll try and keep you guys regularly posted as to > > what's happening, any problems etc.). > > > > Currently I have been looking at the code to gain an understanding of > > ekiga and opal's code and design. Also obviously checking out the IAX2 > > code in opal :). From what I have seen and got working, I will work on > > getting IAX2 going in ekiga first. The main part of this will obviously > > involve writing a gnome meeting endpoint for IAX2. > > > > One key problem I have identified is the accounts code. The protocols > > are tightly integrated with how it works. I could either refactor this > > code to loosen the integration or hack iax2 support in there and > > refactor it later ;). The advantage of this refactored will be when > > someone wants to add Xmpp/libjingle support, or some other protocol down > > the track. > > > > Well, please tell me your thoughts and comments on this project. > > As a New Zealander, you are uniquely placed to communicate with the > author of the OPAL IAX2 code, Derek Smithies, who is a fellow Kiwi! I am > sure that you will be able to get the OPAL IAX2 code working with Ekiga > in no time at all with his help. > > If you have any questions, please contact me directly. > Craig, I do not think moving to an offline conversation with Stephen is a good idea. Julien and myself are supposed to mentor the project. Your help is of course welcome, but we have to be kept informed. Notice also that the project is not only about making IAX2 work with Ekiga. -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Sat Jun 3 14:01:08 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 59C003B01BB for ; Sat, 3 Jun 2006 14:01:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20343-10 for ; Sat, 3 Jun 2006 14:01:02 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id BA0863B04B1 for ; Sat, 3 Jun 2006 14:01:01 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 1184A496A8 for ; Sat, 3 Jun 2006 19:44:21 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13551-04 for ; Sat, 3 Jun 2006 19:44:12 +0200 (CEST) Received: from d51A5F203.access.telenet.be (d51A5F203.access.telenet.be [81.165.242.3]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 993CE49685 for ; Sat, 3 Jun 2006 19:44:07 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <4481A6AF.2060703@tootai.net> References: <4481A6AF.2060703@tootai.net> Content-Type: text/plain; charset=ISO-8859-15 Date: Sat, 03 Jun 2006 20:00:48 +0200 Message-Id: <1149357648.2414.34.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 18:01:08 -0000 Hi, Le samedi 03 juin 2006 à 17:11 +0200, Daniel Huhardeaux a écrit : > Resent as it didn't pass at the first try (too big, I cut the begining > of logs) > > Hi all, > > Ekiga behind a firewall is registering to an asterisk server which is on > internet. The sip user is authorized with gsm,ulaw,alaw on asterisk side. > > When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is > started, connection is showed with PCMU (why not GSM?), see the traffic > in/out (~6 kB) but have no audio. > Asterisk answers with 200 OK indicating that the call should be done with PCMU. > I hangup the call, the hangup info is shown in the toolbar, PCMU > disappear in codec and immediately after, traffic in/out continue with > 0/0, icon in KDE Toolbar show Ekiga on line. The only solution I have is > to kill Ekiga. > Please try with 2.0.2. Craig has done work in CVS and things are potentially broken. If the problem persists once plugins support is in CVS, please report again. > If I deactivate GSM codec, everything is fine. Below you will find a d4 > output from the call. > I do not think activating GSM or not has any influence. The problem is probably something else. > > [...] > 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 OpalUDP > Ended connect, selecting 82.231.69.24:35065 > 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP > Queueing PDU: 1 INVITE <407> > 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP > Waiting for PDU on udp$213.203.241.243:5060 > 2006/06/02 13:12:32.901 0:10.661 SIP Handler:8520268 SIP PDU > handler thread started. > 2006/06/02 13:12:32.902 0:10.662 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:32.902 0:10.663 SIP Handler:8520268 SIP > Handling PDU 1 INVITE <407> (with transaction) > 2006/06/02 13:12:32.903 0:10.663 SIP Handler:8520268 SIP > Transaction 1 INVITE completed. > 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP > Sending PDU on udp$213.203.241.243:5060 > ACK sip:800@sip.tootai.net SIP/2.0 > CSeq: 1 ACK > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bK803b125b-96f0-da11-8388-000ea6217592;rport > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: ;tag=as315809c6 > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE > Content-Length: 0 > Max-Forwards: 70 > > > 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP > Received Proxy Authentication Required response > 2006/06/02 13:12:32.906 0:10.666 SIP Handler:8520268 SIP > Transaction 2 INVITE created. > 2006/06/02 13:12:32.906 0:10.667 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:33.090 0:10.850 SIP Handler:8520268 RTP_UDP > Session 1 created: 82.231.69.24:35010-35011 ssrc=703395120 > 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 RTP > Adding session RTP_UDP > 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 SIP > Using RTP payload [pt=101] for NTE > 2006/06/02 13:12:33.100 0:10.860 SIP Handler:8520268 Call > GetMediaFormats for > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > GSM-06.10 > G.711-uLaw-64k > G.711-ALaw-64k > H.261(QCIF) > H.261(CIF) > YUV420P > RGB32 > RGB24 > > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 2 > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 2 > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 2 > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:33.281 0:11.041 SIP Handler:8520268 RTP_UDP > Session 2 created: 82.231.69.24:35014-35015 ssrc=2454563097 > 2006/06/02 13:12:33.282 0:11.042 SIP Handler:8520268 RTP > Adding session RTP_UDP > 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 Call > GetMediaFormats for > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > GSM-06.10 > G.711-uLaw-64k > G.711-ALaw-64k > H.261(QCIF) > H.261(CIF) > YUV420P > RGB32 > RGB24 > > 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 SIP > Adding authentication information > 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP > Sending PDU on udp$213.203.241.243:5060 > INVITE sip:800@sip.tootai.net SIP/2.0 > Date: Fri, 02 Jun 2006 11:12:32 GMT > CSeq: 2 INVITE > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;rport > User-Agent: Ekiga/2.0.1-20060521-01 > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: > Contact: > Proxy-Authorization: Digest username="104", realm="sip.tootai.net", > nonce="12d01d5d", uri="sip:800@sip.tootai.net", > response="60b65ec9045130eab45495d3c65fbc5e", algorithm=md5 > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE > Content-Type: application/sdp > Content-Length: 302 > Max-Forwards: 70 > > v=0 > o=- 1149246753 1149246753 IN IP4 82.231.69.24 > s=Opal SIP Session > c=IN IP4 82.231.69.24 > t=0 0 > m=audio 35010 RTP/AVP 101 3 0 8 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=rtpmap:3 GSM/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > m=video 35014 RTP/AVP 31 > a=rtpmap:31 H261/90000 > > 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP PDU > Received on udp$213.203.241.243:5060 > SIP/2.0 100 Trying > CSeq: 2 INVITE > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 > User-Agent: Asterisk PBX > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: > Contact: > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > Content-Length: 0 > > > 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP > Queueing PDU: 2 INVITE <100> > 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP > Waiting for PDU on udp$213.203.241.243:5060 > 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP > Handling PDU 2 INVITE <100> (with transaction) > 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP > Transaction 2 INVITE proceeding. > 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Set > targetAddress to sip:800@213.203.241.243 > 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP > Received Trying response > 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP > Media session port=7166 > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP > Adding media session with 2 formats > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP > Unknown media attribute silenceSupp:off - - - - > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SIP PDU > Received on udp$213.203.241.243:5060 > SIP/2.0 200 OK > CSeq: 2 INVITE > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 > User-Agent: Asterisk PBX > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: ;tag=as5d2831d1 > Contact: > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > Content-Type: application/sdp > Content-Length: 221 > > v=0 > o=root 26912 26912 IN IP4 213.203.241.243 > s=session > c=IN IP4 213.203.241.243 > t=0 0 > m=audio 7166 RTP/AVP 0 101 > a=rtpmap:0 PCMU/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=silenceSupp:off - - - - > > 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP > Queueing PDU: 2 INVITE <200> > 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP > Waiting for PDU on udp$213.203.241.243:5060 > 2006/06/02 13:12:33.388 0:11.148 SIP Handler:8520268 SIP > Handling PDU 2 INVITE <200> (with transaction) > 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP > Transaction 2 INVITE completed. > 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP Set > targetAddress to sip:800@213.203.241.243 > 2006/06/02 13:12:33.390 0:11.150 SIP Handler:8520268 SIP > Adding authentication information > 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP > Adjusting transport to address udp$213.203.241.243:5060 > 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP > Sending PDU on udp$213.203.241.243:5060 > ACK sip:800@213.203.241.243 SIP/2.0 > CSeq: 2 ACK > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bK6e2ca15b-96f0-da11-8388-000ea6217592;rport > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: ;tag=as5d2831d1 > Contact: > Proxy-Authorization: Digest username="104", realm="sip.tootai.net", > nonce="12d01d5d", uri="sip:800@213.203.241.243", > response="059defd67706254552a5c23eada565b5", algorithm=md5 > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE > Content-Length: 0 > Max-Forwards: 70 > > > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP > Received INVITE OK response > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 SIP RTP > payload type PCMU matched to codec G.711-uLaw-64k > 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k > 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 OpalCon > OpenSourceMediaStream for session 1 on Call[1]-EP[Default] > 2006/06/02 13:12:33.398 0:11.158 SIP Handler:8520268 OpalCon > Selected media stream PCM-16 -> G.711-uLaw-64k > 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 OpalMan > OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 Call > PatchMediaStreams Call[1]-EP[Default] > 2006/06/02 13:12:34.196 0:11.957 SIP Handler:8520268 OpalCon > OpenSinkMediaStream > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session=1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon > OpenSinkMediaStream, selected PCM-16 -> G.711-uLaw-64k > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:34.197 0:11.958 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 OpalMan > OnOpenMediaStream > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Patch > Added sink > from PCM-16 > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 16 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > to G.711-uLaw-64k > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 8 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > > 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Codec > G711-uLaw-64k encoder created > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Patch > Added media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k using > transcoder PCM-16->G.711-uLaw-64k > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Media > Audio source data size set to 320 bytes and 2 buffers. > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call > GetOtherPartyConnection > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon > OpenSourceMediaStream for session 1 on > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon > Selected media stream G.711-uLaw-64k -> PCM-16 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalMan > OnOpenMediaStream > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 Call > PatchMediaStreams > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon > OpenSinkMediaStream Call[1]-EP[Default] session=1 > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon > OpenSinkMediaStream, selected G.711-uLaw-64k -> PCM-16 > 2006/06/02 13:12:34.513 0:12.274 SIP Handler:8520268 OpalMan > OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:34.514 0:12.274 SIP Handler:8520268 Patch > Added sink > from G.711-uLaw-64k > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 8 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > to PCM-16 > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 16 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Codec > G711-uLaw-64k decoder created > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Media > Audio sink data size set to 320 bytes and 2 buffers. > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Patch > Added media stream sink OpalAudioMediaStream-Sink-PCM-16 using > transcoder G.711-uLaw-64k->PCM-16 > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.525 0:12.285 SIP Handler:8520268 OpalCon > OpenSourceMediaStream (already opened) for session 1 on > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.527 0:12.287 SIP Handler:8520268 RTP_UDP > SetRemoteSocketInfo: session=1 data channel, new=213.203.241.243:7166, > local=82.231.69.24:35010-35011, remote=0.0.0.0:0-0 > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 SIP > Could not find SDP media description for Video > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 OpalMan > OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 Call > OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 PCSS > SetConnected() > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 > GMPCSSEndpoint PCSS connection established > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 > GMManager Will establish the connection > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 OpalMan > OnEstablished Call[1]-EP[Default] > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 Call > OnEstablished Call[1]-EP[Default] > 2006/06/02 13:12:34.540 0:12.300 SIP Handler:8520268 Call > GetMediaFormats for Call[1]-EP[Default] > G.711-uLaw-64k > > 2006/06/02 13:12:34.541 0:12.301 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k > 2006/06/02 13:12:34.542 0:12.302 SIP Handler:8520268 OpalCon > OpenSourceMediaStream (already opened) for session 1 on > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.543 0:12.303 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call > GetMediaFormats for > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > G.711-uLaw-64k > > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 OpalCon > OpenSourceMediaStream (already opened) for session 1 on > Call[1]-EP[Default] > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k > 2006/06/02 13:12:34.552 0:12.312 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k > 2006/06/02 13:12:34.553 0:12.313 Media Patch:8175708 Patch > Thread started for Patch OpalAudioMediaStream-Source-PCM-16 -> > OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:34.556 0:12.316 SIP Handler:8520268 Media > Starting thread Media Patch:8175708 > 2006/06/02 13:12:34.557 0:12.317 Media Patch:8527348 Patch > Thread started for Patch OpalRTPMediaStream-Source-G.711-uLaw-64k -> > OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:34.568 0:12.329 Media Patch:8527348 RTP > Jitter buffer created: size=101 delay=160-4000/160 (20ms) obj=0x8526b30 > 2006/06/02 13:12:34.572 0:12.333 RTP Jitter:8526b30 RTP > Jitter RTP receive thread started: 0x8526b30 > 2006/06/02 13:12:34.574 0:12.334 RTP Jitter:8526b30 RTP > First receive data: ver=2 pt=GSM psz=33 m=0 x=0 seq=39915 ts=160 > src=824302623 ccnt=0 > 2006/06/02 13:12:34.580 0:12.341 SIP Handler:8520268 Media > Starting thread Media Patch:8527348 > 2006/06/02 13:12:34.581 0:12.341 SIP Handler:8520268 OpalCon > Media stream threads started. > 2006/06/02 13:12:34.582 0:12.342 SIP Handler:8520268 OpalCon > Media stream threads started. > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP > Found existing session 2 > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 > GMManager Will establish the connection > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 OpalMan > OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.607 0:12.367 SIP Handler:8520268 Call > OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.610 0:12.371 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:34.648 0:12.408 Media Patch:8527348 RTP > Jitter buffer length exceeded > 2006/06/02 13:12:34.649 0:12.409 Media Patch:8527348 RTP > Jitter buffer length exceed was prior to first write. Not increasing > buffer size > 2006/06/02 13:12:35.277 0:13.037 Media Patch:8175708 RTP > First sent data: ver=2 pt=PCMU psz=160 m=1 x=0 seq=1460 ts=0 > src=703395120 ccnt=0 > 2006/06/02 13:12:35.608 0:13.368 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:35.609 0:13.369 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:36.137 0:13.898 RTP Jitter:8526b30 RTP > Receive statistics: packets=101 octets=3714 lost=0 tooLate=0 order=0 > avgTime=15 maxTime=1556 minTime=0 jitter=16 maxJitter=188 > 2006/06/02 13:12:36.573 0:14.333 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (9760) > 2006/06/02 13:12:36.614 0:14.374 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:36.615 0:14.375 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:36.974 0:14.734 RTP Jitter:8526b30 RTP > Jitter buffer continuously full, throwing away entire buffer. > 2006/06/02 13:12:36.995 0:14.756 RTP Jitter:8526b30 RTP > Jitter buffer full, threw away 21 oldest frames > 2006/06/02 13:12:37.374 0:15.134 RTP Jitter:8526b30 RTP > Receive statistics: packets=201 octets=19714 lost=0 tooLate=0 order=0 > avgTime=12 maxTime=23 minTime=0 jitter=0 maxJitter=188 > 2006/06/02 13:12:37.620 0:15.380 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:37.621 0:15.381 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:37.820 0:15.580 Media Patch:8175708 RTP > Transmit statistics: packets=101 octets=16160 avgTime=25 maxTime=48 > minTime=23 > 2006/06/02 13:12:38.624 0:16.384 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:38.625 0:16.385 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:38.993 0:16.753 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (29120) > 2006/06/02 13:12:39.374 0:17.134 RTP Jitter:8526b30 RTP > Receive statistics: packets=301 octets=35714 lost=0 tooLate=0 order=0 > avgTime=20 maxTime=26 minTime=14 jitter=1 maxJitter=188 > 2006/06/02 13:12:39.395 0:17.155 RTP Jitter:8526b30 RTP > Jitter buffer continuously full, throwing away entire buffer. > 2006/06/02 13:12:39.415 0:17.176 RTP Jitter:8526b30 RTP > Jitter buffer full, threw away 21 oldest frames > 2006/06/02 13:12:39.632 0:17.392 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:39.633 0:17.393 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:40.384 0:18.144 Media Patch:8175708 RTP > Transmit statistics: packets=201 octets=32160 avgTime=25 maxTime=44 > minTime=22 > 2006/06/02 13:12:40.640 0:18.400 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:40.641 0:18.401 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:41.373 0:19.133 RTP Jitter:8526b30 RTP > Receive statistics: packets=401 octets=51714 lost=0 tooLate=0 order=0 > avgTime=19 maxTime=26 minTime=13 jitter=1 maxJitter=188 > 2006/06/02 13:12:41.413 0:19.173 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (48480) > 2006/06/02 13:12:41.648 0:19.424 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:41.665 0:19.425 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:41.813 0:19.573 RTP Jitter:8526b30 RTP > Jitter buffer continuously full, throwing away entire buffer. > 2006/06/02 13:12:41.833 0:19.593 RTP Jitter:8526b30 RTP > Jitter buffer full, threw away 21 oldest frames > 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:42.920 0:20.680 Media Patch:8175708 RTP > Transmit statistics: packets=301 octets=48160 avgTime=25 maxTime=49 > minTime=22 > 2006/06/02 13:12:43.378 0:21.139 RTP Jitter:8526b30 RTP > Receive statistics: packets=501 octets=67714 lost=0 tooLate=0 order=0 > avgTime=20 maxTime=27 minTime=12 jitter=1 maxJitter=188 > 2006/06/02 13:12:43.696 0:21.457 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:43.697 0:21.457 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot Call > Clearing Call[1] reason=EndedByLocalUser > 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot OpalCon > Releasing Call[1]-EP[Default] > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > Call end reason for Default set to EndedByLocalUser > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > SetPhase from EstablishedPhase to ReleasingPhase > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > Releasing Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > Call end reason for fa44075b-96f0-da11-8388-000ea6217592@nomade set to > EndedByLocalUser > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > SetPhase from EstablishedPhase to ReleasingPhase > 2006/06/02 13:12:43.820 0:21.581 OnRelease:856e8a0 OpalCon > OnReleased Call[1]-EP[Default] > 2006/06/02 13:12:43.822 0:21.583 OnRelease:856e8a0 Media > Closing raw media stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.824 0:21.584 OnRelease:856e8a0 Media > Closing stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.825 0:21.585 OnRelease:856e8a0 Media > Disconnecting OpalAudioMediaStream-Source-PCM-16 from patch thread Patch > OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.827 0:21.587 OnRelease:856e8a0 Patch > Closing media patch Patch OpalAudioMediaStream-Source-PCM-16 -> > OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.829 0:21.589 OnRelease:856e8a0 Media > Closing raw media stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.830 0:21.590 OnRelease:856e8a0 Media > Closing stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.831 0:21.591 OnRelease:84f8c00 SIP > OnReleased: > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade], phase = > ReleasingPhase > 2006/06/02 13:12:43.833 0:21.593 OnRelease:84f8c00 OpalCon > SetPhase from ReleasingPhase to ReleasingPhase > 2006/06/02 13:12:43.834 0:21.594 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (67840) > 2006/06/02 13:12:43.836 0:21.596 OnRelease:84f8c00 SIP > Transaction 4 BYE created. > 2006/06/02 13:12:43.842 0:21.603 OnRelease:84f8c00 Media > Closing RTP for OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.844 0:21.604 OnRelease:84f8c00 RTP_UDP > Session 1, Shutting down write. > 2006/06/02 13:12:43.845 0:21.605 OnRelease:84f8c00 Media > Closing stream OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.846 0:21.606 OnRelease:84f8c00 Media > Disconnecting OpalRTPMediaStream-Sink-G.711-uLaw-64k from patch thread > Patch OpalAudioMediaStream-Source-PCM-16 -> > OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.848 0:21.609 OnRelease:84f8c00 Patch > Removing media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.855 0:21.626 OnRelease:84f8c00 Media > Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.867 0:21.627 OnRelease:84f8c00 RTP_UDP > Session 1, Shutting down read. > 2006/06/02 13:12:43.868 0:21.628 OnRelease:84f8c00 Media > Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.869 0:21.630 OnRelease:84f8c00 Media > Disconnecting OpalRTPMediaStream-Source-G.711-uLaw-64k from patch thread > Patch OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.893 0:21.653 Media Patch:8175708 Patch > Thread ended for Patch OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.893 0:21.653 OnRelease:84f8c00 Patch > Closing media patch Patch OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.916 0:21.676 RTP Jitter:8526b30 RTP_UDP > Session 1, Read shutdown. > 2006/06/02 13:12:43.917 0:21.677 RTP Jitter:8526b30 RTP > Jitter RTP receive thread ended > 2006/06/02 13:12:43.917 0:21.677 OnRelease:84f8c00 Media > Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.918 0:21.678 OnRelease:84f8c00 RTP_UDP > Session 1, Shutting down read. > 2006/06/02 13:12:43.919 0:21.679 OnRelease:84f8c00 Media > Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.922 0:21.683 OnRelease:856e8a0 Patch > Waiting for media patch thread to stop Patch > OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.926 0:21.686 OnRelease:856e8a0 Patch > Media patch thread Patch OpalAudioMediaStream-Source-PCM-16 destroyed. > 2006/06/02 13:12:43.930 0:21.691 OnRelease:856e8a0 Media > Closing raw media stream OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:43.932 0:21.693 OnRelease:856e8a0 Media > Closing stream OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:43.933 0:21.694 OnRelease:856e8a0 Media > Disconnecting OpalAudioMediaStream-Sink-PCM-16 from patch thread Patch > OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.956 0:21.717 OnRelease:856e8a0 Patch > Removing media stream sink OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:45.696 0:23.456 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:45.697 0:23.457 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:48.708 0:26.468 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:48.709 0:26.469 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:50.712 0:28.473 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:50.713 0:28.473 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:51.716 0:29.477 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:51.717 0:29.477 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:52.716 0:30.477 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:52.717 0:30.477 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:57.733 0:35.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:57.734 0:35.494 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:02.777 0:40.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:02.778 0:40.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:04.369 0:42.129 Housekeeper SIP Set > state Terminated_Success for transaction 1 INVITE > 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:05.777 0:43.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:05.777 0:43.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:06.613 0:44.374 Housekeeper SIP Set > state Terminated_Success for transaction 2 INVITE > 2006/06/02 13:13:06.777 0:44.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:06.778 0:44.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:07.777 0:45.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:07.778 0:45.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP > Found existing session 2 > Processus arrêté > -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From devel@tootai.net Sat Jun 3 19:25:05 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EBBDB3B06DD for ; Sat, 3 Jun 2006 19:24:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02787-06 for ; Sat, 3 Jun 2006 19:24:40 -0400 (EDT) Received: from mail1.tootai.net (ns1.tootai.net [82.231.69.24]) by menubar.gnome.org (Postfix) with ESMTP id 16D123B0756 for ; Sat, 3 Jun 2006 19:24:35 -0400 (EDT) Received: from [192.168.0.17] (unknown [192.168.0.17]) by mail1.tootai.net (Postfix) with ESMTP id 9C142398B99 for ; Sun, 4 Jun 2006 01:24:35 +0200 (CEST) Message-ID: <44821A19.10001@tootai.net> Date: Sun, 04 Jun 2006 01:24:09 +0200 From: Daniel Huhardeaux Organization: TOOTAi User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 References: <4481A6AF.2060703@tootai.net> <1149357648.2414.34.camel@golgoth01> In-Reply-To: <1149357648.2414.34.camel@golgoth01> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[AWL=0.000, BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 23:25:05 -0000 Damien Sandras wrote: > [...] >> When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is >> started, connection is showed with PCMU (why not GSM?), see the traffic >> in/out (~6 kB) but have no audio. >> >> > > Asterisk answers with 200 OK indicating that the call should be done > with PCMU. > Ok, but as GSM has my preference in Ekiga as well as in asterisk, the call should be done in GSM > [...] > > Please try with 2.0.2. Craig has done work in CVS and things are > potentially broken. If the problem persists once plugins support is in > CVS, please report again. > I use the Ekiga snapshot SID version which don't provide newest version as the one mentioned :-( Kilian? BTW, asterisk is 1.2-r16008 from 29/03/2006 - SVN stable. > > >> If I deactivate GSM codec, everything is fine. Below you will find a d4 >> output from the call. >> >> > > I do not think activating GSM or not has any influence. The problem is > probably something else. > I would like to believe you, but this problem happends only with GSM codec. -- Daniel From ebischoff@nerim.net Sun Jun 4 11:52:03 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C970B3B011B for ; Sun, 4 Jun 2006 11:52:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26992-10 for ; Sun, 4 Jun 2006 11:52:01 -0400 (EDT) Received: from mallaury.nerim.net (smtp-100-sunday.noc.nerim.net [62.4.17.100]) by menubar.gnome.org (Postfix) with ESMTP id 9601A3B00CE for ; Sun, 4 Jun 2006 11:52:01 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by mallaury.nerim.net (Postfix) with ESMTP id 32E474F399 for ; Sun, 4 Jun 2006 17:51:50 +0200 (CEST) From: =?iso-8859-1?q?=C9ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Sun, 4 Jun 2006 17:52:11 +0200 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606041752.12228.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.535 tagged_above=-999 required=2 tests=[AWL=0.064, BAYES_00=-2.599] X-Spam-Score: -2.535 X-Spam-Level: Subject: [GnomeMeeting-devel-list] KDE address book support in Ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 15:52:04 -0000 (this message has already been sent by mistake on gnomemeeting-list a few=20 hours ago, sorry for the crossposting) Hi everyone, A small notice to let you know that I am working on adding support for KDE= =20 Address Book (kab) to Ekiga. I already have some early "proof of concept"=20 code working (see screenshot at=20 http://opensource.bureau-cornavin.com/ekiga/screenshot.png). KDE Address Book is an application of its own, but it's also a library that= is=20 used by most KDE applications (KMail, Kontact, KPilot, Kopete, ...), and al= so=20 by third-party applications like OpenOffice.org. It can use several=20 "resources" for its addresses: local VCard files, remote LDAP servers, etc. Before anyone does the remark : YES it would be better if Evolution/GNOME a= nd=20 KDE shared the same address book library. But currently we have to live wit= h=20 this situation... There are two issues that currently slow me down a bit: 1) Ekiga's address book model distinguishes between "local" and "remote"=20 address books. This makes little sense for kab which can transparently use= =20 both local and remote resources. In a first time, my code will act as a=20 "local" address book, just like Evolution address book. 2) KDE address book currently has no field for SIP nor H323 addresses. I am= =20 currently trying to contact Will Stephenson (KDE) who added support for Sky= pe=20 addresses to see how we could do that cleanly. Of course, this functionality will remain optional and require no library f= or=20 those who can live without it :-). Any suggestion, wish, encouragement, criticism, and/or offer for help is=20 welcome. Hoping that helps, =2D-=20 =C9ric From jpuydt@free.fr Sun Jun 4 12:08:13 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C97F03B009F; Sun, 4 Jun 2006 12:08:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28175-05; Sun, 4 Jun 2006 12:08:00 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 880B03B0187; Sun, 4 Jun 2006 12:08:00 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-54-82-251-83-65.adsl.proxad.net [82.251.83.65]) by smtp5-g19.free.fr (Postfix) with ESMTP id 3EBD2250F8; Sun, 4 Jun 2006 18:07:59 +0200 (CEST) Message-ID: <44830581.8080503@free.fr> Date: Sun, 04 Jun 2006 18:08:33 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting mailing list , GnomeMeeting development mailing list References: <200606041116.31785.ebischoff@nerim.net> In-Reply-To: <200606041116.31785.ebischoff@nerim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: Cc: Subject: [GnomeMeeting-devel-list] Re: [GnomeMeeting-list] KDE address book support in Ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 16:08:14 -0000 Éric Bischoff a écrit : > A small notice to let you know that I am working on adding support for KDE > Address Book (kab) to Ekiga. I already have some early "proof of concept" > code working (see screenshot at > http://opensource.bureau-cornavin.com/ekiga/screenshot.png). I know :-) > KDE Address Book is an application of its own, but it's also a library that is > used by most KDE applications (KMail, Kontact, KPilot, Kopete, ...), and also > by third-party applications like OpenOffice.org. It can use several > "resources" for its addresses: local VCard files, remote LDAP servers, etc. Nice. > Before anyone does the remark : YES it would be better if Evolution/GNOME and > KDE shared the same address book library. But currently we have to live with > this situation... Indeed. > There are two issues that currently slow me down a bit: > > 1) Ekiga's address book model distinguishes between "local" and "remote" > address books. This makes little sense for kab which can transparently use > both local and remote resources. In a first time, my code will act as a > "local" address book, just like Evolution address book. I'm refactoring the addressbook ; and I don't like that distinction either. I'm still trying to convince Damien and Jan my ideas can fly. I think Jan is already beginning to see where I go ; Damien hasn't had the time to dive into it. > 2) KDE address book currently has no field for SIP nor H323 addresses. I am > currently trying to contact Will Stephenson (KDE) who added support for Skype > addresses to see how we could do that cleanly. Ok. > Of course, this functionality will remain optional and require no library for > those who can live without it :-). Ok too. We'll go with a --enable-kde at compile time. Then later on we'll see if it's possible to do something at runtime. > Any suggestion, wish, encouragement, criticism, and/or offer for help is > welcome. * Suggestion: use -devel-list ;-) * Wish: what you have written will work well with what I have in mind * Encouragement: I like the idea very much, and appreciate your working on ekiga * Criticism: couldn't you do that either long before or just after the re-architecturing? ;-) * Offer for help: uh... I'm refactoring, and it may help (the api I ask from "addressbooks" is much lighter). Snark on #ekiga From ebischoff@nerim.net Sun Jun 4 12:36:03 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6EBCD3B00E9 for ; Sun, 4 Jun 2006 12:36:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29967-09 for ; Sun, 4 Jun 2006 12:36:02 -0400 (EDT) Received: from kraid.nerim.net (smtp-100-sunday.nerim.net [62.4.16.100]) by menubar.gnome.org (Postfix) with ESMTP id 16E7B3B009F for ; Sun, 4 Jun 2006 12:36:01 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id C772E40E31 for ; Sun, 4 Jun 2006 18:35:59 +0200 (CEST) From: =?iso-8859-1?q?=C9ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Re: [GnomeMeeting-list] KDE address book support in Ekiga Date: Sun, 4 Jun 2006 18:36:11 +0200 User-Agent: KMail/1.8.2 References: <200606041116.31785.ebischoff@nerim.net> <44830581.8080503@free.fr> In-Reply-To: <44830581.8080503@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606041836.12390.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.553 tagged_above=-999 required=2 tests=[AWL=0.046, BAYES_00=-2.599] X-Spam-Score: -2.553 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 16:36:03 -0000 Le Dimanche 4 Juin 2006 18:08, Julien PUYDT a =E9crit=A0: > I know :-) I know you know ;-). > I'm refactoring the addressbook ; and I don't like that distinction > either. I'm still trying to convince Damien and Jan my ideas can fly. I > think Jan is already beginning to see where I go ; Damien hasn't had the > time to dive into it. Okay, I have not written much code yet, so there will be no problem to adap= t=20 it to your new layout, whatever it will be. > Ok too. We'll go with a --enable-kde at compile time. Then later on > we'll see if it's possible to do something at runtime. Yes, I was figuring out something like that. > * Suggestion: use -devel-list ;-) Yup, sorry... :-/ > * Wish: what you have written will work well with what I have in mind See above, I have not written much yet, and it's "obvious" code anyway, so= =20 there's no problem even if I have to restart from scratch. > * Encouragement: I like the idea very much, and appreciate your working > on ekiga Thank you for the warm welcome, Julien :-). > * Criticism: couldn't you do that either long before or just after the > re-architecturing? ;-) No. Did you hear about Murphy's law ? ;-) > * Offer for help: uh... I'm refactoring, and it may help (the api I ask > from "addressbooks" is much lighter). Indeed. =2D-=20 =C9ric From dsandras@seconix.com Mon Jun 5 15:24:19 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 115A33B038A for ; Mon, 5 Jun 2006 15:24:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24872-10 for ; Mon, 5 Jun 2006 15:24:15 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 482C73B0420 for ; Mon, 5 Jun 2006 15:24:15 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 73E6049870 for ; Mon, 5 Jun 2006 21:07:08 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23599-08 for ; Mon, 5 Jun 2006 21:06:52 +0200 (CEST) Received: from [192.168.0.161] (39.128-245-81.adsl-dyn.isp.belgacom.be [81.245.128.39]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 4C3C84986E for ; Mon, 5 Jun 2006 21:06:52 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44821A19.10001@tootai.net> References: <4481A6AF.2060703@tootai.net> <1149357648.2414.34.camel@golgoth01> <44821A19.10001@tootai.net> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 05 Jun 2006 21:24:50 +0200 Message-Id: <1149535490.2508.3.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.455 tagged_above=-999 required=2 tests=[AWL=0.009, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.455 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 19:24:19 -0000 Le dimanche 04 juin 2006 à 01:24 +0200, Daniel Huhardeaux a écrit : > Damien Sandras wrote: > > [...] > >> When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is > >> started, connection is showed with PCMU (why not GSM?), see the traffic > >> in/out (~6 kB) but have no audio. > >> > >> > > > > Asterisk answers with 200 OK indicating that the call should be done > > with PCMU. > > > Ok, but as GSM has my preference in Ekiga as well as in asterisk, the > call should be done in GSM I agree, but if you look at the 200 OK sent by Asterisk, GSM is not part of it, while it is part of the INVITE sent by Ekiga. > > I do not think activating GSM or not has any influence. The problem is > > probably something else. > > > I would like to believe you, but this problem happends only with GSM codec. Is there some way I could reproduce it here? -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Mon Jun 5 17:45:53 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 776D43B03A0; Mon, 5 Jun 2006 17:45:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02457-06; Mon, 5 Jun 2006 17:45:52 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 22F123B0295; Mon, 5 Jun 2006 17:45:52 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 8C0904984F; Mon, 5 Jun 2006 23:28:44 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29850-10; Mon, 5 Jun 2006 23:28:37 +0200 (CEST) Received: from [192.168.0.161] (39.128-245-81.adsl-dyn.isp.belgacom.be [81.245.128.39]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 089E44984C; Mon, 5 Jun 2006 23:28:36 +0200 (CEST) From: Damien Sandras To: gnomemeeting-list@gnome.org Content-Type: text/plain Date: Mon, 05 Jun 2006 23:46:32 +0200 Message-Id: <1149543992.2508.40.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.455 tagged_above=-999 required=2 tests=[AWL=0.009, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.455 X-Spam-Level: Cc: gnomemeeting-devel-list@gnome.org Subject: [GnomeMeeting-devel-list] Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 21:45:53 -0000 Hello to all, Ekiga 2.0.2 is available on http://www.ekiga.org More packages will be added as they are released. Thanks a lot to all supporters of the project! -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From simon@mungewell.org Mon Jun 5 18:20:27 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1BD3C3B0389 for ; Mon, 5 Jun 2006 18:20:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04790-06 for ; Mon, 5 Jun 2006 18:20:25 -0400 (EDT) Received: from pd3mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by menubar.gnome.org (Postfix) with ESMTP id 864BD3B04F7 for ; Mon, 5 Jun 2006 18:20:25 -0400 (EDT) Received: from pd3mr3so.prod.shaw.ca (pd3mr3so-qfe3.prod.shaw.ca [10.0.141.179]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0E00FK5RE0KD10@l-daemon> for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:20:24 -0600 (MDT) Received: from pn2ml4so.prod.shaw.ca ([10.0.121.148]) by pd3mr3so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0E002HJRE0FOB0@pd3mr3so.prod.shaw.ca> for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:20:24 -0600 (MDT) Received: from slone.mungewell.org ([68.146.98.7]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0E00GPGRE0XH60@l-daemon> for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:20:24 -0600 (MDT) Received: from simon by slone.mungewell.org with local (Exim 4.61) (envelope-from ) id 1FnNDw-0002Wd-6Y for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:07:00 -0600 Date: Mon, 05 Jun 2006 16:07:00 -0600 From: simon Subject: Re: [GnomeMeeting-devel-list] Ekiga 2.0.2 In-reply-to: <1149543992.2508.40.camel@golgoth01> To: GnomeMeeting development mailing list Message-id: <20060605220700.GA9699@mungewell.org> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline References: <1149543992.2508.40.camel@golgoth01> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[AWL=-0.000, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 22:20:27 -0000 On Mon, Jun 05, 2006 at 11:46:32PM +0200, Damien Sandras wrote: > Hello to all, > > > Ekiga 2.0.2 is available on http://www.ekiga.org > Woo Woo another release party! What only a '.' release - oh, guess we'll have to share a can of Pop ;-) Seriously though, Thanks to Damien and all the other developers. Simon From siti@orcon.net.nz Tue Jun 6 05:25:31 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5963D3B00EF for ; Tue, 6 Jun 2006 05:25:31 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29810-06 for ; Tue, 6 Jun 2006 05:25:29 -0400 (EDT) Received: from dbmail-mx2.orcon.net.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id AB0663B00E2 for ; Tue, 6 Jun 2006 05:25:28 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx2.orcon.net.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k569PFih007843 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Jun 2006 21:25:16 +1200 Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Stephen Cook To: Derek Smithies In-Reply-To: References: Content-Type: text/plain Date: Tue, 06 Jun 2006 21:25:24 +1200 Message-Id: <1149585924.16149.8.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx2.orcon.net.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.532 tagged_above=-999 required=2 tests=[AWL=0.068, BAYES_00=-2.599] X-Spam-Score: -2.532 X-Spam-Level: Cc: GnomeMeeting development mailing list X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 09:25:31 -0000 On Tue, 2006-06-06 at 10:32 +1200, Derek Smithies wrote: > Hi, > Ok, just back from a long weekend (three days of not touching a computer) > and back into things. > > Stephen, I saw some comment from you on this topic at: > > http://siti.geek.nz/web/content/blogsection/4/26/ > > interesting - very interesting.. > > hey - now that is a coincidence. > I studied at Canterbury University also. Well that's cool :) Could you send me a private email with an instant messaging address that you use. BTW Damien and others we will keep as much information on the mailing list. To give you guys an update I have IAX2 calls going in ekiga although it needs a lot of work :). Then obviously the improvements to IAX2 in opal... > > > ============== > > Craig, I do not think moving to an offline conversation with Stephen is > > a good idea. Julien and myself are supposed to mentor the project. Your > > help is of course welcome, but we have to be kept informed. > Sorry Damien, but there will be a lot of offline comment. > I suspect that Stephen and I live in the same city. Sending a CC of phone > conversations etc will not be easy. > > I will endeavour though to keep you informed of what is happening, and we > can move everything forward towards the nirvana of iax2, sip, and h323 in > gnomemeeting. > > > =========================== > > Stephen, > > I am really happy to work with you on IAX2 - really happy. This > would be great for the project. It should be a good learning experience for me and I am sure it'll be good fun :) From dsandras@seconix.com Tue Jun 6 05:29:32 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 40D9E3B0A68 for ; Tue, 6 Jun 2006 05:29:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30841-02 for ; Tue, 6 Jun 2006 05:29:30 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 9F34C3B0A5C for ; Tue, 6 Jun 2006 05:29:30 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id DDF8E493CB; Tue, 6 Jun 2006 11:12:16 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30209-02; Tue, 6 Jun 2006 11:11:57 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 679F9492DA; Tue, 6 Jun 2006 11:11:57 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: Stephen Cook In-Reply-To: <1149585924.16149.8.camel@siti> References: <1149585924.16149.8.camel@siti> Content-Type: text/plain; charset=ISO-8859-15 Date: Tue, 06 Jun 2006 11:29:17 +0200 Message-Id: <1149586157.2470.27.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Cc: Derek Smithies , GnomeMeeting development mailing list X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 09:29:32 -0000 Le mardi 06 juin 2006 à 21:25 +1200, Stephen Cook a écrit : > On Tue, 2006-06-06 at 10:32 +1200, Derek Smithies wrote: > > Hi, > > Ok, just back from a long weekend (three days of not touching a computer) > > and back into things. > > > > Stephen, I saw some comment from you on this topic at: > > > > http://siti.geek.nz/web/content/blogsection/4/26/ > > > > interesting - very interesting.. > > > > hey - now that is a coincidence. > > I studied at Canterbury University also. > Well that's cool :) > > Could you send me a private email with an instant messaging address that > you use. > > BTW Damien and others we will keep as much information on the mailing > list. > > To give you guys an update I have IAX2 calls going in ekiga although it > needs a lot of work :). Then obviously the improvements to IAX2 in > opal... > Excellent ;-) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From jpuydt@free.fr Tue Jun 6 06:41:15 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 18B6B3B00E0 for ; Tue, 6 Jun 2006 06:41:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10263-10 for ; Tue, 6 Jun 2006 06:41:14 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id BD54A3B00D2 for ; Tue, 6 Jun 2006 06:41:13 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-57-82-249-29-56.adsl.proxad.net [82.249.29.56]) by smtp1-g19.free.fr (Postfix) with ESMTP id 909369AAC7 for ; Tue, 6 Jun 2006 12:41:12 +0200 (CEST) Message-ID: <44855BEC.1040306@free.fr> Date: Tue, 06 Jun 2006 12:41:48 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga References: <1149585924.16149.8.camel@siti> In-Reply-To: <1149585924.16149.8.camel@siti> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.585 tagged_above=-999 required=2 tests=[AWL=0.014, BAYES_00=-2.599] X-Spam-Score: -2.585 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 10:41:15 -0000 Stephen Cook a écrit : > Could you send me a private email with an instant messaging address that > you use. > > BTW Damien and others we will keep as much information on the mailing > list. > > To give you guys an update I have IAX2 calls going in ekiga although it > needs a lot of work :). Then obviously the improvements to IAX2 in > opal... This sounds great :-) Do all codecs work ok ? Could you make a short list of what is lacking, so your progress can easily be seen ? :-) Snark From siti@orcon.net.nz Tue Jun 6 08:02:29 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0E2D93B008B for ; Tue, 6 Jun 2006 08:02:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19082-05 for ; Tue, 6 Jun 2006 08:02:18 -0400 (EDT) Received: from dbmail-mx3.orcon.co.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 7C3DD3B0A9D for ; Tue, 6 Jun 2006 08:01:24 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx3.orcon.co.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k56C17Ej021180 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 7 Jun 2006 00:01:12 +1200 Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Stephen Cook To: GnomeMeeting development mailing list In-Reply-To: <44855BEC.1040306@free.fr> References: <1149585924.16149.8.camel@siti> <44855BEC.1040306@free.fr> Content-Type: text/plain; charset=utf-8 Date: Wed, 07 Jun 2006 00:01:17 +1200 Message-Id: <1149595277.17468.7.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx3.orcon.co.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.495 tagged_above=-999 required=2 tests=[AWL=-0.031, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.495 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 12:02:29 -0000 On Tue, 2006-06-06 at 12:41 +0200, Julien PUYDT wrote: > Stephen Cook a écrit : > > Could you send me a private email with an instant messaging address that > > you use. > > > > BTW Damien and others we will keep as much information on the mailing > > list. > > > > To give you guys an update I have IAX2 calls going in ekiga although it > > needs a lot of work :). Then obviously the improvements to IAX2 in > > opal... > > This sounds great :-) > > Do all codecs work ok ? I have only tried ULAW > > Could you make a short list of what is lacking, so your progress can > easily be seen ? In Ekiga: * Url handler for IAX2 * If I have time in the future -- Refactor protocol components in ekiga In Iax2: * Call Hold * Transfer Calls * Register > > :-) > > Snark > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list From jan.schampera@web.de Tue Jun 6 11:41:54 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 300F43B00A7 for ; Tue, 6 Jun 2006 11:41:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01645-10 for ; Tue, 6 Jun 2006 11:41:52 -0400 (EDT) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by menubar.gnome.org (Postfix) with ESMTP id 5016E3B0117 for ; Tue, 6 Jun 2006 11:41:52 -0400 (EDT) Received: from fwd28.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1Fndgj-000497-06; Tue, 06 Jun 2006 17:41:49 +0200 Received: from mail.home.thebonsai.de (SxWWnGZHgenZylg6UcgKDR7M2nKdws-wslY10mn82PtIepb06FcVZ4@[84.147.103.162]) by fwd28.sul.t-online.de with esmtp id 1Fndgc-1VKS9o0; Tue, 6 Jun 2006 17:41:42 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id B18576B0FF for ; Tue, 6 Jun 2006 17:41:40 +0200 (CEST) Date: Tue, 6 Jun 2006 17:37:41 +0200 From: Jan Schampera To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga Message-ID: <20060606173741.7739fbf0@localhost.localdomain> In-Reply-To: <1149595277.17468.7.camel@siti> References: <1149585924.16149.8.camel@siti> <44855BEC.1040306@free.fr> <1149595277.17468.7.camel@siti> Organization: private X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: SxWWnGZHgenZylg6UcgKDR7M2nKdws-wslY10mn82PtIepb06FcVZ4@t-dialin.net X-TOI-MSGID: d621850d-8c24-4c96-bc80-424b3278e7ee X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.966 tagged_above=-999 required=2 tests=[AWL=0.632, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.966 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 15:41:54 -0000 On Wed, 07 Jun 2006 00:01:17 +1200 Stephen Cook wrote: > In Ekiga: > * Url handler for IAX2 > * If I have time in the future -- Refactor protocol components in > ekiga > > In Iax2: > * Call Hold > * Transfer Calls > * Register I X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C93A63B023C for ; Tue, 6 Jun 2006 18:32:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26160-07 for ; Tue, 6 Jun 2006 18:32:35 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by menubar.gnome.org (Postfix) with ESMTP id EE5BE3B0124 for ; Tue, 6 Jun 2006 18:32:34 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x31so57152pye for ; Tue, 06 Jun 2006 15:32:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=PWNZjwnHiPmpdYl2MsXZ9YZF9d4xYPXUg1ADy6s6gr7kpZpuMn+pMk4SiPqw6G91hexsOp1xDFUNDwMZyQ+X01mIY9TDqR0zrylP3BBJTKYCjcgQm4+vLCMe9AVXFuvgQ8NYOFrWwmRpr+zSS1OaVc2h2FssBRFPxlSabyu06bg= Received: by 10.35.76.9 with SMTP id d9mr79929pyl; Tue, 06 Jun 2006 15:32:33 -0700 (PDT) Received: by 10.35.9.3 with HTTP; Tue, 6 Jun 2006 15:32:33 -0700 (PDT) Message-ID: <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> Date: Tue, 6 Jun 2006 18:32:33 -0400 From: "mcquaid mcquaid" To: "GnomeMeeting development mailing list" Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode In-Reply-To: <1149246461.2966.28.camel@golgoth01> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7731_6834590.1149633153798" References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> <1149246461.2966.28.camel@golgoth01> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.041 tagged_above=-999 required=2 tests=[AWL=0.062, BAYES_00=-2.599, HTML_40_50=0.496, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.041 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 22:32:38 -0000 ------=_Part_7731_6834590.1149633153798 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Just a user, I'm curious as to why the trend of throwing opengl at everything. On one hand I think it's really cool, but this isn't like xgl where we want wobbly windows or something, just accelerated video. Isn't that what hardware video overlay is for? It takes a large burden off the cpu for video playback. Would benefit more people as some don't have prope= r opengl drivers. On 6/2/06, Damien Sandras wrote: > > Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit : > > So configure.in is hand-generated? Surprising. > > > > That's te way it works. You write configure.in and configure is > generated from there. I guess you are confusing things here. > > > 1) How exactly do I add the opengl ( libgl ) library? > > > > By writing autconf code in configure.in. No idea exactly how it should > be done. > > > 2) Xrandr is mentioned in the Makefile, but is not in configure.in. Ho= w > > exactly does it get put into the Makefile? > > > > Probably by an external library that we are using. > > > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I didn't wan= t > > to code against a moving target. > > > > Yes. It is even OK if you do not provide the configure.in code, but only > the OpenGL Ekiga code. > > > Thanks, > > > > -Dan > > > > Damien Sandras wrote: > > > > >Le mercredi 31 mai 2006 =E0 12:41 -0700, Dan Sandberg a =E9crit : > > > > > > > > >>I'd imagine it would work on win32, but don't know. > > >> > > >> > > >> > > > > > >Probably. > > > > > > > > > > > >>I'll work on the patches. > > >> > > >>Where's the right place to add required libraries like openGL? > > >> > > >> > > > > > >In configure.in. > > > > > > > > > > > >>configure.in seems to be autogenerated by something, but whatever it > is > > >>doesn't seem to be in the CVS snapshot... > > >> > > >> > > >> > > > > > >configure.in is in the CVS snapshot. > > > > > > > > > > > > > > >>Thanks, > > >> > > >>-Dan > > >> > > >>Julien PUYDT wrote: > > >> > > >> > > >> > > >>>Dan Sandberg a =E9crit : > > >>> > > >>> > > >>> > > >>>>How should we proceed? I could just send you an updated > gui/main.cpp > > >>>>file... > > >>>> > > >>>> > > >>>I'd like to see patches instead of full files, preferably independan= t > > >>>on each others. > > >>> > > >>>There's also the question of the portability of this : since you > > >>>mention SDL, I guess this will work great on win32 too ? > > >>> > > >>>Snark > > >>>_______________________________________________ > > >>>Gnomemeeting-devel-list mailing list > > >>>Gnomemeeting-devel-list@gnome.org > > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >>> > > >>> > > >>> > > >>_______________________________________________ > > >>Gnomemeeting-devel-list mailing list > > >>Gnomemeeting-devel-list@gnome.org > > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >> > > >> > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > -- > _ Damien Sandras > (o- > //\ Ekiga Softphone: http://www.ekiga.org/ > v_/_ FOSDEM 2006 : http://www.fosdem.org/ > SIP Phone : sip:dsandras@ekiga.net > sip:600000@ekiga.net > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > ------=_Part_7731_6834590.1149633153798 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Just a user, I'm curious as to why the trend of throwing opengl at everythi= ng.  On one hand I think it's really cool, but this isn't like xgl whe= re we want wobbly windows or something, just accelerated video.  Isn't= that what hardware video overlay is for?  It takes a large burden off= the cpu for video playback.  Would benefit more people as some don't = have proper opengl drivers.

On 6/2/06, Damien Sandras <dsand= ras@seconix.com> wrote:
Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit :
> = So configure.in is hand-generated? = ; Surprising.
>

That's te way it works. You write configure.in and configure is
generated from there. I guess you are = confusing things here.

> 1) How exactly do I add the opengl ( lib= gl ) library?
>

By writing autconf code in configure.in. No idea exactly how it should
be done.

> 2) = Xrandr is mentioned in the Makefile, but is not in configure.in.  How
> exactly does it get put in= to the Makefile?
>

Probably by an external library that we are using.

&= gt; 3) Is it ok if I send in a patch that is for Ekiga 2.0.1?  I = didn't want
> to code against a moving target.
>

Yes. It= is even OK if you do not provide the=20 configure.in code, but only
the Open= GL Ekiga code.

> Thanks,
>
> -Dan
>
> Dam= ien Sandras wrote:
>
> >Le mercredi 31 mai 2006 =E0 12:41 -0= 700, Dan Sandberg a =E9crit :
> >
> >
> >>I'd imagine it would work on win= 32, but don't know.
> >>
> >>
> >>
&= gt; >
> >Probably.
> >
> >
> >
> >>I'll work on the patches.
> >>
> >>Whe= re's the right place to add required libraries like openGL?
> >>= ;
> >>
> >
> >In configure.in.
> >
> >
> >
> >>configure.in seems to be autogenerated by= something, but whatever it is
> >>doesn't seem to be in the CV= S snapshot...
> >>
> >>
> >>
> >
> &g= t;configure.in is in the CVS snapshot.<= br>> >
> >
> >
> >
> >>Thanks,
> >>
> >>-Dan
> >>
> >>Jul= ien PUYDT wrote:
> >>
> >>
> >>
>= >>>Dan Sandberg a =E9crit :
> >>>
> >>= >
> >>>
> >>>>How should we proceed? &= nbsp;I could just send you an updated gui/main.cpp
> >>>>= file...
> >>>>
> >>>>
> >>&= gt;I'd like to see patches instead of full files, preferably independant
> >>>on each others.
> >>>
> >>&= gt;There's also the question of the portability of this : since you
>= >>>mention SDL, I guess this will work great on win32 too ?
> >>>
> >>>Snark
> >>>___________= ____________________________________
> >>>Gnomemeeting-devel= -list mailing list
> >>> Gnomemeeting-devel-list@gnome.org
> >>>http://mail.gnome= .org/mailman/listinfo/gnomemeeting-devel-list
> >>>
> >>>
> >>>
> >>____________________= ___________________________
> >>Gnomemeeting-devel-list mailing= list
> >> Gnomemeeting-devel-list@gnome.org
> >>http://mail.gnome.org= /mailman/listinfo/gnomemeeting-devel-list
> >>
> >= >
>
> _______________________________________________
> Gn= omemeeting-devel-list mailing list
> Gnomemeeting-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
-- _      Damien Sandras
(o-
//\ &n= bsp;   Ekiga Softphone: http://= www.ekiga.org/
v_/_    FOSDEM 2006  &n= bsp; : http://www.fosdem.org/
       &nb= sp;SIP Phone      : sip:dsandras@ekiga.net
    &nbs= p;            &= nbsp;       sip:600000@ekiga.net

____________________________________= ___________
Gnomemeeting-devel-list mailing list
Gnomemeeting-devel-list@gnome.org
http://mail.= gnome.org/mailman/listinfo/gnomemeeting-devel-list

------=_Part_7731_6834590.1149633153798-- From x@cs.stanford.edu Tue Jun 6 18:47:00 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5D25C3B036D for ; Tue, 6 Jun 2006 18:46:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26984-04 for ; Tue, 6 Jun 2006 18:46:56 -0400 (EDT) Received: from smtp104.plus.mail.mud.yahoo.com (smtp104.plus.mail.mud.yahoo.com [68.142.206.237]) by menubar.gnome.org (Postfix) with SMTP id 502483B0124 for ; Tue, 6 Jun 2006 18:46:56 -0400 (EDT) Received: (qmail 87952 invoked from network); 6 Jun 2006 22:46:55 -0000 Received: from unknown (HELO ?192.168.2.47?) (dan?sandberg@71.138.128.214 with plain) by smtp104.plus.mail.mud.yahoo.com with SMTP; 6 Jun 2006 22:46:54 -0000 Message-ID: <448605B0.6080504@cs.stanford.edu> Date: Tue, 06 Jun 2006 15:46:08 -0700 From: Dan Sandberg User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> <1149246461.2966.28.camel@golgoth01> <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> In-Reply-To: <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.808 tagged_above=-999 required=2 tests=[AWL=-0.593, BAYES_00=-2.599, SPF_SOFTFAIL=1.384] X-Spam-Score: -1.808 X-Spam-Level: Cc: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 22:47:00 -0000 I could be wrong, but I believe that video overlay moves the data direct from a capture card to the video card, bypassing the CPU. Since we're trying to display images that come from over the network, there's no way to bypass the CPU. And doing a nice looking resize from 176x144 to 640x480 is quite slow. Then you have to copy the whole 640x480 image to the display card, which is slow. With OpenGL you just copy the 176x144 image to the video card, and have it do the resize. Cheers, -Dan mcquaid mcquaid wrote: > Just a user, I'm curious as to why the trend of throwing opengl at > everything. On one hand I think it's really cool, but this isn't like > xgl where we want wobbly windows or something, just accelerated > video. Isn't that what hardware video overlay is for? It takes a > large burden off the cpu for video playback. Would benefit more > people as some don't have proper opengl drivers. > > On 6/2/06, *Damien Sandras* > wrote: > > Le vendredi 02 juin 2006 à 03:03 -0700, Dan Sandberg a écrit : > > So configure.in is > hand-generated? Surprising. > > > > That's te way it works. You write configure.in > and configure is > generated from there. I guess you are confusing things here. > > > 1) How exactly do I add the opengl ( libgl ) library? > > > > By writing autconf code in configure.in . No > idea exactly how it should > be done. > > > 2) Xrandr is mentioned in the Makefile, but is not in > configure.in . How > > exactly does it get put into the Makefile? > > > > Probably by an external library that we are using. > > > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I > didn't want > > to code against a moving target. > > > > Yes. It is even OK if you do not provide the configure.in > code, but only > the OpenGL Ekiga code. > > > Thanks, > > > > -Dan > > > > Damien Sandras wrote: > > > > >Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > > > > > > > > >>I'd imagine it would work on win32, but don't know. > > >> > > >> > > >> > > > > > >Probably. > > > > > > > > > > > >>I'll work on the patches. > > >> > > >>Where's the right place to add required libraries like openGL? > > >> > > >> > > > > > >In configure.in . > > > > > > > > > > > >>configure.in seems to be autogenerated > by something, but whatever it is > > >>doesn't seem to be in the CVS snapshot... > > >> > > >> > > >> > > > > > >configure.in is in the CVS snapshot. > > > > > > > > > > > > > > >>Thanks, > > >> > > >>-Dan > > >> > > >>Julien PUYDT wrote: > > >> > > >> > > >> > > >>>Dan Sandberg a écrit : > > >>> > > >>> > > >>> > > >>>>How should we proceed? I could just send you an updated > gui/main.cpp > > >>>>file... > > >>>> > > >>>> > > >>>I'd like to see patches instead of full files, preferably > independant > > >>>on each others. > > >>> > > >>>There's also the question of the portability of this : since you > > >>>mention SDL, I guess this will work great on win32 too ? > > >>> > > >>>Snark > > >>>_______________________________________________ > > >>>Gnomemeeting-devel-list mailing list > > >>> Gnomemeeting-devel-list@gnome.org > > > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >>> > > >>> > > >>> > > >>_______________________________________________ > > >>Gnomemeeting-devel-list mailing list > > >> Gnomemeeting-devel-list@gnome.org > > > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >> > > >> > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > -- > _ Damien Sandras > (o- > //\ Ekiga Softphone: http://www.ekiga.org/ > v_/_ FOSDEM 2006 : http://www.fosdem.org/ > SIP Phone : sip:dsandras@ekiga.net > > sip:600000@ekiga.net > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > From mcquaidster@gmail.com Tue Jun 6 19:15:44 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1CB1D3B0100 for ; Tue, 6 Jun 2006 19:15:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28543-05 for ; Tue, 6 Jun 2006 19:15:41 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id 15D153B033F for ; Tue, 6 Jun 2006 19:15:40 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x31so65185pye for ; Tue, 06 Jun 2006 16:15:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Mcduoi+u93PszObMtVWeXgYeQW4VI1eW7YkgZ+7d03TZ67OjKeE6aoo507wYkIOly9icd2mdZ2fuDTkH7FKrnfSoGo+jOXhxLaobIUCU6gQdxyXgRqVTPVs16J/2P3hFDJ8K1ELtr1xuKRWtdbXceWGlDpZn2R3lxDak1f6E47c= Received: by 10.35.40.10 with SMTP id s10mr72093pyj; Tue, 06 Jun 2006 16:15:39 -0700 (PDT) Received: by 10.35.9.3 with HTTP; Tue, 6 Jun 2006 16:15:39 -0700 (PDT) Message-ID: <58a398810606061615s6a801fected291a67dbb85214@mail.gmail.com> Date: Tue, 6 Jun 2006 19:15:39 -0400 From: "mcquaid mcquaid" To: "Dan Sandberg" Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode In-Reply-To: <448605B0.6080504@cs.stanford.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8108_3516387.1149635739799" References: <447CCA43.3@stdout.at> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> <1149246461.2966.28.camel@golgoth01> <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> <448605B0.6080504@cs.stanford.edu> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.242 tagged_above=-999 required=2 tests=[AWL=0.223, BAYES_00=-2.599, HTML_50_60=0.134, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.242 X-Spam-Level: Cc: GnomeMeeting development mailing list X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 23:15:44 -0000 ------=_Part_8108_3516387.1149635739799 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hmm, again I don't know much about this but I think what you describe can b= e handled by hardware video overlay. Just a quick googling has this about hardware video overlay at the zoomplayer's website: http://www.inmatrix.com/zplayer/highlights/vidrender.shtml *The Video Overlay:* > At around 1995, when MPEG1 (VCD) playback started to become popular on th= e > PC, the actual processing power of the PC was not quite strong enough to > play such content. The display card manufacturers at the time came up wit= h a > solution called "The Video Overlay". The Video Overlay is a special hardw= are > on the display card which is used to perform several video-display featur= es > in hardware (Stretching, Color-Space Conversion, etc...), thus allowing > smooth playback of video at no cost to the CPU. It does go on to say that video rendering via dx9 (and thus I assume opengl) provide better image quality and don't suffer from some multimonitor issues with video overlay. Afaik, only one display can have hardware overlay so that's what he's referring to there. But, for the most part, it sounds like hardware overlay would be a nice solution as well that just about everyone would benefit from as again, ther= e are still a lot of people without good opengl in linux but most probably functional hardware overlay. Maybe an option for both? On 6/6/06, Dan Sandberg wrote: > > I could be wrong, but I believe that video overlay moves the data direct > from a capture card to the video card, bypassing the CPU. Since we're > trying to display images that come from over the network, there's no way > to bypass the CPU. And doing a nice looking resize from 176x144 to > 640x480 is quite slow. Then you have to copy the whole 640x480 image to > the display card, which is slow. With OpenGL you just copy the 176x144 > image to the video card, and have it do the resize. > > Cheers, > > -Dan > > mcquaid mcquaid wrote: > > Just a user, I'm curious as to why the trend of throwing opengl at > > everything. On one hand I think it's really cool, but this isn't like > > xgl where we want wobbly windows or something, just accelerated > > video. Isn't that what hardware video overlay is for? It takes a > > large burden off the cpu for video playback. Would benefit more > > people as some don't have proper opengl drivers. > > > > On 6/2/06, *Damien Sandras* > > wrote: > > > > Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit : > > > So configure.in is > > hand-generated? Surprising. > > > > > > > That's te way it works. You write configure.in > > and configure is > > generated from there. I guess you are confusing things here. > > > > > 1) How exactly do I add the opengl ( libgl ) library? > > > > > > > By writing autconf code in configure.in . No > > idea exactly how it should > > be done. > > > > > 2) Xrandr is mentioned in the Makefile, but is not in > > configure.in . How > > > exactly does it get put into the Makefile? > > > > > > > Probably by an external library that we are using. > > > > > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I > > didn't want > > > to code against a moving target. > > > > > > > Yes. It is even OK if you do not provide the configure.in > > code, but only > > the OpenGL Ekiga code. > > > > > Thanks, > > > > > > -Dan > > > > > > Damien Sandras wrote: > > > > > > >Le mercredi 31 mai 2006 =E0 12:41 -0700, Dan Sandberg a =E9crit = : > > > > > > > > > > > >>I'd imagine it would work on win32, but don't know. > > > >> > > > >> > > > >> > > > > > > > >Probably. > > > > > > > > > > > > > > > >>I'll work on the patches. > > > >> > > > >>Where's the right place to add required libraries like openGL? > > > >> > > > >> > > > > > > > >In configure.in . > > > > > > > > > > > > > > > >>configure.in seems to be autogenerated > > by something, but whatever it is > > > >>doesn't seem to be in the CVS snapshot... > > > >> > > > >> > > > >> > > > > > > > >configure.in is in the CVS snapshot. > > > > > > > > > > > > > > > > > > > >>Thanks, > > > >> > > > >>-Dan > > > >> > > > >>Julien PUYDT wrote: > > > >> > > > >> > > > >> > > > >>>Dan Sandberg a =E9crit : > > > >>> > > > >>> > > > >>> > > > >>>>How should we proceed? I could just send you an updated > > gui/main.cpp > > > >>>>file... > > > >>>> > > > >>>> > > > >>>I'd like to see patches instead of full files, preferably > > independant > > > >>>on each others. > > > >>> > > > >>>There's also the question of the portability of this : since > you > > > >>>mention SDL, I guess this will work great on win32 too ? > > > >>> > > > >>>Snark > > > >>>_______________________________________________ > > > >>>Gnomemeeting-devel-list mailing list > > > >>> Gnomemeeting-devel-list@gnome.org > > > > > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > >>> > > > >>> > > > >>> > > > >>_______________________________________________ > > > >>Gnomemeeting-devel-list mailing list > > > >> Gnomemeeting-devel-list@gnome.org > > > > > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > >> > > > >> > > > > > > _______________________________________________ > > > Gnomemeeting-devel-list mailing list > > > Gnomemeeting-devel-list@gnome.org > > > > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > -- > > _ Damien Sandras > > (o- > > //\ Ekiga Softphone: http://www.ekiga.org/ > > v_/_ FOSDEM 2006 : http://www.fosdem.org/ > > SIP Phone : sip:dsandras@ekiga.net > > > > sip:600000@ekiga.net > > > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > ------=_Part_8108_3516387.1149635739799 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hmm, again I don't know much about this but I think what you describe can b= e handled by
hardware video overlay.

Just a quick googling has t= his about hardware video overlay at the zoomplayer's website:

http://www.inmatrix.com/zplayer/highlights/vidrender.shtml

The Video Overlay:
At around 1995, when MPEG1 (VCD) playback started to become popular on the = PC, the actual processing power of the PC was not quite strong enough to play such content. The display card manufacturers a= t the time came up with a solution called "The Video Overlay". The Video Overlay is a special hardware on = the display card which is used to perform several video-display features in hardware (Stretching, Color-Space Conversion, etc...), thus all= owing smooth playback of video at no cost to the CPU.


It does go on to say  that video rend= ering via dx9 (and thus I assume opengl)  provide better image quality= and don't suffer from some multimonitor issues with video overlay.
Afai= k, only one display can have hardware overlay so that's what he's referring= to there.

But, for the most part, it sounds like hardware overlay would be a = nice solution as well that just about everyone would benefit from as again,= there are still a lot of people without good opengl in linux but most prob= ably functional hardware overlay.

Maybe an option for both? 

On 6/6/06, Dan Sandberg <<= a href=3D"mailto:x@cs.stanford.edu">x@cs.stanford.edu> wrote:=
I could be wrong, but I believe that video overlay moves the data directfrom a capture card to the video card, bypassing the CPU.  Since= we're
trying to display images that come from over the network, there's= no way
to bypass the CPU.  And doing a nice looking resize from 176x= 144 to
640x480 is quite slow.  Then you have to copy the whole= 640x480 image to
the display card, which is slow.  With OpenG= L you just copy the 176x144
image to the video card, and have it do the resize.

Cheers,
<= br>-Dan

mcquaid mcquaid wrote:
> Just a user, I'm curious as t= o why the trend of throwing opengl at
> everything.  On one= hand I think it's really cool, but this isn't like
> xgl where we want wobbly windows or something, just accelerated> video.  Isn't that what hardware video overlay is for? = ; It takes a
> large burden off the cpu for video playback. = ; Would benefit more
> people as some don't have proper opengl drivers.
>
> On 6/= 2/06, *Damien Sandras* <dsandras= @seconix.com
> <mailto: dsandras@seconix.com>> wrote:
>
>   &n= bsp; Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit :
= >     > So config= ure.in < http://configure.in> is
>     hand-generat= ed?  Surprising.
>     >
>
= >     That's te way it works. You write configure.in
>     < http://configure.in> and configure is
>    = ; generated from there. I guess you are confusing things here.
>
&= gt;     > 1) How exactly do I add the opengl ( libgl= ) library?
>     >
>
>     By writing autconf code in configure.in <http:= //configure.in>. No
>     idea exactly how= it should
>     be done.
>
>     > 2) Xrandr is mentioned in the Makefile, b= ut is not in
>     configure.in <http://configure.in<= /a>>.  How
>     > exactly does i= t get put into the Makefile?
>     >
>
>   &nbs= p; Probably by an external library that we are using.
>
> =     > 3) Is it ok if I send in a patch that is for Ekiga = 2.0.1?  I
>     didn't want
>&nbs= p;    > to code against a moving target.
>     >
>
>   &nbs= p; Yes. It is even OK if you do not provide the configure.in
>     <http://configure.in> code, but only
>     the OpenGL Ekiga code.
>
> &n= bsp;   > Thanks,
>     >
>&= nbsp;    > -Dan
>     >
&= gt;     > Damien Sandras wrote:
>  &= nbsp;  >
>     > >Le mercredi 31 ma= i 2006 =E0 12:41 -0700, Dan Sandberg a =E9crit :
>     > >
>     = > >
>     > >>I'd imagine it would= work on win32, but don't know.
>     > >&g= t;
>     > >>
>   &= nbsp; > >>
>     > >
>     > >Probably.
>  &nbs= p;  > >
>     > >
> &= nbsp;   > >
>     > >>I'= ll work on the patches.
>     > >>
&g= t;     > >>Where's the right place to add requ= ired libraries like openGL?
>     > >>
>   &nb= sp; > >>
>     > >
> &n= bsp;   > >In configure.in <http://configure.in>.
>=      > >
>     > >
>     = > >
>     > >>configure.in <http://con= figure.in> seems to be autogenerated
>    = by something, but whatever it is
>     > >>doesn't seem to be in the CVS= snapshot...
>     > >>
> &nb= sp;   > >>
>     > >>=
>     > >
>     = > >configure.in <http://configure.in> is in = the CVS snapshot.
>     > >
> &n= bsp;   > >
>     > >
>= ;     > >
>     > &g= t;>Thanks,
>     > >>
>     > >>-Dan
>   = ;  > >>
>     > >>Julien P= UYDT wrote:
>     > >>
> &nbs= p;   > >>
>     > >><= br>>     > >>>Dan Sandberg a =E9crit :
>     > >>>
>   = ;  > >>>
>     > >>>=
>     > >>>>How should we proceed= ?  I could just send you an updated
>   &nbs= p; gui/main.cpp
>     > >>>>file..= .
>     > >>>>
>  &= nbsp;  > >>>>
>     > >= >>I'd like to see patches instead of full files, preferably
>&n= bsp;    independant
>     > >= ;>>on each others.
>     > >>>
>   = ;  > >>>There's also the question of the portability of th= is : since you
>     > >>>mention SDL= , I guess this will work great on win32 too ?
>   &nbs= p; > >>>
>     > >>>Snark
>  =    > >>>_____________________________________________= __
>     > >>>Gnomemeeting-devel-list= mailing list
>     > >>> Gnomemeeting-devel-list@gnome.org
>     <m= ailto:Gnomemeeting-dev= el-list@gnome.org>
>     > >>>= http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>&= nbsp;    > >>>
>     &= gt; >>>
>     > >>>
>&= nbsp;    > >>______________________________________= _________
>     > >>Gnomemeeting-devel-list maili= ng list
>     > >> Gnomemeeting-devel-list@gnome.org
&g= t;     <mailto: Gnomemeeting-devel-list@gnome.org>
>     &= gt; >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list<= /a>
>     > >>
>     > >>
>   &nb= sp; >
>     > _____________________________= __________________
>     > Gnomemeeting-devel-= list mailing list
>     > Gnomemeeting-devel-list@gnome.org
>     <m= ailto:Gnomemeeting-dev= el-list@gnome.org>
>     > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>&= nbsp;    --
>     _  &nb= sp;   Damien Sandras
>     (o-
= >     //\     Ekiga Softphone: <= a href=3D"http://www.ekiga.org/">http://www.ekiga.org/
>     v_/_    FOSDEM 200= 6    : http://www.fo= sdem.org/
>         =     SIP Phone      : sip:dsandras@ekiga.net
> =     <mailto: sip:dsandr= as@ekiga.net>
>        = ;            &n= bsp;         sip:600000@ekiga.net
>   &n= bsp; <mailto: sip:600000@ekiga.net>
>= ;
>     _________________________________________= ______
>     Gnomemeeting-devel-list mailing list=
>     Gnomemeeting-devel-list@gnome.org
>     <m= ailto:Gnomemeeting-dev= el-list@gnome.org>
>     http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>&= nbsp;    <http://mail.gnome.org/mailman/listinfo/gnomemee= ting-devel-list >
>
>
> ----------------------------------------------= --------------------------
>
> ________________________________= _______________
> Gnomemeeting-devel-list mailing list
> Gnomemeeting-devel-list@gnome.org
> http://mail.gnome.org/mailman= /listinfo/gnomemeeting-devel-list
>

------=_Part_8108_3516387.1149635739799-- From stefan@watri.org.au Wed Jun 7 00:39:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 26FE33B0B45 for ; Wed, 7 Jun 2006 00:39:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12142-08 for ; Wed, 7 Jun 2006 00:39:13 -0400 (EDT) Received: from asclepius.uwa.edu.au (asclepius.uwa.edu.au [130.95.128.56]) by menubar.gnome.org (Postfix) with ESMTP id 1153F3B022D for ; Wed, 7 Jun 2006 00:39:11 -0400 (EDT) Received: from asclepius.kas (localhost.localdomain [127.0.0.1]) by asclepius.uwa.edu.au (Postfix) with SMTP id 9EF11184629 for ; Wed, 7 Jun 2006 12:39:05 +0800 (WST) Received: from asclepius (localhost.localdomain [127.0.0.1]) by asclepius.prekas (Postfix) with SMTP id 7CB52188123 for ; Wed, 7 Jun 2006 12:39:05 +0800 (WST) X-UWA-Client-IP: 130.95.28.15 (UWA) Received: from ns1.watri.uwa.edu.au (ns1.watri.org.au [130.95.28.15]) by asclepius.extinput (Postfix) with ESMTP id 6CCE5188174 for ; Wed, 7 Jun 2006 12:39:05 +0800 (WST) Received: from gluttony (gluttony.watri.org.au [130.95.29.76]) by ns1.watri.uwa.edu.au (8.13.1/8.13.1) with ESMTP id k574d4dE023954 for ; Wed, 7 Jun 2006 12:39:04 +0800 (WST) Message-Id: <200606070439.k574d4dE023954@ns1.watri.uwa.edu.au> From: =?iso-8859-1?Q?Stefan_Br=FCns?= To: "'GnomeMeeting development mailing list'" Subject: RE: [GnomeMeeting-devel-list] Full Screen Mode Date: Wed, 7 Jun 2006 12:41:40 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <448605B0.6080504@cs.stanford.edu> Thread-Index: AcaJu2+MfoUGcqUFRii2sxvr70Y3NQALgJIg X-SpamTest-Info: Profile: Formal (387/060606) X-SpamTest-Info: Profile: Detect Hard [UCS 290904] X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking Spam - Subject (UCS) [02-08-04] X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.176 tagged_above=-999 required=2 tests=[AWL=-1.125, BAYES_40=-0.185, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] X-Spam-Score: -1.176 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 04:39:16 -0000 > -----Original Message----- > From: gnomemeeting-devel-list-bounces@gnome.org > [mailto:gnomemeeting-devel-list-bounces@gnome.org] On Behalf > Of Dan Sandberg > Sent: Wednesday, 7 June 2006 6:46 AM > To: GnomeMeeting development mailing list > Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode > > I could be wrong, but I believe that video overlay moves the > data direct > >from a capture card to the video card, bypassing the CPU. > Since we're > trying to display images that come from over the network, > there's no way > to bypass the CPU. And doing a nice looking resize from 176x144 to > 640x480 is quite slow. Then you have to copy the whole > 640x480 image to > the display card, which is slow. With OpenGL you just copy > the 176x144 > image to the video card, and have it do the resize. Just to clarify some things: Video overlay over XV support scaling in hardware, and colorspace transforms. Unfortunately, most graphic cards support only one overlay at a time. In case you only have a single video, this is fine, but as soon as you have multiple (local/remote, maybe conference anytime in the future), you have to do the compositing before uploading the image to the card. In case of Picture in Picture, this means that you a) Scale the to be small video down, compose it into the large one, and upload the composed image. Drawback: Also the small image may end up as large as an unscaled CIF image, it will have a lower resolution, due to the downscaling. or b) Scale the to be large image up, and compose the small image into it. Also the small image will have its full resolution (it may be a CIF (352x288) image on a 1024x768 or larger screen), the upscaling of the large image adds a lot of burden to the CPU and memory transfers. On the other hand, if you use OpenGL textures, you have all the benefits: - You can upload every video to a different texture, every video ends up on the screen with all the available resolution, all the scaling is done on the GPU (which is very efficient for this). - Most cards support YUV colorspaces for textures, so color transform can be done on the card. - As the different videos stream end up on different textures, you may have the local video with full 25fps framerate, and the remote with something like 10fps. - Superimposing any text (Chat, callers name, new incoming call ...) comes down to putting the text into just another texture. This may be easily alpha blended, with full screen resolution (if you superimpose text on the video directly, you can only use the videos resolution, and edges may look really strange due to the UV subsampling). - You may due almost arbitrary transforms on the video, without burdening the CPU (have a look at the Conference feature of iChat AV to see what I mean). Greetings, Stefan From t.schorpp@gmx.de Wed Jun 7 03:35:24 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 125143B0C5F for ; Wed, 7 Jun 2006 03:35:24 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23077-04 for ; Wed, 7 Jun 2006 03:35:22 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by menubar.gnome.org (Postfix) with SMTP id 544083B0368 for ; Wed, 7 Jun 2006 03:35:21 -0400 (EDT) Received: (qmail invoked by alias); 07 Jun 2006 07:35:19 -0000 Received: from p85.212.144.48.tisdip.tiscali.de (EHLO [192.168.1.100]) [85.212.144.48] by mail.gmx.net (mp029) with SMTP; 07 Jun 2006 09:35:19 +0200 X-Authenticated: #17142692 Message-ID: <448681B6.5000204@gmx.de> Date: Wed, 07 Jun 2006 09:35:18 +0200 From: thomas schorpp User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1 X-Accept-Language: de, en-us MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode References: <200606070439.k574d4dE023954@ns1.watri.uwa.edu.au> In-Reply-To: <200606070439.k574d4dE023954@ns1.watri.uwa.edu.au> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.476 tagged_above=-999 required=2 tests=[AWL=-0.011, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] X-Spam-Score: -2.476 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: t.schorpp@gmx.de, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 07:35:24 -0000 Stefan Brüns wrote: >>-----Original Message----- >>From: gnomemeeting-devel-list-bounces@gnome.org >>[mailto:gnomemeeting-devel-list-bounces@gnome.org] On Behalf >>Of Dan Sandberg >>Sent: Wednesday, 7 June 2006 6:46 AM >>To: GnomeMeeting development mailing list >>Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode >> >>I could be wrong, but I believe that video overlay moves the >>data direct >>>from a capture card to the video card, bypassing the CPU. >>Since we're >>trying to display images that come from over the network, >>there's no way >>to bypass the CPU. And doing a nice looking resize from 176x144 to >>640x480 is quite slow. Then you have to copy the whole >>640x480 image to >>the display card, which is slow. With OpenGL you just copy >>the 176x144 >>image to the video card, and have it do the resize. > > > Just to clarify some things: > > Video overlay over XV support scaling in hardware, and colorspace > transforms. are You sure? ive some display apps here which can switch between XV and "real overlay". kvdr, tvtime, xawtv... XV can use significant high cpu load in my experience here... > > Unfortunately, most graphic cards support only one overlay at a time. not sure about this, too. all the chips i had since ati mach64 supported at least 2 overlays at a time. kvdr supports even up to 4 overlays(?) on modern cards respectively. http://www.s.netic.de/gfiala/ > In > case you only have a single video, this is fine, but as soon as you have > multiple (local/remote, maybe conference anytime in the future), you have to > do the compositing before uploading the image to the card. In case of > Picture in Picture, this means that you > > a) Scale the to be small video down, compose it into the large one, and > upload the composed image. Drawback: Also the small image may end up as > large as an unscaled CIF image, it will have a lower resolution, due to the > downscaling. > > or > b) Scale the to be large image up, and compose the small image into it. Also > the small image will have its full resolution (it may be a CIF (352x288) > image on a 1024x768 or larger screen), the upscaling of the large image adds > a lot of burden to the CPU and memory transfers. > > On the other hand, if you use OpenGL textures, you have all the benefits: > - You can upload every video to a different texture, every video ends up on > the screen with all the available resolution, all the scaling is done on the > GPU (which is very efficient for this). > - Most cards support YUV colorspaces for textures, so color transform can be > done on the card. > - As the different videos stream end up on different textures, you may have > the local video with full 25fps framerate, and the remote with something > like 10fps. > - Superimposing any text (Chat, callers name, new incoming call ...) comes > down to putting the text into just another texture. This may be easily alpha > blended, with full screen resolution (if you superimpose text on the video > directly, you can only use the videos resolution, and edges may look really > strange due to the UV subsampling). > - You may due almost arbitrary transforms on the video, without burdening > the CPU (have a look at the Conference feature of iChat AV to see what I > mean). > > Greetings, > is there no standard "network video class" for the application layer somewhere? > Stefan tom From jpuydt@free.fr Wed Jun 7 07:50:57 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 57F3B3B030A for ; Wed, 7 Jun 2006 07:50:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08294-07 for ; Wed, 7 Jun 2006 07:50:54 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id 565043B03D0 for ; Wed, 7 Jun 2006 07:50:54 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp3-g19.free.fr (Postfix) with ESMTP id 26AE4498B4 for ; Wed, 7 Jun 2006 13:50:53 +0200 (CEST) Message-ID: <4486BDD0.9050805@free.fr> Date: Wed, 07 Jun 2006 13:51:44 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.845 tagged_above=-999 required=2 tests=[AWL=-0.735, BAYES_05=-1.11] X-Spam-Score: -1.845 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Refactoring of the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 11:50:57 -0000 Hi, after some discussions, it seems my initial ideas just don't fly. I don't consider them as a full failure, but they certainly are 80% so. I has in particular a long (private) discussion with Éric Bischoff, which allowed me to test my ideas on a newcomer. :-) Snark From jpuydt@free.fr Wed Jun 7 08:02:38 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A3A943B0CA0 for ; Wed, 7 Jun 2006 08:02:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09379-09 for ; Wed, 7 Jun 2006 08:02:30 -0400 (EDT) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by menubar.gnome.org (Postfix) with ESMTP id 0A6253B0CFE for ; Wed, 7 Jun 2006 08:01:42 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp2-g19.free.fr (Postfix) with ESMTP id 9A1E973329 for ; Wed, 7 Jun 2006 14:01:41 +0200 (CEST) Message-ID: <4486C05B.9080200@free.fr> Date: Wed, 07 Jun 2006 14:02:35 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> In-Reply-To: <4486BDD0.9050805@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:02:38 -0000 Julien PUYDT a écrit : > Notice that I forgot the conclusion : back to blackboard :-) Snark From pbrobinson@gmail.com Wed Jun 7 08:05:53 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D7E343B0C89 for ; Wed, 7 Jun 2006 08:05:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09667-03 for ; Wed, 7 Jun 2006 08:05:53 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by menubar.gnome.org (Postfix) with ESMTP id 33FD03B0C35 for ; Wed, 7 Jun 2006 08:05:52 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id q2so283058uge for ; Wed, 07 Jun 2006 05:05:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=G9St54usrU1EqN6hzRVdcsL0b9E6Bqxv3H4s4TGGxDEm0S9y4VTy4J2/S9c86GUzX86KIkPRd3gDHRfgFY6rCHfD2mYVgjzsw18dl0V8Ib8+WG4xy7/jO5pBwQEky1I69/GeIoNY6Q1nIE7TBp9rIFYmsHkPs+aO3lXDh5BJAzE= Received: by 10.67.89.5 with SMTP id r5mr423228ugl; Wed, 07 Jun 2006 05:05:51 -0700 (PDT) Received: by 10.67.25.6 with HTTP; Wed, 7 Jun 2006 05:05:51 -0700 (PDT) Message-ID: <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> Date: Wed, 7 Jun 2006 13:05:51 +0100 From: "Peter Robinson" To: "GnomeMeeting development mailing list" Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code In-Reply-To: <4486C05B.9080200@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4486BDD0.9050805@free.fr> <4486C05B.9080200@free.fr> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.56 tagged_above=-999 required=2 tests=[AWL=-0.518, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.56 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:05:54 -0000 > Julien PUYDT a =E9crit : > > > > Notice that I forgot the conclusion : back to blackboard :-) So are there any ideas running around that blackboard as of yet? Peter From jpuydt@free.fr Wed Jun 7 08:22:36 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CBE393B08CC for ; Wed, 7 Jun 2006 08:22:36 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10857-05 for ; Wed, 7 Jun 2006 08:22:35 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 97D9B3B0CDC for ; Wed, 7 Jun 2006 08:22:35 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp5-g19.free.fr (Postfix) with ESMTP id 65742275AC for ; Wed, 7 Jun 2006 14:22:34 +0200 (CEST) Message-ID: <4486C53D.2080306@free.fr> Date: Wed, 07 Jun 2006 14:23:25 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> In-Reply-To: <4486BDD0.9050805@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:22:37 -0000 Ok, so let's see what the constraints are. 1) the already available addressbooks must fit in the new scheme ; 2) the future kde addressbooks must find their place easily ; 3) searching should be dead-easy ; 4) the future "live" contacts must find their place easily ; 5) the backend-frontend frontier should be clear enough to allow for easy DBUS exporting 6) Damien wants it fast. Yes, going back to the blackboard isn't the best way to achieve 6... Snark From jpuydt@free.fr Wed Jun 7 08:52:53 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 92FD63B03C4 for ; Wed, 7 Jun 2006 08:52:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12995-08 for ; Wed, 7 Jun 2006 08:52:50 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id D0F7E3B0C97 for ; Wed, 7 Jun 2006 08:52:49 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp3-g19.free.fr (Postfix) with ESMTP id AEAAC497A1 for ; Wed, 7 Jun 2006 14:52:48 +0200 (CEST) Message-ID: <4486CC54.9090206@free.fr> Date: Wed, 07 Jun 2006 14:53:40 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <4486C05B.9080200@free.fr> <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> In-Reply-To: <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:52:53 -0000 Peter Robinson a écrit : > So are there any ideas running around that blackboard as of yet? Plenty. Snark From ebischoff@nerim.net Wed Jun 7 09:43:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C57F03B03C1 for ; Wed, 7 Jun 2006 09:43:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17343-08 for ; Wed, 7 Jun 2006 09:43:14 -0400 (EDT) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by menubar.gnome.org (Postfix) with ESMTP id BB8E53B03F1 for ; Wed, 7 Jun 2006 09:43:13 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 09C7C40FD8 for ; Wed, 7 Jun 2006 15:43:11 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Wed, 7 Jun 2006 15:43:21 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <4486C53D.2080306@free.fr> In-Reply-To: <4486C53D.2080306@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606071543.22163.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.562 tagged_above=-999 required=2 tests=[AWL=0.037, BAYES_00=-2.599] X-Spam-Score: -2.562 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 13:43:16 -0000 Le Mercredi 7 Juin 2006 14:23, Julien PUYDT a =C3=A9crit=C2=A0: > Yes, going back to the blackboard isn't the best way to achieve 6... You don't go black to the blackboard with no experience ;-). In pecular, I have been proposing a framework for address book "drivers" li= ke: class EkigaAddressBook { public: virtual gchar *name() const =3D 0; virtual const EkigaContact *firstContact() =3D 0; virtual const EkigaContact *nextContact() =3D 0; }; class EkigaContact { public: virtual boolean hasName() const =3D 0; virtual gchar *name() const =3D 0; virtual boolean hasTelephone() const =3D 0; virtual gchar *telephone() const =3D 0; etc... }; class EkigaEvolutionAddressBook : public EkigaAddressBook { public: virtual gchar *name() const; virtual const EkigaContact *firstContact(); virtual const EkigaContact *nextContact(); }; class EkigaEvolutionContact : public EkigaContact { public: virtual boolean hasName() const; virtual gchar *name() const; virtual boolean hasTelephone() const; virtual gchar *telephone() const; etc... }; Comments and flames welcome. =2D-=20 =C3=89ric From jpuydt@free.fr Wed Jun 7 13:58:31 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6343F3B0BC1 for ; Wed, 7 Jun 2006 13:58:31 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02884-04 for ; Wed, 7 Jun 2006 13:58:23 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 55DA13B069F for ; Wed, 7 Jun 2006 13:58:19 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp1-g19.free.fr (Postfix) with ESMTP id E2BA8911A6 for ; Wed, 7 Jun 2006 19:58:17 +0200 (CEST) Message-ID: <4486F76C.7060301@free.fr> Date: Wed, 07 Jun 2006 17:57:32 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <4486C53D.2080306@free.fr> <200606071543.22163.ebischoff@nerim.net> In-Reply-To: <200606071543.22163.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 17:58:31 -0000 Éric Bischoff a écrit : > Le Mercredi 7 Juin 2006 14:23, Julien PUYDT a écrit : >> Yes, going back to the blackboard isn't the best way to achieve 6... > > You don't go black to the blackboard with no experience ;-). Of course no :-) > In pecular, I have been proposing a framework for address book "drivers" like: > > class EkigaAddressBook > { > public: > virtual gchar *name() const = 0; > virtual const EkigaContact *firstContact() = 0; > virtual const EkigaContact *nextContact() = 0; > }; I don't like your first/next idea. If I take an XMPP roster in ekiga, connect to the same account from another program, and add a contact there, the XMPP roster will do a roster push, which your api doesn't handle. A much better approach IMNSHO, when it comes to keeping track of a list of contacts, is the following pseudo-code api : - get the current list of contacts ; - notify/signal me when a new one appears. There are two ways to handle the removing of a contact from such a list: (i) either the book tells you the contact has been removed ; (ii) or the contact itself tells you so. Both can be handled by a notification/signal. My first tests used the second way to do so, but now I think the first is better : the signal tells you both the book and the contact. > class EkigaContact > { > public: > virtual boolean hasName() const = 0; > virtual gchar *name() const = 0; > > virtual boolean hasTelephone() const = 0; > virtual gchar *telephone() const = 0; > > etc... > }; Bad. :-) First, you don't handle the case where several telephone numbers are available. Then if you begin to put /everything/ in the *base* class, that will end badly. A base class should only have the most basic capabilities, not all of them. > Comments and flames welcome. As a last comment, I will repoint the two arguments I have to prefer a GObject solution to a C++ solution : 1) the GObject will nicely live and die in the glib mainloop, so we won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere ; 2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame /dev/null). Snark From jpuydt@free.fr Wed Jun 7 14:30:54 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6C9E83B0255 for ; Wed, 7 Jun 2006 14:30:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04954-09 for ; Wed, 7 Jun 2006 14:30:52 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 15D9C3B0135 for ; Wed, 7 Jun 2006 14:30:52 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp5-g19.free.fr (Postfix) with ESMTP id E116F2766C for ; Wed, 7 Jun 2006 20:30:50 +0200 (CEST) Message-ID: <44871B92.9090703@free.fr> Date: Wed, 07 Jun 2006 20:31:46 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <4486C05B.9080200@free.fr> <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> <4486CC54.9090206@free.fr> In-Reply-To: <4486CC54.9090206@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 18:30:54 -0000 Julien PUYDT a écrit : > Plenty. Ok, here are a few. First of all, Éric convinced me the "no common class for contacts" was bad. So the main organization should probably be the following : - at the upper level, there are sources of addressbooks (avahi, e-d-s, kab, call history, xmpp...) ; - those sources give access to addressbooks ; - those addressbooks contain contacts. Now the question is detailing what is done where :-) Snark From ebischoff@nerim.net Wed Jun 7 14:33:56 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E21DC3B027D for ; Wed, 7 Jun 2006 14:33:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05177-06 for ; Wed, 7 Jun 2006 14:33:54 -0400 (EDT) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by menubar.gnome.org (Postfix) with ESMTP id 360A33B0135 for ; Wed, 7 Jun 2006 14:33:53 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 7CB2240E26 for ; Wed, 7 Jun 2006 20:33:50 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Wed, 7 Jun 2006 20:33:52 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606071543.22163.ebischoff@nerim.net> <4486F76C.7060301@free.fr> In-Reply-To: <4486F76C.7060301@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606072033.54523.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.569 tagged_above=-999 required=2 tests=[AWL=0.030, BAYES_00=-2.599] X-Spam-Score: -2.569 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 18:33:56 -0000 Le Mercredi 7 Juin 2006 17:57, Julien PUYDT a =C3=A9crit=C2=A0: > A much better approach IMNSHO, when it comes to keeping track of a list > of contacts, is the following pseudo-code api : > - get the current list of contacts ; > - notify/signal me when a new one appears. I am not sure that the Evolution, LDAP or KAddressBook drivers will all be= =20 able to wake up when a new contact is created. The contact can be created=20 asynchronously by another user on another machine on some LDAP server far=20 away on a network that is broken half of the time, for example. So even the= =20 underlying Evolution / LDAP / KAddressBook libraries might not know. =46urthermore, keeping a list all contacts in memory can have a high cost i= n=20 memory usage. > There are two ways to handle the removing of a contact from such a list: > (i) either the book tells you the contact has been removed ; > (ii) or the contact itself tells you so. > Both can be handled by a notification/signal. My first tests used the > second way to do so, but now I think the first is better : the signal > tells you both the book and the contact. Is that such a problem if the driver loops over an older version of the lis= t? > First, you don't handle the case where several telephone numbers are > available. Yeah, yeah. That was just an example. > Then if you begin to put /everything/ in the *base* class, that will end > badly. A base class should only have the most basic capabilities, not > all of them. Well, most address books are expected to deliver names and telephone=20 numbers ,-). But if you don't want to code hooks that return NULL all the=20 time for properties that do not exist (which I can understand), there's an= =20 easy and clean variant: class EkigaContact { public: enum property { name, telephone, street, ... }; virtual bool hasProperty(property p) const =3D 0; gchar *value(property p) const =3D 0; }; So contact->value(street) returns the street address and if contact->hasProperty(street) is true. > As a last comment, I will repoint the two arguments I have to prefer a > GObject solution to a C++ solution : Well, that's the kind of debate that can typically end up in a religious=20 war ;-), but: 1) why reinvent the wheel? C++ has mechanisms for object programming, it's= =20 rather strange to reimplement them in C; 2) such choices tie Ekiga more deeply into GNOME libraries (okay, it's a GN= OME=20 project. But...) > 1) the GObject will nicely live and die in the glib mainloop, so we > won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere= ; > 2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga > more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame > /dev/null). GBUS is indeed a nice invention ;-). =2D-=20 =C3=89ric From jpuydt@free.fr Wed Jun 7 15:29:48 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 91CC53B027D for ; Wed, 7 Jun 2006 15:29:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08481-05 for ; Wed, 7 Jun 2006 15:29:45 -0400 (EDT) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by menubar.gnome.org (Postfix) with ESMTP id 54DB33B0546 for ; Wed, 7 Jun 2006 15:29:45 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp2-g19.free.fr (Postfix) with ESMTP id 2EC0A6FECE for ; Wed, 7 Jun 2006 21:29:44 +0200 (CEST) Message-ID: <4487295A.9060506@free.fr> Date: Wed, 07 Jun 2006 21:30:34 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606071543.22163.ebischoff@nerim.net> <4486F76C.7060301@free.fr> <200606072033.54523.ebischoff@nerim.net> In-Reply-To: <200606072033.54523.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 19:29:48 -0000 Éric Bischoff a écrit : > Le Mercredi 7 Juin 2006 17:57, Julien PUYDT a écrit : >> A much better approach IMNSHO, when it comes to keeping track of a list >> of contacts, is the following pseudo-code api : >> - get the current list of contacts ; >> - notify/signal me when a new one appears. > > I am not sure that the Evolution, LDAP or KAddressBook drivers will all be > able to wake up when a new contact is created. The contact can be created > asynchronously by another user on another machine on some LDAP server far > away on a network that is broken half of the time, for example. So even the > underlying Evolution / LDAP / KAddressBook libraries might not know. Well, for those what I propose still works : - they get a list of contacts (and emit the "contact-added" signal for each) ; - when they are refreshed, they remove all their contacts, and get the new list of contacts. And what I propose works also for XMPP rosters, which are dynamically updated. > Furthermore, keeping a list all contacts in memory can have a high cost in > memory usage. Indeed, some books shouldn't treat "get the list of contacts" litterally. That is why they shouldn't be too stupid :-) >> There are two ways to handle the removing of a contact from such a list: >> (i) either the book tells you the contact has been removed ; >> (ii) or the contact itself tells you so. >> Both can be handled by a notification/signal. My first tests used the >> second way to do so, but now I think the first is better : the signal >> tells you both the book and the contact. > > Is that such a problem if the driver loops over an older version of the list? To do what ? It is not a problem if the list of users on ekiga.net isn't updated live. But it certainly is if your XMPP roster isn't ! >> First, you don't handle the case where several telephone numbers are >> available. > > Yeah, yeah. That was just an example. :-) >> Then if you begin to put /everything/ in the *base* class, that will end >> badly. A base class should only have the most basic capabilities, not >> all of them. > > Well, most address books are expected to deliver names and telephone > numbers ,-). But if you don't want to code hooks that return NULL all the > time for properties that do not exist (which I can understand), there's an > easy and clean variant: > class EkigaContact > { > public: > enum property { name, telephone, street, ... }; > > virtual bool hasProperty(property p) const = 0; > gchar *value(property p) const = 0; > }; Eh... this looks like GObject properties! >> As a last comment, I will repoint the two arguments I have to prefer a >> GObject solution to a C++ solution : > > Well, that's the kind of debate that can typically end up in a religious > war ;-), but: > 1) why reinvent the wheel? C++ has mechanisms for object programming, it's > rather strange to reimplement them in C; > 2) such choices tie Ekiga more deeply into GNOME libraries (okay, it's a GNOME > project. But...) glib/gobject isn't gnome. It isn't even graphical. >> 1) the GObject will nicely live and die in the glib mainloop, so we >> won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere ; >> 2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga >> more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame >> /dev/null). > > GBUS is indeed a nice invention ;-). DBUS, not GBUS. Snark From ebischoff@nerim.net Wed Jun 7 17:05:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 354B63B00A5 for ; Wed, 7 Jun 2006 17:05:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14677-05 for ; Wed, 7 Jun 2006 17:05:13 -0400 (EDT) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by menubar.gnome.org (Postfix) with ESMTP id CB5F43B0135 for ; Wed, 7 Jun 2006 17:05:12 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 1E15A437B0 for ; Wed, 7 Jun 2006 22:52:51 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Wed, 7 Jun 2006 22:53:00 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606072033.54523.ebischoff@nerim.net> <4487295A.9060506@free.fr> In-Reply-To: <4487295A.9060506@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606072253.01820.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.573 tagged_above=-999 required=2 tests=[AWL=0.026, BAYES_00=-2.599] X-Spam-Score: -2.573 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 21:05:17 -0000 Le Mercredi 7 Juin 2006 21:30, Julien PUYDT a =C3=A9crit=C2=A0: > > I am not sure that the Evolution, LDAP or KAddressBook drivers will all > > be able to wake up when a new contact is created. The contact can be > > created asynchronously by another user on another machine on some LDAP > > server far away on a network that is broken half of the time, for > > example. So even the underlying Evolution / LDAP / KAddressBook librari= es > > might not know. > > Well, for those what I propose still works : > - they get a list of contacts (and emit the "contact-added" signal for > each) ; > - when they are refreshed, they remove all their contacts, and get the > new list of contacts. What makes you think that they get "refreshed" at some point? > And what I propose works also for XMPP rosters, which are dynamically > updated. Promise, I will look someday what a "XMPP roster" is ;-). > > Furthermore, keeping a list all contacts in memory can have a high cost > > in memory usage. > > Indeed, some books shouldn't treat "get the list of contacts" > litterally. That is why they shouldn't be too stupid :-) Then you must some kind of evolved caching mechanism in your driver. That's= =20 sounds overcomplicated and hard to code to me. If you simply loop through t= he=20 contacts, you can just get the information you need and display it. > > Is that such a problem if the driver loops over an older version of the > > list? > > To do what ? It is not a problem if the list of users on ekiga.net isn't > updated live. But it certainly is if your XMPP roster isn't ! If you convinced me of one thing, it's that I need to look at the definitio= n=20 of these SNMP toasters ;-). > > class EkigaContact > > { > > public: > > enum property { name, telephone, street, ... }; > > > > virtual bool hasProperty(property p) const =3D 0; > > gchar *value(property p) const =3D 0; > > }; > > Eh... this looks like GObject properties! Indeed! Excepted that you are just using the possibilities of the programmi= ng=20 language, not of some library. At this point, I must do some clarification: I am a newcomer to Ekiga and perfectly aware of the fact that I might ignor= e a=20 lot of things about the past and the possible future of this software. I am= a=20 complete ignorant of GNOME and its libraries. I do not know anything about= =20 the multithreading problems that Julien has to deal with. I am not here to= =20 slow down Julien, nor to get my views adopted. I will be more than happy to= =20 adapt my code to *any* API that Julien will bring up. And to shut my big=20 mouth up if anyone ask me to ;-). > glib/gobject isn't gnome. It isn't even graphical. Okay, to me who comes from the KDE world, it's the same thing, it starts wi= th=20 "g" ;-). > > GBUS is indeed a nice invention ;-). > > DBUS, not GBUS. Yes, sorry for the many typos... :-/ =2D-=20 =C3=89ric From jan.schampera@web.de Wed Jun 7 23:13:06 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7395E3B043B for ; Wed, 7 Jun 2006 23:13:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02368-03 for ; Wed, 7 Jun 2006 23:13:03 -0400 (EDT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by menubar.gnome.org (Postfix) with ESMTP id 6D4823B012E for ; Wed, 7 Jun 2006 23:13:03 -0400 (EDT) Received: from fwd35.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1FoAxC-0004rd-00; Thu, 08 Jun 2006 05:13:02 +0200 Received: from mail.home.thebonsai.de (Z2ab0kZBZewL1AHEQWezyBxMlAJSeayZbCOT8jbF9IKQFlf7QKn1Ul@[84.147.102.15]) by fwd35.sul.t-online.de with esmtp id 1FoAx4-1YpxqK0; Thu, 8 Jun 2006 05:12:54 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id 8DF136B173 for ; Thu, 8 Jun 2006 05:12:52 +0200 (CEST) Date: Thu, 8 Jun 2006 05:08:28 +0200 From: Jan Schampera To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Message-ID: <20060608050828.37d3ac08@localhost.localdomain> In-Reply-To: <200606072253.01820.ebischoff@nerim.net> References: <4486BDD0.9050805@free.fr> <200606072033.54523.ebischoff@nerim.net> <4487295A.9060506@free.fr> <200606072253.01820.ebischoff@nerim.net> Organization: private X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-ID: Z2ab0kZBZewL1AHEQWezyBxMlAJSeayZbCOT8jbF9IKQFlf7QKn1Ul@t-dialin.net X-TOI-MSGID: c2323eec-2b6b-468d-b9e5-6ee93ecdce82 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.971 tagged_above=-999 required=2 tests=[AWL=0.627, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.971 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 03:13:06 -0000 On Wed, 7 Jun 2006 22:53:00 +0200 =C3=89ric Bischoff wrote: > (GLib vs OOP) > Indeed! Excepted that you are just using the possibilities of the > programming language, not of some library. Please note, regardless all other arguments, that an own C++-object system will be totally independant of the used framework. In case we leave GTK and GLib some day, the OOP approach won't need any changes. The GObject approach would need either an equivalent in the new framework, or a rewrite to (finally) OOP. Beside that, I tend to say "a matter of taste". J. --=20 dreaming in digital living in realtime thinking in binary talking in IP WELCOME TO OUR WORLD From jpuydt@free.fr Thu Jun 8 04:39:27 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8DA623B05CC for ; Thu, 8 Jun 2006 04:39:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19858-03 for ; Thu, 8 Jun 2006 04:39:24 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id D38EA3B0E0F for ; Thu, 8 Jun 2006 04:39:23 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp6-g19.free.fr (Postfix) with ESMTP id A778922647 for ; Thu, 8 Jun 2006 10:39:22 +0200 (CEST) Message-ID: <4487E272.80605@free.fr> Date: Thu, 08 Jun 2006 10:40:18 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606072033.54523.ebischoff@nerim.net> <4487295A.9060506@free.fr> <200606072253.01820.ebischoff@nerim.net> In-Reply-To: <200606072253.01820.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 08:39:27 -0000 Éric Bischoff a écrit : > Le Mercredi 7 Juin 2006 21:30, Julien PUYDT a écrit : >>> I am not sure that the Evolution, LDAP or KAddressBook drivers will all >>> be able to wake up when a new contact is created. The contact can be >>> created asynchronously by another user on another machine on some LDAP >>> server far away on a network that is broken half of the time, for >>> example. So even the underlying Evolution / LDAP / KAddressBook libraries >>> might not know. >> Well, for those what I propose still works : >> - they get a list of contacts (and emit the "contact-added" signal for >> each) ; >> - when they are refreshed, they remove all their contacts, and get the >> new list of contacts. > > What makes you think that they get "refreshed" at some point? The user triggers the "refresh" action :-) >> And what I propose works also for XMPP rosters, which are dynamically >> updated. > > Promise, I will look someday what a "XMPP roster" is ;-). Perhaps you know what a "jabber roster" is? http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html >>> Furthermore, keeping a list all contacts in memory can have a high cost >>> in memory usage. >> Indeed, some books shouldn't treat "get the list of contacts" >> litterally. That is why they shouldn't be too stupid :-) > > Then you must some kind of evolved caching mechanism in your driver. That's > sounds overcomplicated and hard to code to me. If you simply loop through the > contacts, you can just get the information you need and display it. I don't think a trivial proxying counts as an "evolved caching mechanism" :-) >>> Is that such a problem if the driver loops over an older version of the >>> list? >> To do what ? It is not a problem if the list of users on ekiga.net isn't >> updated live. But it certainly is if your XMPP roster isn't ! > > If you convinced me of one thing, it's that I need to look at the definition > of these SNMP toasters ;-). Who's toast ? ;-) >>> class EkigaContact >>> { >>> public: >>> enum property { name, telephone, street, ... }; >>> >>> virtual bool hasProperty(property p) const = 0; >>> gchar *value(property p) const = 0; >>> }; >> Eh... this looks like GObject properties! > > Indeed! Excepted that you are just using the possibilities of the programming > language, not of some library. Can you add properties to the enum when inheriting ? > At this point, I must do some clarification: > > I am a newcomer to Ekiga and perfectly aware of the fact that I might ignore a > lot of things about the past and the possible future of this software. I am a > complete ignorant of GNOME and its libraries. I do not know anything about > the multithreading problems that Julien has to deal with. I am not here to > slow down Julien, nor to get my views adopted. I will be more than happy to > adapt my code to *any* API that Julien will bring up. And to shut my big > mouth up if anyone ask me to ;-). Yes, yes, no problem. I'm happy to have feedback :-) >> glib/gobject isn't gnome. It isn't even graphical. > > Okay, to me who comes from the KDE world, it's the same thing, it starts with > "g" ;-). glib, gobject & gtk+ already make ekiga run on win32. >>> GBUS is indeed a nice invention ;-). >> DBUS, not GBUS. > > Yes, sorry for the many typos... :-/ Eh... that one was pretty bad for someone who has something against g-letter words ;-) Snark From ebischoff@nerim.net Thu Jun 8 04:49:09 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DA33D3B013D for ; Thu, 8 Jun 2006 04:49:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20394-06 for ; Thu, 8 Jun 2006 04:49:08 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id 682F73B05A7 for ; Thu, 8 Jun 2006 04:49:07 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 6666B41095 for ; Thu, 8 Jun 2006 10:49:06 +0200 (CEST) From: =?iso-8859-15?q?=C9ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 10:49:15 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <20060608050828.37d3ac08@localhost.localdomain> In-Reply-To: <20060608050828.37d3ac08@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606081049.16046.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.577 tagged_above=-999 required=2 tests=[AWL=0.022, BAYES_00=-2.599] X-Spam-Score: -2.577 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 08:49:10 -0000 Le Jeudi 8 Juin 2006 05:08, Jan Schampera a =E9crit=A0: > > Indeed! Excepted that you are just using the possibilities of the > > programming language, not of some library. > > Please note, regardless all other arguments, that an own C++-object > system will be totally independant of the used framework. In case we > leave GTK and GLib some day, the OOP approach won't need any changes. > > The GObject approach would need either an equivalent in the new > framework, or a rewrite to (finally) OOP. Yes. That was precisely my point. > Beside that, I tend to say "a matter of taste". Yes. Sometimes programming has to do with aesthetics. Compare: =3D=3D=3D GObject way =3D=3D=3D struct _GmBook { GObject parent; }; struct _GmBookClass { GObjectClass parent; const gchar *(*get_name)(GmBook *self); }; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D with: =3D=3D=3D C++ way =3D=3D=3D class GmBook { public: virtual get_name() const; } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D My tastes tell me that second code, besides from being much shorter, has mo= re=20 "beauty" than the first one. But as you say, tastes are a very personal=20 thing. =2D-=20 =C9ric From jpuydt@free.fr Thu Jun 8 05:09:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C38A43B04E8 for ; Thu, 8 Jun 2006 05:09:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21821-03 for ; Thu, 8 Jun 2006 05:09:15 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 32ECF3B0505 for ; Thu, 8 Jun 2006 05:09:15 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp5-g19.free.fr (Postfix) with ESMTP id BD9EA275B9 for ; Thu, 8 Jun 2006 11:09:13 +0200 (CEST) Message-ID: <4487E971.8070602@free.fr> Date: Thu, 08 Jun 2006 11:10:09 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <20060608050828.37d3ac08@localhost.localdomain> <200606081049.16046.ebischoff@nerim.net> In-Reply-To: <200606081049.16046.ebischoff@nerim.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 09:09:16 -0000 Éric Bischoff a écrit : > Le Jeudi 8 Juin 2006 05:08, Jan Schampera a écrit : >>> Indeed! Excepted that you are just using the possibilities of the >>> programming language, not of some library. >> Please note, regardless all other arguments, that an own C++-object >> system will be totally independant of the used framework. In case we >> leave GTK and GLib some day, the OOP approach won't need any changes. >> >> The GObject approach would need either an equivalent in the new >> framework, or a rewrite to (finally) OOP. > > Yes. That was precisely my point. > >> Beside that, I tend to say "a matter of taste". > > Yes. Sometimes programming has to do with aesthetics. Compare: > > === GObject way === > struct _GmBook { > GObject parent; > }; > > struct _GmBookClass { > GObjectClass parent; > > const gchar *(*get_name)(GmBook *self); > }; > ================== > > with: > > === C++ way === > class GmBook { > public: > virtual get_name() const; > } > ================== > > My tastes tell me that second code, besides from being much shorter, has more > "beauty" than the first one. But as you say, tastes are a very personal > thing. My experience is that when it comes to export the object on DBUS, you're better off with a gobject than with a C++ object. One has some introspection, the other doesn't. I prefer working a little harder upfront, then have an easy life, than writing easy code then feel miserable :-) Snark From ebischoff@nerim.net Thu Jun 8 05:22:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C67273B0598 for ; Thu, 8 Jun 2006 05:22:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22528-04 for ; Thu, 8 Jun 2006 05:22:07 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id D66F33B0B13 for ; Thu, 8 Jun 2006 05:22:06 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 4966F40FBF for ; Thu, 8 Jun 2006 11:22:05 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 11:22:09 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <4487E272.80605@free.fr> In-Reply-To: <4487E272.80605@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606081122.11835.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.579 tagged_above=-999 required=2 tests=[AWL=0.020, BAYES_00=-2.599] X-Spam-Score: -2.579 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 09:22:11 -0000 Le Jeudi 8 Juin 2006 10:40, Julien PUYDT a =C3=A9crit=C2=A0: > > What makes you think that they get "refreshed" at some point? > > The user triggers the "refresh" action :-) Then you loop again through the address book contacts ;-). No need to keep = a=20 copy of the contacts for that. > > Promise, I will look someday what a "XMPP roster" is ;-). > > Perhaps you know what a "jabber roster" is? > http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html No, and this article does not contain the word "roster" :-(. > > Then you must some kind of evolved caching mechanism in your driver. > > That's sounds overcomplicated and hard to code to me. If you simply loop > > through the contacts, you can just get the information you need and > > display it. > > I don't think a trivial proxying counts as an "evolved caching > mechanism" :-) I told you in private that I had a very lazy concept of programming ;-). > Who's toast ? ;-) ;-). > Can you add properties to the enum when inheriting ? Yes: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D class Repas { public: enum plat { nouilles, riz, patates, pain }; virtual void mange(plat p) =3D 0; }; class BonRepas : public Repas { public: enum bonPlat { caviar =3D pain + 1, langouste, foiegras, saumon }; virtual void mange(plat p); }; void BonRepas::mange(plat p) { if ((bonPlat) p =3D=3D langouste) printf("Miam!\n"); } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D With anonymous enums you should even be able to get rid of the casts. But=20 named enums make the code clearer. > Yes, yes, no problem. I'm happy to have feedback :-) Thanks for your openess, Julien :-). > glib, gobject & gtk+ already make ekiga run on win32. I know. But I think it is always good to remove references to libraries if = you=20 do not really need them. > Eh... that one was pretty bad for someone who has something against > g-letter words ;-) I have nothing against, I am just ignorant ;-). =2D-=20 =C3=89ric From conrad_videokonferenz@gmx.de Thu Jun 8 06:04:43 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7A1F63B0CF2 for ; Thu, 8 Jun 2006 06:04:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24863-06 for ; Thu, 8 Jun 2006 06:04:41 -0400 (EDT) Received: from vz17136.evanzo-server.de (vz17136.evanzo-server.de [62.140.17.136]) by menubar.gnome.org (Postfix) with ESMTP id E081B3B05CC for ; Thu, 8 Jun 2006 06:04:40 -0400 (EDT) Received: from c133075.adsl.hansenet.de (c133075.adsl.hansenet.de [213.39.133.75]) (authenticated bits=0) by vz17136.evanzo-server.de (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id k58A4cTf030082 for ; Thu, 8 Jun 2006 12:04:39 +0200 From: Conrad Beckert To: gnomemeeting-devel-list@gnome.org Date: Thu, 8 Jun 2006 10:02:37 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606081002.37875.conrad_videokonferenz@gmx.de> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.106 tagged_above=-999 required=2 tests=[AWL=-1.138, BAYES_05=-1.11, SPF_FAIL=1.142] X-Spam-Score: -1.106 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 10:04:45 -0000 Hi, has anybody an idea where the Debian packages for Ekiga 2.0.2 (or the corresponding CVS versions) are? The last version I can install using apt-get a couple of days old (May 25 - or somethin) - at least this is a version with the nonfunctional German locale. (defaults to English) What's up? Conrad From jpuydt@free.fr Thu Jun 8 06:59:27 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 483C83B0ED8 for ; Thu, 8 Jun 2006 06:59:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27917-10 for ; Thu, 8 Jun 2006 06:59:15 -0400 (EDT) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by menubar.gnome.org (Postfix) with ESMTP id 1C5223B0630 for ; Thu, 8 Jun 2006 06:59:12 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp4-g19.free.fr (Postfix) with ESMTP id A681254974 for ; Thu, 8 Jun 2006 12:59:10 +0200 (CEST) Message-ID: <44880335.3060401@free.fr> Date: Thu, 08 Jun 2006 13:00:05 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <4487E272.80605@free.fr> <200606081122.11835.ebischoff@nerim.net> In-Reply-To: <200606081122.11835.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 10:59:27 -0000 Éric Bischoff a écrit : > Le Jeudi 8 Juin 2006 10:40, Julien PUYDT a écrit : >>> What makes you think that they get "refreshed" at some point? >> The user triggers the "refresh" action :-) > > Then you loop again through the address book contacts ;-). No need to keep a > copy of the contacts for that. You will need to keep a copy to show them to the user anyway. And notice that a same contact could be shown at several places through the user interface! >>> Promise, I will look someday what a "XMPP roster" is ;-). >> Perhaps you know what a "jabber roster" is? >> http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html > > No, and this article does not contain the word "roster" :-(. The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish them from 'live' contacts. The situation is that you may have jc@jabber.lat in your roster, with the information that the name is "Julius Caesar", and belongs to the groups "Politicians" and "Jokers". But when he connects from his pda, he will show up as jc@jabber.lat/pda, and will neither be able to do VoIP, nor receive XHTML messages. When he is home, he connects from his computer as jc@jabber.lat/home, and will be able to do both. Now he goes to work, from where he shows up as jc@jabber.lat/work, which can do XHTML messaging, but not VoIP. >> Yes, yes, no problem. I'm happy to have feedback :-) > > Thanks for your openess, Julien :-). No problem. More brains means better solutions :-) >> glib, gobject & gtk+ already make ekiga run on win32. > > I know. But I think it is always good to remove references to libraries if you > do not really need them. Well, glib is nice. The main problem KDE problem have with it is that it begins with a 'g' and is already used in GNOME. :-) Snark From ebischoff@nerim.net Thu Jun 8 09:37:50 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CE2BD3B03A6 for ; Thu, 8 Jun 2006 09:37:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08027-03 for ; Thu, 8 Jun 2006 09:37:49 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id 549EB3B0622 for ; Thu, 8 Jun 2006 09:37:48 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 1D58441027 for ; Thu, 8 Jun 2006 15:37:45 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 15:37:53 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606081122.11835.ebischoff@nerim.net> <44880335.3060401@free.fr> In-Reply-To: <44880335.3060401@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606081537.55137.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.504 tagged_above=-999 required=2 tests=[AWL=-0.059, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077] X-Spam-Score: -2.504 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 13:37:51 -0000 Le Jeudi 8 Juin 2006 13:00, Julien PUYDT a =C3=A9crit=C2=A0: > > Then you loop again through the address book contacts ;-). No need to > > keep a copy of the contacts for that. > > You will need to keep a copy to show them to the user anyway. Keeping contacts in memory is not the same at all as keeping an image of wh= at=20 Ekiga has to display of them. The GUI needs basically a list of strings to= =20 display, not the potentially complex data structure of an address book=20 contact. Having one of these complex structures in memory at a time is enough IMHO. Should it be only for performance reasons: when the user scrolls down the l= ist=20 by one contact, it is much quicker to retreive data from a prepared list of= =20 strings than from the contact itself. > And notice=20 > that a same contact could be shown at several places through the user > interface! Yes, and perharps displayed in different ways. > > No, and this article does not contain the word "roster" :-(. > > The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish > them from 'live' contacts. > > The situation is that you may have jc@jabber.lat in your roster, with > the information that the name is "Julius Caesar", and belongs to the > groups "Politicians" and "Jokers". But when he connects from his pda, he > will show up as jc@jabber.lat/pda, and will neither be able to do VoIP, > nor receive XHTML messages. When he is home, he connects from his > computer as jc@jabber.lat/home, and will be able to do both. Now he goes > to work, from where he shows up as jc@jabber.lat/work, which can do > XHTML messaging, but not VoIP. Aha. > > Thanks for your openess, Julien :-). > > No problem. More brains means better solutions :-) Yes, indeed. I hope my advice brings something constructive. As I told you = in=20 private, you keep it or throw it, it's your decision. > > I know. But I think it is always good to remove references to libraries > > if you do not really need them. > > Well, glib is nice. The main problem KDE problem have with it is that it > begins with a 'g' and is already used in GNOME. :-) Do not believe that. We are not religious people. For example, we are very= =20 happy sharing libxml with GNOME. Even though there is already a XML API in= =20 Qt! Just because libxml rocks... (oh yeah, there's no "g" in libxml... ;-) ) We already share libxml, desktop files, DocBook documentation, DBUS=20 communication, po translation memories, and many, many other things. Cool=20 apps like Ekiga can run in a KDE environment. Cool apps like ... errr...=20 KEuroCalc ;-) can run in a GNOME environment. And in fact I know that many= =20 people do that. In fact, the more we will be able to share with you, the happier we will be= =2E I=20 can ensure you that this has always been what we said, even during private= =20 discussions at KDE meetings. I do not know why we do not share glib. I have my ideas about that, but it'= s=20 just personal assumptions ;-). =2D-=20 =C3=89ric From jpuydt@free.fr Thu Jun 8 15:02:29 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6459F3B0F68 for ; Thu, 8 Jun 2006 15:02:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30195-09 for ; Thu, 8 Jun 2006 15:02:28 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id 1D6653B035A for ; Thu, 8 Jun 2006 15:02:28 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp6-g19.free.fr (Postfix) with ESMTP id A118022783 for ; Thu, 8 Jun 2006 21:02:23 +0200 (CEST) Message-ID: <4488747B.6080906@free.fr> Date: Thu, 08 Jun 2006 21:03:23 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606081122.11835.ebischoff@nerim.net> <44880335.3060401@free.fr> <200606081537.55137.ebischoff@nerim.net> In-Reply-To: <200606081537.55137.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.512 tagged_above=-999 required=2 tests=[AWL=-0.067, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077] X-Spam-Score: -2.512 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:02:29 -0000 Éric Bischoff a écrit : >> You will need to keep a copy to show them to the user anyway. > > Keeping contacts in memory is not the same at all as keeping an image of what > Ekiga has to display of them. The GUI needs basically a list of strings to > display, not the potentially complex data structure of an address book > contact. > > Having one of these complex structures in memory at a time is enough IMHO. Not at all. And it won't allow you to update informations like presence easily. > Should it be only for performance reasons: when the user scrolls down the list > by one contact, it is much quicker to retreive data from a prepared list of > strings than from the contact itself. The contact isn't that much more than strings... >> And notice >> that a same contact could be shown at several places through the user >> interface! > > Yes, and perharps displayed in different ways. Yes, that too. >>> No, and this article does not contain the word "roster" :-(. >> The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish >> them from 'live' contacts. >> >> The situation is that you may have jc@jabber.lat in your roster, with >> the information that the name is "Julius Caesar", and belongs to the >> groups "Politicians" and "Jokers". But when he connects from his pda, he >> will show up as jc@jabber.lat/pda, and will neither be able to do VoIP, >> nor receive XHTML messages. When he is home, he connects from his >> computer as jc@jabber.lat/home, and will be able to do both. Now he goes >> to work, from where he shows up as jc@jabber.lat/work, which can do >> XHTML messaging, but not VoIP. > > Aha. Yes, it's that bad :-/ >>> Thanks for your openess, Julien :-). >> No problem. More brains means better solutions :-) > > Yes, indeed. I hope my advice brings something constructive. As I told you in > private, you keep it or throw it, it's your decision. Last time you wrote that I ended throwing both your ideas and mines ;-) >>> I know. But I think it is always good to remove references to libraries >>> if you do not really need them. >> Well, glib is nice. The main problem KDE problem have with it is that it >> begins with a 'g' and is already used in GNOME. :-) > > Do not believe that. We are not religious people. For example, we are very > happy sharing libxml with GNOME. Even though there is already a XML API in > Qt! Just because libxml rocks... > > (oh yeah, there's no "g" in libxml... ;-) ) > > We already share libxml, desktop files, DocBook documentation, DBUS > communication, po translation memories, and many, many other things. Cool > apps like Ekiga can run in a KDE environment. Cool apps like ... errr... > KEuroCalc ;-) can run in a GNOME environment. And in fact I know that many > people do that. What is KEuroCalc ? > In fact, the more we will be able to share with you, the happier we will be. I > can ensure you that this has always been what we said, even during private > discussions at KDE meetings. This is why it's so important to have a good DBUS component. And this is made easier by using glib-object :-) > I do not know why we do not share glib. I have my ideas about that, but it's > just personal assumptions ;-). I can make a few guesses : 1) it does things that QT does ; 2) it does things that C++ STL does. Snark From ebischoff@nerim.net Thu Jun 8 15:38:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D9F313B054E for ; Thu, 8 Jun 2006 15:38:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32745-08 for ; Thu, 8 Jun 2006 15:38:37 -0400 (EDT) Received: from mallaury.nerim.net (smtp-104-thursday.noc.nerim.net [62.4.17.104]) by menubar.gnome.org (Postfix) with ESMTP id 3976E3B000E for ; Thu, 8 Jun 2006 15:38:35 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by mallaury.nerim.net (Postfix) with ESMTP id 1ED2F4F3A4 for ; Thu, 8 Jun 2006 21:38:22 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 21:38:46 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606081537.55137.ebischoff@nerim.net> <4488747B.6080906@free.fr> In-Reply-To: <4488747B.6080906@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606082138.46648.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.576 tagged_above=-999 required=2 tests=[AWL=0.023, BAYES_00=-2.599] X-Spam-Score: -2.576 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:38:40 -0000 Le Jeudi 8 Juin 2006 21:03, Julien PUYDT a =C3=A9crit=C2=A0: > > We already share libxml, desktop files, DocBook documentation, DBUS > > communication, po translation memories, and many, many other things. Co= ol > > apps like Ekiga can run in a KDE environment. Cool apps like ... errr... > > KEuroCalc ;-) can run in a GNOME environment. And in fact I know that > > many people do that. > > What is KEuroCalc ? Mentioning it was merely a joke: it's a small KDE app that I wrote. http://opensource.bureau-cornavin.com/keurocalc/ ;-) > > I do not know why we do not share glib. I have my ideas about that, but > > it's just personal assumptions ;-). > > I can make a few guesses : > 1) it does things that QT does ; > 2) it does things that C++ STL does. Exactly the same guesses as me ;-). It even does things that C++ _alone_ do= es. Best, =2D-=20 =C3=89ric From ph.l@libertysurf.fr Thu Jun 8 15:47:49 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9705F3B1039 for ; Thu, 8 Jun 2006 15:47:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00870-02 for ; Thu, 8 Jun 2006 15:47:38 -0400 (EDT) Received: from smtp4.mail.easynet.fr (smarthost169.mail.easynet.fr [212.180.1.169]) by menubar.gnome.org (Postfix) with ESMTP id 527163B1020 for ; Thu, 8 Jun 2006 15:47:35 -0400 (EDT) Received: from asi-236.asi256ip.easynet.fr ([212.180.39.236] helo=[145.111.24.1]) by smtp4.mail.easynet.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FoQUy-0004IP-Fg for gnomemeeting-devel-list@gnome.org; Thu, 08 Jun 2006 21:48:56 +0200 Message-ID: <44887ECE.9040902@libertysurf.fr> Date: Thu, 08 Jun 2006 21:47:26 +0200 From: Philippe Lefevre User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: gnomemeeting-devel-list@gnome.org References: <20060608160031.473BF3B0FB3@menubar.gnome.org> In-Reply-To: <20060608160031.473BF3B0FB3@menubar.gnome.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.436 tagged_above=-999 required=2 tests=[AWL=-0.853, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, TW_BX=0.077, TW_IB=0.077, TW_RW=0.077, TW_WX=0.077] X-Spam-Score: -1.436 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ekiga under windows X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ph.l@libertysurf.fr, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:47:49 -0000 Hello, Today I tried to install ekiga on my PC under XP and I never get anything to work :'( You'll find bellow what I did. I can do some other tests if it may in any help. PhiL My PC is running Windows XP SP1 1G memory. I installed GTK 2.0 (version 2.8.9.0) installed under C:\Program Files\Fichiers communs\GTK\2.0 and Ekiga (downloaded from CVS June 8, 2006) installed under C:\Program Files\Ekiga CYGWIN and MSYS are installed too with XP : nothing happen, no log (empty file even with -d 4 option) with MSYS : same issue $ echo $PATH .:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32: /c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/oracle9/bin:/c/oracle8/bin: /i/progicil/orawin2:/i/progicil/orawin2/bin: /c/Program Files/Microsoft SQL Server/80/Tools/BINN: /c/Program Files/Fichiers communs/GTK/2.0/bin:/c/php5: /c/php5/ext:/c/Program Files/MySQL/MySQL Server 5.0/bin: /c/bin:/c/cygdrive/c/cygwin/bin:/c/cygdrive/c/cygwin/sbin:/c/oracle9/bin: /c/oracle8/bin:/i/progicil/orawin2:/i/progicil/orawin2/bin: /c/Program Files/Ekiga:/c/caml/bin PHL@BORG /c/program files/ekiga $ ./ekiga.exe 1>log 2>&1 Log is empty $ ls -rwxr-xr-x 1 PHL Administ 7934464 May 16 05:26 ekiga.exe -rw-r--r-- 1 PHL Administ 1231950 May 16 05:26 ekiga.schemas -rwxr-xr-x 1 PHL Administ 44032 May 16 05:26 liblber.dll -rwxr-xr-x 1 PHL Administ 188416 May 16 05:26 libldap_r.dll -rwxr-xr-x 1 PHL Administ 1276928 May 16 05:26 libxml2-2.dll drwxr-xr-x 70 PHL Administ 0 Jun 8 09:52 locale -rw-r--r-- 1 PHL Administ 0 Jun 8 13:30 log Using GDB in a cygdrive environment : $ gdb ekiga.exe GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) (gdb) run Starting program: /cygdrive/c/Program Files/Ekiga/ekiga.exe Program received signal SIGSEGV, Segmentation fault. Program received signal SIGSEGV, Segmentation fault. Program exited with code 0200. You can't do that without a process to debug. (gdb) bt No stack. (gdb) From jpuydt@free.fr Thu Jun 8 15:50:47 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 143943B027F for ; Thu, 8 Jun 2006 15:50:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01017-01 for ; Thu, 8 Jun 2006 15:50:46 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id E67403B021A for ; Thu, 8 Jun 2006 15:50:45 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp3-g19.free.fr (Postfix) with ESMTP id C567B4901D; Thu, 8 Jun 2006 21:50:43 +0200 (CEST) Message-ID: <44887FCD.7040300@free.fr> Date: Thu, 08 Jun 2006 21:51:41 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: ph.l@libertysurf.fr, GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Ekiga under windows References: <20060608160031.473BF3B0FB3@menubar.gnome.org> <44887ECE.9040902@libertysurf.fr> In-Reply-To: <44887ECE.9040902@libertysurf.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.434 tagged_above=-999 required=2 tests=[AWL=-0.143, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077, TW_RW=0.077, TW_WX=0.077] X-Spam-Score: -2.434 X-Spam-Level: Cc: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:50:47 -0000 Philippe Lefevre a écrit : > Today I tried to install ekiga on my PC under XP and I never get > anything to work :'( Yes, we don't have a nice installer yet. > I installed GTK 2.0 (version 2.8.9.0) installed under > C:\Program Files\Fichiers communs\GTK\2.0 I'm wondering if that is recent enough. > CYGWIN and MSYS are installed too Unnecessary. > $ ls > -rwxr-xr-x 1 PHL Administ 7934464 May 16 05:26 ekiga.exe > -rw-r--r-- 1 PHL Administ 1231950 May 16 05:26 ekiga.schemas > -rwxr-xr-x 1 PHL Administ 44032 May 16 05:26 liblber.dll > -rwxr-xr-x 1 PHL Administ 188416 May 16 05:26 libldap_r.dll > -rwxr-xr-x 1 PHL Administ 1276928 May 16 05:26 libxml2-2.dll > drwxr-xr-x 70 PHL Administ 0 Jun 8 09:52 locale > -rw-r--r-- 1 PHL Administ 0 Jun 8 13:30 log No libSDL.dll or some such ? :-/ Snark From ph.l@libertysurf.fr Thu Jun 8 16:43:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 40F853B00EA for ; Thu, 8 Jun 2006 16:43:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04211-07 for ; Thu, 8 Jun 2006 16:43:38 -0400 (EDT) Received: from smtp3.mail.easynet.fr (smarthost168.mail.easynet.fr [212.180.1.168]) by menubar.gnome.org (Postfix) with ESMTP id 52BD23B000E for ; Thu, 8 Jun 2006 16:43:37 -0400 (EDT) Received: from asi-236.asi256ip.easynet.fr ([212.180.39.236] helo=[145.111.24.1]) by smtp3.mail.easynet.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FoRMF-0007kr-6F; Thu, 08 Jun 2006 22:43:59 +0200 Message-ID: <44888BF6.8020906@libertysurf.fr> Date: Thu, 08 Jun 2006 22:43:34 +0200 From: Philippe Lefevre User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: Julien PUYDT , gnomemeeting-devel-list@gnome.org References: <20060608160031.473BF3B0FB3@menubar.gnome.org> <44887ECE.9040902@libertysurf.fr> <44887FCD.7040300@free.fr> In-Reply-To: <44887FCD.7040300@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.283 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077, TW_RW=0.077, TW_WX=0.077] X-Spam-Score: -2.283 X-Spam-Level: Cc: Subject: [GnomeMeeting-devel-list] Re : Ekiga under windows X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ph.l@libertysurf.fr, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 20:43:39 -0000 Julien PUYDT a écrit : > Philippe Lefevre a écrit : > >> Today I tried to install ekiga on my PC under XP and I never get >> anything to work :'( > > > Yes, we don't have a nice installer yet. No pb, unzip works well for now. > >> I installed GTK 2.0 (version 2.8.9.0) installed under >> C:\Program Files\Fichiers communs\GTK\2.0 > > > I'm wondering if that is recent enough. > 2.8.9.0 is the latest stable version but there is a 2.8.15 too dated from March (still unstable ?) >> CYGWIN and MSYS are installed too > > > Unnecessary. > Of course. It's just to use dbg. (I installed it for other things anyway) >> $ ls >> -rwxr-xr-x 1 PHL Administ 7934464 May 16 05:26 ekiga.exe >> -rw-r--r-- 1 PHL Administ 1231950 May 16 05:26 ekiga.schemas >> -rwxr-xr-x 1 PHL Administ 44032 May 16 05:26 liblber.dll >> -rwxr-xr-x 1 PHL Administ 188416 May 16 05:26 libldap_r.dll >> -rwxr-xr-x 1 PHL Administ 1276928 May 16 05:26 libxml2-2.dll >> drwxr-xr-x 70 PHL Administ 0 Jun 8 09:52 locale >> -rw-r--r-- 1 PHL Administ 0 Jun 8 13:30 log > > > No libSDL.dll or some such ? :-/ > Sorry I don't think so. I will check tomorrow (it is on my PC at work) But, I just check the zip file... there is no libSDL (or name close to that) into it. > Snark > Thanks Julien. From mcquaidster@gmail.com Thu Jun 8 17:09:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DF4253B0622 for ; Thu, 8 Jun 2006 17:09:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05835-02 for ; Thu, 8 Jun 2006 17:09:06 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id 76D583B0F9D for ; Thu, 8 Jun 2006 17:09:06 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id z74so693545pyg for ; Thu, 08 Jun 2006 14:09:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=HVNAtak5n7Z91wpmXr/Qu5ON4YhH7Q4dCf+4y5GUbTwwY23VOAXrmjBMj7263bIU8fqFePgmvS6HIFqN59D2Jy6YmXM2xD1V+aMpky/Ed9jdEhbQxbJYZUEi6YN6vk99BkQspxK0SEsZWjsxDvHu3Rk9O5hKBW5HcpVNrhkyGCo= Received: by 10.35.63.2 with SMTP id q2mr2928428pyk; Thu, 08 Jun 2006 14:09:05 -0700 (PDT) Received: by 10.35.31.2 with HTTP; Thu, 8 Jun 2006 14:09:05 -0700 (PDT) Message-ID: <58a398810606081409o3026d11cnd9f5f3a16b0243e@mail.gmail.com> Date: Thu, 8 Jun 2006 17:09:05 -0400 From: "mcquaid mcquaid" To: "GnomeMeeting development mailing list" In-Reply-To: <58a398810606061625x7684427q73db38225fa398dc@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10127_1193274.1149800945207" References: <58a398810606061625x7684427q73db38225fa398dc@mail.gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.359 tagged_above=-999 required=2 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.359 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Re: no audio on incoming calls. X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 21:09:10 -0000 ------=_Part_10127_1193274.1149800945207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Can I get any assistance on this or is there something else I should be providing? I can get other voip apps like linphone working but I can't get ekiga to transmit audio either way on incoming calls. Not sure if it's any help but asterisk seems to behave in the same manner. With asterisk I again could make outgoing call fine, but for incoming it would route calls to my local sipphone, but no audio either way. On 6/6/06, mcquaid mcquaid wrote: > > I have tried ekiga from time to time, and now using the latest cvs, I > still have the same problem. > > On outgoing calls, audio transmits both ways without issue. > > When receiving a call, no audio is transmitted either way. > > I realize it'll probably be considered a firewall issue, but linphone has > always worked for me and I have never setup stun or a nat traversal method > in linphone. I'd prefer to use ekiga instead of linphone. > > Here is the output of an incoming call that lasts until ekiga reports > 'remote user cleared the call'. > > I tried ekiga lastest cvs as I read about 2.02 hoping this might have been > resolved. > > > > ------=_Part_10127_1193274.1149800945207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Can I get any assistance on this or is there something else I should be providing?  I can get other voip apps like linphone working but I can't get ekiga to transmit audio either way on incoming calls.  Not sure if it's any help but asterisk seems to behave in the same manner.  With asterisk I again could make outgoing call fine, but for incoming it would route calls to my local sipphone, but no audio either way.

On 6/6/06, mcquaid mcquaid <mcquaidster@gmail.com> wrote:
I have tried ekiga from time to time, and now using the latest cvs, I still have the same problem.

On outgoing calls, audio transmits both ways without issue.

When receiving a call, no audio is transmitted either way.

I realize it'll probably be considered a firewall issue, but linphone has always worked for me and I have never setup stun or a nat traversal method in linphone.  I'd prefer to use ekiga instead of linphone.

Here is the output of an incoming call that lasts until ekiga reports 'remote user cleared the call'.

I tried ekiga lastest cvs as I read about 2.02 hoping this might have been resolved.




------=_Part_10127_1193274.1149800945207-- From dsandras@seconix.com Fri Jun 9 03:56:41 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5D27B3B006E for ; Fri, 9 Jun 2006 03:56:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05479-07 for ; Fri, 9 Jun 2006 03:56:39 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 62A113B017E for ; Fri, 9 Jun 2006 03:56:39 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 2E8E349758 for ; Fri, 9 Jun 2006 09:38:49 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16204-09 for ; Fri, 9 Jun 2006 09:38:42 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 6559949755 for ; Fri, 9 Jun 2006 09:38:42 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Re: no audio on incoming calls. From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <58a398810606081409o3026d11cnd9f5f3a16b0243e@mail.gmail.com> References: <58a398810606061625x7684427q73db38225fa398dc@mail.gmail.com> <58a398810606081409o3026d11cnd9f5f3a16b0243e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 09 Jun 2006 09:56:30 +0200 Message-Id: <1149839790.3351.0.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 07:56:41 -0000 You should provide a debug 4 output. Le jeudi 08 juin 2006 à 17:09 -0400, mcquaid mcquaid a écrit : > Can I get any assistance on this or is there something else I should > be providing? I can get other voip apps like linphone working but I > can't get ekiga to transmit audio either way on incoming calls. Not > sure if it's any help but asterisk seems to behave in the same manner. > With asterisk I again could make outgoing call fine, but for incoming > it would route calls to my local sipphone, but no audio either way. > > On 6/6/06, mcquaid mcquaid wrote: > I have tried ekiga from time to time, and now using the latest > cvs, I still have the same problem. > > On outgoing calls, audio transmits both ways without issue. > > When receiving a call, no audio is transmitted either way. > > I realize it'll probably be considered a firewall issue, but > linphone has always worked for me and I have never setup stun > or a nat traversal method in linphone. I'd prefer to use > ekiga instead of linphone. > > Here is the output of an incoming call that lasts until ekiga > reports 'remote user cleared the call'. > > I tried ekiga lastest cvs as I read about 2.02 hoping this > might have been resolved. > > > > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From ph.l@libertysurf.fr Sat Jun 10 12:49:37 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 174BA3B01B8 for ; Sat, 10 Jun 2006 12:49:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15518-01 for ; Sat, 10 Jun 2006 12:49:36 -0400 (EDT) Received: from smtp4.mail.easynet.fr (smarthost169.mail.easynet.fr [212.180.1.169]) by menubar.gnome.org (Postfix) with ESMTP id C9C343B032B for ; Sat, 10 Jun 2006 12:49:35 -0400 (EDT) Received: from asi-236.asi256ip.easynet.fr ([212.180.39.236] helo=[145.111.24.1]) by smtp4.mail.easynet.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Fp6fr-0001ZY-Dc for gnomemeeting-devel-list@gnome.org; Sat, 10 Jun 2006 18:50:59 +0200 Message-ID: <448AF812.4010106@libertysurf.fr> Date: Sat, 10 Jun 2006 18:49:22 +0200 From: Philippe Lefevre User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: GnomeMeeting devel list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.839 tagged_above=-999 required=2 tests=[AWL=-1.437, BAYES_05=-1.11, DNS_FROM_RFC_POST=1.708] X-Spam-Score: -0.839 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ekiga 2.0.2 Ubuntu packages X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 16:49:37 -0000 Hi all, For a few days I'm looking for Ekiga 2.0.2 for ubuntu packages @ http://www.ekiga.org but there are no link available yet. Is this normal ? Thanks. PhiL From mathiaschulze@gmail.com Sun Jun 11 10:47:28 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7E1CC3B00B0 for ; Sun, 11 Jun 2006 10:47:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14779-09 for ; Sun, 11 Jun 2006 10:47:27 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by menubar.gnome.org (Postfix) with ESMTP id 6898E3B0084 for ; Sun, 11 Jun 2006 10:47:27 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id 9so1563867nzo for ; Sun, 11 Jun 2006 07:46:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=RdwAYw0jPdY9iOC0Sf+iOKQJ9I7YfnL/kWXyEPnc+Cr+QIVa1sKM88ZdFWngpOkudGwRUvtt1Aw9vAL7lpvseD6hTwpLtjhbhu306m/DpJDRigRtWN/PSaYRcSohSjgiAaMN7SNdOXCHLIjQ0ZzdPpKX46kbgKn0qo2/Dg4UYbo= Received: by 10.37.2.45 with SMTP id e45mr7180725nzi; Sun, 11 Jun 2006 07:46:45 -0700 (PDT) Received: from vaio ( [71.98.110.104]) by mx.gmail.com with ESMTP id 37sm151203nzf.2006.06.11.07.46.44; Sun, 11 Jun 2006 07:46:45 -0700 (PDT) From: Mathias Schulze To: gnomemeeting-devel-list@gnome.org Content-Type: text/plain Date: Sun, 11 Jun 2006 10:46:43 -0400 Message-Id: <1150037203.24558.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.821 tagged_above=-999 required=2 tests=[AWL=-0.779, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.821 X-Spam-Level: Subject: [GnomeMeeting-devel-list] alsa default device X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 14:47:28 -0000 Hello, I would like to make Ekiga automatically use my USB Headset whenever it is plugged in. It is no problem to switch the default device to the headset by a udev rule. But Ekiga seems to ignore any changes of the default device after start-up. I think if the default device is selected Ekiga should check the current default device immediately before starting the conversation. So if someone calls I can plug in the USB headset and accept the call. An example of a program which seems to do this is the gnome music player "Listen". An even better solution (but maybe too much work?) could be if Ekiga pops up a request whenever a new audio device appears to ask the user if this device should be used. Such request appears e.g. under Ubuntu in the control panel. Thanks for Ekiga, it's really great! Mathias From dsandras@seconix.com Mon Jun 12 04:46:20 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EDE963B00D8 for ; Mon, 12 Jun 2006 04:46:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26328-09 for ; Mon, 12 Jun 2006 04:46:16 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id B27083B009D for ; Mon, 12 Jun 2006 04:46:16 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 8BE0B83C22 for ; Mon, 12 Jun 2006 10:26:53 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29245-09 for ; Mon, 12 Jun 2006 10:26:48 +0200 (CEST) Received: from [192.168.0.161] (157.137-245-81.adsl-dyn.isp.belgacom.be [81.245.137.157]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id BF7E583C1F for ; Mon, 12 Jun 2006 10:26:48 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Ekiga 2.0.2 Ubuntu packages From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <448AF812.4010106@libertysurf.fr> References: <448AF812.4010106@libertysurf.fr> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 12 Jun 2006 10:46:31 +0200 Message-Id: <1150101991.2505.12.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 08:46:20 -0000 Le samedi 10 juin 2006 à 18:49 +0200, Philippe Lefevre a écrit : > Hi all, > For a few days I'm looking for Ekiga 2.0.2 for ubuntu packages @ > http://www.ekiga.org > but there are no link available yet. Is this normal ? They are coming soon... -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Mon Jun 12 08:26:32 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 96E503B0061 for ; Mon, 12 Jun 2006 08:26:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01773-10 for ; Mon, 12 Jun 2006 08:26:29 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 0BDDA3B000D for ; Mon, 12 Jun 2006 08:26:28 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id A4ACC83C24 for ; Mon, 12 Jun 2006 13:43:24 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15346-08 for ; Mon, 12 Jun 2006 13:43:15 +0200 (CEST) Received: from [192.168.0.161] (157.137-245-81.adsl-dyn.isp.belgacom.be [81.245.137.157]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 3FB8E83C22 for ; Mon, 12 Jun 2006 13:43:15 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] alsa default device From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <1150037203.24558.24.camel@localhost.localdomain> References: <1150037203.24558.24.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 12 Jun 2006 14:03:41 +0200 Message-Id: <1150113821.7909.5.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 12:26:32 -0000 Hi, Le dimanche 11 juin 2006 à 10:46 -0400, Mathias Schulze a écrit : > Hello, > > I would like to make Ekiga automatically use my USB Headset whenever it > is plugged in. It is no problem to switch the default device to the > headset by a udev rule. But Ekiga seems to ignore any changes of the > default device after start-up. > It is most probably due to ALSA and libasound if I understand correctly what you mean. If you change from "USB Headset" to "Soundcard" or to "Default", Ekiga will work correctly. However, you probably mean that you want to select "Default" as device in Ekiga and that "Default" will be linked to the USB headset or to the soundcard depending if the headset is plugged in or not. For Ekiga, it is transparent. Ekiga simply open the "Default" device when playing sounds. If the "Default" device is linked in real time to the USB headset while Ekiga is running, and if it still uses the sound card, then it means that libasound already mapped the default device to the soundcard when starting the application and doesn't accept changing it. So I would say that I'm 100% confident it is an ALSA limitation. However, I tried here changing the settings of my default device through .asoundrc when Ekiga is running and it works. > I think if the default device is selected Ekiga should check the current > default device immediately before starting the conversation. So if > someone calls I can plug in the USB headset and accept the call. > An example of a program which seems to do this is the gnome music player > "Listen". It is transparent for Ekiga. Ekiga opens the "Default" device whatever it is through ALSA. > > An even better solution (but maybe too much work?) could be if Ekiga > pops up a request whenever a new audio device appears to ask the user if > this device should be used. Such request appears e.g. under Ubuntu in > the control panel. It is planned in the future through HAL. > > Thanks for Ekiga, it's really great! > Mathias > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Mon Jun 12 17:23:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 441F03B01DB for ; Mon, 12 Jun 2006 17:23:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31653-03 for ; Mon, 12 Jun 2006 17:23:08 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 994B13B0010 for ; Mon, 12 Jun 2006 17:23:08 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 666F683C23 for ; Mon, 12 Jun 2006 23:01:22 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19698-06 for ; Mon, 12 Jun 2006 23:01:18 +0200 (CEST) Received: from [192.168.0.161] (157.137-245-81.adsl-dyn.isp.belgacom.be [81.245.137.157]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id AFAEE83C22 for ; Mon, 12 Jun 2006 23:01:18 +0200 (CEST) From: Damien Sandras To: gnomemeeting-devel-list@gnome.org Content-Type: text/plain Date: Mon, 12 Jun 2006 23:24:02 +0200 Message-Id: <1150147442.11823.2.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Subject: [GnomeMeeting-devel-list] New user interface : first stubs X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 21:23:10 -0000 Hi to all, I committed the first stubs of the new user interface. Please do not criticize too much as it is work in progress and it is in the very early stages of development. Julien is working on big changes too, but that should have no impact on the user interface. In the next few weeks, I will work more on : - the user interface - sip support (integrate Craig's changes) And finally work on a roster. Enjoy, -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From jpuydt@free.fr Tue Jun 13 13:58:03 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 530F33B03CF for ; Tue, 13 Jun 2006 13:58:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01110-02 for ; Tue, 13 Jun 2006 13:58:01 -0400 (EDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by menubar.gnome.org (Postfix) with ESMTP id EC4F23B00DB for ; Tue, 13 Jun 2006 13:58:00 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by postfix1-c.free.fr (Postfix) with ESMTP id 91A4B1CF1DC3 for ; Tue, 13 Jun 2006 17:47:25 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-32-82-254-24-205.adsl.proxad.net [82.254.24.205]) by smtp6-g19.free.fr (Postfix) with ESMTP id CD69E2286C for ; Tue, 13 Jun 2006 18:42:21 +0200 (CEST) Message-ID: <448EC473.7060800@free.fr> Date: Tue, 13 Jun 2006 15:58:11 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <448B2A40.5060600@free.fr> <20060612174347.5181a8f9@localhost.localdomain> <448DABA7.4060103@free.fr> <200606130951.56969.ebischoff@nerim.net> In-Reply-To: <200606130951.56969.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.567 tagged_above=-999 required=2 tests=[AWL=0.032, BAYES_00=-2.599] X-Spam-Score: -2.567 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 17:58:03 -0000 Hi, in private mails (with quite big attachments since I provided some sample stupid code), Éric Bischoff found my code not that explicit concerning what I have in mind. Since I would like to keep things as opened as possible, I drop my text here :-) Let's see if I can manage to give useful ideas. ***** BIG WORDS Model - View - Controller ***** VIEWING (GENERIC) We need to be able to present a book to the user. For that, the view needs to have a list of contacts (no, a single contact definitely isn't enough!). So we need a function call to get a list of contacts. The problem is that this list will change during time (new contacts added, others removed, presence changed, status message changed, and the list goes on). So the view will need to be notified about it. Hence the idea that the book will have "contact-added" and "contact-removed" signals, and the contacts a "updated" signal. In addition to that, there is an interesting special case to handle : you have a contact in a book, and this contact shows up in a search result. When you remove the contact from the book, we want to make it disappear from the list too. Hence a "removed" signal for contacts. Now this is all nice, but what can we do if an addressbook contains millions of entries ? And if a search gives thousands of results ? In such cases, my stance is that the low level code should do something about it, since it is the one giving the problem. How can the high level code cope correctly with the situation anyway ? Only the low level code can say "Eh, I already made two hundred contacts go through the wire for that search, perhaps I should make it easy!". The question to really ask, and to which I have no satisfactory answer is: "How do me make the low level tell the high level it had to cut the list ?". ***** VIEWING (CONTACTS) The contacts should contain enough to be viewed from a generic view in the contacts window, and be shown in a search result. That won't prevent some other parts of the code to make a better use of them. For example, in the contact window we will probably be able to see a contact's title and description, but not its detailed presence, while the main window will contain a much better and more specific view for the live contacts. ***** CONTROLLING (GENERIC) Now, we want to be able to act on our objects ; say rename a book or a contact, subscribe/unsubscribe to its presence, etc. The best thing to do is to be able to get menus for each of them. Notice the plural: we will certainly to have at least menu in the menu bar and a popup menu. The first bad news about such menus is that they won't be generic : they will depend heavily on the specific type of object (no rename for avahi contacts, subscribe/unsubscribe only for XMPP contacts...). So we will certainly need some sort of shared actions that will be basic bricks for building menu (like the shared-actions.[ch] of my first round of proposals), that each implementation will mix as it sees fit. The second bad news about them is that they won't be static either. They will have to update themselves following the object they are attached to. Say your nice XMPP contact is connected with a client which has VoIP support, but now connects with a no-VoIP client, and disconnects the first : we want the "Call" menuitem to disappear to reflect this. So my proposition (no code yet) is that those menus will be obtained by subclassing of GtkMenu, register to get signals from the contact/book they are attached to, and use that to keep themselves up to date. ***** CONTROLLING (CONTACTS) Let's try to be more specific: in avahi-contact-menu.h, we would have: GtkWidget *avahi_contact_menu_new (AvahiContact *contact); and in gm-contact.h: GtkWidget *gm_contact_get_menu_new (GmContact *contact); This later function would be different in each implementation, which allows for example the avahi_contact_get_menu_new implementation to call avahi_contact_menu_new. The high level code called a generic function, but got access to a very specific implementation, which knows the full api of the specific contact, and hence will provide the best service. ***** CONTROLLING (BOOKS) Perhaps the menu shouldn't be attached to the book himself, but to its view. That would allow to place things such as "Show offline contacts" in it. Mostly the idea would be to have controllers for both the model-as-model and its view-as-model. ***** ABOUT EVOLUTION-DATA-SERVER The evolution-data-server api looks pretty good -- except that it seems to mainly handle static vcard-based contacts, where I would like to be able to handle things like. For example, we find a nice contacts-changed signal, but in the EBookView api... not in the EBook api, which seems strange. ***** ABOUT LIBGAIM I shriek everytime I read/think about that comment in blist.h (just before the declaration of struct _GaimBuddy) : "A buddy. This contains everything Gaim will ever need to know about someone on the buddy list. Everything." (sic). and that one (before the declaration of struct _GaimContact) : "A contact. This contains everything Gaim will ever need to know about a contact." and that one (before the declaration of struct _GaimGroup) : "A group. This contains everything Gaim will ever need to know about a group." Notice that the comment before struct _GaimChat, although very similar, isn't so bad in my eye :-) Notice too that although I find the way it is done inelegant, it still is very good and efficient to get the job done, and contains quite an impressive list of good ideas. (And it's more portable as ekiga, gasp!) ***** ABOUT LIBGALAGO Why, why, oh why does it contain a GalagoList api which looks so much like a GList but isn't !? Apart from that, I would say it looks nice, but is out of scope for what we want to do right now : it doesn't deal with addressbooks, but with persons as single. "Using" it would be nice at some point. ***** LAST WORDS Congratulations, comments and flames welcome, but flames will end in /dev/null. Snark From jpuydt@free.fr Thu Jun 15 04:55:35 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7B51D3B008E for ; Thu, 15 Jun 2006 04:55:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24192-02 for ; Thu, 15 Jun 2006 04:55:31 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id C36A43B00CA for ; Thu, 15 Jun 2006 04:55:30 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp3-g19.free.fr (Postfix) with ESMTP id 26E1F496DD for ; Thu, 15 Jun 2006 10:54:59 +0200 (CEST) Message-ID: <4491205F.5070708@free.fr> Date: Thu, 15 Jun 2006 10:54:55 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.369 tagged_above=-999 required=2 tests=[AWL=0.230, BAYES_00=-2.599] X-Spam-Score: -2.369 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 08:55:35 -0000 Hi, in private mails (with quite big attachments since I provided some sample stupid code), Éric Bischoff found my code not that explicit concerning what I have in mind. Since I would like to keep things as opened as possible, I drop my text here :-) Let's see if I can manage to give useful ideas. ***** BIG WORDS Model - View - Controller ***** VIEWING (GENERIC) We need to be able to present a book to the user. For that, the view needs to have a list of contacts (no, a single contact definitely isn't enough!). So we need a function call to get a list of contacts. The problem is that this list will change during time (new contacts added, others removed, presence changed, status message changed, and the list goes on). So the view will need to be notified about it. Hence the idea that the book will have "contact-added" and "contact-removed" signals, and the contacts a "updated" signal. In addition to that, there is an interesting special case to handle : you have a contact in a book, and this contact shows up in a search result. When you remove the contact from the book, we want to make it disappear from the list too. Hence a "removed" signal for contacts. Now this is all nice, but what can we do if an addressbook contains millions of entries ? And if a search gives thousands of results ? In such cases, my stance is that the low level code should do something about it, since it is the one giving the problem. How can the high level code cope correctly with the situation anyway ? Only the low level code can say "Eh, I already made two hundred contacts go through the wire for that search, perhaps I should make it easy!". The question to really ask, and to which I have no satisfactory answer is: "How do me make the low level tell the high level it had to cut the list ?". ***** VIEWING (CONTACTS) The contacts should contain enough to be viewed from a generic view in the contacts window, and be shown in a search result. That won't prevent some other parts of the code to make a better use of them. For example, in the contact window we will probably be able to see a contact's title and description, but not its detailed presence, while the main window will contain a much better and more specific view for the live contacts. ***** CONTROLLING (GENERIC) Now, we want to be able to act on our objects ; say rename a book or a contact, subscribe/unsubscribe to its presence, etc. The best thing to do is to be able to get menus for each of them. Notice the plural: we will certainly to have at least menu in the menu bar and a popup menu. The first bad news about such menus is that they won't be generic : they will depend heavily on the specific type of object (no rename for avahi contacts, subscribe/unsubscribe only for XMPP contacts...). So we will certainly need some sort of shared actions that will be basic bricks for building menu (like the shared-actions.[ch] of my first round of proposals), that each implementation will mix as it sees fit. The second bad news about them is that they won't be static either. They will have to update themselves following the object they are attached to. Say your nice XMPP contact is connected with a client which has VoIP support, but now connects with a no-VoIP client, and disconnects the first : we want the "Call" menuitem to disappear to reflect this. So my proposition (no code yet) is that those menus will be obtained by subclassing of GtkMenu, register to get signals from the contact/book they are attached to, and use that to keep themselves up to date. ***** CONTROLLING (CONTACTS) Let's try to be more specific: in avahi-contact-menu.h, we would have: GtkWidget *avahi_contact_menu_new (AvahiContact *contact); and in gm-contact.h: GtkWidget *gm_contact_get_menu_new (GmContact *contact); This later function would be different in each implementation, which allows for example the avahi_contact_get_menu_new implementation to call avahi_contact_menu_new. The high level code called a generic function, but got access to a very specific implementation, which knows the full api of the specific contact, and hence will provide the best service. ***** CONTROLLING (BOOKS) Perhaps the menu shouldn't be attached to the book himself, but to its view. That would allow to place things such as "Show offline contacts" in it. Mostly the idea would be to have controllers for both the model-as-model and its view-as-model. ***** ABOUT EVOLUTION-DATA-SERVER The evolution-data-server api looks pretty good -- except that it seems to mainly handle static vcard-based contacts, where I would like to be able to handle things like. For example, we find a nice contacts-changed signal, but in the EBookView api... not in the EBook api, which seems strange. ***** ABOUT LIBGAIM I shriek everytime I read/think about that comment in blist.h (just before the declaration of struct _GaimBuddy) : "A buddy. This contains everything Gaim will ever need to know about someone on the buddy list. Everything." (sic). and that one (before the declaration of struct _GaimContact) : "A contact. This contains everything Gaim will ever need to know about a contact." and that one (before the declaration of struct _GaimGroup) : "A group. This contains everything Gaim will ever need to know about a group." Notice that the comment before struct _GaimChat, although very similar, isn't so bad in my eye :-) Notice too that although I find the way it is done inelegant, it still is very good and efficient to get the job done, and contains quite an impressive list of good ideas. (And it's more portable as ekiga, gasp!) ***** ABOUT LIBGALAGO Why, why, oh why does it contain a GalagoList api which looks so much like a GList but isn't !? Apart from that, I would say it looks nice, but is out of scope for what we want to do right now : it doesn't deal with addressbooks, but with persons as single. "Using" it would be nice at some point. ***** LAST WORDS Congratulations, comments and flames welcome, but flames will end in /dev/null. Snark PS: this message is already two or three days old... but got stuck. From ebischoff@nerim.net Thu Jun 15 07:18:00 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 98B4A3B032E for ; Thu, 15 Jun 2006 07:18:00 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01896-02 for ; Thu, 15 Jun 2006 07:17:57 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id 2C6AF3B0488 for ; Thu, 15 Jun 2006 07:17:56 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 3CBA240F45 for ; Thu, 15 Jun 2006 13:17:52 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Thu, 15 Jun 2006 13:18:05 +0200 User-Agent: KMail/1.8.2 References: <4491205F.5070708@free.fr> In-Reply-To: <4491205F.5070708@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606151318.05338.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.578 tagged_above=-999 required=2 tests=[AWL=0.021, BAYES_00=-2.599] X-Spam-Score: -2.578 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 11:18:01 -0000 Hi Julien, and thanks for this nice document. That looks like a good basis for thinkin= g=20 aloud :-). Le Jeudi 15 Juin 2006 10:54, Julien PUYDT a =C3=A9crit=C2=A0: > ***** BIG WORDS > > Model - View - Controller Excellent basis. > ***** VIEWING (GENERIC) > > We need to be able to present a book to the user. For that, the view > needs to have a list of contacts (no, a single contact definitely isn't > enough!). So we need a function call to get a list of contacts. In this paragraph I will assume that you mean "the view needs a list of all= =20 contacts from the address book driver". If it is not what you mean, please= =20 ignore this paragraph... The view needs to display, say, 10 contects at a time. No need to keep a li= st=20 of all contacts in memory. All we "need" is a function that gets _one_ contact from the driver. The vi= ew=20 can then use this information to keep the list of the 10 contacts that it=20 currently displays. > The problem is that this list will change during time (new contacts > added, others removed, presence changed, status message changed, and the > list goes on). So the view will need to be notified about it. Hence the > idea that the book will have "contact-added" and "contact-removed" > signals, and the contacts a "updated" signal. > In addition to that, there is an interesting special case to handle : > you have a contact in a book, and this contact shows up in a search > result. When you remove the contact from the book, we want to make it > disappear from the list too. Hence a "removed" signal for contacts. While this sounds cool, I am not sure that this will be possible in some=20 circumstances. The underlying address book (evolution, KDE address book, LD= AP=20 server, Zeroconf, ...) might not have the mechanisms to send such a signal. I can imagine situations where some users on machine A update a LDAP server= on=20 machine B while Ekiga runs on machine C, with the network connection betwee= n=20 B and C being temporarily broken. Will an update message come up to the=20 driver, and if yes when and how? Please notice that I do not know LDAP well and that such mechanisms might=20 exist. Should that be the case, please ignore these paragraphs. What do I propose instead? To be less ambitious, and have an address book t= hat=20 only pulls the data from the data source. If the user does not press=20 "refresh", then he/she might have outdated information. If he/she presses=20 "refresh", then the addresses are fetched again from the source. > Now this is all nice, but what can we do if an addressbook contains > millions of entries ? And if a search gives thousands of results ? In > such cases, my stance is that the low level code should do something > about it, since it is the one giving the problem. I do not like that repartition of tasks. Let me take an example. When you write an operating system, you write: =2D disk drivers (the low level code that does physical read and write from and to the hard disk) =2D a filesystem (the high level code that gathers individual sectors into files, handles a cache, etc) The low level code should not be bothered with handling the disk cache. Oka= y,=20 the problem comes from the disk driver, because it does slow access to the= =20 medium. That does not mean that it's not another component, the filesystem,= =20 that can solve it. Why this repartition of tasks? Because the performance problem is a problem= =20 that can be shared by many disk drivers. Therefore, the solution can be put= =20 in common in the high level code. > How can the high level > code cope correctly with the situation anyway ? Only the low level code > can say "Eh, I already made two hundred contacts go through the wire for > that search, perhaps I should make it easy!". Why transfer 200 contacts when the view knows that it needs only 10? > The question to really ask, and to which I have no satisfactory answer > is: "How do me make the low level tell the high level it had to cut the > list ?". The views know that contacts 301 to 309 are displayed. It's the view that=20 knows where to cut. In fact, there's nothing to cut, since all the view doe= s=20 is ask the driver for the contects it needs. > ***** VIEWING (CONTACTS) > > The contacts should contain enough to be viewed from a generic view in > the contacts window, and be shown in a search result. That won't prevent > some other parts of the code to make a better use of them. > > For example, in the contact window we will probably be able to see a > contact's title and description, but not its detailed presence, while > the main window will contain a much better and more specific view for > the live contacts. You say that the "contact" class must have _enough_ information to be used= =20 both in situation A and in sitation B. It would be better to have _different_ "contact" classes for situations "A"= =20 and "B". The list of contacts could just manage a name, a company and a phone number= =2E=20 The search result could handle much more detailed information. In other words, there's no need to put all the model's data into the views'= =20 data. Each view can handle the data it needs. > ***** CONTROLLING (GENERIC) > > Now, we want to be able to act on our objects ; say rename a book or a > contact, subscribe/unsubscribe to its presence, etc. > > The best thing to do is to be able to get menus for each of them. Notice > the plural: we will certainly to have at least menu in the menu bar and > a popup menu. > > The first bad news about such menus is that they won't be generic : they > will depend heavily on the specific type of object (no rename for avahi > contacts, subscribe/unsubscribe only for XMPP contacts...). So we will > certainly need some sort of shared actions that will be basic bricks for > building menu (like the shared-actions.[ch] of my first round of > proposals), that each implementation will mix as it sees fit. I assume here that an 'implementation" is one of the address book drivers, = and=20 that you mean that the drivers will be in charge of building menus. If thos= e=20 assumptions are wrong, the paragraph below does not apply, please just igno= re=20 it. Just the same as a hard disk driver does not display menus to the user, I=20 think that the address book drivers in Ekiga should not be responsible for= =20 user interaction. The high level code should be responsible for that. Of course the contents = of=20 the various menus depends on the address book capabilities. That's why the= =20 API between the driver and the high level code should include "query=20 capabilities functions:" class addressBook { virtual bool isReadOnly() =3D 0; virtual bool canSubscribeContacts() =3D 0; ... }; > The second bad news about them is that they won't be static either. They > will have to update themselves following the object they are attached > to. Say your nice XMPP contact is connected with a client which has VoIP > support, but now connects with a no-VoIP client, and disconnects the > first : we want the "Call" menuitem to disappear to reflect this. > > So my proposition (no code yet) is that those menus will be obtained by > subclassing of GtkMenu, register to get signals from the contact/book > they are attached to, and use that to keep themselves up to date. In your example, a signal is not needed. Knowing that there is no VoIP number in the current contact is enough. > ***** CONTROLLING (CONTACTS) > > Let's try to be more specific: > in avahi-contact-menu.h, we would have: > GtkWidget *avahi_contact_menu_new (AvahiContact *contact); > and in gm-contact.h: > GtkWidget *gm_contact_get_menu_new (GmContact *contact); > > This later function would be different in each implementation, which > allows for example the avahi_contact_get_menu_new implementation to call > avahi_contact_menu_new. The high level code called a generic function, > but got access to a very specific implementation, which knows the full > api of the specific contact, and hence will provide the best service. Again, this logic should be in the high-level code and needs not be=20 avahi-specific. What exactly should be presented to the user could be=20 determined from querying the address book for its capabilities. > ***** CONTROLLING (BOOKS) > > Perhaps the menu shouldn't be attached to the book himself, but to its > view. That would allow to place things such as "Show offline contacts" > in it. Mostly the idea would be to have controllers for both the > model-as-model and its view-as-model. Agree. > ***** ABOUT EVOLUTION-DATA-SERVER > > The evolution-data-server api looks pretty good -- except that it seems > to mainly handle static vcard-based contacts, where I would like to be > able to handle things like. > > For example, we find a nice contacts-changed signal, but in the > EBookView api... not in the EBook api, which seems strange. > > ***** ABOUT LIBGAIM > > I shriek everytime I read/think about that comment in blist.h (just > before the declaration of struct _GaimBuddy) : > "A buddy. This contains everything Gaim will ever need to know about > someone on the buddy list. Everything." (sic). > and that one (before the declaration of struct _GaimContact) : > "A contact. This contains everything Gaim will ever need to know about > a contact." > and that one (before the declaration of struct _GaimGroup) : > "A group. This contains everything Gaim will ever need to know about a > group." > > Notice that the comment before struct _GaimChat, although very similar, > isn't so bad in my eye :-) > > Notice too that although I find the way it is done inelegant, it still > is very good and efficient to get the job done, and contains quite an > impressive list of good ideas. (And it's more portable as ekiga, gasp!) > > ***** ABOUT LIBGALAGO > > Why, why, oh why does it contain a GalagoList api which looks so much > like a GList but isn't !? > > Apart from that, I would say it looks nice, but is out of scope for what > we want to do right now : it doesn't deal with addressbooks, but with > persons as single. > > "Using" it would be nice at some point. > > ***** LAST WORDS > > Congratulations, comments and flames welcome, but flames will end in > /dev/null. It definitly deserves congratulations. You forgot to mention one of your ni= ce=20 ideas, that it that it should be possible to search in several address book= s=20 at a time. =46or the comments, please note that my comments are based on a lot of=20 assumptions and guesses. In particular, I assume that you have in mind a=20 different assignment of tasks of the various software layers than the one=20 that I would like to see. If those assumptions reveal wrong, then of course= =20 my comments do not make much sense. If I did not misinterpret your thoughts, you have a very lazy view of the=20 high-level code. It's software that sits down and waits for signals to act.= =20 Somehow, the high level code provides "services" to the drivers. The driver= s=20 are the ones who understand what's going on. I have the opposite view: the address book drivers are simple and stupid.=20 Their main task is to go and fetch the requested contacts. The high level=20 code has an active attitude: it queries the drivers for contacts, it querie= s=20 the drivers capabilities, it displays the contact windows, it handles the=20 menues... The high level code has the real intelligence. I hope that helps, =2D-=20 Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m=C3=A9dire." (Le concombre masqu=C3=A9, Mandriva) From kk@verfaction.de Thu Jun 15 10:03:55 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C686B3B0336 for ; Thu, 15 Jun 2006 10:03:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15471-01 for ; Thu, 15 Jun 2006 10:03:54 -0400 (EDT) Received: from mx.verfaction.de (mx.verfaction.de [212.9.177.23]) by menubar.gnome.org (Postfix) with ESMTP id 779793B00CE for ; Thu, 15 Jun 2006 10:03:54 -0400 (EDT) Received: from erebos.verfaction.de ([2001:14b0:201:7357::1] helo=homemx.verfaction.de ident=Debian-exim) by mx.verfaction.de with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FqsRp-0003kA-3Z for gnomemeeting-devel-list@gnome.org; Thu, 15 Jun 2006 16:03:52 +0200 Received: from ganymede.kk.de ([192.168.7.10]) by homemx.verfaction.de with esmtp (Exim 4.50) id 1FqsRk-0000ld-Dw for gnomemeeting-devel-list@gnome.org; Thu, 15 Jun 2006 16:03:48 +0200 From: Kilian Krause To: GnomeMeeting development mailing list In-Reply-To: <200606081002.37875.conrad_videokonferenz@gmx.de> References: <200606081002.37875.conrad_videokonferenz@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aitPD1cXT483JdjYdYcu" Date: Thu, 15 Jun 2006 16:03:43 +0200 Message-Id: <1150380224.6599.22.camel@ganymede.verfaction.de> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-SA-Exim-Connect-IP: 2001:14b0:201:7357::1 X-SA-Exim-Mail-From: kk@verfaction.de X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 14:03:56 -0000 --=-aitPD1cXT483JdjYdYcu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hey Conrad, Am Donnerstag, den 08.06.2006, 10:02 +0000 schrieb Conrad Beckert: > has anybody an idea where the Debian packages for Ekiga 2.0.2 (or the=20 > corresponding CVS versions) are? on their way. > The last version I can install using apt-get a couple of days old (May 25= - or=20 > somethin) - at least this is a version with the nonfunctional German loc= ale.=20 > (defaults to English) >=20 > What's up? /me is having a sheer lack of time and thus it took me a while to get everything polished and fixed just like i love to have it. =3D) Everything should be back to normal as of tonight (eventually sarge cvs snaps and win32 will remain for the weekend - we'll see) --=20 Best regards, Kilian --=-aitPD1cXT483JdjYdYcu Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEkWi/vdkzt4X+wX8RAnZ/AJoCW2qvo1l8kFsAJzogWEPKv73LUACZAZk6 n6VWZ1JiCCXnGNsq5yEsLwU= =VwN+ -----END PGP SIGNATURE----- --=-aitPD1cXT483JdjYdYcu-- From jpuydt@free.fr Thu Jun 15 11:41:17 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D25F23B0616 for ; Thu, 15 Jun 2006 11:41:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20025-08 for ; Thu, 15 Jun 2006 11:41:15 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id 8BF5B3B041B for ; Thu, 15 Jun 2006 11:41:14 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp6-g19.free.fr (Postfix) with ESMTP id 3FD8B227D9 for ; Thu, 15 Jun 2006 17:40:32 +0200 (CEST) Message-ID: <44917F71.10408@free.fr> Date: Thu, 15 Jun 2006 17:40:33 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> In-Reply-To: <200606151318.05338.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.337 tagged_above=-999 required=2 tests=[AWL=0.185, BAYES_00=-2.599, TW_AV=0.077] X-Spam-Score: -2.337 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:41:18 -0000 Éric Bischoff a écrit : >> ***** VIEWING (GENERIC) >> >> We need to be able to present a book to the user. For that, the view >> needs to have a list of contacts (no, a single contact definitely isn't >> enough!). So we need a function call to get a list of contacts. > > In this paragraph I will assume that you mean "the view needs a list of all > contacts from the address book driver". If it is not what you mean, please > ignore this paragraph... Well, all contacts may be asking too much. I expect drivers to keep things sane. > The view needs to display, say, 10 contects at a time. No need to keep a list > of all contacts in memory. > > All we "need" is a function that gets _one_ contact from the driver. The view > can then use this information to keep the list of the 10 contacts that it > currently displays. Blah. If you're gonna loop on a list of contacts anyway, then get the list at once. Saying "I get only the 10 I need" is nice, but how do you tell the driver which they are ? Especially a roster XMPP generally comes as a single roster push you ask for when connecting, then little update pushes. >> The problem is that this list will change during time (new contacts >> added, others removed, presence changed, status message changed, and the >> list goes on). So the view will need to be notified about it. Hence the >> idea that the book will have "contact-added" and "contact-removed" >> signals, and the contacts a "updated" signal. >> In addition to that, there is an interesting special case to handle : >> you have a contact in a book, and this contact shows up in a search >> result. When you remove the contact from the book, we want to make it >> disappear from the list too. Hence a "removed" signal for contacts. > > While this sounds cool, I am not sure that this will be possible in some > circumstances. The underlying address book (evolution, KDE address book, LDAP > server, Zeroconf, ...) might not have the mechanisms to send such a signal. No problem : then they don't. Let's take the avahi book. It will probably update the list of users regularly (and have some action to update *now*). How will it work ? Well, it will populate a cache with those contacts, and on updating, flush it ("contact-removed" emitted on all of them), then repopulate it ("contact-added"). > I can imagine situations where some users on machine A update a LDAP server on > machine B while Ekiga runs on machine C, with the network connection between > B and C being temporarily broken. Will an update message come up to the > driver, and if yes when and how? If the backend doesn't give incremental changes, that still fits in my design. > What do I propose instead? To be less ambitious, and have an address book that > only pulls the data from the data source. If the user does not press > "refresh", then he/she might have outdated information. If he/she presses > "refresh", then the addresses are fetched again from the source. Bad. If the backend gives incremental changes, you don't handle it. Such a design works only for the most simple backends. >> Now this is all nice, but what can we do if an addressbook contains >> millions of entries ? And if a search gives thousands of results ? In >> such cases, my stance is that the low level code should do something >> about it, since it is the one giving the problem. > > I do not like that repartition of tasks. > > Let me take an example. When you write an operating system, you write: > - disk drivers > (the low level code that does physical read and write from and to > the hard disk) > - a filesystem > (the high level code that gathers individual sectors into files, > handles a cache, etc) > > The low level code should not be bothered with handling the disk cache. Okay, > the problem comes from the disk driver, because it does slow access to the > medium. That does not mean that it's not another component, the filesystem, > that can solve it. > > Why this repartition of tasks? Because the performance problem is a problem > that can be shared by many disk drivers. Therefore, the solution can be put > in common in the high level code. Your file manager doesn't handle the filesystems itself : they all present the same interface, and take care of caching themselves. I want the addressbook manager to be *high* level. If some caching is needed between the addressbook manager and the backend, I want the driver to take care of it. In fact, I implemented a SearchBook to take care of presenting all search results (whatever the book), and it's certainly desirable to provide a CachedBook, which will avoid code duplication. >> How can the high level >> code cope correctly with the situation anyway ? Only the low level code >> can say "Eh, I already made two hundred contacts go through the wire for >> that search, perhaps I should make it easy!". > > Why transfer 200 contacts when the view knows that it needs only 10? The view may show only ten at the same time on the screen, but the mouse wheel makes it so easy to go through all of the 200, that it wouldn't be wise to have them ready. If there are several thousands, that's more annoying. >> The question to really ask, and to which I have no satisfactory answer >> is: "How do me make the low level tell the high level it had to cut the >> list ?". > > The views know that contacts 301 to 309 are displayed. It's the view that > knows where to cut. In fact, there's nothing to cut, since all the view does > is ask the driver for the contects it needs. How do you number the contacts in a sane way? >> ***** VIEWING (CONTACTS) >> >> The contacts should contain enough to be viewed from a generic view in >> the contacts window, and be shown in a search result. That won't prevent >> some other parts of the code to make a better use of them. >> >> For example, in the contact window we will probably be able to see a >> contact's title and description, but not its detailed presence, while >> the main window will contain a much better and more specific view for >> the live contacts. > > You say that the "contact" class must have _enough_ information to be used > both in situation A and in sitation B. > > It would be better to have _different_ "contact" classes for situations "A" > and "B". Of course there will be. I was discussing the base class. > The list of contacts could just manage a name, a company and a phone number. I would put the following : 1) a title (generally the name) 2) a description (for example a location, a status message, etc) 3) an icon > The search result could handle much more detailed information. Of course it cannot. Your search result is a book which needs to be able to show avahi contacts, sip contacts, call history contacts, etc... so it can only show the contacts as generic. > In other words, there's no need to put all the model's data into the views' > data. Each view can handle the data it needs. The view which is specific to an addressbook, of course can show the data from the specific contact associated to it. But the generic view can only show generic information. >> ***** CONTROLLING (GENERIC) >> >> Now, we want to be able to act on our objects ; say rename a book or a >> contact, subscribe/unsubscribe to its presence, etc. >> >> The best thing to do is to be able to get menus for each of them. Notice >> the plural: we will certainly to have at least menu in the menu bar and >> a popup menu. >> >> The first bad news about such menus is that they won't be generic : they >> will depend heavily on the specific type of object (no rename for avahi >> contacts, subscribe/unsubscribe only for XMPP contacts...). So we will >> certainly need some sort of shared actions that will be basic bricks for >> building menu (like the shared-actions.[ch] of my first round of >> proposals), that each implementation will mix as it sees fit. > > I assume here that an 'implementation" is one of the address book drivers, and > that you mean that the drivers will be in charge of building menus. If those > assumptions are wrong, the paragraph below does not apply, please just ignore > it. Yes, that's precisely that. > Just the same as a hard disk driver does not display menus to the user, I > think that the address book drivers in Ekiga should not be responsible for > user interaction The menu is supposed to contain actions which are specific to the given contact, book or view. Hence it must be created by code which is specific to that contact, book or view. It cannot be done by the generic code. > The high level code should be responsible for that. Of course the contents of > the various menus depends on the address book capabilities. That's why the > API between the driver and the high level code should include "query > capabilities functions:" > > class addressBook > { > virtual bool isReadOnly() = 0; > virtual bool canSubscribeContacts() = 0; > ... > }; No, that is wrong and I already explained why. Putting everything in the base class is bad. >> The second bad news about them is that they won't be static either. They >> will have to update themselves following the object they are attached >> to. Say your nice XMPP contact is connected with a client which has VoIP >> support, but now connects with a no-VoIP client, and disconnects the >> first : we want the "Call" menuitem to disappear to reflect this. >> >> So my proposition (no code yet) is that those menus will be obtained by >> subclassing of GtkMenu, register to get signals from the contact/book >> they are attached to, and use that to keep themselves up to date. > > In your example, a signal is not needed. > > Knowing that there is no VoIP number in the current contact is enough. That is wrong. The same contact could update itself and gain it. Or update itself and lose it. >> ***** CONTROLLING (CONTACTS) >> >> Let's try to be more specific: >> in avahi-contact-menu.h, we would have: >> GtkWidget *avahi_contact_menu_new (AvahiContact *contact); >> and in gm-contact.h: >> GtkWidget *gm_contact_get_menu_new (GmContact *contact); >> >> This later function would be different in each implementation, which >> allows for example the avahi_contact_get_menu_new implementation to call >> avahi_contact_menu_new. The high level code called a generic function, >> but got access to a very specific implementation, which knows the full >> api of the specific contact, and hence will provide the best service. > > Again, this logic should be in the high-level code and needs not be > avahi-specific. What exactly should be presented to the user could be > determined from querying the address book for its capabilities. Which means : 1) *all* of the addressbooks would by default have *all* the possible apis for such capability by default, with a isAbleToDoFoo function for each Foo capability ; 2) if an addressbook needs a new capability, we'll have to modify the base addressbook to add it in for it ; it won't just be a matter for the new code to add only what is necessary for itself in its own files. >> ***** CONTROLLING (BOOKS) >> >> Perhaps the menu shouldn't be attached to the book himself, but to its >> view. That would allow to place things such as "Show offline contacts" >> in it. Mostly the idea would be to have controllers for both the >> model-as-model and its view-as-model. > > Agree. Nice. >> Congratulations, comments and flames welcome, but flames will end in >> /dev/null. > > It definitly deserves congratulations. You forgot to mention one of your nice > ideas, that it that it should be possible to search in several address books > at a time. Well, that is the main side-effect of having a base class for contacts. > For the comments, please note that my comments are based on a lot of > assumptions and guesses. In particular, I assume that you have in mind a > different assignment of tasks of the various software layers than the one > that I would like to see. If those assumptions reveal wrong, then of course > my comments do not make much sense. I think you are focused on an addressbook as something both very big and very static, which explains many of our divergences. > If I did not misinterpret your thoughts, you have a very lazy view of the > high-level code. It's software that sits down and waits for signals to act. > Somehow, the high level code provides "services" to the drivers. The drivers > are the ones who understand what's going on. Yes, that's it. The high-level code doesn't know what an AvahiContact or EDSContact is ; it only knows avbout GmContact. That means it cannot do fancy things with them, and has to call functions on them to do anything interesting. > I have the opposite view: the address book drivers are simple and stupid. > Their main task is to go and fetch the requested contacts. The high level > code has an active attitude: it queries the drivers for contacts, it queries > the drivers capabilities, it displays the contact windows, it handles the > menues... The high level code has the real intelligence. Your high level code is very complex, and has to be modified heavily anytime we add a new type of addressbook with new capabilities. Anytime you want to do something, you should ask yourself the question: "Who knows how to do it?". You want to send a message to a contact ? Who knows if it's even possible, and how to do it ? The contact itself! Hence this should be handled by the contact. Of course, as-is that would mean a lot of code duplication. That's where we can use a toolbox ; of which you had an example in the first round of sample code I sent in private. To make it explicit for the -devel- readers, this sample code had a function: void shared_action_rename (GObject *obj); so any object which could be renamed, had only to: - have a "name" property ; - provide an action which trigerred that function on itself. the function handled showing a nice dialog to rename the function. The idea is that of course quite a few objects will have common capabilities ; but instead of putting them all in the high level code and clutter it with functions and conditional, I want to provide the bricks which the low-level code will use to build a specific and well-fit system. Snark From ebischoff@nerim.net Thu Jun 15 14:27:54 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1F1163B04C0 for ; Thu, 15 Jun 2006 14:27:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27103-03 for ; Thu, 15 Jun 2006 14:27:51 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id E36E93B0412 for ; Thu, 15 Jun 2006 14:27:50 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 25E1340F90 for ; Thu, 15 Jun 2006 20:26:36 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Thu, 15 Jun 2006 20:26:49 +0200 User-Agent: KMail/1.8.2 References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> <44917F71.10408@free.fr> In-Reply-To: <44917F71.10408@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606152026.49639.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.533 tagged_above=-999 required=2 tests=[AWL=-0.011, BAYES_00=-2.599, SUBJECT_EXCESS_QP=0, TW_AV=0.077] X-Spam-Score: -2.533 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] =?utf-8?q?Ideas_and_considerations_for_?= =?utf-8?q?the=09addressbook_code?= X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 18:27:54 -0000 Le Jeudi 15 Juin 2006 17:40, Julien PUYDT a =C3=A9crit=C2=A0: > Saying "I get only the 10 I need" is nice, but how do you tell the > driver which they are ? There are several ways to acheive that. It could be contact numbers. Or it= =20 could be some data kept internally inside the driver. It could be a void *.= =20 Etc. > > While this sounds cool, I am not sure that this will be possible in some > > circumstances. The underlying address book (evolution, KDE address book, > > LDAP server, Zeroconf, ...) might not have the mechanisms to send such a > > signal. > > No problem : then they don't. OK. So that should not be a requirement, and certainly not a mechanism at t= he=20 core of the system. Just a nice plus. > > Why transfer 200 contacts when the view knows that it needs only 10? > > The view may show only ten at the same time on the screen, but the mouse > wheel makes it so easy to go through all of the 200, that it wouldn't be > wise to have them ready. Yes. You could have a few spare contacts before and after the user's view.= =20 This algorithm is rather common. > If there are several thousands, that's more annoying. Okay. Let's simulate your algorithm, or what I have understood of it. The user views a search selection of contacts named "Tom". His/her window=20 should contain contacts Tom Smith (#1032), Tom Jones (#2050) and Tom Doe=20 (#3172). The high level software asks the driver "get me all contacts". Aft= er=20 a relatively long time, the driver is wise and stops at contact 200. It=20 returns a list with contacts 1, 2, 3, etc, up to 200. The high level softwa= re=20 searches for Tom's in the list and finds none, since the Tom's have numbers= =20 1032, 2050 and 3172. The returned list is useless, and the window remains=20 blank. I know that it cannot be _that_ bad and that I certainly misunderstood=20 something. But what? > > The views know that contacts 301 to 309 are displayed. It's the view th= at > > knows where to cut. In fact, there's nothing to cut, since all the view > > does is ask the driver for the contects it needs. > > How do you number the contacts in a sane way? These numbers are here for the demonstration. I agree that numbers probably= =20 are not so well adapted to real address books. You could use "markers". I think that all address books use contact UIDs. A= =20 given UID could be used to mark the place where the address book stopped=20 "last time". =46or most usage you do not even need anything. Most operation is sequentia= l.=20 Take for example searching. Usually you browse all records and only keep in= =20 the result list the ones that match. > I would put the following : > 1) a title (generally the name) > 2) a description (for example a location, a status message, etc) > 3) an icon Yes, we are discussing principles. Details can be arranged later. > > The search result could handle much more detailed information. > > Of course it cannot. Your search result is a book which needs to be able > to show avahi contacts, sip contacts, call history contacts, etc... so > it can only show the contacts as generic. Why would you be unable to display detailed information about objects which= =20 you only know as generic? while (genericContact =3D nextContact()) { if (genericContact->book()->canSubscribeContacts()) proposeSubscription(genericContact); ... } > The view which is specific to an addressbook, of course can show the > data from the specific contact associated to it. But the generic view > can only show generic information. Wrong ;-). Not shown in the code sample above, but that's also the whole point of virt= ual=20 methods. > The menu is supposed to contain actions which are specific to the given > contact, book or view. Hence it must be created by code which is > specific to that contact, book or view. It cannot be done by the generic > code. ;-) > > class addressBook > > { > > virtual bool isReadOnly() =3D 0; > > virtual bool canSubscribeContacts() =3D 0; > > ... > > }; > > No, that is wrong and I already explained why. Putting everything in the > base class is bad. Do you realize that the above is not an implementation? It's just an API=20 definition. Those are pure virtual methods. Everything is implemented in th= e=20 derived subclasses. Such style of coding is very classical, good, C++ (or java). > > In your example, a signal is not needed. > > > > Knowing that there is no VoIP number in the current contact is enough. > > That is wrong. The same contact could update itself and gain it. Or > update itself and lose it. I should have added "at a given time". > Which means : > 1) *all* of the addressbooks would by default have *all* the possible > apis for such capability by default, with a isAbleToDoFoo function for > each Foo capability ; No. Defining pure virtual functions in the base class does not mean that yo= u=20 implement a function in the derived class. If it can't do something, and le= ts=20 the engine know it, then it can't ;-). > 2) if an addressbook needs a new capability, we'll have to modify the > base addressbook to add it in for it ; it won't just be a matter for the > new code to add only what is necessary for itself in its own files. Wrong again, C++ comes with programming techniques that permit to locate th= e=20 real implementations in the derived classes. > > It definitly deserves congratulations. You forgot to mention one of your > > nice ideas, that it that it should be possible to search in several > > address books at a time. > > Well, that is the main side-effect of having a base class for contacts. ;-) > I think you are focused on an addressbook as something both very big and > very static, which explains many of our divergences. I think that we are both wrong here ;-). An address book could be big (whic= h=20 you underestimated), and it could be moving (which I underestimated). > Yes, that's it. The high-level code doesn't know what an AvahiContact or > EDSContact is ; it only knows avbout GmContact. That means it cannot do > fancy things with them, and has to call functions on them to do anything > interesting. I have a view that is not so far away. The book just knows contacts. Virtua= l=20 methods and subclassing both the book and the contacts does the rest. > Your high level code is very complex, and has to be modified heavily > anytime we add a new type of addressbook with new capabilities. Yes, but much more generic. And if the same capability exists in a second address book, the code is=20 already written. > Of course, as-is that would mean a lot of code duplication. That's where > we can use a toolbox ; of which you had an example in the first round of > sample code I sent in private. Ah, you too you can see the duplication problem with your method ;-). A tool box... Sounds like a C library ;-). I think that we basically foresee the same problems, but you want to do the= m=20 in the procedural, C way, and I would like them to be done in the=20 object-oriented, C++ way. > To make it explicit for the -devel- readers, this sample code had a > function: > void shared_action_rename (GObject *obj); > so any object which could be renamed, had only to: > - have a "name" property ; > - provide an action which trigerred that function on itself. > the function handled showing a nice dialog to rename the function. Yup. You see functions where I see methods ;-). > The idea is that of course quite a few objects will have common > capabilities ; but instead of putting them all in the high level code > and clutter it with functions and conditional, Yes, that would be the logical consequence if we were in C. We are not. We= =20 have virtual methods. > I want to provide the=20 > bricks which the low-level code will use to build a specific and > well-fit system. You will end up with an engine doing about nothing, and all the work to be= =20 reimplemented again and again in the drivers. Plus painfully shared code in= =20 the "toolbox" to avoid almost identical code where it can be avoided. That'= s=20 typical procedural approach. =2D-=20 Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m=C3=A9dire." (Le concombre masqu=C3=A9, Mandriva) From jpuydt@free.fr Thu Jun 15 16:46:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 4F0A43B01FF for ; Thu, 15 Jun 2006 16:46:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32671-05 for ; Thu, 15 Jun 2006 16:46:37 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 91ADA3B00D0 for ; Thu, 15 Jun 2006 16:46:36 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp1-g19.free.fr (Postfix) with ESMTP id 743AD9A39A for ; Thu, 15 Jun 2006 22:46:01 +0200 (CEST) Message-ID: <4491C708.3060203@free.fr> Date: Thu, 15 Jun 2006 22:46:00 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> <44917F71.10408@free.fr> <200606152026.49639.ebischoff@nerim.net> In-Reply-To: <200606152026.49639.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.342 tagged_above=-999 required=2 tests=[AWL=0.180, BAYES_00=-2.599, TW_AV=0.077] X-Spam-Score: -2.342 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 20:46:39 -0000 Éric Bischoff a écrit : > Le Jeudi 15 Juin 2006 17:40, Julien PUYDT a écrit : >> Saying "I get only the 10 I need" is nice, but how do you tell the >> driver which they are ? > > There are several ways to acheive that. It could be contact numbers. Or it > could be some data kept internally inside the driver. It could be a void *. > Etc. Well, then you reduced the question: "How do I tell the driver which contacts I want?" to: "How do I tell the driver which identifiers I want?" I don't find this impressive. >>> While this sounds cool, I am not sure that this will be possible in some >>> circumstances. The underlying address book (evolution, KDE address book, >>> LDAP server, Zeroconf, ...) might not have the mechanisms to send such a >>> signal. >> No problem : then they don't. > > OK. So that should not be a requirement, and certainly not a mechanism at the > core of the system. Just a nice plus. It *must* be at the core of the system. We _do_ want to update the live data when it changes. >>> Why transfer 200 contacts when the view knows that it needs only 10? >> The view may show only ten at the same time on the screen, but the mouse >> wheel makes it so easy to go through all of the 200, that it wouldn't be >> wise to have them ready. > > Yes. You could have a few spare contacts before and after the user's view. > This algorithm is rather common. What do "before" and "after" mean ? >> If there are several thousands, that's more annoying. > > Okay. Let's simulate your algorithm, or what I have understood of it. > > The user views a search selection of contacts named "Tom". His/her window > should contain contacts Tom Smith (#1032), Tom Jones (#2050) and Tom Doe > (#3172). The high level software asks the driver "get me all contacts". After > a relatively long time, the driver is wise and stops at contact 200. It > returns a list with contacts 1, 2, 3, etc, up to 200. The high level software > searches for Tom's in the list and finds none, since the Tom's have numbers > 1032, 2050 and 3172. The returned list is useless, and the window remains > blank. > > I know that it cannot be _that_ bad and that I certainly misunderstood > something. But what? I certainly have issues with big books, and must find some satisfying way to handle them. But doing function calls to walk on a list where I could get the list and walk it myself directly, is definitely wrong. >>> The views know that contacts 301 to 309 are displayed. It's the view that >>> knows where to cut. In fact, there's nothing to cut, since all the view >>> does is ask the driver for the contects it needs. >> How do you number the contacts in a sane way? > > These numbers are here for the demonstration. I agree that numbers probably > are not so well adapted to real address books. > > You could use "markers". I think that all address books use contact UIDs. A > given UID could be used to mark the place where the address book stopped > "last time". Notice that the only place where you call the _get_contacts function is when you first populate the book. The rest of the time you don't want to know. > For most usage you do not even need anything. Most operation is sequential. > Take for example searching. Usually you browse all records and only keep in > the result list the ones that match. Most operations are sequential when the book is static. When your contacts go online/offline/whatever, that certainly is random access, and I can tell you a first/current/next approach doesn't fly in such a situation. >>> The search result could handle much more detailed information. >> Of course it cannot. Your search result is a book which needs to be able >> to show avahi contacts, sip contacts, call history contacts, etc... so >> it can only show the contacts as generic. > > Why would you be unable to display detailed information about objects which > you only know as generic? > > while (genericContact = nextContact()) > { > if (genericContact->book()->canSubscribeContacts()) > proposeSubscription(genericContact); > ... > } Yes, of course. You put everything at the high level, something which I already stressed was very very bad. Let's try an example. A text editor will just access files. It won't wonder if they are local or remote, it won't wonder about where the data really is on disk, need caching, etc. This is the job of the low-level system. The text editor doesn't have functions and tests to handle all of the various situations possible. High level is high, it doesn't take mud baths with the details, it doesn't handle them. It delegates them to the low level. >> The view which is specific to an addressbook, of course can show the >> data from the specific contact associated to it. But the generic view >> can only show generic information. > > Wrong ;-). Partially wrong. The generic view can indeed get access to some specific features (like the menus I explained). But it certainly *must* not get them by handling *all* possible situations. >>> class addressBook >>> { >>> virtual bool isReadOnly() = 0; >>> virtual bool canSubscribeContacts() = 0; >>> ... >>> }; >> No, that is wrong and I already explained why. Putting everything in the >> base class is bad. > > Do you realize that the above is not an implementation? It's just an API > definition. Those are pure virtual methods. Everything is implemented in the > derived subclasses. > > Such style of coding is very classical, good, C++ (or java). Such style of coding is not classical, is bad and evil. I see abstractions layers everywhere to hide the details of the lower level, and you want to push those details high up the stack. >>> In your example, a signal is not needed. >>> >>> Knowing that there is no VoIP number in the current contact is enough. >> That is wrong. The same contact could update itself and gain it. Or >> update itself and lose it. > > I should have added "at a given time". > >> Which means : >> 1) *all* of the addressbooks would by default have *all* the possible >> apis for such capability by default, with a isAbleToDoFoo function for >> each Foo capability ; > > No. Defining pure virtual functions in the base class does not mean that you > implement a function in the derived class. If it can't do something, and lets > the engine know it, then it can't ;-). You push all the code to the high level, and never really abstract. That is very wrong. >> 2) if an addressbook needs a new capability, we'll have to modify the >> base addressbook to add it in for it ; it won't just be a matter for the >> new code to add only what is necessary for itself in its own files. > > Wrong again, C++ comes with programming techniques that permit to locate the > real implementations in the derived classes. If I add a new addressbook type with a Foo capability, your designs says I have to modify the base class and add: bool canDoFoo (); void pleaseDoFooThisWay (...); void pleaseDoFooThisOtherWay (...); void etcFoo (...) (with all the virtual pure syntactic crap needed) My idea of right design is that if the new addressbook is the only one needing Foo, it will handle it himself (through a specific api that its view and controller will know and use). >> I think you are focused on an addressbook as something both very big and >> very static, which explains many of our divergences. > > I think that we are both wrong here ;-). An address book could be big (which > you underestimated), and it could be moving (which I underestimated). I agree I have issues seeing how to do things *properly* with a very large addressbook. >> Yes, that's it. The high-level code doesn't know what an AvahiContact or >> EDSContact is ; it only knows avbout GmContact. That means it cannot do >> fancy things with them, and has to call functions on them to do anything >> interesting. > > I have a view that is not so far away. The book just knows contacts. Virtual > methods and subclassing both the book and the contacts does the rest. > >> Your high level code is very complex, and has to be modified heavily >> anytime we add a new type of addressbook with new capabilities. > > Yes, but much more generic. It isn't much more generic. It is an awful and indigest mix of all the specific implementations. > And if the same capability exists in a second address book, the code is > already written. Not really. >> Of course, as-is that would mean a lot of code duplication. That's where >> we can use a toolbox ; of which you had an example in the first round of >> sample code I sent in private. > > Ah, you too you can see the duplication problem with your method ;-). > > A tool box... Sounds like a C library ;-). Which are very useful and allow to abstract common work at a lower layer and not take care of it ourselves way up. > I think that we basically foresee the same problems, but you want to do them > in the procedural, C way, and I would like them to be done in the > object-oriented, C++ way. Your view isn't OO, and isn't C++. >> To make it explicit for the -devel- readers, this sample code had a >> function: >> void shared_action_rename (GObject *obj); >> so any object which could be renamed, had only to: >> - have a "name" property ; >> - provide an action which trigerred that function on itself. >> the function handled showing a nice dialog to rename the function. > > Yup. You see functions where I see methods ;-). I see functions spread in maintainable files, with well-separated features and responsibility. You see functions named "methods" stuffed into the same poor base class, which has to handle everything and the rest, and where the limits between everything is blurred. Where I say function and do: gm_contact_do_foo (contact, arguments); you say method and to: contact->do_foo (arguments); which I agree is shorter, but isn't the magical solution you think it is! :-) >> The idea is that of course quite a few objects will have common >> capabilities ; but instead of putting them all in the high level code >> and clutter it with functions and conditional, > > Yes, that would be the logical consequence if we were in C. We are not. We > have virtual methods. You *do* have isReadOnly and canSubscribeContacts, which you will use to do the ifs I said where very wrong, and you will do so at the high level, which is precisely the place where details shouldn't be handled! It isn't a case of leaky abstraction, it is a case of no-abstraction! >> I want to provide the >> bricks which the low-level code will use to build a specific and >> well-fit system. > > You will end up with an engine doing about nothing, and all the work to be > reimplemented again and again in the drivers. Plus painfully shared code in > the "toolbox" to avoid almost identical code where it can be avoided. That's > typical procedural approach. I generally end up with nice layers of functions doing almost nothing, with clean api between the layer, ensuring the code will be pretty maintainable. See lib/gmconf/ for example. We have a nice api in gmconf.h, and an implementation in gmconf-glib.c, which is layered in the same file, with lowlevel functions doing some work, and higher level doing another. Not everything done at the same final level. When I wrote that code, the goal was to make gconf (the gnome configuration management system) optional, so the port to win32 would be easier. I wrote a generic api to handle things, then two implementations *hidden* behind it. Well, at least we both agree I don't handle the case of very large addressbooks very well :-/ Snark From jpuydt@free.fr Fri Jun 16 11:44:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AC28C3B0005 for ; Fri, 16 Jun 2006 11:44:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01534-04 for ; Fri, 16 Jun 2006 11:44:08 -0400 (EDT) Received: from postfix2-c.free.fr (postfix2-c.free.fr [213.228.0.80]) by menubar.gnome.org (Postfix) with ESMTP id E28BA3B0007 for ; Fri, 16 Jun 2006 11:44:07 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by postfix2-c.free.fr (Postfix) with ESMTP id E4AFC458B6CE for ; Fri, 16 Jun 2006 16:07:32 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp6-g19.free.fr (Postfix) with ESMTP id DF5BD2265E for ; Fri, 16 Jun 2006 17:02:28 +0200 (CEST) Message-ID: <4492B888.8060206@free.fr> Date: Fri, 16 Jun 2006 15:56:24 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> In-Reply-To: <4491205F.5070708@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.382 tagged_above=-999 required=2 tests=[AWL=0.217, BAYES_00=-2.599] X-Spam-Score: -2.382 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 15:44:10 -0000 Julien PUYDT a écrit : > ***** ABOUT EVOLUTION-DATA-SERVER > > The evolution-data-server api looks pretty good -- except that it seems > to mainly handle static vcard-based contacts, where I would like to be > able to handle things like. Hmmm... this sentence should have ended with "able to handle things like live contacts with presence (SIP and XMPP)". On the subject of big addressbook handling, I must say what evolution-data-server does is quite nice : they run a query (EQuery) on a book (EBook), which gives them a view of the result (EBookView). That means that they can easily do a partial view of an addressbook, since they control what is seen! While this organisation doesn't suffer from the problem Éric pointed out, it has still a problem : how does one just "search" ? I mean, if your api is "search a book => get a view", how does one make a search which encompasses all books? Snark PS: notice that the current addressbook code happily tries to get all contacts, whatever the size of the addressbook -- and even not asynchronously! From jpuydt@free.fr Sat Jun 17 03:08:50 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 27E423B03CB for ; Sat, 17 Jun 2006 03:08:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11317-07 for ; Sat, 17 Jun 2006 03:08:48 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 068E83B00DE for ; Sat, 17 Jun 2006 03:08:47 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-57-82-249-55-125.adsl.proxad.net [82.249.55.125]) by smtp1-g19.free.fr (Postfix) with ESMTP id CE8E69AA70 for ; Sat, 17 Jun 2006 09:07:34 +0200 (CEST) Message-ID: <4493AA32.5030602@free.fr> Date: Sat, 17 Jun 2006 09:07:30 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> In-Reply-To: <4492B888.8060206@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.586 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599] X-Spam-Score: -2.586 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 07:08:50 -0000 Julien PUYDT a écrit : > While this organisation doesn't suffer from the problem Éric pointed > out, it has still a problem : how does one just "search" ? I mean, if > your api is "search a book => get a view", how does one make a search > which encompasses all books? Ok, I think I'm on something : let's a book have a simple api, where on one side: 1) a book can return a view for itself, which means the view becomes specific, and hence can handle the case of big addressbooks ; 2) a full search function, which will return a new book, restricted to the the search ; again this book has its view, which will handle the case of big searches ; 3) a restricted search function, which will return say at most a hundred contacts matching the string ; this one allows to make a search on all the books, since we are assured we won't be drowned by the number. This organisation would allow a clean approach for the view on a single addressbook, while still having the possibility to have a working "Find a contact" button. Does that looks nicer ? Snark From ebischoff@nerim.net Sat Jun 17 05:24:05 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id ACD5F3B038B for ; Sat, 17 Jun 2006 05:24:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15888-07 for ; Sat, 17 Jun 2006 05:24:02 -0400 (EDT) Received: from kellthuzad.dmz.nerim.net (smtp-dmz-236-saturday.dmz.nerim.net [195.5.254.236]) by menubar.gnome.org (Postfix) with ESMTP id 2C81F3B0809 for ; Sat, 17 Jun 2006 05:24:01 -0400 (EDT) Received: from kraid.nerim.net (smtp-106-saturday.nerim.net [62.4.16.106]) by kellthuzad.dmz.nerim.net (Postfix) with ESMTP id 9BD1139D6B for ; Sat, 17 Jun 2006 11:23:14 +0200 (CEST) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 5A4A940E35 for ; Sat, 17 Jun 2006 11:22:48 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Sat, 17 Jun 2006 11:22:59 +0200 User-Agent: KMail/1.8.2 References: <4491205F.5070708@free.fr> <200606152026.49639.ebischoff@nerim.net> <4491C708.3060203@free.fr> In-Reply-To: <4491C708.3060203@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606171123.00082.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.51 tagged_above=-999 required=2 tests=[AWL=0.089, BAYES_00=-2.599] X-Spam-Score: -2.51 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 09:24:05 -0000 Le Jeudi 15 Juin 2006 22:46, Julien PUYDT a =C3=A9crit=C2=A0: > > OK. So that should not be a requirement, and certainly not a mechanism = at > > the core of the system. Just a nice plus. > > It *must* be at the core of the system. We _do_ want to update the live > data when it changes. Sorry, that was not clear. By "at the core" I meant "necessary for the addr= ess=20 books to work". > > Yes. You could have a few spare contacts before and after the user's > > view. This algorithm is rather common. > > What do "before" and "after" mean ? Records just before and after the ones that are displayed in sequential ord= er. > > I know that it cannot be _that_ bad and that I certainly misunderstood > > something. But what? > > I certainly have issues with big books, and must find some satisfying > way to handle them. But doing function calls to walk on a list where I > could get the list and walk it myself directly, is definitely wrong. What is wrong is to see that as a list ;-). > Most operations are sequential when the book is static. When your > contacts go online/offline/whatever, that certainly is random access, > and I can tell you a first/current/next approach doesn't fly in such a > situation. I would not say "not fly" but it certainly becomes much more acrobatic, I=20 agree. > If I add a new addressbook type with a Foo capability, your designs says > I have to modify the base class and add: > > bool canDoFoo (); > void pleaseDoFooThisWay (...); > void pleaseDoFooThisOtherWay (...); > void etcFoo (...) > (with all the virtual pure syntactic crap needed) This "crap" is a lightweight modification since it is only one function=20 declaration. No implementation. That is done in the subclasses, if necessar= y. > My idea of right design is that if the new addressbook is the only one > needing Foo, it will handle it himself (through a specific api that its > view and controller will know and use). Okay. Perharps the our differences in opinion is not that much on the=20 programming design, but more on what the software has to do. To me, an address book is just an address book, they are not that different= =20 one from the other. Ekiga need to dig through them to show names, categorie= s=20 and to pick up SIP numbers to call the people. I see a relatively homogeneo= us=20 user interface, with more or less the same appearance (if not exactly the=20 same) for the various address books. I have a "unifying" vision. To you, all address books have very strong pecularities and the software ha= s=20 to adapt a lot to each of them, to take them to the maximum of their=20 possibilities. The user will get different display, different menues, and=20 even different functionality. That explains why you want to put everything in the "drivers", while I want= to=20 put a lot of common logic in the "engine". > > I think that we are both wrong here ;-). An address book could be big > > (which you underestimated), and it could be moving (which I > > underestimated). > > I agree I have issues seeing how to do things *properly* with a very > large addressbook. Yes, and I have certainly underestimated the "dynamic" aspect :-(. > Your view isn't OO, and isn't C++. Come on ;-). > You see functions named "methods" stuffed into the same poor base class, No. Again and again, the base class only has declarations. It sees an=20 abstraction of what the address book is. In every C++ book, you can see examples like this class vehicle { virtual void accelerate(int a) =3D 0; ... }; class car : public vehicle { virtual void accelerate(int a); ... }; class plane : public vehicle { virtual void accelerate(int a); ... }; Planes and cars have very different ways to accelerate. Planes can't brake = and=20 cars can't fly, but such designs are clean and very popular. > Well, at least we both agree I don't handle the case of very large > addressbooks very well :-/ Yes, this discussion is not pointless :-). And at the end if you are more comfortable with libraries of C functions th= an=20 with subclassing and virtual functions, it's no problem. After all, it's yo= u=20 who are going to be doing the dirty work (and I think we all thank you for= =20 that!). =2D-=20 Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m=C3=A9dire." (Le concombre masqu=C3=A9, Mandriva) From jpuydt@free.fr Sat Jun 17 15:09:04 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2976B3B0144 for ; Sat, 17 Jun 2006 15:09:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04217-02 for ; Sat, 17 Jun 2006 15:08:59 -0400 (EDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by menubar.gnome.org (Postfix) with ESMTP id BC2893B019D for ; Sat, 17 Jun 2006 15:07:46 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-c.free.fr (Postfix) with ESMTP id 4C9DC1D0C42D for ; Sat, 17 Jun 2006 20:06:22 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-57-82-249-55-125.adsl.proxad.net [82.249.55.125]) by smtp5-g19.free.fr (Postfix) with ESMTP id B65BC26C83 for ; Sat, 17 Jun 2006 21:05:51 +0200 (CEST) Message-ID: <4494528F.2040804@free.fr> Date: Sat, 17 Jun 2006 21:05:51 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <200606152026.49639.ebischoff@nerim.net> <4491C708.3060203@free.fr> <200606171123.00082.ebischoff@nerim.net> In-Reply-To: <200606171123.00082.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.584 tagged_above=-999 required=2 tests=[AWL=0.015, BAYES_00=-2.599] X-Spam-Score: -2.584 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 19:09:04 -0000 Éric Bischoff a écrit : >>> Yes. You could have a few spare contacts before and after the user's >>> view. This algorithm is rather common. >> What do "before" and "after" mean ? > > Records just before and after the ones that are displayed in sequential order. Sequential hurts. >>> I know that it cannot be _that_ bad and that I certainly misunderstood >>> something. But what? >> I certainly have issues with big books, and must find some satisfying >> way to handle them. But doing function calls to walk on a list where I >> could get the list and walk it myself directly, is definitely wrong. > > What is wrong is to see that as a list ;-). Indeed. >> If I add a new addressbook type with a Foo capability, your designs says >> I have to modify the base class and add: >> >> bool canDoFoo (); >> void pleaseDoFooThisWay (...); >> void pleaseDoFooThisOtherWay (...); >> void etcFoo (...) >> (with all the virtual pure syntactic crap needed) > > This "crap" is a lightweight modification since it is only one function > declaration. No implementation. That is done in the subclasses, if necessary. Notice that I used "crap" to describe the syntactic need in C++ to add "virtual" and "= 0" everywhere. And your "lightweight modification" still involves modifying the base class anytime a child class needs something! >> My idea of right design is that if the new addressbook is the only one >> needing Foo, it will handle it himself (through a specific api that its >> view and controller will know and use). > > Okay. Perharps the our differences in opinion is not that much on the > programming design, but more on what the software has to do. > > To me, an address book is just an address book, they are not that different > one from the other. Ekiga need to dig through them to show names, categories > and to pick up SIP numbers to call the people. I see a relatively homogeneous > user interface, with more or less the same appearance (if not exactly the > same) for the various address books. I have a "unifying" vision. > > To you, all address books have very strong pecularities and the software has > to adapt a lot to each of them, to take them to the maximum of their > possibilities. The user will get different display, different menues, and > even different functionality. Well, look at what we have to put already in the addressbooks: - evolution-data-server addressbooks ; - avahi contacts ; - history contacts ; - speeddials. And the future holds : - SIP contacts ; - XMPP contacts. > That explains why you want to put everything in the "drivers", while I want to > put a lot of common logic in the "engine". Your high level is what I call low level : it handles all of the details! >> Your view isn't OO, and isn't C++. > > Come on ;-). > >> You see functions named "methods" stuffed into the same poor base class, > > No. Again and again, the base class only has declarations. It sees an > abstraction of what the address book is. You're still stuffing that in the base class, which is awful. Does the QWidget class have all the methods of all its child already declared? > In every C++ book, you can see examples like this > > class vehicle { > virtual void accelerate(int a) = 0; > ... > }; > > class car : public vehicle { > virtual void accelerate(int a); > ... > }; > > class plane : public vehicle { > virtual void accelerate(int a); > ... > }; > Planes and cars have very different ways to accelerate. Planes can't brake and > cars can't fly, but such designs are clean and very popular. They all accelerate, and that is the reason why having an accelerate method is put as a requirement in the base class. Anyway I since made another proposition which I find neater ; I'm eagerly waiting for your comments on it :-) Snark From siti@orcon.net.nz Sat Jun 17 16:21:14 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 166443B02D7 for ; Sat, 17 Jun 2006 16:21:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06960-02 for ; Sat, 17 Jun 2006 16:21:11 -0400 (EDT) Received: from dbmail-mx3.orcon.co.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 420E03B0769 for ; Sat, 17 Jun 2006 16:21:10 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx3.orcon.co.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k5HKBcBi027983 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 18 Jun 2006 08:11:39 +1200 From: Stephen Cook To: GnomeMeeting development mailing list Content-Type: text/plain Date: Sun, 18 Jun 2006 08:11:38 +1200 Message-Id: <1150575098.10433.5.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx3.orcon.co.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.484 tagged_above=-999 required=2 tests=[AWL=-0.020, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.484 X-Spam-Level: Subject: [GnomeMeeting-devel-list] IAX2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 20:21:14 -0000 Hello, It's been a long time I gave you guys an update. In IAX2 in opal I have got music on hold going which is nice :). I will be doing registration next as this is probably the most important feature for users. Also I have not run in to any stability problems with IAX2. My iax2/ekiga integration is working well as a tester with my asterisk server. It basically has all the functionality there but needs more integration and bug/quirky fixes. Also some refactoring in the future would be nice depending if I get time or not... From jan.schampera@web.de Sat Jun 17 23:26:05 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 973DD3B0089 for ; Sat, 17 Jun 2006 23:26:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21686-02 for ; Sat, 17 Jun 2006 23:26:04 -0400 (EDT) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by menubar.gnome.org (Postfix) with ESMTP id 718E83B0080 for ; Sat, 17 Jun 2006 23:26:04 -0400 (EDT) Received: from fwd28.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1Frm9f-0005mL-03; Sun, 18 Jun 2006 03:32:47 +0200 Received: from mail.home.thebonsai.de (Ee3Yp-Z-ge9I5Mahsz3ULnxaW3DaPSfdXF9f7jCM5sjCj+WYBVPHwg@[84.147.75.32]) by fwd28.sul.t-online.de with esmtp id 1Frm9c-1vtsA40; Sun, 18 Jun 2006 03:32:44 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id 610F16B154 for ; Sun, 18 Jun 2006 03:32:43 +0200 (CEST) Date: Sun, 18 Jun 2006 03:32:42 +0200 From: Jan Schampera To: gnomemeeting-devel-list@gnome.org Message-ID: <20060618033242.5cce3d15@localhost.localdomain> In-Reply-To: <4493AA32.5030602@free.fr> References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> <4493AA32.5030602@free.fr> Organization: private X-Mailer: Sylpheed-Claws 2.2.0 (GTK+ 2.8.18; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: Ee3Yp-Z-ge9I5Mahsz3ULnxaW3DaPSfdXF9f7jCM5sjCj+WYBVPHwg@t-dialin.net X-TOI-MSGID: d12d82d7-adb7-47a8-a0ce-a3a4ced5117e X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.982 tagged_above=-999 required=2 tests=[AWL=0.616, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.982 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 03:26:05 -0000 On Sat, 17 Jun 2006 09:07:30 +0200 Julien PUYDT wrote: > 1) a book can return a view for itself, which means the view becomes > specific, and hence can handle the case of big addressbooks ; And which view would such a book return by default? > 2) a full search function, which will return a new book, restricted > to the the search ; again this book has its view, which will handle > the case of big searches ; ACK > 3) a restricted search function, which will return say at most a > hundred contacts matching the string ; this one allows to make a > search on all the books, since we are assured we won't be drowned by > the number. > Does that looks nicer ? Yip. J. -- God is real... unless declared as integer. From jpuydt@free.fr Sun Jun 18 06:22:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8B7533B09FC for ; Sun, 18 Jun 2006 06:22:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18409-03 for ; Sun, 18 Jun 2006 06:22:08 -0400 (EDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by menubar.gnome.org (Postfix) with ESMTP id 03CAF3B0956 for ; Sun, 18 Jun 2006 06:22:07 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-c.free.fr (Postfix) with ESMTP id B13A21D0A67F for ; Sun, 18 Jun 2006 11:20:11 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-30-82-253-152-157.adsl.proxad.net [82.253.152.157]) by smtp5-g19.free.fr (Postfix) with ESMTP id 8697F270B8 for ; Sun, 18 Jun 2006 12:19:37 +0200 (CEST) Message-ID: <449528BF.3020104@free.fr> Date: Sun, 18 Jun 2006 12:19:43 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> <4493AA32.5030602@free.fr> <20060618033242.5cce3d15@localhost.localdomain> In-Reply-To: <20060618033242.5cce3d15@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 10:22:10 -0000 Jan Schampera a écrit : >> 1) a book can return a view for itself, which means the view becomes >> specific, and hence can handle the case of big addressbooks ; > And which view would such a book return by default? No default view. I think there should be a GmFullBook class (from which all books which can be displayed fully), and an associated GmFullBookView class, which would then be default for the children. >> Does that looks nicer ? > Yip. Nice. I'm writing some code to showcase things... may take long since I lack time those days :-/ Snark From dsandras@seconix.com Sun Jun 18 15:32:22 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 425673B0114 for ; Sun, 18 Jun 2006 15:32:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08600-02 for ; Sun, 18 Jun 2006 15:32:19 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 178373B0009 for ; Sun, 18 Jun 2006 15:32:18 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id EF61583C26 for ; Sun, 18 Jun 2006 21:11:21 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03870-02 for ; Sun, 18 Jun 2006 21:11:15 +0200 (CEST) Received: from [192.168.0.161] (206-158.242.81.adsl.skynet.be [81.242.158.206]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 657C683C23 for ; Sun, 18 Jun 2006 21:11:15 +0200 (CEST) From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <1150575098.10433.5.camel@siti> References: <1150575098.10433.5.camel@siti> Content-Type: text/plain; charset=ISO-8859-15 Date: Sun, 18 Jun 2006 21:31:27 +0200 Message-Id: <1150659087.2477.3.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.256 tagged_above=-999 required=2 tests=[AWL=0.208, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.256 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] IAX2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 19:32:22 -0000 Le dimanche 18 juin 2006 à 08:11 +1200, Stephen Cook a écrit : > Hello, > > It's been a long time I gave you guys an update. > > In IAX2 in opal I have got music on hold going which is nice :). I will > be doing registration next as this is probably the most important > feature for users. Also I have not run in to any stability problems > with IAX2. > > My iax2/ekiga integration is working well as a tester with my asterisk > server. It basically has all the functionality there but needs more > integration and bug/quirky fixes. Also some refactoring in the future > would be nice depending if I get time or not... Hi, I've seen Derek committed some code from you. I think it is important that you keep a repository with your patches so that we really know what you have fixed/added for Google SoC. (Actually, I should see the patches, even though it is perfectly acceptable that Derek commits them). Thank you, -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From gcgagd-gnomemeeting-devel-list@m.gmane.org Sun Jun 18 16:15:08 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8DDA23B0114 for ; Sun, 18 Jun 2006 16:15:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09248-09 for ; Sun, 18 Jun 2006 16:15:07 -0400 (EDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by menubar.gnome.org (Postfix) with ESMTP id 662BD3B00B2 for ; Sun, 18 Jun 2006 16:15:07 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Fs3eO-0006gT-LO for gnomemeeting-devel-list@gnome.org; Sun, 18 Jun 2006 22:13:40 +0200 Received: from jupiter.physics.ubc.ca ([142.103.234.78]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Jun 2006 22:13:40 +0200 Received: from johan_brn by jupiter.physics.ubc.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Jun 2006 22:13:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gnomemeeting-devel-list@gnome.org From: Johan Brannlund Date: Sun, 18 Jun 2006 13:13:29 -0700 Lines: 22 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: jupiter.physics.ubc.ca User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux)) Sender: news X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.752 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_YAHOO_RCVD=1.849, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.752 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Main window size X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 20:15:08 -0000 I posted the below as a wishlist bug, but apparently the developers prefer carrying out the discussion on this mailing list. This is what I wrote: "I just tried the 20060615 cvs snapshot of ekiga, and it's getting better all the time. I have a small request though: I don't use video, which means that the main window is much bigger than it has to be. Would it be possible to add a resizing widget, or to automatically make the window smaller when video is disabled?" Damien also added the following comment: "I would also say that it will look less bigger when having a contacts list. :) " ... which I don't quite understand. At least in my snapshot, the contacts are in a separate window. Regards, Johan From siti@orcon.net.nz Sun Jun 18 21:23:06 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 415B73B0387 for ; Sun, 18 Jun 2006 21:23:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18559-06 for ; Sun, 18 Jun 2006 21:23:01 -0400 (EDT) Received: from dbmail-mx2.orcon.net.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 66E1B3B0196 for ; Sun, 18 Jun 2006 21:23:01 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx2.orcon.net.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k5J1Lujn017301 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 19 Jun 2006 13:21:57 +1200 From: Stephen Cook To: GnomeMeeting development mailing list In-Reply-To: <1150659087.2477.3.camel@golgoth01> References: <1150575098.10433.5.camel@siti> <1150659087.2477.3.camel@golgoth01> Content-Type: text/plain; charset=utf-8 Date: Mon, 19 Jun 2006 13:21:55 +1200 Message-Id: <1150680115.31741.1.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx2.orcon.net.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.547 tagged_above=-999 required=2 tests=[AWL=0.052, BAYES_00=-2.599] X-Spam-Score: -2.547 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] IAX2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 01:23:06 -0000 On Sun, 2006-06-18 at 21:31 +0200, Damien Sandras wrote: > Le dimanche 18 juin 2006 à 08:11 +1200, Stephen Cook a écrit : > > Hello, > > > > It's been a long time I gave you guys an update. > > > > In IAX2 in opal I have got music on hold going which is nice :). I will > > be doing registration next as this is probably the most important > > feature for users. Also I have not run in to any stability problems > > with IAX2. > > > > My iax2/ekiga integration is working well as a tester with my asterisk > > server. It basically has all the functionality there but needs more > > integration and bug/quirky fixes. Also some refactoring in the future > > would be nice depending if I get time or not... > > Hi, > > > I've seen Derek committed some code from you. > > I think it is important that you keep a repository with your patches so > that we really know what you have fixed/added for Google SoC. > (Actually, I should see the patches, even though it is perfectly > acceptable that Derek commits them). I'll try and get you to review them first. I'll also put the patches on my website and give you guys a link soon. > > Thank you, From jpuydt@free.fr Mon Jun 19 01:26:43 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E9CF83B09E1 for ; Mon, 19 Jun 2006 01:26:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25898-10 for ; Mon, 19 Jun 2006 01:26:41 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 737143B03C7 for ; Mon, 19 Jun 2006 01:26:41 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-60-82-254-197-114.adsl.proxad.net [82.254.197.114]) by smtp1-g19.free.fr (Postfix) with ESMTP id C5B1D10170 for ; Mon, 19 Jun 2006 07:25:07 +0200 (CEST) Message-ID: <44963539.6080309@free.fr> Date: Mon, 19 Jun 2006 07:25:13 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.567 tagged_above=-999 required=2 tests=[AWL=0.032, BAYES_00=-2.599] X-Spam-Score: -2.567 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Main window size X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 05:26:43 -0000 Johan Brannlund a écrit : > I posted the below as a wishlist bug, but apparently the developers prefer > carrying out the discussion on this mailing list. This is what I wrote: Well, bug reports are nice for a beta or a stable release ; during the development cycle, discussing on the -devel- mailing-list is better (especially right at the beginning). :-) > "I just tried the 20060615 cvs snapshot of ekiga, and it's getting better > all the time. I have a small request though: I don't use video, which > means that the main window is much bigger than it has to be. > > Would it be possible to add a resizing widget, or to automatically make the > window smaller when video is disabled?" > > Damien also added the following comment: > > "I would also say that it will look less bigger when having a contacts > list. :) " > > ... which I don't quite understand. At least in my snapshot, the contacts > are in a separate window. He means that you should see some of your contacts in the main window in the future, with presence information about them. Snark From dsandras@seconix.com Mon Jun 19 04:55:21 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 539283B00A5 for ; Mon, 19 Jun 2006 04:55:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01183-02 for ; Mon, 19 Jun 2006 04:55:13 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id CCC843B0004 for ; Mon, 19 Jun 2006 04:55:11 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id D5FC083C1F for ; Mon, 19 Jun 2006 10:34:14 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32316-06 for ; Mon, 19 Jun 2006 10:34:11 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 694B183C1A for ; Mon, 19 Jun 2006 10:34:11 +0200 (CEST) From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44963539.6080309@free.fr> References: <44963539.6080309@free.fr> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 19 Jun 2006 10:54:04 +0200 Message-Id: <1150707244.2904.2.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Main window size X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 08:55:21 -0000 Le lundi 19 juin 2006 à 07:25 +0200, Julien PUYDT a écrit : > Johan Brannlund a écrit : > > I posted the below as a wishlist bug, but apparently the developers prefer > > carrying out the discussion on this mailing list. This is what I wrote: > > Well, bug reports are nice for a beta or a stable release ; during the > development cycle, discussing on the -devel- mailing-list is better > (especially right at the beginning). :-) > Yes, because it is a work in progress. So it will change with time, and get improved. No worries :) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From firstone5@hotmail.com Wed Jun 21 13:09:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C9A9D3B02A4 for ; Wed, 21 Jun 2006 13:09:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23702-03 for ; Wed, 21 Jun 2006 13:09:09 -0400 (EDT) Received: from hotmail.com (bay101-f15.bay101.hotmail.com [64.4.56.25]) by menubar.gnome.org (Postfix) with ESMTP id C2B763B01C1 for ; Wed, 21 Jun 2006 13:09:09 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Jun 2006 10:09:08 -0700 Message-ID: Received: from 64.4.56.200 by by101fd.bay101.hotmail.msn.com with HTTP; Wed, 21 Jun 2006 17:09:07 GMT X-Originating-IP: [69.245.3.192] X-Originating-Email: [firstone5@hotmail.com] X-Sender: firstone5@hotmail.com From: "M. Renee Hopkins" To: gnomemeeting-devel-list@gnome.org Date: Wed, 21 Jun 2006 17:09:07 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 21 Jun 2006 17:09:08.0863 (UTC) FILETIME=[68BD40F0:01C69555] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=0.607 tagged_above=-999 required=2 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: 0.607 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Mingw build of CVS ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:09:11 -0000 Greetings all, I am now building ekiga from cvs with the mingw tools on linux with some success, thanks to help from the list developers and patches. Most all features seem to be working. However, my builds don't detect the videoforwindows devices even though other ekiga.exe (not mine) versions correctly see the camera. Any ideas for missing switches on compile before I began greping through pwlib? I'm rather new to the code so any help is appreciated. Congrads to all developers on great work, MR From dsandras@seconix.com Wed Jun 21 13:42:37 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C742A3B05E9 for ; Wed, 21 Jun 2006 13:42:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25791-05 for ; Wed, 21 Jun 2006 13:42:36 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 0647C3B00B0 for ; Wed, 21 Jun 2006 13:42:35 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id AC0EF83C1C for ; Wed, 21 Jun 2006 19:22:12 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05950-02 for ; Wed, 21 Jun 2006 19:22:11 +0200 (CEST) Received: from [192.168.0.161] (185.1-247-81.adsl-dyn.isp.belgacom.be [81.247.1.185]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id C5DD783C1B for ; Wed, 21 Jun 2006 19:22:10 +0200 (CEST) From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-15 Date: Wed, 21 Jun 2006 19:43:29 +0200 Message-Id: <1150911809.2537.7.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.461 tagged_above=-999 required=2 tests=[AWL=0.003, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.461 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Mingw build of CVS ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:42:38 -0000 Le mercredi 21 juin 2006 à 17:09 +0000, M. Renee Hopkins a écrit : > Greetings all, > > I am now building ekiga from cvs with the mingw tools on linux with some > success, thanks to help from the list developers and patches. > > Most all features seem to be working. However, my builds don't detect the > videoforwindows devices even though other ekiga.exe (not mine) versions > correctly see the camera. > > Any ideas for missing switches on compile before I began greping through > pwlib? > I'm not an expert of the win32 build, but the first guess would be that the pwlib plugins are not compiled in. > I'm rather new to the code so any help is appreciated. > > Congrads to all developers on great work, > MR > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From tonim@telefonica.net Wed Jun 28 04:13:24 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9083D3B0079 for ; Wed, 28 Jun 2006 04:13:24 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31830-06 for ; Wed, 28 Jun 2006 04:13:23 -0400 (EDT) Received: from lothlorienng.sisman.info (157.Red-83-58-24.dynamicIP.rima-tde.net [83.58.24.157]) by menubar.gnome.org (Postfix) with ESMTP id C1F293B0002 for ; Wed, 28 Jun 2006 04:13:22 -0400 (EDT) Received: from gandalf.sisman.info (gandalf.sisman.info [192.168.16.201]) by lothlorienng.sisman.info (Postfix) with ESMTP id B33D71D8437 for ; Wed, 28 Jun 2006 08:18:54 +0200 (CEST) From: Toni Moreno To: gnomemeeting-devel-list@gnome.org In-Reply-To: <1150680115.31741.1.camel@siti> References: <1150575098.10433.5.camel@siti> <1150659087.2477.3.camel@golgoth01> <1150680115.31741.1.camel@siti> Content-Type: text/plain Date: Wed, 28 Jun 2006 08:09:46 +0200 Message-Id: <1151474986.5988.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: Yes, score=2.597 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046, SPF_NEUTRAL=1.069] X-Spam-Score: 2.597 X-Spam-Level: ** X-Spam-Flag: YES Subject: [GnomeMeeting-devel-list] A bit OFF-TOPIC, but usefull X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 08:13:24 -0000 I have found a report of skype, which shows the huge network activity it has (apart from voice network usage). Interesting to pinpoint differences between Skype & Ekiga, or other VoIP hardware phones. Enjoy, and excuse me the off-topic. http://www.ja.net/development/voip/skype&janet.pdf -- Toni Moreno From lurch@gmx.li Thu Jun 29 03:50:09 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A67023B011E for ; Thu, 29 Jun 2006 03:50:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26540-04 for ; Thu, 29 Jun 2006 03:50:02 -0400 (EDT) Received: from asclepius.uwa.edu.au (unknown [130.95.128.56]) by menubar.gnome.org (Postfix) with ESMTP id 6733A3B04C2 for ; Thu, 29 Jun 2006 03:50:01 -0400 (EDT) Received: from asclepius.kas (localhost.localdomain [127.0.0.1]) by asclepius.uwa.edu.au (Postfix) with SMTP id E6028183A6F for ; Thu, 29 Jun 2006 15:49:45 +0800 (WST) Received: from asclepius (localhost.localdomain [127.0.0.1]) by asclepius.prekas (Postfix) with SMTP id CC7321841AD for ; Thu, 29 Jun 2006 15:49:45 +0800 (WST) X-UWA-Client-IP: 130.95.28.15 (UWA) Received: from ns1.watri.uwa.edu.au (ns1.watri.org.au [130.95.28.15]) by asclepius.extinput (Postfix) with ESMTP id B3012183CC9 for ; Thu, 29 Jun 2006 15:49:45 +0800 (WST) Received: from [130.95.29.76] (gluttony.watri.org.au [130.95.29.76]) by ns1.watri.uwa.edu.au (8.13.1/8.13.1) with ESMTP id k5T7nflM013861 for ; Thu, 29 Jun 2006 15:49:44 +0800 (WST) Message-ID: <44A386D4.8040708@gmx.li> Date: Thu, 29 Jun 2006 15:52:52 +0800 From: =?ISO-8859-1?Q?Stefan_Br=FCns?= User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <200606081002.37875.conrad_videokonferenz@gmx.de> <1150380224.6599.22.camel@ganymede.verfaction.de> In-Reply-To: <1150380224.6599.22.camel@ganymede.verfaction.de> Content-Type: multipart/mixed; boundary="------------030008030501050603080306" X-SpamTest-Info: Profile: Formal (405/060628) X-SpamTest-Info: Profile: Detect Hard [UCS 290904] X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking Spam - Subject (UCS) [02-08-04] X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.358 tagged_above=-999 required=2 tests=[AWL=-0.036, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142] X-Spam-Score: -1.358 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 07:50:09 -0000 This is a multi-part message in MIME format. --------------030008030501050603080306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> The last version I can install using apt-get a couple of days old (May 25 - or >> somethin) - at least this is a version with the nonfunctional German locale. >> (defaults to English) >> >> What's up? > > > /me is having a sheer lack of time and thus it took me a while to get > everything polished and fixed just like i love to have it. =) > Everything should be back to normal as of tonight (eventually sarge cvs > snaps and win32 will remain for the weekend - we'll see) I think I have found the problem with the missing tranlations - it is caused by the recent change from the ALL_LINGUAS variable to the po/LINGUAS file. Patch attached. @Kilian: can you try the patch and submit it upstream, if successfull? Lurchi --------------030008030501050603080306 Content-Type: text/plain; name="configure_in_fix_all_linguas.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="configure_in_fix_all_linguas.diff" --- configure.in_orig 2006-06-29 07:59:40.000000000 +0200 +++ configure.in 2006-06-29 09:10:08.000000000 +0200 @@ -527,7 +527,8 @@ dnl Support for internationalization dnl ######################################################################## AC_SUBST([CONFIG_STATUS_DEPENDENCIES],['$(top_srcdir)/po/LINGUAS']) -ALL_LINGUAS="`grep -v '^#' "$srcdir/po/LINGUAS"`" +# ALL_LINGUAS="`grep -v '^#' "$srcdir/po/LINGUAS"`" +ALL_LINGUAS="`sed -ne '/\#.*/ d; H; $ {x; s/^\\n//g; s/\\n/ /g; p}' "$srcdir/po/LINGUAS"`" GETTEXT_PACKAGE=AC_PACKAGE_NAME AC_SUBST(GETTEXT_PACKAGE) --------------030008030501050603080306-- From jpuydt@free.fr Thu Jun 29 06:15:38 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0617C3B050F for ; Thu, 29 Jun 2006 06:15:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03057-05 for ; Thu, 29 Jun 2006 06:15:36 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 17C0C3B02CE for ; Thu, 29 Jun 2006 06:15:36 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-61-82-250-109-134.adsl.proxad.net [82.250.109.134]) by smtp5-g19.free.fr (Postfix) with ESMTP id 08B3E27766 for ; Thu, 29 Jun 2006 12:15:34 +0200 (CEST) Message-ID: <44A3A865.7000201@free.fr> Date: Thu, 29 Jun 2006 12:16:05 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <200606081002.37875.conrad_videokonferenz@gmx.de> <1150380224.6599.22.camel@ganymede.verfaction.de> <44A386D4.8040708@gmx.li> In-Reply-To: <44A386D4.8040708@gmx.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.596 tagged_above=-999 required=2 tests=[AWL=0.003, BAYES_00=-2.599] X-Spam-Score: -2.596 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 10:15:38 -0000 Stefan Brüns a écrit : > @Kilian: can you try the patch and submit it upstream, if successfull? You can call me "Snark", you know ;-) Snark From jpuydt@free.fr Thu Jun 29 06:20:46 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5F2F33B0286 for ; Thu, 29 Jun 2006 06:20:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03470-04 for ; Thu, 29 Jun 2006 06:20:45 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 5A2F43B01CE for ; Thu, 29 Jun 2006 06:20:45 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-61-82-250-109-134.adsl.proxad.net [82.250.109.134]) by smtp5-g19.free.fr (Postfix) with ESMTP id 4DBBF2765B for ; Thu, 29 Jun 2006 12:20:44 +0200 (CEST) Message-ID: <44A3A99B.8030605@free.fr> Date: Thu, 29 Jun 2006 12:21:15 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <200606081002.37875.conrad_videokonferenz@gmx.de> <1150380224.6599.22.camel@ganymede.verfaction.de> <44A386D4.8040708@gmx.li> <44A3A865.7000201@free.fr> In-Reply-To: <44A3A865.7000201@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.596 tagged_above=-999 required=2 tests=[AWL=0.003, BAYES_00=-2.599] X-Spam-Score: -2.596 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 10:20:46 -0000 Julien PUYDT a écrit : > Stefan Brüns a écrit : >> @Kilian: can you try the patch and submit it upstream, if successfull? > > You can call me "Snark", you know ;-) Hmmmm... which "upstream" are we talking about ? :-) /me should read before answering ;-) Snark From dsandras@seconix.com Thu Jun 1 02:40:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F28C93B00EB for ; Thu, 1 Jun 2006 02:40:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10407-03 for ; Thu, 1 Jun 2006 02:40:07 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 9FA173B00CB for ; Thu, 1 Jun 2006 02:40:06 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id DE1A2496FC for ; Thu, 1 Jun 2006 08:23:55 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15636-08 for ; Thu, 1 Jun 2006 08:23:54 +0200 (CEST) Received: from [172.16.100.156] (tcts.fpms.ac.be [193.190.194.194]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 0CBC0496FB for ; Thu, 1 Jun 2006 08:23:54 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <447DF183.3090300@cs.stanford.edu> References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-15 Date: Thu, 01 Jun 2006 08:41:01 +0200 Message-Id: <1149144061.2457.4.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 06:40:10 -0000 Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > I'd imagine it would work on win32, but don't know. > Probably. > I'll work on the patches. > > Where's the right place to add required libraries like openGL? In configure.in. > configure.in seems to be autogenerated by something, but whatever it is > doesn't seem to be in the CVS snapshot... > configure.in is in the CVS snapshot. > Thanks, > > -Dan > > Julien PUYDT wrote: > > > Dan Sandberg a écrit : > > > >> How should we proceed? I could just send you an updated gui/main.cpp > >> file... > > > > > > I'd like to see patches instead of full files, preferably independant > > on each others. > > > > There's also the question of the portability of this : since you > > mention SDL, I guess this will work great on win32 too ? > > > > Snark > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From hoglet@solit.se Thu Jun 1 09:09:47 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 90B2B3B017F for ; Thu, 1 Jun 2006 09:09:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04710-03 for ; Thu, 1 Jun 2006 09:09:45 -0400 (EDT) Received: from aurian.solit.se (unknown [82.182.216.174]) by menubar.gnome.org (Postfix) with ESMTP id 63B703B0134 for ; Thu, 1 Jun 2006 09:09:45 -0400 (EDT) Received: from ip76.kassjo.se ([85.11.28.76] helo=localhost.localdomain) by aurian.solit.se with asmtp (Exim 3.35 #1 (Debian)) id 1Flmvj-0004Et-00 for ; Thu, 01 Jun 2006 15:09:39 +0200 Date: Thu, 1 Jun 2006 15:09:38 +0200 From: Kent Asplund To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Re: Ekiga branched Message-Id: <20060601150938.fcdea791.hoglet@solit.se> In-Reply-To: <1148209984.2488.26.camel@golgoth01> References: <1147894199.7225.2.camel@golgoth01> <1148207277.6654.0.camel@frobisher.madeley.id.au> <1148209984.2488.26.camel@golgoth01> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: ej spam, SpamAssassin (resultat=-4.4, krav 5, IN_REP_TO -4.43) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.832 tagged_above=-999 required=2 tests=[AWL=-0.510, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142] X-Spam-Score: -1.832 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:09:47 -0000 --Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 21 May 2006 13:13:04 +0200 Damien Sandras wrote: > Le dimanche 21 mai 2006 =E0 18:27 +0800, Davyd Madeley a =E9crit : > > On Wed, 2006-05-17 at 21:29 +0200, Damien Sandras wrote: > >=20 > > > I have created a new branch named "gnome-2-14" for Ekiga from the > > > current CVS HEAD. > >=20 > > What are your exciting plans for the next Ekiga? > >=20 >=20 > Most of the plans are on http://wiki.ekiga.org, but I would summarize it > by those big features : > - New user interface I have some problems selling Ekiga to my wife an mother-in-law because it lacks the list of contacts you are about to implement. Another detail is the "contact" button that they did not see as intuitive. Exchanging the button to a green phone handle (red when calling in progress) would make it more alike others and therefore easier to accept. Greetings /Kent --=20 Killing time murders opportunities. --Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEfucS4WZLcIH5l3kRAm+MAJ95cAJ7mAiuBBLrCdfk7vNFTiLv7ACeKWZd 6tzVdWbow84O8RfCFvm51AU= =lD5w -----END PGP SIGNATURE----- --Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ-- From jpuydt@free.fr Thu Jun 1 09:20:42 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 792AE3B01C4 for ; Thu, 1 Jun 2006 09:20:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05042-09 for ; Thu, 1 Jun 2006 09:20:38 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 505C93B01E3 for ; Thu, 1 Jun 2006 09:20:37 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-30-82-253-132-170.adsl.proxad.net [82.253.132.170]) by smtp1-g19.free.fr (Postfix) with ESMTP id DA3499ADFF for ; Thu, 1 Jun 2006 15:20:35 +0200 (CEST) Message-ID: <447EE9BE.5030005@free.fr> Date: Thu, 01 Jun 2006 15:21:02 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Re: Ekiga branched References: <1147894199.7225.2.camel@golgoth01> <1148207277.6654.0.camel@frobisher.madeley.id.au> <1148209984.2488.26.camel@golgoth01> <20060601150938.fcdea791.hoglet@solit.se> In-Reply-To: <20060601150938.fcdea791.hoglet@solit.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599] X-Spam-Score: -2.561 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:20:42 -0000 Kent Asplund a écrit : > Exchanging the button to a green phone handle (red when calling in > progress) would make it more alike others and therefore easier to > accept. The classic case of "your flying car lacks a spare wheel!" ;-) Snark From jan.schampera@web.de Thu Jun 1 12:03:48 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B922E3B0E4B for ; Thu, 1 Jun 2006 12:03:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18635-04 for ; Thu, 1 Jun 2006 12:03:47 -0400 (EDT) Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by menubar.gnome.org (Postfix) with ESMTP id EBE813B0E61 for ; Thu, 1 Jun 2006 12:01:39 -0400 (EDT) Received: from fwd29.aul.t-online.de by mailout05.sul.t-online.com with smtp id 1FlpcA-0003xH-07; Thu, 01 Jun 2006 18:01:38 +0200 Received: from mail.home.thebonsai.de (VypBOcZSYex2PaURfsq4FLxwkOKh2FKpRdjn4Nur7iMG3ImbsTH1w4@[84.147.102.147]) by fwd29.sul.t-online.de with esmtp id 1FlpO1-0yxMBM0; Thu, 1 Jun 2006 17:47:01 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id E08C06B173 for ; Thu, 1 Jun 2006 17:47:00 +0200 (CEST) Date: Thu, 1 Jun 2006 17:44:27 +0200 From: Jan Schampera To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode Message-ID: <20060601174427.48266dee@localhost.localdomain> In-Reply-To: <447DE4E2.7040204@cs.stanford.edu> References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> Organization: private X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: VypBOcZSYex2PaURfsq4FLxwkOKh2FKpRdjn4Nur7iMG3ImbsTH1w4@t-dialin.net X-TOI-MSGID: e6494e3b-869b-447f-a832-f769a200d3af X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.942 tagged_above=-999 required=2 tests=[AWL=0.656, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.942 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:03:48 -0000 On Wed, 31 May 2006 11:48:02 -0700 Dan Sandberg wrote: > 2) Replace the SDL/GTK/GDK calls that do the full screen resizing with > OpenGL ones. [ This is done, needs to be integrated ] Guess that's the key I searched for, when I measured those performance problems. Something that is "usually" installed on the user's machines and that has more power then GDK/SDL (I was afraid to raise yet another exotic dependancy, but OpenGL seems fair enough). J. -- "Be liberal in what you accept, and conservative in what you send." - J. B. Postel, master of the net. From siti@orcon.net.nz Fri Jun 2 05:53:55 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5C8803B10AE for ; Fri, 2 Jun 2006 05:53:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15897-03 for ; Fri, 2 Jun 2006 05:53:53 -0400 (EDT) Received: from dbmail-mx4.orcon.co.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 1A8E13B0EB6 for ; Fri, 2 Jun 2006 05:53:52 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx4.orcon.co.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k529rnLs032645 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 2 Jun 2006 21:53:50 +1200 From: Stephen Cook To: GnomeMeeting development mailing list Content-Type: text/plain Date: Fri, 02 Jun 2006 21:55:24 +1200 Message-Id: <1149242124.4509.17.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.2/1506/Fri Jun 2 16:01:20 2006 on dbmail-mx4.orcon.co.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: Subject: [GnomeMeeting-devel-list] IAX2 In Ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 09:53:55 -0000 Hi, I haven't introduced myself here before, I am Stephen Cook (siti). My proposal for implementing IAX2 in ekiga got accepted with google's summer of code. To give an update (I'll try and keep you guys regularly posted as to what's happening, any problems etc.). Currently I have been looking at the code to gain an understanding of ekiga and opal's code and design. Also obviously checking out the IAX2 code in opal :). From what I have seen and got working, I will work on getting IAX2 going in ekiga first. The main part of this will obviously involve writing a gnome meeting endpoint for IAX2. One key problem I have identified is the accounts code. The protocols are tightly integrated with how it works. I could either refactor this code to loosen the integration or hack iax2 support in there and refactor it later ;). The advantage of this refactored will be when someone wants to add Xmpp/libjingle support, or some other protocol down the track. Well, please tell me your thoughts and comments on this project. -Stephen From x@cs.stanford.edu Fri Jun 2 06:04:24 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0CBE83B0EB6 for ; Fri, 2 Jun 2006 06:04:24 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16680-02 for ; Fri, 2 Jun 2006 06:04:22 -0400 (EDT) Received: from smtp102.plus.mail.mud.yahoo.com (smtp102.plus.mail.mud.yahoo.com [68.142.206.235]) by menubar.gnome.org (Postfix) with SMTP id 1A3583B0490 for ; Fri, 2 Jun 2006 06:04:22 -0400 (EDT) Received: (qmail 57482 invoked from network); 2 Jun 2006 10:04:21 -0000 Received: from unknown (HELO ?192.168.2.47?) (dan?sandberg@71.138.128.214 with plain) by smtp102.plus.mail.mud.yahoo.com with SMTP; 2 Jun 2006 10:04:20 -0000 Message-ID: <44800CFA.5090800@cs.stanford.edu> Date: Fri, 02 Jun 2006 03:03:38 -0700 From: Dan Sandberg User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> In-Reply-To: <1149144061.2457.4.camel@golgoth01> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.808 tagged_above=-999 required=2 tests=[AWL=-0.593, BAYES_00=-2.599, SPF_SOFTFAIL=1.384] X-Spam-Score: -1.808 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 10:04:24 -0000 So configure.in is hand-generated? Surprising. 1) How exactly do I add the opengl ( libgl ) library? 2) Xrandr is mentioned in the Makefile, but is not in configure.in. How exactly does it get put into the Makefile? 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I didn't want to code against a moving target. Thanks, -Dan Damien Sandras wrote: >Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > > >>I'd imagine it would work on win32, but don't know. >> >> >> > >Probably. > > > >>I'll work on the patches. >> >>Where's the right place to add required libraries like openGL? >> >> > >In configure.in. > > > >>configure.in seems to be autogenerated by something, but whatever it is >>doesn't seem to be in the CVS snapshot... >> >> >> > >configure.in is in the CVS snapshot. > > > > >>Thanks, >> >>-Dan >> >>Julien PUYDT wrote: >> >> >> >>>Dan Sandberg a écrit : >>> >>> >>> >>>>How should we proceed? I could just send you an updated gui/main.cpp >>>>file... >>>> >>>> >>>I'd like to see patches instead of full files, preferably independant >>>on each others. >>> >>>There's also the question of the portability of this : since you >>>mention SDL, I guess this will work great on win32 too ? >>> >>>Snark >>>_______________________________________________ >>>Gnomemeeting-devel-list mailing list >>>Gnomemeeting-devel-list@gnome.org >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list >>> >>> >>> >>_______________________________________________ >>Gnomemeeting-devel-list mailing list >>Gnomemeeting-devel-list@gnome.org >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list >> >> From dsandras@seconix.com Fri Jun 2 07:06:22 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9B2253B0407 for ; Fri, 2 Jun 2006 07:06:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20694-02 for ; Fri, 2 Jun 2006 07:06:20 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 830933B0490 for ; Fri, 2 Jun 2006 07:06:20 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 3567C4974A for ; Fri, 2 Jun 2006 12:49:55 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03852-06 for ; Fri, 2 Jun 2006 12:49:51 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 5D9BD49749 for ; Fri, 2 Jun 2006 12:49:51 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <1149242124.4509.17.camel@siti> References: <1149242124.4509.17.camel@siti> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 02 Jun 2006 13:06:14 +0200 Message-Id: <1149246374.2966.25.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:06:22 -0000 Le vendredi 02 juin 2006 à 21:55 +1200, Stephen Cook a écrit : > Hi, > > I haven't introduced myself here before, I am Stephen Cook (siti). My > proposal for implementing IAX2 in ekiga got accepted with google's > summer of code. > > To give an update (I'll try and keep you guys regularly posted as to > what's happening, any problems etc.). > > Currently I have been looking at the code to gain an understanding of > ekiga and opal's code and design. Also obviously checking out the IAX2 > code in opal :). From what I have seen and got working, I will work on > getting IAX2 going in ekiga first. The main part of this will obviously > involve writing a gnome meeting endpoint for IAX2. > I would say that the main part will be to write / finish the IAX2 code in OPAL, either new code, or reusing the current code so that all features that you see in SIP and H.323 are also available for IAX2. Your first project will be to look the limitations of the current code and write a document showing what features you have tested, what work is required to complete them, and what new work is required for new features (Call Hold, Call Transfer, Registering, Call Forward, ...). Writing the endpoint in Ekiga is the last part of the project once the code in OPAL is full functional. Ekiga only contains high-level code. > One key problem I have identified is the accounts code. The protocols > are tightly integrated with how it works. I could either refactor this > code to loosen the integration or hack iax2 support in there and > refactor it later ;). The advantage of this refactored will be when > someone wants to add Xmpp/libjingle support, or some other protocol down > the track. > I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and finally perhaps to a refactoring of the accounts code as it is not the primary purpose of the Google SoC :) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Fri Jun 2 07:08:01 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 243E83B0407 for ; Fri, 2 Jun 2006 07:08:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20781-05 for ; Fri, 2 Jun 2006 07:07:58 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 6C7333B10B6 for ; Fri, 2 Jun 2006 07:07:58 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 5426B49753 for ; Fri, 2 Jun 2006 12:51:33 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06419-06 for ; Fri, 2 Jun 2006 12:51:18 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id EF0D549750 for ; Fri, 2 Jun 2006 12:51:17 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44800CFA.5090800@cs.stanford.edu> References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 02 Jun 2006 13:07:41 +0200 Message-Id: <1149246461.2966.28.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:08:01 -0000 Le vendredi 02 juin 2006 à 03:03 -0700, Dan Sandberg a écrit : > So configure.in is hand-generated? Surprising. > That's te way it works. You write configure.in and configure is generated from there. I guess you are confusing things here. > 1) How exactly do I add the opengl ( libgl ) library? > By writing autconf code in configure.in. No idea exactly how it should be done. > 2) Xrandr is mentioned in the Makefile, but is not in configure.in. How > exactly does it get put into the Makefile? > Probably by an external library that we are using. > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I didn't want > to code against a moving target. > Yes. It is even OK if you do not provide the configure.in code, but only the OpenGL Ekiga code. > Thanks, > > -Dan > > Damien Sandras wrote: > > >Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > > > > > >>I'd imagine it would work on win32, but don't know. > >> > >> > >> > > > >Probably. > > > > > > > >>I'll work on the patches. > >> > >>Where's the right place to add required libraries like openGL? > >> > >> > > > >In configure.in. > > > > > > > >>configure.in seems to be autogenerated by something, but whatever it is > >>doesn't seem to be in the CVS snapshot... > >> > >> > >> > > > >configure.in is in the CVS snapshot. > > > > > > > > > >>Thanks, > >> > >>-Dan > >> > >>Julien PUYDT wrote: > >> > >> > >> > >>>Dan Sandberg a écrit : > >>> > >>> > >>> > >>>>How should we proceed? I could just send you an updated gui/main.cpp > >>>>file... > >>>> > >>>> > >>>I'd like to see patches instead of full files, preferably independant > >>>on each others. > >>> > >>>There's also the question of the portability of this : since you > >>>mention SDL, I guess this will work great on win32 too ? > >>> > >>>Snark > >>>_______________________________________________ > >>>Gnomemeeting-devel-list mailing list > >>>Gnomemeeting-devel-list@gnome.org > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > >>> > >>> > >>> > >>_______________________________________________ > >>Gnomemeeting-devel-list mailing list > >>Gnomemeeting-devel-list@gnome.org > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > >> > >> > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From jpuydt@free.fr Fri Jun 2 09:55:37 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 35E163B0A0B for ; Fri, 2 Jun 2006 09:55:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30481-03 for ; Fri, 2 Jun 2006 09:55:35 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id DF18F3B0468 for ; Fri, 2 Jun 2006 09:55:34 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-30-82-253-132-170.adsl.proxad.net [82.253.132.170]) by smtp6-g19.free.fr (Postfix) with ESMTP id D0F23225C9 for ; Fri, 2 Jun 2006 15:55:31 +0200 (CEST) Message-ID: <44804375.6090107@free.fr> Date: Fri, 02 Jun 2006 15:56:05 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga References: <1149242124.4509.17.camel@siti> <1149246374.2966.25.camel@golgoth01> In-Reply-To: <1149246374.2966.25.camel@golgoth01> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599] X-Spam-Score: -2.561 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 13:55:37 -0000 Damien Sandras a écrit : > I would say that the main part will be to write / finish the IAX2 code > in OPAL, either new code, or reusing the current code so that all > features that you see in SIP and H.323 are also available for IAX2. > > Your first project will be to look the limitations of the current code > and write a document showing what features you have tested, what work is > required to complete them, and what new work is required for new > features (Call Hold, Call Transfer, Registering, Call Forward, ...). > > Writing the endpoint in Ekiga is the last part of the project once the > code in OPAL is full functional. Ekiga only contains high-level code. I don't fully agree with you: writing low-level code all summer long then finally writing the upper-level code, will lead to a non-working feature :-/ Having a least minimal functionality in ekiga would be nice to test the low-level regularly, and see it improving. >> One key problem I have identified is the accounts code. The protocols >> are tightly integrated with how it works. I could either refactor this >> code to loosen the integration or hack iax2 support in there and >> refactor it later ;). The advantage of this refactored will be when >> someone wants to add Xmpp/libjingle support, or some other protocol down >> the track. > > I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and > finally perhaps to a refactoring of the accounts code as it is not the > primary purpose of the Google SoC :) Indeed, the purpose is the IAX2 support, not refactoring the code. I would say that hardcoding the IAX2 account setup in the code would be enough for the SoC. Making it work in the ui in the accounts would be bonus if you had the time, or would be a work to do afterwards. Snark From dsandras@seconix.com Fri Jun 2 10:34:17 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C28113B045D for ; Fri, 2 Jun 2006 10:34:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00352-08 for ; Fri, 2 Jun 2006 10:34:16 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id CE7FF3B0478 for ; Fri, 2 Jun 2006 10:34:15 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 0EFE1496C7 for ; Fri, 2 Jun 2006 16:17:49 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08222-10 for ; Fri, 2 Jun 2006 16:17:42 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 3C897496C6 for ; Fri, 2 Jun 2006 16:17:42 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44804375.6090107@free.fr> References: <1149242124.4509.17.camel@siti> <1149246374.2966.25.camel@golgoth01> <44804375.6090107@free.fr> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 02 Jun 2006 16:34:27 +0200 Message-Id: <1149258867.8383.10.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 14:34:17 -0000 Le vendredi 02 juin 2006 à 15:56 +0200, Julien PUYDT a écrit : > Damien Sandras a écrit : > > I would say that the main part will be to write / finish the IAX2 code > > in OPAL, either new code, or reusing the current code so that all > > features that you see in SIP and H.323 are also available for IAX2. > > > > Your first project will be to look the limitations of the current code > > and write a document showing what features you have tested, what work is > > required to complete them, and what new work is required for new > > features (Call Hold, Call Transfer, Registering, Call Forward, ...). > > > > Writing the endpoint in Ekiga is the last part of the project once the > > code in OPAL is full functional. Ekiga only contains high-level code. > > I don't fully agree with you: writing low-level code all summer long > then finally writing the upper-level code, will lead to a non-working > feature :-/ I agree with you, but you can not start writing the EndPoint if there is no code behind it ;) > > Having a least minimal functionality in ekiga would be nice to test the > low-level regularly, and see it improving. > > >> One key problem I have identified is the accounts code. The protocols > >> are tightly integrated with how it works. I could either refactor this > >> code to loosen the integration or hack iax2 support in there and > >> refactor it later ;). The advantage of this refactored will be when > >> someone wants to add Xmpp/libjingle support, or some other protocol down > >> the track. > > > > I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and > > finally perhaps to a refactoring of the accounts code as it is not the > > primary purpose of the Google SoC :) > > Indeed, the purpose is the IAX2 support, not refactoring the code. I > would say that hardcoding the IAX2 account setup in the code would be > enough for the SoC. > > Making it work in the ui in the accounts would be bonus if you had the > time, or would be a work to do afterwards. > Exactly. > Snark > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From t.schorpp@gmx.de Fri Jun 2 11:06:17 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 63A943B02F7 for ; Fri, 2 Jun 2006 11:06:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02214-08 for ; Fri, 2 Jun 2006 11:06:10 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by menubar.gnome.org (Postfix) with SMTP id 7B6603B0421 for ; Fri, 2 Jun 2006 11:06:09 -0400 (EDT) Received: (qmail invoked by alias); 02 Jun 2006 15:06:08 -0000 Received: from p85.212.150.108.tisdip.tiscali.de (EHLO [192.168.1.100]) [85.212.150.108] by mail.gmx.net (mp001) with SMTP; 02 Jun 2006 17:06:08 +0200 X-Authenticated: #17142692 Message-ID: <448053DE.1010406@gmx.de> Date: Fri, 02 Jun 2006 17:06:06 +0200 From: thomas schorpp User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1 X-Accept-Language: de, en-us MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Bad review about Ekiga References: <1148993400.2400.77.camel@golgoth01> In-Reply-To: <1148993400.2400.77.camel@golgoth01> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.476 tagged_above=-999 required=2 tests=[AWL=-0.011, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] X-Spam-Score: -2.476 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: t.schorpp@gmx.de, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 15:06:17 -0000 Damien Sandras wrote: > http://linux.softpedia.com/progViewUserReviews/156167.html > > This software is a descendant of the former "gnome-meeting" software. It > comes bundled with its own SIP service but claims to work with others. > Unfortunately it has inherited not only the GUI from gnome-meeting but > also the habit to crash every other minute without apparent reason. So I > never got to really test it yet. > > The developers might be better off not making the same mistake as they > did with gnome-meeting and should try to fix all the bugs instead of > adding more crashing bells and whistles. Bad? Bad yes: for marketing. You cant just say this commenter were just too stupid to get the right libs together. Bad no: for development. says You need better CM: - suggest the devs and QA people, users, agree on a certain range of gui libs versions. - suggest meeting with distro maintainers and tight the deps found above to avoid lib/binary inconsistencies. - improve exception handling and fault tolerance on the outside interfaces. ? y tom From craigs@postincrement.com Fri Jun 2 19:57:21 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CDB2A3B11E3 for ; Fri, 2 Jun 2006 19:57:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32469-02 for ; Fri, 2 Jun 2006 19:57:18 -0400 (EDT) Received: from bastion.southeren.com (unknown [220.244.81.10]) by menubar.gnome.org (Postfix) with ESMTP id 870583B11CC for ; Fri, 2 Jun 2006 19:57:17 -0400 (EDT) Received: from [10.0.2.13] (rapido.southeren.com [10.0.2.13]) by bastion.southeren.com (8.12.8/8.12.8) with ESMTP id k52NteJG016237; Sat, 3 Jun 2006 09:55:40 +1000 Date: Sat, 03 Jun 2006 09:55:43 +1000 From: Craig Southeren To: Stephen Cook , GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga In-Reply-To: <1149242124.4509.17.camel@siti> References: <1149242124.4509.17.camel@siti> Message-Id: <20060603095331.79CD.CRAIGS@postincrement.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Becky! ver. 2.11.02 [en] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.939 tagged_above=-999 required=2 tests=[AWL=-0.482, BAYES_00=-2.599, SPF_FAIL=1.142] X-Spam-Score: -1.939 X-Spam-Level: Cc: Derek Smithies X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 23:57:22 -0000 On Fri, 02 Jun 2006 21:55:24 +1200 Stephen Cook wrote: > Hi, >=20 > I haven't introduced myself here before, I am Stephen Cook (siti). My > proposal for implementing IAX2 in ekiga got accepted with google's > summer of code. >=20 > To give an update (I'll try and keep you guys regularly posted as to > what's happening, any problems etc.). >=20 > Currently I have been looking at the code to gain an understanding of > ekiga and opal's code and design. Also obviously checking out the IAX2 > code in opal :). From what I have seen and got working, I will work on > getting IAX2 going in ekiga first. The main part of this will obviously > involve writing a gnome meeting endpoint for IAX2. >=20 > One key problem I have identified is the accounts code. The protocols > are tightly integrated with how it works. I could either refactor this > code to loosen the integration or hack iax2 support in there and > refactor it later ;). The advantage of this refactored will be when > someone wants to add Xmpp/libjingle support, or some other protocol down > the track. >=20 > Well, please tell me your thoughts and comments on this project. As a New Zealander, you are uniquely placed to communicate with the author of the OPAL IAX2 code, Derek Smithies, who is a fellow Kiwi! I am sure that you will be able to get the OPAL IAX2 code working with Ekiga in no time at all with his help.=20 If you have any questions, please contact me directly. Craig ----------------------------------------------------------------------- Craig Southeren Post Increment =96 VoIP Consulting and Software craigs@postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren@hotmail.com Mobile: +61 417231046 =20 "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting From hoglet@solit.se Sat Jun 3 03:46:01 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9178F3B04E8 for ; Sat, 3 Jun 2006 03:46:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19488-05 for ; Sat, 3 Jun 2006 03:45:59 -0400 (EDT) Received: from aurian.solit.se (unknown [82.182.216.174]) by menubar.gnome.org (Postfix) with ESMTP id 9DD3C3B0505 for ; Sat, 3 Jun 2006 03:45:59 -0400 (EDT) Received: from ip76.kassjo.se ([85.11.28.76] helo=localhost.localdomain) by aurian.solit.se with asmtp (Exim 3.35 #1 (Debian)) id 1FmQpW-0006J7-00 for ; Sat, 03 Jun 2006 09:45:54 +0200 Date: Sat, 3 Jun 2006 09:45:50 +0200 From: Kent Asplund To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Bad review about Ekiga Message-Id: <20060603094550.0e1ff8aa.hoglet@solit.se> In-Reply-To: <1148993400.2400.77.camel@golgoth01> References: <1148993400.2400.77.camel@golgoth01> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: ej spam, SpamAssassin (resultat=-4.4, krav 5, IN_REP_TO -4.43) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.898 tagged_above=-999 required=2 tests=[AWL=-1.435, BAYES_20=-0.74, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142] X-Spam-Score: -0.898 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 07:46:01 -0000 --Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 30 May 2006 14:50:00 +0200 Damien Sandras wrote: > http://linux.softpedia.com/progViewUserReviews/156167.html >=20 > This software is a descendant of the former "gnome-meeting" software. It > comes bundled with its own SIP service but claims to work with others. > Unfortunately it has inherited not only the GUI from gnome-meeting but > also the habit to crash every other minute without apparent reason. So I > never got to really test it yet. >=20 > The developers might be better off not making the same mistake as they > did with gnome-meeting and should try to fix all the bugs instead of > adding more crashing bells and whistles. I have never had a crash and the program was easy to setup. I have had some problem but they have been outside of Ekiga (siproxd and firewall) Ekiga has som distance to go to "get finished" but it is still THE BEST PROGRAM AROUND! Subjectively of course :) Waiting patiently for 2.2 /Hoglet --=20 Go ahead... make my day. -- Dirty Harry --Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEgT4x4WZLcIH5l3kRApw3AJ9yPgdPoUSeKGniD1w0w0cMTXajRACfWaDG 2YUvSTxFnaSeD8q0uWWv6zE= =2nFl -----END PGP SIGNATURE----- --Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny-- From hoglet@solit.se Sat Jun 3 03:54:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C25A43B05C8 for ; Sat, 3 Jun 2006 03:54:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19755-10 for ; Sat, 3 Jun 2006 03:54:38 -0400 (EDT) Received: from aurian.solit.se (unknown [82.182.216.174]) by menubar.gnome.org (Postfix) with ESMTP id B980A3B04F9 for ; Sat, 3 Jun 2006 03:54:38 -0400 (EDT) Received: from ip76.kassjo.se ([85.11.28.76] helo=localhost.localdomain) by aurian.solit.se with asmtp (Exim 3.35 #1 (Debian)) id 1FmQxt-0006L4-00 for ; Sat, 03 Jun 2006 09:54:33 +0200 Date: Sat, 3 Jun 2006 09:54:33 +0200 From: Kent Asplund To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Re: Ekiga branched Message-Id: <20060603095433.82461abf.hoglet@solit.se> In-Reply-To: <447EE9BE.5030005@free.fr> References: <1147894199.7225.2.camel@golgoth01> <1148207277.6654.0.camel@frobisher.madeley.id.au> <1148209984.2488.26.camel@golgoth01> <20060601150938.fcdea791.hoglet@solit.se> <447EE9BE.5030005@free.fr> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: ej spam, SpamAssassin (resultat=-4.4, krav 5, IN_REP_TO -4.43) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.764 tagged_above=-999 required=2 tests=[AWL=-0.519, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142, TW_KT=0.077] X-Spam-Score: -1.764 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 07:54:39 -0000 --Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 01 Jun 2006 15:21:02 +0200 Julien PUYDT wrote: > Kent Asplund a =E9crit : > > Exchanging the button to a green phone handle (red when calling in > > progress) would make it more alike others and therefore easier to > > accept. >=20 > The classic case of "your flying car lacks a spare wheel!" ;-) I'm taking the risk of seeming to be completely without humour. No, it is more a case of having a car with automatic gearbox and instead of having a lever you have a button for changing direction.=20 It works perfektly OK but people will think that it is a strange car and choose another one. (I think Citro=EBn had this problem) My wife just said "it is made for nerds not humans" Greetings /Hoglet the nerd --=20 I don't know anything about music. In my line you don't have to. -- Elvis Presley --Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEgUA54WZLcIH5l3kRAiYpAJ4/lkEYFVjWRQrYSvn7D9XmkU+6FgCgiejD m2Sp2AVqfZZHzT5TaBCVu5I= =OH96 -----END PGP SIGNATURE----- --Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ-- From devel@tootai.net Sat Jun 3 11:12:15 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3EF583B05AE for ; Sat, 3 Jun 2006 11:12:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11557-03 for ; Sat, 3 Jun 2006 11:12:10 -0400 (EDT) Received: from mail1.tootai.net (ns1.tootai.net [82.231.69.24]) by menubar.gnome.org (Postfix) with ESMTP id A02F63B0348 for ; Sat, 3 Jun 2006 11:12:09 -0400 (EDT) Received: from [192.168.0.17] (unknown [192.168.0.17]) by mail1.tootai.net (Postfix) with ESMTP id E2ACD398BA0 for ; Sat, 3 Jun 2006 17:12:06 +0200 (CEST) Message-ID: <4481A6AF.2060703@tootai.net> Date: Sat, 03 Jun 2006 17:11:43 +0200 From: Daniel Huhardeaux Organization: TOOTAi User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: GnomeMeeting development mailing list Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: Subject: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 15:12:15 -0000 Resent as it didn't pass at the first try (too big, I cut the begining of logs) Hi all, Ekiga behind a firewall is registering to an asterisk server which is on internet. The sip user is authorized with gsm,ulaw,alaw on asterisk side. When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is started, connection is showed with PCMU (why not GSM?), see the traffic in/out (~6 kB) but have no audio. I hangup the call, the hangup info is shown in the toolbar, PCMU disappear in codec and immediately after, traffic in/out continue with 0/0, icon in KDE Toolbar show Ekiga on line. The only solution I have is to kill Ekiga. If I deactivate GSM codec, everything is fine. Below you will find a d4 output from the call. [...] 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 OpalUDP Ended connect, selecting 82.231.69.24:35065 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP Queueing PDU: 1 INVITE <407> 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP Waiting for PDU on udp$213.203.241.243:5060 2006/06/02 13:12:32.901 0:10.661 SIP Handler:8520268 SIP PDU handler thread started. 2006/06/02 13:12:32.902 0:10.662 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:32.902 0:10.663 SIP Handler:8520268 SIP Handling PDU 1 INVITE <407> (with transaction) 2006/06/02 13:12:32.903 0:10.663 SIP Handler:8520268 SIP Transaction 1 INVITE completed. 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP Sending PDU on udp$213.203.241.243:5060 ACK sip:800@sip.tootai.net SIP/2.0 CSeq: 1 ACK Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bK803b125b-96f0-da11-8388-000ea6217592;rport From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: ;tag=as315809c6 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 70 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP Received Proxy Authentication Required response 2006/06/02 13:12:32.906 0:10.666 SIP Handler:8520268 SIP Transaction 2 INVITE created. 2006/06/02 13:12:32.906 0:10.667 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:33.090 0:10.850 SIP Handler:8520268 RTP_UDP Session 1 created: 82.231.69.24:35010-35011 ssrc=703395120 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 RTP Adding session RTP_UDP 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 SIP Using RTP payload [pt=101] for NTE 2006/06/02 13:12:33.100 0:10.860 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k H.261(QCIF) H.261(CIF) YUV420P RGB32 RGB24 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 2 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 2 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 SIP IsMediaBypassPossible: session 2 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:33.281 0:11.041 SIP Handler:8520268 RTP_UDP Session 2 created: 82.231.69.24:35014-35015 ssrc=2454563097 2006/06/02 13:12:33.282 0:11.042 SIP Handler:8520268 RTP Adding session RTP_UDP 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k H.261(QCIF) H.261(CIF) YUV420P RGB32 RGB24 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 SIP Adding authentication information 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP Sending PDU on udp$213.203.241.243:5060 INVITE sip:800@sip.tootai.net SIP/2.0 Date: Fri, 02 Jun 2006 11:12:32 GMT CSeq: 2 INVITE Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;rport User-Agent: Ekiga/2.0.1-20060521-01 From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: Contact: Proxy-Authorization: Digest username="104", realm="sip.tootai.net", nonce="12d01d5d", uri="sip:800@sip.tootai.net", response="60b65ec9045130eab45495d3c65fbc5e", algorithm=md5 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Type: application/sdp Content-Length: 302 Max-Forwards: 70 v=0 o=- 1149246753 1149246753 IN IP4 82.231.69.24 s=Opal SIP Session c=IN IP4 82.231.69.24 t=0 0 m=audio 35010 RTP/AVP 101 3 0 8 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 m=video 35014 RTP/AVP 31 a=rtpmap:31 H261/90000 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP PDU Received on udp$213.203.241.243:5060 SIP/2.0 100 Trying CSeq: 2 INVITE Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 User-Agent: Asterisk PBX From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP Queueing PDU: 2 INVITE <100> 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP Waiting for PDU on udp$213.203.241.243:5060 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP Handling PDU 2 INVITE <100> (with transaction) 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP Transaction 2 INVITE proceeding. 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Set targetAddress to sip:800@213.203.241.243 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Received Trying response 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP Media session port=7166 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP Adding media session with 2 formats 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP Unknown media attribute silenceSupp:off - - - - 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SIP PDU Received on udp$213.203.241.243:5060 SIP/2.0 200 OK CSeq: 2 INVITE Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 User-Agent: Asterisk PBX From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: ;tag=as5d2831d1 Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Type: application/sdp Content-Length: 221 v=0 o=root 26912 26912 IN IP4 213.203.241.243 s=session c=IN IP4 213.203.241.243 t=0 0 m=audio 7166 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP Queueing PDU: 2 INVITE <200> 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP Waiting for PDU on udp$213.203.241.243:5060 2006/06/02 13:12:33.388 0:11.148 SIP Handler:8520268 SIP Handling PDU 2 INVITE <200> (with transaction) 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP Transaction 2 INVITE completed. 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP Set targetAddress to sip:800@213.203.241.243 2006/06/02 13:12:33.390 0:11.150 SIP Handler:8520268 SIP Adding authentication information 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP Adjusting transport to address udp$213.203.241.243:5060 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP Sending PDU on udp$213.203.241.243:5060 ACK sip:800@213.203.241.243 SIP/2.0 CSeq: 2 ACK Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bK6e2ca15b-96f0-da11-8388-000ea6217592;rport From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: ;tag=as5d2831d1 Contact: Proxy-Authorization: Digest username="104", realm="sip.tootai.net", nonce="12d01d5d", uri="sip:800@213.203.241.243", response="059defd67706254552a5c23eada565b5", algorithm=md5 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 70 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP Received INVITE OK response 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 SIP RTP payload type PCMU matched to codec G.711-uLaw-64k 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 OpalCon OpenSourceMediaStream for session 1 on Call[1]-EP[Default] 2006/06/02 13:12:33.398 0:11.158 SIP Handler:8520268 OpalCon Selected media stream PCM-16 -> G.711-uLaw-64k 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 Call PatchMediaStreams Call[1]-EP[Default] 2006/06/02 13:12:34.196 0:11.957 SIP Handler:8520268 OpalCon OpenSinkMediaStream Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session=1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon OpenSinkMediaStream, selected PCM-16 -> G.711-uLaw-64k 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:34.197 0:11.958 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Patch Added sink from PCM-16 Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 16 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 to G.711-uLaw-64k Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 8 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Codec G711-uLaw-64k encoder created 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Patch Added media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k using transcoder PCM-16->G.711-uLaw-64k 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Media Audio source data size set to 320 bytes and 2 buffers. 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call GetOtherPartyConnection Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon OpenSourceMediaStream for session 1 on Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon Selected media stream G.711-uLaw-64k -> PCM-16 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 Call PatchMediaStreams Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon OpenSinkMediaStream Call[1]-EP[Default] session=1 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon OpenSinkMediaStream, selected G.711-uLaw-64k -> PCM-16 2006/06/02 13:12:34.513 0:12.274 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:34.514 0:12.274 SIP Handler:8520268 Patch Added sink from G.711-uLaw-64k Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 8 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 to PCM-16 Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 16 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Codec G711-uLaw-64k decoder created 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Media Audio sink data size set to 320 bytes and 2 buffers. 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Patch Added media stream sink OpalAudioMediaStream-Sink-PCM-16 using transcoder G.711-uLaw-64k->PCM-16 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.525 0:12.285 SIP Handler:8520268 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.527 0:12.287 SIP Handler:8520268 RTP_UDP SetRemoteSocketInfo: session=1 data channel, new=213.203.241.243:7166, local=82.231.69.24:35010-35011, remote=0.0.0.0:0-0 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 SIP Could not find SDP media description for Video 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 OpalMan OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 Call OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 PCSS SetConnected() 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 GMPCSSEndpoint PCSS connection established 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 GMManager Will establish the connection 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 OpalMan OnEstablished Call[1]-EP[Default] 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 Call OnEstablished Call[1]-EP[Default] 2006/06/02 13:12:34.540 0:12.300 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[Default] G.711-uLaw-64k 2006/06/02 13:12:34.541 0:12.301 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k 2006/06/02 13:12:34.542 0:12.302 SIP Handler:8520268 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.543 0:12.303 SIP Handler:8520268 Call OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] G.711-uLaw-64k 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[Default] 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k 2006/06/02 13:12:34.552 0:12.312 SIP Handler:8520268 Call OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k 2006/06/02 13:12:34.553 0:12.313 Media Patch:8175708 Patch Thread started for Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:34.556 0:12.316 SIP Handler:8520268 Media Starting thread Media Patch:8175708 2006/06/02 13:12:34.557 0:12.317 Media Patch:8527348 Patch Thread started for Patch OpalRTPMediaStream-Source-G.711-uLaw-64k -> OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:34.568 0:12.329 Media Patch:8527348 RTP Jitter buffer created: size=101 delay=160-4000/160 (20ms) obj=0x8526b30 2006/06/02 13:12:34.572 0:12.333 RTP Jitter:8526b30 RTP Jitter RTP receive thread started: 0x8526b30 2006/06/02 13:12:34.574 0:12.334 RTP Jitter:8526b30 RTP First receive data: ver=2 pt=GSM psz=33 m=0 x=0 seq=39915 ts=160 src=824302623 ccnt=0 2006/06/02 13:12:34.580 0:12.341 SIP Handler:8520268 Media Starting thread Media Patch:8527348 2006/06/02 13:12:34.581 0:12.341 SIP Handler:8520268 OpalCon Media stream threads started. 2006/06/02 13:12:34.582 0:12.342 SIP Handler:8520268 OpalCon Media stream threads started. 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP Found existing session 2 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 GMManager Will establish the connection 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 OpalMan OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.607 0:12.367 SIP Handler:8520268 Call OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.610 0:12.371 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:34.648 0:12.408 Media Patch:8527348 RTP Jitter buffer length exceeded 2006/06/02 13:12:34.649 0:12.409 Media Patch:8527348 RTP Jitter buffer length exceed was prior to first write. Not increasing buffer size 2006/06/02 13:12:35.277 0:13.037 Media Patch:8175708 RTP First sent data: ver=2 pt=PCMU psz=160 m=1 x=0 seq=1460 ts=0 src=703395120 ccnt=0 2006/06/02 13:12:35.608 0:13.368 Housekeeper RTP Found existing session 1 2006/06/02 13:12:35.609 0:13.369 Housekeeper RTP Found existing session 2 2006/06/02 13:12:36.137 0:13.898 RTP Jitter:8526b30 RTP Receive statistics: packets=101 octets=3714 lost=0 tooLate=0 order=0 avgTime=15 maxTime=1556 minTime=0 jitter=16 maxJitter=188 2006/06/02 13:12:36.573 0:14.333 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (9760) 2006/06/02 13:12:36.614 0:14.374 Housekeeper RTP Found existing session 1 2006/06/02 13:12:36.615 0:14.375 Housekeeper RTP Found existing session 2 2006/06/02 13:12:36.974 0:14.734 RTP Jitter:8526b30 RTP Jitter buffer continuously full, throwing away entire buffer. 2006/06/02 13:12:36.995 0:14.756 RTP Jitter:8526b30 RTP Jitter buffer full, threw away 21 oldest frames 2006/06/02 13:12:37.374 0:15.134 RTP Jitter:8526b30 RTP Receive statistics: packets=201 octets=19714 lost=0 tooLate=0 order=0 avgTime=12 maxTime=23 minTime=0 jitter=0 maxJitter=188 2006/06/02 13:12:37.620 0:15.380 Housekeeper RTP Found existing session 1 2006/06/02 13:12:37.621 0:15.381 Housekeeper RTP Found existing session 2 2006/06/02 13:12:37.820 0:15.580 Media Patch:8175708 RTP Transmit statistics: packets=101 octets=16160 avgTime=25 maxTime=48 minTime=23 2006/06/02 13:12:38.624 0:16.384 Housekeeper RTP Found existing session 1 2006/06/02 13:12:38.625 0:16.385 Housekeeper RTP Found existing session 2 2006/06/02 13:12:38.993 0:16.753 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (29120) 2006/06/02 13:12:39.374 0:17.134 RTP Jitter:8526b30 RTP Receive statistics: packets=301 octets=35714 lost=0 tooLate=0 order=0 avgTime=20 maxTime=26 minTime=14 jitter=1 maxJitter=188 2006/06/02 13:12:39.395 0:17.155 RTP Jitter:8526b30 RTP Jitter buffer continuously full, throwing away entire buffer. 2006/06/02 13:12:39.415 0:17.176 RTP Jitter:8526b30 RTP Jitter buffer full, threw away 21 oldest frames 2006/06/02 13:12:39.632 0:17.392 Housekeeper RTP Found existing session 1 2006/06/02 13:12:39.633 0:17.393 Housekeeper RTP Found existing session 2 2006/06/02 13:12:40.384 0:18.144 Media Patch:8175708 RTP Transmit statistics: packets=201 octets=32160 avgTime=25 maxTime=44 minTime=22 2006/06/02 13:12:40.640 0:18.400 Housekeeper RTP Found existing session 1 2006/06/02 13:12:40.641 0:18.401 Housekeeper RTP Found existing session 2 2006/06/02 13:12:41.373 0:19.133 RTP Jitter:8526b30 RTP Receive statistics: packets=401 octets=51714 lost=0 tooLate=0 order=0 avgTime=19 maxTime=26 minTime=13 jitter=1 maxJitter=188 2006/06/02 13:12:41.413 0:19.173 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (48480) 2006/06/02 13:12:41.648 0:19.424 Housekeeper RTP Found existing session 1 2006/06/02 13:12:41.665 0:19.425 Housekeeper RTP Found existing session 2 2006/06/02 13:12:41.813 0:19.573 RTP Jitter:8526b30 RTP Jitter buffer continuously full, throwing away entire buffer. 2006/06/02 13:12:41.833 0:19.593 RTP Jitter:8526b30 RTP Jitter buffer full, threw away 21 oldest frames 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP Found existing session 1 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP Found existing session 2 2006/06/02 13:12:42.920 0:20.680 Media Patch:8175708 RTP Transmit statistics: packets=301 octets=48160 avgTime=25 maxTime=49 minTime=22 2006/06/02 13:12:43.378 0:21.139 RTP Jitter:8526b30 RTP Receive statistics: packets=501 octets=67714 lost=0 tooLate=0 order=0 avgTime=20 maxTime=27 minTime=12 jitter=1 maxJitter=188 2006/06/02 13:12:43.696 0:21.457 Housekeeper RTP Found existing session 1 2006/06/02 13:12:43.697 0:21.457 Housekeeper RTP Found existing session 2 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot Call Clearing Call[1] reason=EndedByLocalUser 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot OpalCon Releasing Call[1]-EP[Default] 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon Call end reason for Default set to EndedByLocalUser 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon SetPhase from EstablishedPhase to ReleasingPhase 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon Releasing Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon Call end reason for fa44075b-96f0-da11-8388-000ea6217592@nomade set to EndedByLocalUser 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon SetPhase from EstablishedPhase to ReleasingPhase 2006/06/02 13:12:43.820 0:21.581 OnRelease:856e8a0 OpalCon OnReleased Call[1]-EP[Default] 2006/06/02 13:12:43.822 0:21.583 OnRelease:856e8a0 Media Closing raw media stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.824 0:21.584 OnRelease:856e8a0 Media Closing stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.825 0:21.585 OnRelease:856e8a0 Media Disconnecting OpalAudioMediaStream-Source-PCM-16 from patch thread Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.827 0:21.587 OnRelease:856e8a0 Patch Closing media patch Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.829 0:21.589 OnRelease:856e8a0 Media Closing raw media stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.830 0:21.590 OnRelease:856e8a0 Media Closing stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.831 0:21.591 OnRelease:84f8c00 SIP OnReleased: Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade], phase = ReleasingPhase 2006/06/02 13:12:43.833 0:21.593 OnRelease:84f8c00 OpalCon SetPhase from ReleasingPhase to ReleasingPhase 2006/06/02 13:12:43.834 0:21.594 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (67840) 2006/06/02 13:12:43.836 0:21.596 OnRelease:84f8c00 SIP Transaction 4 BYE created. 2006/06/02 13:12:43.842 0:21.603 OnRelease:84f8c00 Media Closing RTP for OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.844 0:21.604 OnRelease:84f8c00 RTP_UDP Session 1, Shutting down write. 2006/06/02 13:12:43.845 0:21.605 OnRelease:84f8c00 Media Closing stream OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.846 0:21.606 OnRelease:84f8c00 Media Disconnecting OpalRTPMediaStream-Sink-G.711-uLaw-64k from patch thread Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.848 0:21.609 OnRelease:84f8c00 Patch Removing media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.855 0:21.626 OnRelease:84f8c00 Media Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.867 0:21.627 OnRelease:84f8c00 RTP_UDP Session 1, Shutting down read. 2006/06/02 13:12:43.868 0:21.628 OnRelease:84f8c00 Media Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.869 0:21.630 OnRelease:84f8c00 Media Disconnecting OpalRTPMediaStream-Source-G.711-uLaw-64k from patch thread Patch OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.893 0:21.653 Media Patch:8175708 Patch Thread ended for Patch OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.893 0:21.653 OnRelease:84f8c00 Patch Closing media patch Patch OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.916 0:21.676 RTP Jitter:8526b30 RTP_UDP Session 1, Read shutdown. 2006/06/02 13:12:43.917 0:21.677 RTP Jitter:8526b30 RTP Jitter RTP receive thread ended 2006/06/02 13:12:43.917 0:21.677 OnRelease:84f8c00 Media Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.918 0:21.678 OnRelease:84f8c00 RTP_UDP Session 1, Shutting down read. 2006/06/02 13:12:43.919 0:21.679 OnRelease:84f8c00 Media Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.922 0:21.683 OnRelease:856e8a0 Patch Waiting for media patch thread to stop Patch OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.926 0:21.686 OnRelease:856e8a0 Patch Media patch thread Patch OpalAudioMediaStream-Source-PCM-16 destroyed. 2006/06/02 13:12:43.930 0:21.691 OnRelease:856e8a0 Media Closing raw media stream OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:43.932 0:21.693 OnRelease:856e8a0 Media Closing stream OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:43.933 0:21.694 OnRelease:856e8a0 Media Disconnecting OpalAudioMediaStream-Sink-PCM-16 from patch thread Patch OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.956 0:21.717 OnRelease:856e8a0 Patch Removing media stream sink OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP Found existing session 1 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP Found existing session 2 2006/06/02 13:12:45.696 0:23.456 Housekeeper RTP Found existing session 1 2006/06/02 13:12:45.697 0:23.457 Housekeeper RTP Found existing session 2 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP Found existing session 1 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP Found existing session 2 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP Found existing session 1 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP Found existing session 2 2006/06/02 13:12:48.708 0:26.468 Housekeeper RTP Found existing session 1 2006/06/02 13:12:48.709 0:26.469 Housekeeper RTP Found existing session 2 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP Found existing session 1 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP Found existing session 2 2006/06/02 13:12:50.712 0:28.473 Housekeeper RTP Found existing session 1 2006/06/02 13:12:50.713 0:28.473 Housekeeper RTP Found existing session 2 2006/06/02 13:12:51.716 0:29.477 Housekeeper RTP Found existing session 1 2006/06/02 13:12:51.717 0:29.477 Housekeeper RTP Found existing session 2 2006/06/02 13:12:52.716 0:30.477 Housekeeper RTP Found existing session 1 2006/06/02 13:12:52.717 0:30.477 Housekeeper RTP Found existing session 2 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP Found existing session 1 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP Found existing session 2 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP Found existing session 1 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP Found existing session 2 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP Found existing session 1 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP Found existing session 2 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP Found existing session 1 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP Found existing session 2 2006/06/02 13:12:57.733 0:35.493 Housekeeper RTP Found existing session 1 2006/06/02 13:12:57.734 0:35.494 Housekeeper RTP Found existing session 2 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP Found existing session 1 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP Found existing session 2 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP Found existing session 1 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP Found existing session 2 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP Found existing session 1 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP Found existing session 2 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP Found existing session 1 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP Found existing session 2 2006/06/02 13:13:02.777 0:40.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:02.778 0:40.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP Found existing session 2 2006/06/02 13:13:04.369 0:42.129 Housekeeper SIP Set state Terminated_Success for transaction 1 INVITE 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP Found existing session 2 2006/06/02 13:13:05.777 0:43.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:05.777 0:43.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:06.613 0:44.374 Housekeeper SIP Set state Terminated_Success for transaction 2 INVITE 2006/06/02 13:13:06.777 0:44.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:06.778 0:44.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:07.777 0:45.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:07.778 0:45.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP Found existing session 2 Processus arrêté -- Daniel From dsandras@seconix.com Sat Jun 3 13:58:00 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 184373B06A7 for ; Sat, 3 Jun 2006 13:58:00 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20355-03 for ; Sat, 3 Jun 2006 13:57:57 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 19BB03B036E for ; Sat, 3 Jun 2006 13:57:56 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id BC1A4493FD; Sat, 3 Jun 2006 19:41:15 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13551-03; Sat, 3 Jun 2006 19:41:05 +0200 (CEST) Received: from d51A5F203.access.telenet.be (d51A5F203.access.telenet.be [81.165.242.3]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id BC664493EE; Sat, 3 Jun 2006 19:41:05 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <20060603095331.79CD.CRAIGS@postincrement.com> References: <1149242124.4509.17.camel@siti> <20060603095331.79CD.CRAIGS@postincrement.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Sat, 03 Jun 2006 19:57:45 +0200 Message-Id: <1149357465.2414.30.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: Cc: Derek Smithies X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 17:58:00 -0000 Le samedi 03 juin 2006 à 09:55 +1000, Craig Southeren a écrit : > On Fri, 02 Jun 2006 21:55:24 +1200 > Stephen Cook wrote: > > > Hi, > > > > I haven't introduced myself here before, I am Stephen Cook (siti). My > > proposal for implementing IAX2 in ekiga got accepted with google's > > summer of code. > > > > To give an update (I'll try and keep you guys regularly posted as to > > what's happening, any problems etc.). > > > > Currently I have been looking at the code to gain an understanding of > > ekiga and opal's code and design. Also obviously checking out the IAX2 > > code in opal :). From what I have seen and got working, I will work on > > getting IAX2 going in ekiga first. The main part of this will obviously > > involve writing a gnome meeting endpoint for IAX2. > > > > One key problem I have identified is the accounts code. The protocols > > are tightly integrated with how it works. I could either refactor this > > code to loosen the integration or hack iax2 support in there and > > refactor it later ;). The advantage of this refactored will be when > > someone wants to add Xmpp/libjingle support, or some other protocol down > > the track. > > > > Well, please tell me your thoughts and comments on this project. > > As a New Zealander, you are uniquely placed to communicate with the > author of the OPAL IAX2 code, Derek Smithies, who is a fellow Kiwi! I am > sure that you will be able to get the OPAL IAX2 code working with Ekiga > in no time at all with his help. > > If you have any questions, please contact me directly. > Craig, I do not think moving to an offline conversation with Stephen is a good idea. Julien and myself are supposed to mentor the project. Your help is of course welcome, but we have to be kept informed. Notice also that the project is not only about making IAX2 work with Ekiga. -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Sat Jun 3 14:01:08 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 59C003B01BB for ; Sat, 3 Jun 2006 14:01:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20343-10 for ; Sat, 3 Jun 2006 14:01:02 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id BA0863B04B1 for ; Sat, 3 Jun 2006 14:01:01 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 1184A496A8 for ; Sat, 3 Jun 2006 19:44:21 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13551-04 for ; Sat, 3 Jun 2006 19:44:12 +0200 (CEST) Received: from d51A5F203.access.telenet.be (d51A5F203.access.telenet.be [81.165.242.3]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 993CE49685 for ; Sat, 3 Jun 2006 19:44:07 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <4481A6AF.2060703@tootai.net> References: <4481A6AF.2060703@tootai.net> Content-Type: text/plain; charset=ISO-8859-15 Date: Sat, 03 Jun 2006 20:00:48 +0200 Message-Id: <1149357648.2414.34.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 18:01:08 -0000 Hi, Le samedi 03 juin 2006 à 17:11 +0200, Daniel Huhardeaux a écrit : > Resent as it didn't pass at the first try (too big, I cut the begining > of logs) > > Hi all, > > Ekiga behind a firewall is registering to an asterisk server which is on > internet. The sip user is authorized with gsm,ulaw,alaw on asterisk side. > > When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is > started, connection is showed with PCMU (why not GSM?), see the traffic > in/out (~6 kB) but have no audio. > Asterisk answers with 200 OK indicating that the call should be done with PCMU. > I hangup the call, the hangup info is shown in the toolbar, PCMU > disappear in codec and immediately after, traffic in/out continue with > 0/0, icon in KDE Toolbar show Ekiga on line. The only solution I have is > to kill Ekiga. > Please try with 2.0.2. Craig has done work in CVS and things are potentially broken. If the problem persists once plugins support is in CVS, please report again. > If I deactivate GSM codec, everything is fine. Below you will find a d4 > output from the call. > I do not think activating GSM or not has any influence. The problem is probably something else. > > [...] > 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 OpalUDP > Ended connect, selecting 82.231.69.24:35065 > 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP > Queueing PDU: 1 INVITE <407> > 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP > Waiting for PDU on udp$213.203.241.243:5060 > 2006/06/02 13:12:32.901 0:10.661 SIP Handler:8520268 SIP PDU > handler thread started. > 2006/06/02 13:12:32.902 0:10.662 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:32.902 0:10.663 SIP Handler:8520268 SIP > Handling PDU 1 INVITE <407> (with transaction) > 2006/06/02 13:12:32.903 0:10.663 SIP Handler:8520268 SIP > Transaction 1 INVITE completed. > 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP > Sending PDU on udp$213.203.241.243:5060 > ACK sip:800@sip.tootai.net SIP/2.0 > CSeq: 1 ACK > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bK803b125b-96f0-da11-8388-000ea6217592;rport > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: ;tag=as315809c6 > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE > Content-Length: 0 > Max-Forwards: 70 > > > 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP > Received Proxy Authentication Required response > 2006/06/02 13:12:32.906 0:10.666 SIP Handler:8520268 SIP > Transaction 2 INVITE created. > 2006/06/02 13:12:32.906 0:10.667 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:33.090 0:10.850 SIP Handler:8520268 RTP_UDP > Session 1 created: 82.231.69.24:35010-35011 ssrc=703395120 > 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 RTP > Adding session RTP_UDP > 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 SIP > Using RTP payload [pt=101] for NTE > 2006/06/02 13:12:33.100 0:10.860 SIP Handler:8520268 Call > GetMediaFormats for > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > GSM-06.10 > G.711-uLaw-64k > G.711-ALaw-64k > H.261(QCIF) > H.261(CIF) > YUV420P > RGB32 > RGB24 > > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 2 > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 2 > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 2 > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:33.281 0:11.041 SIP Handler:8520268 RTP_UDP > Session 2 created: 82.231.69.24:35014-35015 ssrc=2454563097 > 2006/06/02 13:12:33.282 0:11.042 SIP Handler:8520268 RTP > Adding session RTP_UDP > 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 Call > GetMediaFormats for > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > GSM-06.10 > G.711-uLaw-64k > G.711-ALaw-64k > H.261(QCIF) > H.261(CIF) > YUV420P > RGB32 > RGB24 > > 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 SIP > Adding authentication information > 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP > Sending PDU on udp$213.203.241.243:5060 > INVITE sip:800@sip.tootai.net SIP/2.0 > Date: Fri, 02 Jun 2006 11:12:32 GMT > CSeq: 2 INVITE > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;rport > User-Agent: Ekiga/2.0.1-20060521-01 > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: > Contact: > Proxy-Authorization: Digest username="104", realm="sip.tootai.net", > nonce="12d01d5d", uri="sip:800@sip.tootai.net", > response="60b65ec9045130eab45495d3c65fbc5e", algorithm=md5 > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE > Content-Type: application/sdp > Content-Length: 302 > Max-Forwards: 70 > > v=0 > o=- 1149246753 1149246753 IN IP4 82.231.69.24 > s=Opal SIP Session > c=IN IP4 82.231.69.24 > t=0 0 > m=audio 35010 RTP/AVP 101 3 0 8 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=rtpmap:3 GSM/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > m=video 35014 RTP/AVP 31 > a=rtpmap:31 H261/90000 > > 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP PDU > Received on udp$213.203.241.243:5060 > SIP/2.0 100 Trying > CSeq: 2 INVITE > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 > User-Agent: Asterisk PBX > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: > Contact: > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > Content-Length: 0 > > > 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP > Queueing PDU: 2 INVITE <100> > 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP > Waiting for PDU on udp$213.203.241.243:5060 > 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP > Handling PDU 2 INVITE <100> (with transaction) > 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP > Transaction 2 INVITE proceeding. > 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Set > targetAddress to sip:800@213.203.241.243 > 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP > Received Trying response > 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP > Media session port=7166 > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP > Adding media session with 2 formats > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP > Unknown media attribute silenceSupp:off - - - - > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SIP PDU > Received on udp$213.203.241.243:5060 > SIP/2.0 200 OK > CSeq: 2 INVITE > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 > User-Agent: Asterisk PBX > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: ;tag=as5d2831d1 > Contact: > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > Content-Type: application/sdp > Content-Length: 221 > > v=0 > o=root 26912 26912 IN IP4 213.203.241.243 > s=session > c=IN IP4 213.203.241.243 > t=0 0 > m=audio 7166 RTP/AVP 0 101 > a=rtpmap:0 PCMU/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=silenceSupp:off - - - - > > 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP > Queueing PDU: 2 INVITE <200> > 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP > Waiting for PDU on udp$213.203.241.243:5060 > 2006/06/02 13:12:33.388 0:11.148 SIP Handler:8520268 SIP > Handling PDU 2 INVITE <200> (with transaction) > 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP > Transaction 2 INVITE completed. > 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP Set > targetAddress to sip:800@213.203.241.243 > 2006/06/02 13:12:33.390 0:11.150 SIP Handler:8520268 SIP > Adding authentication information > 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP > Adjusting transport to address udp$213.203.241.243:5060 > 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP > Sending PDU on udp$213.203.241.243:5060 > ACK sip:800@213.203.241.243 SIP/2.0 > CSeq: 2 ACK > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bK6e2ca15b-96f0-da11-8388-000ea6217592;rport > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: ;tag=as5d2831d1 > Contact: > Proxy-Authorization: Digest username="104", realm="sip.tootai.net", > nonce="12d01d5d", uri="sip:800@213.203.241.243", > response="059defd67706254552a5c23eada565b5", algorithm=md5 > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE > Content-Length: 0 > Max-Forwards: 70 > > > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP > Received INVITE OK response > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 SIP RTP > payload type PCMU matched to codec G.711-uLaw-64k > 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k > 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 OpalCon > OpenSourceMediaStream for session 1 on Call[1]-EP[Default] > 2006/06/02 13:12:33.398 0:11.158 SIP Handler:8520268 OpalCon > Selected media stream PCM-16 -> G.711-uLaw-64k > 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 OpalMan > OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 Call > PatchMediaStreams Call[1]-EP[Default] > 2006/06/02 13:12:34.196 0:11.957 SIP Handler:8520268 OpalCon > OpenSinkMediaStream > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session=1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon > OpenSinkMediaStream, selected PCM-16 -> G.711-uLaw-64k > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:34.197 0:11.958 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 OpalMan > OnOpenMediaStream > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Patch > Added sink > from PCM-16 > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 16 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > to G.711-uLaw-64k > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 8 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > > 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Codec > G711-uLaw-64k encoder created > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Patch > Added media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k using > transcoder PCM-16->G.711-uLaw-64k > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Media > Audio source data size set to 320 bytes and 2 buffers. > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call > GetOtherPartyConnection > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon > OpenSourceMediaStream for session 1 on > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon > Selected media stream G.711-uLaw-64k -> PCM-16 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalMan > OnOpenMediaStream > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 Call > PatchMediaStreams > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon > OpenSinkMediaStream Call[1]-EP[Default] session=1 > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon > OpenSinkMediaStream, selected G.711-uLaw-64k -> PCM-16 > 2006/06/02 13:12:34.513 0:12.274 SIP Handler:8520268 OpalMan > OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:34.514 0:12.274 SIP Handler:8520268 Patch > Added sink > from G.711-uLaw-64k > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 8 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > to PCM-16 > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 16 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Codec > G711-uLaw-64k decoder created > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Media > Audio sink data size set to 320 bytes and 2 buffers. > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Patch > Added media stream sink OpalAudioMediaStream-Sink-PCM-16 using > transcoder G.711-uLaw-64k->PCM-16 > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.525 0:12.285 SIP Handler:8520268 OpalCon > OpenSourceMediaStream (already opened) for session 1 on > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.527 0:12.287 SIP Handler:8520268 RTP_UDP > SetRemoteSocketInfo: session=1 data channel, new=213.203.241.243:7166, > local=82.231.69.24:35010-35011, remote=0.0.0.0:0-0 > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 SIP > Could not find SDP media description for Video > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 OpalMan > OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 Call > OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 PCSS > SetConnected() > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 > GMPCSSEndpoint PCSS connection established > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 > GMManager Will establish the connection > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 OpalMan > OnEstablished Call[1]-EP[Default] > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 Call > OnEstablished Call[1]-EP[Default] > 2006/06/02 13:12:34.540 0:12.300 SIP Handler:8520268 Call > GetMediaFormats for Call[1]-EP[Default] > G.711-uLaw-64k > > 2006/06/02 13:12:34.541 0:12.301 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k > 2006/06/02 13:12:34.542 0:12.302 SIP Handler:8520268 OpalCon > OpenSourceMediaStream (already opened) for session 1 on > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.543 0:12.303 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call > GetMediaFormats for > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > G.711-uLaw-64k > > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 OpalCon > OpenSourceMediaStream (already opened) for session 1 on > Call[1]-EP[Default] > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k > 2006/06/02 13:12:34.552 0:12.312 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k > 2006/06/02 13:12:34.553 0:12.313 Media Patch:8175708 Patch > Thread started for Patch OpalAudioMediaStream-Source-PCM-16 -> > OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:34.556 0:12.316 SIP Handler:8520268 Media > Starting thread Media Patch:8175708 > 2006/06/02 13:12:34.557 0:12.317 Media Patch:8527348 Patch > Thread started for Patch OpalRTPMediaStream-Source-G.711-uLaw-64k -> > OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:34.568 0:12.329 Media Patch:8527348 RTP > Jitter buffer created: size=101 delay=160-4000/160 (20ms) obj=0x8526b30 > 2006/06/02 13:12:34.572 0:12.333 RTP Jitter:8526b30 RTP > Jitter RTP receive thread started: 0x8526b30 > 2006/06/02 13:12:34.574 0:12.334 RTP Jitter:8526b30 RTP > First receive data: ver=2 pt=GSM psz=33 m=0 x=0 seq=39915 ts=160 > src=824302623 ccnt=0 > 2006/06/02 13:12:34.580 0:12.341 SIP Handler:8520268 Media > Starting thread Media Patch:8527348 > 2006/06/02 13:12:34.581 0:12.341 SIP Handler:8520268 OpalCon > Media stream threads started. > 2006/06/02 13:12:34.582 0:12.342 SIP Handler:8520268 OpalCon > Media stream threads started. > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP > Found existing session 2 > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 > GMManager Will establish the connection > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 OpalMan > OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.607 0:12.367 SIP Handler:8520268 Call > OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.610 0:12.371 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:34.648 0:12.408 Media Patch:8527348 RTP > Jitter buffer length exceeded > 2006/06/02 13:12:34.649 0:12.409 Media Patch:8527348 RTP > Jitter buffer length exceed was prior to first write. Not increasing > buffer size > 2006/06/02 13:12:35.277 0:13.037 Media Patch:8175708 RTP > First sent data: ver=2 pt=PCMU psz=160 m=1 x=0 seq=1460 ts=0 > src=703395120 ccnt=0 > 2006/06/02 13:12:35.608 0:13.368 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:35.609 0:13.369 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:36.137 0:13.898 RTP Jitter:8526b30 RTP > Receive statistics: packets=101 octets=3714 lost=0 tooLate=0 order=0 > avgTime=15 maxTime=1556 minTime=0 jitter=16 maxJitter=188 > 2006/06/02 13:12:36.573 0:14.333 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (9760) > 2006/06/02 13:12:36.614 0:14.374 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:36.615 0:14.375 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:36.974 0:14.734 RTP Jitter:8526b30 RTP > Jitter buffer continuously full, throwing away entire buffer. > 2006/06/02 13:12:36.995 0:14.756 RTP Jitter:8526b30 RTP > Jitter buffer full, threw away 21 oldest frames > 2006/06/02 13:12:37.374 0:15.134 RTP Jitter:8526b30 RTP > Receive statistics: packets=201 octets=19714 lost=0 tooLate=0 order=0 > avgTime=12 maxTime=23 minTime=0 jitter=0 maxJitter=188 > 2006/06/02 13:12:37.620 0:15.380 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:37.621 0:15.381 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:37.820 0:15.580 Media Patch:8175708 RTP > Transmit statistics: packets=101 octets=16160 avgTime=25 maxTime=48 > minTime=23 > 2006/06/02 13:12:38.624 0:16.384 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:38.625 0:16.385 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:38.993 0:16.753 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (29120) > 2006/06/02 13:12:39.374 0:17.134 RTP Jitter:8526b30 RTP > Receive statistics: packets=301 octets=35714 lost=0 tooLate=0 order=0 > avgTime=20 maxTime=26 minTime=14 jitter=1 maxJitter=188 > 2006/06/02 13:12:39.395 0:17.155 RTP Jitter:8526b30 RTP > Jitter buffer continuously full, throwing away entire buffer. > 2006/06/02 13:12:39.415 0:17.176 RTP Jitter:8526b30 RTP > Jitter buffer full, threw away 21 oldest frames > 2006/06/02 13:12:39.632 0:17.392 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:39.633 0:17.393 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:40.384 0:18.144 Media Patch:8175708 RTP > Transmit statistics: packets=201 octets=32160 avgTime=25 maxTime=44 > minTime=22 > 2006/06/02 13:12:40.640 0:18.400 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:40.641 0:18.401 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:41.373 0:19.133 RTP Jitter:8526b30 RTP > Receive statistics: packets=401 octets=51714 lost=0 tooLate=0 order=0 > avgTime=19 maxTime=26 minTime=13 jitter=1 maxJitter=188 > 2006/06/02 13:12:41.413 0:19.173 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (48480) > 2006/06/02 13:12:41.648 0:19.424 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:41.665 0:19.425 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:41.813 0:19.573 RTP Jitter:8526b30 RTP > Jitter buffer continuously full, throwing away entire buffer. > 2006/06/02 13:12:41.833 0:19.593 RTP Jitter:8526b30 RTP > Jitter buffer full, threw away 21 oldest frames > 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:42.920 0:20.680 Media Patch:8175708 RTP > Transmit statistics: packets=301 octets=48160 avgTime=25 maxTime=49 > minTime=22 > 2006/06/02 13:12:43.378 0:21.139 RTP Jitter:8526b30 RTP > Receive statistics: packets=501 octets=67714 lost=0 tooLate=0 order=0 > avgTime=20 maxTime=27 minTime=12 jitter=1 maxJitter=188 > 2006/06/02 13:12:43.696 0:21.457 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:43.697 0:21.457 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot Call > Clearing Call[1] reason=EndedByLocalUser > 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot OpalCon > Releasing Call[1]-EP[Default] > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > Call end reason for Default set to EndedByLocalUser > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > SetPhase from EstablishedPhase to ReleasingPhase > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > Releasing Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > Call end reason for fa44075b-96f0-da11-8388-000ea6217592@nomade set to > EndedByLocalUser > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > SetPhase from EstablishedPhase to ReleasingPhase > 2006/06/02 13:12:43.820 0:21.581 OnRelease:856e8a0 OpalCon > OnReleased Call[1]-EP[Default] > 2006/06/02 13:12:43.822 0:21.583 OnRelease:856e8a0 Media > Closing raw media stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.824 0:21.584 OnRelease:856e8a0 Media > Closing stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.825 0:21.585 OnRelease:856e8a0 Media > Disconnecting OpalAudioMediaStream-Source-PCM-16 from patch thread Patch > OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.827 0:21.587 OnRelease:856e8a0 Patch > Closing media patch Patch OpalAudioMediaStream-Source-PCM-16 -> > OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.829 0:21.589 OnRelease:856e8a0 Media > Closing raw media stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.830 0:21.590 OnRelease:856e8a0 Media > Closing stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.831 0:21.591 OnRelease:84f8c00 SIP > OnReleased: > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade], phase = > ReleasingPhase > 2006/06/02 13:12:43.833 0:21.593 OnRelease:84f8c00 OpalCon > SetPhase from ReleasingPhase to ReleasingPhase > 2006/06/02 13:12:43.834 0:21.594 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (67840) > 2006/06/02 13:12:43.836 0:21.596 OnRelease:84f8c00 SIP > Transaction 4 BYE created. > 2006/06/02 13:12:43.842 0:21.603 OnRelease:84f8c00 Media > Closing RTP for OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.844 0:21.604 OnRelease:84f8c00 RTP_UDP > Session 1, Shutting down write. > 2006/06/02 13:12:43.845 0:21.605 OnRelease:84f8c00 Media > Closing stream OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.846 0:21.606 OnRelease:84f8c00 Media > Disconnecting OpalRTPMediaStream-Sink-G.711-uLaw-64k from patch thread > Patch OpalAudioMediaStream-Source-PCM-16 -> > OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.848 0:21.609 OnRelease:84f8c00 Patch > Removing media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.855 0:21.626 OnRelease:84f8c00 Media > Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.867 0:21.627 OnRelease:84f8c00 RTP_UDP > Session 1, Shutting down read. > 2006/06/02 13:12:43.868 0:21.628 OnRelease:84f8c00 Media > Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.869 0:21.630 OnRelease:84f8c00 Media > Disconnecting OpalRTPMediaStream-Source-G.711-uLaw-64k from patch thread > Patch OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.893 0:21.653 Media Patch:8175708 Patch > Thread ended for Patch OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.893 0:21.653 OnRelease:84f8c00 Patch > Closing media patch Patch OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.916 0:21.676 RTP Jitter:8526b30 RTP_UDP > Session 1, Read shutdown. > 2006/06/02 13:12:43.917 0:21.677 RTP Jitter:8526b30 RTP > Jitter RTP receive thread ended > 2006/06/02 13:12:43.917 0:21.677 OnRelease:84f8c00 Media > Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.918 0:21.678 OnRelease:84f8c00 RTP_UDP > Session 1, Shutting down read. > 2006/06/02 13:12:43.919 0:21.679 OnRelease:84f8c00 Media > Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.922 0:21.683 OnRelease:856e8a0 Patch > Waiting for media patch thread to stop Patch > OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.926 0:21.686 OnRelease:856e8a0 Patch > Media patch thread Patch OpalAudioMediaStream-Source-PCM-16 destroyed. > 2006/06/02 13:12:43.930 0:21.691 OnRelease:856e8a0 Media > Closing raw media stream OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:43.932 0:21.693 OnRelease:856e8a0 Media > Closing stream OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:43.933 0:21.694 OnRelease:856e8a0 Media > Disconnecting OpalAudioMediaStream-Sink-PCM-16 from patch thread Patch > OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.956 0:21.717 OnRelease:856e8a0 Patch > Removing media stream sink OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:45.696 0:23.456 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:45.697 0:23.457 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:48.708 0:26.468 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:48.709 0:26.469 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:50.712 0:28.473 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:50.713 0:28.473 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:51.716 0:29.477 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:51.717 0:29.477 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:52.716 0:30.477 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:52.717 0:30.477 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:57.733 0:35.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:57.734 0:35.494 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:02.777 0:40.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:02.778 0:40.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:04.369 0:42.129 Housekeeper SIP Set > state Terminated_Success for transaction 1 INVITE > 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:05.777 0:43.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:05.777 0:43.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:06.613 0:44.374 Housekeeper SIP Set > state Terminated_Success for transaction 2 INVITE > 2006/06/02 13:13:06.777 0:44.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:06.778 0:44.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:07.777 0:45.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:07.778 0:45.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP > Found existing session 2 > Processus arrêté > -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From devel@tootai.net Sat Jun 3 19:25:05 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EBBDB3B06DD for ; Sat, 3 Jun 2006 19:24:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02787-06 for ; Sat, 3 Jun 2006 19:24:40 -0400 (EDT) Received: from mail1.tootai.net (ns1.tootai.net [82.231.69.24]) by menubar.gnome.org (Postfix) with ESMTP id 16D123B0756 for ; Sat, 3 Jun 2006 19:24:35 -0400 (EDT) Received: from [192.168.0.17] (unknown [192.168.0.17]) by mail1.tootai.net (Postfix) with ESMTP id 9C142398B99 for ; Sun, 4 Jun 2006 01:24:35 +0200 (CEST) Message-ID: <44821A19.10001@tootai.net> Date: Sun, 04 Jun 2006 01:24:09 +0200 From: Daniel Huhardeaux Organization: TOOTAi User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 References: <4481A6AF.2060703@tootai.net> <1149357648.2414.34.camel@golgoth01> In-Reply-To: <1149357648.2414.34.camel@golgoth01> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[AWL=0.000, BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 23:25:05 -0000 Damien Sandras wrote: > [...] >> When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is >> started, connection is showed with PCMU (why not GSM?), see the traffic >> in/out (~6 kB) but have no audio. >> >> > > Asterisk answers with 200 OK indicating that the call should be done > with PCMU. > Ok, but as GSM has my preference in Ekiga as well as in asterisk, the call should be done in GSM > [...] > > Please try with 2.0.2. Craig has done work in CVS and things are > potentially broken. If the problem persists once plugins support is in > CVS, please report again. > I use the Ekiga snapshot SID version which don't provide newest version as the one mentioned :-( Kilian? BTW, asterisk is 1.2-r16008 from 29/03/2006 - SVN stable. > > >> If I deactivate GSM codec, everything is fine. Below you will find a d4 >> output from the call. >> >> > > I do not think activating GSM or not has any influence. The problem is > probably something else. > I would like to believe you, but this problem happends only with GSM codec. -- Daniel From ebischoff@nerim.net Sun Jun 4 11:52:03 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C970B3B011B for ; Sun, 4 Jun 2006 11:52:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26992-10 for ; Sun, 4 Jun 2006 11:52:01 -0400 (EDT) Received: from mallaury.nerim.net (smtp-100-sunday.noc.nerim.net [62.4.17.100]) by menubar.gnome.org (Postfix) with ESMTP id 9601A3B00CE for ; Sun, 4 Jun 2006 11:52:01 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by mallaury.nerim.net (Postfix) with ESMTP id 32E474F399 for ; Sun, 4 Jun 2006 17:51:50 +0200 (CEST) From: =?iso-8859-1?q?=C9ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Sun, 4 Jun 2006 17:52:11 +0200 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606041752.12228.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.535 tagged_above=-999 required=2 tests=[AWL=0.064, BAYES_00=-2.599] X-Spam-Score: -2.535 X-Spam-Level: Subject: [GnomeMeeting-devel-list] KDE address book support in Ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 15:52:04 -0000 (this message has already been sent by mistake on gnomemeeting-list a few=20 hours ago, sorry for the crossposting) Hi everyone, A small notice to let you know that I am working on adding support for KDE= =20 Address Book (kab) to Ekiga. I already have some early "proof of concept"=20 code working (see screenshot at=20 http://opensource.bureau-cornavin.com/ekiga/screenshot.png). KDE Address Book is an application of its own, but it's also a library that= is=20 used by most KDE applications (KMail, Kontact, KPilot, Kopete, ...), and al= so=20 by third-party applications like OpenOffice.org. It can use several=20 "resources" for its addresses: local VCard files, remote LDAP servers, etc. Before anyone does the remark : YES it would be better if Evolution/GNOME a= nd=20 KDE shared the same address book library. But currently we have to live wit= h=20 this situation... There are two issues that currently slow me down a bit: 1) Ekiga's address book model distinguishes between "local" and "remote"=20 address books. This makes little sense for kab which can transparently use= =20 both local and remote resources. In a first time, my code will act as a=20 "local" address book, just like Evolution address book. 2) KDE address book currently has no field for SIP nor H323 addresses. I am= =20 currently trying to contact Will Stephenson (KDE) who added support for Sky= pe=20 addresses to see how we could do that cleanly. Of course, this functionality will remain optional and require no library f= or=20 those who can live without it :-). Any suggestion, wish, encouragement, criticism, and/or offer for help is=20 welcome. Hoping that helps, =2D-=20 =C9ric From jpuydt@free.fr Sun Jun 4 12:08:13 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C97F03B009F; Sun, 4 Jun 2006 12:08:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28175-05; Sun, 4 Jun 2006 12:08:00 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 880B03B0187; Sun, 4 Jun 2006 12:08:00 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-54-82-251-83-65.adsl.proxad.net [82.251.83.65]) by smtp5-g19.free.fr (Postfix) with ESMTP id 3EBD2250F8; Sun, 4 Jun 2006 18:07:59 +0200 (CEST) Message-ID: <44830581.8080503@free.fr> Date: Sun, 04 Jun 2006 18:08:33 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting mailing list , GnomeMeeting development mailing list References: <200606041116.31785.ebischoff@nerim.net> In-Reply-To: <200606041116.31785.ebischoff@nerim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: Cc: Subject: [GnomeMeeting-devel-list] Re: [GnomeMeeting-list] KDE address book support in Ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 16:08:14 -0000 Éric Bischoff a écrit : > A small notice to let you know that I am working on adding support for KDE > Address Book (kab) to Ekiga. I already have some early "proof of concept" > code working (see screenshot at > http://opensource.bureau-cornavin.com/ekiga/screenshot.png). I know :-) > KDE Address Book is an application of its own, but it's also a library that is > used by most KDE applications (KMail, Kontact, KPilot, Kopete, ...), and also > by third-party applications like OpenOffice.org. It can use several > "resources" for its addresses: local VCard files, remote LDAP servers, etc. Nice. > Before anyone does the remark : YES it would be better if Evolution/GNOME and > KDE shared the same address book library. But currently we have to live with > this situation... Indeed. > There are two issues that currently slow me down a bit: > > 1) Ekiga's address book model distinguishes between "local" and "remote" > address books. This makes little sense for kab which can transparently use > both local and remote resources. In a first time, my code will act as a > "local" address book, just like Evolution address book. I'm refactoring the addressbook ; and I don't like that distinction either. I'm still trying to convince Damien and Jan my ideas can fly. I think Jan is already beginning to see where I go ; Damien hasn't had the time to dive into it. > 2) KDE address book currently has no field for SIP nor H323 addresses. I am > currently trying to contact Will Stephenson (KDE) who added support for Skype > addresses to see how we could do that cleanly. Ok. > Of course, this functionality will remain optional and require no library for > those who can live without it :-). Ok too. We'll go with a --enable-kde at compile time. Then later on we'll see if it's possible to do something at runtime. > Any suggestion, wish, encouragement, criticism, and/or offer for help is > welcome. * Suggestion: use -devel-list ;-) * Wish: what you have written will work well with what I have in mind * Encouragement: I like the idea very much, and appreciate your working on ekiga * Criticism: couldn't you do that either long before or just after the re-architecturing? ;-) * Offer for help: uh... I'm refactoring, and it may help (the api I ask from "addressbooks" is much lighter). Snark on #ekiga From ebischoff@nerim.net Sun Jun 4 12:36:03 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6EBCD3B00E9 for ; Sun, 4 Jun 2006 12:36:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29967-09 for ; Sun, 4 Jun 2006 12:36:02 -0400 (EDT) Received: from kraid.nerim.net (smtp-100-sunday.nerim.net [62.4.16.100]) by menubar.gnome.org (Postfix) with ESMTP id 16E7B3B009F for ; Sun, 4 Jun 2006 12:36:01 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id C772E40E31 for ; Sun, 4 Jun 2006 18:35:59 +0200 (CEST) From: =?iso-8859-1?q?=C9ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Re: [GnomeMeeting-list] KDE address book support in Ekiga Date: Sun, 4 Jun 2006 18:36:11 +0200 User-Agent: KMail/1.8.2 References: <200606041116.31785.ebischoff@nerim.net> <44830581.8080503@free.fr> In-Reply-To: <44830581.8080503@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606041836.12390.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.553 tagged_above=-999 required=2 tests=[AWL=0.046, BAYES_00=-2.599] X-Spam-Score: -2.553 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 16:36:03 -0000 Le Dimanche 4 Juin 2006 18:08, Julien PUYDT a =E9crit=A0: > I know :-) I know you know ;-). > I'm refactoring the addressbook ; and I don't like that distinction > either. I'm still trying to convince Damien and Jan my ideas can fly. I > think Jan is already beginning to see where I go ; Damien hasn't had the > time to dive into it. Okay, I have not written much code yet, so there will be no problem to adap= t=20 it to your new layout, whatever it will be. > Ok too. We'll go with a --enable-kde at compile time. Then later on > we'll see if it's possible to do something at runtime. Yes, I was figuring out something like that. > * Suggestion: use -devel-list ;-) Yup, sorry... :-/ > * Wish: what you have written will work well with what I have in mind See above, I have not written much yet, and it's "obvious" code anyway, so= =20 there's no problem even if I have to restart from scratch. > * Encouragement: I like the idea very much, and appreciate your working > on ekiga Thank you for the warm welcome, Julien :-). > * Criticism: couldn't you do that either long before or just after the > re-architecturing? ;-) No. Did you hear about Murphy's law ? ;-) > * Offer for help: uh... I'm refactoring, and it may help (the api I ask > from "addressbooks" is much lighter). Indeed. =2D-=20 =C9ric From dsandras@seconix.com Mon Jun 5 15:24:19 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 115A33B038A for ; Mon, 5 Jun 2006 15:24:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24872-10 for ; Mon, 5 Jun 2006 15:24:15 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 482C73B0420 for ; Mon, 5 Jun 2006 15:24:15 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 73E6049870 for ; Mon, 5 Jun 2006 21:07:08 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23599-08 for ; Mon, 5 Jun 2006 21:06:52 +0200 (CEST) Received: from [192.168.0.161] (39.128-245-81.adsl-dyn.isp.belgacom.be [81.245.128.39]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 4C3C84986E for ; Mon, 5 Jun 2006 21:06:52 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44821A19.10001@tootai.net> References: <4481A6AF.2060703@tootai.net> <1149357648.2414.34.camel@golgoth01> <44821A19.10001@tootai.net> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 05 Jun 2006 21:24:50 +0200 Message-Id: <1149535490.2508.3.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.455 tagged_above=-999 required=2 tests=[AWL=0.009, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.455 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 19:24:19 -0000 Le dimanche 04 juin 2006 à 01:24 +0200, Daniel Huhardeaux a écrit : > Damien Sandras wrote: > > [...] > >> When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is > >> started, connection is showed with PCMU (why not GSM?), see the traffic > >> in/out (~6 kB) but have no audio. > >> > >> > > > > Asterisk answers with 200 OK indicating that the call should be done > > with PCMU. > > > Ok, but as GSM has my preference in Ekiga as well as in asterisk, the > call should be done in GSM I agree, but if you look at the 200 OK sent by Asterisk, GSM is not part of it, while it is part of the INVITE sent by Ekiga. > > I do not think activating GSM or not has any influence. The problem is > > probably something else. > > > I would like to believe you, but this problem happends only with GSM codec. Is there some way I could reproduce it here? -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Mon Jun 5 17:45:53 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 776D43B03A0; Mon, 5 Jun 2006 17:45:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02457-06; Mon, 5 Jun 2006 17:45:52 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 22F123B0295; Mon, 5 Jun 2006 17:45:52 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 8C0904984F; Mon, 5 Jun 2006 23:28:44 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29850-10; Mon, 5 Jun 2006 23:28:37 +0200 (CEST) Received: from [192.168.0.161] (39.128-245-81.adsl-dyn.isp.belgacom.be [81.245.128.39]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 089E44984C; Mon, 5 Jun 2006 23:28:36 +0200 (CEST) From: Damien Sandras To: gnomemeeting-list@gnome.org Content-Type: text/plain Date: Mon, 05 Jun 2006 23:46:32 +0200 Message-Id: <1149543992.2508.40.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.455 tagged_above=-999 required=2 tests=[AWL=0.009, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.455 X-Spam-Level: Cc: gnomemeeting-devel-list@gnome.org Subject: [GnomeMeeting-devel-list] Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 21:45:53 -0000 Hello to all, Ekiga 2.0.2 is available on http://www.ekiga.org More packages will be added as they are released. Thanks a lot to all supporters of the project! -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From simon@mungewell.org Mon Jun 5 18:20:27 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1BD3C3B0389 for ; Mon, 5 Jun 2006 18:20:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04790-06 for ; Mon, 5 Jun 2006 18:20:25 -0400 (EDT) Received: from pd3mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by menubar.gnome.org (Postfix) with ESMTP id 864BD3B04F7 for ; Mon, 5 Jun 2006 18:20:25 -0400 (EDT) Received: from pd3mr3so.prod.shaw.ca (pd3mr3so-qfe3.prod.shaw.ca [10.0.141.179]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0E00FK5RE0KD10@l-daemon> for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:20:24 -0600 (MDT) Received: from pn2ml4so.prod.shaw.ca ([10.0.121.148]) by pd3mr3so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0E002HJRE0FOB0@pd3mr3so.prod.shaw.ca> for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:20:24 -0600 (MDT) Received: from slone.mungewell.org ([68.146.98.7]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0E00GPGRE0XH60@l-daemon> for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:20:24 -0600 (MDT) Received: from simon by slone.mungewell.org with local (Exim 4.61) (envelope-from ) id 1FnNDw-0002Wd-6Y for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:07:00 -0600 Date: Mon, 05 Jun 2006 16:07:00 -0600 From: simon Subject: Re: [GnomeMeeting-devel-list] Ekiga 2.0.2 In-reply-to: <1149543992.2508.40.camel@golgoth01> To: GnomeMeeting development mailing list Message-id: <20060605220700.GA9699@mungewell.org> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline References: <1149543992.2508.40.camel@golgoth01> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[AWL=-0.000, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 22:20:27 -0000 On Mon, Jun 05, 2006 at 11:46:32PM +0200, Damien Sandras wrote: > Hello to all, > > > Ekiga 2.0.2 is available on http://www.ekiga.org > Woo Woo another release party! What only a '.' release - oh, guess we'll have to share a can of Pop ;-) Seriously though, Thanks to Damien and all the other developers. Simon From siti@orcon.net.nz Tue Jun 6 05:25:31 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5963D3B00EF for ; Tue, 6 Jun 2006 05:25:31 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29810-06 for ; Tue, 6 Jun 2006 05:25:29 -0400 (EDT) Received: from dbmail-mx2.orcon.net.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id AB0663B00E2 for ; Tue, 6 Jun 2006 05:25:28 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx2.orcon.net.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k569PFih007843 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Jun 2006 21:25:16 +1200 Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Stephen Cook To: Derek Smithies In-Reply-To: References: Content-Type: text/plain Date: Tue, 06 Jun 2006 21:25:24 +1200 Message-Id: <1149585924.16149.8.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx2.orcon.net.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.532 tagged_above=-999 required=2 tests=[AWL=0.068, BAYES_00=-2.599] X-Spam-Score: -2.532 X-Spam-Level: Cc: GnomeMeeting development mailing list X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 09:25:31 -0000 On Tue, 2006-06-06 at 10:32 +1200, Derek Smithies wrote: > Hi, > Ok, just back from a long weekend (three days of not touching a computer) > and back into things. > > Stephen, I saw some comment from you on this topic at: > > http://siti.geek.nz/web/content/blogsection/4/26/ > > interesting - very interesting.. > > hey - now that is a coincidence. > I studied at Canterbury University also. Well that's cool :) Could you send me a private email with an instant messaging address that you use. BTW Damien and others we will keep as much information on the mailing list. To give you guys an update I have IAX2 calls going in ekiga although it needs a lot of work :). Then obviously the improvements to IAX2 in opal... > > > ============== > > Craig, I do not think moving to an offline conversation with Stephen is > > a good idea. Julien and myself are supposed to mentor the project. Your > > help is of course welcome, but we have to be kept informed. > Sorry Damien, but there will be a lot of offline comment. > I suspect that Stephen and I live in the same city. Sending a CC of phone > conversations etc will not be easy. > > I will endeavour though to keep you informed of what is happening, and we > can move everything forward towards the nirvana of iax2, sip, and h323 in > gnomemeeting. > > > =========================== > > Stephen, > > I am really happy to work with you on IAX2 - really happy. This > would be great for the project. It should be a good learning experience for me and I am sure it'll be good fun :) From dsandras@seconix.com Tue Jun 6 05:29:32 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 40D9E3B0A68 for ; Tue, 6 Jun 2006 05:29:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30841-02 for ; Tue, 6 Jun 2006 05:29:30 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 9F34C3B0A5C for ; Tue, 6 Jun 2006 05:29:30 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id DDF8E493CB; Tue, 6 Jun 2006 11:12:16 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30209-02; Tue, 6 Jun 2006 11:11:57 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 679F9492DA; Tue, 6 Jun 2006 11:11:57 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: Stephen Cook In-Reply-To: <1149585924.16149.8.camel@siti> References: <1149585924.16149.8.camel@siti> Content-Type: text/plain; charset=ISO-8859-15 Date: Tue, 06 Jun 2006 11:29:17 +0200 Message-Id: <1149586157.2470.27.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Cc: Derek Smithies , GnomeMeeting development mailing list X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 09:29:32 -0000 Le mardi 06 juin 2006 à 21:25 +1200, Stephen Cook a écrit : > On Tue, 2006-06-06 at 10:32 +1200, Derek Smithies wrote: > > Hi, > > Ok, just back from a long weekend (three days of not touching a computer) > > and back into things. > > > > Stephen, I saw some comment from you on this topic at: > > > > http://siti.geek.nz/web/content/blogsection/4/26/ > > > > interesting - very interesting.. > > > > hey - now that is a coincidence. > > I studied at Canterbury University also. > Well that's cool :) > > Could you send me a private email with an instant messaging address that > you use. > > BTW Damien and others we will keep as much information on the mailing > list. > > To give you guys an update I have IAX2 calls going in ekiga although it > needs a lot of work :). Then obviously the improvements to IAX2 in > opal... > Excellent ;-) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From jpuydt@free.fr Tue Jun 6 06:41:15 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 18B6B3B00E0 for ; Tue, 6 Jun 2006 06:41:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10263-10 for ; Tue, 6 Jun 2006 06:41:14 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id BD54A3B00D2 for ; Tue, 6 Jun 2006 06:41:13 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-57-82-249-29-56.adsl.proxad.net [82.249.29.56]) by smtp1-g19.free.fr (Postfix) with ESMTP id 909369AAC7 for ; Tue, 6 Jun 2006 12:41:12 +0200 (CEST) Message-ID: <44855BEC.1040306@free.fr> Date: Tue, 06 Jun 2006 12:41:48 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga References: <1149585924.16149.8.camel@siti> In-Reply-To: <1149585924.16149.8.camel@siti> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.585 tagged_above=-999 required=2 tests=[AWL=0.014, BAYES_00=-2.599] X-Spam-Score: -2.585 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 10:41:15 -0000 Stephen Cook a écrit : > Could you send me a private email with an instant messaging address that > you use. > > BTW Damien and others we will keep as much information on the mailing > list. > > To give you guys an update I have IAX2 calls going in ekiga although it > needs a lot of work :). Then obviously the improvements to IAX2 in > opal... This sounds great :-) Do all codecs work ok ? Could you make a short list of what is lacking, so your progress can easily be seen ? :-) Snark From siti@orcon.net.nz Tue Jun 6 08:02:29 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0E2D93B008B for ; Tue, 6 Jun 2006 08:02:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19082-05 for ; Tue, 6 Jun 2006 08:02:18 -0400 (EDT) Received: from dbmail-mx3.orcon.co.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 7C3DD3B0A9D for ; Tue, 6 Jun 2006 08:01:24 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx3.orcon.co.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k56C17Ej021180 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 7 Jun 2006 00:01:12 +1200 Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Stephen Cook To: GnomeMeeting development mailing list In-Reply-To: <44855BEC.1040306@free.fr> References: <1149585924.16149.8.camel@siti> <44855BEC.1040306@free.fr> Content-Type: text/plain; charset=utf-8 Date: Wed, 07 Jun 2006 00:01:17 +1200 Message-Id: <1149595277.17468.7.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx3.orcon.co.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.495 tagged_above=-999 required=2 tests=[AWL=-0.031, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.495 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 12:02:29 -0000 On Tue, 2006-06-06 at 12:41 +0200, Julien PUYDT wrote: > Stephen Cook a écrit : > > Could you send me a private email with an instant messaging address that > > you use. > > > > BTW Damien and others we will keep as much information on the mailing > > list. > > > > To give you guys an update I have IAX2 calls going in ekiga although it > > needs a lot of work :). Then obviously the improvements to IAX2 in > > opal... > > This sounds great :-) > > Do all codecs work ok ? I have only tried ULAW > > Could you make a short list of what is lacking, so your progress can > easily be seen ? In Ekiga: * Url handler for IAX2 * If I have time in the future -- Refactor protocol components in ekiga In Iax2: * Call Hold * Transfer Calls * Register > > :-) > > Snark > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list From jan.schampera@web.de Tue Jun 6 11:41:54 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 300F43B00A7 for ; Tue, 6 Jun 2006 11:41:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01645-10 for ; Tue, 6 Jun 2006 11:41:52 -0400 (EDT) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by menubar.gnome.org (Postfix) with ESMTP id 5016E3B0117 for ; Tue, 6 Jun 2006 11:41:52 -0400 (EDT) Received: from fwd28.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1Fndgj-000497-06; Tue, 06 Jun 2006 17:41:49 +0200 Received: from mail.home.thebonsai.de (SxWWnGZHgenZylg6UcgKDR7M2nKdws-wslY10mn82PtIepb06FcVZ4@[84.147.103.162]) by fwd28.sul.t-online.de with esmtp id 1Fndgc-1VKS9o0; Tue, 6 Jun 2006 17:41:42 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id B18576B0FF for ; Tue, 6 Jun 2006 17:41:40 +0200 (CEST) Date: Tue, 6 Jun 2006 17:37:41 +0200 From: Jan Schampera To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga Message-ID: <20060606173741.7739fbf0@localhost.localdomain> In-Reply-To: <1149595277.17468.7.camel@siti> References: <1149585924.16149.8.camel@siti> <44855BEC.1040306@free.fr> <1149595277.17468.7.camel@siti> Organization: private X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: SxWWnGZHgenZylg6UcgKDR7M2nKdws-wslY10mn82PtIepb06FcVZ4@t-dialin.net X-TOI-MSGID: d621850d-8c24-4c96-bc80-424b3278e7ee X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.966 tagged_above=-999 required=2 tests=[AWL=0.632, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.966 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 15:41:54 -0000 On Wed, 07 Jun 2006 00:01:17 +1200 Stephen Cook wrote: > In Ekiga: > * Url handler for IAX2 > * If I have time in the future -- Refactor protocol components in > ekiga > > In Iax2: > * Call Hold > * Transfer Calls > * Register I X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C93A63B023C for ; Tue, 6 Jun 2006 18:32:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26160-07 for ; Tue, 6 Jun 2006 18:32:35 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by menubar.gnome.org (Postfix) with ESMTP id EE5BE3B0124 for ; Tue, 6 Jun 2006 18:32:34 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x31so57152pye for ; Tue, 06 Jun 2006 15:32:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=PWNZjwnHiPmpdYl2MsXZ9YZF9d4xYPXUg1ADy6s6gr7kpZpuMn+pMk4SiPqw6G91hexsOp1xDFUNDwMZyQ+X01mIY9TDqR0zrylP3BBJTKYCjcgQm4+vLCMe9AVXFuvgQ8NYOFrWwmRpr+zSS1OaVc2h2FssBRFPxlSabyu06bg= Received: by 10.35.76.9 with SMTP id d9mr79929pyl; Tue, 06 Jun 2006 15:32:33 -0700 (PDT) Received: by 10.35.9.3 with HTTP; Tue, 6 Jun 2006 15:32:33 -0700 (PDT) Message-ID: <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> Date: Tue, 6 Jun 2006 18:32:33 -0400 From: "mcquaid mcquaid" To: "GnomeMeeting development mailing list" Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode In-Reply-To: <1149246461.2966.28.camel@golgoth01> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7731_6834590.1149633153798" References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> <1149246461.2966.28.camel@golgoth01> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.041 tagged_above=-999 required=2 tests=[AWL=0.062, BAYES_00=-2.599, HTML_40_50=0.496, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.041 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 22:32:38 -0000 ------=_Part_7731_6834590.1149633153798 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Just a user, I'm curious as to why the trend of throwing opengl at everything. On one hand I think it's really cool, but this isn't like xgl where we want wobbly windows or something, just accelerated video. Isn't that what hardware video overlay is for? It takes a large burden off the cpu for video playback. Would benefit more people as some don't have prope= r opengl drivers. On 6/2/06, Damien Sandras wrote: > > Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit : > > So configure.in is hand-generated? Surprising. > > > > That's te way it works. You write configure.in and configure is > generated from there. I guess you are confusing things here. > > > 1) How exactly do I add the opengl ( libgl ) library? > > > > By writing autconf code in configure.in. No idea exactly how it should > be done. > > > 2) Xrandr is mentioned in the Makefile, but is not in configure.in. Ho= w > > exactly does it get put into the Makefile? > > > > Probably by an external library that we are using. > > > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I didn't wan= t > > to code against a moving target. > > > > Yes. It is even OK if you do not provide the configure.in code, but only > the OpenGL Ekiga code. > > > Thanks, > > > > -Dan > > > > Damien Sandras wrote: > > > > >Le mercredi 31 mai 2006 =E0 12:41 -0700, Dan Sandberg a =E9crit : > > > > > > > > >>I'd imagine it would work on win32, but don't know. > > >> > > >> > > >> > > > > > >Probably. > > > > > > > > > > > >>I'll work on the patches. > > >> > > >>Where's the right place to add required libraries like openGL? > > >> > > >> > > > > > >In configure.in. > > > > > > > > > > > >>configure.in seems to be autogenerated by something, but whatever it > is > > >>doesn't seem to be in the CVS snapshot... > > >> > > >> > > >> > > > > > >configure.in is in the CVS snapshot. > > > > > > > > > > > > > > >>Thanks, > > >> > > >>-Dan > > >> > > >>Julien PUYDT wrote: > > >> > > >> > > >> > > >>>Dan Sandberg a =E9crit : > > >>> > > >>> > > >>> > > >>>>How should we proceed? I could just send you an updated > gui/main.cpp > > >>>>file... > > >>>> > > >>>> > > >>>I'd like to see patches instead of full files, preferably independan= t > > >>>on each others. > > >>> > > >>>There's also the question of the portability of this : since you > > >>>mention SDL, I guess this will work great on win32 too ? > > >>> > > >>>Snark > > >>>_______________________________________________ > > >>>Gnomemeeting-devel-list mailing list > > >>>Gnomemeeting-devel-list@gnome.org > > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >>> > > >>> > > >>> > > >>_______________________________________________ > > >>Gnomemeeting-devel-list mailing list > > >>Gnomemeeting-devel-list@gnome.org > > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >> > > >> > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > -- > _ Damien Sandras > (o- > //\ Ekiga Softphone: http://www.ekiga.org/ > v_/_ FOSDEM 2006 : http://www.fosdem.org/ > SIP Phone : sip:dsandras@ekiga.net > sip:600000@ekiga.net > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > ------=_Part_7731_6834590.1149633153798 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Just a user, I'm curious as to why the trend of throwing opengl at everythi= ng.  On one hand I think it's really cool, but this isn't like xgl whe= re we want wobbly windows or something, just accelerated video.  Isn't= that what hardware video overlay is for?  It takes a large burden off= the cpu for video playback.  Would benefit more people as some don't = have proper opengl drivers.

On 6/2/06, Damien Sandras <dsand= ras@seconix.com> wrote:
Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit :
> = So configure.in is hand-generated? = ; Surprising.
>

That's te way it works. You write configure.in and configure is
generated from there. I guess you are = confusing things here.

> 1) How exactly do I add the opengl ( lib= gl ) library?
>

By writing autconf code in configure.in. No idea exactly how it should
be done.

> 2) = Xrandr is mentioned in the Makefile, but is not in configure.in.  How
> exactly does it get put in= to the Makefile?
>

Probably by an external library that we are using.

&= gt; 3) Is it ok if I send in a patch that is for Ekiga 2.0.1?  I = didn't want
> to code against a moving target.
>

Yes. It= is even OK if you do not provide the=20 configure.in code, but only
the Open= GL Ekiga code.

> Thanks,
>
> -Dan
>
> Dam= ien Sandras wrote:
>
> >Le mercredi 31 mai 2006 =E0 12:41 -0= 700, Dan Sandberg a =E9crit :
> >
> >
> >>I'd imagine it would work on win= 32, but don't know.
> >>
> >>
> >>
&= gt; >
> >Probably.
> >
> >
> >
> >>I'll work on the patches.
> >>
> >>Whe= re's the right place to add required libraries like openGL?
> >>= ;
> >>
> >
> >In configure.in.
> >
> >
> >
> >>configure.in seems to be autogenerated by= something, but whatever it is
> >>doesn't seem to be in the CV= S snapshot...
> >>
> >>
> >>
> >
> &g= t;configure.in is in the CVS snapshot.<= br>> >
> >
> >
> >
> >>Thanks,
> >>
> >>-Dan
> >>
> >>Jul= ien PUYDT wrote:
> >>
> >>
> >>
>= >>>Dan Sandberg a =E9crit :
> >>>
> >>= >
> >>>
> >>>>How should we proceed? &= nbsp;I could just send you an updated gui/main.cpp
> >>>>= file...
> >>>>
> >>>>
> >>&= gt;I'd like to see patches instead of full files, preferably independant
> >>>on each others.
> >>>
> >>&= gt;There's also the question of the portability of this : since you
>= >>>mention SDL, I guess this will work great on win32 too ?
> >>>
> >>>Snark
> >>>___________= ____________________________________
> >>>Gnomemeeting-devel= -list mailing list
> >>> Gnomemeeting-devel-list@gnome.org
> >>>http://mail.gnome= .org/mailman/listinfo/gnomemeeting-devel-list
> >>>
> >>>
> >>>
> >>____________________= ___________________________
> >>Gnomemeeting-devel-list mailing= list
> >> Gnomemeeting-devel-list@gnome.org
> >>http://mail.gnome.org= /mailman/listinfo/gnomemeeting-devel-list
> >>
> >= >
>
> _______________________________________________
> Gn= omemeeting-devel-list mailing list
> Gnomemeeting-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
-- _      Damien Sandras
(o-
//\ &n= bsp;   Ekiga Softphone: http://= www.ekiga.org/
v_/_    FOSDEM 2006  &n= bsp; : http://www.fosdem.org/
       &nb= sp;SIP Phone      : sip:dsandras@ekiga.net
    &nbs= p;            &= nbsp;       sip:600000@ekiga.net

____________________________________= ___________
Gnomemeeting-devel-list mailing list
Gnomemeeting-devel-list@gnome.org
http://mail.= gnome.org/mailman/listinfo/gnomemeeting-devel-list

------=_Part_7731_6834590.1149633153798-- From x@cs.stanford.edu Tue Jun 6 18:47:00 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5D25C3B036D for ; Tue, 6 Jun 2006 18:46:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26984-04 for ; Tue, 6 Jun 2006 18:46:56 -0400 (EDT) Received: from smtp104.plus.mail.mud.yahoo.com (smtp104.plus.mail.mud.yahoo.com [68.142.206.237]) by menubar.gnome.org (Postfix) with SMTP id 502483B0124 for ; Tue, 6 Jun 2006 18:46:56 -0400 (EDT) Received: (qmail 87952 invoked from network); 6 Jun 2006 22:46:55 -0000 Received: from unknown (HELO ?192.168.2.47?) (dan?sandberg@71.138.128.214 with plain) by smtp104.plus.mail.mud.yahoo.com with SMTP; 6 Jun 2006 22:46:54 -0000 Message-ID: <448605B0.6080504@cs.stanford.edu> Date: Tue, 06 Jun 2006 15:46:08 -0700 From: Dan Sandberg User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> <1149246461.2966.28.camel@golgoth01> <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> In-Reply-To: <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.808 tagged_above=-999 required=2 tests=[AWL=-0.593, BAYES_00=-2.599, SPF_SOFTFAIL=1.384] X-Spam-Score: -1.808 X-Spam-Level: Cc: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 22:47:00 -0000 I could be wrong, but I believe that video overlay moves the data direct from a capture card to the video card, bypassing the CPU. Since we're trying to display images that come from over the network, there's no way to bypass the CPU. And doing a nice looking resize from 176x144 to 640x480 is quite slow. Then you have to copy the whole 640x480 image to the display card, which is slow. With OpenGL you just copy the 176x144 image to the video card, and have it do the resize. Cheers, -Dan mcquaid mcquaid wrote: > Just a user, I'm curious as to why the trend of throwing opengl at > everything. On one hand I think it's really cool, but this isn't like > xgl where we want wobbly windows or something, just accelerated > video. Isn't that what hardware video overlay is for? It takes a > large burden off the cpu for video playback. Would benefit more > people as some don't have proper opengl drivers. > > On 6/2/06, *Damien Sandras* > wrote: > > Le vendredi 02 juin 2006 à 03:03 -0700, Dan Sandberg a écrit : > > So configure.in is > hand-generated? Surprising. > > > > That's te way it works. You write configure.in > and configure is > generated from there. I guess you are confusing things here. > > > 1) How exactly do I add the opengl ( libgl ) library? > > > > By writing autconf code in configure.in . No > idea exactly how it should > be done. > > > 2) Xrandr is mentioned in the Makefile, but is not in > configure.in . How > > exactly does it get put into the Makefile? > > > > Probably by an external library that we are using. > > > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I > didn't want > > to code against a moving target. > > > > Yes. It is even OK if you do not provide the configure.in > code, but only > the OpenGL Ekiga code. > > > Thanks, > > > > -Dan > > > > Damien Sandras wrote: > > > > >Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > > > > > > > > >>I'd imagine it would work on win32, but don't know. > > >> > > >> > > >> > > > > > >Probably. > > > > > > > > > > > >>I'll work on the patches. > > >> > > >>Where's the right place to add required libraries like openGL? > > >> > > >> > > > > > >In configure.in . > > > > > > > > > > > >>configure.in seems to be autogenerated > by something, but whatever it is > > >>doesn't seem to be in the CVS snapshot... > > >> > > >> > > >> > > > > > >configure.in is in the CVS snapshot. > > > > > > > > > > > > > > >>Thanks, > > >> > > >>-Dan > > >> > > >>Julien PUYDT wrote: > > >> > > >> > > >> > > >>>Dan Sandberg a écrit : > > >>> > > >>> > > >>> > > >>>>How should we proceed? I could just send you an updated > gui/main.cpp > > >>>>file... > > >>>> > > >>>> > > >>>I'd like to see patches instead of full files, preferably > independant > > >>>on each others. > > >>> > > >>>There's also the question of the portability of this : since you > > >>>mention SDL, I guess this will work great on win32 too ? > > >>> > > >>>Snark > > >>>_______________________________________________ > > >>>Gnomemeeting-devel-list mailing list > > >>> Gnomemeeting-devel-list@gnome.org > > > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >>> > > >>> > > >>> > > >>_______________________________________________ > > >>Gnomemeeting-devel-list mailing list > > >> Gnomemeeting-devel-list@gnome.org > > > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >> > > >> > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > -- > _ Damien Sandras > (o- > //\ Ekiga Softphone: http://www.ekiga.org/ > v_/_ FOSDEM 2006 : http://www.fosdem.org/ > SIP Phone : sip:dsandras@ekiga.net > > sip:600000@ekiga.net > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > From mcquaidster@gmail.com Tue Jun 6 19:15:44 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1CB1D3B0100 for ; Tue, 6 Jun 2006 19:15:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28543-05 for ; Tue, 6 Jun 2006 19:15:41 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id 15D153B033F for ; Tue, 6 Jun 2006 19:15:40 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x31so65185pye for ; Tue, 06 Jun 2006 16:15:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Mcduoi+u93PszObMtVWeXgYeQW4VI1eW7YkgZ+7d03TZ67OjKeE6aoo507wYkIOly9icd2mdZ2fuDTkH7FKrnfSoGo+jOXhxLaobIUCU6gQdxyXgRqVTPVs16J/2P3hFDJ8K1ELtr1xuKRWtdbXceWGlDpZn2R3lxDak1f6E47c= Received: by 10.35.40.10 with SMTP id s10mr72093pyj; Tue, 06 Jun 2006 16:15:39 -0700 (PDT) Received: by 10.35.9.3 with HTTP; Tue, 6 Jun 2006 16:15:39 -0700 (PDT) Message-ID: <58a398810606061615s6a801fected291a67dbb85214@mail.gmail.com> Date: Tue, 6 Jun 2006 19:15:39 -0400 From: "mcquaid mcquaid" To: "Dan Sandberg" Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode In-Reply-To: <448605B0.6080504@cs.stanford.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8108_3516387.1149635739799" References: <447CCA43.3@stdout.at> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> <1149246461.2966.28.camel@golgoth01> <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> <448605B0.6080504@cs.stanford.edu> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.242 tagged_above=-999 required=2 tests=[AWL=0.223, BAYES_00=-2.599, HTML_50_60=0.134, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.242 X-Spam-Level: Cc: GnomeMeeting development mailing list X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 23:15:44 -0000 ------=_Part_8108_3516387.1149635739799 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hmm, again I don't know much about this but I think what you describe can b= e handled by hardware video overlay. Just a quick googling has this about hardware video overlay at the zoomplayer's website: http://www.inmatrix.com/zplayer/highlights/vidrender.shtml *The Video Overlay:* > At around 1995, when MPEG1 (VCD) playback started to become popular on th= e > PC, the actual processing power of the PC was not quite strong enough to > play such content. The display card manufacturers at the time came up wit= h a > solution called "The Video Overlay". The Video Overlay is a special hardw= are > on the display card which is used to perform several video-display featur= es > in hardware (Stretching, Color-Space Conversion, etc...), thus allowing > smooth playback of video at no cost to the CPU. It does go on to say that video rendering via dx9 (and thus I assume opengl) provide better image quality and don't suffer from some multimonitor issues with video overlay. Afaik, only one display can have hardware overlay so that's what he's referring to there. But, for the most part, it sounds like hardware overlay would be a nice solution as well that just about everyone would benefit from as again, ther= e are still a lot of people without good opengl in linux but most probably functional hardware overlay. Maybe an option for both? On 6/6/06, Dan Sandberg wrote: > > I could be wrong, but I believe that video overlay moves the data direct > from a capture card to the video card, bypassing the CPU. Since we're > trying to display images that come from over the network, there's no way > to bypass the CPU. And doing a nice looking resize from 176x144 to > 640x480 is quite slow. Then you have to copy the whole 640x480 image to > the display card, which is slow. With OpenGL you just copy the 176x144 > image to the video card, and have it do the resize. > > Cheers, > > -Dan > > mcquaid mcquaid wrote: > > Just a user, I'm curious as to why the trend of throwing opengl at > > everything. On one hand I think it's really cool, but this isn't like > > xgl where we want wobbly windows or something, just accelerated > > video. Isn't that what hardware video overlay is for? It takes a > > large burden off the cpu for video playback. Would benefit more > > people as some don't have proper opengl drivers. > > > > On 6/2/06, *Damien Sandras* > > wrote: > > > > Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit : > > > So configure.in is > > hand-generated? Surprising. > > > > > > > That's te way it works. You write configure.in > > and configure is > > generated from there. I guess you are confusing things here. > > > > > 1) How exactly do I add the opengl ( libgl ) library? > > > > > > > By writing autconf code in configure.in . No > > idea exactly how it should > > be done. > > > > > 2) Xrandr is mentioned in the Makefile, but is not in > > configure.in . How > > > exactly does it get put into the Makefile? > > > > > > > Probably by an external library that we are using. > > > > > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I > > didn't want > > > to code against a moving target. > > > > > > > Yes. It is even OK if you do not provide the configure.in > > code, but only > > the OpenGL Ekiga code. > > > > > Thanks, > > > > > > -Dan > > > > > > Damien Sandras wrote: > > > > > > >Le mercredi 31 mai 2006 =E0 12:41 -0700, Dan Sandberg a =E9crit = : > > > > > > > > > > > >>I'd imagine it would work on win32, but don't know. > > > >> > > > >> > > > >> > > > > > > > >Probably. > > > > > > > > > > > > > > > >>I'll work on the patches. > > > >> > > > >>Where's the right place to add required libraries like openGL? > > > >> > > > >> > > > > > > > >In configure.in . > > > > > > > > > > > > > > > >>configure.in seems to be autogenerated > > by something, but whatever it is > > > >>doesn't seem to be in the CVS snapshot... > > > >> > > > >> > > > >> > > > > > > > >configure.in is in the CVS snapshot. > > > > > > > > > > > > > > > > > > > >>Thanks, > > > >> > > > >>-Dan > > > >> > > > >>Julien PUYDT wrote: > > > >> > > > >> > > > >> > > > >>>Dan Sandberg a =E9crit : > > > >>> > > > >>> > > > >>> > > > >>>>How should we proceed? I could just send you an updated > > gui/main.cpp > > > >>>>file... > > > >>>> > > > >>>> > > > >>>I'd like to see patches instead of full files, preferably > > independant > > > >>>on each others. > > > >>> > > > >>>There's also the question of the portability of this : since > you > > > >>>mention SDL, I guess this will work great on win32 too ? > > > >>> > > > >>>Snark > > > >>>_______________________________________________ > > > >>>Gnomemeeting-devel-list mailing list > > > >>> Gnomemeeting-devel-list@gnome.org > > > > > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > >>> > > > >>> > > > >>> > > > >>_______________________________________________ > > > >>Gnomemeeting-devel-list mailing list > > > >> Gnomemeeting-devel-list@gnome.org > > > > > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > >> > > > >> > > > > > > _______________________________________________ > > > Gnomemeeting-devel-list mailing list > > > Gnomemeeting-devel-list@gnome.org > > > > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > -- > > _ Damien Sandras > > (o- > > //\ Ekiga Softphone: http://www.ekiga.org/ > > v_/_ FOSDEM 2006 : http://www.fosdem.org/ > > SIP Phone : sip:dsandras@ekiga.net > > > > sip:600000@ekiga.net > > > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > ------=_Part_8108_3516387.1149635739799 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hmm, again I don't know much about this but I think what you describe can b= e handled by
hardware video overlay.

Just a quick googling has t= his about hardware video overlay at the zoomplayer's website:

http://www.inmatrix.com/zplayer/highlights/vidrender.shtml

The Video Overlay:
At around 1995, when MPEG1 (VCD) playback started to become popular on the = PC, the actual processing power of the PC was not quite strong enough to play such content. The display card manufacturers a= t the time came up with a solution called "The Video Overlay". The Video Overlay is a special hardware on = the display card which is used to perform several video-display features in hardware (Stretching, Color-Space Conversion, etc...), thus all= owing smooth playback of video at no cost to the CPU.


It does go on to say  that video rend= ering via dx9 (and thus I assume opengl)  provide better image quality= and don't suffer from some multimonitor issues with video overlay.
Afai= k, only one display can have hardware overlay so that's what he's referring= to there.

But, for the most part, it sounds like hardware overlay would be a = nice solution as well that just about everyone would benefit from as again,= there are still a lot of people without good opengl in linux but most prob= ably functional hardware overlay.

Maybe an option for both? 

On 6/6/06, Dan Sandberg <<= a href=3D"mailto:x@cs.stanford.edu">x@cs.stanford.edu> wrote:=
I could be wrong, but I believe that video overlay moves the data directfrom a capture card to the video card, bypassing the CPU.  Since= we're
trying to display images that come from over the network, there's= no way
to bypass the CPU.  And doing a nice looking resize from 176x= 144 to
640x480 is quite slow.  Then you have to copy the whole= 640x480 image to
the display card, which is slow.  With OpenG= L you just copy the 176x144
image to the video card, and have it do the resize.

Cheers,
<= br>-Dan

mcquaid mcquaid wrote:
> Just a user, I'm curious as t= o why the trend of throwing opengl at
> everything.  On one= hand I think it's really cool, but this isn't like
> xgl where we want wobbly windows or something, just accelerated> video.  Isn't that what hardware video overlay is for? = ; It takes a
> large burden off the cpu for video playback. = ; Would benefit more
> people as some don't have proper opengl drivers.
>
> On 6/= 2/06, *Damien Sandras* <dsandras= @seconix.com
> <mailto: dsandras@seconix.com>> wrote:
>
>   &n= bsp; Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit :
= >     > So config= ure.in < http://configure.in> is
>     hand-generat= ed?  Surprising.
>     >
>
= >     That's te way it works. You write configure.in
>     < http://configure.in> and configure is
>    = ; generated from there. I guess you are confusing things here.
>
&= gt;     > 1) How exactly do I add the opengl ( libgl= ) library?
>     >
>
>     By writing autconf code in configure.in <http:= //configure.in>. No
>     idea exactly how= it should
>     be done.
>
>     > 2) Xrandr is mentioned in the Makefile, b= ut is not in
>     configure.in <http://configure.in<= /a>>.  How
>     > exactly does i= t get put into the Makefile?
>     >
>
>   &nbs= p; Probably by an external library that we are using.
>
> =     > 3) Is it ok if I send in a patch that is for Ekiga = 2.0.1?  I
>     didn't want
>&nbs= p;    > to code against a moving target.
>     >
>
>   &nbs= p; Yes. It is even OK if you do not provide the configure.in
>     <http://configure.in> code, but only
>     the OpenGL Ekiga code.
>
> &n= bsp;   > Thanks,
>     >
>&= nbsp;    > -Dan
>     >
&= gt;     > Damien Sandras wrote:
>  &= nbsp;  >
>     > >Le mercredi 31 ma= i 2006 =E0 12:41 -0700, Dan Sandberg a =E9crit :
>     > >
>     = > >
>     > >>I'd imagine it would= work on win32, but don't know.
>     > >&g= t;
>     > >>
>   &= nbsp; > >>
>     > >
>     > >Probably.
>  &nbs= p;  > >
>     > >
> &= nbsp;   > >
>     > >>I'= ll work on the patches.
>     > >>
&g= t;     > >>Where's the right place to add requ= ired libraries like openGL?
>     > >>
>   &nb= sp; > >>
>     > >
> &n= bsp;   > >In configure.in <http://configure.in>.
>=      > >
>     > >
>     = > >
>     > >>configure.in <http://con= figure.in> seems to be autogenerated
>    = by something, but whatever it is
>     > >>doesn't seem to be in the CVS= snapshot...
>     > >>
> &nb= sp;   > >>
>     > >>=
>     > >
>     = > >configure.in <http://configure.in> is in = the CVS snapshot.
>     > >
> &n= bsp;   > >
>     > >
>= ;     > >
>     > &g= t;>Thanks,
>     > >>
>     > >>-Dan
>   = ;  > >>
>     > >>Julien P= UYDT wrote:
>     > >>
> &nbs= p;   > >>
>     > >><= br>>     > >>>Dan Sandberg a =E9crit :
>     > >>>
>   = ;  > >>>
>     > >>>=
>     > >>>>How should we proceed= ?  I could just send you an updated
>   &nbs= p; gui/main.cpp
>     > >>>>file..= .
>     > >>>>
>  &= nbsp;  > >>>>
>     > >= >>I'd like to see patches instead of full files, preferably
>&n= bsp;    independant
>     > >= ;>>on each others.
>     > >>>
>   = ;  > >>>There's also the question of the portability of th= is : since you
>     > >>>mention SDL= , I guess this will work great on win32 too ?
>   &nbs= p; > >>>
>     > >>>Snark
>  =    > >>>_____________________________________________= __
>     > >>>Gnomemeeting-devel-list= mailing list
>     > >>> Gnomemeeting-devel-list@gnome.org
>     <m= ailto:Gnomemeeting-dev= el-list@gnome.org>
>     > >>>= http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>&= nbsp;    > >>>
>     &= gt; >>>
>     > >>>
>&= nbsp;    > >>______________________________________= _________
>     > >>Gnomemeeting-devel-list maili= ng list
>     > >> Gnomemeeting-devel-list@gnome.org
&g= t;     <mailto: Gnomemeeting-devel-list@gnome.org>
>     &= gt; >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list<= /a>
>     > >>
>     > >>
>   &nb= sp; >
>     > _____________________________= __________________
>     > Gnomemeeting-devel-= list mailing list
>     > Gnomemeeting-devel-list@gnome.org
>     <m= ailto:Gnomemeeting-dev= el-list@gnome.org>
>     > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>&= nbsp;    --
>     _  &nb= sp;   Damien Sandras
>     (o-
= >     //\     Ekiga Softphone: <= a href=3D"http://www.ekiga.org/">http://www.ekiga.org/
>     v_/_    FOSDEM 200= 6    : http://www.fo= sdem.org/
>         =     SIP Phone      : sip:dsandras@ekiga.net
> =     <mailto: sip:dsandr= as@ekiga.net>
>        = ;            &n= bsp;         sip:600000@ekiga.net
>   &n= bsp; <mailto: sip:600000@ekiga.net>
>= ;
>     _________________________________________= ______
>     Gnomemeeting-devel-list mailing list=
>     Gnomemeeting-devel-list@gnome.org
>     <m= ailto:Gnomemeeting-dev= el-list@gnome.org>
>     http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>&= nbsp;    <http://mail.gnome.org/mailman/listinfo/gnomemee= ting-devel-list >
>
>
> ----------------------------------------------= --------------------------
>
> ________________________________= _______________
> Gnomemeeting-devel-list mailing list
> Gnomemeeting-devel-list@gnome.org
> http://mail.gnome.org/mailman= /listinfo/gnomemeeting-devel-list
>

------=_Part_8108_3516387.1149635739799-- From stefan@watri.org.au Wed Jun 7 00:39:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 26FE33B0B45 for ; Wed, 7 Jun 2006 00:39:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12142-08 for ; Wed, 7 Jun 2006 00:39:13 -0400 (EDT) Received: from asclepius.uwa.edu.au (asclepius.uwa.edu.au [130.95.128.56]) by menubar.gnome.org (Postfix) with ESMTP id 1153F3B022D for ; Wed, 7 Jun 2006 00:39:11 -0400 (EDT) Received: from asclepius.kas (localhost.localdomain [127.0.0.1]) by asclepius.uwa.edu.au (Postfix) with SMTP id 9EF11184629 for ; Wed, 7 Jun 2006 12:39:05 +0800 (WST) Received: from asclepius (localhost.localdomain [127.0.0.1]) by asclepius.prekas (Postfix) with SMTP id 7CB52188123 for ; Wed, 7 Jun 2006 12:39:05 +0800 (WST) X-UWA-Client-IP: 130.95.28.15 (UWA) Received: from ns1.watri.uwa.edu.au (ns1.watri.org.au [130.95.28.15]) by asclepius.extinput (Postfix) with ESMTP id 6CCE5188174 for ; Wed, 7 Jun 2006 12:39:05 +0800 (WST) Received: from gluttony (gluttony.watri.org.au [130.95.29.76]) by ns1.watri.uwa.edu.au (8.13.1/8.13.1) with ESMTP id k574d4dE023954 for ; Wed, 7 Jun 2006 12:39:04 +0800 (WST) Message-Id: <200606070439.k574d4dE023954@ns1.watri.uwa.edu.au> From: =?iso-8859-1?Q?Stefan_Br=FCns?= To: "'GnomeMeeting development mailing list'" Subject: RE: [GnomeMeeting-devel-list] Full Screen Mode Date: Wed, 7 Jun 2006 12:41:40 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <448605B0.6080504@cs.stanford.edu> Thread-Index: AcaJu2+MfoUGcqUFRii2sxvr70Y3NQALgJIg X-SpamTest-Info: Profile: Formal (387/060606) X-SpamTest-Info: Profile: Detect Hard [UCS 290904] X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking Spam - Subject (UCS) [02-08-04] X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.176 tagged_above=-999 required=2 tests=[AWL=-1.125, BAYES_40=-0.185, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] X-Spam-Score: -1.176 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 04:39:16 -0000 > -----Original Message----- > From: gnomemeeting-devel-list-bounces@gnome.org > [mailto:gnomemeeting-devel-list-bounces@gnome.org] On Behalf > Of Dan Sandberg > Sent: Wednesday, 7 June 2006 6:46 AM > To: GnomeMeeting development mailing list > Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode > > I could be wrong, but I believe that video overlay moves the > data direct > >from a capture card to the video card, bypassing the CPU. > Since we're > trying to display images that come from over the network, > there's no way > to bypass the CPU. And doing a nice looking resize from 176x144 to > 640x480 is quite slow. Then you have to copy the whole > 640x480 image to > the display card, which is slow. With OpenGL you just copy > the 176x144 > image to the video card, and have it do the resize. Just to clarify some things: Video overlay over XV support scaling in hardware, and colorspace transforms. Unfortunately, most graphic cards support only one overlay at a time. In case you only have a single video, this is fine, but as soon as you have multiple (local/remote, maybe conference anytime in the future), you have to do the compositing before uploading the image to the card. In case of Picture in Picture, this means that you a) Scale the to be small video down, compose it into the large one, and upload the composed image. Drawback: Also the small image may end up as large as an unscaled CIF image, it will have a lower resolution, due to the downscaling. or b) Scale the to be large image up, and compose the small image into it. Also the small image will have its full resolution (it may be a CIF (352x288) image on a 1024x768 or larger screen), the upscaling of the large image adds a lot of burden to the CPU and memory transfers. On the other hand, if you use OpenGL textures, you have all the benefits: - You can upload every video to a different texture, every video ends up on the screen with all the available resolution, all the scaling is done on the GPU (which is very efficient for this). - Most cards support YUV colorspaces for textures, so color transform can be done on the card. - As the different videos stream end up on different textures, you may have the local video with full 25fps framerate, and the remote with something like 10fps. - Superimposing any text (Chat, callers name, new incoming call ...) comes down to putting the text into just another texture. This may be easily alpha blended, with full screen resolution (if you superimpose text on the video directly, you can only use the videos resolution, and edges may look really strange due to the UV subsampling). - You may due almost arbitrary transforms on the video, without burdening the CPU (have a look at the Conference feature of iChat AV to see what I mean). Greetings, Stefan From t.schorpp@gmx.de Wed Jun 7 03:35:24 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 125143B0C5F for ; Wed, 7 Jun 2006 03:35:24 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23077-04 for ; Wed, 7 Jun 2006 03:35:22 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by menubar.gnome.org (Postfix) with SMTP id 544083B0368 for ; Wed, 7 Jun 2006 03:35:21 -0400 (EDT) Received: (qmail invoked by alias); 07 Jun 2006 07:35:19 -0000 Received: from p85.212.144.48.tisdip.tiscali.de (EHLO [192.168.1.100]) [85.212.144.48] by mail.gmx.net (mp029) with SMTP; 07 Jun 2006 09:35:19 +0200 X-Authenticated: #17142692 Message-ID: <448681B6.5000204@gmx.de> Date: Wed, 07 Jun 2006 09:35:18 +0200 From: thomas schorpp User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1 X-Accept-Language: de, en-us MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode References: <200606070439.k574d4dE023954@ns1.watri.uwa.edu.au> In-Reply-To: <200606070439.k574d4dE023954@ns1.watri.uwa.edu.au> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.476 tagged_above=-999 required=2 tests=[AWL=-0.011, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] X-Spam-Score: -2.476 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: t.schorpp@gmx.de, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 07:35:24 -0000 Stefan Brüns wrote: >>-----Original Message----- >>From: gnomemeeting-devel-list-bounces@gnome.org >>[mailto:gnomemeeting-devel-list-bounces@gnome.org] On Behalf >>Of Dan Sandberg >>Sent: Wednesday, 7 June 2006 6:46 AM >>To: GnomeMeeting development mailing list >>Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode >> >>I could be wrong, but I believe that video overlay moves the >>data direct >>>from a capture card to the video card, bypassing the CPU. >>Since we're >>trying to display images that come from over the network, >>there's no way >>to bypass the CPU. And doing a nice looking resize from 176x144 to >>640x480 is quite slow. Then you have to copy the whole >>640x480 image to >>the display card, which is slow. With OpenGL you just copy >>the 176x144 >>image to the video card, and have it do the resize. > > > Just to clarify some things: > > Video overlay over XV support scaling in hardware, and colorspace > transforms. are You sure? ive some display apps here which can switch between XV and "real overlay". kvdr, tvtime, xawtv... XV can use significant high cpu load in my experience here... > > Unfortunately, most graphic cards support only one overlay at a time. not sure about this, too. all the chips i had since ati mach64 supported at least 2 overlays at a time. kvdr supports even up to 4 overlays(?) on modern cards respectively. http://www.s.netic.de/gfiala/ > In > case you only have a single video, this is fine, but as soon as you have > multiple (local/remote, maybe conference anytime in the future), you have to > do the compositing before uploading the image to the card. In case of > Picture in Picture, this means that you > > a) Scale the to be small video down, compose it into the large one, and > upload the composed image. Drawback: Also the small image may end up as > large as an unscaled CIF image, it will have a lower resolution, due to the > downscaling. > > or > b) Scale the to be large image up, and compose the small image into it. Also > the small image will have its full resolution (it may be a CIF (352x288) > image on a 1024x768 or larger screen), the upscaling of the large image adds > a lot of burden to the CPU and memory transfers. > > On the other hand, if you use OpenGL textures, you have all the benefits: > - You can upload every video to a different texture, every video ends up on > the screen with all the available resolution, all the scaling is done on the > GPU (which is very efficient for this). > - Most cards support YUV colorspaces for textures, so color transform can be > done on the card. > - As the different videos stream end up on different textures, you may have > the local video with full 25fps framerate, and the remote with something > like 10fps. > - Superimposing any text (Chat, callers name, new incoming call ...) comes > down to putting the text into just another texture. This may be easily alpha > blended, with full screen resolution (if you superimpose text on the video > directly, you can only use the videos resolution, and edges may look really > strange due to the UV subsampling). > - You may due almost arbitrary transforms on the video, without burdening > the CPU (have a look at the Conference feature of iChat AV to see what I > mean). > > Greetings, > is there no standard "network video class" for the application layer somewhere? > Stefan tom From jpuydt@free.fr Wed Jun 7 07:50:57 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 57F3B3B030A for ; Wed, 7 Jun 2006 07:50:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08294-07 for ; Wed, 7 Jun 2006 07:50:54 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id 565043B03D0 for ; Wed, 7 Jun 2006 07:50:54 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp3-g19.free.fr (Postfix) with ESMTP id 26AE4498B4 for ; Wed, 7 Jun 2006 13:50:53 +0200 (CEST) Message-ID: <4486BDD0.9050805@free.fr> Date: Wed, 07 Jun 2006 13:51:44 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.845 tagged_above=-999 required=2 tests=[AWL=-0.735, BAYES_05=-1.11] X-Spam-Score: -1.845 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Refactoring of the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 11:50:57 -0000 Hi, after some discussions, it seems my initial ideas just don't fly. I don't consider them as a full failure, but they certainly are 80% so. I has in particular a long (private) discussion with Éric Bischoff, which allowed me to test my ideas on a newcomer. :-) Snark From jpuydt@free.fr Wed Jun 7 08:02:38 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A3A943B0CA0 for ; Wed, 7 Jun 2006 08:02:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09379-09 for ; Wed, 7 Jun 2006 08:02:30 -0400 (EDT) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by menubar.gnome.org (Postfix) with ESMTP id 0A6253B0CFE for ; Wed, 7 Jun 2006 08:01:42 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp2-g19.free.fr (Postfix) with ESMTP id 9A1E973329 for ; Wed, 7 Jun 2006 14:01:41 +0200 (CEST) Message-ID: <4486C05B.9080200@free.fr> Date: Wed, 07 Jun 2006 14:02:35 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> In-Reply-To: <4486BDD0.9050805@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:02:38 -0000 Julien PUYDT a écrit : > Notice that I forgot the conclusion : back to blackboard :-) Snark From pbrobinson@gmail.com Wed Jun 7 08:05:53 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D7E343B0C89 for ; Wed, 7 Jun 2006 08:05:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09667-03 for ; Wed, 7 Jun 2006 08:05:53 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by menubar.gnome.org (Postfix) with ESMTP id 33FD03B0C35 for ; Wed, 7 Jun 2006 08:05:52 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id q2so283058uge for ; Wed, 07 Jun 2006 05:05:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=G9St54usrU1EqN6hzRVdcsL0b9E6Bqxv3H4s4TGGxDEm0S9y4VTy4J2/S9c86GUzX86KIkPRd3gDHRfgFY6rCHfD2mYVgjzsw18dl0V8Ib8+WG4xy7/jO5pBwQEky1I69/GeIoNY6Q1nIE7TBp9rIFYmsHkPs+aO3lXDh5BJAzE= Received: by 10.67.89.5 with SMTP id r5mr423228ugl; Wed, 07 Jun 2006 05:05:51 -0700 (PDT) Received: by 10.67.25.6 with HTTP; Wed, 7 Jun 2006 05:05:51 -0700 (PDT) Message-ID: <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> Date: Wed, 7 Jun 2006 13:05:51 +0100 From: "Peter Robinson" To: "GnomeMeeting development mailing list" Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code In-Reply-To: <4486C05B.9080200@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4486BDD0.9050805@free.fr> <4486C05B.9080200@free.fr> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.56 tagged_above=-999 required=2 tests=[AWL=-0.518, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.56 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:05:54 -0000 > Julien PUYDT a =E9crit : > > > > Notice that I forgot the conclusion : back to blackboard :-) So are there any ideas running around that blackboard as of yet? Peter From jpuydt@free.fr Wed Jun 7 08:22:36 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CBE393B08CC for ; Wed, 7 Jun 2006 08:22:36 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10857-05 for ; Wed, 7 Jun 2006 08:22:35 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 97D9B3B0CDC for ; Wed, 7 Jun 2006 08:22:35 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp5-g19.free.fr (Postfix) with ESMTP id 65742275AC for ; Wed, 7 Jun 2006 14:22:34 +0200 (CEST) Message-ID: <4486C53D.2080306@free.fr> Date: Wed, 07 Jun 2006 14:23:25 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> In-Reply-To: <4486BDD0.9050805@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:22:37 -0000 Ok, so let's see what the constraints are. 1) the already available addressbooks must fit in the new scheme ; 2) the future kde addressbooks must find their place easily ; 3) searching should be dead-easy ; 4) the future "live" contacts must find their place easily ; 5) the backend-frontend frontier should be clear enough to allow for easy DBUS exporting 6) Damien wants it fast. Yes, going back to the blackboard isn't the best way to achieve 6... Snark From jpuydt@free.fr Wed Jun 7 08:52:53 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 92FD63B03C4 for ; Wed, 7 Jun 2006 08:52:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12995-08 for ; Wed, 7 Jun 2006 08:52:50 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id D0F7E3B0C97 for ; Wed, 7 Jun 2006 08:52:49 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp3-g19.free.fr (Postfix) with ESMTP id AEAAC497A1 for ; Wed, 7 Jun 2006 14:52:48 +0200 (CEST) Message-ID: <4486CC54.9090206@free.fr> Date: Wed, 07 Jun 2006 14:53:40 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <4486C05B.9080200@free.fr> <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> In-Reply-To: <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:52:53 -0000 Peter Robinson a écrit : > So are there any ideas running around that blackboard as of yet? Plenty. Snark From ebischoff@nerim.net Wed Jun 7 09:43:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C57F03B03C1 for ; Wed, 7 Jun 2006 09:43:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17343-08 for ; Wed, 7 Jun 2006 09:43:14 -0400 (EDT) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by menubar.gnome.org (Postfix) with ESMTP id BB8E53B03F1 for ; Wed, 7 Jun 2006 09:43:13 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 09C7C40FD8 for ; Wed, 7 Jun 2006 15:43:11 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Wed, 7 Jun 2006 15:43:21 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <4486C53D.2080306@free.fr> In-Reply-To: <4486C53D.2080306@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606071543.22163.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.562 tagged_above=-999 required=2 tests=[AWL=0.037, BAYES_00=-2.599] X-Spam-Score: -2.562 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 13:43:16 -0000 Le Mercredi 7 Juin 2006 14:23, Julien PUYDT a =C3=A9crit=C2=A0: > Yes, going back to the blackboard isn't the best way to achieve 6... You don't go black to the blackboard with no experience ;-). In pecular, I have been proposing a framework for address book "drivers" li= ke: class EkigaAddressBook { public: virtual gchar *name() const =3D 0; virtual const EkigaContact *firstContact() =3D 0; virtual const EkigaContact *nextContact() =3D 0; }; class EkigaContact { public: virtual boolean hasName() const =3D 0; virtual gchar *name() const =3D 0; virtual boolean hasTelephone() const =3D 0; virtual gchar *telephone() const =3D 0; etc... }; class EkigaEvolutionAddressBook : public EkigaAddressBook { public: virtual gchar *name() const; virtual const EkigaContact *firstContact(); virtual const EkigaContact *nextContact(); }; class EkigaEvolutionContact : public EkigaContact { public: virtual boolean hasName() const; virtual gchar *name() const; virtual boolean hasTelephone() const; virtual gchar *telephone() const; etc... }; Comments and flames welcome. =2D-=20 =C3=89ric From jpuydt@free.fr Wed Jun 7 13:58:31 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6343F3B0BC1 for ; Wed, 7 Jun 2006 13:58:31 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02884-04 for ; Wed, 7 Jun 2006 13:58:23 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 55DA13B069F for ; Wed, 7 Jun 2006 13:58:19 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp1-g19.free.fr (Postfix) with ESMTP id E2BA8911A6 for ; Wed, 7 Jun 2006 19:58:17 +0200 (CEST) Message-ID: <4486F76C.7060301@free.fr> Date: Wed, 07 Jun 2006 17:57:32 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <4486C53D.2080306@free.fr> <200606071543.22163.ebischoff@nerim.net> In-Reply-To: <200606071543.22163.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 17:58:31 -0000 Éric Bischoff a écrit : > Le Mercredi 7 Juin 2006 14:23, Julien PUYDT a écrit : >> Yes, going back to the blackboard isn't the best way to achieve 6... > > You don't go black to the blackboard with no experience ;-). Of course no :-) > In pecular, I have been proposing a framework for address book "drivers" like: > > class EkigaAddressBook > { > public: > virtual gchar *name() const = 0; > virtual const EkigaContact *firstContact() = 0; > virtual const EkigaContact *nextContact() = 0; > }; I don't like your first/next idea. If I take an XMPP roster in ekiga, connect to the same account from another program, and add a contact there, the XMPP roster will do a roster push, which your api doesn't handle. A much better approach IMNSHO, when it comes to keeping track of a list of contacts, is the following pseudo-code api : - get the current list of contacts ; - notify/signal me when a new one appears. There are two ways to handle the removing of a contact from such a list: (i) either the book tells you the contact has been removed ; (ii) or the contact itself tells you so. Both can be handled by a notification/signal. My first tests used the second way to do so, but now I think the first is better : the signal tells you both the book and the contact. > class EkigaContact > { > public: > virtual boolean hasName() const = 0; > virtual gchar *name() const = 0; > > virtual boolean hasTelephone() const = 0; > virtual gchar *telephone() const = 0; > > etc... > }; Bad. :-) First, you don't handle the case where several telephone numbers are available. Then if you begin to put /everything/ in the *base* class, that will end badly. A base class should only have the most basic capabilities, not all of them. > Comments and flames welcome. As a last comment, I will repoint the two arguments I have to prefer a GObject solution to a C++ solution : 1) the GObject will nicely live and die in the glib mainloop, so we won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere ; 2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame /dev/null). Snark From jpuydt@free.fr Wed Jun 7 14:30:54 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6C9E83B0255 for ; Wed, 7 Jun 2006 14:30:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04954-09 for ; Wed, 7 Jun 2006 14:30:52 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 15D9C3B0135 for ; Wed, 7 Jun 2006 14:30:52 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp5-g19.free.fr (Postfix) with ESMTP id E116F2766C for ; Wed, 7 Jun 2006 20:30:50 +0200 (CEST) Message-ID: <44871B92.9090703@free.fr> Date: Wed, 07 Jun 2006 20:31:46 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <4486C05B.9080200@free.fr> <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> <4486CC54.9090206@free.fr> In-Reply-To: <4486CC54.9090206@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 18:30:54 -0000 Julien PUYDT a écrit : > Plenty. Ok, here are a few. First of all, Éric convinced me the "no common class for contacts" was bad. So the main organization should probably be the following : - at the upper level, there are sources of addressbooks (avahi, e-d-s, kab, call history, xmpp...) ; - those sources give access to addressbooks ; - those addressbooks contain contacts. Now the question is detailing what is done where :-) Snark From ebischoff@nerim.net Wed Jun 7 14:33:56 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E21DC3B027D for ; Wed, 7 Jun 2006 14:33:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05177-06 for ; Wed, 7 Jun 2006 14:33:54 -0400 (EDT) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by menubar.gnome.org (Postfix) with ESMTP id 360A33B0135 for ; Wed, 7 Jun 2006 14:33:53 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 7CB2240E26 for ; Wed, 7 Jun 2006 20:33:50 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Wed, 7 Jun 2006 20:33:52 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606071543.22163.ebischoff@nerim.net> <4486F76C.7060301@free.fr> In-Reply-To: <4486F76C.7060301@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606072033.54523.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.569 tagged_above=-999 required=2 tests=[AWL=0.030, BAYES_00=-2.599] X-Spam-Score: -2.569 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 18:33:56 -0000 Le Mercredi 7 Juin 2006 17:57, Julien PUYDT a =C3=A9crit=C2=A0: > A much better approach IMNSHO, when it comes to keeping track of a list > of contacts, is the following pseudo-code api : > - get the current list of contacts ; > - notify/signal me when a new one appears. I am not sure that the Evolution, LDAP or KAddressBook drivers will all be= =20 able to wake up when a new contact is created. The contact can be created=20 asynchronously by another user on another machine on some LDAP server far=20 away on a network that is broken half of the time, for example. So even the= =20 underlying Evolution / LDAP / KAddressBook libraries might not know. =46urthermore, keeping a list all contacts in memory can have a high cost i= n=20 memory usage. > There are two ways to handle the removing of a contact from such a list: > (i) either the book tells you the contact has been removed ; > (ii) or the contact itself tells you so. > Both can be handled by a notification/signal. My first tests used the > second way to do so, but now I think the first is better : the signal > tells you both the book and the contact. Is that such a problem if the driver loops over an older version of the lis= t? > First, you don't handle the case where several telephone numbers are > available. Yeah, yeah. That was just an example. > Then if you begin to put /everything/ in the *base* class, that will end > badly. A base class should only have the most basic capabilities, not > all of them. Well, most address books are expected to deliver names and telephone=20 numbers ,-). But if you don't want to code hooks that return NULL all the=20 time for properties that do not exist (which I can understand), there's an= =20 easy and clean variant: class EkigaContact { public: enum property { name, telephone, street, ... }; virtual bool hasProperty(property p) const =3D 0; gchar *value(property p) const =3D 0; }; So contact->value(street) returns the street address and if contact->hasProperty(street) is true. > As a last comment, I will repoint the two arguments I have to prefer a > GObject solution to a C++ solution : Well, that's the kind of debate that can typically end up in a religious=20 war ;-), but: 1) why reinvent the wheel? C++ has mechanisms for object programming, it's= =20 rather strange to reimplement them in C; 2) such choices tie Ekiga more deeply into GNOME libraries (okay, it's a GN= OME=20 project. But...) > 1) the GObject will nicely live and die in the glib mainloop, so we > won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere= ; > 2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga > more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame > /dev/null). GBUS is indeed a nice invention ;-). =2D-=20 =C3=89ric From jpuydt@free.fr Wed Jun 7 15:29:48 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 91CC53B027D for ; Wed, 7 Jun 2006 15:29:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08481-05 for ; Wed, 7 Jun 2006 15:29:45 -0400 (EDT) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by menubar.gnome.org (Postfix) with ESMTP id 54DB33B0546 for ; Wed, 7 Jun 2006 15:29:45 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp2-g19.free.fr (Postfix) with ESMTP id 2EC0A6FECE for ; Wed, 7 Jun 2006 21:29:44 +0200 (CEST) Message-ID: <4487295A.9060506@free.fr> Date: Wed, 07 Jun 2006 21:30:34 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606071543.22163.ebischoff@nerim.net> <4486F76C.7060301@free.fr> <200606072033.54523.ebischoff@nerim.net> In-Reply-To: <200606072033.54523.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 19:29:48 -0000 Éric Bischoff a écrit : > Le Mercredi 7 Juin 2006 17:57, Julien PUYDT a écrit : >> A much better approach IMNSHO, when it comes to keeping track of a list >> of contacts, is the following pseudo-code api : >> - get the current list of contacts ; >> - notify/signal me when a new one appears. > > I am not sure that the Evolution, LDAP or KAddressBook drivers will all be > able to wake up when a new contact is created. The contact can be created > asynchronously by another user on another machine on some LDAP server far > away on a network that is broken half of the time, for example. So even the > underlying Evolution / LDAP / KAddressBook libraries might not know. Well, for those what I propose still works : - they get a list of contacts (and emit the "contact-added" signal for each) ; - when they are refreshed, they remove all their contacts, and get the new list of contacts. And what I propose works also for XMPP rosters, which are dynamically updated. > Furthermore, keeping a list all contacts in memory can have a high cost in > memory usage. Indeed, some books shouldn't treat "get the list of contacts" litterally. That is why they shouldn't be too stupid :-) >> There are two ways to handle the removing of a contact from such a list: >> (i) either the book tells you the contact has been removed ; >> (ii) or the contact itself tells you so. >> Both can be handled by a notification/signal. My first tests used the >> second way to do so, but now I think the first is better : the signal >> tells you both the book and the contact. > > Is that such a problem if the driver loops over an older version of the list? To do what ? It is not a problem if the list of users on ekiga.net isn't updated live. But it certainly is if your XMPP roster isn't ! >> First, you don't handle the case where several telephone numbers are >> available. > > Yeah, yeah. That was just an example. :-) >> Then if you begin to put /everything/ in the *base* class, that will end >> badly. A base class should only have the most basic capabilities, not >> all of them. > > Well, most address books are expected to deliver names and telephone > numbers ,-). But if you don't want to code hooks that return NULL all the > time for properties that do not exist (which I can understand), there's an > easy and clean variant: > class EkigaContact > { > public: > enum property { name, telephone, street, ... }; > > virtual bool hasProperty(property p) const = 0; > gchar *value(property p) const = 0; > }; Eh... this looks like GObject properties! >> As a last comment, I will repoint the two arguments I have to prefer a >> GObject solution to a C++ solution : > > Well, that's the kind of debate that can typically end up in a religious > war ;-), but: > 1) why reinvent the wheel? C++ has mechanisms for object programming, it's > rather strange to reimplement them in C; > 2) such choices tie Ekiga more deeply into GNOME libraries (okay, it's a GNOME > project. But...) glib/gobject isn't gnome. It isn't even graphical. >> 1) the GObject will nicely live and die in the glib mainloop, so we >> won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere ; >> 2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga >> more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame >> /dev/null). > > GBUS is indeed a nice invention ;-). DBUS, not GBUS. Snark From ebischoff@nerim.net Wed Jun 7 17:05:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 354B63B00A5 for ; Wed, 7 Jun 2006 17:05:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14677-05 for ; Wed, 7 Jun 2006 17:05:13 -0400 (EDT) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by menubar.gnome.org (Postfix) with ESMTP id CB5F43B0135 for ; Wed, 7 Jun 2006 17:05:12 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 1E15A437B0 for ; Wed, 7 Jun 2006 22:52:51 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Wed, 7 Jun 2006 22:53:00 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606072033.54523.ebischoff@nerim.net> <4487295A.9060506@free.fr> In-Reply-To: <4487295A.9060506@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606072253.01820.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.573 tagged_above=-999 required=2 tests=[AWL=0.026, BAYES_00=-2.599] X-Spam-Score: -2.573 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 21:05:17 -0000 Le Mercredi 7 Juin 2006 21:30, Julien PUYDT a =C3=A9crit=C2=A0: > > I am not sure that the Evolution, LDAP or KAddressBook drivers will all > > be able to wake up when a new contact is created. The contact can be > > created asynchronously by another user on another machine on some LDAP > > server far away on a network that is broken half of the time, for > > example. So even the underlying Evolution / LDAP / KAddressBook librari= es > > might not know. > > Well, for those what I propose still works : > - they get a list of contacts (and emit the "contact-added" signal for > each) ; > - when they are refreshed, they remove all their contacts, and get the > new list of contacts. What makes you think that they get "refreshed" at some point? > And what I propose works also for XMPP rosters, which are dynamically > updated. Promise, I will look someday what a "XMPP roster" is ;-). > > Furthermore, keeping a list all contacts in memory can have a high cost > > in memory usage. > > Indeed, some books shouldn't treat "get the list of contacts" > litterally. That is why they shouldn't be too stupid :-) Then you must some kind of evolved caching mechanism in your driver. That's= =20 sounds overcomplicated and hard to code to me. If you simply loop through t= he=20 contacts, you can just get the information you need and display it. > > Is that such a problem if the driver loops over an older version of the > > list? > > To do what ? It is not a problem if the list of users on ekiga.net isn't > updated live. But it certainly is if your XMPP roster isn't ! If you convinced me of one thing, it's that I need to look at the definitio= n=20 of these SNMP toasters ;-). > > class EkigaContact > > { > > public: > > enum property { name, telephone, street, ... }; > > > > virtual bool hasProperty(property p) const =3D 0; > > gchar *value(property p) const =3D 0; > > }; > > Eh... this looks like GObject properties! Indeed! Excepted that you are just using the possibilities of the programmi= ng=20 language, not of some library. At this point, I must do some clarification: I am a newcomer to Ekiga and perfectly aware of the fact that I might ignor= e a=20 lot of things about the past and the possible future of this software. I am= a=20 complete ignorant of GNOME and its libraries. I do not know anything about= =20 the multithreading problems that Julien has to deal with. I am not here to= =20 slow down Julien, nor to get my views adopted. I will be more than happy to= =20 adapt my code to *any* API that Julien will bring up. And to shut my big=20 mouth up if anyone ask me to ;-). > glib/gobject isn't gnome. It isn't even graphical. Okay, to me who comes from the KDE world, it's the same thing, it starts wi= th=20 "g" ;-). > > GBUS is indeed a nice invention ;-). > > DBUS, not GBUS. Yes, sorry for the many typos... :-/ =2D-=20 =C3=89ric From jan.schampera@web.de Wed Jun 7 23:13:06 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7395E3B043B for ; Wed, 7 Jun 2006 23:13:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02368-03 for ; Wed, 7 Jun 2006 23:13:03 -0400 (EDT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by menubar.gnome.org (Postfix) with ESMTP id 6D4823B012E for ; Wed, 7 Jun 2006 23:13:03 -0400 (EDT) Received: from fwd35.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1FoAxC-0004rd-00; Thu, 08 Jun 2006 05:13:02 +0200 Received: from mail.home.thebonsai.de (Z2ab0kZBZewL1AHEQWezyBxMlAJSeayZbCOT8jbF9IKQFlf7QKn1Ul@[84.147.102.15]) by fwd35.sul.t-online.de with esmtp id 1FoAx4-1YpxqK0; Thu, 8 Jun 2006 05:12:54 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id 8DF136B173 for ; Thu, 8 Jun 2006 05:12:52 +0200 (CEST) Date: Thu, 8 Jun 2006 05:08:28 +0200 From: Jan Schampera To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Message-ID: <20060608050828.37d3ac08@localhost.localdomain> In-Reply-To: <200606072253.01820.ebischoff@nerim.net> References: <4486BDD0.9050805@free.fr> <200606072033.54523.ebischoff@nerim.net> <4487295A.9060506@free.fr> <200606072253.01820.ebischoff@nerim.net> Organization: private X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-ID: Z2ab0kZBZewL1AHEQWezyBxMlAJSeayZbCOT8jbF9IKQFlf7QKn1Ul@t-dialin.net X-TOI-MSGID: c2323eec-2b6b-468d-b9e5-6ee93ecdce82 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.971 tagged_above=-999 required=2 tests=[AWL=0.627, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.971 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 03:13:06 -0000 On Wed, 7 Jun 2006 22:53:00 +0200 =C3=89ric Bischoff wrote: > (GLib vs OOP) > Indeed! Excepted that you are just using the possibilities of the > programming language, not of some library. Please note, regardless all other arguments, that an own C++-object system will be totally independant of the used framework. In case we leave GTK and GLib some day, the OOP approach won't need any changes. The GObject approach would need either an equivalent in the new framework, or a rewrite to (finally) OOP. Beside that, I tend to say "a matter of taste". J. --=20 dreaming in digital living in realtime thinking in binary talking in IP WELCOME TO OUR WORLD From jpuydt@free.fr Thu Jun 8 04:39:27 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8DA623B05CC for ; Thu, 8 Jun 2006 04:39:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19858-03 for ; Thu, 8 Jun 2006 04:39:24 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id D38EA3B0E0F for ; Thu, 8 Jun 2006 04:39:23 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp6-g19.free.fr (Postfix) with ESMTP id A778922647 for ; Thu, 8 Jun 2006 10:39:22 +0200 (CEST) Message-ID: <4487E272.80605@free.fr> Date: Thu, 08 Jun 2006 10:40:18 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606072033.54523.ebischoff@nerim.net> <4487295A.9060506@free.fr> <200606072253.01820.ebischoff@nerim.net> In-Reply-To: <200606072253.01820.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 08:39:27 -0000 Éric Bischoff a écrit : > Le Mercredi 7 Juin 2006 21:30, Julien PUYDT a écrit : >>> I am not sure that the Evolution, LDAP or KAddressBook drivers will all >>> be able to wake up when a new contact is created. The contact can be >>> created asynchronously by another user on another machine on some LDAP >>> server far away on a network that is broken half of the time, for >>> example. So even the underlying Evolution / LDAP / KAddressBook libraries >>> might not know. >> Well, for those what I propose still works : >> - they get a list of contacts (and emit the "contact-added" signal for >> each) ; >> - when they are refreshed, they remove all their contacts, and get the >> new list of contacts. > > What makes you think that they get "refreshed" at some point? The user triggers the "refresh" action :-) >> And what I propose works also for XMPP rosters, which are dynamically >> updated. > > Promise, I will look someday what a "XMPP roster" is ;-). Perhaps you know what a "jabber roster" is? http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html >>> Furthermore, keeping a list all contacts in memory can have a high cost >>> in memory usage. >> Indeed, some books shouldn't treat "get the list of contacts" >> litterally. That is why they shouldn't be too stupid :-) > > Then you must some kind of evolved caching mechanism in your driver. That's > sounds overcomplicated and hard to code to me. If you simply loop through the > contacts, you can just get the information you need and display it. I don't think a trivial proxying counts as an "evolved caching mechanism" :-) >>> Is that such a problem if the driver loops over an older version of the >>> list? >> To do what ? It is not a problem if the list of users on ekiga.net isn't >> updated live. But it certainly is if your XMPP roster isn't ! > > If you convinced me of one thing, it's that I need to look at the definition > of these SNMP toasters ;-). Who's toast ? ;-) >>> class EkigaContact >>> { >>> public: >>> enum property { name, telephone, street, ... }; >>> >>> virtual bool hasProperty(property p) const = 0; >>> gchar *value(property p) const = 0; >>> }; >> Eh... this looks like GObject properties! > > Indeed! Excepted that you are just using the possibilities of the programming > language, not of some library. Can you add properties to the enum when inheriting ? > At this point, I must do some clarification: > > I am a newcomer to Ekiga and perfectly aware of the fact that I might ignore a > lot of things about the past and the possible future of this software. I am a > complete ignorant of GNOME and its libraries. I do not know anything about > the multithreading problems that Julien has to deal with. I am not here to > slow down Julien, nor to get my views adopted. I will be more than happy to > adapt my code to *any* API that Julien will bring up. And to shut my big > mouth up if anyone ask me to ;-). Yes, yes, no problem. I'm happy to have feedback :-) >> glib/gobject isn't gnome. It isn't even graphical. > > Okay, to me who comes from the KDE world, it's the same thing, it starts with > "g" ;-). glib, gobject & gtk+ already make ekiga run on win32. >>> GBUS is indeed a nice invention ;-). >> DBUS, not GBUS. > > Yes, sorry for the many typos... :-/ Eh... that one was pretty bad for someone who has something against g-letter words ;-) Snark From ebischoff@nerim.net Thu Jun 8 04:49:09 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DA33D3B013D for ; Thu, 8 Jun 2006 04:49:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20394-06 for ; Thu, 8 Jun 2006 04:49:08 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id 682F73B05A7 for ; Thu, 8 Jun 2006 04:49:07 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 6666B41095 for ; Thu, 8 Jun 2006 10:49:06 +0200 (CEST) From: =?iso-8859-15?q?=C9ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 10:49:15 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <20060608050828.37d3ac08@localhost.localdomain> In-Reply-To: <20060608050828.37d3ac08@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606081049.16046.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.577 tagged_above=-999 required=2 tests=[AWL=0.022, BAYES_00=-2.599] X-Spam-Score: -2.577 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 08:49:10 -0000 Le Jeudi 8 Juin 2006 05:08, Jan Schampera a =E9crit=A0: > > Indeed! Excepted that you are just using the possibilities of the > > programming language, not of some library. > > Please note, regardless all other arguments, that an own C++-object > system will be totally independant of the used framework. In case we > leave GTK and GLib some day, the OOP approach won't need any changes. > > The GObject approach would need either an equivalent in the new > framework, or a rewrite to (finally) OOP. Yes. That was precisely my point. > Beside that, I tend to say "a matter of taste". Yes. Sometimes programming has to do with aesthetics. Compare: =3D=3D=3D GObject way =3D=3D=3D struct _GmBook { GObject parent; }; struct _GmBookClass { GObjectClass parent; const gchar *(*get_name)(GmBook *self); }; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D with: =3D=3D=3D C++ way =3D=3D=3D class GmBook { public: virtual get_name() const; } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D My tastes tell me that second code, besides from being much shorter, has mo= re=20 "beauty" than the first one. But as you say, tastes are a very personal=20 thing. =2D-=20 =C9ric From jpuydt@free.fr Thu Jun 8 05:09:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C38A43B04E8 for ; Thu, 8 Jun 2006 05:09:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21821-03 for ; Thu, 8 Jun 2006 05:09:15 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 32ECF3B0505 for ; Thu, 8 Jun 2006 05:09:15 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp5-g19.free.fr (Postfix) with ESMTP id BD9EA275B9 for ; Thu, 8 Jun 2006 11:09:13 +0200 (CEST) Message-ID: <4487E971.8070602@free.fr> Date: Thu, 08 Jun 2006 11:10:09 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <20060608050828.37d3ac08@localhost.localdomain> <200606081049.16046.ebischoff@nerim.net> In-Reply-To: <200606081049.16046.ebischoff@nerim.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 09:09:16 -0000 Éric Bischoff a écrit : > Le Jeudi 8 Juin 2006 05:08, Jan Schampera a écrit : >>> Indeed! Excepted that you are just using the possibilities of the >>> programming language, not of some library. >> Please note, regardless all other arguments, that an own C++-object >> system will be totally independant of the used framework. In case we >> leave GTK and GLib some day, the OOP approach won't need any changes. >> >> The GObject approach would need either an equivalent in the new >> framework, or a rewrite to (finally) OOP. > > Yes. That was precisely my point. > >> Beside that, I tend to say "a matter of taste". > > Yes. Sometimes programming has to do with aesthetics. Compare: > > === GObject way === > struct _GmBook { > GObject parent; > }; > > struct _GmBookClass { > GObjectClass parent; > > const gchar *(*get_name)(GmBook *self); > }; > ================== > > with: > > === C++ way === > class GmBook { > public: > virtual get_name() const; > } > ================== > > My tastes tell me that second code, besides from being much shorter, has more > "beauty" than the first one. But as you say, tastes are a very personal > thing. My experience is that when it comes to export the object on DBUS, you're better off with a gobject than with a C++ object. One has some introspection, the other doesn't. I prefer working a little harder upfront, then have an easy life, than writing easy code then feel miserable :-) Snark From ebischoff@nerim.net Thu Jun 8 05:22:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C67273B0598 for ; Thu, 8 Jun 2006 05:22:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22528-04 for ; Thu, 8 Jun 2006 05:22:07 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id D66F33B0B13 for ; Thu, 8 Jun 2006 05:22:06 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 4966F40FBF for ; Thu, 8 Jun 2006 11:22:05 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 11:22:09 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <4487E272.80605@free.fr> In-Reply-To: <4487E272.80605@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606081122.11835.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.579 tagged_above=-999 required=2 tests=[AWL=0.020, BAYES_00=-2.599] X-Spam-Score: -2.579 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 09:22:11 -0000 Le Jeudi 8 Juin 2006 10:40, Julien PUYDT a =C3=A9crit=C2=A0: > > What makes you think that they get "refreshed" at some point? > > The user triggers the "refresh" action :-) Then you loop again through the address book contacts ;-). No need to keep = a=20 copy of the contacts for that. > > Promise, I will look someday what a "XMPP roster" is ;-). > > Perhaps you know what a "jabber roster" is? > http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html No, and this article does not contain the word "roster" :-(. > > Then you must some kind of evolved caching mechanism in your driver. > > That's sounds overcomplicated and hard to code to me. If you simply loop > > through the contacts, you can just get the information you need and > > display it. > > I don't think a trivial proxying counts as an "evolved caching > mechanism" :-) I told you in private that I had a very lazy concept of programming ;-). > Who's toast ? ;-) ;-). > Can you add properties to the enum when inheriting ? Yes: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D class Repas { public: enum plat { nouilles, riz, patates, pain }; virtual void mange(plat p) =3D 0; }; class BonRepas : public Repas { public: enum bonPlat { caviar =3D pain + 1, langouste, foiegras, saumon }; virtual void mange(plat p); }; void BonRepas::mange(plat p) { if ((bonPlat) p =3D=3D langouste) printf("Miam!\n"); } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D With anonymous enums you should even be able to get rid of the casts. But=20 named enums make the code clearer. > Yes, yes, no problem. I'm happy to have feedback :-) Thanks for your openess, Julien :-). > glib, gobject & gtk+ already make ekiga run on win32. I know. But I think it is always good to remove references to libraries if = you=20 do not really need them. > Eh... that one was pretty bad for someone who has something against > g-letter words ;-) I have nothing against, I am just ignorant ;-). =2D-=20 =C3=89ric From conrad_videokonferenz@gmx.de Thu Jun 8 06:04:43 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7A1F63B0CF2 for ; Thu, 8 Jun 2006 06:04:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24863-06 for ; Thu, 8 Jun 2006 06:04:41 -0400 (EDT) Received: from vz17136.evanzo-server.de (vz17136.evanzo-server.de [62.140.17.136]) by menubar.gnome.org (Postfix) with ESMTP id E081B3B05CC for ; Thu, 8 Jun 2006 06:04:40 -0400 (EDT) Received: from c133075.adsl.hansenet.de (c133075.adsl.hansenet.de [213.39.133.75]) (authenticated bits=0) by vz17136.evanzo-server.de (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id k58A4cTf030082 for ; Thu, 8 Jun 2006 12:04:39 +0200 From: Conrad Beckert To: gnomemeeting-devel-list@gnome.org Date: Thu, 8 Jun 2006 10:02:37 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606081002.37875.conrad_videokonferenz@gmx.de> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.106 tagged_above=-999 required=2 tests=[AWL=-1.138, BAYES_05=-1.11, SPF_FAIL=1.142] X-Spam-Score: -1.106 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 10:04:45 -0000 Hi, has anybody an idea where the Debian packages for Ekiga 2.0.2 (or the corresponding CVS versions) are? The last version I can install using apt-get a couple of days old (May 25 - or somethin) - at least this is a version with the nonfunctional German locale. (defaults to English) What's up? Conrad From jpuydt@free.fr Thu Jun 8 06:59:27 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 483C83B0ED8 for ; Thu, 8 Jun 2006 06:59:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27917-10 for ; Thu, 8 Jun 2006 06:59:15 -0400 (EDT) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by menubar.gnome.org (Postfix) with ESMTP id 1C5223B0630 for ; Thu, 8 Jun 2006 06:59:12 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp4-g19.free.fr (Postfix) with ESMTP id A681254974 for ; Thu, 8 Jun 2006 12:59:10 +0200 (CEST) Message-ID: <44880335.3060401@free.fr> Date: Thu, 08 Jun 2006 13:00:05 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <4487E272.80605@free.fr> <200606081122.11835.ebischoff@nerim.net> In-Reply-To: <200606081122.11835.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 10:59:27 -0000 Éric Bischoff a écrit : > Le Jeudi 8 Juin 2006 10:40, Julien PUYDT a écrit : >>> What makes you think that they get "refreshed" at some point? >> The user triggers the "refresh" action :-) > > Then you loop again through the address book contacts ;-). No need to keep a > copy of the contacts for that. You will need to keep a copy to show them to the user anyway. And notice that a same contact could be shown at several places through the user interface! >>> Promise, I will look someday what a "XMPP roster" is ;-). >> Perhaps you know what a "jabber roster" is? >> http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html > > No, and this article does not contain the word "roster" :-(. The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish them from 'live' contacts. The situation is that you may have jc@jabber.lat in your roster, with the information that the name is "Julius Caesar", and belongs to the groups "Politicians" and "Jokers". But when he connects from his pda, he will show up as jc@jabber.lat/pda, and will neither be able to do VoIP, nor receive XHTML messages. When he is home, he connects from his computer as jc@jabber.lat/home, and will be able to do both. Now he goes to work, from where he shows up as jc@jabber.lat/work, which can do XHTML messaging, but not VoIP. >> Yes, yes, no problem. I'm happy to have feedback :-) > > Thanks for your openess, Julien :-). No problem. More brains means better solutions :-) >> glib, gobject & gtk+ already make ekiga run on win32. > > I know. But I think it is always good to remove references to libraries if you > do not really need them. Well, glib is nice. The main problem KDE problem have with it is that it begins with a 'g' and is already used in GNOME. :-) Snark From ebischoff@nerim.net Thu Jun 8 09:37:50 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CE2BD3B03A6 for ; Thu, 8 Jun 2006 09:37:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08027-03 for ; Thu, 8 Jun 2006 09:37:49 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id 549EB3B0622 for ; Thu, 8 Jun 2006 09:37:48 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 1D58441027 for ; Thu, 8 Jun 2006 15:37:45 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 15:37:53 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606081122.11835.ebischoff@nerim.net> <44880335.3060401@free.fr> In-Reply-To: <44880335.3060401@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606081537.55137.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.504 tagged_above=-999 required=2 tests=[AWL=-0.059, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077] X-Spam-Score: -2.504 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 13:37:51 -0000 Le Jeudi 8 Juin 2006 13:00, Julien PUYDT a =C3=A9crit=C2=A0: > > Then you loop again through the address book contacts ;-). No need to > > keep a copy of the contacts for that. > > You will need to keep a copy to show them to the user anyway. Keeping contacts in memory is not the same at all as keeping an image of wh= at=20 Ekiga has to display of them. The GUI needs basically a list of strings to= =20 display, not the potentially complex data structure of an address book=20 contact. Having one of these complex structures in memory at a time is enough IMHO. Should it be only for performance reasons: when the user scrolls down the l= ist=20 by one contact, it is much quicker to retreive data from a prepared list of= =20 strings than from the contact itself. > And notice=20 > that a same contact could be shown at several places through the user > interface! Yes, and perharps displayed in different ways. > > No, and this article does not contain the word "roster" :-(. > > The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish > them from 'live' contacts. > > The situation is that you may have jc@jabber.lat in your roster, with > the information that the name is "Julius Caesar", and belongs to the > groups "Politicians" and "Jokers". But when he connects from his pda, he > will show up as jc@jabber.lat/pda, and will neither be able to do VoIP, > nor receive XHTML messages. When he is home, he connects from his > computer as jc@jabber.lat/home, and will be able to do both. Now he goes > to work, from where he shows up as jc@jabber.lat/work, which can do > XHTML messaging, but not VoIP. Aha. > > Thanks for your openess, Julien :-). > > No problem. More brains means better solutions :-) Yes, indeed. I hope my advice brings something constructive. As I told you = in=20 private, you keep it or throw it, it's your decision. > > I know. But I think it is always good to remove references to libraries > > if you do not really need them. > > Well, glib is nice. The main problem KDE problem have with it is that it > begins with a 'g' and is already used in GNOME. :-) Do not believe that. We are not religious people. For example, we are very= =20 happy sharing libxml with GNOME. Even though there is already a XML API in= =20 Qt! Just because libxml rocks... (oh yeah, there's no "g" in libxml... ;-) ) We already share libxml, desktop files, DocBook documentation, DBUS=20 communication, po translation memories, and many, many other things. Cool=20 apps like Ekiga can run in a KDE environment. Cool apps like ... errr...=20 KEuroCalc ;-) can run in a GNOME environment. And in fact I know that many= =20 people do that. In fact, the more we will be able to share with you, the happier we will be= =2E I=20 can ensure you that this has always been what we said, even during private= =20 discussions at KDE meetings. I do not know why we do not share glib. I have my ideas about that, but it'= s=20 just personal assumptions ;-). =2D-=20 =C3=89ric From jpuydt@free.fr Thu Jun 8 15:02:29 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6459F3B0F68 for ; Thu, 8 Jun 2006 15:02:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30195-09 for ; Thu, 8 Jun 2006 15:02:28 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id 1D6653B035A for ; Thu, 8 Jun 2006 15:02:28 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp6-g19.free.fr (Postfix) with ESMTP id A118022783 for ; Thu, 8 Jun 2006 21:02:23 +0200 (CEST) Message-ID: <4488747B.6080906@free.fr> Date: Thu, 08 Jun 2006 21:03:23 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606081122.11835.ebischoff@nerim.net> <44880335.3060401@free.fr> <200606081537.55137.ebischoff@nerim.net> In-Reply-To: <200606081537.55137.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.512 tagged_above=-999 required=2 tests=[AWL=-0.067, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077] X-Spam-Score: -2.512 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:02:29 -0000 Éric Bischoff a écrit : >> You will need to keep a copy to show them to the user anyway. > > Keeping contacts in memory is not the same at all as keeping an image of what > Ekiga has to display of them. The GUI needs basically a list of strings to > display, not the potentially complex data structure of an address book > contact. > > Having one of these complex structures in memory at a time is enough IMHO. Not at all. And it won't allow you to update informations like presence easily. > Should it be only for performance reasons: when the user scrolls down the list > by one contact, it is much quicker to retreive data from a prepared list of > strings than from the contact itself. The contact isn't that much more than strings... >> And notice >> that a same contact could be shown at several places through the user >> interface! > > Yes, and perharps displayed in different ways. Yes, that too. >>> No, and this article does not contain the word "roster" :-(. >> The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish >> them from 'live' contacts. >> >> The situation is that you may have jc@jabber.lat in your roster, with >> the information that the name is "Julius Caesar", and belongs to the >> groups "Politicians" and "Jokers". But when he connects from his pda, he >> will show up as jc@jabber.lat/pda, and will neither be able to do VoIP, >> nor receive XHTML messages. When he is home, he connects from his >> computer as jc@jabber.lat/home, and will be able to do both. Now he goes >> to work, from where he shows up as jc@jabber.lat/work, which can do >> XHTML messaging, but not VoIP. > > Aha. Yes, it's that bad :-/ >>> Thanks for your openess, Julien :-). >> No problem. More brains means better solutions :-) > > Yes, indeed. I hope my advice brings something constructive. As I told you in > private, you keep it or throw it, it's your decision. Last time you wrote that I ended throwing both your ideas and mines ;-) >>> I know. But I think it is always good to remove references to libraries >>> if you do not really need them. >> Well, glib is nice. The main problem KDE problem have with it is that it >> begins with a 'g' and is already used in GNOME. :-) > > Do not believe that. We are not religious people. For example, we are very > happy sharing libxml with GNOME. Even though there is already a XML API in > Qt! Just because libxml rocks... > > (oh yeah, there's no "g" in libxml... ;-) ) > > We already share libxml, desktop files, DocBook documentation, DBUS > communication, po translation memories, and many, many other things. Cool > apps like Ekiga can run in a KDE environment. Cool apps like ... errr... > KEuroCalc ;-) can run in a GNOME environment. And in fact I know that many > people do that. What is KEuroCalc ? > In fact, the more we will be able to share with you, the happier we will be. I > can ensure you that this has always been what we said, even during private > discussions at KDE meetings. This is why it's so important to have a good DBUS component. And this is made easier by using glib-object :-) > I do not know why we do not share glib. I have my ideas about that, but it's > just personal assumptions ;-). I can make a few guesses : 1) it does things that QT does ; 2) it does things that C++ STL does. Snark From ebischoff@nerim.net Thu Jun 8 15:38:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D9F313B054E for ; Thu, 8 Jun 2006 15:38:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32745-08 for ; Thu, 8 Jun 2006 15:38:37 -0400 (EDT) Received: from mallaury.nerim.net (smtp-104-thursday.noc.nerim.net [62.4.17.104]) by menubar.gnome.org (Postfix) with ESMTP id 3976E3B000E for ; Thu, 8 Jun 2006 15:38:35 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by mallaury.nerim.net (Postfix) with ESMTP id 1ED2F4F3A4 for ; Thu, 8 Jun 2006 21:38:22 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 21:38:46 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606081537.55137.ebischoff@nerim.net> <4488747B.6080906@free.fr> In-Reply-To: <4488747B.6080906@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606082138.46648.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.576 tagged_above=-999 required=2 tests=[AWL=0.023, BAYES_00=-2.599] X-Spam-Score: -2.576 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:38:40 -0000 Le Jeudi 8 Juin 2006 21:03, Julien PUYDT a =C3=A9crit=C2=A0: > > We already share libxml, desktop files, DocBook documentation, DBUS > > communication, po translation memories, and many, many other things. Co= ol > > apps like Ekiga can run in a KDE environment. Cool apps like ... errr... > > KEuroCalc ;-) can run in a GNOME environment. And in fact I know that > > many people do that. > > What is KEuroCalc ? Mentioning it was merely a joke: it's a small KDE app that I wrote. http://opensource.bureau-cornavin.com/keurocalc/ ;-) > > I do not know why we do not share glib. I have my ideas about that, but > > it's just personal assumptions ;-). > > I can make a few guesses : > 1) it does things that QT does ; > 2) it does things that C++ STL does. Exactly the same guesses as me ;-). It even does things that C++ _alone_ do= es. Best, =2D-=20 =C3=89ric From ph.l@libertysurf.fr Thu Jun 8 15:47:49 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9705F3B1039 for ; Thu, 8 Jun 2006 15:47:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00870-02 for ; Thu, 8 Jun 2006 15:47:38 -0400 (EDT) Received: from smtp4.mail.easynet.fr (smarthost169.mail.easynet.fr [212.180.1.169]) by menubar.gnome.org (Postfix) with ESMTP id 527163B1020 for ; Thu, 8 Jun 2006 15:47:35 -0400 (EDT) Received: from asi-236.asi256ip.easynet.fr ([212.180.39.236] helo=[145.111.24.1]) by smtp4.mail.easynet.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FoQUy-0004IP-Fg for gnomemeeting-devel-list@gnome.org; Thu, 08 Jun 2006 21:48:56 +0200 Message-ID: <44887ECE.9040902@libertysurf.fr> Date: Thu, 08 Jun 2006 21:47:26 +0200 From: Philippe Lefevre User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: gnomemeeting-devel-list@gnome.org References: <20060608160031.473BF3B0FB3@menubar.gnome.org> In-Reply-To: <20060608160031.473BF3B0FB3@menubar.gnome.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.436 tagged_above=-999 required=2 tests=[AWL=-0.853, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, TW_BX=0.077, TW_IB=0.077, TW_RW=0.077, TW_WX=0.077] X-Spam-Score: -1.436 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ekiga under windows X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ph.l@libertysurf.fr, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:47:49 -0000 Hello, Today I tried to install ekiga on my PC under XP and I never get anything to work :'( You'll find bellow what I did. I can do some other tests if it may in any help. PhiL My PC is running Windows XP SP1 1G memory. I installed GTK 2.0 (version 2.8.9.0) installed under C:\Program Files\Fichiers communs\GTK\2.0 and Ekiga (downloaded from CVS June 8, 2006) installed under C:\Program Files\Ekiga CYGWIN and MSYS are installed too with XP : nothing happen, no log (empty file even with -d 4 option) with MSYS : same issue $ echo $PATH .:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32: /c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/oracle9/bin:/c/oracle8/bin: /i/progicil/orawin2:/i/progicil/orawin2/bin: /c/Program Files/Microsoft SQL Server/80/Tools/BINN: /c/Program Files/Fichiers communs/GTK/2.0/bin:/c/php5: /c/php5/ext:/c/Program Files/MySQL/MySQL Server 5.0/bin: /c/bin:/c/cygdrive/c/cygwin/bin:/c/cygdrive/c/cygwin/sbin:/c/oracle9/bin: /c/oracle8/bin:/i/progicil/orawin2:/i/progicil/orawin2/bin: /c/Program Files/Ekiga:/c/caml/bin PHL@BORG /c/program files/ekiga $ ./ekiga.exe 1>log 2>&1 Log is empty $ ls -rwxr-xr-x 1 PHL Administ 7934464 May 16 05:26 ekiga.exe -rw-r--r-- 1 PHL Administ 1231950 May 16 05:26 ekiga.schemas -rwxr-xr-x 1 PHL Administ 44032 May 16 05:26 liblber.dll -rwxr-xr-x 1 PHL Administ 188416 May 16 05:26 libldap_r.dll -rwxr-xr-x 1 PHL Administ 1276928 May 16 05:26 libxml2-2.dll drwxr-xr-x 70 PHL Administ 0 Jun 8 09:52 locale -rw-r--r-- 1 PHL Administ 0 Jun 8 13:30 log Using GDB in a cygdrive environment : $ gdb ekiga.exe GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) (gdb) run Starting program: /cygdrive/c/Program Files/Ekiga/ekiga.exe Program received signal SIGSEGV, Segmentation fault. Program received signal SIGSEGV, Segmentation fault. Program exited with code 0200. You can't do that without a process to debug. (gdb) bt No stack. (gdb) From jpuydt@free.fr Thu Jun 8 15:50:47 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 143943B027F for ; Thu, 8 Jun 2006 15:50:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01017-01 for ; Thu, 8 Jun 2006 15:50:46 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id E67403B021A for ; Thu, 8 Jun 2006 15:50:45 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp3-g19.free.fr (Postfix) with ESMTP id C567B4901D; Thu, 8 Jun 2006 21:50:43 +0200 (CEST) Message-ID: <44887FCD.7040300@free.fr> Date: Thu, 08 Jun 2006 21:51:41 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: ph.l@libertysurf.fr, GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Ekiga under windows References: <20060608160031.473BF3B0FB3@menubar.gnome.org> <44887ECE.9040902@libertysurf.fr> In-Reply-To: <44887ECE.9040902@libertysurf.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.434 tagged_above=-999 required=2 tests=[AWL=-0.143, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077, TW_RW=0.077, TW_WX=0.077] X-Spam-Score: -2.434 X-Spam-Level: Cc: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:50:47 -0000 Philippe Lefevre a écrit : > Today I tried to install ekiga on my PC under XP and I never get > anything to work :'( Yes, we don't have a nice installer yet. > I installed GTK 2.0 (version 2.8.9.0) installed under > C:\Program Files\Fichiers communs\GTK\2.0 I'm wondering if that is recent enough. > CYGWIN and MSYS are installed too Unnecessary. > $ ls > -rwxr-xr-x 1 PHL Administ 7934464 May 16 05:26 ekiga.exe > -rw-r--r-- 1 PHL Administ 1231950 May 16 05:26 ekiga.schemas > -rwxr-xr-x 1 PHL Administ 44032 May 16 05:26 liblber.dll > -rwxr-xr-x 1 PHL Administ 188416 May 16 05:26 libldap_r.dll > -rwxr-xr-x 1 PHL Administ 1276928 May 16 05:26 libxml2-2.dll > drwxr-xr-x 70 PHL Administ 0 Jun 8 09:52 locale > -rw-r--r-- 1 PHL Administ 0 Jun 8 13:30 log No libSDL.dll or some such ? :-/ Snark From ph.l@libertysurf.fr Thu Jun 8 16:43:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 40F853B00EA for ; Thu, 8 Jun 2006 16:43:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04211-07 for ; Thu, 8 Jun 2006 16:43:38 -0400 (EDT) Received: from smtp3.mail.easynet.fr (smarthost168.mail.easynet.fr [212.180.1.168]) by menubar.gnome.org (Postfix) with ESMTP id 52BD23B000E for ; Thu, 8 Jun 2006 16:43:37 -0400 (EDT) Received: from asi-236.asi256ip.easynet.fr ([212.180.39.236] helo=[145.111.24.1]) by smtp3.mail.easynet.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FoRMF-0007kr-6F; Thu, 08 Jun 2006 22:43:59 +0200 Message-ID: <44888BF6.8020906@libertysurf.fr> Date: Thu, 08 Jun 2006 22:43:34 +0200 From: Philippe Lefevre User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: Julien PUYDT , gnomemeeting-devel-list@gnome.org References: <20060608160031.473BF3B0FB3@menubar.gnome.org> <44887ECE.9040902@libertysurf.fr> <44887FCD.7040300@free.fr> In-Reply-To: <44887FCD.7040300@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.283 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077, TW_RW=0.077, TW_WX=0.077] X-Spam-Score: -2.283 X-Spam-Level: Cc: Subject: [GnomeMeeting-devel-list] Re : Ekiga under windows X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ph.l@libertysurf.fr, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 20:43:39 -0000 Julien PUYDT a écrit : > Philippe Lefevre a écrit : > >> Today I tried to install ekiga on my PC under XP and I never get >> anything to work :'( > > > Yes, we don't have a nice installer yet. No pb, unzip works well for now. > >> I installed GTK 2.0 (version 2.8.9.0) installed under >> C:\Program Files\Fichiers communs\GTK\2.0 > > > I'm wondering if that is recent enough. > 2.8.9.0 is the latest stable version but there is a 2.8.15 too dated from March (still unstable ?) >> CYGWIN and MSYS are installed too > > > Unnecessary. > Of course. It's just to use dbg. (I installed it for other things anyway) >> $ ls >> -rwxr-xr-x 1 PHL Administ 7934464 May 16 05:26 ekiga.exe >> -rw-r--r-- 1 PHL Administ 1231950 May 16 05:26 ekiga.schemas >> -rwxr-xr-x 1 PHL Administ 44032 May 16 05:26 liblber.dll >> -rwxr-xr-x 1 PHL Administ 188416 May 16 05:26 libldap_r.dll >> -rwxr-xr-x 1 PHL Administ 1276928 May 16 05:26 libxml2-2.dll >> drwxr-xr-x 70 PHL Administ 0 Jun 8 09:52 locale >> -rw-r--r-- 1 PHL Administ 0 Jun 8 13:30 log > > > No libSDL.dll or some such ? :-/ > Sorry I don't think so. I will check tomorrow (it is on my PC at work) But, I just check the zip file... there is no libSDL (or name close to that) into it. > Snark > Thanks Julien. From mcquaidster@gmail.com Thu Jun 8 17:09:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DF4253B0622 for ; Thu, 8 Jun 2006 17:09:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05835-02 for ; Thu, 8 Jun 2006 17:09:06 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id 76D583B0F9D for ; Thu, 8 Jun 2006 17:09:06 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id z74so693545pyg for ; Thu, 08 Jun 2006 14:09:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=HVNAtak5n7Z91wpmXr/Qu5ON4YhH7Q4dCf+4y5GUbTwwY23VOAXrmjBMj7263bIU8fqFePgmvS6HIFqN59D2Jy6YmXM2xD1V+aMpky/Ed9jdEhbQxbJYZUEi6YN6vk99BkQspxK0SEsZWjsxDvHu3Rk9O5hKBW5HcpVNrhkyGCo= Received: by 10.35.63.2 with SMTP id q2mr2928428pyk; Thu, 08 Jun 2006 14:09:05 -0700 (PDT) Received: by 10.35.31.2 with HTTP; Thu, 8 Jun 2006 14:09:05 -0700 (PDT) Message-ID: <58a398810606081409o3026d11cnd9f5f3a16b0243e@mail.gmail.com> Date: Thu, 8 Jun 2006 17:09:05 -0400 From: "mcquaid mcquaid" To: "GnomeMeeting development mailing list" In-Reply-To: <58a398810606061625x7684427q73db38225fa398dc@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10127_1193274.1149800945207" References: <58a398810606061625x7684427q73db38225fa398dc@mail.gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.359 tagged_above=-999 required=2 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.359 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Re: no audio on incoming calls. X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 21:09:10 -0000 ------=_Part_10127_1193274.1149800945207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Can I get any assistance on this or is there something else I should be providing? I can get other voip apps like linphone working but I can't get ekiga to transmit audio either way on incoming calls. Not sure if it's any help but asterisk seems to behave in the same manner. With asterisk I again could make outgoing call fine, but for incoming it would route calls to my local sipphone, but no audio either way. On 6/6/06, mcquaid mcquaid wrote: > > I have tried ekiga from time to time, and now using the latest cvs, I > still have the same problem. > > On outgoing calls, audio transmits both ways without issue. > > When receiving a call, no audio is transmitted either way. > > I realize it'll probably be considered a firewall issue, but linphone has > always worked for me and I have never setup stun or a nat traversal method > in linphone. I'd prefer to use ekiga instead of linphone. > > Here is the output of an incoming call that lasts until ekiga reports > 'remote user cleared the call'. > > I tried ekiga lastest cvs as I read about 2.02 hoping this might have been > resolved. > > > > ------=_Part_10127_1193274.1149800945207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Can I get any assistance on this or is there something else I should be providing?  I can get other voip apps like linphone working but I can't get ekiga to transmit audio either way on incoming calls.  Not sure if it's any help but asterisk seems to behave in the same manner.  With asterisk I again could make outgoing call fine, but for incoming it would route calls to my local sipphone, but no audio either way.

On 6/6/06, mcquaid mcquaid <mcquaidster@gmail.com> wrote:
I have tried ekiga from time to time, and now using the latest cvs, I still have the same problem.

On outgoing calls, audio transmits both ways without issue.

When receiving a call, no audio is transmitted either way.

I realize it'll probably be considered a firewall issue, but linphone has always worked for me and I have never setup stun or a nat traversal method in linphone.  I'd prefer to use ekiga instead of linphone.

Here is the output of an incoming call that lasts until ekiga reports 'remote user cleared the call'.

I tried ekiga lastest cvs as I read about 2.02 hoping this might have been resolved.




------=_Part_10127_1193274.1149800945207-- From dsandras@seconix.com Fri Jun 9 03:56:41 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5D27B3B006E for ; Fri, 9 Jun 2006 03:56:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05479-07 for ; Fri, 9 Jun 2006 03:56:39 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 62A113B017E for ; Fri, 9 Jun 2006 03:56:39 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 2E8E349758 for ; Fri, 9 Jun 2006 09:38:49 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16204-09 for ; Fri, 9 Jun 2006 09:38:42 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 6559949755 for ; Fri, 9 Jun 2006 09:38:42 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Re: no audio on incoming calls. From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <58a398810606081409o3026d11cnd9f5f3a16b0243e@mail.gmail.com> References: <58a398810606061625x7684427q73db38225fa398dc@mail.gmail.com> <58a398810606081409o3026d11cnd9f5f3a16b0243e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 09 Jun 2006 09:56:30 +0200 Message-Id: <1149839790.3351.0.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 07:56:41 -0000 You should provide a debug 4 output. Le jeudi 08 juin 2006 à 17:09 -0400, mcquaid mcquaid a écrit : > Can I get any assistance on this or is there something else I should > be providing? I can get other voip apps like linphone working but I > can't get ekiga to transmit audio either way on incoming calls. Not > sure if it's any help but asterisk seems to behave in the same manner. > With asterisk I again could make outgoing call fine, but for incoming > it would route calls to my local sipphone, but no audio either way. > > On 6/6/06, mcquaid mcquaid wrote: > I have tried ekiga from time to time, and now using the latest > cvs, I still have the same problem. > > On outgoing calls, audio transmits both ways without issue. > > When receiving a call, no audio is transmitted either way. > > I realize it'll probably be considered a firewall issue, but > linphone has always worked for me and I have never setup stun > or a nat traversal method in linphone. I'd prefer to use > ekiga instead of linphone. > > Here is the output of an incoming call that lasts until ekiga > reports 'remote user cleared the call'. > > I tried ekiga lastest cvs as I read about 2.02 hoping this > might have been resolved. > > > > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From ph.l@libertysurf.fr Sat Jun 10 12:49:37 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 174BA3B01B8 for ; Sat, 10 Jun 2006 12:49:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15518-01 for ; Sat, 10 Jun 2006 12:49:36 -0400 (EDT) Received: from smtp4.mail.easynet.fr (smarthost169.mail.easynet.fr [212.180.1.169]) by menubar.gnome.org (Postfix) with ESMTP id C9C343B032B for ; Sat, 10 Jun 2006 12:49:35 -0400 (EDT) Received: from asi-236.asi256ip.easynet.fr ([212.180.39.236] helo=[145.111.24.1]) by smtp4.mail.easynet.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Fp6fr-0001ZY-Dc for gnomemeeting-devel-list@gnome.org; Sat, 10 Jun 2006 18:50:59 +0200 Message-ID: <448AF812.4010106@libertysurf.fr> Date: Sat, 10 Jun 2006 18:49:22 +0200 From: Philippe Lefevre User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: GnomeMeeting devel list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.839 tagged_above=-999 required=2 tests=[AWL=-1.437, BAYES_05=-1.11, DNS_FROM_RFC_POST=1.708] X-Spam-Score: -0.839 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ekiga 2.0.2 Ubuntu packages X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 16:49:37 -0000 Hi all, For a few days I'm looking for Ekiga 2.0.2 for ubuntu packages @ http://www.ekiga.org but there are no link available yet. Is this normal ? Thanks. PhiL From mathiaschulze@gmail.com Sun Jun 11 10:47:28 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7E1CC3B00B0 for ; Sun, 11 Jun 2006 10:47:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14779-09 for ; Sun, 11 Jun 2006 10:47:27 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by menubar.gnome.org (Postfix) with ESMTP id 6898E3B0084 for ; Sun, 11 Jun 2006 10:47:27 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id 9so1563867nzo for ; Sun, 11 Jun 2006 07:46:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=RdwAYw0jPdY9iOC0Sf+iOKQJ9I7YfnL/kWXyEPnc+Cr+QIVa1sKM88ZdFWngpOkudGwRUvtt1Aw9vAL7lpvseD6hTwpLtjhbhu306m/DpJDRigRtWN/PSaYRcSohSjgiAaMN7SNdOXCHLIjQ0ZzdPpKX46kbgKn0qo2/Dg4UYbo= Received: by 10.37.2.45 with SMTP id e45mr7180725nzi; Sun, 11 Jun 2006 07:46:45 -0700 (PDT) Received: from vaio ( [71.98.110.104]) by mx.gmail.com with ESMTP id 37sm151203nzf.2006.06.11.07.46.44; Sun, 11 Jun 2006 07:46:45 -0700 (PDT) From: Mathias Schulze To: gnomemeeting-devel-list@gnome.org Content-Type: text/plain Date: Sun, 11 Jun 2006 10:46:43 -0400 Message-Id: <1150037203.24558.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.821 tagged_above=-999 required=2 tests=[AWL=-0.779, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.821 X-Spam-Level: Subject: [GnomeMeeting-devel-list] alsa default device X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 14:47:28 -0000 Hello, I would like to make Ekiga automatically use my USB Headset whenever it is plugged in. It is no problem to switch the default device to the headset by a udev rule. But Ekiga seems to ignore any changes of the default device after start-up. I think if the default device is selected Ekiga should check the current default device immediately before starting the conversation. So if someone calls I can plug in the USB headset and accept the call. An example of a program which seems to do this is the gnome music player "Listen". An even better solution (but maybe too much work?) could be if Ekiga pops up a request whenever a new audio device appears to ask the user if this device should be used. Such request appears e.g. under Ubuntu in the control panel. Thanks for Ekiga, it's really great! Mathias From dsandras@seconix.com Mon Jun 12 04:46:20 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EDE963B00D8 for ; Mon, 12 Jun 2006 04:46:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26328-09 for ; Mon, 12 Jun 2006 04:46:16 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id B27083B009D for ; Mon, 12 Jun 2006 04:46:16 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 8BE0B83C22 for ; Mon, 12 Jun 2006 10:26:53 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29245-09 for ; Mon, 12 Jun 2006 10:26:48 +0200 (CEST) Received: from [192.168.0.161] (157.137-245-81.adsl-dyn.isp.belgacom.be [81.245.137.157]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id BF7E583C1F for ; Mon, 12 Jun 2006 10:26:48 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Ekiga 2.0.2 Ubuntu packages From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <448AF812.4010106@libertysurf.fr> References: <448AF812.4010106@libertysurf.fr> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 12 Jun 2006 10:46:31 +0200 Message-Id: <1150101991.2505.12.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 08:46:20 -0000 Le samedi 10 juin 2006 à 18:49 +0200, Philippe Lefevre a écrit : > Hi all, > For a few days I'm looking for Ekiga 2.0.2 for ubuntu packages @ > http://www.ekiga.org > but there are no link available yet. Is this normal ? They are coming soon... -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Mon Jun 12 08:26:32 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 96E503B0061 for ; Mon, 12 Jun 2006 08:26:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01773-10 for ; Mon, 12 Jun 2006 08:26:29 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 0BDDA3B000D for ; Mon, 12 Jun 2006 08:26:28 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id A4ACC83C24 for ; Mon, 12 Jun 2006 13:43:24 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15346-08 for ; Mon, 12 Jun 2006 13:43:15 +0200 (CEST) Received: from [192.168.0.161] (157.137-245-81.adsl-dyn.isp.belgacom.be [81.245.137.157]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 3FB8E83C22 for ; Mon, 12 Jun 2006 13:43:15 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] alsa default device From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <1150037203.24558.24.camel@localhost.localdomain> References: <1150037203.24558.24.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 12 Jun 2006 14:03:41 +0200 Message-Id: <1150113821.7909.5.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 12:26:32 -0000 Hi, Le dimanche 11 juin 2006 à 10:46 -0400, Mathias Schulze a écrit : > Hello, > > I would like to make Ekiga automatically use my USB Headset whenever it > is plugged in. It is no problem to switch the default device to the > headset by a udev rule. But Ekiga seems to ignore any changes of the > default device after start-up. > It is most probably due to ALSA and libasound if I understand correctly what you mean. If you change from "USB Headset" to "Soundcard" or to "Default", Ekiga will work correctly. However, you probably mean that you want to select "Default" as device in Ekiga and that "Default" will be linked to the USB headset or to the soundcard depending if the headset is plugged in or not. For Ekiga, it is transparent. Ekiga simply open the "Default" device when playing sounds. If the "Default" device is linked in real time to the USB headset while Ekiga is running, and if it still uses the sound card, then it means that libasound already mapped the default device to the soundcard when starting the application and doesn't accept changing it. So I would say that I'm 100% confident it is an ALSA limitation. However, I tried here changing the settings of my default device through .asoundrc when Ekiga is running and it works. > I think if the default device is selected Ekiga should check the current > default device immediately before starting the conversation. So if > someone calls I can plug in the USB headset and accept the call. > An example of a program which seems to do this is the gnome music player > "Listen". It is transparent for Ekiga. Ekiga opens the "Default" device whatever it is through ALSA. > > An even better solution (but maybe too much work?) could be if Ekiga > pops up a request whenever a new audio device appears to ask the user if > this device should be used. Such request appears e.g. under Ubuntu in > the control panel. It is planned in the future through HAL. > > Thanks for Ekiga, it's really great! > Mathias > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Mon Jun 12 17:23:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 441F03B01DB for ; Mon, 12 Jun 2006 17:23:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31653-03 for ; Mon, 12 Jun 2006 17:23:08 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 994B13B0010 for ; Mon, 12 Jun 2006 17:23:08 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 666F683C23 for ; Mon, 12 Jun 2006 23:01:22 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19698-06 for ; Mon, 12 Jun 2006 23:01:18 +0200 (CEST) Received: from [192.168.0.161] (157.137-245-81.adsl-dyn.isp.belgacom.be [81.245.137.157]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id AFAEE83C22 for ; Mon, 12 Jun 2006 23:01:18 +0200 (CEST) From: Damien Sandras To: gnomemeeting-devel-list@gnome.org Content-Type: text/plain Date: Mon, 12 Jun 2006 23:24:02 +0200 Message-Id: <1150147442.11823.2.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Subject: [GnomeMeeting-devel-list] New user interface : first stubs X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 21:23:10 -0000 Hi to all, I committed the first stubs of the new user interface. Please do not criticize too much as it is work in progress and it is in the very early stages of development. Julien is working on big changes too, but that should have no impact on the user interface. In the next few weeks, I will work more on : - the user interface - sip support (integrate Craig's changes) And finally work on a roster. Enjoy, -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From jpuydt@free.fr Tue Jun 13 13:58:03 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 530F33B03CF for ; Tue, 13 Jun 2006 13:58:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01110-02 for ; Tue, 13 Jun 2006 13:58:01 -0400 (EDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by menubar.gnome.org (Postfix) with ESMTP id EC4F23B00DB for ; Tue, 13 Jun 2006 13:58:00 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by postfix1-c.free.fr (Postfix) with ESMTP id 91A4B1CF1DC3 for ; Tue, 13 Jun 2006 17:47:25 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-32-82-254-24-205.adsl.proxad.net [82.254.24.205]) by smtp6-g19.free.fr (Postfix) with ESMTP id CD69E2286C for ; Tue, 13 Jun 2006 18:42:21 +0200 (CEST) Message-ID: <448EC473.7060800@free.fr> Date: Tue, 13 Jun 2006 15:58:11 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <448B2A40.5060600@free.fr> <20060612174347.5181a8f9@localhost.localdomain> <448DABA7.4060103@free.fr> <200606130951.56969.ebischoff@nerim.net> In-Reply-To: <200606130951.56969.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.567 tagged_above=-999 required=2 tests=[AWL=0.032, BAYES_00=-2.599] X-Spam-Score: -2.567 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 17:58:03 -0000 Hi, in private mails (with quite big attachments since I provided some sample stupid code), Éric Bischoff found my code not that explicit concerning what I have in mind. Since I would like to keep things as opened as possible, I drop my text here :-) Let's see if I can manage to give useful ideas. ***** BIG WORDS Model - View - Controller ***** VIEWING (GENERIC) We need to be able to present a book to the user. For that, the view needs to have a list of contacts (no, a single contact definitely isn't enough!). So we need a function call to get a list of contacts. The problem is that this list will change during time (new contacts added, others removed, presence changed, status message changed, and the list goes on). So the view will need to be notified about it. Hence the idea that the book will have "contact-added" and "contact-removed" signals, and the contacts a "updated" signal. In addition to that, there is an interesting special case to handle : you have a contact in a book, and this contact shows up in a search result. When you remove the contact from the book, we want to make it disappear from the list too. Hence a "removed" signal for contacts. Now this is all nice, but what can we do if an addressbook contains millions of entries ? And if a search gives thousands of results ? In such cases, my stance is that the low level code should do something about it, since it is the one giving the problem. How can the high level code cope correctly with the situation anyway ? Only the low level code can say "Eh, I already made two hundred contacts go through the wire for that search, perhaps I should make it easy!". The question to really ask, and to which I have no satisfactory answer is: "How do me make the low level tell the high level it had to cut the list ?". ***** VIEWING (CONTACTS) The contacts should contain enough to be viewed from a generic view in the contacts window, and be shown in a search result. That won't prevent some other parts of the code to make a better use of them. For example, in the contact window we will probably be able to see a contact's title and description, but not its detailed presence, while the main window will contain a much better and more specific view for the live contacts. ***** CONTROLLING (GENERIC) Now, we want to be able to act on our objects ; say rename a book or a contact, subscribe/unsubscribe to its presence, etc. The best thing to do is to be able to get menus for each of them. Notice the plural: we will certainly to have at least menu in the menu bar and a popup menu. The first bad news about such menus is that they won't be generic : they will depend heavily on the specific type of object (no rename for avahi contacts, subscribe/unsubscribe only for XMPP contacts...). So we will certainly need some sort of shared actions that will be basic bricks for building menu (like the shared-actions.[ch] of my first round of proposals), that each implementation will mix as it sees fit. The second bad news about them is that they won't be static either. They will have to update themselves following the object they are attached to. Say your nice XMPP contact is connected with a client which has VoIP support, but now connects with a no-VoIP client, and disconnects the first : we want the "Call" menuitem to disappear to reflect this. So my proposition (no code yet) is that those menus will be obtained by subclassing of GtkMenu, register to get signals from the contact/book they are attached to, and use that to keep themselves up to date. ***** CONTROLLING (CONTACTS) Let's try to be more specific: in avahi-contact-menu.h, we would have: GtkWidget *avahi_contact_menu_new (AvahiContact *contact); and in gm-contact.h: GtkWidget *gm_contact_get_menu_new (GmContact *contact); This later function would be different in each implementation, which allows for example the avahi_contact_get_menu_new implementation to call avahi_contact_menu_new. The high level code called a generic function, but got access to a very specific implementation, which knows the full api of the specific contact, and hence will provide the best service. ***** CONTROLLING (BOOKS) Perhaps the menu shouldn't be attached to the book himself, but to its view. That would allow to place things such as "Show offline contacts" in it. Mostly the idea would be to have controllers for both the model-as-model and its view-as-model. ***** ABOUT EVOLUTION-DATA-SERVER The evolution-data-server api looks pretty good -- except that it seems to mainly handle static vcard-based contacts, where I would like to be able to handle things like. For example, we find a nice contacts-changed signal, but in the EBookView api... not in the EBook api, which seems strange. ***** ABOUT LIBGAIM I shriek everytime I read/think about that comment in blist.h (just before the declaration of struct _GaimBuddy) : "A buddy. This contains everything Gaim will ever need to know about someone on the buddy list. Everything." (sic). and that one (before the declaration of struct _GaimContact) : "A contact. This contains everything Gaim will ever need to know about a contact." and that one (before the declaration of struct _GaimGroup) : "A group. This contains everything Gaim will ever need to know about a group." Notice that the comment before struct _GaimChat, although very similar, isn't so bad in my eye :-) Notice too that although I find the way it is done inelegant, it still is very good and efficient to get the job done, and contains quite an impressive list of good ideas. (And it's more portable as ekiga, gasp!) ***** ABOUT LIBGALAGO Why, why, oh why does it contain a GalagoList api which looks so much like a GList but isn't !? Apart from that, I would say it looks nice, but is out of scope for what we want to do right now : it doesn't deal with addressbooks, but with persons as single. "Using" it would be nice at some point. ***** LAST WORDS Congratulations, comments and flames welcome, but flames will end in /dev/null. Snark From jpuydt@free.fr Thu Jun 15 04:55:35 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7B51D3B008E for ; Thu, 15 Jun 2006 04:55:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24192-02 for ; Thu, 15 Jun 2006 04:55:31 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id C36A43B00CA for ; Thu, 15 Jun 2006 04:55:30 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp3-g19.free.fr (Postfix) with ESMTP id 26E1F496DD for ; Thu, 15 Jun 2006 10:54:59 +0200 (CEST) Message-ID: <4491205F.5070708@free.fr> Date: Thu, 15 Jun 2006 10:54:55 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.369 tagged_above=-999 required=2 tests=[AWL=0.230, BAYES_00=-2.599] X-Spam-Score: -2.369 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 08:55:35 -0000 Hi, in private mails (with quite big attachments since I provided some sample stupid code), Éric Bischoff found my code not that explicit concerning what I have in mind. Since I would like to keep things as opened as possible, I drop my text here :-) Let's see if I can manage to give useful ideas. ***** BIG WORDS Model - View - Controller ***** VIEWING (GENERIC) We need to be able to present a book to the user. For that, the view needs to have a list of contacts (no, a single contact definitely isn't enough!). So we need a function call to get a list of contacts. The problem is that this list will change during time (new contacts added, others removed, presence changed, status message changed, and the list goes on). So the view will need to be notified about it. Hence the idea that the book will have "contact-added" and "contact-removed" signals, and the contacts a "updated" signal. In addition to that, there is an interesting special case to handle : you have a contact in a book, and this contact shows up in a search result. When you remove the contact from the book, we want to make it disappear from the list too. Hence a "removed" signal for contacts. Now this is all nice, but what can we do if an addressbook contains millions of entries ? And if a search gives thousands of results ? In such cases, my stance is that the low level code should do something about it, since it is the one giving the problem. How can the high level code cope correctly with the situation anyway ? Only the low level code can say "Eh, I already made two hundred contacts go through the wire for that search, perhaps I should make it easy!". The question to really ask, and to which I have no satisfactory answer is: "How do me make the low level tell the high level it had to cut the list ?". ***** VIEWING (CONTACTS) The contacts should contain enough to be viewed from a generic view in the contacts window, and be shown in a search result. That won't prevent some other parts of the code to make a better use of them. For example, in the contact window we will probably be able to see a contact's title and description, but not its detailed presence, while the main window will contain a much better and more specific view for the live contacts. ***** CONTROLLING (GENERIC) Now, we want to be able to act on our objects ; say rename a book or a contact, subscribe/unsubscribe to its presence, etc. The best thing to do is to be able to get menus for each of them. Notice the plural: we will certainly to have at least menu in the menu bar and a popup menu. The first bad news about such menus is that they won't be generic : they will depend heavily on the specific type of object (no rename for avahi contacts, subscribe/unsubscribe only for XMPP contacts...). So we will certainly need some sort of shared actions that will be basic bricks for building menu (like the shared-actions.[ch] of my first round of proposals), that each implementation will mix as it sees fit. The second bad news about them is that they won't be static either. They will have to update themselves following the object they are attached to. Say your nice XMPP contact is connected with a client which has VoIP support, but now connects with a no-VoIP client, and disconnects the first : we want the "Call" menuitem to disappear to reflect this. So my proposition (no code yet) is that those menus will be obtained by subclassing of GtkMenu, register to get signals from the contact/book they are attached to, and use that to keep themselves up to date. ***** CONTROLLING (CONTACTS) Let's try to be more specific: in avahi-contact-menu.h, we would have: GtkWidget *avahi_contact_menu_new (AvahiContact *contact); and in gm-contact.h: GtkWidget *gm_contact_get_menu_new (GmContact *contact); This later function would be different in each implementation, which allows for example the avahi_contact_get_menu_new implementation to call avahi_contact_menu_new. The high level code called a generic function, but got access to a very specific implementation, which knows the full api of the specific contact, and hence will provide the best service. ***** CONTROLLING (BOOKS) Perhaps the menu shouldn't be attached to the book himself, but to its view. That would allow to place things such as "Show offline contacts" in it. Mostly the idea would be to have controllers for both the model-as-model and its view-as-model. ***** ABOUT EVOLUTION-DATA-SERVER The evolution-data-server api looks pretty good -- except that it seems to mainly handle static vcard-based contacts, where I would like to be able to handle things like. For example, we find a nice contacts-changed signal, but in the EBookView api... not in the EBook api, which seems strange. ***** ABOUT LIBGAIM I shriek everytime I read/think about that comment in blist.h (just before the declaration of struct _GaimBuddy) : "A buddy. This contains everything Gaim will ever need to know about someone on the buddy list. Everything." (sic). and that one (before the declaration of struct _GaimContact) : "A contact. This contains everything Gaim will ever need to know about a contact." and that one (before the declaration of struct _GaimGroup) : "A group. This contains everything Gaim will ever need to know about a group." Notice that the comment before struct _GaimChat, although very similar, isn't so bad in my eye :-) Notice too that although I find the way it is done inelegant, it still is very good and efficient to get the job done, and contains quite an impressive list of good ideas. (And it's more portable as ekiga, gasp!) ***** ABOUT LIBGALAGO Why, why, oh why does it contain a GalagoList api which looks so much like a GList but isn't !? Apart from that, I would say it looks nice, but is out of scope for what we want to do right now : it doesn't deal with addressbooks, but with persons as single. "Using" it would be nice at some point. ***** LAST WORDS Congratulations, comments and flames welcome, but flames will end in /dev/null. Snark PS: this message is already two or three days old... but got stuck. From ebischoff@nerim.net Thu Jun 15 07:18:00 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 98B4A3B032E for ; Thu, 15 Jun 2006 07:18:00 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01896-02 for ; Thu, 15 Jun 2006 07:17:57 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id 2C6AF3B0488 for ; Thu, 15 Jun 2006 07:17:56 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 3CBA240F45 for ; Thu, 15 Jun 2006 13:17:52 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Thu, 15 Jun 2006 13:18:05 +0200 User-Agent: KMail/1.8.2 References: <4491205F.5070708@free.fr> In-Reply-To: <4491205F.5070708@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606151318.05338.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.578 tagged_above=-999 required=2 tests=[AWL=0.021, BAYES_00=-2.599] X-Spam-Score: -2.578 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 11:18:01 -0000 Hi Julien, and thanks for this nice document. That looks like a good basis for thinkin= g=20 aloud :-). Le Jeudi 15 Juin 2006 10:54, Julien PUYDT a =C3=A9crit=C2=A0: > ***** BIG WORDS > > Model - View - Controller Excellent basis. > ***** VIEWING (GENERIC) > > We need to be able to present a book to the user. For that, the view > needs to have a list of contacts (no, a single contact definitely isn't > enough!). So we need a function call to get a list of contacts. In this paragraph I will assume that you mean "the view needs a list of all= =20 contacts from the address book driver". If it is not what you mean, please= =20 ignore this paragraph... The view needs to display, say, 10 contects at a time. No need to keep a li= st=20 of all contacts in memory. All we "need" is a function that gets _one_ contact from the driver. The vi= ew=20 can then use this information to keep the list of the 10 contacts that it=20 currently displays. > The problem is that this list will change during time (new contacts > added, others removed, presence changed, status message changed, and the > list goes on). So the view will need to be notified about it. Hence the > idea that the book will have "contact-added" and "contact-removed" > signals, and the contacts a "updated" signal. > In addition to that, there is an interesting special case to handle : > you have a contact in a book, and this contact shows up in a search > result. When you remove the contact from the book, we want to make it > disappear from the list too. Hence a "removed" signal for contacts. While this sounds cool, I am not sure that this will be possible in some=20 circumstances. The underlying address book (evolution, KDE address book, LD= AP=20 server, Zeroconf, ...) might not have the mechanisms to send such a signal. I can imagine situations where some users on machine A update a LDAP server= on=20 machine B while Ekiga runs on machine C, with the network connection betwee= n=20 B and C being temporarily broken. Will an update message come up to the=20 driver, and if yes when and how? Please notice that I do not know LDAP well and that such mechanisms might=20 exist. Should that be the case, please ignore these paragraphs. What do I propose instead? To be less ambitious, and have an address book t= hat=20 only pulls the data from the data source. If the user does not press=20 "refresh", then he/she might have outdated information. If he/she presses=20 "refresh", then the addresses are fetched again from the source. > Now this is all nice, but what can we do if an addressbook contains > millions of entries ? And if a search gives thousands of results ? In > such cases, my stance is that the low level code should do something > about it, since it is the one giving the problem. I do not like that repartition of tasks. Let me take an example. When you write an operating system, you write: =2D disk drivers (the low level code that does physical read and write from and to the hard disk) =2D a filesystem (the high level code that gathers individual sectors into files, handles a cache, etc) The low level code should not be bothered with handling the disk cache. Oka= y,=20 the problem comes from the disk driver, because it does slow access to the= =20 medium. That does not mean that it's not another component, the filesystem,= =20 that can solve it. Why this repartition of tasks? Because the performance problem is a problem= =20 that can be shared by many disk drivers. Therefore, the solution can be put= =20 in common in the high level code. > How can the high level > code cope correctly with the situation anyway ? Only the low level code > can say "Eh, I already made two hundred contacts go through the wire for > that search, perhaps I should make it easy!". Why transfer 200 contacts when the view knows that it needs only 10? > The question to really ask, and to which I have no satisfactory answer > is: "How do me make the low level tell the high level it had to cut the > list ?". The views know that contacts 301 to 309 are displayed. It's the view that=20 knows where to cut. In fact, there's nothing to cut, since all the view doe= s=20 is ask the driver for the contects it needs. > ***** VIEWING (CONTACTS) > > The contacts should contain enough to be viewed from a generic view in > the contacts window, and be shown in a search result. That won't prevent > some other parts of the code to make a better use of them. > > For example, in the contact window we will probably be able to see a > contact's title and description, but not its detailed presence, while > the main window will contain a much better and more specific view for > the live contacts. You say that the "contact" class must have _enough_ information to be used= =20 both in situation A and in sitation B. It would be better to have _different_ "contact" classes for situations "A"= =20 and "B". The list of contacts could just manage a name, a company and a phone number= =2E=20 The search result could handle much more detailed information. In other words, there's no need to put all the model's data into the views'= =20 data. Each view can handle the data it needs. > ***** CONTROLLING (GENERIC) > > Now, we want to be able to act on our objects ; say rename a book or a > contact, subscribe/unsubscribe to its presence, etc. > > The best thing to do is to be able to get menus for each of them. Notice > the plural: we will certainly to have at least menu in the menu bar and > a popup menu. > > The first bad news about such menus is that they won't be generic : they > will depend heavily on the specific type of object (no rename for avahi > contacts, subscribe/unsubscribe only for XMPP contacts...). So we will > certainly need some sort of shared actions that will be basic bricks for > building menu (like the shared-actions.[ch] of my first round of > proposals), that each implementation will mix as it sees fit. I assume here that an 'implementation" is one of the address book drivers, = and=20 that you mean that the drivers will be in charge of building menus. If thos= e=20 assumptions are wrong, the paragraph below does not apply, please just igno= re=20 it. Just the same as a hard disk driver does not display menus to the user, I=20 think that the address book drivers in Ekiga should not be responsible for= =20 user interaction. The high level code should be responsible for that. Of course the contents = of=20 the various menus depends on the address book capabilities. That's why the= =20 API between the driver and the high level code should include "query=20 capabilities functions:" class addressBook { virtual bool isReadOnly() =3D 0; virtual bool canSubscribeContacts() =3D 0; ... }; > The second bad news about them is that they won't be static either. They > will have to update themselves following the object they are attached > to. Say your nice XMPP contact is connected with a client which has VoIP > support, but now connects with a no-VoIP client, and disconnects the > first : we want the "Call" menuitem to disappear to reflect this. > > So my proposition (no code yet) is that those menus will be obtained by > subclassing of GtkMenu, register to get signals from the contact/book > they are attached to, and use that to keep themselves up to date. In your example, a signal is not needed. Knowing that there is no VoIP number in the current contact is enough. > ***** CONTROLLING (CONTACTS) > > Let's try to be more specific: > in avahi-contact-menu.h, we would have: > GtkWidget *avahi_contact_menu_new (AvahiContact *contact); > and in gm-contact.h: > GtkWidget *gm_contact_get_menu_new (GmContact *contact); > > This later function would be different in each implementation, which > allows for example the avahi_contact_get_menu_new implementation to call > avahi_contact_menu_new. The high level code called a generic function, > but got access to a very specific implementation, which knows the full > api of the specific contact, and hence will provide the best service. Again, this logic should be in the high-level code and needs not be=20 avahi-specific. What exactly should be presented to the user could be=20 determined from querying the address book for its capabilities. > ***** CONTROLLING (BOOKS) > > Perhaps the menu shouldn't be attached to the book himself, but to its > view. That would allow to place things such as "Show offline contacts" > in it. Mostly the idea would be to have controllers for both the > model-as-model and its view-as-model. Agree. > ***** ABOUT EVOLUTION-DATA-SERVER > > The evolution-data-server api looks pretty good -- except that it seems > to mainly handle static vcard-based contacts, where I would like to be > able to handle things like. > > For example, we find a nice contacts-changed signal, but in the > EBookView api... not in the EBook api, which seems strange. > > ***** ABOUT LIBGAIM > > I shriek everytime I read/think about that comment in blist.h (just > before the declaration of struct _GaimBuddy) : > "A buddy. This contains everything Gaim will ever need to know about > someone on the buddy list. Everything." (sic). > and that one (before the declaration of struct _GaimContact) : > "A contact. This contains everything Gaim will ever need to know about > a contact." > and that one (before the declaration of struct _GaimGroup) : > "A group. This contains everything Gaim will ever need to know about a > group." > > Notice that the comment before struct _GaimChat, although very similar, > isn't so bad in my eye :-) > > Notice too that although I find the way it is done inelegant, it still > is very good and efficient to get the job done, and contains quite an > impressive list of good ideas. (And it's more portable as ekiga, gasp!) > > ***** ABOUT LIBGALAGO > > Why, why, oh why does it contain a GalagoList api which looks so much > like a GList but isn't !? > > Apart from that, I would say it looks nice, but is out of scope for what > we want to do right now : it doesn't deal with addressbooks, but with > persons as single. > > "Using" it would be nice at some point. > > ***** LAST WORDS > > Congratulations, comments and flames welcome, but flames will end in > /dev/null. It definitly deserves congratulations. You forgot to mention one of your ni= ce=20 ideas, that it that it should be possible to search in several address book= s=20 at a time. =46or the comments, please note that my comments are based on a lot of=20 assumptions and guesses. In particular, I assume that you have in mind a=20 different assignment of tasks of the various software layers than the one=20 that I would like to see. If those assumptions reveal wrong, then of course= =20 my comments do not make much sense. If I did not misinterpret your thoughts, you have a very lazy view of the=20 high-level code. It's software that sits down and waits for signals to act.= =20 Somehow, the high level code provides "services" to the drivers. The driver= s=20 are the ones who understand what's going on. I have the opposite view: the address book drivers are simple and stupid.=20 Their main task is to go and fetch the requested contacts. The high level=20 code has an active attitude: it queries the drivers for contacts, it querie= s=20 the drivers capabilities, it displays the contact windows, it handles the=20 menues... The high level code has the real intelligence. I hope that helps, =2D-=20 Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m=C3=A9dire." (Le concombre masqu=C3=A9, Mandriva) From kk@verfaction.de Thu Jun 15 10:03:55 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C686B3B0336 for ; Thu, 15 Jun 2006 10:03:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15471-01 for ; Thu, 15 Jun 2006 10:03:54 -0400 (EDT) Received: from mx.verfaction.de (mx.verfaction.de [212.9.177.23]) by menubar.gnome.org (Postfix) with ESMTP id 779793B00CE for ; Thu, 15 Jun 2006 10:03:54 -0400 (EDT) Received: from erebos.verfaction.de ([2001:14b0:201:7357::1] helo=homemx.verfaction.de ident=Debian-exim) by mx.verfaction.de with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FqsRp-0003kA-3Z for gnomemeeting-devel-list@gnome.org; Thu, 15 Jun 2006 16:03:52 +0200 Received: from ganymede.kk.de ([192.168.7.10]) by homemx.verfaction.de with esmtp (Exim 4.50) id 1FqsRk-0000ld-Dw for gnomemeeting-devel-list@gnome.org; Thu, 15 Jun 2006 16:03:48 +0200 From: Kilian Krause To: GnomeMeeting development mailing list In-Reply-To: <200606081002.37875.conrad_videokonferenz@gmx.de> References: <200606081002.37875.conrad_videokonferenz@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aitPD1cXT483JdjYdYcu" Date: Thu, 15 Jun 2006 16:03:43 +0200 Message-Id: <1150380224.6599.22.camel@ganymede.verfaction.de> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-SA-Exim-Connect-IP: 2001:14b0:201:7357::1 X-SA-Exim-Mail-From: kk@verfaction.de X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 14:03:56 -0000 --=-aitPD1cXT483JdjYdYcu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hey Conrad, Am Donnerstag, den 08.06.2006, 10:02 +0000 schrieb Conrad Beckert: > has anybody an idea where the Debian packages for Ekiga 2.0.2 (or the=20 > corresponding CVS versions) are? on their way. > The last version I can install using apt-get a couple of days old (May 25= - or=20 > somethin) - at least this is a version with the nonfunctional German loc= ale.=20 > (defaults to English) >=20 > What's up? /me is having a sheer lack of time and thus it took me a while to get everything polished and fixed just like i love to have it. =3D) Everything should be back to normal as of tonight (eventually sarge cvs snaps and win32 will remain for the weekend - we'll see) --=20 Best regards, Kilian --=-aitPD1cXT483JdjYdYcu Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEkWi/vdkzt4X+wX8RAnZ/AJoCW2qvo1l8kFsAJzogWEPKv73LUACZAZk6 n6VWZ1JiCCXnGNsq5yEsLwU= =VwN+ -----END PGP SIGNATURE----- --=-aitPD1cXT483JdjYdYcu-- From jpuydt@free.fr Thu Jun 15 11:41:17 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D25F23B0616 for ; Thu, 15 Jun 2006 11:41:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20025-08 for ; Thu, 15 Jun 2006 11:41:15 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id 8BF5B3B041B for ; Thu, 15 Jun 2006 11:41:14 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp6-g19.free.fr (Postfix) with ESMTP id 3FD8B227D9 for ; Thu, 15 Jun 2006 17:40:32 +0200 (CEST) Message-ID: <44917F71.10408@free.fr> Date: Thu, 15 Jun 2006 17:40:33 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> In-Reply-To: <200606151318.05338.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.337 tagged_above=-999 required=2 tests=[AWL=0.185, BAYES_00=-2.599, TW_AV=0.077] X-Spam-Score: -2.337 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:41:18 -0000 Éric Bischoff a écrit : >> ***** VIEWING (GENERIC) >> >> We need to be able to present a book to the user. For that, the view >> needs to have a list of contacts (no, a single contact definitely isn't >> enough!). So we need a function call to get a list of contacts. > > In this paragraph I will assume that you mean "the view needs a list of all > contacts from the address book driver". If it is not what you mean, please > ignore this paragraph... Well, all contacts may be asking too much. I expect drivers to keep things sane. > The view needs to display, say, 10 contects at a time. No need to keep a list > of all contacts in memory. > > All we "need" is a function that gets _one_ contact from the driver. The view > can then use this information to keep the list of the 10 contacts that it > currently displays. Blah. If you're gonna loop on a list of contacts anyway, then get the list at once. Saying "I get only the 10 I need" is nice, but how do you tell the driver which they are ? Especially a roster XMPP generally comes as a single roster push you ask for when connecting, then little update pushes. >> The problem is that this list will change during time (new contacts >> added, others removed, presence changed, status message changed, and the >> list goes on). So the view will need to be notified about it. Hence the >> idea that the book will have "contact-added" and "contact-removed" >> signals, and the contacts a "updated" signal. >> In addition to that, there is an interesting special case to handle : >> you have a contact in a book, and this contact shows up in a search >> result. When you remove the contact from the book, we want to make it >> disappear from the list too. Hence a "removed" signal for contacts. > > While this sounds cool, I am not sure that this will be possible in some > circumstances. The underlying address book (evolution, KDE address book, LDAP > server, Zeroconf, ...) might not have the mechanisms to send such a signal. No problem : then they don't. Let's take the avahi book. It will probably update the list of users regularly (and have some action to update *now*). How will it work ? Well, it will populate a cache with those contacts, and on updating, flush it ("contact-removed" emitted on all of them), then repopulate it ("contact-added"). > I can imagine situations where some users on machine A update a LDAP server on > machine B while Ekiga runs on machine C, with the network connection between > B and C being temporarily broken. Will an update message come up to the > driver, and if yes when and how? If the backend doesn't give incremental changes, that still fits in my design. > What do I propose instead? To be less ambitious, and have an address book that > only pulls the data from the data source. If the user does not press > "refresh", then he/she might have outdated information. If he/she presses > "refresh", then the addresses are fetched again from the source. Bad. If the backend gives incremental changes, you don't handle it. Such a design works only for the most simple backends. >> Now this is all nice, but what can we do if an addressbook contains >> millions of entries ? And if a search gives thousands of results ? In >> such cases, my stance is that the low level code should do something >> about it, since it is the one giving the problem. > > I do not like that repartition of tasks. > > Let me take an example. When you write an operating system, you write: > - disk drivers > (the low level code that does physical read and write from and to > the hard disk) > - a filesystem > (the high level code that gathers individual sectors into files, > handles a cache, etc) > > The low level code should not be bothered with handling the disk cache. Okay, > the problem comes from the disk driver, because it does slow access to the > medium. That does not mean that it's not another component, the filesystem, > that can solve it. > > Why this repartition of tasks? Because the performance problem is a problem > that can be shared by many disk drivers. Therefore, the solution can be put > in common in the high level code. Your file manager doesn't handle the filesystems itself : they all present the same interface, and take care of caching themselves. I want the addressbook manager to be *high* level. If some caching is needed between the addressbook manager and the backend, I want the driver to take care of it. In fact, I implemented a SearchBook to take care of presenting all search results (whatever the book), and it's certainly desirable to provide a CachedBook, which will avoid code duplication. >> How can the high level >> code cope correctly with the situation anyway ? Only the low level code >> can say "Eh, I already made two hundred contacts go through the wire for >> that search, perhaps I should make it easy!". > > Why transfer 200 contacts when the view knows that it needs only 10? The view may show only ten at the same time on the screen, but the mouse wheel makes it so easy to go through all of the 200, that it wouldn't be wise to have them ready. If there are several thousands, that's more annoying. >> The question to really ask, and to which I have no satisfactory answer >> is: "How do me make the low level tell the high level it had to cut the >> list ?". > > The views know that contacts 301 to 309 are displayed. It's the view that > knows where to cut. In fact, there's nothing to cut, since all the view does > is ask the driver for the contects it needs. How do you number the contacts in a sane way? >> ***** VIEWING (CONTACTS) >> >> The contacts should contain enough to be viewed from a generic view in >> the contacts window, and be shown in a search result. That won't prevent >> some other parts of the code to make a better use of them. >> >> For example, in the contact window we will probably be able to see a >> contact's title and description, but not its detailed presence, while >> the main window will contain a much better and more specific view for >> the live contacts. > > You say that the "contact" class must have _enough_ information to be used > both in situation A and in sitation B. > > It would be better to have _different_ "contact" classes for situations "A" > and "B". Of course there will be. I was discussing the base class. > The list of contacts could just manage a name, a company and a phone number. I would put the following : 1) a title (generally the name) 2) a description (for example a location, a status message, etc) 3) an icon > The search result could handle much more detailed information. Of course it cannot. Your search result is a book which needs to be able to show avahi contacts, sip contacts, call history contacts, etc... so it can only show the contacts as generic. > In other words, there's no need to put all the model's data into the views' > data. Each view can handle the data it needs. The view which is specific to an addressbook, of course can show the data from the specific contact associated to it. But the generic view can only show generic information. >> ***** CONTROLLING (GENERIC) >> >> Now, we want to be able to act on our objects ; say rename a book or a >> contact, subscribe/unsubscribe to its presence, etc. >> >> The best thing to do is to be able to get menus for each of them. Notice >> the plural: we will certainly to have at least menu in the menu bar and >> a popup menu. >> >> The first bad news about such menus is that they won't be generic : they >> will depend heavily on the specific type of object (no rename for avahi >> contacts, subscribe/unsubscribe only for XMPP contacts...). So we will >> certainly need some sort of shared actions that will be basic bricks for >> building menu (like the shared-actions.[ch] of my first round of >> proposals), that each implementation will mix as it sees fit. > > I assume here that an 'implementation" is one of the address book drivers, and > that you mean that the drivers will be in charge of building menus. If those > assumptions are wrong, the paragraph below does not apply, please just ignore > it. Yes, that's precisely that. > Just the same as a hard disk driver does not display menus to the user, I > think that the address book drivers in Ekiga should not be responsible for > user interaction The menu is supposed to contain actions which are specific to the given contact, book or view. Hence it must be created by code which is specific to that contact, book or view. It cannot be done by the generic code. > The high level code should be responsible for that. Of course the contents of > the various menus depends on the address book capabilities. That's why the > API between the driver and the high level code should include "query > capabilities functions:" > > class addressBook > { > virtual bool isReadOnly() = 0; > virtual bool canSubscribeContacts() = 0; > ... > }; No, that is wrong and I already explained why. Putting everything in the base class is bad. >> The second bad news about them is that they won't be static either. They >> will have to update themselves following the object they are attached >> to. Say your nice XMPP contact is connected with a client which has VoIP >> support, but now connects with a no-VoIP client, and disconnects the >> first : we want the "Call" menuitem to disappear to reflect this. >> >> So my proposition (no code yet) is that those menus will be obtained by >> subclassing of GtkMenu, register to get signals from the contact/book >> they are attached to, and use that to keep themselves up to date. > > In your example, a signal is not needed. > > Knowing that there is no VoIP number in the current contact is enough. That is wrong. The same contact could update itself and gain it. Or update itself and lose it. >> ***** CONTROLLING (CONTACTS) >> >> Let's try to be more specific: >> in avahi-contact-menu.h, we would have: >> GtkWidget *avahi_contact_menu_new (AvahiContact *contact); >> and in gm-contact.h: >> GtkWidget *gm_contact_get_menu_new (GmContact *contact); >> >> This later function would be different in each implementation, which >> allows for example the avahi_contact_get_menu_new implementation to call >> avahi_contact_menu_new. The high level code called a generic function, >> but got access to a very specific implementation, which knows the full >> api of the specific contact, and hence will provide the best service. > > Again, this logic should be in the high-level code and needs not be > avahi-specific. What exactly should be presented to the user could be > determined from querying the address book for its capabilities. Which means : 1) *all* of the addressbooks would by default have *all* the possible apis for such capability by default, with a isAbleToDoFoo function for each Foo capability ; 2) if an addressbook needs a new capability, we'll have to modify the base addressbook to add it in for it ; it won't just be a matter for the new code to add only what is necessary for itself in its own files. >> ***** CONTROLLING (BOOKS) >> >> Perhaps the menu shouldn't be attached to the book himself, but to its >> view. That would allow to place things such as "Show offline contacts" >> in it. Mostly the idea would be to have controllers for both the >> model-as-model and its view-as-model. > > Agree. Nice. >> Congratulations, comments and flames welcome, but flames will end in >> /dev/null. > > It definitly deserves congratulations. You forgot to mention one of your nice > ideas, that it that it should be possible to search in several address books > at a time. Well, that is the main side-effect of having a base class for contacts. > For the comments, please note that my comments are based on a lot of > assumptions and guesses. In particular, I assume that you have in mind a > different assignment of tasks of the various software layers than the one > that I would like to see. If those assumptions reveal wrong, then of course > my comments do not make much sense. I think you are focused on an addressbook as something both very big and very static, which explains many of our divergences. > If I did not misinterpret your thoughts, you have a very lazy view of the > high-level code. It's software that sits down and waits for signals to act. > Somehow, the high level code provides "services" to the drivers. The drivers > are the ones who understand what's going on. Yes, that's it. The high-level code doesn't know what an AvahiContact or EDSContact is ; it only knows avbout GmContact. That means it cannot do fancy things with them, and has to call functions on them to do anything interesting. > I have the opposite view: the address book drivers are simple and stupid. > Their main task is to go and fetch the requested contacts. The high level > code has an active attitude: it queries the drivers for contacts, it queries > the drivers capabilities, it displays the contact windows, it handles the > menues... The high level code has the real intelligence. Your high level code is very complex, and has to be modified heavily anytime we add a new type of addressbook with new capabilities. Anytime you want to do something, you should ask yourself the question: "Who knows how to do it?". You want to send a message to a contact ? Who knows if it's even possible, and how to do it ? The contact itself! Hence this should be handled by the contact. Of course, as-is that would mean a lot of code duplication. That's where we can use a toolbox ; of which you had an example in the first round of sample code I sent in private. To make it explicit for the -devel- readers, this sample code had a function: void shared_action_rename (GObject *obj); so any object which could be renamed, had only to: - have a "name" property ; - provide an action which trigerred that function on itself. the function handled showing a nice dialog to rename the function. The idea is that of course quite a few objects will have common capabilities ; but instead of putting them all in the high level code and clutter it with functions and conditional, I want to provide the bricks which the low-level code will use to build a specific and well-fit system. Snark From ebischoff@nerim.net Thu Jun 15 14:27:54 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1F1163B04C0 for ; Thu, 15 Jun 2006 14:27:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27103-03 for ; Thu, 15 Jun 2006 14:27:51 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id E36E93B0412 for ; Thu, 15 Jun 2006 14:27:50 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 25E1340F90 for ; Thu, 15 Jun 2006 20:26:36 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Thu, 15 Jun 2006 20:26:49 +0200 User-Agent: KMail/1.8.2 References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> <44917F71.10408@free.fr> In-Reply-To: <44917F71.10408@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606152026.49639.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.533 tagged_above=-999 required=2 tests=[AWL=-0.011, BAYES_00=-2.599, SUBJECT_EXCESS_QP=0, TW_AV=0.077] X-Spam-Score: -2.533 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] =?utf-8?q?Ideas_and_considerations_for_?= =?utf-8?q?the=09addressbook_code?= X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 18:27:54 -0000 Le Jeudi 15 Juin 2006 17:40, Julien PUYDT a =C3=A9crit=C2=A0: > Saying "I get only the 10 I need" is nice, but how do you tell the > driver which they are ? There are several ways to acheive that. It could be contact numbers. Or it= =20 could be some data kept internally inside the driver. It could be a void *.= =20 Etc. > > While this sounds cool, I am not sure that this will be possible in some > > circumstances. The underlying address book (evolution, KDE address book, > > LDAP server, Zeroconf, ...) might not have the mechanisms to send such a > > signal. > > No problem : then they don't. OK. So that should not be a requirement, and certainly not a mechanism at t= he=20 core of the system. Just a nice plus. > > Why transfer 200 contacts when the view knows that it needs only 10? > > The view may show only ten at the same time on the screen, but the mouse > wheel makes it so easy to go through all of the 200, that it wouldn't be > wise to have them ready. Yes. You could have a few spare contacts before and after the user's view.= =20 This algorithm is rather common. > If there are several thousands, that's more annoying. Okay. Let's simulate your algorithm, or what I have understood of it. The user views a search selection of contacts named "Tom". His/her window=20 should contain contacts Tom Smith (#1032), Tom Jones (#2050) and Tom Doe=20 (#3172). The high level software asks the driver "get me all contacts". Aft= er=20 a relatively long time, the driver is wise and stops at contact 200. It=20 returns a list with contacts 1, 2, 3, etc, up to 200. The high level softwa= re=20 searches for Tom's in the list and finds none, since the Tom's have numbers= =20 1032, 2050 and 3172. The returned list is useless, and the window remains=20 blank. I know that it cannot be _that_ bad and that I certainly misunderstood=20 something. But what? > > The views know that contacts 301 to 309 are displayed. It's the view th= at > > knows where to cut. In fact, there's nothing to cut, since all the view > > does is ask the driver for the contects it needs. > > How do you number the contacts in a sane way? These numbers are here for the demonstration. I agree that numbers probably= =20 are not so well adapted to real address books. You could use "markers". I think that all address books use contact UIDs. A= =20 given UID could be used to mark the place where the address book stopped=20 "last time". =46or most usage you do not even need anything. Most operation is sequentia= l.=20 Take for example searching. Usually you browse all records and only keep in= =20 the result list the ones that match. > I would put the following : > 1) a title (generally the name) > 2) a description (for example a location, a status message, etc) > 3) an icon Yes, we are discussing principles. Details can be arranged later. > > The search result could handle much more detailed information. > > Of course it cannot. Your search result is a book which needs to be able > to show avahi contacts, sip contacts, call history contacts, etc... so > it can only show the contacts as generic. Why would you be unable to display detailed information about objects which= =20 you only know as generic? while (genericContact =3D nextContact()) { if (genericContact->book()->canSubscribeContacts()) proposeSubscription(genericContact); ... } > The view which is specific to an addressbook, of course can show the > data from the specific contact associated to it. But the generic view > can only show generic information. Wrong ;-). Not shown in the code sample above, but that's also the whole point of virt= ual=20 methods. > The menu is supposed to contain actions which are specific to the given > contact, book or view. Hence it must be created by code which is > specific to that contact, book or view. It cannot be done by the generic > code. ;-) > > class addressBook > > { > > virtual bool isReadOnly() =3D 0; > > virtual bool canSubscribeContacts() =3D 0; > > ... > > }; > > No, that is wrong and I already explained why. Putting everything in the > base class is bad. Do you realize that the above is not an implementation? It's just an API=20 definition. Those are pure virtual methods. Everything is implemented in th= e=20 derived subclasses. Such style of coding is very classical, good, C++ (or java). > > In your example, a signal is not needed. > > > > Knowing that there is no VoIP number in the current contact is enough. > > That is wrong. The same contact could update itself and gain it. Or > update itself and lose it. I should have added "at a given time". > Which means : > 1) *all* of the addressbooks would by default have *all* the possible > apis for such capability by default, with a isAbleToDoFoo function for > each Foo capability ; No. Defining pure virtual functions in the base class does not mean that yo= u=20 implement a function in the derived class. If it can't do something, and le= ts=20 the engine know it, then it can't ;-). > 2) if an addressbook needs a new capability, we'll have to modify the > base addressbook to add it in for it ; it won't just be a matter for the > new code to add only what is necessary for itself in its own files. Wrong again, C++ comes with programming techniques that permit to locate th= e=20 real implementations in the derived classes. > > It definitly deserves congratulations. You forgot to mention one of your > > nice ideas, that it that it should be possible to search in several > > address books at a time. > > Well, that is the main side-effect of having a base class for contacts. ;-) > I think you are focused on an addressbook as something both very big and > very static, which explains many of our divergences. I think that we are both wrong here ;-). An address book could be big (whic= h=20 you underestimated), and it could be moving (which I underestimated). > Yes, that's it. The high-level code doesn't know what an AvahiContact or > EDSContact is ; it only knows avbout GmContact. That means it cannot do > fancy things with them, and has to call functions on them to do anything > interesting. I have a view that is not so far away. The book just knows contacts. Virtua= l=20 methods and subclassing both the book and the contacts does the rest. > Your high level code is very complex, and has to be modified heavily > anytime we add a new type of addressbook with new capabilities. Yes, but much more generic. And if the same capability exists in a second address book, the code is=20 already written. > Of course, as-is that would mean a lot of code duplication. That's where > we can use a toolbox ; of which you had an example in the first round of > sample code I sent in private. Ah, you too you can see the duplication problem with your method ;-). A tool box... Sounds like a C library ;-). I think that we basically foresee the same problems, but you want to do the= m=20 in the procedural, C way, and I would like them to be done in the=20 object-oriented, C++ way. > To make it explicit for the -devel- readers, this sample code had a > function: > void shared_action_rename (GObject *obj); > so any object which could be renamed, had only to: > - have a "name" property ; > - provide an action which trigerred that function on itself. > the function handled showing a nice dialog to rename the function. Yup. You see functions where I see methods ;-). > The idea is that of course quite a few objects will have common > capabilities ; but instead of putting them all in the high level code > and clutter it with functions and conditional, Yes, that would be the logical consequence if we were in C. We are not. We= =20 have virtual methods. > I want to provide the=20 > bricks which the low-level code will use to build a specific and > well-fit system. You will end up with an engine doing about nothing, and all the work to be= =20 reimplemented again and again in the drivers. Plus painfully shared code in= =20 the "toolbox" to avoid almost identical code where it can be avoided. That'= s=20 typical procedural approach. =2D-=20 Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m=C3=A9dire." (Le concombre masqu=C3=A9, Mandriva) From jpuydt@free.fr Thu Jun 15 16:46:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 4F0A43B01FF for ; Thu, 15 Jun 2006 16:46:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32671-05 for ; Thu, 15 Jun 2006 16:46:37 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 91ADA3B00D0 for ; Thu, 15 Jun 2006 16:46:36 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp1-g19.free.fr (Postfix) with ESMTP id 743AD9A39A for ; Thu, 15 Jun 2006 22:46:01 +0200 (CEST) Message-ID: <4491C708.3060203@free.fr> Date: Thu, 15 Jun 2006 22:46:00 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> <44917F71.10408@free.fr> <200606152026.49639.ebischoff@nerim.net> In-Reply-To: <200606152026.49639.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.342 tagged_above=-999 required=2 tests=[AWL=0.180, BAYES_00=-2.599, TW_AV=0.077] X-Spam-Score: -2.342 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 20:46:39 -0000 Éric Bischoff a écrit : > Le Jeudi 15 Juin 2006 17:40, Julien PUYDT a écrit : >> Saying "I get only the 10 I need" is nice, but how do you tell the >> driver which they are ? > > There are several ways to acheive that. It could be contact numbers. Or it > could be some data kept internally inside the driver. It could be a void *. > Etc. Well, then you reduced the question: "How do I tell the driver which contacts I want?" to: "How do I tell the driver which identifiers I want?" I don't find this impressive. >>> While this sounds cool, I am not sure that this will be possible in some >>> circumstances. The underlying address book (evolution, KDE address book, >>> LDAP server, Zeroconf, ...) might not have the mechanisms to send such a >>> signal. >> No problem : then they don't. > > OK. So that should not be a requirement, and certainly not a mechanism at the > core of the system. Just a nice plus. It *must* be at the core of the system. We _do_ want to update the live data when it changes. >>> Why transfer 200 contacts when the view knows that it needs only 10? >> The view may show only ten at the same time on the screen, but the mouse >> wheel makes it so easy to go through all of the 200, that it wouldn't be >> wise to have them ready. > > Yes. You could have a few spare contacts before and after the user's view. > This algorithm is rather common. What do "before" and "after" mean ? >> If there are several thousands, that's more annoying. > > Okay. Let's simulate your algorithm, or what I have understood of it. > > The user views a search selection of contacts named "Tom". His/her window > should contain contacts Tom Smith (#1032), Tom Jones (#2050) and Tom Doe > (#3172). The high level software asks the driver "get me all contacts". After > a relatively long time, the driver is wise and stops at contact 200. It > returns a list with contacts 1, 2, 3, etc, up to 200. The high level software > searches for Tom's in the list and finds none, since the Tom's have numbers > 1032, 2050 and 3172. The returned list is useless, and the window remains > blank. > > I know that it cannot be _that_ bad and that I certainly misunderstood > something. But what? I certainly have issues with big books, and must find some satisfying way to handle them. But doing function calls to walk on a list where I could get the list and walk it myself directly, is definitely wrong. >>> The views know that contacts 301 to 309 are displayed. It's the view that >>> knows where to cut. In fact, there's nothing to cut, since all the view >>> does is ask the driver for the contects it needs. >> How do you number the contacts in a sane way? > > These numbers are here for the demonstration. I agree that numbers probably > are not so well adapted to real address books. > > You could use "markers". I think that all address books use contact UIDs. A > given UID could be used to mark the place where the address book stopped > "last time". Notice that the only place where you call the _get_contacts function is when you first populate the book. The rest of the time you don't want to know. > For most usage you do not even need anything. Most operation is sequential. > Take for example searching. Usually you browse all records and only keep in > the result list the ones that match. Most operations are sequential when the book is static. When your contacts go online/offline/whatever, that certainly is random access, and I can tell you a first/current/next approach doesn't fly in such a situation. >>> The search result could handle much more detailed information. >> Of course it cannot. Your search result is a book which needs to be able >> to show avahi contacts, sip contacts, call history contacts, etc... so >> it can only show the contacts as generic. > > Why would you be unable to display detailed information about objects which > you only know as generic? > > while (genericContact = nextContact()) > { > if (genericContact->book()->canSubscribeContacts()) > proposeSubscription(genericContact); > ... > } Yes, of course. You put everything at the high level, something which I already stressed was very very bad. Let's try an example. A text editor will just access files. It won't wonder if they are local or remote, it won't wonder about where the data really is on disk, need caching, etc. This is the job of the low-level system. The text editor doesn't have functions and tests to handle all of the various situations possible. High level is high, it doesn't take mud baths with the details, it doesn't handle them. It delegates them to the low level. >> The view which is specific to an addressbook, of course can show the >> data from the specific contact associated to it. But the generic view >> can only show generic information. > > Wrong ;-). Partially wrong. The generic view can indeed get access to some specific features (like the menus I explained). But it certainly *must* not get them by handling *all* possible situations. >>> class addressBook >>> { >>> virtual bool isReadOnly() = 0; >>> virtual bool canSubscribeContacts() = 0; >>> ... >>> }; >> No, that is wrong and I already explained why. Putting everything in the >> base class is bad. > > Do you realize that the above is not an implementation? It's just an API > definition. Those are pure virtual methods. Everything is implemented in the > derived subclasses. > > Such style of coding is very classical, good, C++ (or java). Such style of coding is not classical, is bad and evil. I see abstractions layers everywhere to hide the details of the lower level, and you want to push those details high up the stack. >>> In your example, a signal is not needed. >>> >>> Knowing that there is no VoIP number in the current contact is enough. >> That is wrong. The same contact could update itself and gain it. Or >> update itself and lose it. > > I should have added "at a given time". > >> Which means : >> 1) *all* of the addressbooks would by default have *all* the possible >> apis for such capability by default, with a isAbleToDoFoo function for >> each Foo capability ; > > No. Defining pure virtual functions in the base class does not mean that you > implement a function in the derived class. If it can't do something, and lets > the engine know it, then it can't ;-). You push all the code to the high level, and never really abstract. That is very wrong. >> 2) if an addressbook needs a new capability, we'll have to modify the >> base addressbook to add it in for it ; it won't just be a matter for the >> new code to add only what is necessary for itself in its own files. > > Wrong again, C++ comes with programming techniques that permit to locate the > real implementations in the derived classes. If I add a new addressbook type with a Foo capability, your designs says I have to modify the base class and add: bool canDoFoo (); void pleaseDoFooThisWay (...); void pleaseDoFooThisOtherWay (...); void etcFoo (...) (with all the virtual pure syntactic crap needed) My idea of right design is that if the new addressbook is the only one needing Foo, it will handle it himself (through a specific api that its view and controller will know and use). >> I think you are focused on an addressbook as something both very big and >> very static, which explains many of our divergences. > > I think that we are both wrong here ;-). An address book could be big (which > you underestimated), and it could be moving (which I underestimated). I agree I have issues seeing how to do things *properly* with a very large addressbook. >> Yes, that's it. The high-level code doesn't know what an AvahiContact or >> EDSContact is ; it only knows avbout GmContact. That means it cannot do >> fancy things with them, and has to call functions on them to do anything >> interesting. > > I have a view that is not so far away. The book just knows contacts. Virtual > methods and subclassing both the book and the contacts does the rest. > >> Your high level code is very complex, and has to be modified heavily >> anytime we add a new type of addressbook with new capabilities. > > Yes, but much more generic. It isn't much more generic. It is an awful and indigest mix of all the specific implementations. > And if the same capability exists in a second address book, the code is > already written. Not really. >> Of course, as-is that would mean a lot of code duplication. That's where >> we can use a toolbox ; of which you had an example in the first round of >> sample code I sent in private. > > Ah, you too you can see the duplication problem with your method ;-). > > A tool box... Sounds like a C library ;-). Which are very useful and allow to abstract common work at a lower layer and not take care of it ourselves way up. > I think that we basically foresee the same problems, but you want to do them > in the procedural, C way, and I would like them to be done in the > object-oriented, C++ way. Your view isn't OO, and isn't C++. >> To make it explicit for the -devel- readers, this sample code had a >> function: >> void shared_action_rename (GObject *obj); >> so any object which could be renamed, had only to: >> - have a "name" property ; >> - provide an action which trigerred that function on itself. >> the function handled showing a nice dialog to rename the function. > > Yup. You see functions where I see methods ;-). I see functions spread in maintainable files, with well-separated features and responsibility. You see functions named "methods" stuffed into the same poor base class, which has to handle everything and the rest, and where the limits between everything is blurred. Where I say function and do: gm_contact_do_foo (contact, arguments); you say method and to: contact->do_foo (arguments); which I agree is shorter, but isn't the magical solution you think it is! :-) >> The idea is that of course quite a few objects will have common >> capabilities ; but instead of putting them all in the high level code >> and clutter it with functions and conditional, > > Yes, that would be the logical consequence if we were in C. We are not. We > have virtual methods. You *do* have isReadOnly and canSubscribeContacts, which you will use to do the ifs I said where very wrong, and you will do so at the high level, which is precisely the place where details shouldn't be handled! It isn't a case of leaky abstraction, it is a case of no-abstraction! >> I want to provide the >> bricks which the low-level code will use to build a specific and >> well-fit system. > > You will end up with an engine doing about nothing, and all the work to be > reimplemented again and again in the drivers. Plus painfully shared code in > the "toolbox" to avoid almost identical code where it can be avoided. That's > typical procedural approach. I generally end up with nice layers of functions doing almost nothing, with clean api between the layer, ensuring the code will be pretty maintainable. See lib/gmconf/ for example. We have a nice api in gmconf.h, and an implementation in gmconf-glib.c, which is layered in the same file, with lowlevel functions doing some work, and higher level doing another. Not everything done at the same final level. When I wrote that code, the goal was to make gconf (the gnome configuration management system) optional, so the port to win32 would be easier. I wrote a generic api to handle things, then two implementations *hidden* behind it. Well, at least we both agree I don't handle the case of very large addressbooks very well :-/ Snark From jpuydt@free.fr Fri Jun 16 11:44:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AC28C3B0005 for ; Fri, 16 Jun 2006 11:44:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01534-04 for ; Fri, 16 Jun 2006 11:44:08 -0400 (EDT) Received: from postfix2-c.free.fr (postfix2-c.free.fr [213.228.0.80]) by menubar.gnome.org (Postfix) with ESMTP id E28BA3B0007 for ; Fri, 16 Jun 2006 11:44:07 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by postfix2-c.free.fr (Postfix) with ESMTP id E4AFC458B6CE for ; Fri, 16 Jun 2006 16:07:32 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp6-g19.free.fr (Postfix) with ESMTP id DF5BD2265E for ; Fri, 16 Jun 2006 17:02:28 +0200 (CEST) Message-ID: <4492B888.8060206@free.fr> Date: Fri, 16 Jun 2006 15:56:24 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> In-Reply-To: <4491205F.5070708@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.382 tagged_above=-999 required=2 tests=[AWL=0.217, BAYES_00=-2.599] X-Spam-Score: -2.382 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 15:44:10 -0000 Julien PUYDT a écrit : > ***** ABOUT EVOLUTION-DATA-SERVER > > The evolution-data-server api looks pretty good -- except that it seems > to mainly handle static vcard-based contacts, where I would like to be > able to handle things like. Hmmm... this sentence should have ended with "able to handle things like live contacts with presence (SIP and XMPP)". On the subject of big addressbook handling, I must say what evolution-data-server does is quite nice : they run a query (EQuery) on a book (EBook), which gives them a view of the result (EBookView). That means that they can easily do a partial view of an addressbook, since they control what is seen! While this organisation doesn't suffer from the problem Éric pointed out, it has still a problem : how does one just "search" ? I mean, if your api is "search a book => get a view", how does one make a search which encompasses all books? Snark PS: notice that the current addressbook code happily tries to get all contacts, whatever the size of the addressbook -- and even not asynchronously! From jpuydt@free.fr Sat Jun 17 03:08:50 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 27E423B03CB for ; Sat, 17 Jun 2006 03:08:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11317-07 for ; Sat, 17 Jun 2006 03:08:48 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 068E83B00DE for ; Sat, 17 Jun 2006 03:08:47 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-57-82-249-55-125.adsl.proxad.net [82.249.55.125]) by smtp1-g19.free.fr (Postfix) with ESMTP id CE8E69AA70 for ; Sat, 17 Jun 2006 09:07:34 +0200 (CEST) Message-ID: <4493AA32.5030602@free.fr> Date: Sat, 17 Jun 2006 09:07:30 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> In-Reply-To: <4492B888.8060206@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.586 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599] X-Spam-Score: -2.586 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 07:08:50 -0000 Julien PUYDT a écrit : > While this organisation doesn't suffer from the problem Éric pointed > out, it has still a problem : how does one just "search" ? I mean, if > your api is "search a book => get a view", how does one make a search > which encompasses all books? Ok, I think I'm on something : let's a book have a simple api, where on one side: 1) a book can return a view for itself, which means the view becomes specific, and hence can handle the case of big addressbooks ; 2) a full search function, which will return a new book, restricted to the the search ; again this book has its view, which will handle the case of big searches ; 3) a restricted search function, which will return say at most a hundred contacts matching the string ; this one allows to make a search on all the books, since we are assured we won't be drowned by the number. This organisation would allow a clean approach for the view on a single addressbook, while still having the possibility to have a working "Find a contact" button. Does that looks nicer ? Snark From ebischoff@nerim.net Sat Jun 17 05:24:05 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id ACD5F3B038B for ; Sat, 17 Jun 2006 05:24:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15888-07 for ; Sat, 17 Jun 2006 05:24:02 -0400 (EDT) Received: from kellthuzad.dmz.nerim.net (smtp-dmz-236-saturday.dmz.nerim.net [195.5.254.236]) by menubar.gnome.org (Postfix) with ESMTP id 2C81F3B0809 for ; Sat, 17 Jun 2006 05:24:01 -0400 (EDT) Received: from kraid.nerim.net (smtp-106-saturday.nerim.net [62.4.16.106]) by kellthuzad.dmz.nerim.net (Postfix) with ESMTP id 9BD1139D6B for ; Sat, 17 Jun 2006 11:23:14 +0200 (CEST) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 5A4A940E35 for ; Sat, 17 Jun 2006 11:22:48 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Sat, 17 Jun 2006 11:22:59 +0200 User-Agent: KMail/1.8.2 References: <4491205F.5070708@free.fr> <200606152026.49639.ebischoff@nerim.net> <4491C708.3060203@free.fr> In-Reply-To: <4491C708.3060203@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606171123.00082.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.51 tagged_above=-999 required=2 tests=[AWL=0.089, BAYES_00=-2.599] X-Spam-Score: -2.51 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 09:24:05 -0000 Le Jeudi 15 Juin 2006 22:46, Julien PUYDT a =C3=A9crit=C2=A0: > > OK. So that should not be a requirement, and certainly not a mechanism = at > > the core of the system. Just a nice plus. > > It *must* be at the core of the system. We _do_ want to update the live > data when it changes. Sorry, that was not clear. By "at the core" I meant "necessary for the addr= ess=20 books to work". > > Yes. You could have a few spare contacts before and after the user's > > view. This algorithm is rather common. > > What do "before" and "after" mean ? Records just before and after the ones that are displayed in sequential ord= er. > > I know that it cannot be _that_ bad and that I certainly misunderstood > > something. But what? > > I certainly have issues with big books, and must find some satisfying > way to handle them. But doing function calls to walk on a list where I > could get the list and walk it myself directly, is definitely wrong. What is wrong is to see that as a list ;-). > Most operations are sequential when the book is static. When your > contacts go online/offline/whatever, that certainly is random access, > and I can tell you a first/current/next approach doesn't fly in such a > situation. I would not say "not fly" but it certainly becomes much more acrobatic, I=20 agree. > If I add a new addressbook type with a Foo capability, your designs says > I have to modify the base class and add: > > bool canDoFoo (); > void pleaseDoFooThisWay (...); > void pleaseDoFooThisOtherWay (...); > void etcFoo (...) > (with all the virtual pure syntactic crap needed) This "crap" is a lightweight modification since it is only one function=20 declaration. No implementation. That is done in the subclasses, if necessar= y. > My idea of right design is that if the new addressbook is the only one > needing Foo, it will handle it himself (through a specific api that its > view and controller will know and use). Okay. Perharps the our differences in opinion is not that much on the=20 programming design, but more on what the software has to do. To me, an address book is just an address book, they are not that different= =20 one from the other. Ekiga need to dig through them to show names, categorie= s=20 and to pick up SIP numbers to call the people. I see a relatively homogeneo= us=20 user interface, with more or less the same appearance (if not exactly the=20 same) for the various address books. I have a "unifying" vision. To you, all address books have very strong pecularities and the software ha= s=20 to adapt a lot to each of them, to take them to the maximum of their=20 possibilities. The user will get different display, different menues, and=20 even different functionality. That explains why you want to put everything in the "drivers", while I want= to=20 put a lot of common logic in the "engine". > > I think that we are both wrong here ;-). An address book could be big > > (which you underestimated), and it could be moving (which I > > underestimated). > > I agree I have issues seeing how to do things *properly* with a very > large addressbook. Yes, and I have certainly underestimated the "dynamic" aspect :-(. > Your view isn't OO, and isn't C++. Come on ;-). > You see functions named "methods" stuffed into the same poor base class, No. Again and again, the base class only has declarations. It sees an=20 abstraction of what the address book is. In every C++ book, you can see examples like this class vehicle { virtual void accelerate(int a) =3D 0; ... }; class car : public vehicle { virtual void accelerate(int a); ... }; class plane : public vehicle { virtual void accelerate(int a); ... }; Planes and cars have very different ways to accelerate. Planes can't brake = and=20 cars can't fly, but such designs are clean and very popular. > Well, at least we both agree I don't handle the case of very large > addressbooks very well :-/ Yes, this discussion is not pointless :-). And at the end if you are more comfortable with libraries of C functions th= an=20 with subclassing and virtual functions, it's no problem. After all, it's yo= u=20 who are going to be doing the dirty work (and I think we all thank you for= =20 that!). =2D-=20 Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m=C3=A9dire." (Le concombre masqu=C3=A9, Mandriva) From jpuydt@free.fr Sat Jun 17 15:09:04 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2976B3B0144 for ; Sat, 17 Jun 2006 15:09:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04217-02 for ; Sat, 17 Jun 2006 15:08:59 -0400 (EDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by menubar.gnome.org (Postfix) with ESMTP id BC2893B019D for ; Sat, 17 Jun 2006 15:07:46 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-c.free.fr (Postfix) with ESMTP id 4C9DC1D0C42D for ; Sat, 17 Jun 2006 20:06:22 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-57-82-249-55-125.adsl.proxad.net [82.249.55.125]) by smtp5-g19.free.fr (Postfix) with ESMTP id B65BC26C83 for ; Sat, 17 Jun 2006 21:05:51 +0200 (CEST) Message-ID: <4494528F.2040804@free.fr> Date: Sat, 17 Jun 2006 21:05:51 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <200606152026.49639.ebischoff@nerim.net> <4491C708.3060203@free.fr> <200606171123.00082.ebischoff@nerim.net> In-Reply-To: <200606171123.00082.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.584 tagged_above=-999 required=2 tests=[AWL=0.015, BAYES_00=-2.599] X-Spam-Score: -2.584 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 19:09:04 -0000 Éric Bischoff a écrit : >>> Yes. You could have a few spare contacts before and after the user's >>> view. This algorithm is rather common. >> What do "before" and "after" mean ? > > Records just before and after the ones that are displayed in sequential order. Sequential hurts. >>> I know that it cannot be _that_ bad and that I certainly misunderstood >>> something. But what? >> I certainly have issues with big books, and must find some satisfying >> way to handle them. But doing function calls to walk on a list where I >> could get the list and walk it myself directly, is definitely wrong. > > What is wrong is to see that as a list ;-). Indeed. >> If I add a new addressbook type with a Foo capability, your designs says >> I have to modify the base class and add: >> >> bool canDoFoo (); >> void pleaseDoFooThisWay (...); >> void pleaseDoFooThisOtherWay (...); >> void etcFoo (...) >> (with all the virtual pure syntactic crap needed) > > This "crap" is a lightweight modification since it is only one function > declaration. No implementation. That is done in the subclasses, if necessary. Notice that I used "crap" to describe the syntactic need in C++ to add "virtual" and "= 0" everywhere. And your "lightweight modification" still involves modifying the base class anytime a child class needs something! >> My idea of right design is that if the new addressbook is the only one >> needing Foo, it will handle it himself (through a specific api that its >> view and controller will know and use). > > Okay. Perharps the our differences in opinion is not that much on the > programming design, but more on what the software has to do. > > To me, an address book is just an address book, they are not that different > one from the other. Ekiga need to dig through them to show names, categories > and to pick up SIP numbers to call the people. I see a relatively homogeneous > user interface, with more or less the same appearance (if not exactly the > same) for the various address books. I have a "unifying" vision. > > To you, all address books have very strong pecularities and the software has > to adapt a lot to each of them, to take them to the maximum of their > possibilities. The user will get different display, different menues, and > even different functionality. Well, look at what we have to put already in the addressbooks: - evolution-data-server addressbooks ; - avahi contacts ; - history contacts ; - speeddials. And the future holds : - SIP contacts ; - XMPP contacts. > That explains why you want to put everything in the "drivers", while I want to > put a lot of common logic in the "engine". Your high level is what I call low level : it handles all of the details! >> Your view isn't OO, and isn't C++. > > Come on ;-). > >> You see functions named "methods" stuffed into the same poor base class, > > No. Again and again, the base class only has declarations. It sees an > abstraction of what the address book is. You're still stuffing that in the base class, which is awful. Does the QWidget class have all the methods of all its child already declared? > In every C++ book, you can see examples like this > > class vehicle { > virtual void accelerate(int a) = 0; > ... > }; > > class car : public vehicle { > virtual void accelerate(int a); > ... > }; > > class plane : public vehicle { > virtual void accelerate(int a); > ... > }; > Planes and cars have very different ways to accelerate. Planes can't brake and > cars can't fly, but such designs are clean and very popular. They all accelerate, and that is the reason why having an accelerate method is put as a requirement in the base class. Anyway I since made another proposition which I find neater ; I'm eagerly waiting for your comments on it :-) Snark From siti@orcon.net.nz Sat Jun 17 16:21:14 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 166443B02D7 for ; Sat, 17 Jun 2006 16:21:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06960-02 for ; Sat, 17 Jun 2006 16:21:11 -0400 (EDT) Received: from dbmail-mx3.orcon.co.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 420E03B0769 for ; Sat, 17 Jun 2006 16:21:10 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx3.orcon.co.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k5HKBcBi027983 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 18 Jun 2006 08:11:39 +1200 From: Stephen Cook To: GnomeMeeting development mailing list Content-Type: text/plain Date: Sun, 18 Jun 2006 08:11:38 +1200 Message-Id: <1150575098.10433.5.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx3.orcon.co.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.484 tagged_above=-999 required=2 tests=[AWL=-0.020, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.484 X-Spam-Level: Subject: [GnomeMeeting-devel-list] IAX2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 20:21:14 -0000 Hello, It's been a long time I gave you guys an update. In IAX2 in opal I have got music on hold going which is nice :). I will be doing registration next as this is probably the most important feature for users. Also I have not run in to any stability problems with IAX2. My iax2/ekiga integration is working well as a tester with my asterisk server. It basically has all the functionality there but needs more integration and bug/quirky fixes. Also some refactoring in the future would be nice depending if I get time or not... From jan.schampera@web.de Sat Jun 17 23:26:05 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 973DD3B0089 for ; Sat, 17 Jun 2006 23:26:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21686-02 for ; Sat, 17 Jun 2006 23:26:04 -0400 (EDT) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by menubar.gnome.org (Postfix) with ESMTP id 718E83B0080 for ; Sat, 17 Jun 2006 23:26:04 -0400 (EDT) Received: from fwd28.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1Frm9f-0005mL-03; Sun, 18 Jun 2006 03:32:47 +0200 Received: from mail.home.thebonsai.de (Ee3Yp-Z-ge9I5Mahsz3ULnxaW3DaPSfdXF9f7jCM5sjCj+WYBVPHwg@[84.147.75.32]) by fwd28.sul.t-online.de with esmtp id 1Frm9c-1vtsA40; Sun, 18 Jun 2006 03:32:44 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id 610F16B154 for ; Sun, 18 Jun 2006 03:32:43 +0200 (CEST) Date: Sun, 18 Jun 2006 03:32:42 +0200 From: Jan Schampera To: gnomemeeting-devel-list@gnome.org Message-ID: <20060618033242.5cce3d15@localhost.localdomain> In-Reply-To: <4493AA32.5030602@free.fr> References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> <4493AA32.5030602@free.fr> Organization: private X-Mailer: Sylpheed-Claws 2.2.0 (GTK+ 2.8.18; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: Ee3Yp-Z-ge9I5Mahsz3ULnxaW3DaPSfdXF9f7jCM5sjCj+WYBVPHwg@t-dialin.net X-TOI-MSGID: d12d82d7-adb7-47a8-a0ce-a3a4ced5117e X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.982 tagged_above=-999 required=2 tests=[AWL=0.616, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.982 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 03:26:05 -0000 On Sat, 17 Jun 2006 09:07:30 +0200 Julien PUYDT wrote: > 1) a book can return a view for itself, which means the view becomes > specific, and hence can handle the case of big addressbooks ; And which view would such a book return by default? > 2) a full search function, which will return a new book, restricted > to the the search ; again this book has its view, which will handle > the case of big searches ; ACK > 3) a restricted search function, which will return say at most a > hundred contacts matching the string ; this one allows to make a > search on all the books, since we are assured we won't be drowned by > the number. > Does that looks nicer ? Yip. J. -- God is real... unless declared as integer. From jpuydt@free.fr Sun Jun 18 06:22:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8B7533B09FC for ; Sun, 18 Jun 2006 06:22:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18409-03 for ; Sun, 18 Jun 2006 06:22:08 -0400 (EDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by menubar.gnome.org (Postfix) with ESMTP id 03CAF3B0956 for ; Sun, 18 Jun 2006 06:22:07 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-c.free.fr (Postfix) with ESMTP id B13A21D0A67F for ; Sun, 18 Jun 2006 11:20:11 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-30-82-253-152-157.adsl.proxad.net [82.253.152.157]) by smtp5-g19.free.fr (Postfix) with ESMTP id 8697F270B8 for ; Sun, 18 Jun 2006 12:19:37 +0200 (CEST) Message-ID: <449528BF.3020104@free.fr> Date: Sun, 18 Jun 2006 12:19:43 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> <4493AA32.5030602@free.fr> <20060618033242.5cce3d15@localhost.localdomain> In-Reply-To: <20060618033242.5cce3d15@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 10:22:10 -0000 Jan Schampera a écrit : >> 1) a book can return a view for itself, which means the view becomes >> specific, and hence can handle the case of big addressbooks ; > And which view would such a book return by default? No default view. I think there should be a GmFullBook class (from which all books which can be displayed fully), and an associated GmFullBookView class, which would then be default for the children. >> Does that looks nicer ? > Yip. Nice. I'm writing some code to showcase things... may take long since I lack time those days :-/ Snark From dsandras@seconix.com Sun Jun 18 15:32:22 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 425673B0114 for ; Sun, 18 Jun 2006 15:32:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08600-02 for ; Sun, 18 Jun 2006 15:32:19 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 178373B0009 for ; Sun, 18 Jun 2006 15:32:18 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id EF61583C26 for ; Sun, 18 Jun 2006 21:11:21 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03870-02 for ; Sun, 18 Jun 2006 21:11:15 +0200 (CEST) Received: from [192.168.0.161] (206-158.242.81.adsl.skynet.be [81.242.158.206]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 657C683C23 for ; Sun, 18 Jun 2006 21:11:15 +0200 (CEST) From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <1150575098.10433.5.camel@siti> References: <1150575098.10433.5.camel@siti> Content-Type: text/plain; charset=ISO-8859-15 Date: Sun, 18 Jun 2006 21:31:27 +0200 Message-Id: <1150659087.2477.3.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.256 tagged_above=-999 required=2 tests=[AWL=0.208, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.256 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] IAX2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 19:32:22 -0000 Le dimanche 18 juin 2006 à 08:11 +1200, Stephen Cook a écrit : > Hello, > > It's been a long time I gave you guys an update. > > In IAX2 in opal I have got music on hold going which is nice :). I will > be doing registration next as this is probably the most important > feature for users. Also I have not run in to any stability problems > with IAX2. > > My iax2/ekiga integration is working well as a tester with my asterisk > server. It basically has all the functionality there but needs more > integration and bug/quirky fixes. Also some refactoring in the future > would be nice depending if I get time or not... Hi, I've seen Derek committed some code from you. I think it is important that you keep a repository with your patches so that we really know what you have fixed/added for Google SoC. (Actually, I should see the patches, even though it is perfectly acceptable that Derek commits them). Thank you, -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From gcgagd-gnomemeeting-devel-list@m.gmane.org Sun Jun 18 16:15:08 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8DDA23B0114 for ; Sun, 18 Jun 2006 16:15:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09248-09 for ; Sun, 18 Jun 2006 16:15:07 -0400 (EDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by menubar.gnome.org (Postfix) with ESMTP id 662BD3B00B2 for ; Sun, 18 Jun 2006 16:15:07 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Fs3eO-0006gT-LO for gnomemeeting-devel-list@gnome.org; Sun, 18 Jun 2006 22:13:40 +0200 Received: from jupiter.physics.ubc.ca ([142.103.234.78]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Jun 2006 22:13:40 +0200 Received: from johan_brn by jupiter.physics.ubc.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Jun 2006 22:13:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gnomemeeting-devel-list@gnome.org From: Johan Brannlund Date: Sun, 18 Jun 2006 13:13:29 -0700 Lines: 22 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: jupiter.physics.ubc.ca User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux)) Sender: news X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.752 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_YAHOO_RCVD=1.849, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.752 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Main window size X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 20:15:08 -0000 I posted the below as a wishlist bug, but apparently the developers prefer carrying out the discussion on this mailing list. This is what I wrote: "I just tried the 20060615 cvs snapshot of ekiga, and it's getting better all the time. I have a small request though: I don't use video, which means that the main window is much bigger than it has to be. Would it be possible to add a resizing widget, or to automatically make the window smaller when video is disabled?" Damien also added the following comment: "I would also say that it will look less bigger when having a contacts list. :) " ... which I don't quite understand. At least in my snapshot, the contacts are in a separate window. Regards, Johan From siti@orcon.net.nz Sun Jun 18 21:23:06 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 415B73B0387 for ; Sun, 18 Jun 2006 21:23:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18559-06 for ; Sun, 18 Jun 2006 21:23:01 -0400 (EDT) Received: from dbmail-mx2.orcon.net.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 66E1B3B0196 for ; Sun, 18 Jun 2006 21:23:01 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx2.orcon.net.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k5J1Lujn017301 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 19 Jun 2006 13:21:57 +1200 From: Stephen Cook To: GnomeMeeting development mailing list In-Reply-To: <1150659087.2477.3.camel@golgoth01> References: <1150575098.10433.5.camel@siti> <1150659087.2477.3.camel@golgoth01> Content-Type: text/plain; charset=utf-8 Date: Mon, 19 Jun 2006 13:21:55 +1200 Message-Id: <1150680115.31741.1.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx2.orcon.net.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.547 tagged_above=-999 required=2 tests=[AWL=0.052, BAYES_00=-2.599] X-Spam-Score: -2.547 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] IAX2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 01:23:06 -0000 On Sun, 2006-06-18 at 21:31 +0200, Damien Sandras wrote: > Le dimanche 18 juin 2006 à 08:11 +1200, Stephen Cook a écrit : > > Hello, > > > > It's been a long time I gave you guys an update. > > > > In IAX2 in opal I have got music on hold going which is nice :). I will > > be doing registration next as this is probably the most important > > feature for users. Also I have not run in to any stability problems > > with IAX2. > > > > My iax2/ekiga integration is working well as a tester with my asterisk > > server. It basically has all the functionality there but needs more > > integration and bug/quirky fixes. Also some refactoring in the future > > would be nice depending if I get time or not... > > Hi, > > > I've seen Derek committed some code from you. > > I think it is important that you keep a repository with your patches so > that we really know what you have fixed/added for Google SoC. > (Actually, I should see the patches, even though it is perfectly > acceptable that Derek commits them). I'll try and get you to review them first. I'll also put the patches on my website and give you guys a link soon. > > Thank you, From jpuydt@free.fr Mon Jun 19 01:26:43 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E9CF83B09E1 for ; Mon, 19 Jun 2006 01:26:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25898-10 for ; Mon, 19 Jun 2006 01:26:41 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 737143B03C7 for ; Mon, 19 Jun 2006 01:26:41 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-60-82-254-197-114.adsl.proxad.net [82.254.197.114]) by smtp1-g19.free.fr (Postfix) with ESMTP id C5B1D10170 for ; Mon, 19 Jun 2006 07:25:07 +0200 (CEST) Message-ID: <44963539.6080309@free.fr> Date: Mon, 19 Jun 2006 07:25:13 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.567 tagged_above=-999 required=2 tests=[AWL=0.032, BAYES_00=-2.599] X-Spam-Score: -2.567 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Main window size X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 05:26:43 -0000 Johan Brannlund a écrit : > I posted the below as a wishlist bug, but apparently the developers prefer > carrying out the discussion on this mailing list. This is what I wrote: Well, bug reports are nice for a beta or a stable release ; during the development cycle, discussing on the -devel- mailing-list is better (especially right at the beginning). :-) > "I just tried the 20060615 cvs snapshot of ekiga, and it's getting better > all the time. I have a small request though: I don't use video, which > means that the main window is much bigger than it has to be. > > Would it be possible to add a resizing widget, or to automatically make the > window smaller when video is disabled?" > > Damien also added the following comment: > > "I would also say that it will look less bigger when having a contacts > list. :) " > > ... which I don't quite understand. At least in my snapshot, the contacts > are in a separate window. He means that you should see some of your contacts in the main window in the future, with presence information about them. Snark From dsandras@seconix.com Mon Jun 19 04:55:21 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 539283B00A5 for ; Mon, 19 Jun 2006 04:55:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01183-02 for ; Mon, 19 Jun 2006 04:55:13 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id CCC843B0004 for ; Mon, 19 Jun 2006 04:55:11 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id D5FC083C1F for ; Mon, 19 Jun 2006 10:34:14 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32316-06 for ; Mon, 19 Jun 2006 10:34:11 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 694B183C1A for ; Mon, 19 Jun 2006 10:34:11 +0200 (CEST) From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44963539.6080309@free.fr> References: <44963539.6080309@free.fr> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 19 Jun 2006 10:54:04 +0200 Message-Id: <1150707244.2904.2.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Main window size X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 08:55:21 -0000 Le lundi 19 juin 2006 à 07:25 +0200, Julien PUYDT a écrit : > Johan Brannlund a écrit : > > I posted the below as a wishlist bug, but apparently the developers prefer > > carrying out the discussion on this mailing list. This is what I wrote: > > Well, bug reports are nice for a beta or a stable release ; during the > development cycle, discussing on the -devel- mailing-list is better > (especially right at the beginning). :-) > Yes, because it is a work in progress. So it will change with time, and get improved. No worries :) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From firstone5@hotmail.com Wed Jun 21 13:09:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C9A9D3B02A4 for ; Wed, 21 Jun 2006 13:09:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23702-03 for ; Wed, 21 Jun 2006 13:09:09 -0400 (EDT) Received: from hotmail.com (bay101-f15.bay101.hotmail.com [64.4.56.25]) by menubar.gnome.org (Postfix) with ESMTP id C2B763B01C1 for ; Wed, 21 Jun 2006 13:09:09 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Jun 2006 10:09:08 -0700 Message-ID: Received: from 64.4.56.200 by by101fd.bay101.hotmail.msn.com with HTTP; Wed, 21 Jun 2006 17:09:07 GMT X-Originating-IP: [69.245.3.192] X-Originating-Email: [firstone5@hotmail.com] X-Sender: firstone5@hotmail.com From: "M. Renee Hopkins" To: gnomemeeting-devel-list@gnome.org Date: Wed, 21 Jun 2006 17:09:07 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 21 Jun 2006 17:09:08.0863 (UTC) FILETIME=[68BD40F0:01C69555] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=0.607 tagged_above=-999 required=2 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: 0.607 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Mingw build of CVS ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:09:11 -0000 Greetings all, I am now building ekiga from cvs with the mingw tools on linux with some success, thanks to help from the list developers and patches. Most all features seem to be working. However, my builds don't detect the videoforwindows devices even though other ekiga.exe (not mine) versions correctly see the camera. Any ideas for missing switches on compile before I began greping through pwlib? I'm rather new to the code so any help is appreciated. Congrads to all developers on great work, MR From dsandras@seconix.com Wed Jun 21 13:42:37 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C742A3B05E9 for ; Wed, 21 Jun 2006 13:42:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25791-05 for ; Wed, 21 Jun 2006 13:42:36 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 0647C3B00B0 for ; Wed, 21 Jun 2006 13:42:35 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id AC0EF83C1C for ; Wed, 21 Jun 2006 19:22:12 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05950-02 for ; Wed, 21 Jun 2006 19:22:11 +0200 (CEST) Received: from [192.168.0.161] (185.1-247-81.adsl-dyn.isp.belgacom.be [81.247.1.185]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id C5DD783C1B for ; Wed, 21 Jun 2006 19:22:10 +0200 (CEST) From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-15 Date: Wed, 21 Jun 2006 19:43:29 +0200 Message-Id: <1150911809.2537.7.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.461 tagged_above=-999 required=2 tests=[AWL=0.003, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.461 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Mingw build of CVS ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:42:38 -0000 Le mercredi 21 juin 2006 à 17:09 +0000, M. Renee Hopkins a écrit : > Greetings all, > > I am now building ekiga from cvs with the mingw tools on linux with some > success, thanks to help from the list developers and patches. > > Most all features seem to be working. However, my builds don't detect the > videoforwindows devices even though other ekiga.exe (not mine) versions > correctly see the camera. > > Any ideas for missing switches on compile before I began greping through > pwlib? > I'm not an expert of the win32 build, but the first guess would be that the pwlib plugins are not compiled in. > I'm rather new to the code so any help is appreciated. > > Congrads to all developers on great work, > MR > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From tonim@telefonica.net Wed Jun 28 04:13:24 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9083D3B0079 for ; Wed, 28 Jun 2006 04:13:24 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31830-06 for ; Wed, 28 Jun 2006 04:13:23 -0400 (EDT) Received: from lothlorienng.sisman.info (157.Red-83-58-24.dynamicIP.rima-tde.net [83.58.24.157]) by menubar.gnome.org (Postfix) with ESMTP id C1F293B0002 for ; Wed, 28 Jun 2006 04:13:22 -0400 (EDT) Received: from gandalf.sisman.info (gandalf.sisman.info [192.168.16.201]) by lothlorienng.sisman.info (Postfix) with ESMTP id B33D71D8437 for ; Wed, 28 Jun 2006 08:18:54 +0200 (CEST) From: Toni Moreno To: gnomemeeting-devel-list@gnome.org In-Reply-To: <1150680115.31741.1.camel@siti> References: <1150575098.10433.5.camel@siti> <1150659087.2477.3.camel@golgoth01> <1150680115.31741.1.camel@siti> Content-Type: text/plain Date: Wed, 28 Jun 2006 08:09:46 +0200 Message-Id: <1151474986.5988.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: Yes, score=2.597 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046, SPF_NEUTRAL=1.069] X-Spam-Score: 2.597 X-Spam-Level: ** X-Spam-Flag: YES Subject: [GnomeMeeting-devel-list] A bit OFF-TOPIC, but usefull X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 08:13:24 -0000 I have found a report of skype, which shows the huge network activity it has (apart from voice network usage). Interesting to pinpoint differences between Skype & Ekiga, or other VoIP hardware phones. Enjoy, and excuse me the off-topic. http://www.ja.net/development/voip/skype&janet.pdf -- Toni Moreno From lurch@gmx.li Thu Jun 29 03:50:09 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A67023B011E for ; Thu, 29 Jun 2006 03:50:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26540-04 for ; Thu, 29 Jun 2006 03:50:02 -0400 (EDT) Received: from asclepius.uwa.edu.au (unknown [130.95.128.56]) by menubar.gnome.org (Postfix) with ESMTP id 6733A3B04C2 for ; Thu, 29 Jun 2006 03:50:01 -0400 (EDT) Received: from asclepius.kas (localhost.localdomain [127.0.0.1]) by asclepius.uwa.edu.au (Postfix) with SMTP id E6028183A6F for ; Thu, 29 Jun 2006 15:49:45 +0800 (WST) Received: from asclepius (localhost.localdomain [127.0.0.1]) by asclepius.prekas (Postfix) with SMTP id CC7321841AD for ; Thu, 29 Jun 2006 15:49:45 +0800 (WST) X-UWA-Client-IP: 130.95.28.15 (UWA) Received: from ns1.watri.uwa.edu.au (ns1.watri.org.au [130.95.28.15]) by asclepius.extinput (Postfix) with ESMTP id B3012183CC9 for ; Thu, 29 Jun 2006 15:49:45 +0800 (WST) Received: from [130.95.29.76] (gluttony.watri.org.au [130.95.29.76]) by ns1.watri.uwa.edu.au (8.13.1/8.13.1) with ESMTP id k5T7nflM013861 for ; Thu, 29 Jun 2006 15:49:44 +0800 (WST) Message-ID: <44A386D4.8040708@gmx.li> Date: Thu, 29 Jun 2006 15:52:52 +0800 From: =?ISO-8859-1?Q?Stefan_Br=FCns?= User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <200606081002.37875.conrad_videokonferenz@gmx.de> <1150380224.6599.22.camel@ganymede.verfaction.de> In-Reply-To: <1150380224.6599.22.camel@ganymede.verfaction.de> Content-Type: multipart/mixed; boundary="------------030008030501050603080306" X-SpamTest-Info: Profile: Formal (405/060628) X-SpamTest-Info: Profile: Detect Hard [UCS 290904] X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking Spam - Subject (UCS) [02-08-04] X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.358 tagged_above=-999 required=2 tests=[AWL=-0.036, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142] X-Spam-Score: -1.358 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 07:50:09 -0000 This is a multi-part message in MIME format. --------------030008030501050603080306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> The last version I can install using apt-get a couple of days old (May 25 - or >> somethin) - at least this is a version with the nonfunctional German locale. >> (defaults to English) >> >> What's up? > > > /me is having a sheer lack of time and thus it took me a while to get > everything polished and fixed just like i love to have it. =) > Everything should be back to normal as of tonight (eventually sarge cvs > snaps and win32 will remain for the weekend - we'll see) I think I have found the problem with the missing tranlations - it is caused by the recent change from the ALL_LINGUAS variable to the po/LINGUAS file. Patch attached. @Kilian: can you try the patch and submit it upstream, if successfull? Lurchi --------------030008030501050603080306 Content-Type: text/plain; name="configure_in_fix_all_linguas.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="configure_in_fix_all_linguas.diff" --- configure.in_orig 2006-06-29 07:59:40.000000000 +0200 +++ configure.in 2006-06-29 09:10:08.000000000 +0200 @@ -527,7 +527,8 @@ dnl Support for internationalization dnl ######################################################################## AC_SUBST([CONFIG_STATUS_DEPENDENCIES],['$(top_srcdir)/po/LINGUAS']) -ALL_LINGUAS="`grep -v '^#' "$srcdir/po/LINGUAS"`" +# ALL_LINGUAS="`grep -v '^#' "$srcdir/po/LINGUAS"`" +ALL_LINGUAS="`sed -ne '/\#.*/ d; H; $ {x; s/^\\n//g; s/\\n/ /g; p}' "$srcdir/po/LINGUAS"`" GETTEXT_PACKAGE=AC_PACKAGE_NAME AC_SUBST(GETTEXT_PACKAGE) --------------030008030501050603080306-- From jpuydt@free.fr Thu Jun 29 06:15:38 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0617C3B050F for ; Thu, 29 Jun 2006 06:15:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03057-05 for ; Thu, 29 Jun 2006 06:15:36 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 17C0C3B02CE for ; Thu, 29 Jun 2006 06:15:36 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-61-82-250-109-134.adsl.proxad.net [82.250.109.134]) by smtp5-g19.free.fr (Postfix) with ESMTP id 08B3E27766 for ; Thu, 29 Jun 2006 12:15:34 +0200 (CEST) Message-ID: <44A3A865.7000201@free.fr> Date: Thu, 29 Jun 2006 12:16:05 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <200606081002.37875.conrad_videokonferenz@gmx.de> <1150380224.6599.22.camel@ganymede.verfaction.de> <44A386D4.8040708@gmx.li> In-Reply-To: <44A386D4.8040708@gmx.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.596 tagged_above=-999 required=2 tests=[AWL=0.003, BAYES_00=-2.599] X-Spam-Score: -2.596 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 10:15:38 -0000 Stefan Brüns a écrit : > @Kilian: can you try the patch and submit it upstream, if successfull? You can call me "Snark", you know ;-) Snark From jpuydt@free.fr Thu Jun 29 06:20:46 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5F2F33B0286 for ; Thu, 29 Jun 2006 06:20:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03470-04 for ; Thu, 29 Jun 2006 06:20:45 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 5A2F43B01CE for ; Thu, 29 Jun 2006 06:20:45 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-61-82-250-109-134.adsl.proxad.net [82.250.109.134]) by smtp5-g19.free.fr (Postfix) with ESMTP id 4DBBF2765B for ; Thu, 29 Jun 2006 12:20:44 +0200 (CEST) Message-ID: <44A3A99B.8030605@free.fr> Date: Thu, 29 Jun 2006 12:21:15 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <200606081002.37875.conrad_videokonferenz@gmx.de> <1150380224.6599.22.camel@ganymede.verfaction.de> <44A386D4.8040708@gmx.li> <44A3A865.7000201@free.fr> In-Reply-To: <44A3A865.7000201@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.596 tagged_above=-999 required=2 tests=[AWL=0.003, BAYES_00=-2.599] X-Spam-Score: -2.596 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 10:20:46 -0000 Julien PUYDT a écrit : > Stefan Brüns a écrit : >> @Kilian: can you try the patch and submit it upstream, if successfull? > > You can call me "Snark", you know ;-) Hmmmm... which "upstream" are we talking about ? :-) /me should read before answering ;-) Snark From dsandras@seconix.com Thu Jun 1 02:40:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F28C93B00EB for ; Thu, 1 Jun 2006 02:40:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10407-03 for ; Thu, 1 Jun 2006 02:40:07 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 9FA173B00CB for ; Thu, 1 Jun 2006 02:40:06 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id DE1A2496FC for ; Thu, 1 Jun 2006 08:23:55 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15636-08 for ; Thu, 1 Jun 2006 08:23:54 +0200 (CEST) Received: from [172.16.100.156] (tcts.fpms.ac.be [193.190.194.194]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 0CBC0496FB for ; Thu, 1 Jun 2006 08:23:54 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <447DF183.3090300@cs.stanford.edu> References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-15 Date: Thu, 01 Jun 2006 08:41:01 +0200 Message-Id: <1149144061.2457.4.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 06:40:10 -0000 Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > I'd imagine it would work on win32, but don't know. > Probably. > I'll work on the patches. > > Where's the right place to add required libraries like openGL? In configure.in. > configure.in seems to be autogenerated by something, but whatever it is > doesn't seem to be in the CVS snapshot... > configure.in is in the CVS snapshot. > Thanks, > > -Dan > > Julien PUYDT wrote: > > > Dan Sandberg a écrit : > > > >> How should we proceed? I could just send you an updated gui/main.cpp > >> file... > > > > > > I'd like to see patches instead of full files, preferably independant > > on each others. > > > > There's also the question of the portability of this : since you > > mention SDL, I guess this will work great on win32 too ? > > > > Snark > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From hoglet@solit.se Thu Jun 1 09:09:47 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 90B2B3B017F for ; Thu, 1 Jun 2006 09:09:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04710-03 for ; Thu, 1 Jun 2006 09:09:45 -0400 (EDT) Received: from aurian.solit.se (unknown [82.182.216.174]) by menubar.gnome.org (Postfix) with ESMTP id 63B703B0134 for ; Thu, 1 Jun 2006 09:09:45 -0400 (EDT) Received: from ip76.kassjo.se ([85.11.28.76] helo=localhost.localdomain) by aurian.solit.se with asmtp (Exim 3.35 #1 (Debian)) id 1Flmvj-0004Et-00 for ; Thu, 01 Jun 2006 15:09:39 +0200 Date: Thu, 1 Jun 2006 15:09:38 +0200 From: Kent Asplund To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Re: Ekiga branched Message-Id: <20060601150938.fcdea791.hoglet@solit.se> In-Reply-To: <1148209984.2488.26.camel@golgoth01> References: <1147894199.7225.2.camel@golgoth01> <1148207277.6654.0.camel@frobisher.madeley.id.au> <1148209984.2488.26.camel@golgoth01> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: ej spam, SpamAssassin (resultat=-4.4, krav 5, IN_REP_TO -4.43) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.832 tagged_above=-999 required=2 tests=[AWL=-0.510, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142] X-Spam-Score: -1.832 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:09:47 -0000 --Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 21 May 2006 13:13:04 +0200 Damien Sandras wrote: > Le dimanche 21 mai 2006 =E0 18:27 +0800, Davyd Madeley a =E9crit : > > On Wed, 2006-05-17 at 21:29 +0200, Damien Sandras wrote: > >=20 > > > I have created a new branch named "gnome-2-14" for Ekiga from the > > > current CVS HEAD. > >=20 > > What are your exciting plans for the next Ekiga? > >=20 >=20 > Most of the plans are on http://wiki.ekiga.org, but I would summarize it > by those big features : > - New user interface I have some problems selling Ekiga to my wife an mother-in-law because it lacks the list of contacts you are about to implement. Another detail is the "contact" button that they did not see as intuitive. Exchanging the button to a green phone handle (red when calling in progress) would make it more alike others and therefore easier to accept. Greetings /Kent --=20 Killing time murders opportunities. --Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEfucS4WZLcIH5l3kRAm+MAJ95cAJ7mAiuBBLrCdfk7vNFTiLv7ACeKWZd 6tzVdWbow84O8RfCFvm51AU= =lD5w -----END PGP SIGNATURE----- --Signature=_Thu__1_Jun_2006_15_09_38_+0200_R0Yqu0dZHd7XDLUQ-- From jpuydt@free.fr Thu Jun 1 09:20:42 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 792AE3B01C4 for ; Thu, 1 Jun 2006 09:20:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05042-09 for ; Thu, 1 Jun 2006 09:20:38 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 505C93B01E3 for ; Thu, 1 Jun 2006 09:20:37 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-30-82-253-132-170.adsl.proxad.net [82.253.132.170]) by smtp1-g19.free.fr (Postfix) with ESMTP id DA3499ADFF for ; Thu, 1 Jun 2006 15:20:35 +0200 (CEST) Message-ID: <447EE9BE.5030005@free.fr> Date: Thu, 01 Jun 2006 15:21:02 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Re: Ekiga branched References: <1147894199.7225.2.camel@golgoth01> <1148207277.6654.0.camel@frobisher.madeley.id.au> <1148209984.2488.26.camel@golgoth01> <20060601150938.fcdea791.hoglet@solit.se> In-Reply-To: <20060601150938.fcdea791.hoglet@solit.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599] X-Spam-Score: -2.561 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:20:42 -0000 Kent Asplund a écrit : > Exchanging the button to a green phone handle (red when calling in > progress) would make it more alike others and therefore easier to > accept. The classic case of "your flying car lacks a spare wheel!" ;-) Snark From jan.schampera@web.de Thu Jun 1 12:03:48 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B922E3B0E4B for ; Thu, 1 Jun 2006 12:03:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18635-04 for ; Thu, 1 Jun 2006 12:03:47 -0400 (EDT) Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by menubar.gnome.org (Postfix) with ESMTP id EBE813B0E61 for ; Thu, 1 Jun 2006 12:01:39 -0400 (EDT) Received: from fwd29.aul.t-online.de by mailout05.sul.t-online.com with smtp id 1FlpcA-0003xH-07; Thu, 01 Jun 2006 18:01:38 +0200 Received: from mail.home.thebonsai.de (VypBOcZSYex2PaURfsq4FLxwkOKh2FKpRdjn4Nur7iMG3ImbsTH1w4@[84.147.102.147]) by fwd29.sul.t-online.de with esmtp id 1FlpO1-0yxMBM0; Thu, 1 Jun 2006 17:47:01 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id E08C06B173 for ; Thu, 1 Jun 2006 17:47:00 +0200 (CEST) Date: Thu, 1 Jun 2006 17:44:27 +0200 From: Jan Schampera To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode Message-ID: <20060601174427.48266dee@localhost.localdomain> In-Reply-To: <447DE4E2.7040204@cs.stanford.edu> References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> Organization: private X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: VypBOcZSYex2PaURfsq4FLxwkOKh2FKpRdjn4Nur7iMG3ImbsTH1w4@t-dialin.net X-TOI-MSGID: e6494e3b-869b-447f-a832-f769a200d3af X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.942 tagged_above=-999 required=2 tests=[AWL=0.656, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.942 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:03:48 -0000 On Wed, 31 May 2006 11:48:02 -0700 Dan Sandberg wrote: > 2) Replace the SDL/GTK/GDK calls that do the full screen resizing with > OpenGL ones. [ This is done, needs to be integrated ] Guess that's the key I searched for, when I measured those performance problems. Something that is "usually" installed on the user's machines and that has more power then GDK/SDL (I was afraid to raise yet another exotic dependancy, but OpenGL seems fair enough). J. -- "Be liberal in what you accept, and conservative in what you send." - J. B. Postel, master of the net. From siti@orcon.net.nz Fri Jun 2 05:53:55 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5C8803B10AE for ; Fri, 2 Jun 2006 05:53:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15897-03 for ; Fri, 2 Jun 2006 05:53:53 -0400 (EDT) Received: from dbmail-mx4.orcon.co.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 1A8E13B0EB6 for ; Fri, 2 Jun 2006 05:53:52 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx4.orcon.co.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k529rnLs032645 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 2 Jun 2006 21:53:50 +1200 From: Stephen Cook To: GnomeMeeting development mailing list Content-Type: text/plain Date: Fri, 02 Jun 2006 21:55:24 +1200 Message-Id: <1149242124.4509.17.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.2/1506/Fri Jun 2 16:01:20 2006 on dbmail-mx4.orcon.co.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: Subject: [GnomeMeeting-devel-list] IAX2 In Ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 09:53:55 -0000 Hi, I haven't introduced myself here before, I am Stephen Cook (siti). My proposal for implementing IAX2 in ekiga got accepted with google's summer of code. To give an update (I'll try and keep you guys regularly posted as to what's happening, any problems etc.). Currently I have been looking at the code to gain an understanding of ekiga and opal's code and design. Also obviously checking out the IAX2 code in opal :). From what I have seen and got working, I will work on getting IAX2 going in ekiga first. The main part of this will obviously involve writing a gnome meeting endpoint for IAX2. One key problem I have identified is the accounts code. The protocols are tightly integrated with how it works. I could either refactor this code to loosen the integration or hack iax2 support in there and refactor it later ;). The advantage of this refactored will be when someone wants to add Xmpp/libjingle support, or some other protocol down the track. Well, please tell me your thoughts and comments on this project. -Stephen From x@cs.stanford.edu Fri Jun 2 06:04:24 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0CBE83B0EB6 for ; Fri, 2 Jun 2006 06:04:24 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16680-02 for ; Fri, 2 Jun 2006 06:04:22 -0400 (EDT) Received: from smtp102.plus.mail.mud.yahoo.com (smtp102.plus.mail.mud.yahoo.com [68.142.206.235]) by menubar.gnome.org (Postfix) with SMTP id 1A3583B0490 for ; Fri, 2 Jun 2006 06:04:22 -0400 (EDT) Received: (qmail 57482 invoked from network); 2 Jun 2006 10:04:21 -0000 Received: from unknown (HELO ?192.168.2.47?) (dan?sandberg@71.138.128.214 with plain) by smtp102.plus.mail.mud.yahoo.com with SMTP; 2 Jun 2006 10:04:20 -0000 Message-ID: <44800CFA.5090800@cs.stanford.edu> Date: Fri, 02 Jun 2006 03:03:38 -0700 From: Dan Sandberg User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> In-Reply-To: <1149144061.2457.4.camel@golgoth01> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.808 tagged_above=-999 required=2 tests=[AWL=-0.593, BAYES_00=-2.599, SPF_SOFTFAIL=1.384] X-Spam-Score: -1.808 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 10:04:24 -0000 So configure.in is hand-generated? Surprising. 1) How exactly do I add the opengl ( libgl ) library? 2) Xrandr is mentioned in the Makefile, but is not in configure.in. How exactly does it get put into the Makefile? 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I didn't want to code against a moving target. Thanks, -Dan Damien Sandras wrote: >Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > > >>I'd imagine it would work on win32, but don't know. >> >> >> > >Probably. > > > >>I'll work on the patches. >> >>Where's the right place to add required libraries like openGL? >> >> > >In configure.in. > > > >>configure.in seems to be autogenerated by something, but whatever it is >>doesn't seem to be in the CVS snapshot... >> >> >> > >configure.in is in the CVS snapshot. > > > > >>Thanks, >> >>-Dan >> >>Julien PUYDT wrote: >> >> >> >>>Dan Sandberg a écrit : >>> >>> >>> >>>>How should we proceed? I could just send you an updated gui/main.cpp >>>>file... >>>> >>>> >>>I'd like to see patches instead of full files, preferably independant >>>on each others. >>> >>>There's also the question of the portability of this : since you >>>mention SDL, I guess this will work great on win32 too ? >>> >>>Snark >>>_______________________________________________ >>>Gnomemeeting-devel-list mailing list >>>Gnomemeeting-devel-list@gnome.org >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list >>> >>> >>> >>_______________________________________________ >>Gnomemeeting-devel-list mailing list >>Gnomemeeting-devel-list@gnome.org >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list >> >> From dsandras@seconix.com Fri Jun 2 07:06:22 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9B2253B0407 for ; Fri, 2 Jun 2006 07:06:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20694-02 for ; Fri, 2 Jun 2006 07:06:20 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 830933B0490 for ; Fri, 2 Jun 2006 07:06:20 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 3567C4974A for ; Fri, 2 Jun 2006 12:49:55 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03852-06 for ; Fri, 2 Jun 2006 12:49:51 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 5D9BD49749 for ; Fri, 2 Jun 2006 12:49:51 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <1149242124.4509.17.camel@siti> References: <1149242124.4509.17.camel@siti> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 02 Jun 2006 13:06:14 +0200 Message-Id: <1149246374.2966.25.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:06:22 -0000 Le vendredi 02 juin 2006 à 21:55 +1200, Stephen Cook a écrit : > Hi, > > I haven't introduced myself here before, I am Stephen Cook (siti). My > proposal for implementing IAX2 in ekiga got accepted with google's > summer of code. > > To give an update (I'll try and keep you guys regularly posted as to > what's happening, any problems etc.). > > Currently I have been looking at the code to gain an understanding of > ekiga and opal's code and design. Also obviously checking out the IAX2 > code in opal :). From what I have seen and got working, I will work on > getting IAX2 going in ekiga first. The main part of this will obviously > involve writing a gnome meeting endpoint for IAX2. > I would say that the main part will be to write / finish the IAX2 code in OPAL, either new code, or reusing the current code so that all features that you see in SIP and H.323 are also available for IAX2. Your first project will be to look the limitations of the current code and write a document showing what features you have tested, what work is required to complete them, and what new work is required for new features (Call Hold, Call Transfer, Registering, Call Forward, ...). Writing the endpoint in Ekiga is the last part of the project once the code in OPAL is full functional. Ekiga only contains high-level code. > One key problem I have identified is the accounts code. The protocols > are tightly integrated with how it works. I could either refactor this > code to loosen the integration or hack iax2 support in there and > refactor it later ;). The advantage of this refactored will be when > someone wants to add Xmpp/libjingle support, or some other protocol down > the track. > I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and finally perhaps to a refactoring of the accounts code as it is not the primary purpose of the Google SoC :) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Fri Jun 2 07:08:01 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 243E83B0407 for ; Fri, 2 Jun 2006 07:08:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20781-05 for ; Fri, 2 Jun 2006 07:07:58 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 6C7333B10B6 for ; Fri, 2 Jun 2006 07:07:58 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 5426B49753 for ; Fri, 2 Jun 2006 12:51:33 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06419-06 for ; Fri, 2 Jun 2006 12:51:18 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id EF0D549750 for ; Fri, 2 Jun 2006 12:51:17 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44800CFA.5090800@cs.stanford.edu> References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 02 Jun 2006 13:07:41 +0200 Message-Id: <1149246461.2966.28.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:08:01 -0000 Le vendredi 02 juin 2006 à 03:03 -0700, Dan Sandberg a écrit : > So configure.in is hand-generated? Surprising. > That's te way it works. You write configure.in and configure is generated from there. I guess you are confusing things here. > 1) How exactly do I add the opengl ( libgl ) library? > By writing autconf code in configure.in. No idea exactly how it should be done. > 2) Xrandr is mentioned in the Makefile, but is not in configure.in. How > exactly does it get put into the Makefile? > Probably by an external library that we are using. > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I didn't want > to code against a moving target. > Yes. It is even OK if you do not provide the configure.in code, but only the OpenGL Ekiga code. > Thanks, > > -Dan > > Damien Sandras wrote: > > >Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > > > > > >>I'd imagine it would work on win32, but don't know. > >> > >> > >> > > > >Probably. > > > > > > > >>I'll work on the patches. > >> > >>Where's the right place to add required libraries like openGL? > >> > >> > > > >In configure.in. > > > > > > > >>configure.in seems to be autogenerated by something, but whatever it is > >>doesn't seem to be in the CVS snapshot... > >> > >> > >> > > > >configure.in is in the CVS snapshot. > > > > > > > > > >>Thanks, > >> > >>-Dan > >> > >>Julien PUYDT wrote: > >> > >> > >> > >>>Dan Sandberg a écrit : > >>> > >>> > >>> > >>>>How should we proceed? I could just send you an updated gui/main.cpp > >>>>file... > >>>> > >>>> > >>>I'd like to see patches instead of full files, preferably independant > >>>on each others. > >>> > >>>There's also the question of the portability of this : since you > >>>mention SDL, I guess this will work great on win32 too ? > >>> > >>>Snark > >>>_______________________________________________ > >>>Gnomemeeting-devel-list mailing list > >>>Gnomemeeting-devel-list@gnome.org > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > >>> > >>> > >>> > >>_______________________________________________ > >>Gnomemeeting-devel-list mailing list > >>Gnomemeeting-devel-list@gnome.org > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > >> > >> > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From jpuydt@free.fr Fri Jun 2 09:55:37 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 35E163B0A0B for ; Fri, 2 Jun 2006 09:55:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30481-03 for ; Fri, 2 Jun 2006 09:55:35 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id DF18F3B0468 for ; Fri, 2 Jun 2006 09:55:34 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-30-82-253-132-170.adsl.proxad.net [82.253.132.170]) by smtp6-g19.free.fr (Postfix) with ESMTP id D0F23225C9 for ; Fri, 2 Jun 2006 15:55:31 +0200 (CEST) Message-ID: <44804375.6090107@free.fr> Date: Fri, 02 Jun 2006 15:56:05 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga References: <1149242124.4509.17.camel@siti> <1149246374.2966.25.camel@golgoth01> In-Reply-To: <1149246374.2966.25.camel@golgoth01> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599] X-Spam-Score: -2.561 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 13:55:37 -0000 Damien Sandras a écrit : > I would say that the main part will be to write / finish the IAX2 code > in OPAL, either new code, or reusing the current code so that all > features that you see in SIP and H.323 are also available for IAX2. > > Your first project will be to look the limitations of the current code > and write a document showing what features you have tested, what work is > required to complete them, and what new work is required for new > features (Call Hold, Call Transfer, Registering, Call Forward, ...). > > Writing the endpoint in Ekiga is the last part of the project once the > code in OPAL is full functional. Ekiga only contains high-level code. I don't fully agree with you: writing low-level code all summer long then finally writing the upper-level code, will lead to a non-working feature :-/ Having a least minimal functionality in ekiga would be nice to test the low-level regularly, and see it improving. >> One key problem I have identified is the accounts code. The protocols >> are tightly integrated with how it works. I could either refactor this >> code to loosen the integration or hack iax2 support in there and >> refactor it later ;). The advantage of this refactored will be when >> someone wants to add Xmpp/libjingle support, or some other protocol down >> the track. > > I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and > finally perhaps to a refactoring of the accounts code as it is not the > primary purpose of the Google SoC :) Indeed, the purpose is the IAX2 support, not refactoring the code. I would say that hardcoding the IAX2 account setup in the code would be enough for the SoC. Making it work in the ui in the accounts would be bonus if you had the time, or would be a work to do afterwards. Snark From dsandras@seconix.com Fri Jun 2 10:34:17 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C28113B045D for ; Fri, 2 Jun 2006 10:34:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00352-08 for ; Fri, 2 Jun 2006 10:34:16 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id CE7FF3B0478 for ; Fri, 2 Jun 2006 10:34:15 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 0EFE1496C7 for ; Fri, 2 Jun 2006 16:17:49 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08222-10 for ; Fri, 2 Jun 2006 16:17:42 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 3C897496C6 for ; Fri, 2 Jun 2006 16:17:42 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44804375.6090107@free.fr> References: <1149242124.4509.17.camel@siti> <1149246374.2966.25.camel@golgoth01> <44804375.6090107@free.fr> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 02 Jun 2006 16:34:27 +0200 Message-Id: <1149258867.8383.10.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 14:34:17 -0000 Le vendredi 02 juin 2006 à 15:56 +0200, Julien PUYDT a écrit : > Damien Sandras a écrit : > > I would say that the main part will be to write / finish the IAX2 code > > in OPAL, either new code, or reusing the current code so that all > > features that you see in SIP and H.323 are also available for IAX2. > > > > Your first project will be to look the limitations of the current code > > and write a document showing what features you have tested, what work is > > required to complete them, and what new work is required for new > > features (Call Hold, Call Transfer, Registering, Call Forward, ...). > > > > Writing the endpoint in Ekiga is the last part of the project once the > > code in OPAL is full functional. Ekiga only contains high-level code. > > I don't fully agree with you: writing low-level code all summer long > then finally writing the upper-level code, will lead to a non-working > feature :-/ I agree with you, but you can not start writing the EndPoint if there is no code behind it ;) > > Having a least minimal functionality in ekiga would be nice to test the > low-level regularly, and see it improving. > > >> One key problem I have identified is the accounts code. The protocols > >> are tightly integrated with how it works. I could either refactor this > >> code to loosen the integration or hack iax2 support in there and > >> refactor it later ;). The advantage of this refactored will be when > >> someone wants to add Xmpp/libjingle support, or some other protocol down > >> the track. > > > > I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and > > finally perhaps to a refactoring of the accounts code as it is not the > > primary purpose of the Google SoC :) > > Indeed, the purpose is the IAX2 support, not refactoring the code. I > would say that hardcoding the IAX2 account setup in the code would be > enough for the SoC. > > Making it work in the ui in the accounts would be bonus if you had the > time, or would be a work to do afterwards. > Exactly. > Snark > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From t.schorpp@gmx.de Fri Jun 2 11:06:17 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 63A943B02F7 for ; Fri, 2 Jun 2006 11:06:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02214-08 for ; Fri, 2 Jun 2006 11:06:10 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by menubar.gnome.org (Postfix) with SMTP id 7B6603B0421 for ; Fri, 2 Jun 2006 11:06:09 -0400 (EDT) Received: (qmail invoked by alias); 02 Jun 2006 15:06:08 -0000 Received: from p85.212.150.108.tisdip.tiscali.de (EHLO [192.168.1.100]) [85.212.150.108] by mail.gmx.net (mp001) with SMTP; 02 Jun 2006 17:06:08 +0200 X-Authenticated: #17142692 Message-ID: <448053DE.1010406@gmx.de> Date: Fri, 02 Jun 2006 17:06:06 +0200 From: thomas schorpp User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1 X-Accept-Language: de, en-us MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Bad review about Ekiga References: <1148993400.2400.77.camel@golgoth01> In-Reply-To: <1148993400.2400.77.camel@golgoth01> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.476 tagged_above=-999 required=2 tests=[AWL=-0.011, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] X-Spam-Score: -2.476 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: t.schorpp@gmx.de, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 15:06:17 -0000 Damien Sandras wrote: > http://linux.softpedia.com/progViewUserReviews/156167.html > > This software is a descendant of the former "gnome-meeting" software. It > comes bundled with its own SIP service but claims to work with others. > Unfortunately it has inherited not only the GUI from gnome-meeting but > also the habit to crash every other minute without apparent reason. So I > never got to really test it yet. > > The developers might be better off not making the same mistake as they > did with gnome-meeting and should try to fix all the bugs instead of > adding more crashing bells and whistles. Bad? Bad yes: for marketing. You cant just say this commenter were just too stupid to get the right libs together. Bad no: for development. says You need better CM: - suggest the devs and QA people, users, agree on a certain range of gui libs versions. - suggest meeting with distro maintainers and tight the deps found above to avoid lib/binary inconsistencies. - improve exception handling and fault tolerance on the outside interfaces. ? y tom From craigs@postincrement.com Fri Jun 2 19:57:21 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CDB2A3B11E3 for ; Fri, 2 Jun 2006 19:57:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32469-02 for ; Fri, 2 Jun 2006 19:57:18 -0400 (EDT) Received: from bastion.southeren.com (unknown [220.244.81.10]) by menubar.gnome.org (Postfix) with ESMTP id 870583B11CC for ; Fri, 2 Jun 2006 19:57:17 -0400 (EDT) Received: from [10.0.2.13] (rapido.southeren.com [10.0.2.13]) by bastion.southeren.com (8.12.8/8.12.8) with ESMTP id k52NteJG016237; Sat, 3 Jun 2006 09:55:40 +1000 Date: Sat, 03 Jun 2006 09:55:43 +1000 From: Craig Southeren To: Stephen Cook , GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga In-Reply-To: <1149242124.4509.17.camel@siti> References: <1149242124.4509.17.camel@siti> Message-Id: <20060603095331.79CD.CRAIGS@postincrement.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Becky! ver. 2.11.02 [en] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.939 tagged_above=-999 required=2 tests=[AWL=-0.482, BAYES_00=-2.599, SPF_FAIL=1.142] X-Spam-Score: -1.939 X-Spam-Level: Cc: Derek Smithies X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 23:57:22 -0000 On Fri, 02 Jun 2006 21:55:24 +1200 Stephen Cook wrote: > Hi, >=20 > I haven't introduced myself here before, I am Stephen Cook (siti). My > proposal for implementing IAX2 in ekiga got accepted with google's > summer of code. >=20 > To give an update (I'll try and keep you guys regularly posted as to > what's happening, any problems etc.). >=20 > Currently I have been looking at the code to gain an understanding of > ekiga and opal's code and design. Also obviously checking out the IAX2 > code in opal :). From what I have seen and got working, I will work on > getting IAX2 going in ekiga first. The main part of this will obviously > involve writing a gnome meeting endpoint for IAX2. >=20 > One key problem I have identified is the accounts code. The protocols > are tightly integrated with how it works. I could either refactor this > code to loosen the integration or hack iax2 support in there and > refactor it later ;). The advantage of this refactored will be when > someone wants to add Xmpp/libjingle support, or some other protocol down > the track. >=20 > Well, please tell me your thoughts and comments on this project. As a New Zealander, you are uniquely placed to communicate with the author of the OPAL IAX2 code, Derek Smithies, who is a fellow Kiwi! I am sure that you will be able to get the OPAL IAX2 code working with Ekiga in no time at all with his help.=20 If you have any questions, please contact me directly. Craig ----------------------------------------------------------------------- Craig Southeren Post Increment =96 VoIP Consulting and Software craigs@postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren@hotmail.com Mobile: +61 417231046 =20 "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting From hoglet@solit.se Sat Jun 3 03:46:01 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9178F3B04E8 for ; Sat, 3 Jun 2006 03:46:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19488-05 for ; Sat, 3 Jun 2006 03:45:59 -0400 (EDT) Received: from aurian.solit.se (unknown [82.182.216.174]) by menubar.gnome.org (Postfix) with ESMTP id 9DD3C3B0505 for ; Sat, 3 Jun 2006 03:45:59 -0400 (EDT) Received: from ip76.kassjo.se ([85.11.28.76] helo=localhost.localdomain) by aurian.solit.se with asmtp (Exim 3.35 #1 (Debian)) id 1FmQpW-0006J7-00 for ; Sat, 03 Jun 2006 09:45:54 +0200 Date: Sat, 3 Jun 2006 09:45:50 +0200 From: Kent Asplund To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Bad review about Ekiga Message-Id: <20060603094550.0e1ff8aa.hoglet@solit.se> In-Reply-To: <1148993400.2400.77.camel@golgoth01> References: <1148993400.2400.77.camel@golgoth01> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: ej spam, SpamAssassin (resultat=-4.4, krav 5, IN_REP_TO -4.43) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.898 tagged_above=-999 required=2 tests=[AWL=-1.435, BAYES_20=-0.74, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142] X-Spam-Score: -0.898 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 07:46:01 -0000 --Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 30 May 2006 14:50:00 +0200 Damien Sandras wrote: > http://linux.softpedia.com/progViewUserReviews/156167.html >=20 > This software is a descendant of the former "gnome-meeting" software. It > comes bundled with its own SIP service but claims to work with others. > Unfortunately it has inherited not only the GUI from gnome-meeting but > also the habit to crash every other minute without apparent reason. So I > never got to really test it yet. >=20 > The developers might be better off not making the same mistake as they > did with gnome-meeting and should try to fix all the bugs instead of > adding more crashing bells and whistles. I have never had a crash and the program was easy to setup. I have had some problem but they have been outside of Ekiga (siproxd and firewall) Ekiga has som distance to go to "get finished" but it is still THE BEST PROGRAM AROUND! Subjectively of course :) Waiting patiently for 2.2 /Hoglet --=20 Go ahead... make my day. -- Dirty Harry --Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEgT4x4WZLcIH5l3kRApw3AJ9yPgdPoUSeKGniD1w0w0cMTXajRACfWaDG 2YUvSTxFnaSeD8q0uWWv6zE= =2nFl -----END PGP SIGNATURE----- --Signature=_Sat__3_Jun_2006_09_45_50_+0200_sdo+K3clJ9roSWny-- From hoglet@solit.se Sat Jun 3 03:54:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C25A43B05C8 for ; Sat, 3 Jun 2006 03:54:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19755-10 for ; Sat, 3 Jun 2006 03:54:38 -0400 (EDT) Received: from aurian.solit.se (unknown [82.182.216.174]) by menubar.gnome.org (Postfix) with ESMTP id B980A3B04F9 for ; Sat, 3 Jun 2006 03:54:38 -0400 (EDT) Received: from ip76.kassjo.se ([85.11.28.76] helo=localhost.localdomain) by aurian.solit.se with asmtp (Exim 3.35 #1 (Debian)) id 1FmQxt-0006L4-00 for ; Sat, 03 Jun 2006 09:54:33 +0200 Date: Sat, 3 Jun 2006 09:54:33 +0200 From: Kent Asplund To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Re: Ekiga branched Message-Id: <20060603095433.82461abf.hoglet@solit.se> In-Reply-To: <447EE9BE.5030005@free.fr> References: <1147894199.7225.2.camel@golgoth01> <1148207277.6654.0.camel@frobisher.madeley.id.au> <1148209984.2488.26.camel@golgoth01> <20060601150938.fcdea791.hoglet@solit.se> <447EE9BE.5030005@free.fr> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: ej spam, SpamAssassin (resultat=-4.4, krav 5, IN_REP_TO -4.43) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.764 tagged_above=-999 required=2 tests=[AWL=-0.519, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142, TW_KT=0.077] X-Spam-Score: -1.764 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 07:54:39 -0000 --Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 01 Jun 2006 15:21:02 +0200 Julien PUYDT wrote: > Kent Asplund a =E9crit : > > Exchanging the button to a green phone handle (red when calling in > > progress) would make it more alike others and therefore easier to > > accept. >=20 > The classic case of "your flying car lacks a spare wheel!" ;-) I'm taking the risk of seeming to be completely without humour. No, it is more a case of having a car with automatic gearbox and instead of having a lever you have a button for changing direction.=20 It works perfektly OK but people will think that it is a strange car and choose another one. (I think Citro=EBn had this problem) My wife just said "it is made for nerds not humans" Greetings /Hoglet the nerd --=20 I don't know anything about music. In my line you don't have to. -- Elvis Presley --Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEgUA54WZLcIH5l3kRAiYpAJ4/lkEYFVjWRQrYSvn7D9XmkU+6FgCgiejD m2Sp2AVqfZZHzT5TaBCVu5I= =OH96 -----END PGP SIGNATURE----- --Signature=_Sat__3_Jun_2006_09_54_33_+0200_haVSzn6=Yh/4yHlQ-- From devel@tootai.net Sat Jun 3 11:12:15 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3EF583B05AE for ; Sat, 3 Jun 2006 11:12:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11557-03 for ; Sat, 3 Jun 2006 11:12:10 -0400 (EDT) Received: from mail1.tootai.net (ns1.tootai.net [82.231.69.24]) by menubar.gnome.org (Postfix) with ESMTP id A02F63B0348 for ; Sat, 3 Jun 2006 11:12:09 -0400 (EDT) Received: from [192.168.0.17] (unknown [192.168.0.17]) by mail1.tootai.net (Postfix) with ESMTP id E2ACD398BA0 for ; Sat, 3 Jun 2006 17:12:06 +0200 (CEST) Message-ID: <4481A6AF.2060703@tootai.net> Date: Sat, 03 Jun 2006 17:11:43 +0200 From: Daniel Huhardeaux Organization: TOOTAi User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: GnomeMeeting development mailing list Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: Subject: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 15:12:15 -0000 Resent as it didn't pass at the first try (too big, I cut the begining of logs) Hi all, Ekiga behind a firewall is registering to an asterisk server which is on internet. The sip user is authorized with gsm,ulaw,alaw on asterisk side. When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is started, connection is showed with PCMU (why not GSM?), see the traffic in/out (~6 kB) but have no audio. I hangup the call, the hangup info is shown in the toolbar, PCMU disappear in codec and immediately after, traffic in/out continue with 0/0, icon in KDE Toolbar show Ekiga on line. The only solution I have is to kill Ekiga. If I deactivate GSM codec, everything is fine. Below you will find a d4 output from the call. [...] 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 OpalUDP Ended connect, selecting 82.231.69.24:35065 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP Queueing PDU: 1 INVITE <407> 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP Waiting for PDU on udp$213.203.241.243:5060 2006/06/02 13:12:32.901 0:10.661 SIP Handler:8520268 SIP PDU handler thread started. 2006/06/02 13:12:32.902 0:10.662 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:32.902 0:10.663 SIP Handler:8520268 SIP Handling PDU 1 INVITE <407> (with transaction) 2006/06/02 13:12:32.903 0:10.663 SIP Handler:8520268 SIP Transaction 1 INVITE completed. 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP Sending PDU on udp$213.203.241.243:5060 ACK sip:800@sip.tootai.net SIP/2.0 CSeq: 1 ACK Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bK803b125b-96f0-da11-8388-000ea6217592;rport From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: ;tag=as315809c6 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 70 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP Received Proxy Authentication Required response 2006/06/02 13:12:32.906 0:10.666 SIP Handler:8520268 SIP Transaction 2 INVITE created. 2006/06/02 13:12:32.906 0:10.667 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:33.090 0:10.850 SIP Handler:8520268 RTP_UDP Session 1 created: 82.231.69.24:35010-35011 ssrc=703395120 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 RTP Adding session RTP_UDP 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 SIP Using RTP payload [pt=101] for NTE 2006/06/02 13:12:33.100 0:10.860 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k H.261(QCIF) H.261(CIF) YUV420P RGB32 RGB24 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 2 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 2 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 SIP IsMediaBypassPossible: session 2 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:33.281 0:11.041 SIP Handler:8520268 RTP_UDP Session 2 created: 82.231.69.24:35014-35015 ssrc=2454563097 2006/06/02 13:12:33.282 0:11.042 SIP Handler:8520268 RTP Adding session RTP_UDP 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k H.261(QCIF) H.261(CIF) YUV420P RGB32 RGB24 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 SIP Adding authentication information 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP Sending PDU on udp$213.203.241.243:5060 INVITE sip:800@sip.tootai.net SIP/2.0 Date: Fri, 02 Jun 2006 11:12:32 GMT CSeq: 2 INVITE Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;rport User-Agent: Ekiga/2.0.1-20060521-01 From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: Contact: Proxy-Authorization: Digest username="104", realm="sip.tootai.net", nonce="12d01d5d", uri="sip:800@sip.tootai.net", response="60b65ec9045130eab45495d3c65fbc5e", algorithm=md5 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Type: application/sdp Content-Length: 302 Max-Forwards: 70 v=0 o=- 1149246753 1149246753 IN IP4 82.231.69.24 s=Opal SIP Session c=IN IP4 82.231.69.24 t=0 0 m=audio 35010 RTP/AVP 101 3 0 8 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 m=video 35014 RTP/AVP 31 a=rtpmap:31 H261/90000 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP PDU Received on udp$213.203.241.243:5060 SIP/2.0 100 Trying CSeq: 2 INVITE Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 User-Agent: Asterisk PBX From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP Queueing PDU: 2 INVITE <100> 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP Waiting for PDU on udp$213.203.241.243:5060 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP Handling PDU 2 INVITE <100> (with transaction) 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP Transaction 2 INVITE proceeding. 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Set targetAddress to sip:800@213.203.241.243 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Received Trying response 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP Media session port=7166 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP Adding media session with 2 formats 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP Unknown media attribute silenceSupp:off - - - - 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SIP PDU Received on udp$213.203.241.243:5060 SIP/2.0 200 OK CSeq: 2 INVITE Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 User-Agent: Asterisk PBX From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: ;tag=as5d2831d1 Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Type: application/sdp Content-Length: 221 v=0 o=root 26912 26912 IN IP4 213.203.241.243 s=session c=IN IP4 213.203.241.243 t=0 0 m=audio 7166 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP Queueing PDU: 2 INVITE <200> 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP Waiting for PDU on udp$213.203.241.243:5060 2006/06/02 13:12:33.388 0:11.148 SIP Handler:8520268 SIP Handling PDU 2 INVITE <200> (with transaction) 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP Transaction 2 INVITE completed. 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP Set targetAddress to sip:800@213.203.241.243 2006/06/02 13:12:33.390 0:11.150 SIP Handler:8520268 SIP Adding authentication information 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP Adjusting transport to address udp$213.203.241.243:5060 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP Sending PDU on udp$213.203.241.243:5060 ACK sip:800@213.203.241.243 SIP/2.0 CSeq: 2 ACK Via: SIP/2.0/UDP 82.231.69.24:35065;branch=z9hG4bK6e2ca15b-96f0-da11-8388-000ea6217592;rport From: "Huhardeaux Daniel" ;tag=8c53075b-96f0-da11-8388-000ea6217592 Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade To: ;tag=as5d2831d1 Contact: Proxy-Authorization: Digest username="104", realm="sip.tootai.net", nonce="12d01d5d", uri="sip:800@213.203.241.243", response="059defd67706254552a5c23eada565b5", algorithm=md5 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 70 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP Received INVITE OK response 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 SIP RTP payload type PCMU matched to codec G.711-uLaw-64k 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 OpalCon OpenSourceMediaStream for session 1 on Call[1]-EP[Default] 2006/06/02 13:12:33.398 0:11.158 SIP Handler:8520268 OpalCon Selected media stream PCM-16 -> G.711-uLaw-64k 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 Call PatchMediaStreams Call[1]-EP[Default] 2006/06/02 13:12:34.196 0:11.957 SIP Handler:8520268 OpalCon OpenSinkMediaStream Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session=1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon OpenSinkMediaStream, selected PCM-16 -> G.711-uLaw-64k 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:34.197 0:11.958 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Patch Added sink from PCM-16 Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 16 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 to G.711-uLaw-64k Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 8 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Codec G711-uLaw-64k encoder created 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Patch Added media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k using transcoder PCM-16->G.711-uLaw-64k 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Media Audio source data size set to 320 bytes and 2 buffers. 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call GetOtherPartyConnection Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon OpenSourceMediaStream for session 1 on Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon Selected media stream G.711-uLaw-64k -> PCM-16 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 Call CanDoMediaBypass Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalMan IsMediaBypassPossible: session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 SIP IsMediaBypassPossible: session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon IsMediaBypassPossible: default returns FALSE 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 Call PatchMediaStreams Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon OpenSinkMediaStream Call[1]-EP[Default] session=1 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon OpenSinkMediaStream, selected G.711-uLaw-64k -> PCM-16 2006/06/02 13:12:34.513 0:12.274 SIP Handler:8520268 OpalMan OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:34.514 0:12.274 SIP Handler:8520268 Patch Added sink from G.711-uLaw-64k Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 8 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 to PCM-16 Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 16 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Codec G711-uLaw-64k decoder created 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Media Audio sink data size set to 320 bytes and 2 buffers. 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Patch Added media stream sink OpalAudioMediaStream-Sink-PCM-16 using transcoder G.711-uLaw-64k->PCM-16 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon New patch created 2006/06/02 13:12:34.525 0:12.285 SIP Handler:8520268 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.527 0:12.287 SIP Handler:8520268 RTP_UDP SetRemoteSocketInfo: session=1 data channel, new=213.203.241.243:7166, local=82.231.69.24:35010-35011, remote=0.0.0.0:0-0 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 SIP Could not find SDP media description for Video 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 OpalMan OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 Call OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 PCSS SetConnected() 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 GMPCSSEndpoint PCSS connection established 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 GMManager Will establish the connection 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 OpalMan OnEstablished Call[1]-EP[Default] 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 Call OnEstablished Call[1]-EP[Default] 2006/06/02 13:12:34.540 0:12.300 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[Default] G.711-uLaw-64k 2006/06/02 13:12:34.541 0:12.301 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k 2006/06/02 13:12:34.542 0:12.302 SIP Handler:8520268 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.543 0:12.303 SIP Handler:8520268 Call OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call GetMediaFormats for Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] G.711-uLaw-64k 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[Default] 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k 2006/06/02 13:12:34.552 0:12.312 SIP Handler:8520268 Call OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k 2006/06/02 13:12:34.553 0:12.313 Media Patch:8175708 Patch Thread started for Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:34.556 0:12.316 SIP Handler:8520268 Media Starting thread Media Patch:8175708 2006/06/02 13:12:34.557 0:12.317 Media Patch:8527348 Patch Thread started for Patch OpalRTPMediaStream-Source-G.711-uLaw-64k -> OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:34.568 0:12.329 Media Patch:8527348 RTP Jitter buffer created: size=101 delay=160-4000/160 (20ms) obj=0x8526b30 2006/06/02 13:12:34.572 0:12.333 RTP Jitter:8526b30 RTP Jitter RTP receive thread started: 0x8526b30 2006/06/02 13:12:34.574 0:12.334 RTP Jitter:8526b30 RTP First receive data: ver=2 pt=GSM psz=33 m=0 x=0 seq=39915 ts=160 src=824302623 ccnt=0 2006/06/02 13:12:34.580 0:12.341 SIP Handler:8520268 Media Starting thread Media Patch:8527348 2006/06/02 13:12:34.581 0:12.341 SIP Handler:8520268 OpalCon Media stream threads started. 2006/06/02 13:12:34.582 0:12.342 SIP Handler:8520268 OpalCon Media stream threads started. 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP Found existing session 1 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP Found existing session 2 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 GMManager Will establish the connection 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 OpalMan OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.607 0:12.367 SIP Handler:8520268 Call OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:34.610 0:12.371 SIP Handler:8520268 SIP Awaiting next PDU. 2006/06/02 13:12:34.648 0:12.408 Media Patch:8527348 RTP Jitter buffer length exceeded 2006/06/02 13:12:34.649 0:12.409 Media Patch:8527348 RTP Jitter buffer length exceed was prior to first write. Not increasing buffer size 2006/06/02 13:12:35.277 0:13.037 Media Patch:8175708 RTP First sent data: ver=2 pt=PCMU psz=160 m=1 x=0 seq=1460 ts=0 src=703395120 ccnt=0 2006/06/02 13:12:35.608 0:13.368 Housekeeper RTP Found existing session 1 2006/06/02 13:12:35.609 0:13.369 Housekeeper RTP Found existing session 2 2006/06/02 13:12:36.137 0:13.898 RTP Jitter:8526b30 RTP Receive statistics: packets=101 octets=3714 lost=0 tooLate=0 order=0 avgTime=15 maxTime=1556 minTime=0 jitter=16 maxJitter=188 2006/06/02 13:12:36.573 0:14.333 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (9760) 2006/06/02 13:12:36.614 0:14.374 Housekeeper RTP Found existing session 1 2006/06/02 13:12:36.615 0:14.375 Housekeeper RTP Found existing session 2 2006/06/02 13:12:36.974 0:14.734 RTP Jitter:8526b30 RTP Jitter buffer continuously full, throwing away entire buffer. 2006/06/02 13:12:36.995 0:14.756 RTP Jitter:8526b30 RTP Jitter buffer full, threw away 21 oldest frames 2006/06/02 13:12:37.374 0:15.134 RTP Jitter:8526b30 RTP Receive statistics: packets=201 octets=19714 lost=0 tooLate=0 order=0 avgTime=12 maxTime=23 minTime=0 jitter=0 maxJitter=188 2006/06/02 13:12:37.620 0:15.380 Housekeeper RTP Found existing session 1 2006/06/02 13:12:37.621 0:15.381 Housekeeper RTP Found existing session 2 2006/06/02 13:12:37.820 0:15.580 Media Patch:8175708 RTP Transmit statistics: packets=101 octets=16160 avgTime=25 maxTime=48 minTime=23 2006/06/02 13:12:38.624 0:16.384 Housekeeper RTP Found existing session 1 2006/06/02 13:12:38.625 0:16.385 Housekeeper RTP Found existing session 2 2006/06/02 13:12:38.993 0:16.753 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (29120) 2006/06/02 13:12:39.374 0:17.134 RTP Jitter:8526b30 RTP Receive statistics: packets=301 octets=35714 lost=0 tooLate=0 order=0 avgTime=20 maxTime=26 minTime=14 jitter=1 maxJitter=188 2006/06/02 13:12:39.395 0:17.155 RTP Jitter:8526b30 RTP Jitter buffer continuously full, throwing away entire buffer. 2006/06/02 13:12:39.415 0:17.176 RTP Jitter:8526b30 RTP Jitter buffer full, threw away 21 oldest frames 2006/06/02 13:12:39.632 0:17.392 Housekeeper RTP Found existing session 1 2006/06/02 13:12:39.633 0:17.393 Housekeeper RTP Found existing session 2 2006/06/02 13:12:40.384 0:18.144 Media Patch:8175708 RTP Transmit statistics: packets=201 octets=32160 avgTime=25 maxTime=44 minTime=22 2006/06/02 13:12:40.640 0:18.400 Housekeeper RTP Found existing session 1 2006/06/02 13:12:40.641 0:18.401 Housekeeper RTP Found existing session 2 2006/06/02 13:12:41.373 0:19.133 RTP Jitter:8526b30 RTP Receive statistics: packets=401 octets=51714 lost=0 tooLate=0 order=0 avgTime=19 maxTime=26 minTime=13 jitter=1 maxJitter=188 2006/06/02 13:12:41.413 0:19.173 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (48480) 2006/06/02 13:12:41.648 0:19.424 Housekeeper RTP Found existing session 1 2006/06/02 13:12:41.665 0:19.425 Housekeeper RTP Found existing session 2 2006/06/02 13:12:41.813 0:19.573 RTP Jitter:8526b30 RTP Jitter buffer continuously full, throwing away entire buffer. 2006/06/02 13:12:41.833 0:19.593 RTP Jitter:8526b30 RTP Jitter buffer full, threw away 21 oldest frames 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP Found existing session 1 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP Found existing session 2 2006/06/02 13:12:42.920 0:20.680 Media Patch:8175708 RTP Transmit statistics: packets=301 octets=48160 avgTime=25 maxTime=49 minTime=22 2006/06/02 13:12:43.378 0:21.139 RTP Jitter:8526b30 RTP Receive statistics: packets=501 octets=67714 lost=0 tooLate=0 order=0 avgTime=20 maxTime=27 minTime=12 jitter=1 maxJitter=188 2006/06/02 13:12:43.696 0:21.457 Housekeeper RTP Found existing session 1 2006/06/02 13:12:43.697 0:21.457 Housekeeper RTP Found existing session 2 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot Call Clearing Call[1] reason=EndedByLocalUser 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot OpalCon Releasing Call[1]-EP[Default] 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon Call end reason for Default set to EndedByLocalUser 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon SetPhase from EstablishedPhase to ReleasingPhase 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon Releasing Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon Call end reason for fa44075b-96f0-da11-8388-000ea6217592@nomade set to EndedByLocalUser 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon SetPhase from EstablishedPhase to ReleasingPhase 2006/06/02 13:12:43.820 0:21.581 OnRelease:856e8a0 OpalCon OnReleased Call[1]-EP[Default] 2006/06/02 13:12:43.822 0:21.583 OnRelease:856e8a0 Media Closing raw media stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.824 0:21.584 OnRelease:856e8a0 Media Closing stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.825 0:21.585 OnRelease:856e8a0 Media Disconnecting OpalAudioMediaStream-Source-PCM-16 from patch thread Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.827 0:21.587 OnRelease:856e8a0 Patch Closing media patch Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.829 0:21.589 OnRelease:856e8a0 Media Closing raw media stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.830 0:21.590 OnRelease:856e8a0 Media Closing stream OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.831 0:21.591 OnRelease:84f8c00 SIP OnReleased: Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade], phase = ReleasingPhase 2006/06/02 13:12:43.833 0:21.593 OnRelease:84f8c00 OpalCon SetPhase from ReleasingPhase to ReleasingPhase 2006/06/02 13:12:43.834 0:21.594 RTP Jitter:8526b30 RTP Jitter buffer full, throwing away oldest frame (67840) 2006/06/02 13:12:43.836 0:21.596 OnRelease:84f8c00 SIP Transaction 4 BYE created. 2006/06/02 13:12:43.842 0:21.603 OnRelease:84f8c00 Media Closing RTP for OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.844 0:21.604 OnRelease:84f8c00 RTP_UDP Session 1, Shutting down write. 2006/06/02 13:12:43.845 0:21.605 OnRelease:84f8c00 Media Closing stream OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.846 0:21.606 OnRelease:84f8c00 Media Disconnecting OpalRTPMediaStream-Sink-G.711-uLaw-64k from patch thread Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.848 0:21.609 OnRelease:84f8c00 Patch Removing media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k 2006/06/02 13:12:43.855 0:21.626 OnRelease:84f8c00 Media Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.867 0:21.627 OnRelease:84f8c00 RTP_UDP Session 1, Shutting down read. 2006/06/02 13:12:43.868 0:21.628 OnRelease:84f8c00 Media Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.869 0:21.630 OnRelease:84f8c00 Media Disconnecting OpalRTPMediaStream-Source-G.711-uLaw-64k from patch thread Patch OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.893 0:21.653 Media Patch:8175708 Patch Thread ended for Patch OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.893 0:21.653 OnRelease:84f8c00 Patch Closing media patch Patch OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.916 0:21.676 RTP Jitter:8526b30 RTP_UDP Session 1, Read shutdown. 2006/06/02 13:12:43.917 0:21.677 RTP Jitter:8526b30 RTP Jitter RTP receive thread ended 2006/06/02 13:12:43.917 0:21.677 OnRelease:84f8c00 Media Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.918 0:21.678 OnRelease:84f8c00 RTP_UDP Session 1, Shutting down read. 2006/06/02 13:12:43.919 0:21.679 OnRelease:84f8c00 Media Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.922 0:21.683 OnRelease:856e8a0 Patch Waiting for media patch thread to stop Patch OpalAudioMediaStream-Source-PCM-16 2006/06/02 13:12:43.926 0:21.686 OnRelease:856e8a0 Patch Media patch thread Patch OpalAudioMediaStream-Source-PCM-16 destroyed. 2006/06/02 13:12:43.930 0:21.691 OnRelease:856e8a0 Media Closing raw media stream OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:43.932 0:21.693 OnRelease:856e8a0 Media Closing stream OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:43.933 0:21.694 OnRelease:856e8a0 Media Disconnecting OpalAudioMediaStream-Sink-PCM-16 from patch thread Patch OpalRTPMediaStream-Source-G.711-uLaw-64k 2006/06/02 13:12:43.956 0:21.717 OnRelease:856e8a0 Patch Removing media stream sink OpalAudioMediaStream-Sink-PCM-16 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP Found existing session 1 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP Found existing session 2 2006/06/02 13:12:45.696 0:23.456 Housekeeper RTP Found existing session 1 2006/06/02 13:12:45.697 0:23.457 Housekeeper RTP Found existing session 2 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP Found existing session 1 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP Found existing session 2 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP Found existing session 1 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP Found existing session 2 2006/06/02 13:12:48.708 0:26.468 Housekeeper RTP Found existing session 1 2006/06/02 13:12:48.709 0:26.469 Housekeeper RTP Found existing session 2 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP Found existing session 1 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP Found existing session 2 2006/06/02 13:12:50.712 0:28.473 Housekeeper RTP Found existing session 1 2006/06/02 13:12:50.713 0:28.473 Housekeeper RTP Found existing session 2 2006/06/02 13:12:51.716 0:29.477 Housekeeper RTP Found existing session 1 2006/06/02 13:12:51.717 0:29.477 Housekeeper RTP Found existing session 2 2006/06/02 13:12:52.716 0:30.477 Housekeeper RTP Found existing session 1 2006/06/02 13:12:52.717 0:30.477 Housekeeper RTP Found existing session 2 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP Found existing session 1 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP Found existing session 2 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP Found existing session 1 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP Found existing session 2 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP Found existing session 1 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP Found existing session 2 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP Found existing session 1 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP Found existing session 2 2006/06/02 13:12:57.733 0:35.493 Housekeeper RTP Found existing session 1 2006/06/02 13:12:57.734 0:35.494 Housekeeper RTP Found existing session 2 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP Found existing session 1 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP Found existing session 2 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP Found existing session 1 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP Found existing session 2 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP Found existing session 1 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP Found existing session 2 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP Found existing session 1 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP Found existing session 2 2006/06/02 13:13:02.777 0:40.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:02.778 0:40.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP Found existing session 2 2006/06/02 13:13:04.369 0:42.129 Housekeeper SIP Set state Terminated_Success for transaction 1 INVITE 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP Found existing session 2 2006/06/02 13:13:05.777 0:43.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:05.777 0:43.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:06.613 0:44.374 Housekeeper SIP Set state Terminated_Success for transaction 2 INVITE 2006/06/02 13:13:06.777 0:44.537 Housekeeper RTP Found existing session 1 2006/06/02 13:13:06.778 0:44.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:07.777 0:45.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:07.778 0:45.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP Found existing session 2 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP Found existing session 1 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP Found existing session 2 Processus arrêté -- Daniel From dsandras@seconix.com Sat Jun 3 13:58:00 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 184373B06A7 for ; Sat, 3 Jun 2006 13:58:00 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20355-03 for ; Sat, 3 Jun 2006 13:57:57 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 19BB03B036E for ; Sat, 3 Jun 2006 13:57:56 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id BC1A4493FD; Sat, 3 Jun 2006 19:41:15 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13551-03; Sat, 3 Jun 2006 19:41:05 +0200 (CEST) Received: from d51A5F203.access.telenet.be (d51A5F203.access.telenet.be [81.165.242.3]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id BC664493EE; Sat, 3 Jun 2006 19:41:05 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <20060603095331.79CD.CRAIGS@postincrement.com> References: <1149242124.4509.17.camel@siti> <20060603095331.79CD.CRAIGS@postincrement.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Sat, 03 Jun 2006 19:57:45 +0200 Message-Id: <1149357465.2414.30.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: Cc: Derek Smithies X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 17:58:00 -0000 Le samedi 03 juin 2006 à 09:55 +1000, Craig Southeren a écrit : > On Fri, 02 Jun 2006 21:55:24 +1200 > Stephen Cook wrote: > > > Hi, > > > > I haven't introduced myself here before, I am Stephen Cook (siti). My > > proposal for implementing IAX2 in ekiga got accepted with google's > > summer of code. > > > > To give an update (I'll try and keep you guys regularly posted as to > > what's happening, any problems etc.). > > > > Currently I have been looking at the code to gain an understanding of > > ekiga and opal's code and design. Also obviously checking out the IAX2 > > code in opal :). From what I have seen and got working, I will work on > > getting IAX2 going in ekiga first. The main part of this will obviously > > involve writing a gnome meeting endpoint for IAX2. > > > > One key problem I have identified is the accounts code. The protocols > > are tightly integrated with how it works. I could either refactor this > > code to loosen the integration or hack iax2 support in there and > > refactor it later ;). The advantage of this refactored will be when > > someone wants to add Xmpp/libjingle support, or some other protocol down > > the track. > > > > Well, please tell me your thoughts and comments on this project. > > As a New Zealander, you are uniquely placed to communicate with the > author of the OPAL IAX2 code, Derek Smithies, who is a fellow Kiwi! I am > sure that you will be able to get the OPAL IAX2 code working with Ekiga > in no time at all with his help. > > If you have any questions, please contact me directly. > Craig, I do not think moving to an offline conversation with Stephen is a good idea. Julien and myself are supposed to mentor the project. Your help is of course welcome, but we have to be kept informed. Notice also that the project is not only about making IAX2 work with Ekiga. -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Sat Jun 3 14:01:08 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 59C003B01BB for ; Sat, 3 Jun 2006 14:01:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20343-10 for ; Sat, 3 Jun 2006 14:01:02 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id BA0863B04B1 for ; Sat, 3 Jun 2006 14:01:01 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 1184A496A8 for ; Sat, 3 Jun 2006 19:44:21 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13551-04 for ; Sat, 3 Jun 2006 19:44:12 +0200 (CEST) Received: from d51A5F203.access.telenet.be (d51A5F203.access.telenet.be [81.165.242.3]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 993CE49685 for ; Sat, 3 Jun 2006 19:44:07 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <4481A6AF.2060703@tootai.net> References: <4481A6AF.2060703@tootai.net> Content-Type: text/plain; charset=ISO-8859-15 Date: Sat, 03 Jun 2006 20:00:48 +0200 Message-Id: <1149357648.2414.34.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 18:01:08 -0000 Hi, Le samedi 03 juin 2006 à 17:11 +0200, Daniel Huhardeaux a écrit : > Resent as it didn't pass at the first try (too big, I cut the begining > of logs) > > Hi all, > > Ekiga behind a firewall is registering to an asterisk server which is on > internet. The sip user is authorized with gsm,ulaw,alaw on asterisk side. > > When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is > started, connection is showed with PCMU (why not GSM?), see the traffic > in/out (~6 kB) but have no audio. > Asterisk answers with 200 OK indicating that the call should be done with PCMU. > I hangup the call, the hangup info is shown in the toolbar, PCMU > disappear in codec and immediately after, traffic in/out continue with > 0/0, icon in KDE Toolbar show Ekiga on line. The only solution I have is > to kill Ekiga. > Please try with 2.0.2. Craig has done work in CVS and things are potentially broken. If the problem persists once plugins support is in CVS, please report again. > If I deactivate GSM codec, everything is fine. Below you will find a d4 > output from the call. > I do not think activating GSM or not has any influence. The problem is probably something else. > > [...] > 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 OpalUDP > Ended connect, selecting 82.231.69.24:35065 > 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP > Queueing PDU: 1 INVITE <407> > 2006/06/02 13:12:32.899 0:10.659 SIP Transport:84fdac8 SIP > Waiting for PDU on udp$213.203.241.243:5060 > 2006/06/02 13:12:32.901 0:10.661 SIP Handler:8520268 SIP PDU > handler thread started. > 2006/06/02 13:12:32.902 0:10.662 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:32.902 0:10.663 SIP Handler:8520268 SIP > Handling PDU 1 INVITE <407> (with transaction) > 2006/06/02 13:12:32.903 0:10.663 SIP Handler:8520268 SIP > Transaction 1 INVITE completed. > 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP > Sending PDU on udp$213.203.241.243:5060 > ACK sip:800@sip.tootai.net SIP/2.0 > CSeq: 1 ACK > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bK803b125b-96f0-da11-8388-000ea6217592;rport > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: ;tag=as315809c6 > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE > Content-Length: 0 > Max-Forwards: 70 > > > 2006/06/02 13:12:32.905 0:10.665 SIP Handler:8520268 SIP > Received Proxy Authentication Required response > 2006/06/02 13:12:32.906 0:10.666 SIP Handler:8520268 SIP > Transaction 2 INVITE created. > 2006/06/02 13:12:32.906 0:10.667 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:32.907 0:10.667 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:33.090 0:10.850 SIP Handler:8520268 RTP_UDP > Session 1 created: 82.231.69.24:35010-35011 ssrc=703395120 > 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 RTP > Adding session RTP_UDP > 2006/06/02 13:12:33.091 0:10.851 SIP Handler:8520268 SIP > Using RTP payload [pt=101] for NTE > 2006/06/02 13:12:33.100 0:10.860 SIP Handler:8520268 Call > GetMediaFormats for > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > GSM-06.10 > G.711-uLaw-64k > G.711-ALaw-64k > H.261(QCIF) > H.261(CIF) > YUV420P > RGB32 > RGB24 > > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 2 > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 2 > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 2 > 2006/06/02 13:12:33.101 0:10.861 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:33.281 0:11.041 SIP Handler:8520268 RTP_UDP > Session 2 created: 82.231.69.24:35014-35015 ssrc=2454563097 > 2006/06/02 13:12:33.282 0:11.042 SIP Handler:8520268 RTP > Adding session RTP_UDP > 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 Call > GetMediaFormats for > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > GSM-06.10 > G.711-uLaw-64k > G.711-ALaw-64k > H.261(QCIF) > H.261(CIF) > YUV420P > RGB32 > RGB24 > > 2006/06/02 13:12:33.290 0:11.050 SIP Handler:8520268 SIP > Adding authentication information > 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP > Sending PDU on udp$213.203.241.243:5060 > INVITE sip:800@sip.tootai.net SIP/2.0 > Date: Fri, 02 Jun 2006 11:12:32 GMT > CSeq: 2 INVITE > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;rport > User-Agent: Ekiga/2.0.1-20060521-01 > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: > Contact: > Proxy-Authorization: Digest username="104", realm="sip.tootai.net", > nonce="12d01d5d", uri="sip:800@sip.tootai.net", > response="60b65ec9045130eab45495d3c65fbc5e", algorithm=md5 > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE > Content-Type: application/sdp > Content-Length: 302 > Max-Forwards: 70 > > v=0 > o=- 1149246753 1149246753 IN IP4 82.231.69.24 > s=Opal SIP Session > c=IN IP4 82.231.69.24 > t=0 0 > m=audio 35010 RTP/AVP 101 3 0 8 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=rtpmap:3 GSM/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > m=video 35014 RTP/AVP 31 > a=rtpmap:31 H261/90000 > > 2006/06/02 13:12:33.291 0:11.051 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP PDU > Received on udp$213.203.241.243:5060 > SIP/2.0 100 Trying > CSeq: 2 INVITE > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 > User-Agent: Asterisk PBX > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: > Contact: > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > Content-Length: 0 > > > 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP > Queueing PDU: 2 INVITE <100> > 2006/06/02 13:12:33.356 0:11.116 SIP Transport:84fdac8 SIP > Waiting for PDU on udp$213.203.241.243:5060 > 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP > Handling PDU 2 INVITE <100> (with transaction) > 2006/06/02 13:12:33.358 0:11.118 SIP Handler:8520268 SIP > Transaction 2 INVITE proceeding. > 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP Set > targetAddress to sip:800@213.203.241.243 > 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP > Received Trying response > 2006/06/02 13:12:33.359 0:11.119 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP > Media session port=7166 > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP > Adding media session with 2 formats > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SDP > Unknown media attribute silenceSupp:off - - - - > 2006/06/02 13:12:33.387 0:11.147 SIP Transport:84fdac8 SIP PDU > Received on udp$213.203.241.243:5060 > SIP/2.0 200 OK > CSeq: 2 INVITE > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bKbe6c575b-96f0-da11-8388-000ea6217592;received=82.231.69.24;rport=35065 > User-Agent: Asterisk PBX > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: ;tag=as5d2831d1 > Contact: > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > Content-Type: application/sdp > Content-Length: 221 > > v=0 > o=root 26912 26912 IN IP4 213.203.241.243 > s=session > c=IN IP4 213.203.241.243 > t=0 0 > m=audio 7166 RTP/AVP 0 101 > a=rtpmap:0 PCMU/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=silenceSupp:off - - - - > > 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP > Queueing PDU: 2 INVITE <200> > 2006/06/02 13:12:33.388 0:11.148 SIP Transport:84fdac8 SIP > Waiting for PDU on udp$213.203.241.243:5060 > 2006/06/02 13:12:33.388 0:11.148 SIP Handler:8520268 SIP > Handling PDU 2 INVITE <200> (with transaction) > 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP > Transaction 2 INVITE completed. > 2006/06/02 13:12:33.389 0:11.149 SIP Handler:8520268 SIP Set > targetAddress to sip:800@213.203.241.243 > 2006/06/02 13:12:33.390 0:11.150 SIP Handler:8520268 SIP > Adding authentication information > 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP > Adjusting transport to address udp$213.203.241.243:5060 > 2006/06/02 13:12:33.395 0:11.155 SIP Handler:8520268 SIP > Sending PDU on udp$213.203.241.243:5060 > ACK sip:800@213.203.241.243 SIP/2.0 > CSeq: 2 ACK > Via: SIP/2.0/UDP > 82.231.69.24:35065;branch=z9hG4bK6e2ca15b-96f0-da11-8388-000ea6217592;rport > From: "Huhardeaux Daniel" > ;tag=8c53075b-96f0-da11-8388-000ea6217592 > Call-ID: fa44075b-96f0-da11-8388-000ea6217592@nomade > To: ;tag=as5d2831d1 > Contact: > Proxy-Authorization: Digest username="104", realm="sip.tootai.net", > nonce="12d01d5d", uri="sip:800@213.203.241.243", > response="059defd67706254552a5c23eada565b5", algorithm=md5 > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE > Content-Length: 0 > Max-Forwards: 70 > > > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP > Received INVITE OK response > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:33.396 0:11.156 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 SIP RTP > payload type PCMU matched to codec G.711-uLaw-64k > 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k > 2006/06/02 13:12:33.397 0:11.157 SIP Handler:8520268 OpalCon > OpenSourceMediaStream for session 1 on Call[1]-EP[Default] > 2006/06/02 13:12:33.398 0:11.158 SIP Handler:8520268 OpalCon > Selected media stream PCM-16 -> G.711-uLaw-64k > 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 OpalMan > OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:34.196 0:11.956 SIP Handler:8520268 Call > PatchMediaStreams Call[1]-EP[Default] > 2006/06/02 13:12:34.196 0:11.957 SIP Handler:8520268 OpalCon > OpenSinkMediaStream > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session=1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon > OpenSinkMediaStream, selected PCM-16 -> G.711-uLaw-64k > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.197 0:11.957 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:34.197 0:11.958 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.198 0:11.958 SIP Handler:8520268 OpalMan > OnOpenMediaStream > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Patch > Added sink > from PCM-16 > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 16 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > to G.711-uLaw-64k > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 8 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > > 2006/06/02 13:12:34.203 0:11.963 SIP Handler:8520268 Codec > G711-uLaw-64k encoder created > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Patch > Added media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k using > transcoder PCM-16->G.711-uLaw-64k > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Media > Audio source data size set to 320 bytes and 2 buffers. > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k > 2006/06/02 13:12:34.204 0:11.964 SIP Handler:8520268 Call > GetOtherPartyConnection > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon > OpenSourceMediaStream for session 1 on > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon > Selected media stream G.711-uLaw-64k -> PCM-16 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 Call > CanDoMediaBypass > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalMan > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 SIP > IsMediaBypassPossible: session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 OpalCon > IsMediaBypassPossible: default returns FALSE > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.205 0:11.965 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalMan > OnOpenMediaStream > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade],OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 Call > PatchMediaStreams > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon > OpenSinkMediaStream Call[1]-EP[Default] session=1 > 2006/06/02 13:12:34.206 0:11.966 SIP Handler:8520268 OpalCon > OpenSinkMediaStream, selected G.711-uLaw-64k -> PCM-16 > 2006/06/02 13:12:34.513 0:12.274 SIP Handler:8520268 OpalMan > OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:34.514 0:12.274 SIP Handler:8520268 Patch > Added sink > from G.711-uLaw-64k > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 8 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > to PCM-16 > Clock Rate = 8000 > Frame Time = 8 > Max Bit Rate = 64000 > Max Frame Size = 16 > Needs Jitter = 1 > Rx Frames Per Packet = 240 > Tx Frames Per Packet = 30 > > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Codec > G711-uLaw-64k decoder created > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Media > Audio sink data size set to 320 bytes and 2 buffers. > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 Patch > Added media stream sink OpalAudioMediaStream-Sink-PCM-16 using > transcoder G.711-uLaw-64k->PCM-16 > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.515 0:12.275 SIP Handler:8520268 OpalCon > New patch created > 2006/06/02 13:12:34.525 0:12.285 SIP Handler:8520268 OpalCon > OpenSourceMediaStream (already opened) for session 1 on > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.527 0:12.287 SIP Handler:8520268 RTP_UDP > SetRemoteSocketInfo: session=1 data channel, new=213.203.241.243:7166, > local=82.231.69.24:35010-35011, remote=0.0.0.0:0-0 > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 SIP > Could not find SDP media description for Video > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 OpalMan > OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 Call > OnConnected Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.528 0:12.288 SIP Handler:8520268 PCSS > SetConnected() > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 > GMPCSSEndpoint PCSS connection established > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 > GMManager Will establish the connection > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 OpalMan > OnEstablished Call[1]-EP[Default] > 2006/06/02 13:12:34.529 0:12.289 SIP Handler:8520268 Call > OnEstablished Call[1]-EP[Default] > 2006/06/02 13:12:34.540 0:12.300 SIP Handler:8520268 Call > GetMediaFormats for Call[1]-EP[Default] > G.711-uLaw-64k > > 2006/06/02 13:12:34.541 0:12.301 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k > 2006/06/02 13:12:34.542 0:12.302 SIP Handler:8520268 OpalCon > OpenSourceMediaStream (already opened) for session 1 on > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.543 0:12.303 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call > GetMediaFormats for > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > G.711-uLaw-64k > > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 with media G.711-uLaw-64k > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 OpalCon > OpenSourceMediaStream (already opened) for session 1 on > Call[1]-EP[Default] > 2006/06/02 13:12:34.551 0:12.311 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 1 adjusted media to G.711-uLaw-64k > 2006/06/02 13:12:34.552 0:12.312 SIP Handler:8520268 Call > OpenSourceMediaStreams for session 2 with media G.711-uLaw-64k > 2006/06/02 13:12:34.553 0:12.313 Media Patch:8175708 Patch > Thread started for Patch OpalAudioMediaStream-Source-PCM-16 -> > OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:34.556 0:12.316 SIP Handler:8520268 Media > Starting thread Media Patch:8175708 > 2006/06/02 13:12:34.557 0:12.317 Media Patch:8527348 Patch > Thread started for Patch OpalRTPMediaStream-Source-G.711-uLaw-64k -> > OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:34.568 0:12.329 Media Patch:8527348 RTP > Jitter buffer created: size=101 delay=160-4000/160 (20ms) obj=0x8526b30 > 2006/06/02 13:12:34.572 0:12.333 RTP Jitter:8526b30 RTP > Jitter RTP receive thread started: 0x8526b30 > 2006/06/02 13:12:34.574 0:12.334 RTP Jitter:8526b30 RTP > First receive data: ver=2 pt=GSM psz=33 m=0 x=0 seq=39915 ts=160 > src=824302623 ccnt=0 > 2006/06/02 13:12:34.580 0:12.341 SIP Handler:8520268 Media > Starting thread Media Patch:8527348 > 2006/06/02 13:12:34.581 0:12.341 SIP Handler:8520268 OpalCon > Media stream threads started. > 2006/06/02 13:12:34.582 0:12.342 SIP Handler:8520268 OpalCon > Media stream threads started. > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP > Found existing session 1 > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 RTP > Found existing session 2 > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 > GMManager Will establish the connection > 2006/06/02 13:12:34.606 0:12.366 SIP Handler:8520268 OpalMan > OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.607 0:12.367 SIP Handler:8520268 Call > OnEstablished Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:34.610 0:12.371 SIP Handler:8520268 SIP > Awaiting next PDU. > 2006/06/02 13:12:34.648 0:12.408 Media Patch:8527348 RTP > Jitter buffer length exceeded > 2006/06/02 13:12:34.649 0:12.409 Media Patch:8527348 RTP > Jitter buffer length exceed was prior to first write. Not increasing > buffer size > 2006/06/02 13:12:35.277 0:13.037 Media Patch:8175708 RTP > First sent data: ver=2 pt=PCMU psz=160 m=1 x=0 seq=1460 ts=0 > src=703395120 ccnt=0 > 2006/06/02 13:12:35.608 0:13.368 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:35.609 0:13.369 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:36.137 0:13.898 RTP Jitter:8526b30 RTP > Receive statistics: packets=101 octets=3714 lost=0 tooLate=0 order=0 > avgTime=15 maxTime=1556 minTime=0 jitter=16 maxJitter=188 > 2006/06/02 13:12:36.573 0:14.333 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (9760) > 2006/06/02 13:12:36.614 0:14.374 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:36.615 0:14.375 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:36.974 0:14.734 RTP Jitter:8526b30 RTP > Jitter buffer continuously full, throwing away entire buffer. > 2006/06/02 13:12:36.995 0:14.756 RTP Jitter:8526b30 RTP > Jitter buffer full, threw away 21 oldest frames > 2006/06/02 13:12:37.374 0:15.134 RTP Jitter:8526b30 RTP > Receive statistics: packets=201 octets=19714 lost=0 tooLate=0 order=0 > avgTime=12 maxTime=23 minTime=0 jitter=0 maxJitter=188 > 2006/06/02 13:12:37.620 0:15.380 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:37.621 0:15.381 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:37.820 0:15.580 Media Patch:8175708 RTP > Transmit statistics: packets=101 octets=16160 avgTime=25 maxTime=48 > minTime=23 > 2006/06/02 13:12:38.624 0:16.384 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:38.625 0:16.385 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:38.993 0:16.753 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (29120) > 2006/06/02 13:12:39.374 0:17.134 RTP Jitter:8526b30 RTP > Receive statistics: packets=301 octets=35714 lost=0 tooLate=0 order=0 > avgTime=20 maxTime=26 minTime=14 jitter=1 maxJitter=188 > 2006/06/02 13:12:39.395 0:17.155 RTP Jitter:8526b30 RTP > Jitter buffer continuously full, throwing away entire buffer. > 2006/06/02 13:12:39.415 0:17.176 RTP Jitter:8526b30 RTP > Jitter buffer full, threw away 21 oldest frames > 2006/06/02 13:12:39.632 0:17.392 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:39.633 0:17.393 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:40.384 0:18.144 Media Patch:8175708 RTP > Transmit statistics: packets=201 octets=32160 avgTime=25 maxTime=44 > minTime=22 > 2006/06/02 13:12:40.640 0:18.400 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:40.641 0:18.401 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:41.373 0:19.133 RTP Jitter:8526b30 RTP > Receive statistics: packets=401 octets=51714 lost=0 tooLate=0 order=0 > avgTime=19 maxTime=26 minTime=13 jitter=1 maxJitter=188 > 2006/06/02 13:12:41.413 0:19.173 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (48480) > 2006/06/02 13:12:41.648 0:19.424 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:41.665 0:19.425 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:41.813 0:19.573 RTP Jitter:8526b30 RTP > Jitter buffer continuously full, throwing away entire buffer. > 2006/06/02 13:12:41.833 0:19.593 RTP Jitter:8526b30 RTP > Jitter buffer full, threw away 21 oldest frames > 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:42.672 0:20.432 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:42.920 0:20.680 Media Patch:8175708 RTP > Transmit statistics: packets=301 octets=48160 avgTime=25 maxTime=49 > minTime=22 > 2006/06/02 13:12:43.378 0:21.139 RTP Jitter:8526b30 RTP > Receive statistics: packets=501 octets=67714 lost=0 tooLate=0 order=0 > avgTime=20 maxTime=27 minTime=12 jitter=1 maxJitter=188 > 2006/06/02 13:12:43.696 0:21.457 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:43.697 0:21.457 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot Call > Clearing Call[1] reason=EndedByLocalUser > 2006/06/02 13:12:43.812 0:21.572 ekiga-snapshot OpalCon > Releasing Call[1]-EP[Default] > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > Call end reason for Default set to EndedByLocalUser > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > SetPhase from EstablishedPhase to ReleasingPhase > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > Releasing Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade] > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > Call end reason for fa44075b-96f0-da11-8388-000ea6217592@nomade set to > EndedByLocalUser > 2006/06/02 13:12:43.813 0:21.573 ekiga-snapshot OpalCon > SetPhase from EstablishedPhase to ReleasingPhase > 2006/06/02 13:12:43.820 0:21.581 OnRelease:856e8a0 OpalCon > OnReleased Call[1]-EP[Default] > 2006/06/02 13:12:43.822 0:21.583 OnRelease:856e8a0 Media > Closing raw media stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.824 0:21.584 OnRelease:856e8a0 Media > Closing stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.825 0:21.585 OnRelease:856e8a0 Media > Disconnecting OpalAudioMediaStream-Source-PCM-16 from patch thread Patch > OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.827 0:21.587 OnRelease:856e8a0 Patch > Closing media patch Patch OpalAudioMediaStream-Source-PCM-16 -> > OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.829 0:21.589 OnRelease:856e8a0 Media > Closing raw media stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.830 0:21.590 OnRelease:856e8a0 Media > Closing stream OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.831 0:21.591 OnRelease:84f8c00 SIP > OnReleased: > Call[1]-EP[fa44075b-96f0-da11-8388-000ea6217592@nomade], phase = > ReleasingPhase > 2006/06/02 13:12:43.833 0:21.593 OnRelease:84f8c00 OpalCon > SetPhase from ReleasingPhase to ReleasingPhase > 2006/06/02 13:12:43.834 0:21.594 RTP Jitter:8526b30 RTP > Jitter buffer full, throwing away oldest frame (67840) > 2006/06/02 13:12:43.836 0:21.596 OnRelease:84f8c00 SIP > Transaction 4 BYE created. > 2006/06/02 13:12:43.842 0:21.603 OnRelease:84f8c00 Media > Closing RTP for OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.844 0:21.604 OnRelease:84f8c00 RTP_UDP > Session 1, Shutting down write. > 2006/06/02 13:12:43.845 0:21.605 OnRelease:84f8c00 Media > Closing stream OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.846 0:21.606 OnRelease:84f8c00 Media > Disconnecting OpalRTPMediaStream-Sink-G.711-uLaw-64k from patch thread > Patch OpalAudioMediaStream-Source-PCM-16 -> > OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.848 0:21.609 OnRelease:84f8c00 Patch > Removing media stream sink OpalRTPMediaStream-Sink-G.711-uLaw-64k > 2006/06/02 13:12:43.855 0:21.626 OnRelease:84f8c00 Media > Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.867 0:21.627 OnRelease:84f8c00 RTP_UDP > Session 1, Shutting down read. > 2006/06/02 13:12:43.868 0:21.628 OnRelease:84f8c00 Media > Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.869 0:21.630 OnRelease:84f8c00 Media > Disconnecting OpalRTPMediaStream-Source-G.711-uLaw-64k from patch thread > Patch OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.893 0:21.653 Media Patch:8175708 Patch > Thread ended for Patch OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.893 0:21.653 OnRelease:84f8c00 Patch > Closing media patch Patch OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.916 0:21.676 RTP Jitter:8526b30 RTP_UDP > Session 1, Read shutdown. > 2006/06/02 13:12:43.917 0:21.677 RTP Jitter:8526b30 RTP > Jitter RTP receive thread ended > 2006/06/02 13:12:43.917 0:21.677 OnRelease:84f8c00 Media > Closing RTP for OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.918 0:21.678 OnRelease:84f8c00 RTP_UDP > Session 1, Shutting down read. > 2006/06/02 13:12:43.919 0:21.679 OnRelease:84f8c00 Media > Closing stream OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.922 0:21.683 OnRelease:856e8a0 Patch > Waiting for media patch thread to stop Patch > OpalAudioMediaStream-Source-PCM-16 > 2006/06/02 13:12:43.926 0:21.686 OnRelease:856e8a0 Patch > Media patch thread Patch OpalAudioMediaStream-Source-PCM-16 destroyed. > 2006/06/02 13:12:43.930 0:21.691 OnRelease:856e8a0 Media > Closing raw media stream OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:43.932 0:21.693 OnRelease:856e8a0 Media > Closing stream OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:43.933 0:21.694 OnRelease:856e8a0 Media > Disconnecting OpalAudioMediaStream-Sink-PCM-16 from patch thread Patch > OpalRTPMediaStream-Source-G.711-uLaw-64k > 2006/06/02 13:12:43.956 0:21.717 OnRelease:856e8a0 Patch > Removing media stream sink OpalAudioMediaStream-Sink-PCM-16 > 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:44.696 0:22.456 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:45.696 0:23.456 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:45.697 0:23.457 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:46.700 0:24.460 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:47.704 0:25.464 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:48.708 0:26.468 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:48.709 0:26.469 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:49.713 0:27.473 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:50.712 0:28.473 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:50.713 0:28.473 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:51.716 0:29.477 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:51.717 0:29.477 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:52.716 0:30.477 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:52.717 0:30.477 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:53.717 0:31.477 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:54.721 0:32.481 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:55.725 0:33.485 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:56.730 0:34.490 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:57.733 0:35.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:57.734 0:35.494 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:58.733 0:36.493 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:12:59.733 0:37.493 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:00.733 0:38.493 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:01.763 0:39.523 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:02.777 0:40.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:02.778 0:40.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:03.777 0:41.537 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:04.369 0:42.129 Housekeeper SIP Set > state Terminated_Success for transaction 1 INVITE > 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:04.777 0:42.537 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:05.777 0:43.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:05.777 0:43.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:06.613 0:44.374 Housekeeper SIP Set > state Terminated_Success for transaction 2 INVITE > 2006/06/02 13:13:06.777 0:44.537 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:06.778 0:44.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:07.777 0:45.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:07.778 0:45.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:08.778 0:46.538 Housekeeper RTP > Found existing session 2 > 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP > Found existing session 1 > 2006/06/02 13:13:09.778 0:47.538 Housekeeper RTP > Found existing session 2 > Processus arrêté > -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From devel@tootai.net Sat Jun 3 19:25:05 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EBBDB3B06DD for ; Sat, 3 Jun 2006 19:24:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02787-06 for ; Sat, 3 Jun 2006 19:24:40 -0400 (EDT) Received: from mail1.tootai.net (ns1.tootai.net [82.231.69.24]) by menubar.gnome.org (Postfix) with ESMTP id 16D123B0756 for ; Sat, 3 Jun 2006 19:24:35 -0400 (EDT) Received: from [192.168.0.17] (unknown [192.168.0.17]) by mail1.tootai.net (Postfix) with ESMTP id 9C142398B99 for ; Sun, 4 Jun 2006 01:24:35 +0200 (CEST) Message-ID: <44821A19.10001@tootai.net> Date: Sun, 04 Jun 2006 01:24:09 +0200 From: Daniel Huhardeaux Organization: TOOTAi User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 References: <4481A6AF.2060703@tootai.net> <1149357648.2414.34.camel@golgoth01> In-Reply-To: <1149357648.2414.34.camel@golgoth01> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[AWL=0.000, BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 23:25:05 -0000 Damien Sandras wrote: > [...] >> When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is >> started, connection is showed with PCMU (why not GSM?), see the traffic >> in/out (~6 kB) but have no audio. >> >> > > Asterisk answers with 200 OK indicating that the call should be done > with PCMU. > Ok, but as GSM has my preference in Ekiga as well as in asterisk, the call should be done in GSM > [...] > > Please try with 2.0.2. Craig has done work in CVS and things are > potentially broken. If the problem persists once plugins support is in > CVS, please report again. > I use the Ekiga snapshot SID version which don't provide newest version as the one mentioned :-( Kilian? BTW, asterisk is 1.2-r16008 from 29/03/2006 - SVN stable. > > >> If I deactivate GSM codec, everything is fine. Below you will find a d4 >> output from the call. >> >> > > I do not think activating GSM or not has any influence. The problem is > probably something else. > I would like to believe you, but this problem happends only with GSM codec. -- Daniel From ebischoff@nerim.net Sun Jun 4 11:52:03 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C970B3B011B for ; Sun, 4 Jun 2006 11:52:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26992-10 for ; Sun, 4 Jun 2006 11:52:01 -0400 (EDT) Received: from mallaury.nerim.net (smtp-100-sunday.noc.nerim.net [62.4.17.100]) by menubar.gnome.org (Postfix) with ESMTP id 9601A3B00CE for ; Sun, 4 Jun 2006 11:52:01 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by mallaury.nerim.net (Postfix) with ESMTP id 32E474F399 for ; Sun, 4 Jun 2006 17:51:50 +0200 (CEST) From: =?iso-8859-1?q?=C9ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Sun, 4 Jun 2006 17:52:11 +0200 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606041752.12228.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.535 tagged_above=-999 required=2 tests=[AWL=0.064, BAYES_00=-2.599] X-Spam-Score: -2.535 X-Spam-Level: Subject: [GnomeMeeting-devel-list] KDE address book support in Ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 15:52:04 -0000 (this message has already been sent by mistake on gnomemeeting-list a few=20 hours ago, sorry for the crossposting) Hi everyone, A small notice to let you know that I am working on adding support for KDE= =20 Address Book (kab) to Ekiga. I already have some early "proof of concept"=20 code working (see screenshot at=20 http://opensource.bureau-cornavin.com/ekiga/screenshot.png). KDE Address Book is an application of its own, but it's also a library that= is=20 used by most KDE applications (KMail, Kontact, KPilot, Kopete, ...), and al= so=20 by third-party applications like OpenOffice.org. It can use several=20 "resources" for its addresses: local VCard files, remote LDAP servers, etc. Before anyone does the remark : YES it would be better if Evolution/GNOME a= nd=20 KDE shared the same address book library. But currently we have to live wit= h=20 this situation... There are two issues that currently slow me down a bit: 1) Ekiga's address book model distinguishes between "local" and "remote"=20 address books. This makes little sense for kab which can transparently use= =20 both local and remote resources. In a first time, my code will act as a=20 "local" address book, just like Evolution address book. 2) KDE address book currently has no field for SIP nor H323 addresses. I am= =20 currently trying to contact Will Stephenson (KDE) who added support for Sky= pe=20 addresses to see how we could do that cleanly. Of course, this functionality will remain optional and require no library f= or=20 those who can live without it :-). Any suggestion, wish, encouragement, criticism, and/or offer for help is=20 welcome. Hoping that helps, =2D-=20 =C9ric From jpuydt@free.fr Sun Jun 4 12:08:13 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C97F03B009F; Sun, 4 Jun 2006 12:08:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28175-05; Sun, 4 Jun 2006 12:08:00 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 880B03B0187; Sun, 4 Jun 2006 12:08:00 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-54-82-251-83-65.adsl.proxad.net [82.251.83.65]) by smtp5-g19.free.fr (Postfix) with ESMTP id 3EBD2250F8; Sun, 4 Jun 2006 18:07:59 +0200 (CEST) Message-ID: <44830581.8080503@free.fr> Date: Sun, 04 Jun 2006 18:08:33 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting mailing list , GnomeMeeting development mailing list References: <200606041116.31785.ebischoff@nerim.net> In-Reply-To: <200606041116.31785.ebischoff@nerim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: Cc: Subject: [GnomeMeeting-devel-list] Re: [GnomeMeeting-list] KDE address book support in Ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 16:08:14 -0000 Éric Bischoff a écrit : > A small notice to let you know that I am working on adding support for KDE > Address Book (kab) to Ekiga. I already have some early "proof of concept" > code working (see screenshot at > http://opensource.bureau-cornavin.com/ekiga/screenshot.png). I know :-) > KDE Address Book is an application of its own, but it's also a library that is > used by most KDE applications (KMail, Kontact, KPilot, Kopete, ...), and also > by third-party applications like OpenOffice.org. It can use several > "resources" for its addresses: local VCard files, remote LDAP servers, etc. Nice. > Before anyone does the remark : YES it would be better if Evolution/GNOME and > KDE shared the same address book library. But currently we have to live with > this situation... Indeed. > There are two issues that currently slow me down a bit: > > 1) Ekiga's address book model distinguishes between "local" and "remote" > address books. This makes little sense for kab which can transparently use > both local and remote resources. In a first time, my code will act as a > "local" address book, just like Evolution address book. I'm refactoring the addressbook ; and I don't like that distinction either. I'm still trying to convince Damien and Jan my ideas can fly. I think Jan is already beginning to see where I go ; Damien hasn't had the time to dive into it. > 2) KDE address book currently has no field for SIP nor H323 addresses. I am > currently trying to contact Will Stephenson (KDE) who added support for Skype > addresses to see how we could do that cleanly. Ok. > Of course, this functionality will remain optional and require no library for > those who can live without it :-). Ok too. We'll go with a --enable-kde at compile time. Then later on we'll see if it's possible to do something at runtime. > Any suggestion, wish, encouragement, criticism, and/or offer for help is > welcome. * Suggestion: use -devel-list ;-) * Wish: what you have written will work well with what I have in mind * Encouragement: I like the idea very much, and appreciate your working on ekiga * Criticism: couldn't you do that either long before or just after the re-architecturing? ;-) * Offer for help: uh... I'm refactoring, and it may help (the api I ask from "addressbooks" is much lighter). Snark on #ekiga From ebischoff@nerim.net Sun Jun 4 12:36:03 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6EBCD3B00E9 for ; Sun, 4 Jun 2006 12:36:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29967-09 for ; Sun, 4 Jun 2006 12:36:02 -0400 (EDT) Received: from kraid.nerim.net (smtp-100-sunday.nerim.net [62.4.16.100]) by menubar.gnome.org (Postfix) with ESMTP id 16E7B3B009F for ; Sun, 4 Jun 2006 12:36:01 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id C772E40E31 for ; Sun, 4 Jun 2006 18:35:59 +0200 (CEST) From: =?iso-8859-1?q?=C9ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Re: [GnomeMeeting-list] KDE address book support in Ekiga Date: Sun, 4 Jun 2006 18:36:11 +0200 User-Agent: KMail/1.8.2 References: <200606041116.31785.ebischoff@nerim.net> <44830581.8080503@free.fr> In-Reply-To: <44830581.8080503@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606041836.12390.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.553 tagged_above=-999 required=2 tests=[AWL=0.046, BAYES_00=-2.599] X-Spam-Score: -2.553 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 16:36:03 -0000 Le Dimanche 4 Juin 2006 18:08, Julien PUYDT a =E9crit=A0: > I know :-) I know you know ;-). > I'm refactoring the addressbook ; and I don't like that distinction > either. I'm still trying to convince Damien and Jan my ideas can fly. I > think Jan is already beginning to see where I go ; Damien hasn't had the > time to dive into it. Okay, I have not written much code yet, so there will be no problem to adap= t=20 it to your new layout, whatever it will be. > Ok too. We'll go with a --enable-kde at compile time. Then later on > we'll see if it's possible to do something at runtime. Yes, I was figuring out something like that. > * Suggestion: use -devel-list ;-) Yup, sorry... :-/ > * Wish: what you have written will work well with what I have in mind See above, I have not written much yet, and it's "obvious" code anyway, so= =20 there's no problem even if I have to restart from scratch. > * Encouragement: I like the idea very much, and appreciate your working > on ekiga Thank you for the warm welcome, Julien :-). > * Criticism: couldn't you do that either long before or just after the > re-architecturing? ;-) No. Did you hear about Murphy's law ? ;-) > * Offer for help: uh... I'm refactoring, and it may help (the api I ask > from "addressbooks" is much lighter). Indeed. =2D-=20 =C9ric From dsandras@seconix.com Mon Jun 5 15:24:19 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 115A33B038A for ; Mon, 5 Jun 2006 15:24:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24872-10 for ; Mon, 5 Jun 2006 15:24:15 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 482C73B0420 for ; Mon, 5 Jun 2006 15:24:15 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 73E6049870 for ; Mon, 5 Jun 2006 21:07:08 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23599-08 for ; Mon, 5 Jun 2006 21:06:52 +0200 (CEST) Received: from [192.168.0.161] (39.128-245-81.adsl-dyn.isp.belgacom.be [81.245.128.39]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 4C3C84986E for ; Mon, 5 Jun 2006 21:06:52 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] GSM codec problem with Snapshot 2.0.1-20060521-01 From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44821A19.10001@tootai.net> References: <4481A6AF.2060703@tootai.net> <1149357648.2414.34.camel@golgoth01> <44821A19.10001@tootai.net> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 05 Jun 2006 21:24:50 +0200 Message-Id: <1149535490.2508.3.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.455 tagged_above=-999 required=2 tests=[AWL=0.009, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.455 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 19:24:19 -0000 Le dimanche 04 juin 2006 à 01:24 +0200, Daniel Huhardeaux a écrit : > Damien Sandras wrote: > > [...] > >> When I place a call with GSM, PCMU and PCMA activated in Ekiga, call is > >> started, connection is showed with PCMU (why not GSM?), see the traffic > >> in/out (~6 kB) but have no audio. > >> > >> > > > > Asterisk answers with 200 OK indicating that the call should be done > > with PCMU. > > > Ok, but as GSM has my preference in Ekiga as well as in asterisk, the > call should be done in GSM I agree, but if you look at the 200 OK sent by Asterisk, GSM is not part of it, while it is part of the INVITE sent by Ekiga. > > I do not think activating GSM or not has any influence. The problem is > > probably something else. > > > I would like to believe you, but this problem happends only with GSM codec. Is there some way I could reproduce it here? -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Mon Jun 5 17:45:53 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 776D43B03A0; Mon, 5 Jun 2006 17:45:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02457-06; Mon, 5 Jun 2006 17:45:52 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 22F123B0295; Mon, 5 Jun 2006 17:45:52 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 8C0904984F; Mon, 5 Jun 2006 23:28:44 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29850-10; Mon, 5 Jun 2006 23:28:37 +0200 (CEST) Received: from [192.168.0.161] (39.128-245-81.adsl-dyn.isp.belgacom.be [81.245.128.39]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 089E44984C; Mon, 5 Jun 2006 23:28:36 +0200 (CEST) From: Damien Sandras To: gnomemeeting-list@gnome.org Content-Type: text/plain Date: Mon, 05 Jun 2006 23:46:32 +0200 Message-Id: <1149543992.2508.40.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.455 tagged_above=-999 required=2 tests=[AWL=0.009, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.455 X-Spam-Level: Cc: gnomemeeting-devel-list@gnome.org Subject: [GnomeMeeting-devel-list] Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 21:45:53 -0000 Hello to all, Ekiga 2.0.2 is available on http://www.ekiga.org More packages will be added as they are released. Thanks a lot to all supporters of the project! -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From simon@mungewell.org Mon Jun 5 18:20:27 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1BD3C3B0389 for ; Mon, 5 Jun 2006 18:20:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04790-06 for ; Mon, 5 Jun 2006 18:20:25 -0400 (EDT) Received: from pd3mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by menubar.gnome.org (Postfix) with ESMTP id 864BD3B04F7 for ; Mon, 5 Jun 2006 18:20:25 -0400 (EDT) Received: from pd3mr3so.prod.shaw.ca (pd3mr3so-qfe3.prod.shaw.ca [10.0.141.179]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0E00FK5RE0KD10@l-daemon> for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:20:24 -0600 (MDT) Received: from pn2ml4so.prod.shaw.ca ([10.0.121.148]) by pd3mr3so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0E002HJRE0FOB0@pd3mr3so.prod.shaw.ca> for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:20:24 -0600 (MDT) Received: from slone.mungewell.org ([68.146.98.7]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0E00GPGRE0XH60@l-daemon> for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:20:24 -0600 (MDT) Received: from simon by slone.mungewell.org with local (Exim 4.61) (envelope-from ) id 1FnNDw-0002Wd-6Y for gnomemeeting-devel-list@gnome.org; Mon, 05 Jun 2006 16:07:00 -0600 Date: Mon, 05 Jun 2006 16:07:00 -0600 From: simon Subject: Re: [GnomeMeeting-devel-list] Ekiga 2.0.2 In-reply-to: <1149543992.2508.40.camel@golgoth01> To: GnomeMeeting development mailing list Message-id: <20060605220700.GA9699@mungewell.org> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline References: <1149543992.2508.40.camel@golgoth01> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[AWL=-0.000, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 22:20:27 -0000 On Mon, Jun 05, 2006 at 11:46:32PM +0200, Damien Sandras wrote: > Hello to all, > > > Ekiga 2.0.2 is available on http://www.ekiga.org > Woo Woo another release party! What only a '.' release - oh, guess we'll have to share a can of Pop ;-) Seriously though, Thanks to Damien and all the other developers. Simon From siti@orcon.net.nz Tue Jun 6 05:25:31 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5963D3B00EF for ; Tue, 6 Jun 2006 05:25:31 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29810-06 for ; Tue, 6 Jun 2006 05:25:29 -0400 (EDT) Received: from dbmail-mx2.orcon.net.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id AB0663B00E2 for ; Tue, 6 Jun 2006 05:25:28 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx2.orcon.net.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k569PFih007843 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Jun 2006 21:25:16 +1200 Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Stephen Cook To: Derek Smithies In-Reply-To: References: Content-Type: text/plain Date: Tue, 06 Jun 2006 21:25:24 +1200 Message-Id: <1149585924.16149.8.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx2.orcon.net.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.532 tagged_above=-999 required=2 tests=[AWL=0.068, BAYES_00=-2.599] X-Spam-Score: -2.532 X-Spam-Level: Cc: GnomeMeeting development mailing list X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 09:25:31 -0000 On Tue, 2006-06-06 at 10:32 +1200, Derek Smithies wrote: > Hi, > Ok, just back from a long weekend (three days of not touching a computer) > and back into things. > > Stephen, I saw some comment from you on this topic at: > > http://siti.geek.nz/web/content/blogsection/4/26/ > > interesting - very interesting.. > > hey - now that is a coincidence. > I studied at Canterbury University also. Well that's cool :) Could you send me a private email with an instant messaging address that you use. BTW Damien and others we will keep as much information on the mailing list. To give you guys an update I have IAX2 calls going in ekiga although it needs a lot of work :). Then obviously the improvements to IAX2 in opal... > > > ============== > > Craig, I do not think moving to an offline conversation with Stephen is > > a good idea. Julien and myself are supposed to mentor the project. Your > > help is of course welcome, but we have to be kept informed. > Sorry Damien, but there will be a lot of offline comment. > I suspect that Stephen and I live in the same city. Sending a CC of phone > conversations etc will not be easy. > > I will endeavour though to keep you informed of what is happening, and we > can move everything forward towards the nirvana of iax2, sip, and h323 in > gnomemeeting. > > > =========================== > > Stephen, > > I am really happy to work with you on IAX2 - really happy. This > would be great for the project. It should be a good learning experience for me and I am sure it'll be good fun :) From dsandras@seconix.com Tue Jun 6 05:29:32 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 40D9E3B0A68 for ; Tue, 6 Jun 2006 05:29:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30841-02 for ; Tue, 6 Jun 2006 05:29:30 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 9F34C3B0A5C for ; Tue, 6 Jun 2006 05:29:30 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id DDF8E493CB; Tue, 6 Jun 2006 11:12:16 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30209-02; Tue, 6 Jun 2006 11:11:57 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 679F9492DA; Tue, 6 Jun 2006 11:11:57 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Damien Sandras To: Stephen Cook In-Reply-To: <1149585924.16149.8.camel@siti> References: <1149585924.16149.8.camel@siti> Content-Type: text/plain; charset=ISO-8859-15 Date: Tue, 06 Jun 2006 11:29:17 +0200 Message-Id: <1149586157.2470.27.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Cc: Derek Smithies , GnomeMeeting development mailing list X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 09:29:32 -0000 Le mardi 06 juin 2006 à 21:25 +1200, Stephen Cook a écrit : > On Tue, 2006-06-06 at 10:32 +1200, Derek Smithies wrote: > > Hi, > > Ok, just back from a long weekend (three days of not touching a computer) > > and back into things. > > > > Stephen, I saw some comment from you on this topic at: > > > > http://siti.geek.nz/web/content/blogsection/4/26/ > > > > interesting - very interesting.. > > > > hey - now that is a coincidence. > > I studied at Canterbury University also. > Well that's cool :) > > Could you send me a private email with an instant messaging address that > you use. > > BTW Damien and others we will keep as much information on the mailing > list. > > To give you guys an update I have IAX2 calls going in ekiga although it > needs a lot of work :). Then obviously the improvements to IAX2 in > opal... > Excellent ;-) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From jpuydt@free.fr Tue Jun 6 06:41:15 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 18B6B3B00E0 for ; Tue, 6 Jun 2006 06:41:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10263-10 for ; Tue, 6 Jun 2006 06:41:14 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id BD54A3B00D2 for ; Tue, 6 Jun 2006 06:41:13 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-57-82-249-29-56.adsl.proxad.net [82.249.29.56]) by smtp1-g19.free.fr (Postfix) with ESMTP id 909369AAC7 for ; Tue, 6 Jun 2006 12:41:12 +0200 (CEST) Message-ID: <44855BEC.1040306@free.fr> Date: Tue, 06 Jun 2006 12:41:48 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga References: <1149585924.16149.8.camel@siti> In-Reply-To: <1149585924.16149.8.camel@siti> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.585 tagged_above=-999 required=2 tests=[AWL=0.014, BAYES_00=-2.599] X-Spam-Score: -2.585 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 10:41:15 -0000 Stephen Cook a écrit : > Could you send me a private email with an instant messaging address that > you use. > > BTW Damien and others we will keep as much information on the mailing > list. > > To give you guys an update I have IAX2 calls going in ekiga although it > needs a lot of work :). Then obviously the improvements to IAX2 in > opal... This sounds great :-) Do all codecs work ok ? Could you make a short list of what is lacking, so your progress can easily be seen ? :-) Snark From siti@orcon.net.nz Tue Jun 6 08:02:29 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0E2D93B008B for ; Tue, 6 Jun 2006 08:02:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19082-05 for ; Tue, 6 Jun 2006 08:02:18 -0400 (EDT) Received: from dbmail-mx3.orcon.co.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 7C3DD3B0A9D for ; Tue, 6 Jun 2006 08:01:24 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx3.orcon.co.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k56C17Ej021180 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 7 Jun 2006 00:01:12 +1200 Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga From: Stephen Cook To: GnomeMeeting development mailing list In-Reply-To: <44855BEC.1040306@free.fr> References: <1149585924.16149.8.camel@siti> <44855BEC.1040306@free.fr> Content-Type: text/plain; charset=utf-8 Date: Wed, 07 Jun 2006 00:01:17 +1200 Message-Id: <1149595277.17468.7.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx3.orcon.co.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.495 tagged_above=-999 required=2 tests=[AWL=-0.031, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.495 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 12:02:29 -0000 On Tue, 2006-06-06 at 12:41 +0200, Julien PUYDT wrote: > Stephen Cook a écrit : > > Could you send me a private email with an instant messaging address that > > you use. > > > > BTW Damien and others we will keep as much information on the mailing > > list. > > > > To give you guys an update I have IAX2 calls going in ekiga although it > > needs a lot of work :). Then obviously the improvements to IAX2 in > > opal... > > This sounds great :-) > > Do all codecs work ok ? I have only tried ULAW > > Could you make a short list of what is lacking, so your progress can > easily be seen ? In Ekiga: * Url handler for IAX2 * If I have time in the future -- Refactor protocol components in ekiga In Iax2: * Call Hold * Transfer Calls * Register > > :-) > > Snark > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list From jan.schampera@web.de Tue Jun 6 11:41:54 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 300F43B00A7 for ; Tue, 6 Jun 2006 11:41:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01645-10 for ; Tue, 6 Jun 2006 11:41:52 -0400 (EDT) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by menubar.gnome.org (Postfix) with ESMTP id 5016E3B0117 for ; Tue, 6 Jun 2006 11:41:52 -0400 (EDT) Received: from fwd28.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1Fndgj-000497-06; Tue, 06 Jun 2006 17:41:49 +0200 Received: from mail.home.thebonsai.de (SxWWnGZHgenZylg6UcgKDR7M2nKdws-wslY10mn82PtIepb06FcVZ4@[84.147.103.162]) by fwd28.sul.t-online.de with esmtp id 1Fndgc-1VKS9o0; Tue, 6 Jun 2006 17:41:42 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id B18576B0FF for ; Tue, 6 Jun 2006 17:41:40 +0200 (CEST) Date: Tue, 6 Jun 2006 17:37:41 +0200 From: Jan Schampera To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] IAX2 In Ekiga Message-ID: <20060606173741.7739fbf0@localhost.localdomain> In-Reply-To: <1149595277.17468.7.camel@siti> References: <1149585924.16149.8.camel@siti> <44855BEC.1040306@free.fr> <1149595277.17468.7.camel@siti> Organization: private X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: SxWWnGZHgenZylg6UcgKDR7M2nKdws-wslY10mn82PtIepb06FcVZ4@t-dialin.net X-TOI-MSGID: d621850d-8c24-4c96-bc80-424b3278e7ee X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.966 tagged_above=-999 required=2 tests=[AWL=0.632, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.966 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 15:41:54 -0000 On Wed, 07 Jun 2006 00:01:17 +1200 Stephen Cook wrote: > In Ekiga: > * Url handler for IAX2 > * If I have time in the future -- Refactor protocol components in > ekiga > > In Iax2: > * Call Hold > * Transfer Calls > * Register I X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C93A63B023C for ; Tue, 6 Jun 2006 18:32:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26160-07 for ; Tue, 6 Jun 2006 18:32:35 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by menubar.gnome.org (Postfix) with ESMTP id EE5BE3B0124 for ; Tue, 6 Jun 2006 18:32:34 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x31so57152pye for ; Tue, 06 Jun 2006 15:32:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=PWNZjwnHiPmpdYl2MsXZ9YZF9d4xYPXUg1ADy6s6gr7kpZpuMn+pMk4SiPqw6G91hexsOp1xDFUNDwMZyQ+X01mIY9TDqR0zrylP3BBJTKYCjcgQm4+vLCMe9AVXFuvgQ8NYOFrWwmRpr+zSS1OaVc2h2FssBRFPxlSabyu06bg= Received: by 10.35.76.9 with SMTP id d9mr79929pyl; Tue, 06 Jun 2006 15:32:33 -0700 (PDT) Received: by 10.35.9.3 with HTTP; Tue, 6 Jun 2006 15:32:33 -0700 (PDT) Message-ID: <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> Date: Tue, 6 Jun 2006 18:32:33 -0400 From: "mcquaid mcquaid" To: "GnomeMeeting development mailing list" Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode In-Reply-To: <1149246461.2966.28.camel@golgoth01> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7731_6834590.1149633153798" References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> <1149246461.2966.28.camel@golgoth01> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.041 tagged_above=-999 required=2 tests=[AWL=0.062, BAYES_00=-2.599, HTML_40_50=0.496, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.041 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 22:32:38 -0000 ------=_Part_7731_6834590.1149633153798 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Just a user, I'm curious as to why the trend of throwing opengl at everything. On one hand I think it's really cool, but this isn't like xgl where we want wobbly windows or something, just accelerated video. Isn't that what hardware video overlay is for? It takes a large burden off the cpu for video playback. Would benefit more people as some don't have prope= r opengl drivers. On 6/2/06, Damien Sandras wrote: > > Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit : > > So configure.in is hand-generated? Surprising. > > > > That's te way it works. You write configure.in and configure is > generated from there. I guess you are confusing things here. > > > 1) How exactly do I add the opengl ( libgl ) library? > > > > By writing autconf code in configure.in. No idea exactly how it should > be done. > > > 2) Xrandr is mentioned in the Makefile, but is not in configure.in. Ho= w > > exactly does it get put into the Makefile? > > > > Probably by an external library that we are using. > > > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I didn't wan= t > > to code against a moving target. > > > > Yes. It is even OK if you do not provide the configure.in code, but only > the OpenGL Ekiga code. > > > Thanks, > > > > -Dan > > > > Damien Sandras wrote: > > > > >Le mercredi 31 mai 2006 =E0 12:41 -0700, Dan Sandberg a =E9crit : > > > > > > > > >>I'd imagine it would work on win32, but don't know. > > >> > > >> > > >> > > > > > >Probably. > > > > > > > > > > > >>I'll work on the patches. > > >> > > >>Where's the right place to add required libraries like openGL? > > >> > > >> > > > > > >In configure.in. > > > > > > > > > > > >>configure.in seems to be autogenerated by something, but whatever it > is > > >>doesn't seem to be in the CVS snapshot... > > >> > > >> > > >> > > > > > >configure.in is in the CVS snapshot. > > > > > > > > > > > > > > >>Thanks, > > >> > > >>-Dan > > >> > > >>Julien PUYDT wrote: > > >> > > >> > > >> > > >>>Dan Sandberg a =E9crit : > > >>> > > >>> > > >>> > > >>>>How should we proceed? I could just send you an updated > gui/main.cpp > > >>>>file... > > >>>> > > >>>> > > >>>I'd like to see patches instead of full files, preferably independan= t > > >>>on each others. > > >>> > > >>>There's also the question of the portability of this : since you > > >>>mention SDL, I guess this will work great on win32 too ? > > >>> > > >>>Snark > > >>>_______________________________________________ > > >>>Gnomemeeting-devel-list mailing list > > >>>Gnomemeeting-devel-list@gnome.org > > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >>> > > >>> > > >>> > > >>_______________________________________________ > > >>Gnomemeeting-devel-list mailing list > > >>Gnomemeeting-devel-list@gnome.org > > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >> > > >> > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > -- > _ Damien Sandras > (o- > //\ Ekiga Softphone: http://www.ekiga.org/ > v_/_ FOSDEM 2006 : http://www.fosdem.org/ > SIP Phone : sip:dsandras@ekiga.net > sip:600000@ekiga.net > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > ------=_Part_7731_6834590.1149633153798 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Just a user, I'm curious as to why the trend of throwing opengl at everythi= ng.  On one hand I think it's really cool, but this isn't like xgl whe= re we want wobbly windows or something, just accelerated video.  Isn't= that what hardware video overlay is for?  It takes a large burden off= the cpu for video playback.  Would benefit more people as some don't = have proper opengl drivers.

On 6/2/06, Damien Sandras <dsand= ras@seconix.com> wrote:
Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit :
> = So configure.in is hand-generated? = ; Surprising.
>

That's te way it works. You write configure.in and configure is
generated from there. I guess you are = confusing things here.

> 1) How exactly do I add the opengl ( lib= gl ) library?
>

By writing autconf code in configure.in. No idea exactly how it should
be done.

> 2) = Xrandr is mentioned in the Makefile, but is not in configure.in.  How
> exactly does it get put in= to the Makefile?
>

Probably by an external library that we are using.

&= gt; 3) Is it ok if I send in a patch that is for Ekiga 2.0.1?  I = didn't want
> to code against a moving target.
>

Yes. It= is even OK if you do not provide the=20 configure.in code, but only
the Open= GL Ekiga code.

> Thanks,
>
> -Dan
>
> Dam= ien Sandras wrote:
>
> >Le mercredi 31 mai 2006 =E0 12:41 -0= 700, Dan Sandberg a =E9crit :
> >
> >
> >>I'd imagine it would work on win= 32, but don't know.
> >>
> >>
> >>
&= gt; >
> >Probably.
> >
> >
> >
> >>I'll work on the patches.
> >>
> >>Whe= re's the right place to add required libraries like openGL?
> >>= ;
> >>
> >
> >In configure.in.
> >
> >
> >
> >>configure.in seems to be autogenerated by= something, but whatever it is
> >>doesn't seem to be in the CV= S snapshot...
> >>
> >>
> >>
> >
> &g= t;configure.in is in the CVS snapshot.<= br>> >
> >
> >
> >
> >>Thanks,
> >>
> >>-Dan
> >>
> >>Jul= ien PUYDT wrote:
> >>
> >>
> >>
>= >>>Dan Sandberg a =E9crit :
> >>>
> >>= >
> >>>
> >>>>How should we proceed? &= nbsp;I could just send you an updated gui/main.cpp
> >>>>= file...
> >>>>
> >>>>
> >>&= gt;I'd like to see patches instead of full files, preferably independant
> >>>on each others.
> >>>
> >>&= gt;There's also the question of the portability of this : since you
>= >>>mention SDL, I guess this will work great on win32 too ?
> >>>
> >>>Snark
> >>>___________= ____________________________________
> >>>Gnomemeeting-devel= -list mailing list
> >>> Gnomemeeting-devel-list@gnome.org
> >>>http://mail.gnome= .org/mailman/listinfo/gnomemeeting-devel-list
> >>>
> >>>
> >>>
> >>____________________= ___________________________
> >>Gnomemeeting-devel-list mailing= list
> >> Gnomemeeting-devel-list@gnome.org
> >>http://mail.gnome.org= /mailman/listinfo/gnomemeeting-devel-list
> >>
> >= >
>
> _______________________________________________
> Gn= omemeeting-devel-list mailing list
> Gnomemeeting-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
-- _      Damien Sandras
(o-
//\ &n= bsp;   Ekiga Softphone: http://= www.ekiga.org/
v_/_    FOSDEM 2006  &n= bsp; : http://www.fosdem.org/
       &nb= sp;SIP Phone      : sip:dsandras@ekiga.net
    &nbs= p;            &= nbsp;       sip:600000@ekiga.net

____________________________________= ___________
Gnomemeeting-devel-list mailing list
Gnomemeeting-devel-list@gnome.org
http://mail.= gnome.org/mailman/listinfo/gnomemeeting-devel-list

------=_Part_7731_6834590.1149633153798-- From x@cs.stanford.edu Tue Jun 6 18:47:00 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5D25C3B036D for ; Tue, 6 Jun 2006 18:46:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26984-04 for ; Tue, 6 Jun 2006 18:46:56 -0400 (EDT) Received: from smtp104.plus.mail.mud.yahoo.com (smtp104.plus.mail.mud.yahoo.com [68.142.206.237]) by menubar.gnome.org (Postfix) with SMTP id 502483B0124 for ; Tue, 6 Jun 2006 18:46:56 -0400 (EDT) Received: (qmail 87952 invoked from network); 6 Jun 2006 22:46:55 -0000 Received: from unknown (HELO ?192.168.2.47?) (dan?sandberg@71.138.128.214 with plain) by smtp104.plus.mail.mud.yahoo.com with SMTP; 6 Jun 2006 22:46:54 -0000 Message-ID: <448605B0.6080504@cs.stanford.edu> Date: Tue, 06 Jun 2006 15:46:08 -0700 From: Dan Sandberg User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode References: <447CCA43.3@stdout.at> <447CFDA3.9070103@cs.stanford.edu> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> <1149246461.2966.28.camel@golgoth01> <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> In-Reply-To: <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.808 tagged_above=-999 required=2 tests=[AWL=-0.593, BAYES_00=-2.599, SPF_SOFTFAIL=1.384] X-Spam-Score: -1.808 X-Spam-Level: Cc: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 22:47:00 -0000 I could be wrong, but I believe that video overlay moves the data direct from a capture card to the video card, bypassing the CPU. Since we're trying to display images that come from over the network, there's no way to bypass the CPU. And doing a nice looking resize from 176x144 to 640x480 is quite slow. Then you have to copy the whole 640x480 image to the display card, which is slow. With OpenGL you just copy the 176x144 image to the video card, and have it do the resize. Cheers, -Dan mcquaid mcquaid wrote: > Just a user, I'm curious as to why the trend of throwing opengl at > everything. On one hand I think it's really cool, but this isn't like > xgl where we want wobbly windows or something, just accelerated > video. Isn't that what hardware video overlay is for? It takes a > large burden off the cpu for video playback. Would benefit more > people as some don't have proper opengl drivers. > > On 6/2/06, *Damien Sandras* > wrote: > > Le vendredi 02 juin 2006 à 03:03 -0700, Dan Sandberg a écrit : > > So configure.in is > hand-generated? Surprising. > > > > That's te way it works. You write configure.in > and configure is > generated from there. I guess you are confusing things here. > > > 1) How exactly do I add the opengl ( libgl ) library? > > > > By writing autconf code in configure.in . No > idea exactly how it should > be done. > > > 2) Xrandr is mentioned in the Makefile, but is not in > configure.in . How > > exactly does it get put into the Makefile? > > > > Probably by an external library that we are using. > > > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I > didn't want > > to code against a moving target. > > > > Yes. It is even OK if you do not provide the configure.in > code, but only > the OpenGL Ekiga code. > > > Thanks, > > > > -Dan > > > > Damien Sandras wrote: > > > > >Le mercredi 31 mai 2006 à 12:41 -0700, Dan Sandberg a écrit : > > > > > > > > >>I'd imagine it would work on win32, but don't know. > > >> > > >> > > >> > > > > > >Probably. > > > > > > > > > > > >>I'll work on the patches. > > >> > > >>Where's the right place to add required libraries like openGL? > > >> > > >> > > > > > >In configure.in . > > > > > > > > > > > >>configure.in seems to be autogenerated > by something, but whatever it is > > >>doesn't seem to be in the CVS snapshot... > > >> > > >> > > >> > > > > > >configure.in is in the CVS snapshot. > > > > > > > > > > > > > > >>Thanks, > > >> > > >>-Dan > > >> > > >>Julien PUYDT wrote: > > >> > > >> > > >> > > >>>Dan Sandberg a écrit : > > >>> > > >>> > > >>> > > >>>>How should we proceed? I could just send you an updated > gui/main.cpp > > >>>>file... > > >>>> > > >>>> > > >>>I'd like to see patches instead of full files, preferably > independant > > >>>on each others. > > >>> > > >>>There's also the question of the portability of this : since you > > >>>mention SDL, I guess this will work great on win32 too ? > > >>> > > >>>Snark > > >>>_______________________________________________ > > >>>Gnomemeeting-devel-list mailing list > > >>> Gnomemeeting-devel-list@gnome.org > > > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >>> > > >>> > > >>> > > >>_______________________________________________ > > >>Gnomemeeting-devel-list mailing list > > >> Gnomemeeting-devel-list@gnome.org > > > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > >> > > >> > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > -- > _ Damien Sandras > (o- > //\ Ekiga Softphone: http://www.ekiga.org/ > v_/_ FOSDEM 2006 : http://www.fosdem.org/ > SIP Phone : sip:dsandras@ekiga.net > > sip:600000@ekiga.net > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > From mcquaidster@gmail.com Tue Jun 6 19:15:44 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1CB1D3B0100 for ; Tue, 6 Jun 2006 19:15:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28543-05 for ; Tue, 6 Jun 2006 19:15:41 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id 15D153B033F for ; Tue, 6 Jun 2006 19:15:40 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x31so65185pye for ; Tue, 06 Jun 2006 16:15:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Mcduoi+u93PszObMtVWeXgYeQW4VI1eW7YkgZ+7d03TZ67OjKeE6aoo507wYkIOly9icd2mdZ2fuDTkH7FKrnfSoGo+jOXhxLaobIUCU6gQdxyXgRqVTPVs16J/2P3hFDJ8K1ELtr1xuKRWtdbXceWGlDpZn2R3lxDak1f6E47c= Received: by 10.35.40.10 with SMTP id s10mr72093pyj; Tue, 06 Jun 2006 16:15:39 -0700 (PDT) Received: by 10.35.9.3 with HTTP; Tue, 6 Jun 2006 16:15:39 -0700 (PDT) Message-ID: <58a398810606061615s6a801fected291a67dbb85214@mail.gmail.com> Date: Tue, 6 Jun 2006 19:15:39 -0400 From: "mcquaid mcquaid" To: "Dan Sandberg" Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode In-Reply-To: <448605B0.6080504@cs.stanford.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8108_3516387.1149635739799" References: <447CCA43.3@stdout.at> <1149071173.2486.6.camel@golgoth01> <447DE4E2.7040204@cs.stanford.edu> <447DEE59.9060606@free.fr> <447DF183.3090300@cs.stanford.edu> <1149144061.2457.4.camel@golgoth01> <44800CFA.5090800@cs.stanford.edu> <1149246461.2966.28.camel@golgoth01> <58a398810606061532k6aa30dclf63320642c33eac6@mail.gmail.com> <448605B0.6080504@cs.stanford.edu> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.242 tagged_above=-999 required=2 tests=[AWL=0.223, BAYES_00=-2.599, HTML_50_60=0.134, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.242 X-Spam-Level: Cc: GnomeMeeting development mailing list X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 23:15:44 -0000 ------=_Part_8108_3516387.1149635739799 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hmm, again I don't know much about this but I think what you describe can b= e handled by hardware video overlay. Just a quick googling has this about hardware video overlay at the zoomplayer's website: http://www.inmatrix.com/zplayer/highlights/vidrender.shtml *The Video Overlay:* > At around 1995, when MPEG1 (VCD) playback started to become popular on th= e > PC, the actual processing power of the PC was not quite strong enough to > play such content. The display card manufacturers at the time came up wit= h a > solution called "The Video Overlay". The Video Overlay is a special hardw= are > on the display card which is used to perform several video-display featur= es > in hardware (Stretching, Color-Space Conversion, etc...), thus allowing > smooth playback of video at no cost to the CPU. It does go on to say that video rendering via dx9 (and thus I assume opengl) provide better image quality and don't suffer from some multimonitor issues with video overlay. Afaik, only one display can have hardware overlay so that's what he's referring to there. But, for the most part, it sounds like hardware overlay would be a nice solution as well that just about everyone would benefit from as again, ther= e are still a lot of people without good opengl in linux but most probably functional hardware overlay. Maybe an option for both? On 6/6/06, Dan Sandberg wrote: > > I could be wrong, but I believe that video overlay moves the data direct > from a capture card to the video card, bypassing the CPU. Since we're > trying to display images that come from over the network, there's no way > to bypass the CPU. And doing a nice looking resize from 176x144 to > 640x480 is quite slow. Then you have to copy the whole 640x480 image to > the display card, which is slow. With OpenGL you just copy the 176x144 > image to the video card, and have it do the resize. > > Cheers, > > -Dan > > mcquaid mcquaid wrote: > > Just a user, I'm curious as to why the trend of throwing opengl at > > everything. On one hand I think it's really cool, but this isn't like > > xgl where we want wobbly windows or something, just accelerated > > video. Isn't that what hardware video overlay is for? It takes a > > large burden off the cpu for video playback. Would benefit more > > people as some don't have proper opengl drivers. > > > > On 6/2/06, *Damien Sandras* > > wrote: > > > > Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit : > > > So configure.in is > > hand-generated? Surprising. > > > > > > > That's te way it works. You write configure.in > > and configure is > > generated from there. I guess you are confusing things here. > > > > > 1) How exactly do I add the opengl ( libgl ) library? > > > > > > > By writing autconf code in configure.in . No > > idea exactly how it should > > be done. > > > > > 2) Xrandr is mentioned in the Makefile, but is not in > > configure.in . How > > > exactly does it get put into the Makefile? > > > > > > > Probably by an external library that we are using. > > > > > 3) Is it ok if I send in a patch that is for Ekiga 2.0.1? I > > didn't want > > > to code against a moving target. > > > > > > > Yes. It is even OK if you do not provide the configure.in > > code, but only > > the OpenGL Ekiga code. > > > > > Thanks, > > > > > > -Dan > > > > > > Damien Sandras wrote: > > > > > > >Le mercredi 31 mai 2006 =E0 12:41 -0700, Dan Sandberg a =E9crit = : > > > > > > > > > > > >>I'd imagine it would work on win32, but don't know. > > > >> > > > >> > > > >> > > > > > > > >Probably. > > > > > > > > > > > > > > > >>I'll work on the patches. > > > >> > > > >>Where's the right place to add required libraries like openGL? > > > >> > > > >> > > > > > > > >In configure.in . > > > > > > > > > > > > > > > >>configure.in seems to be autogenerated > > by something, but whatever it is > > > >>doesn't seem to be in the CVS snapshot... > > > >> > > > >> > > > >> > > > > > > > >configure.in is in the CVS snapshot. > > > > > > > > > > > > > > > > > > > >>Thanks, > > > >> > > > >>-Dan > > > >> > > > >>Julien PUYDT wrote: > > > >> > > > >> > > > >> > > > >>>Dan Sandberg a =E9crit : > > > >>> > > > >>> > > > >>> > > > >>>>How should we proceed? I could just send you an updated > > gui/main.cpp > > > >>>>file... > > > >>>> > > > >>>> > > > >>>I'd like to see patches instead of full files, preferably > > independant > > > >>>on each others. > > > >>> > > > >>>There's also the question of the portability of this : since > you > > > >>>mention SDL, I guess this will work great on win32 too ? > > > >>> > > > >>>Snark > > > >>>_______________________________________________ > > > >>>Gnomemeeting-devel-list mailing list > > > >>> Gnomemeeting-devel-list@gnome.org > > > > > >>>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > >>> > > > >>> > > > >>> > > > >>_______________________________________________ > > > >>Gnomemeeting-devel-list mailing list > > > >> Gnomemeeting-devel-list@gnome.org > > > > > >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > >> > > > >> > > > > > > _______________________________________________ > > > Gnomemeeting-devel-list mailing list > > > Gnomemeeting-devel-list@gnome.org > > > > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > -- > > _ Damien Sandras > > (o- > > //\ Ekiga Softphone: http://www.ekiga.org/ > > v_/_ FOSDEM 2006 : http://www.fosdem.org/ > > SIP Phone : sip:dsandras@ekiga.net > > > > sip:600000@ekiga.net > > > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > Gnomemeeting-devel-list mailing list > > Gnomemeeting-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list > > > > ------=_Part_8108_3516387.1149635739799 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hmm, again I don't know much about this but I think what you describe can b= e handled by
hardware video overlay.

Just a quick googling has t= his about hardware video overlay at the zoomplayer's website:

http://www.inmatrix.com/zplayer/highlights/vidrender.shtml

The Video Overlay:
At around 1995, when MPEG1 (VCD) playback started to become popular on the = PC, the actual processing power of the PC was not quite strong enough to play such content. The display card manufacturers a= t the time came up with a solution called "The Video Overlay". The Video Overlay is a special hardware on = the display card which is used to perform several video-display features in hardware (Stretching, Color-Space Conversion, etc...), thus all= owing smooth playback of video at no cost to the CPU.


It does go on to say  that video rend= ering via dx9 (and thus I assume opengl)  provide better image quality= and don't suffer from some multimonitor issues with video overlay.
Afai= k, only one display can have hardware overlay so that's what he's referring= to there.

But, for the most part, it sounds like hardware overlay would be a = nice solution as well that just about everyone would benefit from as again,= there are still a lot of people without good opengl in linux but most prob= ably functional hardware overlay.

Maybe an option for both? 

On 6/6/06, Dan Sandberg <<= a href=3D"mailto:x@cs.stanford.edu">x@cs.stanford.edu> wrote:=
I could be wrong, but I believe that video overlay moves the data directfrom a capture card to the video card, bypassing the CPU.  Since= we're
trying to display images that come from over the network, there's= no way
to bypass the CPU.  And doing a nice looking resize from 176x= 144 to
640x480 is quite slow.  Then you have to copy the whole= 640x480 image to
the display card, which is slow.  With OpenG= L you just copy the 176x144
image to the video card, and have it do the resize.

Cheers,
<= br>-Dan

mcquaid mcquaid wrote:
> Just a user, I'm curious as t= o why the trend of throwing opengl at
> everything.  On one= hand I think it's really cool, but this isn't like
> xgl where we want wobbly windows or something, just accelerated> video.  Isn't that what hardware video overlay is for? = ; It takes a
> large burden off the cpu for video playback. = ; Would benefit more
> people as some don't have proper opengl drivers.
>
> On 6/= 2/06, *Damien Sandras* <dsandras= @seconix.com
> <mailto: dsandras@seconix.com>> wrote:
>
>   &n= bsp; Le vendredi 02 juin 2006 =E0 03:03 -0700, Dan Sandberg a =E9crit :
= >     > So config= ure.in < http://configure.in> is
>     hand-generat= ed?  Surprising.
>     >
>
= >     That's te way it works. You write configure.in
>     < http://configure.in> and configure is
>    = ; generated from there. I guess you are confusing things here.
>
&= gt;     > 1) How exactly do I add the opengl ( libgl= ) library?
>     >
>
>     By writing autconf code in configure.in <http:= //configure.in>. No
>     idea exactly how= it should
>     be done.
>
>     > 2) Xrandr is mentioned in the Makefile, b= ut is not in
>     configure.in <http://configure.in<= /a>>.  How
>     > exactly does i= t get put into the Makefile?
>     >
>
>   &nbs= p; Probably by an external library that we are using.
>
> =     > 3) Is it ok if I send in a patch that is for Ekiga = 2.0.1?  I
>     didn't want
>&nbs= p;    > to code against a moving target.
>     >
>
>   &nbs= p; Yes. It is even OK if you do not provide the configure.in
>     <http://configure.in> code, but only
>     the OpenGL Ekiga code.
>
> &n= bsp;   > Thanks,
>     >
>&= nbsp;    > -Dan
>     >
&= gt;     > Damien Sandras wrote:
>  &= nbsp;  >
>     > >Le mercredi 31 ma= i 2006 =E0 12:41 -0700, Dan Sandberg a =E9crit :
>     > >
>     = > >
>     > >>I'd imagine it would= work on win32, but don't know.
>     > >&g= t;
>     > >>
>   &= nbsp; > >>
>     > >
>     > >Probably.
>  &nbs= p;  > >
>     > >
> &= nbsp;   > >
>     > >>I'= ll work on the patches.
>     > >>
&g= t;     > >>Where's the right place to add requ= ired libraries like openGL?
>     > >>
>   &nb= sp; > >>
>     > >
> &n= bsp;   > >In configure.in <http://configure.in>.
>=      > >
>     > >
>     = > >
>     > >>configure.in <http://con= figure.in> seems to be autogenerated
>    = by something, but whatever it is
>     > >>doesn't seem to be in the CVS= snapshot...
>     > >>
> &nb= sp;   > >>
>     > >>=
>     > >
>     = > >configure.in <http://configure.in> is in = the CVS snapshot.
>     > >
> &n= bsp;   > >
>     > >
>= ;     > >
>     > &g= t;>Thanks,
>     > >>
>     > >>-Dan
>   = ;  > >>
>     > >>Julien P= UYDT wrote:
>     > >>
> &nbs= p;   > >>
>     > >><= br>>     > >>>Dan Sandberg a =E9crit :
>     > >>>
>   = ;  > >>>
>     > >>>=
>     > >>>>How should we proceed= ?  I could just send you an updated
>   &nbs= p; gui/main.cpp
>     > >>>>file..= .
>     > >>>>
>  &= nbsp;  > >>>>
>     > >= >>I'd like to see patches instead of full files, preferably
>&n= bsp;    independant
>     > >= ;>>on each others.
>     > >>>
>   = ;  > >>>There's also the question of the portability of th= is : since you
>     > >>>mention SDL= , I guess this will work great on win32 too ?
>   &nbs= p; > >>>
>     > >>>Snark
>  =    > >>>_____________________________________________= __
>     > >>>Gnomemeeting-devel-list= mailing list
>     > >>> Gnomemeeting-devel-list@gnome.org
>     <m= ailto:Gnomemeeting-dev= el-list@gnome.org>
>     > >>>= http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>&= nbsp;    > >>>
>     &= gt; >>>
>     > >>>
>&= nbsp;    > >>______________________________________= _________
>     > >>Gnomemeeting-devel-list maili= ng list
>     > >> Gnomemeeting-devel-list@gnome.org
&g= t;     <mailto: Gnomemeeting-devel-list@gnome.org>
>     &= gt; >>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list<= /a>
>     > >>
>     > >>
>   &nb= sp; >
>     > _____________________________= __________________
>     > Gnomemeeting-devel-= list mailing list
>     > Gnomemeeting-devel-list@gnome.org
>     <m= ailto:Gnomemeeting-dev= el-list@gnome.org>
>     > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>&= nbsp;    --
>     _  &nb= sp;   Damien Sandras
>     (o-
= >     //\     Ekiga Softphone: <= a href=3D"http://www.ekiga.org/">http://www.ekiga.org/
>     v_/_    FOSDEM 200= 6    : http://www.fo= sdem.org/
>         =     SIP Phone      : sip:dsandras@ekiga.net
> =     <mailto: sip:dsandr= as@ekiga.net>
>        = ;            &n= bsp;         sip:600000@ekiga.net
>   &n= bsp; <mailto: sip:600000@ekiga.net>
>= ;
>     _________________________________________= ______
>     Gnomemeeting-devel-list mailing list=
>     Gnomemeeting-devel-list@gnome.org
>     <m= ailto:Gnomemeeting-dev= el-list@gnome.org>
>     http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>&= nbsp;    <http://mail.gnome.org/mailman/listinfo/gnomemee= ting-devel-list >
>
>
> ----------------------------------------------= --------------------------
>
> ________________________________= _______________
> Gnomemeeting-devel-list mailing list
> Gnomemeeting-devel-list@gnome.org
> http://mail.gnome.org/mailman= /listinfo/gnomemeeting-devel-list
>

------=_Part_8108_3516387.1149635739799-- From stefan@watri.org.au Wed Jun 7 00:39:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 26FE33B0B45 for ; Wed, 7 Jun 2006 00:39:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12142-08 for ; Wed, 7 Jun 2006 00:39:13 -0400 (EDT) Received: from asclepius.uwa.edu.au (asclepius.uwa.edu.au [130.95.128.56]) by menubar.gnome.org (Postfix) with ESMTP id 1153F3B022D for ; Wed, 7 Jun 2006 00:39:11 -0400 (EDT) Received: from asclepius.kas (localhost.localdomain [127.0.0.1]) by asclepius.uwa.edu.au (Postfix) with SMTP id 9EF11184629 for ; Wed, 7 Jun 2006 12:39:05 +0800 (WST) Received: from asclepius (localhost.localdomain [127.0.0.1]) by asclepius.prekas (Postfix) with SMTP id 7CB52188123 for ; Wed, 7 Jun 2006 12:39:05 +0800 (WST) X-UWA-Client-IP: 130.95.28.15 (UWA) Received: from ns1.watri.uwa.edu.au (ns1.watri.org.au [130.95.28.15]) by asclepius.extinput (Postfix) with ESMTP id 6CCE5188174 for ; Wed, 7 Jun 2006 12:39:05 +0800 (WST) Received: from gluttony (gluttony.watri.org.au [130.95.29.76]) by ns1.watri.uwa.edu.au (8.13.1/8.13.1) with ESMTP id k574d4dE023954 for ; Wed, 7 Jun 2006 12:39:04 +0800 (WST) Message-Id: <200606070439.k574d4dE023954@ns1.watri.uwa.edu.au> From: =?iso-8859-1?Q?Stefan_Br=FCns?= To: "'GnomeMeeting development mailing list'" Subject: RE: [GnomeMeeting-devel-list] Full Screen Mode Date: Wed, 7 Jun 2006 12:41:40 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <448605B0.6080504@cs.stanford.edu> Thread-Index: AcaJu2+MfoUGcqUFRii2sxvr70Y3NQALgJIg X-SpamTest-Info: Profile: Formal (387/060606) X-SpamTest-Info: Profile: Detect Hard [UCS 290904] X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking Spam - Subject (UCS) [02-08-04] X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.176 tagged_above=-999 required=2 tests=[AWL=-1.125, BAYES_40=-0.185, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] X-Spam-Score: -1.176 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 04:39:16 -0000 > -----Original Message----- > From: gnomemeeting-devel-list-bounces@gnome.org > [mailto:gnomemeeting-devel-list-bounces@gnome.org] On Behalf > Of Dan Sandberg > Sent: Wednesday, 7 June 2006 6:46 AM > To: GnomeMeeting development mailing list > Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode > > I could be wrong, but I believe that video overlay moves the > data direct > >from a capture card to the video card, bypassing the CPU. > Since we're > trying to display images that come from over the network, > there's no way > to bypass the CPU. And doing a nice looking resize from 176x144 to > 640x480 is quite slow. Then you have to copy the whole > 640x480 image to > the display card, which is slow. With OpenGL you just copy > the 176x144 > image to the video card, and have it do the resize. Just to clarify some things: Video overlay over XV support scaling in hardware, and colorspace transforms. Unfortunately, most graphic cards support only one overlay at a time. In case you only have a single video, this is fine, but as soon as you have multiple (local/remote, maybe conference anytime in the future), you have to do the compositing before uploading the image to the card. In case of Picture in Picture, this means that you a) Scale the to be small video down, compose it into the large one, and upload the composed image. Drawback: Also the small image may end up as large as an unscaled CIF image, it will have a lower resolution, due to the downscaling. or b) Scale the to be large image up, and compose the small image into it. Also the small image will have its full resolution (it may be a CIF (352x288) image on a 1024x768 or larger screen), the upscaling of the large image adds a lot of burden to the CPU and memory transfers. On the other hand, if you use OpenGL textures, you have all the benefits: - You can upload every video to a different texture, every video ends up on the screen with all the available resolution, all the scaling is done on the GPU (which is very efficient for this). - Most cards support YUV colorspaces for textures, so color transform can be done on the card. - As the different videos stream end up on different textures, you may have the local video with full 25fps framerate, and the remote with something like 10fps. - Superimposing any text (Chat, callers name, new incoming call ...) comes down to putting the text into just another texture. This may be easily alpha blended, with full screen resolution (if you superimpose text on the video directly, you can only use the videos resolution, and edges may look really strange due to the UV subsampling). - You may due almost arbitrary transforms on the video, without burdening the CPU (have a look at the Conference feature of iChat AV to see what I mean). Greetings, Stefan From t.schorpp@gmx.de Wed Jun 7 03:35:24 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 125143B0C5F for ; Wed, 7 Jun 2006 03:35:24 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23077-04 for ; Wed, 7 Jun 2006 03:35:22 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by menubar.gnome.org (Postfix) with SMTP id 544083B0368 for ; Wed, 7 Jun 2006 03:35:21 -0400 (EDT) Received: (qmail invoked by alias); 07 Jun 2006 07:35:19 -0000 Received: from p85.212.144.48.tisdip.tiscali.de (EHLO [192.168.1.100]) [85.212.144.48] by mail.gmx.net (mp029) with SMTP; 07 Jun 2006 09:35:19 +0200 X-Authenticated: #17142692 Message-ID: <448681B6.5000204@gmx.de> Date: Wed, 07 Jun 2006 09:35:18 +0200 From: thomas schorpp User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1 X-Accept-Language: de, en-us MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode References: <200606070439.k574d4dE023954@ns1.watri.uwa.edu.au> In-Reply-To: <200606070439.k574d4dE023954@ns1.watri.uwa.edu.au> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.476 tagged_above=-999 required=2 tests=[AWL=-0.011, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] X-Spam-Score: -2.476 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: t.schorpp@gmx.de, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 07:35:24 -0000 Stefan Brüns wrote: >>-----Original Message----- >>From: gnomemeeting-devel-list-bounces@gnome.org >>[mailto:gnomemeeting-devel-list-bounces@gnome.org] On Behalf >>Of Dan Sandberg >>Sent: Wednesday, 7 June 2006 6:46 AM >>To: GnomeMeeting development mailing list >>Subject: Re: [GnomeMeeting-devel-list] Full Screen Mode >> >>I could be wrong, but I believe that video overlay moves the >>data direct >>>from a capture card to the video card, bypassing the CPU. >>Since we're >>trying to display images that come from over the network, >>there's no way >>to bypass the CPU. And doing a nice looking resize from 176x144 to >>640x480 is quite slow. Then you have to copy the whole >>640x480 image to >>the display card, which is slow. With OpenGL you just copy >>the 176x144 >>image to the video card, and have it do the resize. > > > Just to clarify some things: > > Video overlay over XV support scaling in hardware, and colorspace > transforms. are You sure? ive some display apps here which can switch between XV and "real overlay". kvdr, tvtime, xawtv... XV can use significant high cpu load in my experience here... > > Unfortunately, most graphic cards support only one overlay at a time. not sure about this, too. all the chips i had since ati mach64 supported at least 2 overlays at a time. kvdr supports even up to 4 overlays(?) on modern cards respectively. http://www.s.netic.de/gfiala/ > In > case you only have a single video, this is fine, but as soon as you have > multiple (local/remote, maybe conference anytime in the future), you have to > do the compositing before uploading the image to the card. In case of > Picture in Picture, this means that you > > a) Scale the to be small video down, compose it into the large one, and > upload the composed image. Drawback: Also the small image may end up as > large as an unscaled CIF image, it will have a lower resolution, due to the > downscaling. > > or > b) Scale the to be large image up, and compose the small image into it. Also > the small image will have its full resolution (it may be a CIF (352x288) > image on a 1024x768 or larger screen), the upscaling of the large image adds > a lot of burden to the CPU and memory transfers. > > On the other hand, if you use OpenGL textures, you have all the benefits: > - You can upload every video to a different texture, every video ends up on > the screen with all the available resolution, all the scaling is done on the > GPU (which is very efficient for this). > - Most cards support YUV colorspaces for textures, so color transform can be > done on the card. > - As the different videos stream end up on different textures, you may have > the local video with full 25fps framerate, and the remote with something > like 10fps. > - Superimposing any text (Chat, callers name, new incoming call ...) comes > down to putting the text into just another texture. This may be easily alpha > blended, with full screen resolution (if you superimpose text on the video > directly, you can only use the videos resolution, and edges may look really > strange due to the UV subsampling). > - You may due almost arbitrary transforms on the video, without burdening > the CPU (have a look at the Conference feature of iChat AV to see what I > mean). > > Greetings, > is there no standard "network video class" for the application layer somewhere? > Stefan tom From jpuydt@free.fr Wed Jun 7 07:50:57 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 57F3B3B030A for ; Wed, 7 Jun 2006 07:50:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08294-07 for ; Wed, 7 Jun 2006 07:50:54 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id 565043B03D0 for ; Wed, 7 Jun 2006 07:50:54 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp3-g19.free.fr (Postfix) with ESMTP id 26AE4498B4 for ; Wed, 7 Jun 2006 13:50:53 +0200 (CEST) Message-ID: <4486BDD0.9050805@free.fr> Date: Wed, 07 Jun 2006 13:51:44 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.845 tagged_above=-999 required=2 tests=[AWL=-0.735, BAYES_05=-1.11] X-Spam-Score: -1.845 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Refactoring of the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 11:50:57 -0000 Hi, after some discussions, it seems my initial ideas just don't fly. I don't consider them as a full failure, but they certainly are 80% so. I has in particular a long (private) discussion with Éric Bischoff, which allowed me to test my ideas on a newcomer. :-) Snark From jpuydt@free.fr Wed Jun 7 08:02:38 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A3A943B0CA0 for ; Wed, 7 Jun 2006 08:02:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09379-09 for ; Wed, 7 Jun 2006 08:02:30 -0400 (EDT) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by menubar.gnome.org (Postfix) with ESMTP id 0A6253B0CFE for ; Wed, 7 Jun 2006 08:01:42 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp2-g19.free.fr (Postfix) with ESMTP id 9A1E973329 for ; Wed, 7 Jun 2006 14:01:41 +0200 (CEST) Message-ID: <4486C05B.9080200@free.fr> Date: Wed, 07 Jun 2006 14:02:35 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> In-Reply-To: <4486BDD0.9050805@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:02:38 -0000 Julien PUYDT a écrit : > Notice that I forgot the conclusion : back to blackboard :-) Snark From pbrobinson@gmail.com Wed Jun 7 08:05:53 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D7E343B0C89 for ; Wed, 7 Jun 2006 08:05:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09667-03 for ; Wed, 7 Jun 2006 08:05:53 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by menubar.gnome.org (Postfix) with ESMTP id 33FD03B0C35 for ; Wed, 7 Jun 2006 08:05:52 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id q2so283058uge for ; Wed, 07 Jun 2006 05:05:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=G9St54usrU1EqN6hzRVdcsL0b9E6Bqxv3H4s4TGGxDEm0S9y4VTy4J2/S9c86GUzX86KIkPRd3gDHRfgFY6rCHfD2mYVgjzsw18dl0V8Ib8+WG4xy7/jO5pBwQEky1I69/GeIoNY6Q1nIE7TBp9rIFYmsHkPs+aO3lXDh5BJAzE= Received: by 10.67.89.5 with SMTP id r5mr423228ugl; Wed, 07 Jun 2006 05:05:51 -0700 (PDT) Received: by 10.67.25.6 with HTTP; Wed, 7 Jun 2006 05:05:51 -0700 (PDT) Message-ID: <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> Date: Wed, 7 Jun 2006 13:05:51 +0100 From: "Peter Robinson" To: "GnomeMeeting development mailing list" Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code In-Reply-To: <4486C05B.9080200@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4486BDD0.9050805@free.fr> <4486C05B.9080200@free.fr> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.56 tagged_above=-999 required=2 tests=[AWL=-0.518, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.56 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:05:54 -0000 > Julien PUYDT a =E9crit : > > > > Notice that I forgot the conclusion : back to blackboard :-) So are there any ideas running around that blackboard as of yet? Peter From jpuydt@free.fr Wed Jun 7 08:22:36 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CBE393B08CC for ; Wed, 7 Jun 2006 08:22:36 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10857-05 for ; Wed, 7 Jun 2006 08:22:35 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 97D9B3B0CDC for ; Wed, 7 Jun 2006 08:22:35 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp5-g19.free.fr (Postfix) with ESMTP id 65742275AC for ; Wed, 7 Jun 2006 14:22:34 +0200 (CEST) Message-ID: <4486C53D.2080306@free.fr> Date: Wed, 07 Jun 2006 14:23:25 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> In-Reply-To: <4486BDD0.9050805@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:22:37 -0000 Ok, so let's see what the constraints are. 1) the already available addressbooks must fit in the new scheme ; 2) the future kde addressbooks must find their place easily ; 3) searching should be dead-easy ; 4) the future "live" contacts must find their place easily ; 5) the backend-frontend frontier should be clear enough to allow for easy DBUS exporting 6) Damien wants it fast. Yes, going back to the blackboard isn't the best way to achieve 6... Snark From jpuydt@free.fr Wed Jun 7 08:52:53 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 92FD63B03C4 for ; Wed, 7 Jun 2006 08:52:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12995-08 for ; Wed, 7 Jun 2006 08:52:50 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id D0F7E3B0C97 for ; Wed, 7 Jun 2006 08:52:49 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp3-g19.free.fr (Postfix) with ESMTP id AEAAC497A1 for ; Wed, 7 Jun 2006 14:52:48 +0200 (CEST) Message-ID: <4486CC54.9090206@free.fr> Date: Wed, 07 Jun 2006 14:53:40 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <4486C05B.9080200@free.fr> <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> In-Reply-To: <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:52:53 -0000 Peter Robinson a écrit : > So are there any ideas running around that blackboard as of yet? Plenty. Snark From ebischoff@nerim.net Wed Jun 7 09:43:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C57F03B03C1 for ; Wed, 7 Jun 2006 09:43:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17343-08 for ; Wed, 7 Jun 2006 09:43:14 -0400 (EDT) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by menubar.gnome.org (Postfix) with ESMTP id BB8E53B03F1 for ; Wed, 7 Jun 2006 09:43:13 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 09C7C40FD8 for ; Wed, 7 Jun 2006 15:43:11 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Wed, 7 Jun 2006 15:43:21 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <4486C53D.2080306@free.fr> In-Reply-To: <4486C53D.2080306@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606071543.22163.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.562 tagged_above=-999 required=2 tests=[AWL=0.037, BAYES_00=-2.599] X-Spam-Score: -2.562 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 13:43:16 -0000 Le Mercredi 7 Juin 2006 14:23, Julien PUYDT a =C3=A9crit=C2=A0: > Yes, going back to the blackboard isn't the best way to achieve 6... You don't go black to the blackboard with no experience ;-). In pecular, I have been proposing a framework for address book "drivers" li= ke: class EkigaAddressBook { public: virtual gchar *name() const =3D 0; virtual const EkigaContact *firstContact() =3D 0; virtual const EkigaContact *nextContact() =3D 0; }; class EkigaContact { public: virtual boolean hasName() const =3D 0; virtual gchar *name() const =3D 0; virtual boolean hasTelephone() const =3D 0; virtual gchar *telephone() const =3D 0; etc... }; class EkigaEvolutionAddressBook : public EkigaAddressBook { public: virtual gchar *name() const; virtual const EkigaContact *firstContact(); virtual const EkigaContact *nextContact(); }; class EkigaEvolutionContact : public EkigaContact { public: virtual boolean hasName() const; virtual gchar *name() const; virtual boolean hasTelephone() const; virtual gchar *telephone() const; etc... }; Comments and flames welcome. =2D-=20 =C3=89ric From jpuydt@free.fr Wed Jun 7 13:58:31 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6343F3B0BC1 for ; Wed, 7 Jun 2006 13:58:31 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02884-04 for ; Wed, 7 Jun 2006 13:58:23 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 55DA13B069F for ; Wed, 7 Jun 2006 13:58:19 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp1-g19.free.fr (Postfix) with ESMTP id E2BA8911A6 for ; Wed, 7 Jun 2006 19:58:17 +0200 (CEST) Message-ID: <4486F76C.7060301@free.fr> Date: Wed, 07 Jun 2006 17:57:32 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <4486C53D.2080306@free.fr> <200606071543.22163.ebischoff@nerim.net> In-Reply-To: <200606071543.22163.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 17:58:31 -0000 Éric Bischoff a écrit : > Le Mercredi 7 Juin 2006 14:23, Julien PUYDT a écrit : >> Yes, going back to the blackboard isn't the best way to achieve 6... > > You don't go black to the blackboard with no experience ;-). Of course no :-) > In pecular, I have been proposing a framework for address book "drivers" like: > > class EkigaAddressBook > { > public: > virtual gchar *name() const = 0; > virtual const EkigaContact *firstContact() = 0; > virtual const EkigaContact *nextContact() = 0; > }; I don't like your first/next idea. If I take an XMPP roster in ekiga, connect to the same account from another program, and add a contact there, the XMPP roster will do a roster push, which your api doesn't handle. A much better approach IMNSHO, when it comes to keeping track of a list of contacts, is the following pseudo-code api : - get the current list of contacts ; - notify/signal me when a new one appears. There are two ways to handle the removing of a contact from such a list: (i) either the book tells you the contact has been removed ; (ii) or the contact itself tells you so. Both can be handled by a notification/signal. My first tests used the second way to do so, but now I think the first is better : the signal tells you both the book and the contact. > class EkigaContact > { > public: > virtual boolean hasName() const = 0; > virtual gchar *name() const = 0; > > virtual boolean hasTelephone() const = 0; > virtual gchar *telephone() const = 0; > > etc... > }; Bad. :-) First, you don't handle the case where several telephone numbers are available. Then if you begin to put /everything/ in the *base* class, that will end badly. A base class should only have the most basic capabilities, not all of them. > Comments and flames welcome. As a last comment, I will repoint the two arguments I have to prefer a GObject solution to a C++ solution : 1) the GObject will nicely live and die in the glib mainloop, so we won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere ; 2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame /dev/null). Snark From jpuydt@free.fr Wed Jun 7 14:30:54 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6C9E83B0255 for ; Wed, 7 Jun 2006 14:30:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04954-09 for ; Wed, 7 Jun 2006 14:30:52 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 15D9C3B0135 for ; Wed, 7 Jun 2006 14:30:52 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp5-g19.free.fr (Postfix) with ESMTP id E116F2766C for ; Wed, 7 Jun 2006 20:30:50 +0200 (CEST) Message-ID: <44871B92.9090703@free.fr> Date: Wed, 07 Jun 2006 20:31:46 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <4486C05B.9080200@free.fr> <5256d0b0606070505y77e29786ve7183abca0304295@mail.gmail.com> <4486CC54.9090206@free.fr> In-Reply-To: <4486CC54.9090206@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.011, BAYES_00=-2.599] X-Spam-Score: -2.588 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 18:30:54 -0000 Julien PUYDT a écrit : > Plenty. Ok, here are a few. First of all, Éric convinced me the "no common class for contacts" was bad. So the main organization should probably be the following : - at the upper level, there are sources of addressbooks (avahi, e-d-s, kab, call history, xmpp...) ; - those sources give access to addressbooks ; - those addressbooks contain contacts. Now the question is detailing what is done where :-) Snark From ebischoff@nerim.net Wed Jun 7 14:33:56 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E21DC3B027D for ; Wed, 7 Jun 2006 14:33:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05177-06 for ; Wed, 7 Jun 2006 14:33:54 -0400 (EDT) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by menubar.gnome.org (Postfix) with ESMTP id 360A33B0135 for ; Wed, 7 Jun 2006 14:33:53 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 7CB2240E26 for ; Wed, 7 Jun 2006 20:33:50 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Wed, 7 Jun 2006 20:33:52 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606071543.22163.ebischoff@nerim.net> <4486F76C.7060301@free.fr> In-Reply-To: <4486F76C.7060301@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606072033.54523.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.569 tagged_above=-999 required=2 tests=[AWL=0.030, BAYES_00=-2.599] X-Spam-Score: -2.569 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 18:33:56 -0000 Le Mercredi 7 Juin 2006 17:57, Julien PUYDT a =C3=A9crit=C2=A0: > A much better approach IMNSHO, when it comes to keeping track of a list > of contacts, is the following pseudo-code api : > - get the current list of contacts ; > - notify/signal me when a new one appears. I am not sure that the Evolution, LDAP or KAddressBook drivers will all be= =20 able to wake up when a new contact is created. The contact can be created=20 asynchronously by another user on another machine on some LDAP server far=20 away on a network that is broken half of the time, for example. So even the= =20 underlying Evolution / LDAP / KAddressBook libraries might not know. =46urthermore, keeping a list all contacts in memory can have a high cost i= n=20 memory usage. > There are two ways to handle the removing of a contact from such a list: > (i) either the book tells you the contact has been removed ; > (ii) or the contact itself tells you so. > Both can be handled by a notification/signal. My first tests used the > second way to do so, but now I think the first is better : the signal > tells you both the book and the contact. Is that such a problem if the driver loops over an older version of the lis= t? > First, you don't handle the case where several telephone numbers are > available. Yeah, yeah. That was just an example. > Then if you begin to put /everything/ in the *base* class, that will end > badly. A base class should only have the most basic capabilities, not > all of them. Well, most address books are expected to deliver names and telephone=20 numbers ,-). But if you don't want to code hooks that return NULL all the=20 time for properties that do not exist (which I can understand), there's an= =20 easy and clean variant: class EkigaContact { public: enum property { name, telephone, street, ... }; virtual bool hasProperty(property p) const =3D 0; gchar *value(property p) const =3D 0; }; So contact->value(street) returns the street address and if contact->hasProperty(street) is true. > As a last comment, I will repoint the two arguments I have to prefer a > GObject solution to a C++ solution : Well, that's the kind of debate that can typically end up in a religious=20 war ;-), but: 1) why reinvent the wheel? C++ has mechanisms for object programming, it's= =20 rather strange to reimplement them in C; 2) such choices tie Ekiga more deeply into GNOME libraries (okay, it's a GN= OME=20 project. But...) > 1) the GObject will nicely live and die in the glib mainloop, so we > won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere= ; > 2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga > more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame > /dev/null). GBUS is indeed a nice invention ;-). =2D-=20 =C3=89ric From jpuydt@free.fr Wed Jun 7 15:29:48 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 91CC53B027D for ; Wed, 7 Jun 2006 15:29:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08481-05 for ; Wed, 7 Jun 2006 15:29:45 -0400 (EDT) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by menubar.gnome.org (Postfix) with ESMTP id 54DB33B0546 for ; Wed, 7 Jun 2006 15:29:45 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-23-82-248-126-226.adsl.proxad.net [82.248.126.226]) by smtp2-g19.free.fr (Postfix) with ESMTP id 2EC0A6FECE for ; Wed, 7 Jun 2006 21:29:44 +0200 (CEST) Message-ID: <4487295A.9060506@free.fr> Date: Wed, 07 Jun 2006 21:30:34 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606071543.22163.ebischoff@nerim.net> <4486F76C.7060301@free.fr> <200606072033.54523.ebischoff@nerim.net> In-Reply-To: <200606072033.54523.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 19:29:48 -0000 Éric Bischoff a écrit : > Le Mercredi 7 Juin 2006 17:57, Julien PUYDT a écrit : >> A much better approach IMNSHO, when it comes to keeping track of a list >> of contacts, is the following pseudo-code api : >> - get the current list of contacts ; >> - notify/signal me when a new one appears. > > I am not sure that the Evolution, LDAP or KAddressBook drivers will all be > able to wake up when a new contact is created. The contact can be created > asynchronously by another user on another machine on some LDAP server far > away on a network that is broken half of the time, for example. So even the > underlying Evolution / LDAP / KAddressBook libraries might not know. Well, for those what I propose still works : - they get a list of contacts (and emit the "contact-added" signal for each) ; - when they are refreshed, they remove all their contacts, and get the new list of contacts. And what I propose works also for XMPP rosters, which are dynamically updated. > Furthermore, keeping a list all contacts in memory can have a high cost in > memory usage. Indeed, some books shouldn't treat "get the list of contacts" litterally. That is why they shouldn't be too stupid :-) >> There are two ways to handle the removing of a contact from such a list: >> (i) either the book tells you the contact has been removed ; >> (ii) or the contact itself tells you so. >> Both can be handled by a notification/signal. My first tests used the >> second way to do so, but now I think the first is better : the signal >> tells you both the book and the contact. > > Is that such a problem if the driver loops over an older version of the list? To do what ? It is not a problem if the list of users on ekiga.net isn't updated live. But it certainly is if your XMPP roster isn't ! >> First, you don't handle the case where several telephone numbers are >> available. > > Yeah, yeah. That was just an example. :-) >> Then if you begin to put /everything/ in the *base* class, that will end >> badly. A base class should only have the most basic capabilities, not >> all of them. > > Well, most address books are expected to deliver names and telephone > numbers ,-). But if you don't want to code hooks that return NULL all the > time for properties that do not exist (which I can understand), there's an > easy and clean variant: > class EkigaContact > { > public: > enum property { name, telephone, street, ... }; > > virtual bool hasProperty(property p) const = 0; > gchar *value(property p) const = 0; > }; Eh... this looks like GObject properties! >> As a last comment, I will repoint the two arguments I have to prefer a >> GObject solution to a C++ solution : > > Well, that's the kind of debate that can typically end up in a religious > war ;-), but: > 1) why reinvent the wheel? C++ has mechanisms for object programming, it's > rather strange to reimplement them in C; > 2) such choices tie Ekiga more deeply into GNOME libraries (okay, it's a GNOME > project. But...) glib/gobject isn't gnome. It isn't even graphical. >> 1) the GObject will nicely live and die in the glib mainloop, so we >> won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere ; >> 2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga >> more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame >> /dev/null). > > GBUS is indeed a nice invention ;-). DBUS, not GBUS. Snark From ebischoff@nerim.net Wed Jun 7 17:05:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 354B63B00A5 for ; Wed, 7 Jun 2006 17:05:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14677-05 for ; Wed, 7 Jun 2006 17:05:13 -0400 (EDT) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by menubar.gnome.org (Postfix) with ESMTP id CB5F43B0135 for ; Wed, 7 Jun 2006 17:05:12 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 1E15A437B0 for ; Wed, 7 Jun 2006 22:52:51 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Wed, 7 Jun 2006 22:53:00 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606072033.54523.ebischoff@nerim.net> <4487295A.9060506@free.fr> In-Reply-To: <4487295A.9060506@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606072253.01820.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.573 tagged_above=-999 required=2 tests=[AWL=0.026, BAYES_00=-2.599] X-Spam-Score: -2.573 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 21:05:17 -0000 Le Mercredi 7 Juin 2006 21:30, Julien PUYDT a =C3=A9crit=C2=A0: > > I am not sure that the Evolution, LDAP or KAddressBook drivers will all > > be able to wake up when a new contact is created. The contact can be > > created asynchronously by another user on another machine on some LDAP > > server far away on a network that is broken half of the time, for > > example. So even the underlying Evolution / LDAP / KAddressBook librari= es > > might not know. > > Well, for those what I propose still works : > - they get a list of contacts (and emit the "contact-added" signal for > each) ; > - when they are refreshed, they remove all their contacts, and get the > new list of contacts. What makes you think that they get "refreshed" at some point? > And what I propose works also for XMPP rosters, which are dynamically > updated. Promise, I will look someday what a "XMPP roster" is ;-). > > Furthermore, keeping a list all contacts in memory can have a high cost > > in memory usage. > > Indeed, some books shouldn't treat "get the list of contacts" > litterally. That is why they shouldn't be too stupid :-) Then you must some kind of evolved caching mechanism in your driver. That's= =20 sounds overcomplicated and hard to code to me. If you simply loop through t= he=20 contacts, you can just get the information you need and display it. > > Is that such a problem if the driver loops over an older version of the > > list? > > To do what ? It is not a problem if the list of users on ekiga.net isn't > updated live. But it certainly is if your XMPP roster isn't ! If you convinced me of one thing, it's that I need to look at the definitio= n=20 of these SNMP toasters ;-). > > class EkigaContact > > { > > public: > > enum property { name, telephone, street, ... }; > > > > virtual bool hasProperty(property p) const =3D 0; > > gchar *value(property p) const =3D 0; > > }; > > Eh... this looks like GObject properties! Indeed! Excepted that you are just using the possibilities of the programmi= ng=20 language, not of some library. At this point, I must do some clarification: I am a newcomer to Ekiga and perfectly aware of the fact that I might ignor= e a=20 lot of things about the past and the possible future of this software. I am= a=20 complete ignorant of GNOME and its libraries. I do not know anything about= =20 the multithreading problems that Julien has to deal with. I am not here to= =20 slow down Julien, nor to get my views adopted. I will be more than happy to= =20 adapt my code to *any* API that Julien will bring up. And to shut my big=20 mouth up if anyone ask me to ;-). > glib/gobject isn't gnome. It isn't even graphical. Okay, to me who comes from the KDE world, it's the same thing, it starts wi= th=20 "g" ;-). > > GBUS is indeed a nice invention ;-). > > DBUS, not GBUS. Yes, sorry for the many typos... :-/ =2D-=20 =C3=89ric From jan.schampera@web.de Wed Jun 7 23:13:06 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7395E3B043B for ; Wed, 7 Jun 2006 23:13:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02368-03 for ; Wed, 7 Jun 2006 23:13:03 -0400 (EDT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by menubar.gnome.org (Postfix) with ESMTP id 6D4823B012E for ; Wed, 7 Jun 2006 23:13:03 -0400 (EDT) Received: from fwd35.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1FoAxC-0004rd-00; Thu, 08 Jun 2006 05:13:02 +0200 Received: from mail.home.thebonsai.de (Z2ab0kZBZewL1AHEQWezyBxMlAJSeayZbCOT8jbF9IKQFlf7QKn1Ul@[84.147.102.15]) by fwd35.sul.t-online.de with esmtp id 1FoAx4-1YpxqK0; Thu, 8 Jun 2006 05:12:54 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id 8DF136B173 for ; Thu, 8 Jun 2006 05:12:52 +0200 (CEST) Date: Thu, 8 Jun 2006 05:08:28 +0200 From: Jan Schampera To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Message-ID: <20060608050828.37d3ac08@localhost.localdomain> In-Reply-To: <200606072253.01820.ebischoff@nerim.net> References: <4486BDD0.9050805@free.fr> <200606072033.54523.ebischoff@nerim.net> <4487295A.9060506@free.fr> <200606072253.01820.ebischoff@nerim.net> Organization: private X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-ID: Z2ab0kZBZewL1AHEQWezyBxMlAJSeayZbCOT8jbF9IKQFlf7QKn1Ul@t-dialin.net X-TOI-MSGID: c2323eec-2b6b-468d-b9e5-6ee93ecdce82 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.971 tagged_above=-999 required=2 tests=[AWL=0.627, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.971 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 03:13:06 -0000 On Wed, 7 Jun 2006 22:53:00 +0200 =C3=89ric Bischoff wrote: > (GLib vs OOP) > Indeed! Excepted that you are just using the possibilities of the > programming language, not of some library. Please note, regardless all other arguments, that an own C++-object system will be totally independant of the used framework. In case we leave GTK and GLib some day, the OOP approach won't need any changes. The GObject approach would need either an equivalent in the new framework, or a rewrite to (finally) OOP. Beside that, I tend to say "a matter of taste". J. --=20 dreaming in digital living in realtime thinking in binary talking in IP WELCOME TO OUR WORLD From jpuydt@free.fr Thu Jun 8 04:39:27 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8DA623B05CC for ; Thu, 8 Jun 2006 04:39:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19858-03 for ; Thu, 8 Jun 2006 04:39:24 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id D38EA3B0E0F for ; Thu, 8 Jun 2006 04:39:23 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp6-g19.free.fr (Postfix) with ESMTP id A778922647 for ; Thu, 8 Jun 2006 10:39:22 +0200 (CEST) Message-ID: <4487E272.80605@free.fr> Date: Thu, 08 Jun 2006 10:40:18 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606072033.54523.ebischoff@nerim.net> <4487295A.9060506@free.fr> <200606072253.01820.ebischoff@nerim.net> In-Reply-To: <200606072253.01820.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 08:39:27 -0000 Éric Bischoff a écrit : > Le Mercredi 7 Juin 2006 21:30, Julien PUYDT a écrit : >>> I am not sure that the Evolution, LDAP or KAddressBook drivers will all >>> be able to wake up when a new contact is created. The contact can be >>> created asynchronously by another user on another machine on some LDAP >>> server far away on a network that is broken half of the time, for >>> example. So even the underlying Evolution / LDAP / KAddressBook libraries >>> might not know. >> Well, for those what I propose still works : >> - they get a list of contacts (and emit the "contact-added" signal for >> each) ; >> - when they are refreshed, they remove all their contacts, and get the >> new list of contacts. > > What makes you think that they get "refreshed" at some point? The user triggers the "refresh" action :-) >> And what I propose works also for XMPP rosters, which are dynamically >> updated. > > Promise, I will look someday what a "XMPP roster" is ;-). Perhaps you know what a "jabber roster" is? http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html >>> Furthermore, keeping a list all contacts in memory can have a high cost >>> in memory usage. >> Indeed, some books shouldn't treat "get the list of contacts" >> litterally. That is why they shouldn't be too stupid :-) > > Then you must some kind of evolved caching mechanism in your driver. That's > sounds overcomplicated and hard to code to me. If you simply loop through the > contacts, you can just get the information you need and display it. I don't think a trivial proxying counts as an "evolved caching mechanism" :-) >>> Is that such a problem if the driver loops over an older version of the >>> list? >> To do what ? It is not a problem if the list of users on ekiga.net isn't >> updated live. But it certainly is if your XMPP roster isn't ! > > If you convinced me of one thing, it's that I need to look at the definition > of these SNMP toasters ;-). Who's toast ? ;-) >>> class EkigaContact >>> { >>> public: >>> enum property { name, telephone, street, ... }; >>> >>> virtual bool hasProperty(property p) const = 0; >>> gchar *value(property p) const = 0; >>> }; >> Eh... this looks like GObject properties! > > Indeed! Excepted that you are just using the possibilities of the programming > language, not of some library. Can you add properties to the enum when inheriting ? > At this point, I must do some clarification: > > I am a newcomer to Ekiga and perfectly aware of the fact that I might ignore a > lot of things about the past and the possible future of this software. I am a > complete ignorant of GNOME and its libraries. I do not know anything about > the multithreading problems that Julien has to deal with. I am not here to > slow down Julien, nor to get my views adopted. I will be more than happy to > adapt my code to *any* API that Julien will bring up. And to shut my big > mouth up if anyone ask me to ;-). Yes, yes, no problem. I'm happy to have feedback :-) >> glib/gobject isn't gnome. It isn't even graphical. > > Okay, to me who comes from the KDE world, it's the same thing, it starts with > "g" ;-). glib, gobject & gtk+ already make ekiga run on win32. >>> GBUS is indeed a nice invention ;-). >> DBUS, not GBUS. > > Yes, sorry for the many typos... :-/ Eh... that one was pretty bad for someone who has something against g-letter words ;-) Snark From ebischoff@nerim.net Thu Jun 8 04:49:09 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DA33D3B013D for ; Thu, 8 Jun 2006 04:49:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20394-06 for ; Thu, 8 Jun 2006 04:49:08 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id 682F73B05A7 for ; Thu, 8 Jun 2006 04:49:07 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 6666B41095 for ; Thu, 8 Jun 2006 10:49:06 +0200 (CEST) From: =?iso-8859-15?q?=C9ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 10:49:15 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <20060608050828.37d3ac08@localhost.localdomain> In-Reply-To: <20060608050828.37d3ac08@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606081049.16046.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.577 tagged_above=-999 required=2 tests=[AWL=0.022, BAYES_00=-2.599] X-Spam-Score: -2.577 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 08:49:10 -0000 Le Jeudi 8 Juin 2006 05:08, Jan Schampera a =E9crit=A0: > > Indeed! Excepted that you are just using the possibilities of the > > programming language, not of some library. > > Please note, regardless all other arguments, that an own C++-object > system will be totally independant of the used framework. In case we > leave GTK and GLib some day, the OOP approach won't need any changes. > > The GObject approach would need either an equivalent in the new > framework, or a rewrite to (finally) OOP. Yes. That was precisely my point. > Beside that, I tend to say "a matter of taste". Yes. Sometimes programming has to do with aesthetics. Compare: =3D=3D=3D GObject way =3D=3D=3D struct _GmBook { GObject parent; }; struct _GmBookClass { GObjectClass parent; const gchar *(*get_name)(GmBook *self); }; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D with: =3D=3D=3D C++ way =3D=3D=3D class GmBook { public: virtual get_name() const; } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D My tastes tell me that second code, besides from being much shorter, has mo= re=20 "beauty" than the first one. But as you say, tastes are a very personal=20 thing. =2D-=20 =C9ric From jpuydt@free.fr Thu Jun 8 05:09:16 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C38A43B04E8 for ; Thu, 8 Jun 2006 05:09:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21821-03 for ; Thu, 8 Jun 2006 05:09:15 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 32ECF3B0505 for ; Thu, 8 Jun 2006 05:09:15 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp5-g19.free.fr (Postfix) with ESMTP id BD9EA275B9 for ; Thu, 8 Jun 2006 11:09:13 +0200 (CEST) Message-ID: <4487E971.8070602@free.fr> Date: Thu, 08 Jun 2006 11:10:09 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <20060608050828.37d3ac08@localhost.localdomain> <200606081049.16046.ebischoff@nerim.net> In-Reply-To: <200606081049.16046.ebischoff@nerim.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 09:09:16 -0000 Éric Bischoff a écrit : > Le Jeudi 8 Juin 2006 05:08, Jan Schampera a écrit : >>> Indeed! Excepted that you are just using the possibilities of the >>> programming language, not of some library. >> Please note, regardless all other arguments, that an own C++-object >> system will be totally independant of the used framework. In case we >> leave GTK and GLib some day, the OOP approach won't need any changes. >> >> The GObject approach would need either an equivalent in the new >> framework, or a rewrite to (finally) OOP. > > Yes. That was precisely my point. > >> Beside that, I tend to say "a matter of taste". > > Yes. Sometimes programming has to do with aesthetics. Compare: > > === GObject way === > struct _GmBook { > GObject parent; > }; > > struct _GmBookClass { > GObjectClass parent; > > const gchar *(*get_name)(GmBook *self); > }; > ================== > > with: > > === C++ way === > class GmBook { > public: > virtual get_name() const; > } > ================== > > My tastes tell me that second code, besides from being much shorter, has more > "beauty" than the first one. But as you say, tastes are a very personal > thing. My experience is that when it comes to export the object on DBUS, you're better off with a gobject than with a C++ object. One has some introspection, the other doesn't. I prefer working a little harder upfront, then have an easy life, than writing easy code then feel miserable :-) Snark From ebischoff@nerim.net Thu Jun 8 05:22:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C67273B0598 for ; Thu, 8 Jun 2006 05:22:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22528-04 for ; Thu, 8 Jun 2006 05:22:07 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id D66F33B0B13 for ; Thu, 8 Jun 2006 05:22:06 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 4966F40FBF for ; Thu, 8 Jun 2006 11:22:05 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 11:22:09 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <4487E272.80605@free.fr> In-Reply-To: <4487E272.80605@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606081122.11835.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.579 tagged_above=-999 required=2 tests=[AWL=0.020, BAYES_00=-2.599] X-Spam-Score: -2.579 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 09:22:11 -0000 Le Jeudi 8 Juin 2006 10:40, Julien PUYDT a =C3=A9crit=C2=A0: > > What makes you think that they get "refreshed" at some point? > > The user triggers the "refresh" action :-) Then you loop again through the address book contacts ;-). No need to keep = a=20 copy of the contacts for that. > > Promise, I will look someday what a "XMPP roster" is ;-). > > Perhaps you know what a "jabber roster" is? > http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html No, and this article does not contain the word "roster" :-(. > > Then you must some kind of evolved caching mechanism in your driver. > > That's sounds overcomplicated and hard to code to me. If you simply loop > > through the contacts, you can just get the information you need and > > display it. > > I don't think a trivial proxying counts as an "evolved caching > mechanism" :-) I told you in private that I had a very lazy concept of programming ;-). > Who's toast ? ;-) ;-). > Can you add properties to the enum when inheriting ? Yes: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D class Repas { public: enum plat { nouilles, riz, patates, pain }; virtual void mange(plat p) =3D 0; }; class BonRepas : public Repas { public: enum bonPlat { caviar =3D pain + 1, langouste, foiegras, saumon }; virtual void mange(plat p); }; void BonRepas::mange(plat p) { if ((bonPlat) p =3D=3D langouste) printf("Miam!\n"); } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D With anonymous enums you should even be able to get rid of the casts. But=20 named enums make the code clearer. > Yes, yes, no problem. I'm happy to have feedback :-) Thanks for your openess, Julien :-). > glib, gobject & gtk+ already make ekiga run on win32. I know. But I think it is always good to remove references to libraries if = you=20 do not really need them. > Eh... that one was pretty bad for someone who has something against > g-letter words ;-) I have nothing against, I am just ignorant ;-). =2D-=20 =C3=89ric From conrad_videokonferenz@gmx.de Thu Jun 8 06:04:43 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7A1F63B0CF2 for ; Thu, 8 Jun 2006 06:04:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24863-06 for ; Thu, 8 Jun 2006 06:04:41 -0400 (EDT) Received: from vz17136.evanzo-server.de (vz17136.evanzo-server.de [62.140.17.136]) by menubar.gnome.org (Postfix) with ESMTP id E081B3B05CC for ; Thu, 8 Jun 2006 06:04:40 -0400 (EDT) Received: from c133075.adsl.hansenet.de (c133075.adsl.hansenet.de [213.39.133.75]) (authenticated bits=0) by vz17136.evanzo-server.de (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id k58A4cTf030082 for ; Thu, 8 Jun 2006 12:04:39 +0200 From: Conrad Beckert To: gnomemeeting-devel-list@gnome.org Date: Thu, 8 Jun 2006 10:02:37 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606081002.37875.conrad_videokonferenz@gmx.de> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.106 tagged_above=-999 required=2 tests=[AWL=-1.138, BAYES_05=-1.11, SPF_FAIL=1.142] X-Spam-Score: -1.106 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 10:04:45 -0000 Hi, has anybody an idea where the Debian packages for Ekiga 2.0.2 (or the corresponding CVS versions) are? The last version I can install using apt-get a couple of days old (May 25 - or somethin) - at least this is a version with the nonfunctional German locale. (defaults to English) What's up? Conrad From jpuydt@free.fr Thu Jun 8 06:59:27 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 483C83B0ED8 for ; Thu, 8 Jun 2006 06:59:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27917-10 for ; Thu, 8 Jun 2006 06:59:15 -0400 (EDT) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by menubar.gnome.org (Postfix) with ESMTP id 1C5223B0630 for ; Thu, 8 Jun 2006 06:59:12 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp4-g19.free.fr (Postfix) with ESMTP id A681254974 for ; Thu, 8 Jun 2006 12:59:10 +0200 (CEST) Message-ID: <44880335.3060401@free.fr> Date: Thu, 08 Jun 2006 13:00:05 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606072253.01820.ebischoff@nerim.net> <4487E272.80605@free.fr> <200606081122.11835.ebischoff@nerim.net> In-Reply-To: <200606081122.11835.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 10:59:27 -0000 Éric Bischoff a écrit : > Le Jeudi 8 Juin 2006 10:40, Julien PUYDT a écrit : >>> What makes you think that they get "refreshed" at some point? >> The user triggers the "refresh" action :-) > > Then you loop again through the address book contacts ;-). No need to keep a > copy of the contacts for that. You will need to keep a copy to show them to the user anyway. And notice that a same contact could be shown at several places through the user interface! >>> Promise, I will look someday what a "XMPP roster" is ;-). >> Perhaps you know what a "jabber roster" is? >> http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html > > No, and this article does not contain the word "roster" :-(. The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish them from 'live' contacts. The situation is that you may have jc@jabber.lat in your roster, with the information that the name is "Julius Caesar", and belongs to the groups "Politicians" and "Jokers". But when he connects from his pda, he will show up as jc@jabber.lat/pda, and will neither be able to do VoIP, nor receive XHTML messages. When he is home, he connects from his computer as jc@jabber.lat/home, and will be able to do both. Now he goes to work, from where he shows up as jc@jabber.lat/work, which can do XHTML messaging, but not VoIP. >> Yes, yes, no problem. I'm happy to have feedback :-) > > Thanks for your openess, Julien :-). No problem. More brains means better solutions :-) >> glib, gobject & gtk+ already make ekiga run on win32. > > I know. But I think it is always good to remove references to libraries if you > do not really need them. Well, glib is nice. The main problem KDE problem have with it is that it begins with a 'g' and is already used in GNOME. :-) Snark From ebischoff@nerim.net Thu Jun 8 09:37:50 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CE2BD3B03A6 for ; Thu, 8 Jun 2006 09:37:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08027-03 for ; Thu, 8 Jun 2006 09:37:49 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id 549EB3B0622 for ; Thu, 8 Jun 2006 09:37:48 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 1D58441027 for ; Thu, 8 Jun 2006 15:37:45 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 15:37:53 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606081122.11835.ebischoff@nerim.net> <44880335.3060401@free.fr> In-Reply-To: <44880335.3060401@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606081537.55137.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.504 tagged_above=-999 required=2 tests=[AWL=-0.059, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077] X-Spam-Score: -2.504 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 13:37:51 -0000 Le Jeudi 8 Juin 2006 13:00, Julien PUYDT a =C3=A9crit=C2=A0: > > Then you loop again through the address book contacts ;-). No need to > > keep a copy of the contacts for that. > > You will need to keep a copy to show them to the user anyway. Keeping contacts in memory is not the same at all as keeping an image of wh= at=20 Ekiga has to display of them. The GUI needs basically a list of strings to= =20 display, not the potentially complex data structure of an address book=20 contact. Having one of these complex structures in memory at a time is enough IMHO. Should it be only for performance reasons: when the user scrolls down the l= ist=20 by one contact, it is much quicker to retreive data from a prepared list of= =20 strings than from the contact itself. > And notice=20 > that a same contact could be shown at several places through the user > interface! Yes, and perharps displayed in different ways. > > No, and this article does not contain the word "roster" :-(. > > The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish > them from 'live' contacts. > > The situation is that you may have jc@jabber.lat in your roster, with > the information that the name is "Julius Caesar", and belongs to the > groups "Politicians" and "Jokers". But when he connects from his pda, he > will show up as jc@jabber.lat/pda, and will neither be able to do VoIP, > nor receive XHTML messages. When he is home, he connects from his > computer as jc@jabber.lat/home, and will be able to do both. Now he goes > to work, from where he shows up as jc@jabber.lat/work, which can do > XHTML messaging, but not VoIP. Aha. > > Thanks for your openess, Julien :-). > > No problem. More brains means better solutions :-) Yes, indeed. I hope my advice brings something constructive. As I told you = in=20 private, you keep it or throw it, it's your decision. > > I know. But I think it is always good to remove references to libraries > > if you do not really need them. > > Well, glib is nice. The main problem KDE problem have with it is that it > begins with a 'g' and is already used in GNOME. :-) Do not believe that. We are not religious people. For example, we are very= =20 happy sharing libxml with GNOME. Even though there is already a XML API in= =20 Qt! Just because libxml rocks... (oh yeah, there's no "g" in libxml... ;-) ) We already share libxml, desktop files, DocBook documentation, DBUS=20 communication, po translation memories, and many, many other things. Cool=20 apps like Ekiga can run in a KDE environment. Cool apps like ... errr...=20 KEuroCalc ;-) can run in a GNOME environment. And in fact I know that many= =20 people do that. In fact, the more we will be able to share with you, the happier we will be= =2E I=20 can ensure you that this has always been what we said, even during private= =20 discussions at KDE meetings. I do not know why we do not share glib. I have my ideas about that, but it'= s=20 just personal assumptions ;-). =2D-=20 =C3=89ric From jpuydt@free.fr Thu Jun 8 15:02:29 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6459F3B0F68 for ; Thu, 8 Jun 2006 15:02:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30195-09 for ; Thu, 8 Jun 2006 15:02:28 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id 1D6653B035A for ; Thu, 8 Jun 2006 15:02:28 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp6-g19.free.fr (Postfix) with ESMTP id A118022783 for ; Thu, 8 Jun 2006 21:02:23 +0200 (CEST) Message-ID: <4488747B.6080906@free.fr> Date: Thu, 08 Jun 2006 21:03:23 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code References: <4486BDD0.9050805@free.fr> <200606081122.11835.ebischoff@nerim.net> <44880335.3060401@free.fr> <200606081537.55137.ebischoff@nerim.net> In-Reply-To: <200606081537.55137.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.512 tagged_above=-999 required=2 tests=[AWL=-0.067, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077] X-Spam-Score: -2.512 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:02:29 -0000 Éric Bischoff a écrit : >> You will need to keep a copy to show them to the user anyway. > > Keeping contacts in memory is not the same at all as keeping an image of what > Ekiga has to display of them. The GUI needs basically a list of strings to > display, not the potentially complex data structure of an address book > contact. > > Having one of these complex structures in memory at a time is enough IMHO. Not at all. And it won't allow you to update informations like presence easily. > Should it be only for performance reasons: when the user scrolls down the list > by one contact, it is much quicker to retreive data from a prepared list of > strings than from the contact itself. The contact isn't that much more than strings... >> And notice >> that a same contact could be shown at several places through the user >> interface! > > Yes, and perharps displayed in different ways. Yes, that too. >>> No, and this article does not contain the word "roster" :-(. >> The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish >> them from 'live' contacts. >> >> The situation is that you may have jc@jabber.lat in your roster, with >> the information that the name is "Julius Caesar", and belongs to the >> groups "Politicians" and "Jokers". But when he connects from his pda, he >> will show up as jc@jabber.lat/pda, and will neither be able to do VoIP, >> nor receive XHTML messages. When he is home, he connects from his >> computer as jc@jabber.lat/home, and will be able to do both. Now he goes >> to work, from where he shows up as jc@jabber.lat/work, which can do >> XHTML messaging, but not VoIP. > > Aha. Yes, it's that bad :-/ >>> Thanks for your openess, Julien :-). >> No problem. More brains means better solutions :-) > > Yes, indeed. I hope my advice brings something constructive. As I told you in > private, you keep it or throw it, it's your decision. Last time you wrote that I ended throwing both your ideas and mines ;-) >>> I know. But I think it is always good to remove references to libraries >>> if you do not really need them. >> Well, glib is nice. The main problem KDE problem have with it is that it >> begins with a 'g' and is already used in GNOME. :-) > > Do not believe that. We are not religious people. For example, we are very > happy sharing libxml with GNOME. Even though there is already a XML API in > Qt! Just because libxml rocks... > > (oh yeah, there's no "g" in libxml... ;-) ) > > We already share libxml, desktop files, DocBook documentation, DBUS > communication, po translation memories, and many, many other things. Cool > apps like Ekiga can run in a KDE environment. Cool apps like ... errr... > KEuroCalc ;-) can run in a GNOME environment. And in fact I know that many > people do that. What is KEuroCalc ? > In fact, the more we will be able to share with you, the happier we will be. I > can ensure you that this has always been what we said, even during private > discussions at KDE meetings. This is why it's so important to have a good DBUS component. And this is made easier by using glib-object :-) > I do not know why we do not share glib. I have my ideas about that, but it's > just personal assumptions ;-). I can make a few guesses : 1) it does things that QT does ; 2) it does things that C++ STL does. Snark From ebischoff@nerim.net Thu Jun 8 15:38:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D9F313B054E for ; Thu, 8 Jun 2006 15:38:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32745-08 for ; Thu, 8 Jun 2006 15:38:37 -0400 (EDT) Received: from mallaury.nerim.net (smtp-104-thursday.noc.nerim.net [62.4.17.104]) by menubar.gnome.org (Postfix) with ESMTP id 3976E3B000E for ; Thu, 8 Jun 2006 15:38:35 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by mallaury.nerim.net (Postfix) with ESMTP id 1ED2F4F3A4 for ; Thu, 8 Jun 2006 21:38:22 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Subject: Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code Date: Thu, 8 Jun 2006 21:38:46 +0200 User-Agent: KMail/1.8.2 References: <4486BDD0.9050805@free.fr> <200606081537.55137.ebischoff@nerim.net> <4488747B.6080906@free.fr> In-Reply-To: <4488747B.6080906@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606082138.46648.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.576 tagged_above=-999 required=2 tests=[AWL=0.023, BAYES_00=-2.599] X-Spam-Score: -2.576 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:38:40 -0000 Le Jeudi 8 Juin 2006 21:03, Julien PUYDT a =C3=A9crit=C2=A0: > > We already share libxml, desktop files, DocBook documentation, DBUS > > communication, po translation memories, and many, many other things. Co= ol > > apps like Ekiga can run in a KDE environment. Cool apps like ... errr... > > KEuroCalc ;-) can run in a GNOME environment. And in fact I know that > > many people do that. > > What is KEuroCalc ? Mentioning it was merely a joke: it's a small KDE app that I wrote. http://opensource.bureau-cornavin.com/keurocalc/ ;-) > > I do not know why we do not share glib. I have my ideas about that, but > > it's just personal assumptions ;-). > > I can make a few guesses : > 1) it does things that QT does ; > 2) it does things that C++ STL does. Exactly the same guesses as me ;-). It even does things that C++ _alone_ do= es. Best, =2D-=20 =C3=89ric From ph.l@libertysurf.fr Thu Jun 8 15:47:49 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9705F3B1039 for ; Thu, 8 Jun 2006 15:47:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00870-02 for ; Thu, 8 Jun 2006 15:47:38 -0400 (EDT) Received: from smtp4.mail.easynet.fr (smarthost169.mail.easynet.fr [212.180.1.169]) by menubar.gnome.org (Postfix) with ESMTP id 527163B1020 for ; Thu, 8 Jun 2006 15:47:35 -0400 (EDT) Received: from asi-236.asi256ip.easynet.fr ([212.180.39.236] helo=[145.111.24.1]) by smtp4.mail.easynet.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FoQUy-0004IP-Fg for gnomemeeting-devel-list@gnome.org; Thu, 08 Jun 2006 21:48:56 +0200 Message-ID: <44887ECE.9040902@libertysurf.fr> Date: Thu, 08 Jun 2006 21:47:26 +0200 From: Philippe Lefevre User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: gnomemeeting-devel-list@gnome.org References: <20060608160031.473BF3B0FB3@menubar.gnome.org> In-Reply-To: <20060608160031.473BF3B0FB3@menubar.gnome.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.436 tagged_above=-999 required=2 tests=[AWL=-0.853, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, TW_BX=0.077, TW_IB=0.077, TW_RW=0.077, TW_WX=0.077] X-Spam-Score: -1.436 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ekiga under windows X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ph.l@libertysurf.fr, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:47:49 -0000 Hello, Today I tried to install ekiga on my PC under XP and I never get anything to work :'( You'll find bellow what I did. I can do some other tests if it may in any help. PhiL My PC is running Windows XP SP1 1G memory. I installed GTK 2.0 (version 2.8.9.0) installed under C:\Program Files\Fichiers communs\GTK\2.0 and Ekiga (downloaded from CVS June 8, 2006) installed under C:\Program Files\Ekiga CYGWIN and MSYS are installed too with XP : nothing happen, no log (empty file even with -d 4 option) with MSYS : same issue $ echo $PATH .:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32: /c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/oracle9/bin:/c/oracle8/bin: /i/progicil/orawin2:/i/progicil/orawin2/bin: /c/Program Files/Microsoft SQL Server/80/Tools/BINN: /c/Program Files/Fichiers communs/GTK/2.0/bin:/c/php5: /c/php5/ext:/c/Program Files/MySQL/MySQL Server 5.0/bin: /c/bin:/c/cygdrive/c/cygwin/bin:/c/cygdrive/c/cygwin/sbin:/c/oracle9/bin: /c/oracle8/bin:/i/progicil/orawin2:/i/progicil/orawin2/bin: /c/Program Files/Ekiga:/c/caml/bin PHL@BORG /c/program files/ekiga $ ./ekiga.exe 1>log 2>&1 Log is empty $ ls -rwxr-xr-x 1 PHL Administ 7934464 May 16 05:26 ekiga.exe -rw-r--r-- 1 PHL Administ 1231950 May 16 05:26 ekiga.schemas -rwxr-xr-x 1 PHL Administ 44032 May 16 05:26 liblber.dll -rwxr-xr-x 1 PHL Administ 188416 May 16 05:26 libldap_r.dll -rwxr-xr-x 1 PHL Administ 1276928 May 16 05:26 libxml2-2.dll drwxr-xr-x 70 PHL Administ 0 Jun 8 09:52 locale -rw-r--r-- 1 PHL Administ 0 Jun 8 13:30 log Using GDB in a cygdrive environment : $ gdb ekiga.exe GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) (gdb) run Starting program: /cygdrive/c/Program Files/Ekiga/ekiga.exe Program received signal SIGSEGV, Segmentation fault. Program received signal SIGSEGV, Segmentation fault. Program exited with code 0200. You can't do that without a process to debug. (gdb) bt No stack. (gdb) From jpuydt@free.fr Thu Jun 8 15:50:47 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 143943B027F for ; Thu, 8 Jun 2006 15:50:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01017-01 for ; Thu, 8 Jun 2006 15:50:46 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id E67403B021A for ; Thu, 8 Jun 2006 15:50:45 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-27-82-248-31-32.adsl.proxad.net [82.248.31.32]) by smtp3-g19.free.fr (Postfix) with ESMTP id C567B4901D; Thu, 8 Jun 2006 21:50:43 +0200 (CEST) Message-ID: <44887FCD.7040300@free.fr> Date: Thu, 08 Jun 2006 21:51:41 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: ph.l@libertysurf.fr, GnomeMeeting development mailing list Subject: Re: [GnomeMeeting-devel-list] Ekiga under windows References: <20060608160031.473BF3B0FB3@menubar.gnome.org> <44887ECE.9040902@libertysurf.fr> In-Reply-To: <44887ECE.9040902@libertysurf.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.434 tagged_above=-999 required=2 tests=[AWL=-0.143, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077, TW_RW=0.077, TW_WX=0.077] X-Spam-Score: -2.434 X-Spam-Level: Cc: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 19:50:47 -0000 Philippe Lefevre a écrit : > Today I tried to install ekiga on my PC under XP and I never get > anything to work :'( Yes, we don't have a nice installer yet. > I installed GTK 2.0 (version 2.8.9.0) installed under > C:\Program Files\Fichiers communs\GTK\2.0 I'm wondering if that is recent enough. > CYGWIN and MSYS are installed too Unnecessary. > $ ls > -rwxr-xr-x 1 PHL Administ 7934464 May 16 05:26 ekiga.exe > -rw-r--r-- 1 PHL Administ 1231950 May 16 05:26 ekiga.schemas > -rwxr-xr-x 1 PHL Administ 44032 May 16 05:26 liblber.dll > -rwxr-xr-x 1 PHL Administ 188416 May 16 05:26 libldap_r.dll > -rwxr-xr-x 1 PHL Administ 1276928 May 16 05:26 libxml2-2.dll > drwxr-xr-x 70 PHL Administ 0 Jun 8 09:52 locale > -rw-r--r-- 1 PHL Administ 0 Jun 8 13:30 log No libSDL.dll or some such ? :-/ Snark From ph.l@libertysurf.fr Thu Jun 8 16:43:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 40F853B00EA for ; Thu, 8 Jun 2006 16:43:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04211-07 for ; Thu, 8 Jun 2006 16:43:38 -0400 (EDT) Received: from smtp3.mail.easynet.fr (smarthost168.mail.easynet.fr [212.180.1.168]) by menubar.gnome.org (Postfix) with ESMTP id 52BD23B000E for ; Thu, 8 Jun 2006 16:43:37 -0400 (EDT) Received: from asi-236.asi256ip.easynet.fr ([212.180.39.236] helo=[145.111.24.1]) by smtp3.mail.easynet.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FoRMF-0007kr-6F; Thu, 08 Jun 2006 22:43:59 +0200 Message-ID: <44888BF6.8020906@libertysurf.fr> Date: Thu, 08 Jun 2006 22:43:34 +0200 From: Philippe Lefevre User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: Julien PUYDT , gnomemeeting-devel-list@gnome.org References: <20060608160031.473BF3B0FB3@menubar.gnome.org> <44887ECE.9040902@libertysurf.fr> <44887FCD.7040300@free.fr> In-Reply-To: <44887FCD.7040300@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.283 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, TW_BX=0.077, TW_IB=0.077, TW_RW=0.077, TW_WX=0.077] X-Spam-Score: -2.283 X-Spam-Level: Cc: Subject: [GnomeMeeting-devel-list] Re : Ekiga under windows X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ph.l@libertysurf.fr, GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 20:43:39 -0000 Julien PUYDT a écrit : > Philippe Lefevre a écrit : > >> Today I tried to install ekiga on my PC under XP and I never get >> anything to work :'( > > > Yes, we don't have a nice installer yet. No pb, unzip works well for now. > >> I installed GTK 2.0 (version 2.8.9.0) installed under >> C:\Program Files\Fichiers communs\GTK\2.0 > > > I'm wondering if that is recent enough. > 2.8.9.0 is the latest stable version but there is a 2.8.15 too dated from March (still unstable ?) >> CYGWIN and MSYS are installed too > > > Unnecessary. > Of course. It's just to use dbg. (I installed it for other things anyway) >> $ ls >> -rwxr-xr-x 1 PHL Administ 7934464 May 16 05:26 ekiga.exe >> -rw-r--r-- 1 PHL Administ 1231950 May 16 05:26 ekiga.schemas >> -rwxr-xr-x 1 PHL Administ 44032 May 16 05:26 liblber.dll >> -rwxr-xr-x 1 PHL Administ 188416 May 16 05:26 libldap_r.dll >> -rwxr-xr-x 1 PHL Administ 1276928 May 16 05:26 libxml2-2.dll >> drwxr-xr-x 70 PHL Administ 0 Jun 8 09:52 locale >> -rw-r--r-- 1 PHL Administ 0 Jun 8 13:30 log > > > No libSDL.dll or some such ? :-/ > Sorry I don't think so. I will check tomorrow (it is on my PC at work) But, I just check the zip file... there is no libSDL (or name close to that) into it. > Snark > Thanks Julien. From mcquaidster@gmail.com Thu Jun 8 17:09:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DF4253B0622 for ; Thu, 8 Jun 2006 17:09:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05835-02 for ; Thu, 8 Jun 2006 17:09:06 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id 76D583B0F9D for ; Thu, 8 Jun 2006 17:09:06 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id z74so693545pyg for ; Thu, 08 Jun 2006 14:09:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=HVNAtak5n7Z91wpmXr/Qu5ON4YhH7Q4dCf+4y5GUbTwwY23VOAXrmjBMj7263bIU8fqFePgmvS6HIFqN59D2Jy6YmXM2xD1V+aMpky/Ed9jdEhbQxbJYZUEi6YN6vk99BkQspxK0SEsZWjsxDvHu3Rk9O5hKBW5HcpVNrhkyGCo= Received: by 10.35.63.2 with SMTP id q2mr2928428pyk; Thu, 08 Jun 2006 14:09:05 -0700 (PDT) Received: by 10.35.31.2 with HTTP; Thu, 8 Jun 2006 14:09:05 -0700 (PDT) Message-ID: <58a398810606081409o3026d11cnd9f5f3a16b0243e@mail.gmail.com> Date: Thu, 8 Jun 2006 17:09:05 -0400 From: "mcquaid mcquaid" To: "GnomeMeeting development mailing list" In-Reply-To: <58a398810606061625x7684427q73db38225fa398dc@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10127_1193274.1149800945207" References: <58a398810606061625x7684427q73db38225fa398dc@mail.gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.359 tagged_above=-999 required=2 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.359 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Re: no audio on incoming calls. X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 21:09:10 -0000 ------=_Part_10127_1193274.1149800945207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Can I get any assistance on this or is there something else I should be providing? I can get other voip apps like linphone working but I can't get ekiga to transmit audio either way on incoming calls. Not sure if it's any help but asterisk seems to behave in the same manner. With asterisk I again could make outgoing call fine, but for incoming it would route calls to my local sipphone, but no audio either way. On 6/6/06, mcquaid mcquaid wrote: > > I have tried ekiga from time to time, and now using the latest cvs, I > still have the same problem. > > On outgoing calls, audio transmits both ways without issue. > > When receiving a call, no audio is transmitted either way. > > I realize it'll probably be considered a firewall issue, but linphone has > always worked for me and I have never setup stun or a nat traversal method > in linphone. I'd prefer to use ekiga instead of linphone. > > Here is the output of an incoming call that lasts until ekiga reports > 'remote user cleared the call'. > > I tried ekiga lastest cvs as I read about 2.02 hoping this might have been > resolved. > > > > ------=_Part_10127_1193274.1149800945207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Can I get any assistance on this or is there something else I should be providing?  I can get other voip apps like linphone working but I can't get ekiga to transmit audio either way on incoming calls.  Not sure if it's any help but asterisk seems to behave in the same manner.  With asterisk I again could make outgoing call fine, but for incoming it would route calls to my local sipphone, but no audio either way.

On 6/6/06, mcquaid mcquaid <mcquaidster@gmail.com> wrote:
I have tried ekiga from time to time, and now using the latest cvs, I still have the same problem.

On outgoing calls, audio transmits both ways without issue.

When receiving a call, no audio is transmitted either way.

I realize it'll probably be considered a firewall issue, but linphone has always worked for me and I have never setup stun or a nat traversal method in linphone.  I'd prefer to use ekiga instead of linphone.

Here is the output of an incoming call that lasts until ekiga reports 'remote user cleared the call'.

I tried ekiga lastest cvs as I read about 2.02 hoping this might have been resolved.




------=_Part_10127_1193274.1149800945207-- From dsandras@seconix.com Fri Jun 9 03:56:41 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5D27B3B006E for ; Fri, 9 Jun 2006 03:56:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05479-07 for ; Fri, 9 Jun 2006 03:56:39 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 62A113B017E for ; Fri, 9 Jun 2006 03:56:39 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 2E8E349758 for ; Fri, 9 Jun 2006 09:38:49 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16204-09 for ; Fri, 9 Jun 2006 09:38:42 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 6559949755 for ; Fri, 9 Jun 2006 09:38:42 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Re: no audio on incoming calls. From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <58a398810606081409o3026d11cnd9f5f3a16b0243e@mail.gmail.com> References: <58a398810606061625x7684427q73db38225fa398dc@mail.gmail.com> <58a398810606081409o3026d11cnd9f5f3a16b0243e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Fri, 09 Jun 2006 09:56:30 +0200 Message-Id: <1149839790.3351.0.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 07:56:41 -0000 You should provide a debug 4 output. Le jeudi 08 juin 2006 à 17:09 -0400, mcquaid mcquaid a écrit : > Can I get any assistance on this or is there something else I should > be providing? I can get other voip apps like linphone working but I > can't get ekiga to transmit audio either way on incoming calls. Not > sure if it's any help but asterisk seems to behave in the same manner. > With asterisk I again could make outgoing call fine, but for incoming > it would route calls to my local sipphone, but no audio either way. > > On 6/6/06, mcquaid mcquaid wrote: > I have tried ekiga from time to time, and now using the latest > cvs, I still have the same problem. > > On outgoing calls, audio transmits both ways without issue. > > When receiving a call, no audio is transmitted either way. > > I realize it'll probably be considered a firewall issue, but > linphone has always worked for me and I have never setup stun > or a nat traversal method in linphone. I'd prefer to use > ekiga instead of linphone. > > Here is the output of an incoming call that lasts until ekiga > reports 'remote user cleared the call'. > > I tried ekiga lastest cvs as I read about 2.02 hoping this > might have been resolved. > > > > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From ph.l@libertysurf.fr Sat Jun 10 12:49:37 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 174BA3B01B8 for ; Sat, 10 Jun 2006 12:49:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15518-01 for ; Sat, 10 Jun 2006 12:49:36 -0400 (EDT) Received: from smtp4.mail.easynet.fr (smarthost169.mail.easynet.fr [212.180.1.169]) by menubar.gnome.org (Postfix) with ESMTP id C9C343B032B for ; Sat, 10 Jun 2006 12:49:35 -0400 (EDT) Received: from asi-236.asi256ip.easynet.fr ([212.180.39.236] helo=[145.111.24.1]) by smtp4.mail.easynet.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Fp6fr-0001ZY-Dc for gnomemeeting-devel-list@gnome.org; Sat, 10 Jun 2006 18:50:59 +0200 Message-ID: <448AF812.4010106@libertysurf.fr> Date: Sat, 10 Jun 2006 18:49:22 +0200 From: Philippe Lefevre User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: GnomeMeeting devel list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.839 tagged_above=-999 required=2 tests=[AWL=-1.437, BAYES_05=-1.11, DNS_FROM_RFC_POST=1.708] X-Spam-Score: -0.839 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ekiga 2.0.2 Ubuntu packages X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 16:49:37 -0000 Hi all, For a few days I'm looking for Ekiga 2.0.2 for ubuntu packages @ http://www.ekiga.org but there are no link available yet. Is this normal ? Thanks. PhiL From mathiaschulze@gmail.com Sun Jun 11 10:47:28 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7E1CC3B00B0 for ; Sun, 11 Jun 2006 10:47:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14779-09 for ; Sun, 11 Jun 2006 10:47:27 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by menubar.gnome.org (Postfix) with ESMTP id 6898E3B0084 for ; Sun, 11 Jun 2006 10:47:27 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id 9so1563867nzo for ; Sun, 11 Jun 2006 07:46:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=RdwAYw0jPdY9iOC0Sf+iOKQJ9I7YfnL/kWXyEPnc+Cr+QIVa1sKM88ZdFWngpOkudGwRUvtt1Aw9vAL7lpvseD6hTwpLtjhbhu306m/DpJDRigRtWN/PSaYRcSohSjgiAaMN7SNdOXCHLIjQ0ZzdPpKX46kbgKn0qo2/Dg4UYbo= Received: by 10.37.2.45 with SMTP id e45mr7180725nzi; Sun, 11 Jun 2006 07:46:45 -0700 (PDT) Received: from vaio ( [71.98.110.104]) by mx.gmail.com with ESMTP id 37sm151203nzf.2006.06.11.07.46.44; Sun, 11 Jun 2006 07:46:45 -0700 (PDT) From: Mathias Schulze To: gnomemeeting-devel-list@gnome.org Content-Type: text/plain Date: Sun, 11 Jun 2006 10:46:43 -0400 Message-Id: <1150037203.24558.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.821 tagged_above=-999 required=2 tests=[AWL=-0.779, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.821 X-Spam-Level: Subject: [GnomeMeeting-devel-list] alsa default device X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 14:47:28 -0000 Hello, I would like to make Ekiga automatically use my USB Headset whenever it is plugged in. It is no problem to switch the default device to the headset by a udev rule. But Ekiga seems to ignore any changes of the default device after start-up. I think if the default device is selected Ekiga should check the current default device immediately before starting the conversation. So if someone calls I can plug in the USB headset and accept the call. An example of a program which seems to do this is the gnome music player "Listen". An even better solution (but maybe too much work?) could be if Ekiga pops up a request whenever a new audio device appears to ask the user if this device should be used. Such request appears e.g. under Ubuntu in the control panel. Thanks for Ekiga, it's really great! Mathias From dsandras@seconix.com Mon Jun 12 04:46:20 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EDE963B00D8 for ; Mon, 12 Jun 2006 04:46:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26328-09 for ; Mon, 12 Jun 2006 04:46:16 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id B27083B009D for ; Mon, 12 Jun 2006 04:46:16 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 8BE0B83C22 for ; Mon, 12 Jun 2006 10:26:53 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29245-09 for ; Mon, 12 Jun 2006 10:26:48 +0200 (CEST) Received: from [192.168.0.161] (157.137-245-81.adsl-dyn.isp.belgacom.be [81.245.137.157]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id BF7E583C1F for ; Mon, 12 Jun 2006 10:26:48 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] Ekiga 2.0.2 Ubuntu packages From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <448AF812.4010106@libertysurf.fr> References: <448AF812.4010106@libertysurf.fr> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 12 Jun 2006 10:46:31 +0200 Message-Id: <1150101991.2505.12.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 08:46:20 -0000 Le samedi 10 juin 2006 à 18:49 +0200, Philippe Lefevre a écrit : > Hi all, > For a few days I'm looking for Ekiga 2.0.2 for ubuntu packages @ > http://www.ekiga.org > but there are no link available yet. Is this normal ? They are coming soon... -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Mon Jun 12 08:26:32 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 96E503B0061 for ; Mon, 12 Jun 2006 08:26:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01773-10 for ; Mon, 12 Jun 2006 08:26:29 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 0BDDA3B000D for ; Mon, 12 Jun 2006 08:26:28 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id A4ACC83C24 for ; Mon, 12 Jun 2006 13:43:24 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15346-08 for ; Mon, 12 Jun 2006 13:43:15 +0200 (CEST) Received: from [192.168.0.161] (157.137-245-81.adsl-dyn.isp.belgacom.be [81.245.137.157]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 3FB8E83C22 for ; Mon, 12 Jun 2006 13:43:15 +0200 (CEST) Subject: Re: [GnomeMeeting-devel-list] alsa default device From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <1150037203.24558.24.camel@localhost.localdomain> References: <1150037203.24558.24.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 12 Jun 2006 14:03:41 +0200 Message-Id: <1150113821.7909.5.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 12:26:32 -0000 Hi, Le dimanche 11 juin 2006 à 10:46 -0400, Mathias Schulze a écrit : > Hello, > > I would like to make Ekiga automatically use my USB Headset whenever it > is plugged in. It is no problem to switch the default device to the > headset by a udev rule. But Ekiga seems to ignore any changes of the > default device after start-up. > It is most probably due to ALSA and libasound if I understand correctly what you mean. If you change from "USB Headset" to "Soundcard" or to "Default", Ekiga will work correctly. However, you probably mean that you want to select "Default" as device in Ekiga and that "Default" will be linked to the USB headset or to the soundcard depending if the headset is plugged in or not. For Ekiga, it is transparent. Ekiga simply open the "Default" device when playing sounds. If the "Default" device is linked in real time to the USB headset while Ekiga is running, and if it still uses the sound card, then it means that libasound already mapped the default device to the soundcard when starting the application and doesn't accept changing it. So I would say that I'm 100% confident it is an ALSA limitation. However, I tried here changing the settings of my default device through .asoundrc when Ekiga is running and it works. > I think if the default device is selected Ekiga should check the current > default device immediately before starting the conversation. So if > someone calls I can plug in the USB headset and accept the call. > An example of a program which seems to do this is the gnome music player > "Listen". It is transparent for Ekiga. Ekiga opens the "Default" device whatever it is through ALSA. > > An even better solution (but maybe too much work?) could be if Ekiga > pops up a request whenever a new audio device appears to ask the user if > this device should be used. Such request appears e.g. under Ubuntu in > the control panel. It is planned in the future through HAL. > > Thanks for Ekiga, it's really great! > Mathias > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From dsandras@seconix.com Mon Jun 12 17:23:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 441F03B01DB for ; Mon, 12 Jun 2006 17:23:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31653-03 for ; Mon, 12 Jun 2006 17:23:08 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 994B13B0010 for ; Mon, 12 Jun 2006 17:23:08 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id 666F683C23 for ; Mon, 12 Jun 2006 23:01:22 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19698-06 for ; Mon, 12 Jun 2006 23:01:18 +0200 (CEST) Received: from [192.168.0.161] (157.137-245-81.adsl-dyn.isp.belgacom.be [81.245.137.157]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id AFAEE83C22 for ; Mon, 12 Jun 2006 23:01:18 +0200 (CEST) From: Damien Sandras To: gnomemeeting-devel-list@gnome.org Content-Type: text/plain Date: Mon, 12 Jun 2006 23:24:02 +0200 Message-Id: <1150147442.11823.2.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Subject: [GnomeMeeting-devel-list] New user interface : first stubs X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 21:23:10 -0000 Hi to all, I committed the first stubs of the new user interface. Please do not criticize too much as it is work in progress and it is in the very early stages of development. Julien is working on big changes too, but that should have no impact on the user interface. In the next few weeks, I will work more on : - the user interface - sip support (integrate Craig's changes) And finally work on a roster. Enjoy, -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From jpuydt@free.fr Tue Jun 13 13:58:03 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 530F33B03CF for ; Tue, 13 Jun 2006 13:58:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01110-02 for ; Tue, 13 Jun 2006 13:58:01 -0400 (EDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by menubar.gnome.org (Postfix) with ESMTP id EC4F23B00DB for ; Tue, 13 Jun 2006 13:58:00 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by postfix1-c.free.fr (Postfix) with ESMTP id 91A4B1CF1DC3 for ; Tue, 13 Jun 2006 17:47:25 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-32-82-254-24-205.adsl.proxad.net [82.254.24.205]) by smtp6-g19.free.fr (Postfix) with ESMTP id CD69E2286C for ; Tue, 13 Jun 2006 18:42:21 +0200 (CEST) Message-ID: <448EC473.7060800@free.fr> Date: Tue, 13 Jun 2006 15:58:11 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <448B2A40.5060600@free.fr> <20060612174347.5181a8f9@localhost.localdomain> <448DABA7.4060103@free.fr> <200606130951.56969.ebischoff@nerim.net> In-Reply-To: <200606130951.56969.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.567 tagged_above=-999 required=2 tests=[AWL=0.032, BAYES_00=-2.599] X-Spam-Score: -2.567 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 17:58:03 -0000 Hi, in private mails (with quite big attachments since I provided some sample stupid code), Éric Bischoff found my code not that explicit concerning what I have in mind. Since I would like to keep things as opened as possible, I drop my text here :-) Let's see if I can manage to give useful ideas. ***** BIG WORDS Model - View - Controller ***** VIEWING (GENERIC) We need to be able to present a book to the user. For that, the view needs to have a list of contacts (no, a single contact definitely isn't enough!). So we need a function call to get a list of contacts. The problem is that this list will change during time (new contacts added, others removed, presence changed, status message changed, and the list goes on). So the view will need to be notified about it. Hence the idea that the book will have "contact-added" and "contact-removed" signals, and the contacts a "updated" signal. In addition to that, there is an interesting special case to handle : you have a contact in a book, and this contact shows up in a search result. When you remove the contact from the book, we want to make it disappear from the list too. Hence a "removed" signal for contacts. Now this is all nice, but what can we do if an addressbook contains millions of entries ? And if a search gives thousands of results ? In such cases, my stance is that the low level code should do something about it, since it is the one giving the problem. How can the high level code cope correctly with the situation anyway ? Only the low level code can say "Eh, I already made two hundred contacts go through the wire for that search, perhaps I should make it easy!". The question to really ask, and to which I have no satisfactory answer is: "How do me make the low level tell the high level it had to cut the list ?". ***** VIEWING (CONTACTS) The contacts should contain enough to be viewed from a generic view in the contacts window, and be shown in a search result. That won't prevent some other parts of the code to make a better use of them. For example, in the contact window we will probably be able to see a contact's title and description, but not its detailed presence, while the main window will contain a much better and more specific view for the live contacts. ***** CONTROLLING (GENERIC) Now, we want to be able to act on our objects ; say rename a book or a contact, subscribe/unsubscribe to its presence, etc. The best thing to do is to be able to get menus for each of them. Notice the plural: we will certainly to have at least menu in the menu bar and a popup menu. The first bad news about such menus is that they won't be generic : they will depend heavily on the specific type of object (no rename for avahi contacts, subscribe/unsubscribe only for XMPP contacts...). So we will certainly need some sort of shared actions that will be basic bricks for building menu (like the shared-actions.[ch] of my first round of proposals), that each implementation will mix as it sees fit. The second bad news about them is that they won't be static either. They will have to update themselves following the object they are attached to. Say your nice XMPP contact is connected with a client which has VoIP support, but now connects with a no-VoIP client, and disconnects the first : we want the "Call" menuitem to disappear to reflect this. So my proposition (no code yet) is that those menus will be obtained by subclassing of GtkMenu, register to get signals from the contact/book they are attached to, and use that to keep themselves up to date. ***** CONTROLLING (CONTACTS) Let's try to be more specific: in avahi-contact-menu.h, we would have: GtkWidget *avahi_contact_menu_new (AvahiContact *contact); and in gm-contact.h: GtkWidget *gm_contact_get_menu_new (GmContact *contact); This later function would be different in each implementation, which allows for example the avahi_contact_get_menu_new implementation to call avahi_contact_menu_new. The high level code called a generic function, but got access to a very specific implementation, which knows the full api of the specific contact, and hence will provide the best service. ***** CONTROLLING (BOOKS) Perhaps the menu shouldn't be attached to the book himself, but to its view. That would allow to place things such as "Show offline contacts" in it. Mostly the idea would be to have controllers for both the model-as-model and its view-as-model. ***** ABOUT EVOLUTION-DATA-SERVER The evolution-data-server api looks pretty good -- except that it seems to mainly handle static vcard-based contacts, where I would like to be able to handle things like. For example, we find a nice contacts-changed signal, but in the EBookView api... not in the EBook api, which seems strange. ***** ABOUT LIBGAIM I shriek everytime I read/think about that comment in blist.h (just before the declaration of struct _GaimBuddy) : "A buddy. This contains everything Gaim will ever need to know about someone on the buddy list. Everything." (sic). and that one (before the declaration of struct _GaimContact) : "A contact. This contains everything Gaim will ever need to know about a contact." and that one (before the declaration of struct _GaimGroup) : "A group. This contains everything Gaim will ever need to know about a group." Notice that the comment before struct _GaimChat, although very similar, isn't so bad in my eye :-) Notice too that although I find the way it is done inelegant, it still is very good and efficient to get the job done, and contains quite an impressive list of good ideas. (And it's more portable as ekiga, gasp!) ***** ABOUT LIBGALAGO Why, why, oh why does it contain a GalagoList api which looks so much like a GList but isn't !? Apart from that, I would say it looks nice, but is out of scope for what we want to do right now : it doesn't deal with addressbooks, but with persons as single. "Using" it would be nice at some point. ***** LAST WORDS Congratulations, comments and flames welcome, but flames will end in /dev/null. Snark From jpuydt@free.fr Thu Jun 15 04:55:35 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7B51D3B008E for ; Thu, 15 Jun 2006 04:55:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24192-02 for ; Thu, 15 Jun 2006 04:55:31 -0400 (EDT) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by menubar.gnome.org (Postfix) with ESMTP id C36A43B00CA for ; Thu, 15 Jun 2006 04:55:30 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp3-g19.free.fr (Postfix) with ESMTP id 26E1F496DD for ; Thu, 15 Jun 2006 10:54:59 +0200 (CEST) Message-ID: <4491205F.5070708@free.fr> Date: Thu, 15 Jun 2006 10:54:55 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.369 tagged_above=-999 required=2 tests=[AWL=0.230, BAYES_00=-2.599] X-Spam-Score: -2.369 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 08:55:35 -0000 Hi, in private mails (with quite big attachments since I provided some sample stupid code), Éric Bischoff found my code not that explicit concerning what I have in mind. Since I would like to keep things as opened as possible, I drop my text here :-) Let's see if I can manage to give useful ideas. ***** BIG WORDS Model - View - Controller ***** VIEWING (GENERIC) We need to be able to present a book to the user. For that, the view needs to have a list of contacts (no, a single contact definitely isn't enough!). So we need a function call to get a list of contacts. The problem is that this list will change during time (new contacts added, others removed, presence changed, status message changed, and the list goes on). So the view will need to be notified about it. Hence the idea that the book will have "contact-added" and "contact-removed" signals, and the contacts a "updated" signal. In addition to that, there is an interesting special case to handle : you have a contact in a book, and this contact shows up in a search result. When you remove the contact from the book, we want to make it disappear from the list too. Hence a "removed" signal for contacts. Now this is all nice, but what can we do if an addressbook contains millions of entries ? And if a search gives thousands of results ? In such cases, my stance is that the low level code should do something about it, since it is the one giving the problem. How can the high level code cope correctly with the situation anyway ? Only the low level code can say "Eh, I already made two hundred contacts go through the wire for that search, perhaps I should make it easy!". The question to really ask, and to which I have no satisfactory answer is: "How do me make the low level tell the high level it had to cut the list ?". ***** VIEWING (CONTACTS) The contacts should contain enough to be viewed from a generic view in the contacts window, and be shown in a search result. That won't prevent some other parts of the code to make a better use of them. For example, in the contact window we will probably be able to see a contact's title and description, but not its detailed presence, while the main window will contain a much better and more specific view for the live contacts. ***** CONTROLLING (GENERIC) Now, we want to be able to act on our objects ; say rename a book or a contact, subscribe/unsubscribe to its presence, etc. The best thing to do is to be able to get menus for each of them. Notice the plural: we will certainly to have at least menu in the menu bar and a popup menu. The first bad news about such menus is that they won't be generic : they will depend heavily on the specific type of object (no rename for avahi contacts, subscribe/unsubscribe only for XMPP contacts...). So we will certainly need some sort of shared actions that will be basic bricks for building menu (like the shared-actions.[ch] of my first round of proposals), that each implementation will mix as it sees fit. The second bad news about them is that they won't be static either. They will have to update themselves following the object they are attached to. Say your nice XMPP contact is connected with a client which has VoIP support, but now connects with a no-VoIP client, and disconnects the first : we want the "Call" menuitem to disappear to reflect this. So my proposition (no code yet) is that those menus will be obtained by subclassing of GtkMenu, register to get signals from the contact/book they are attached to, and use that to keep themselves up to date. ***** CONTROLLING (CONTACTS) Let's try to be more specific: in avahi-contact-menu.h, we would have: GtkWidget *avahi_contact_menu_new (AvahiContact *contact); and in gm-contact.h: GtkWidget *gm_contact_get_menu_new (GmContact *contact); This later function would be different in each implementation, which allows for example the avahi_contact_get_menu_new implementation to call avahi_contact_menu_new. The high level code called a generic function, but got access to a very specific implementation, which knows the full api of the specific contact, and hence will provide the best service. ***** CONTROLLING (BOOKS) Perhaps the menu shouldn't be attached to the book himself, but to its view. That would allow to place things such as "Show offline contacts" in it. Mostly the idea would be to have controllers for both the model-as-model and its view-as-model. ***** ABOUT EVOLUTION-DATA-SERVER The evolution-data-server api looks pretty good -- except that it seems to mainly handle static vcard-based contacts, where I would like to be able to handle things like. For example, we find a nice contacts-changed signal, but in the EBookView api... not in the EBook api, which seems strange. ***** ABOUT LIBGAIM I shriek everytime I read/think about that comment in blist.h (just before the declaration of struct _GaimBuddy) : "A buddy. This contains everything Gaim will ever need to know about someone on the buddy list. Everything." (sic). and that one (before the declaration of struct _GaimContact) : "A contact. This contains everything Gaim will ever need to know about a contact." and that one (before the declaration of struct _GaimGroup) : "A group. This contains everything Gaim will ever need to know about a group." Notice that the comment before struct _GaimChat, although very similar, isn't so bad in my eye :-) Notice too that although I find the way it is done inelegant, it still is very good and efficient to get the job done, and contains quite an impressive list of good ideas. (And it's more portable as ekiga, gasp!) ***** ABOUT LIBGALAGO Why, why, oh why does it contain a GalagoList api which looks so much like a GList but isn't !? Apart from that, I would say it looks nice, but is out of scope for what we want to do right now : it doesn't deal with addressbooks, but with persons as single. "Using" it would be nice at some point. ***** LAST WORDS Congratulations, comments and flames welcome, but flames will end in /dev/null. Snark PS: this message is already two or three days old... but got stuck. From ebischoff@nerim.net Thu Jun 15 07:18:00 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 98B4A3B032E for ; Thu, 15 Jun 2006 07:18:00 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01896-02 for ; Thu, 15 Jun 2006 07:17:57 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id 2C6AF3B0488 for ; Thu, 15 Jun 2006 07:17:56 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 3CBA240F45 for ; Thu, 15 Jun 2006 13:17:52 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Thu, 15 Jun 2006 13:18:05 +0200 User-Agent: KMail/1.8.2 References: <4491205F.5070708@free.fr> In-Reply-To: <4491205F.5070708@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606151318.05338.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.578 tagged_above=-999 required=2 tests=[AWL=0.021, BAYES_00=-2.599] X-Spam-Score: -2.578 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 11:18:01 -0000 Hi Julien, and thanks for this nice document. That looks like a good basis for thinkin= g=20 aloud :-). Le Jeudi 15 Juin 2006 10:54, Julien PUYDT a =C3=A9crit=C2=A0: > ***** BIG WORDS > > Model - View - Controller Excellent basis. > ***** VIEWING (GENERIC) > > We need to be able to present a book to the user. For that, the view > needs to have a list of contacts (no, a single contact definitely isn't > enough!). So we need a function call to get a list of contacts. In this paragraph I will assume that you mean "the view needs a list of all= =20 contacts from the address book driver". If it is not what you mean, please= =20 ignore this paragraph... The view needs to display, say, 10 contects at a time. No need to keep a li= st=20 of all contacts in memory. All we "need" is a function that gets _one_ contact from the driver. The vi= ew=20 can then use this information to keep the list of the 10 contacts that it=20 currently displays. > The problem is that this list will change during time (new contacts > added, others removed, presence changed, status message changed, and the > list goes on). So the view will need to be notified about it. Hence the > idea that the book will have "contact-added" and "contact-removed" > signals, and the contacts a "updated" signal. > In addition to that, there is an interesting special case to handle : > you have a contact in a book, and this contact shows up in a search > result. When you remove the contact from the book, we want to make it > disappear from the list too. Hence a "removed" signal for contacts. While this sounds cool, I am not sure that this will be possible in some=20 circumstances. The underlying address book (evolution, KDE address book, LD= AP=20 server, Zeroconf, ...) might not have the mechanisms to send such a signal. I can imagine situations where some users on machine A update a LDAP server= on=20 machine B while Ekiga runs on machine C, with the network connection betwee= n=20 B and C being temporarily broken. Will an update message come up to the=20 driver, and if yes when and how? Please notice that I do not know LDAP well and that such mechanisms might=20 exist. Should that be the case, please ignore these paragraphs. What do I propose instead? To be less ambitious, and have an address book t= hat=20 only pulls the data from the data source. If the user does not press=20 "refresh", then he/she might have outdated information. If he/she presses=20 "refresh", then the addresses are fetched again from the source. > Now this is all nice, but what can we do if an addressbook contains > millions of entries ? And if a search gives thousands of results ? In > such cases, my stance is that the low level code should do something > about it, since it is the one giving the problem. I do not like that repartition of tasks. Let me take an example. When you write an operating system, you write: =2D disk drivers (the low level code that does physical read and write from and to the hard disk) =2D a filesystem (the high level code that gathers individual sectors into files, handles a cache, etc) The low level code should not be bothered with handling the disk cache. Oka= y,=20 the problem comes from the disk driver, because it does slow access to the= =20 medium. That does not mean that it's not another component, the filesystem,= =20 that can solve it. Why this repartition of tasks? Because the performance problem is a problem= =20 that can be shared by many disk drivers. Therefore, the solution can be put= =20 in common in the high level code. > How can the high level > code cope correctly with the situation anyway ? Only the low level code > can say "Eh, I already made two hundred contacts go through the wire for > that search, perhaps I should make it easy!". Why transfer 200 contacts when the view knows that it needs only 10? > The question to really ask, and to which I have no satisfactory answer > is: "How do me make the low level tell the high level it had to cut the > list ?". The views know that contacts 301 to 309 are displayed. It's the view that=20 knows where to cut. In fact, there's nothing to cut, since all the view doe= s=20 is ask the driver for the contects it needs. > ***** VIEWING (CONTACTS) > > The contacts should contain enough to be viewed from a generic view in > the contacts window, and be shown in a search result. That won't prevent > some other parts of the code to make a better use of them. > > For example, in the contact window we will probably be able to see a > contact's title and description, but not its detailed presence, while > the main window will contain a much better and more specific view for > the live contacts. You say that the "contact" class must have _enough_ information to be used= =20 both in situation A and in sitation B. It would be better to have _different_ "contact" classes for situations "A"= =20 and "B". The list of contacts could just manage a name, a company and a phone number= =2E=20 The search result could handle much more detailed information. In other words, there's no need to put all the model's data into the views'= =20 data. Each view can handle the data it needs. > ***** CONTROLLING (GENERIC) > > Now, we want to be able to act on our objects ; say rename a book or a > contact, subscribe/unsubscribe to its presence, etc. > > The best thing to do is to be able to get menus for each of them. Notice > the plural: we will certainly to have at least menu in the menu bar and > a popup menu. > > The first bad news about such menus is that they won't be generic : they > will depend heavily on the specific type of object (no rename for avahi > contacts, subscribe/unsubscribe only for XMPP contacts...). So we will > certainly need some sort of shared actions that will be basic bricks for > building menu (like the shared-actions.[ch] of my first round of > proposals), that each implementation will mix as it sees fit. I assume here that an 'implementation" is one of the address book drivers, = and=20 that you mean that the drivers will be in charge of building menus. If thos= e=20 assumptions are wrong, the paragraph below does not apply, please just igno= re=20 it. Just the same as a hard disk driver does not display menus to the user, I=20 think that the address book drivers in Ekiga should not be responsible for= =20 user interaction. The high level code should be responsible for that. Of course the contents = of=20 the various menus depends on the address book capabilities. That's why the= =20 API between the driver and the high level code should include "query=20 capabilities functions:" class addressBook { virtual bool isReadOnly() =3D 0; virtual bool canSubscribeContacts() =3D 0; ... }; > The second bad news about them is that they won't be static either. They > will have to update themselves following the object they are attached > to. Say your nice XMPP contact is connected with a client which has VoIP > support, but now connects with a no-VoIP client, and disconnects the > first : we want the "Call" menuitem to disappear to reflect this. > > So my proposition (no code yet) is that those menus will be obtained by > subclassing of GtkMenu, register to get signals from the contact/book > they are attached to, and use that to keep themselves up to date. In your example, a signal is not needed. Knowing that there is no VoIP number in the current contact is enough. > ***** CONTROLLING (CONTACTS) > > Let's try to be more specific: > in avahi-contact-menu.h, we would have: > GtkWidget *avahi_contact_menu_new (AvahiContact *contact); > and in gm-contact.h: > GtkWidget *gm_contact_get_menu_new (GmContact *contact); > > This later function would be different in each implementation, which > allows for example the avahi_contact_get_menu_new implementation to call > avahi_contact_menu_new. The high level code called a generic function, > but got access to a very specific implementation, which knows the full > api of the specific contact, and hence will provide the best service. Again, this logic should be in the high-level code and needs not be=20 avahi-specific. What exactly should be presented to the user could be=20 determined from querying the address book for its capabilities. > ***** CONTROLLING (BOOKS) > > Perhaps the menu shouldn't be attached to the book himself, but to its > view. That would allow to place things such as "Show offline contacts" > in it. Mostly the idea would be to have controllers for both the > model-as-model and its view-as-model. Agree. > ***** ABOUT EVOLUTION-DATA-SERVER > > The evolution-data-server api looks pretty good -- except that it seems > to mainly handle static vcard-based contacts, where I would like to be > able to handle things like. > > For example, we find a nice contacts-changed signal, but in the > EBookView api... not in the EBook api, which seems strange. > > ***** ABOUT LIBGAIM > > I shriek everytime I read/think about that comment in blist.h (just > before the declaration of struct _GaimBuddy) : > "A buddy. This contains everything Gaim will ever need to know about > someone on the buddy list. Everything." (sic). > and that one (before the declaration of struct _GaimContact) : > "A contact. This contains everything Gaim will ever need to know about > a contact." > and that one (before the declaration of struct _GaimGroup) : > "A group. This contains everything Gaim will ever need to know about a > group." > > Notice that the comment before struct _GaimChat, although very similar, > isn't so bad in my eye :-) > > Notice too that although I find the way it is done inelegant, it still > is very good and efficient to get the job done, and contains quite an > impressive list of good ideas. (And it's more portable as ekiga, gasp!) > > ***** ABOUT LIBGALAGO > > Why, why, oh why does it contain a GalagoList api which looks so much > like a GList but isn't !? > > Apart from that, I would say it looks nice, but is out of scope for what > we want to do right now : it doesn't deal with addressbooks, but with > persons as single. > > "Using" it would be nice at some point. > > ***** LAST WORDS > > Congratulations, comments and flames welcome, but flames will end in > /dev/null. It definitly deserves congratulations. You forgot to mention one of your ni= ce=20 ideas, that it that it should be possible to search in several address book= s=20 at a time. =46or the comments, please note that my comments are based on a lot of=20 assumptions and guesses. In particular, I assume that you have in mind a=20 different assignment of tasks of the various software layers than the one=20 that I would like to see. If those assumptions reveal wrong, then of course= =20 my comments do not make much sense. If I did not misinterpret your thoughts, you have a very lazy view of the=20 high-level code. It's software that sits down and waits for signals to act.= =20 Somehow, the high level code provides "services" to the drivers. The driver= s=20 are the ones who understand what's going on. I have the opposite view: the address book drivers are simple and stupid.=20 Their main task is to go and fetch the requested contacts. The high level=20 code has an active attitude: it queries the drivers for contacts, it querie= s=20 the drivers capabilities, it displays the contact windows, it handles the=20 menues... The high level code has the real intelligence. I hope that helps, =2D-=20 Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m=C3=A9dire." (Le concombre masqu=C3=A9, Mandriva) From kk@verfaction.de Thu Jun 15 10:03:55 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C686B3B0336 for ; Thu, 15 Jun 2006 10:03:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15471-01 for ; Thu, 15 Jun 2006 10:03:54 -0400 (EDT) Received: from mx.verfaction.de (mx.verfaction.de [212.9.177.23]) by menubar.gnome.org (Postfix) with ESMTP id 779793B00CE for ; Thu, 15 Jun 2006 10:03:54 -0400 (EDT) Received: from erebos.verfaction.de ([2001:14b0:201:7357::1] helo=homemx.verfaction.de ident=Debian-exim) by mx.verfaction.de with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FqsRp-0003kA-3Z for gnomemeeting-devel-list@gnome.org; Thu, 15 Jun 2006 16:03:52 +0200 Received: from ganymede.kk.de ([192.168.7.10]) by homemx.verfaction.de with esmtp (Exim 4.50) id 1FqsRk-0000ld-Dw for gnomemeeting-devel-list@gnome.org; Thu, 15 Jun 2006 16:03:48 +0200 From: Kilian Krause To: GnomeMeeting development mailing list In-Reply-To: <200606081002.37875.conrad_videokonferenz@gmx.de> References: <200606081002.37875.conrad_videokonferenz@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aitPD1cXT483JdjYdYcu" Date: Thu, 15 Jun 2006 16:03:43 +0200 Message-Id: <1150380224.6599.22.camel@ganymede.verfaction.de> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-SA-Exim-Connect-IP: 2001:14b0:201:7357::1 X-SA-Exim-Mail-From: kk@verfaction.de X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.589 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Score: -2.589 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 14:03:56 -0000 --=-aitPD1cXT483JdjYdYcu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hey Conrad, Am Donnerstag, den 08.06.2006, 10:02 +0000 schrieb Conrad Beckert: > has anybody an idea where the Debian packages for Ekiga 2.0.2 (or the=20 > corresponding CVS versions) are? on their way. > The last version I can install using apt-get a couple of days old (May 25= - or=20 > somethin) - at least this is a version with the nonfunctional German loc= ale.=20 > (defaults to English) >=20 > What's up? /me is having a sheer lack of time and thus it took me a while to get everything polished and fixed just like i love to have it. =3D) Everything should be back to normal as of tonight (eventually sarge cvs snaps and win32 will remain for the weekend - we'll see) --=20 Best regards, Kilian --=-aitPD1cXT483JdjYdYcu Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEkWi/vdkzt4X+wX8RAnZ/AJoCW2qvo1l8kFsAJzogWEPKv73LUACZAZk6 n6VWZ1JiCCXnGNsq5yEsLwU= =VwN+ -----END PGP SIGNATURE----- --=-aitPD1cXT483JdjYdYcu-- From jpuydt@free.fr Thu Jun 15 11:41:17 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D25F23B0616 for ; Thu, 15 Jun 2006 11:41:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20025-08 for ; Thu, 15 Jun 2006 11:41:15 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by menubar.gnome.org (Postfix) with ESMTP id 8BF5B3B041B for ; Thu, 15 Jun 2006 11:41:14 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp6-g19.free.fr (Postfix) with ESMTP id 3FD8B227D9 for ; Thu, 15 Jun 2006 17:40:32 +0200 (CEST) Message-ID: <44917F71.10408@free.fr> Date: Thu, 15 Jun 2006 17:40:33 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> In-Reply-To: <200606151318.05338.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.337 tagged_above=-999 required=2 tests=[AWL=0.185, BAYES_00=-2.599, TW_AV=0.077] X-Spam-Score: -2.337 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:41:18 -0000 Éric Bischoff a écrit : >> ***** VIEWING (GENERIC) >> >> We need to be able to present a book to the user. For that, the view >> needs to have a list of contacts (no, a single contact definitely isn't >> enough!). So we need a function call to get a list of contacts. > > In this paragraph I will assume that you mean "the view needs a list of all > contacts from the address book driver". If it is not what you mean, please > ignore this paragraph... Well, all contacts may be asking too much. I expect drivers to keep things sane. > The view needs to display, say, 10 contects at a time. No need to keep a list > of all contacts in memory. > > All we "need" is a function that gets _one_ contact from the driver. The view > can then use this information to keep the list of the 10 contacts that it > currently displays. Blah. If you're gonna loop on a list of contacts anyway, then get the list at once. Saying "I get only the 10 I need" is nice, but how do you tell the driver which they are ? Especially a roster XMPP generally comes as a single roster push you ask for when connecting, then little update pushes. >> The problem is that this list will change during time (new contacts >> added, others removed, presence changed, status message changed, and the >> list goes on). So the view will need to be notified about it. Hence the >> idea that the book will have "contact-added" and "contact-removed" >> signals, and the contacts a "updated" signal. >> In addition to that, there is an interesting special case to handle : >> you have a contact in a book, and this contact shows up in a search >> result. When you remove the contact from the book, we want to make it >> disappear from the list too. Hence a "removed" signal for contacts. > > While this sounds cool, I am not sure that this will be possible in some > circumstances. The underlying address book (evolution, KDE address book, LDAP > server, Zeroconf, ...) might not have the mechanisms to send such a signal. No problem : then they don't. Let's take the avahi book. It will probably update the list of users regularly (and have some action to update *now*). How will it work ? Well, it will populate a cache with those contacts, and on updating, flush it ("contact-removed" emitted on all of them), then repopulate it ("contact-added"). > I can imagine situations where some users on machine A update a LDAP server on > machine B while Ekiga runs on machine C, with the network connection between > B and C being temporarily broken. Will an update message come up to the > driver, and if yes when and how? If the backend doesn't give incremental changes, that still fits in my design. > What do I propose instead? To be less ambitious, and have an address book that > only pulls the data from the data source. If the user does not press > "refresh", then he/she might have outdated information. If he/she presses > "refresh", then the addresses are fetched again from the source. Bad. If the backend gives incremental changes, you don't handle it. Such a design works only for the most simple backends. >> Now this is all nice, but what can we do if an addressbook contains >> millions of entries ? And if a search gives thousands of results ? In >> such cases, my stance is that the low level code should do something >> about it, since it is the one giving the problem. > > I do not like that repartition of tasks. > > Let me take an example. When you write an operating system, you write: > - disk drivers > (the low level code that does physical read and write from and to > the hard disk) > - a filesystem > (the high level code that gathers individual sectors into files, > handles a cache, etc) > > The low level code should not be bothered with handling the disk cache. Okay, > the problem comes from the disk driver, because it does slow access to the > medium. That does not mean that it's not another component, the filesystem, > that can solve it. > > Why this repartition of tasks? Because the performance problem is a problem > that can be shared by many disk drivers. Therefore, the solution can be put > in common in the high level code. Your file manager doesn't handle the filesystems itself : they all present the same interface, and take care of caching themselves. I want the addressbook manager to be *high* level. If some caching is needed between the addressbook manager and the backend, I want the driver to take care of it. In fact, I implemented a SearchBook to take care of presenting all search results (whatever the book), and it's certainly desirable to provide a CachedBook, which will avoid code duplication. >> How can the high level >> code cope correctly with the situation anyway ? Only the low level code >> can say "Eh, I already made two hundred contacts go through the wire for >> that search, perhaps I should make it easy!". > > Why transfer 200 contacts when the view knows that it needs only 10? The view may show only ten at the same time on the screen, but the mouse wheel makes it so easy to go through all of the 200, that it wouldn't be wise to have them ready. If there are several thousands, that's more annoying. >> The question to really ask, and to which I have no satisfactory answer >> is: "How do me make the low level tell the high level it had to cut the >> list ?". > > The views know that contacts 301 to 309 are displayed. It's the view that > knows where to cut. In fact, there's nothing to cut, since all the view does > is ask the driver for the contects it needs. How do you number the contacts in a sane way? >> ***** VIEWING (CONTACTS) >> >> The contacts should contain enough to be viewed from a generic view in >> the contacts window, and be shown in a search result. That won't prevent >> some other parts of the code to make a better use of them. >> >> For example, in the contact window we will probably be able to see a >> contact's title and description, but not its detailed presence, while >> the main window will contain a much better and more specific view for >> the live contacts. > > You say that the "contact" class must have _enough_ information to be used > both in situation A and in sitation B. > > It would be better to have _different_ "contact" classes for situations "A" > and "B". Of course there will be. I was discussing the base class. > The list of contacts could just manage a name, a company and a phone number. I would put the following : 1) a title (generally the name) 2) a description (for example a location, a status message, etc) 3) an icon > The search result could handle much more detailed information. Of course it cannot. Your search result is a book which needs to be able to show avahi contacts, sip contacts, call history contacts, etc... so it can only show the contacts as generic. > In other words, there's no need to put all the model's data into the views' > data. Each view can handle the data it needs. The view which is specific to an addressbook, of course can show the data from the specific contact associated to it. But the generic view can only show generic information. >> ***** CONTROLLING (GENERIC) >> >> Now, we want to be able to act on our objects ; say rename a book or a >> contact, subscribe/unsubscribe to its presence, etc. >> >> The best thing to do is to be able to get menus for each of them. Notice >> the plural: we will certainly to have at least menu in the menu bar and >> a popup menu. >> >> The first bad news about such menus is that they won't be generic : they >> will depend heavily on the specific type of object (no rename for avahi >> contacts, subscribe/unsubscribe only for XMPP contacts...). So we will >> certainly need some sort of shared actions that will be basic bricks for >> building menu (like the shared-actions.[ch] of my first round of >> proposals), that each implementation will mix as it sees fit. > > I assume here that an 'implementation" is one of the address book drivers, and > that you mean that the drivers will be in charge of building menus. If those > assumptions are wrong, the paragraph below does not apply, please just ignore > it. Yes, that's precisely that. > Just the same as a hard disk driver does not display menus to the user, I > think that the address book drivers in Ekiga should not be responsible for > user interaction The menu is supposed to contain actions which are specific to the given contact, book or view. Hence it must be created by code which is specific to that contact, book or view. It cannot be done by the generic code. > The high level code should be responsible for that. Of course the contents of > the various menus depends on the address book capabilities. That's why the > API between the driver and the high level code should include "query > capabilities functions:" > > class addressBook > { > virtual bool isReadOnly() = 0; > virtual bool canSubscribeContacts() = 0; > ... > }; No, that is wrong and I already explained why. Putting everything in the base class is bad. >> The second bad news about them is that they won't be static either. They >> will have to update themselves following the object they are attached >> to. Say your nice XMPP contact is connected with a client which has VoIP >> support, but now connects with a no-VoIP client, and disconnects the >> first : we want the "Call" menuitem to disappear to reflect this. >> >> So my proposition (no code yet) is that those menus will be obtained by >> subclassing of GtkMenu, register to get signals from the contact/book >> they are attached to, and use that to keep themselves up to date. > > In your example, a signal is not needed. > > Knowing that there is no VoIP number in the current contact is enough. That is wrong. The same contact could update itself and gain it. Or update itself and lose it. >> ***** CONTROLLING (CONTACTS) >> >> Let's try to be more specific: >> in avahi-contact-menu.h, we would have: >> GtkWidget *avahi_contact_menu_new (AvahiContact *contact); >> and in gm-contact.h: >> GtkWidget *gm_contact_get_menu_new (GmContact *contact); >> >> This later function would be different in each implementation, which >> allows for example the avahi_contact_get_menu_new implementation to call >> avahi_contact_menu_new. The high level code called a generic function, >> but got access to a very specific implementation, which knows the full >> api of the specific contact, and hence will provide the best service. > > Again, this logic should be in the high-level code and needs not be > avahi-specific. What exactly should be presented to the user could be > determined from querying the address book for its capabilities. Which means : 1) *all* of the addressbooks would by default have *all* the possible apis for such capability by default, with a isAbleToDoFoo function for each Foo capability ; 2) if an addressbook needs a new capability, we'll have to modify the base addressbook to add it in for it ; it won't just be a matter for the new code to add only what is necessary for itself in its own files. >> ***** CONTROLLING (BOOKS) >> >> Perhaps the menu shouldn't be attached to the book himself, but to its >> view. That would allow to place things such as "Show offline contacts" >> in it. Mostly the idea would be to have controllers for both the >> model-as-model and its view-as-model. > > Agree. Nice. >> Congratulations, comments and flames welcome, but flames will end in >> /dev/null. > > It definitly deserves congratulations. You forgot to mention one of your nice > ideas, that it that it should be possible to search in several address books > at a time. Well, that is the main side-effect of having a base class for contacts. > For the comments, please note that my comments are based on a lot of > assumptions and guesses. In particular, I assume that you have in mind a > different assignment of tasks of the various software layers than the one > that I would like to see. If those assumptions reveal wrong, then of course > my comments do not make much sense. I think you are focused on an addressbook as something both very big and very static, which explains many of our divergences. > If I did not misinterpret your thoughts, you have a very lazy view of the > high-level code. It's software that sits down and waits for signals to act. > Somehow, the high level code provides "services" to the drivers. The drivers > are the ones who understand what's going on. Yes, that's it. The high-level code doesn't know what an AvahiContact or EDSContact is ; it only knows avbout GmContact. That means it cannot do fancy things with them, and has to call functions on them to do anything interesting. > I have the opposite view: the address book drivers are simple and stupid. > Their main task is to go and fetch the requested contacts. The high level > code has an active attitude: it queries the drivers for contacts, it queries > the drivers capabilities, it displays the contact windows, it handles the > menues... The high level code has the real intelligence. Your high level code is very complex, and has to be modified heavily anytime we add a new type of addressbook with new capabilities. Anytime you want to do something, you should ask yourself the question: "Who knows how to do it?". You want to send a message to a contact ? Who knows if it's even possible, and how to do it ? The contact itself! Hence this should be handled by the contact. Of course, as-is that would mean a lot of code duplication. That's where we can use a toolbox ; of which you had an example in the first round of sample code I sent in private. To make it explicit for the -devel- readers, this sample code had a function: void shared_action_rename (GObject *obj); so any object which could be renamed, had only to: - have a "name" property ; - provide an action which trigerred that function on itself. the function handled showing a nice dialog to rename the function. The idea is that of course quite a few objects will have common capabilities ; but instead of putting them all in the high level code and clutter it with functions and conditional, I want to provide the bricks which the low-level code will use to build a specific and well-fit system. Snark From ebischoff@nerim.net Thu Jun 15 14:27:54 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1F1163B04C0 for ; Thu, 15 Jun 2006 14:27:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27103-03 for ; Thu, 15 Jun 2006 14:27:51 -0400 (EDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by menubar.gnome.org (Postfix) with ESMTP id E36E93B0412 for ; Thu, 15 Jun 2006 14:27:50 -0400 (EDT) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 25E1340F90 for ; Thu, 15 Jun 2006 20:26:36 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Thu, 15 Jun 2006 20:26:49 +0200 User-Agent: KMail/1.8.2 References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> <44917F71.10408@free.fr> In-Reply-To: <44917F71.10408@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606152026.49639.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.533 tagged_above=-999 required=2 tests=[AWL=-0.011, BAYES_00=-2.599, SUBJECT_EXCESS_QP=0, TW_AV=0.077] X-Spam-Score: -2.533 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] =?utf-8?q?Ideas_and_considerations_for_?= =?utf-8?q?the=09addressbook_code?= X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 18:27:54 -0000 Le Jeudi 15 Juin 2006 17:40, Julien PUYDT a =C3=A9crit=C2=A0: > Saying "I get only the 10 I need" is nice, but how do you tell the > driver which they are ? There are several ways to acheive that. It could be contact numbers. Or it= =20 could be some data kept internally inside the driver. It could be a void *.= =20 Etc. > > While this sounds cool, I am not sure that this will be possible in some > > circumstances. The underlying address book (evolution, KDE address book, > > LDAP server, Zeroconf, ...) might not have the mechanisms to send such a > > signal. > > No problem : then they don't. OK. So that should not be a requirement, and certainly not a mechanism at t= he=20 core of the system. Just a nice plus. > > Why transfer 200 contacts when the view knows that it needs only 10? > > The view may show only ten at the same time on the screen, but the mouse > wheel makes it so easy to go through all of the 200, that it wouldn't be > wise to have them ready. Yes. You could have a few spare contacts before and after the user's view.= =20 This algorithm is rather common. > If there are several thousands, that's more annoying. Okay. Let's simulate your algorithm, or what I have understood of it. The user views a search selection of contacts named "Tom". His/her window=20 should contain contacts Tom Smith (#1032), Tom Jones (#2050) and Tom Doe=20 (#3172). The high level software asks the driver "get me all contacts". Aft= er=20 a relatively long time, the driver is wise and stops at contact 200. It=20 returns a list with contacts 1, 2, 3, etc, up to 200. The high level softwa= re=20 searches for Tom's in the list and finds none, since the Tom's have numbers= =20 1032, 2050 and 3172. The returned list is useless, and the window remains=20 blank. I know that it cannot be _that_ bad and that I certainly misunderstood=20 something. But what? > > The views know that contacts 301 to 309 are displayed. It's the view th= at > > knows where to cut. In fact, there's nothing to cut, since all the view > > does is ask the driver for the contects it needs. > > How do you number the contacts in a sane way? These numbers are here for the demonstration. I agree that numbers probably= =20 are not so well adapted to real address books. You could use "markers". I think that all address books use contact UIDs. A= =20 given UID could be used to mark the place where the address book stopped=20 "last time". =46or most usage you do not even need anything. Most operation is sequentia= l.=20 Take for example searching. Usually you browse all records and only keep in= =20 the result list the ones that match. > I would put the following : > 1) a title (generally the name) > 2) a description (for example a location, a status message, etc) > 3) an icon Yes, we are discussing principles. Details can be arranged later. > > The search result could handle much more detailed information. > > Of course it cannot. Your search result is a book which needs to be able > to show avahi contacts, sip contacts, call history contacts, etc... so > it can only show the contacts as generic. Why would you be unable to display detailed information about objects which= =20 you only know as generic? while (genericContact =3D nextContact()) { if (genericContact->book()->canSubscribeContacts()) proposeSubscription(genericContact); ... } > The view which is specific to an addressbook, of course can show the > data from the specific contact associated to it. But the generic view > can only show generic information. Wrong ;-). Not shown in the code sample above, but that's also the whole point of virt= ual=20 methods. > The menu is supposed to contain actions which are specific to the given > contact, book or view. Hence it must be created by code which is > specific to that contact, book or view. It cannot be done by the generic > code. ;-) > > class addressBook > > { > > virtual bool isReadOnly() =3D 0; > > virtual bool canSubscribeContacts() =3D 0; > > ... > > }; > > No, that is wrong and I already explained why. Putting everything in the > base class is bad. Do you realize that the above is not an implementation? It's just an API=20 definition. Those are pure virtual methods. Everything is implemented in th= e=20 derived subclasses. Such style of coding is very classical, good, C++ (or java). > > In your example, a signal is not needed. > > > > Knowing that there is no VoIP number in the current contact is enough. > > That is wrong. The same contact could update itself and gain it. Or > update itself and lose it. I should have added "at a given time". > Which means : > 1) *all* of the addressbooks would by default have *all* the possible > apis for such capability by default, with a isAbleToDoFoo function for > each Foo capability ; No. Defining pure virtual functions in the base class does not mean that yo= u=20 implement a function in the derived class. If it can't do something, and le= ts=20 the engine know it, then it can't ;-). > 2) if an addressbook needs a new capability, we'll have to modify the > base addressbook to add it in for it ; it won't just be a matter for the > new code to add only what is necessary for itself in its own files. Wrong again, C++ comes with programming techniques that permit to locate th= e=20 real implementations in the derived classes. > > It definitly deserves congratulations. You forgot to mention one of your > > nice ideas, that it that it should be possible to search in several > > address books at a time. > > Well, that is the main side-effect of having a base class for contacts. ;-) > I think you are focused on an addressbook as something both very big and > very static, which explains many of our divergences. I think that we are both wrong here ;-). An address book could be big (whic= h=20 you underestimated), and it could be moving (which I underestimated). > Yes, that's it. The high-level code doesn't know what an AvahiContact or > EDSContact is ; it only knows avbout GmContact. That means it cannot do > fancy things with them, and has to call functions on them to do anything > interesting. I have a view that is not so far away. The book just knows contacts. Virtua= l=20 methods and subclassing both the book and the contacts does the rest. > Your high level code is very complex, and has to be modified heavily > anytime we add a new type of addressbook with new capabilities. Yes, but much more generic. And if the same capability exists in a second address book, the code is=20 already written. > Of course, as-is that would mean a lot of code duplication. That's where > we can use a toolbox ; of which you had an example in the first round of > sample code I sent in private. Ah, you too you can see the duplication problem with your method ;-). A tool box... Sounds like a C library ;-). I think that we basically foresee the same problems, but you want to do the= m=20 in the procedural, C way, and I would like them to be done in the=20 object-oriented, C++ way. > To make it explicit for the -devel- readers, this sample code had a > function: > void shared_action_rename (GObject *obj); > so any object which could be renamed, had only to: > - have a "name" property ; > - provide an action which trigerred that function on itself. > the function handled showing a nice dialog to rename the function. Yup. You see functions where I see methods ;-). > The idea is that of course quite a few objects will have common > capabilities ; but instead of putting them all in the high level code > and clutter it with functions and conditional, Yes, that would be the logical consequence if we were in C. We are not. We= =20 have virtual methods. > I want to provide the=20 > bricks which the low-level code will use to build a specific and > well-fit system. You will end up with an engine doing about nothing, and all the work to be= =20 reimplemented again and again in the drivers. Plus painfully shared code in= =20 the "toolbox" to avoid almost identical code where it can be avoided. That'= s=20 typical procedural approach. =2D-=20 Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m=C3=A9dire." (Le concombre masqu=C3=A9, Mandriva) From jpuydt@free.fr Thu Jun 15 16:46:39 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 4F0A43B01FF for ; Thu, 15 Jun 2006 16:46:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32671-05 for ; Thu, 15 Jun 2006 16:46:37 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 91ADA3B00D0 for ; Thu, 15 Jun 2006 16:46:36 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp1-g19.free.fr (Postfix) with ESMTP id 743AD9A39A for ; Thu, 15 Jun 2006 22:46:01 +0200 (CEST) Message-ID: <4491C708.3060203@free.fr> Date: Thu, 15 Jun 2006 22:46:00 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <200606151318.05338.ebischoff@nerim.net> <44917F71.10408@free.fr> <200606152026.49639.ebischoff@nerim.net> In-Reply-To: <200606152026.49639.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.342 tagged_above=-999 required=2 tests=[AWL=0.180, BAYES_00=-2.599, TW_AV=0.077] X-Spam-Score: -2.342 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 20:46:39 -0000 Éric Bischoff a écrit : > Le Jeudi 15 Juin 2006 17:40, Julien PUYDT a écrit : >> Saying "I get only the 10 I need" is nice, but how do you tell the >> driver which they are ? > > There are several ways to acheive that. It could be contact numbers. Or it > could be some data kept internally inside the driver. It could be a void *. > Etc. Well, then you reduced the question: "How do I tell the driver which contacts I want?" to: "How do I tell the driver which identifiers I want?" I don't find this impressive. >>> While this sounds cool, I am not sure that this will be possible in some >>> circumstances. The underlying address book (evolution, KDE address book, >>> LDAP server, Zeroconf, ...) might not have the mechanisms to send such a >>> signal. >> No problem : then they don't. > > OK. So that should not be a requirement, and certainly not a mechanism at the > core of the system. Just a nice plus. It *must* be at the core of the system. We _do_ want to update the live data when it changes. >>> Why transfer 200 contacts when the view knows that it needs only 10? >> The view may show only ten at the same time on the screen, but the mouse >> wheel makes it so easy to go through all of the 200, that it wouldn't be >> wise to have them ready. > > Yes. You could have a few spare contacts before and after the user's view. > This algorithm is rather common. What do "before" and "after" mean ? >> If there are several thousands, that's more annoying. > > Okay. Let's simulate your algorithm, or what I have understood of it. > > The user views a search selection of contacts named "Tom". His/her window > should contain contacts Tom Smith (#1032), Tom Jones (#2050) and Tom Doe > (#3172). The high level software asks the driver "get me all contacts". After > a relatively long time, the driver is wise and stops at contact 200. It > returns a list with contacts 1, 2, 3, etc, up to 200. The high level software > searches for Tom's in the list and finds none, since the Tom's have numbers > 1032, 2050 and 3172. The returned list is useless, and the window remains > blank. > > I know that it cannot be _that_ bad and that I certainly misunderstood > something. But what? I certainly have issues with big books, and must find some satisfying way to handle them. But doing function calls to walk on a list where I could get the list and walk it myself directly, is definitely wrong. >>> The views know that contacts 301 to 309 are displayed. It's the view that >>> knows where to cut. In fact, there's nothing to cut, since all the view >>> does is ask the driver for the contects it needs. >> How do you number the contacts in a sane way? > > These numbers are here for the demonstration. I agree that numbers probably > are not so well adapted to real address books. > > You could use "markers". I think that all address books use contact UIDs. A > given UID could be used to mark the place where the address book stopped > "last time". Notice that the only place where you call the _get_contacts function is when you first populate the book. The rest of the time you don't want to know. > For most usage you do not even need anything. Most operation is sequential. > Take for example searching. Usually you browse all records and only keep in > the result list the ones that match. Most operations are sequential when the book is static. When your contacts go online/offline/whatever, that certainly is random access, and I can tell you a first/current/next approach doesn't fly in such a situation. >>> The search result could handle much more detailed information. >> Of course it cannot. Your search result is a book which needs to be able >> to show avahi contacts, sip contacts, call history contacts, etc... so >> it can only show the contacts as generic. > > Why would you be unable to display detailed information about objects which > you only know as generic? > > while (genericContact = nextContact()) > { > if (genericContact->book()->canSubscribeContacts()) > proposeSubscription(genericContact); > ... > } Yes, of course. You put everything at the high level, something which I already stressed was very very bad. Let's try an example. A text editor will just access files. It won't wonder if they are local or remote, it won't wonder about where the data really is on disk, need caching, etc. This is the job of the low-level system. The text editor doesn't have functions and tests to handle all of the various situations possible. High level is high, it doesn't take mud baths with the details, it doesn't handle them. It delegates them to the low level. >> The view which is specific to an addressbook, of course can show the >> data from the specific contact associated to it. But the generic view >> can only show generic information. > > Wrong ;-). Partially wrong. The generic view can indeed get access to some specific features (like the menus I explained). But it certainly *must* not get them by handling *all* possible situations. >>> class addressBook >>> { >>> virtual bool isReadOnly() = 0; >>> virtual bool canSubscribeContacts() = 0; >>> ... >>> }; >> No, that is wrong and I already explained why. Putting everything in the >> base class is bad. > > Do you realize that the above is not an implementation? It's just an API > definition. Those are pure virtual methods. Everything is implemented in the > derived subclasses. > > Such style of coding is very classical, good, C++ (or java). Such style of coding is not classical, is bad and evil. I see abstractions layers everywhere to hide the details of the lower level, and you want to push those details high up the stack. >>> In your example, a signal is not needed. >>> >>> Knowing that there is no VoIP number in the current contact is enough. >> That is wrong. The same contact could update itself and gain it. Or >> update itself and lose it. > > I should have added "at a given time". > >> Which means : >> 1) *all* of the addressbooks would by default have *all* the possible >> apis for such capability by default, with a isAbleToDoFoo function for >> each Foo capability ; > > No. Defining pure virtual functions in the base class does not mean that you > implement a function in the derived class. If it can't do something, and lets > the engine know it, then it can't ;-). You push all the code to the high level, and never really abstract. That is very wrong. >> 2) if an addressbook needs a new capability, we'll have to modify the >> base addressbook to add it in for it ; it won't just be a matter for the >> new code to add only what is necessary for itself in its own files. > > Wrong again, C++ comes with programming techniques that permit to locate the > real implementations in the derived classes. If I add a new addressbook type with a Foo capability, your designs says I have to modify the base class and add: bool canDoFoo (); void pleaseDoFooThisWay (...); void pleaseDoFooThisOtherWay (...); void etcFoo (...) (with all the virtual pure syntactic crap needed) My idea of right design is that if the new addressbook is the only one needing Foo, it will handle it himself (through a specific api that its view and controller will know and use). >> I think you are focused on an addressbook as something both very big and >> very static, which explains many of our divergences. > > I think that we are both wrong here ;-). An address book could be big (which > you underestimated), and it could be moving (which I underestimated). I agree I have issues seeing how to do things *properly* with a very large addressbook. >> Yes, that's it. The high-level code doesn't know what an AvahiContact or >> EDSContact is ; it only knows avbout GmContact. That means it cannot do >> fancy things with them, and has to call functions on them to do anything >> interesting. > > I have a view that is not so far away. The book just knows contacts. Virtual > methods and subclassing both the book and the contacts does the rest. > >> Your high level code is very complex, and has to be modified heavily >> anytime we add a new type of addressbook with new capabilities. > > Yes, but much more generic. It isn't much more generic. It is an awful and indigest mix of all the specific implementations. > And if the same capability exists in a second address book, the code is > already written. Not really. >> Of course, as-is that would mean a lot of code duplication. That's where >> we can use a toolbox ; of which you had an example in the first round of >> sample code I sent in private. > > Ah, you too you can see the duplication problem with your method ;-). > > A tool box... Sounds like a C library ;-). Which are very useful and allow to abstract common work at a lower layer and not take care of it ourselves way up. > I think that we basically foresee the same problems, but you want to do them > in the procedural, C way, and I would like them to be done in the > object-oriented, C++ way. Your view isn't OO, and isn't C++. >> To make it explicit for the -devel- readers, this sample code had a >> function: >> void shared_action_rename (GObject *obj); >> so any object which could be renamed, had only to: >> - have a "name" property ; >> - provide an action which trigerred that function on itself. >> the function handled showing a nice dialog to rename the function. > > Yup. You see functions where I see methods ;-). I see functions spread in maintainable files, with well-separated features and responsibility. You see functions named "methods" stuffed into the same poor base class, which has to handle everything and the rest, and where the limits between everything is blurred. Where I say function and do: gm_contact_do_foo (contact, arguments); you say method and to: contact->do_foo (arguments); which I agree is shorter, but isn't the magical solution you think it is! :-) >> The idea is that of course quite a few objects will have common >> capabilities ; but instead of putting them all in the high level code >> and clutter it with functions and conditional, > > Yes, that would be the logical consequence if we were in C. We are not. We > have virtual methods. You *do* have isReadOnly and canSubscribeContacts, which you will use to do the ifs I said where very wrong, and you will do so at the high level, which is precisely the place where details shouldn't be handled! It isn't a case of leaky abstraction, it is a case of no-abstraction! >> I want to provide the >> bricks which the low-level code will use to build a specific and >> well-fit system. > > You will end up with an engine doing about nothing, and all the work to be > reimplemented again and again in the drivers. Plus painfully shared code in > the "toolbox" to avoid almost identical code where it can be avoided. That's > typical procedural approach. I generally end up with nice layers of functions doing almost nothing, with clean api between the layer, ensuring the code will be pretty maintainable. See lib/gmconf/ for example. We have a nice api in gmconf.h, and an implementation in gmconf-glib.c, which is layered in the same file, with lowlevel functions doing some work, and higher level doing another. Not everything done at the same final level. When I wrote that code, the goal was to make gconf (the gnome configuration management system) optional, so the port to win32 would be easier. I wrote a generic api to handle things, then two implementations *hidden* behind it. Well, at least we both agree I don't handle the case of very large addressbooks very well :-/ Snark From jpuydt@free.fr Fri Jun 16 11:44:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AC28C3B0005 for ; Fri, 16 Jun 2006 11:44:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01534-04 for ; Fri, 16 Jun 2006 11:44:08 -0400 (EDT) Received: from postfix2-c.free.fr (postfix2-c.free.fr [213.228.0.80]) by menubar.gnome.org (Postfix) with ESMTP id E28BA3B0007 for ; Fri, 16 Jun 2006 11:44:07 -0400 (EDT) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by postfix2-c.free.fr (Postfix) with ESMTP id E4AFC458B6CE for ; Fri, 16 Jun 2006 16:07:32 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-24-82-64-168-166.adsl.proxad.net [82.64.168.166]) by smtp6-g19.free.fr (Postfix) with ESMTP id DF5BD2265E for ; Fri, 16 Jun 2006 17:02:28 +0200 (CEST) Message-ID: <4492B888.8060206@free.fr> Date: Fri, 16 Jun 2006 15:56:24 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> In-Reply-To: <4491205F.5070708@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.382 tagged_above=-999 required=2 tests=[AWL=0.217, BAYES_00=-2.599] X-Spam-Score: -2.382 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 15:44:10 -0000 Julien PUYDT a écrit : > ***** ABOUT EVOLUTION-DATA-SERVER > > The evolution-data-server api looks pretty good -- except that it seems > to mainly handle static vcard-based contacts, where I would like to be > able to handle things like. Hmmm... this sentence should have ended with "able to handle things like live contacts with presence (SIP and XMPP)". On the subject of big addressbook handling, I must say what evolution-data-server does is quite nice : they run a query (EQuery) on a book (EBook), which gives them a view of the result (EBookView). That means that they can easily do a partial view of an addressbook, since they control what is seen! While this organisation doesn't suffer from the problem Éric pointed out, it has still a problem : how does one just "search" ? I mean, if your api is "search a book => get a view", how does one make a search which encompasses all books? Snark PS: notice that the current addressbook code happily tries to get all contacts, whatever the size of the addressbook -- and even not asynchronously! From jpuydt@free.fr Sat Jun 17 03:08:50 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 27E423B03CB for ; Sat, 17 Jun 2006 03:08:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11317-07 for ; Sat, 17 Jun 2006 03:08:48 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 068E83B00DE for ; Sat, 17 Jun 2006 03:08:47 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-57-82-249-55-125.adsl.proxad.net [82.249.55.125]) by smtp1-g19.free.fr (Postfix) with ESMTP id CE8E69AA70 for ; Sat, 17 Jun 2006 09:07:34 +0200 (CEST) Message-ID: <4493AA32.5030602@free.fr> Date: Sat, 17 Jun 2006 09:07:30 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> In-Reply-To: <4492B888.8060206@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.586 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599] X-Spam-Score: -2.586 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 07:08:50 -0000 Julien PUYDT a écrit : > While this organisation doesn't suffer from the problem Éric pointed > out, it has still a problem : how does one just "search" ? I mean, if > your api is "search a book => get a view", how does one make a search > which encompasses all books? Ok, I think I'm on something : let's a book have a simple api, where on one side: 1) a book can return a view for itself, which means the view becomes specific, and hence can handle the case of big addressbooks ; 2) a full search function, which will return a new book, restricted to the the search ; again this book has its view, which will handle the case of big searches ; 3) a restricted search function, which will return say at most a hundred contacts matching the string ; this one allows to make a search on all the books, since we are assured we won't be drowned by the number. This organisation would allow a clean approach for the view on a single addressbook, while still having the possibility to have a working "Find a contact" button. Does that looks nicer ? Snark From ebischoff@nerim.net Sat Jun 17 05:24:05 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id ACD5F3B038B for ; Sat, 17 Jun 2006 05:24:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15888-07 for ; Sat, 17 Jun 2006 05:24:02 -0400 (EDT) Received: from kellthuzad.dmz.nerim.net (smtp-dmz-236-saturday.dmz.nerim.net [195.5.254.236]) by menubar.gnome.org (Postfix) with ESMTP id 2C81F3B0809 for ; Sat, 17 Jun 2006 05:24:01 -0400 (EDT) Received: from kraid.nerim.net (smtp-106-saturday.nerim.net [62.4.16.106]) by kellthuzad.dmz.nerim.net (Postfix) with ESMTP id 9BD1139D6B for ; Sat, 17 Jun 2006 11:23:14 +0200 (CEST) Received: from ebischoff.pck.nerim.net (ebischoff.pck.nerim.net [213.41.243.33]) by kraid.nerim.net (Postfix) with ESMTP id 5A4A940E35 for ; Sat, 17 Jun 2006 11:22:48 +0200 (CEST) From: =?utf-8?q?=C3=89ric_Bischoff?= To: gnomemeeting-devel-list@gnome.org Date: Sat, 17 Jun 2006 11:22:59 +0200 User-Agent: KMail/1.8.2 References: <4491205F.5070708@free.fr> <200606152026.49639.ebischoff@nerim.net> <4491C708.3060203@free.fr> In-Reply-To: <4491C708.3060203@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606171123.00082.ebischoff@nerim.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.51 tagged_above=-999 required=2 tests=[AWL=0.089, BAYES_00=-2.599] X-Spam-Score: -2.51 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 09:24:05 -0000 Le Jeudi 15 Juin 2006 22:46, Julien PUYDT a =C3=A9crit=C2=A0: > > OK. So that should not be a requirement, and certainly not a mechanism = at > > the core of the system. Just a nice plus. > > It *must* be at the core of the system. We _do_ want to update the live > data when it changes. Sorry, that was not clear. By "at the core" I meant "necessary for the addr= ess=20 books to work". > > Yes. You could have a few spare contacts before and after the user's > > view. This algorithm is rather common. > > What do "before" and "after" mean ? Records just before and after the ones that are displayed in sequential ord= er. > > I know that it cannot be _that_ bad and that I certainly misunderstood > > something. But what? > > I certainly have issues with big books, and must find some satisfying > way to handle them. But doing function calls to walk on a list where I > could get the list and walk it myself directly, is definitely wrong. What is wrong is to see that as a list ;-). > Most operations are sequential when the book is static. When your > contacts go online/offline/whatever, that certainly is random access, > and I can tell you a first/current/next approach doesn't fly in such a > situation. I would not say "not fly" but it certainly becomes much more acrobatic, I=20 agree. > If I add a new addressbook type with a Foo capability, your designs says > I have to modify the base class and add: > > bool canDoFoo (); > void pleaseDoFooThisWay (...); > void pleaseDoFooThisOtherWay (...); > void etcFoo (...) > (with all the virtual pure syntactic crap needed) This "crap" is a lightweight modification since it is only one function=20 declaration. No implementation. That is done in the subclasses, if necessar= y. > My idea of right design is that if the new addressbook is the only one > needing Foo, it will handle it himself (through a specific api that its > view and controller will know and use). Okay. Perharps the our differences in opinion is not that much on the=20 programming design, but more on what the software has to do. To me, an address book is just an address book, they are not that different= =20 one from the other. Ekiga need to dig through them to show names, categorie= s=20 and to pick up SIP numbers to call the people. I see a relatively homogeneo= us=20 user interface, with more or less the same appearance (if not exactly the=20 same) for the various address books. I have a "unifying" vision. To you, all address books have very strong pecularities and the software ha= s=20 to adapt a lot to each of them, to take them to the maximum of their=20 possibilities. The user will get different display, different menues, and=20 even different functionality. That explains why you want to put everything in the "drivers", while I want= to=20 put a lot of common logic in the "engine". > > I think that we are both wrong here ;-). An address book could be big > > (which you underestimated), and it could be moving (which I > > underestimated). > > I agree I have issues seeing how to do things *properly* with a very > large addressbook. Yes, and I have certainly underestimated the "dynamic" aspect :-(. > Your view isn't OO, and isn't C++. Come on ;-). > You see functions named "methods" stuffed into the same poor base class, No. Again and again, the base class only has declarations. It sees an=20 abstraction of what the address book is. In every C++ book, you can see examples like this class vehicle { virtual void accelerate(int a) =3D 0; ... }; class car : public vehicle { virtual void accelerate(int a); ... }; class plane : public vehicle { virtual void accelerate(int a); ... }; Planes and cars have very different ways to accelerate. Planes can't brake = and=20 cars can't fly, but such designs are clean and very popular. > Well, at least we both agree I don't handle the case of very large > addressbooks very well :-/ Yes, this discussion is not pointless :-). And at the end if you are more comfortable with libraries of C functions th= an=20 with subclassing and virtual functions, it's no problem. After all, it's yo= u=20 who are going to be doing the dirty work (and I think we all thank you for= =20 that!). =2D-=20 Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?" Chourave : "J'aime m=C3=A9dire." (Le concombre masqu=C3=A9, Mandriva) From jpuydt@free.fr Sat Jun 17 15:09:04 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2976B3B0144 for ; Sat, 17 Jun 2006 15:09:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04217-02 for ; Sat, 17 Jun 2006 15:08:59 -0400 (EDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by menubar.gnome.org (Postfix) with ESMTP id BC2893B019D for ; Sat, 17 Jun 2006 15:07:46 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-c.free.fr (Postfix) with ESMTP id 4C9DC1D0C42D for ; Sat, 17 Jun 2006 20:06:22 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-57-82-249-55-125.adsl.proxad.net [82.249.55.125]) by smtp5-g19.free.fr (Postfix) with ESMTP id B65BC26C83 for ; Sat, 17 Jun 2006 21:05:51 +0200 (CEST) Message-ID: <4494528F.2040804@free.fr> Date: Sat, 17 Jun 2006 21:05:51 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <200606152026.49639.ebischoff@nerim.net> <4491C708.3060203@free.fr> <200606171123.00082.ebischoff@nerim.net> In-Reply-To: <200606171123.00082.ebischoff@nerim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.584 tagged_above=-999 required=2 tests=[AWL=0.015, BAYES_00=-2.599] X-Spam-Score: -2.584 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 19:09:04 -0000 Éric Bischoff a écrit : >>> Yes. You could have a few spare contacts before and after the user's >>> view. This algorithm is rather common. >> What do "before" and "after" mean ? > > Records just before and after the ones that are displayed in sequential order. Sequential hurts. >>> I know that it cannot be _that_ bad and that I certainly misunderstood >>> something. But what? >> I certainly have issues with big books, and must find some satisfying >> way to handle them. But doing function calls to walk on a list where I >> could get the list and walk it myself directly, is definitely wrong. > > What is wrong is to see that as a list ;-). Indeed. >> If I add a new addressbook type with a Foo capability, your designs says >> I have to modify the base class and add: >> >> bool canDoFoo (); >> void pleaseDoFooThisWay (...); >> void pleaseDoFooThisOtherWay (...); >> void etcFoo (...) >> (with all the virtual pure syntactic crap needed) > > This "crap" is a lightweight modification since it is only one function > declaration. No implementation. That is done in the subclasses, if necessary. Notice that I used "crap" to describe the syntactic need in C++ to add "virtual" and "= 0" everywhere. And your "lightweight modification" still involves modifying the base class anytime a child class needs something! >> My idea of right design is that if the new addressbook is the only one >> needing Foo, it will handle it himself (through a specific api that its >> view and controller will know and use). > > Okay. Perharps the our differences in opinion is not that much on the > programming design, but more on what the software has to do. > > To me, an address book is just an address book, they are not that different > one from the other. Ekiga need to dig through them to show names, categories > and to pick up SIP numbers to call the people. I see a relatively homogeneous > user interface, with more or less the same appearance (if not exactly the > same) for the various address books. I have a "unifying" vision. > > To you, all address books have very strong pecularities and the software has > to adapt a lot to each of them, to take them to the maximum of their > possibilities. The user will get different display, different menues, and > even different functionality. Well, look at what we have to put already in the addressbooks: - evolution-data-server addressbooks ; - avahi contacts ; - history contacts ; - speeddials. And the future holds : - SIP contacts ; - XMPP contacts. > That explains why you want to put everything in the "drivers", while I want to > put a lot of common logic in the "engine". Your high level is what I call low level : it handles all of the details! >> Your view isn't OO, and isn't C++. > > Come on ;-). > >> You see functions named "methods" stuffed into the same poor base class, > > No. Again and again, the base class only has declarations. It sees an > abstraction of what the address book is. You're still stuffing that in the base class, which is awful. Does the QWidget class have all the methods of all its child already declared? > In every C++ book, you can see examples like this > > class vehicle { > virtual void accelerate(int a) = 0; > ... > }; > > class car : public vehicle { > virtual void accelerate(int a); > ... > }; > > class plane : public vehicle { > virtual void accelerate(int a); > ... > }; > Planes and cars have very different ways to accelerate. Planes can't brake and > cars can't fly, but such designs are clean and very popular. They all accelerate, and that is the reason why having an accelerate method is put as a requirement in the base class. Anyway I since made another proposition which I find neater ; I'm eagerly waiting for your comments on it :-) Snark From siti@orcon.net.nz Sat Jun 17 16:21:14 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 166443B02D7 for ; Sat, 17 Jun 2006 16:21:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06960-02 for ; Sat, 17 Jun 2006 16:21:11 -0400 (EDT) Received: from dbmail-mx3.orcon.co.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 420E03B0769 for ; Sat, 17 Jun 2006 16:21:10 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx3.orcon.co.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k5HKBcBi027983 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 18 Jun 2006 08:11:39 +1200 From: Stephen Cook To: GnomeMeeting development mailing list Content-Type: text/plain Date: Sun, 18 Jun 2006 08:11:38 +1200 Message-Id: <1150575098.10433.5.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx3.orcon.co.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.484 tagged_above=-999 required=2 tests=[AWL=-0.020, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.484 X-Spam-Level: Subject: [GnomeMeeting-devel-list] IAX2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 20:21:14 -0000 Hello, It's been a long time I gave you guys an update. In IAX2 in opal I have got music on hold going which is nice :). I will be doing registration next as this is probably the most important feature for users. Also I have not run in to any stability problems with IAX2. My iax2/ekiga integration is working well as a tester with my asterisk server. It basically has all the functionality there but needs more integration and bug/quirky fixes. Also some refactoring in the future would be nice depending if I get time or not... From jan.schampera@web.de Sat Jun 17 23:26:05 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 973DD3B0089 for ; Sat, 17 Jun 2006 23:26:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21686-02 for ; Sat, 17 Jun 2006 23:26:04 -0400 (EDT) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by menubar.gnome.org (Postfix) with ESMTP id 718E83B0080 for ; Sat, 17 Jun 2006 23:26:04 -0400 (EDT) Received: from fwd28.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1Frm9f-0005mL-03; Sun, 18 Jun 2006 03:32:47 +0200 Received: from mail.home.thebonsai.de (Ee3Yp-Z-ge9I5Mahsz3ULnxaW3DaPSfdXF9f7jCM5sjCj+WYBVPHwg@[84.147.75.32]) by fwd28.sul.t-online.de with esmtp id 1Frm9c-1vtsA40; Sun, 18 Jun 2006 03:32:44 +0200 Received: from home.thebonsai.de (unknown [192.168.64.3]) by mail.home.thebonsai.de (Postfix) with ESMTP id 610F16B154 for ; Sun, 18 Jun 2006 03:32:43 +0200 (CEST) Date: Sun, 18 Jun 2006 03:32:42 +0200 From: Jan Schampera To: gnomemeeting-devel-list@gnome.org Message-ID: <20060618033242.5cce3d15@localhost.localdomain> In-Reply-To: <4493AA32.5030602@free.fr> References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> <4493AA32.5030602@free.fr> Organization: private X-Mailer: Sylpheed-Claws 2.2.0 (GTK+ 2.8.18; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: Ee3Yp-Z-ge9I5Mahsz3ULnxaW3DaPSfdXF9f7jCM5sjCj+WYBVPHwg@t-dialin.net X-TOI-MSGID: d12d82d7-adb7-47a8-a0ce-a3a4ced5117e X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.982 tagged_above=-999 required=2 tests=[AWL=0.616, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -1.982 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 03:26:05 -0000 On Sat, 17 Jun 2006 09:07:30 +0200 Julien PUYDT wrote: > 1) a book can return a view for itself, which means the view becomes > specific, and hence can handle the case of big addressbooks ; And which view would such a book return by default? > 2) a full search function, which will return a new book, restricted > to the the search ; again this book has its view, which will handle > the case of big searches ; ACK > 3) a restricted search function, which will return say at most a > hundred contacts matching the string ; this one allows to make a > search on all the books, since we are assured we won't be drowned by > the number. > Does that looks nicer ? Yip. J. -- God is real... unless declared as integer. From jpuydt@free.fr Sun Jun 18 06:22:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8B7533B09FC for ; Sun, 18 Jun 2006 06:22:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18409-03 for ; Sun, 18 Jun 2006 06:22:08 -0400 (EDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by menubar.gnome.org (Postfix) with ESMTP id 03CAF3B0956 for ; Sun, 18 Jun 2006 06:22:07 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-c.free.fr (Postfix) with ESMTP id B13A21D0A67F for ; Sun, 18 Jun 2006 11:20:11 +0200 (CEST) Received: from [192.168.1.2] (lns-bzn-30-82-253-152-157.adsl.proxad.net [82.253.152.157]) by smtp5-g19.free.fr (Postfix) with ESMTP id 8697F270B8 for ; Sun, 18 Jun 2006 12:19:37 +0200 (CEST) Message-ID: <449528BF.3020104@free.fr> Date: Sun, 18 Jun 2006 12:19:43 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <4491205F.5070708@free.fr> <4492B888.8060206@free.fr> <4493AA32.5030602@free.fr> <20060618033242.5cce3d15@localhost.localdomain> In-Reply-To: <20060618033242.5cce3d15@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 10:22:10 -0000 Jan Schampera a écrit : >> 1) a book can return a view for itself, which means the view becomes >> specific, and hence can handle the case of big addressbooks ; > And which view would such a book return by default? No default view. I think there should be a GmFullBook class (from which all books which can be displayed fully), and an associated GmFullBookView class, which would then be default for the children. >> Does that looks nicer ? > Yip. Nice. I'm writing some code to showcase things... may take long since I lack time those days :-/ Snark From dsandras@seconix.com Sun Jun 18 15:32:22 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 425673B0114 for ; Sun, 18 Jun 2006 15:32:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08600-02 for ; Sun, 18 Jun 2006 15:32:19 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 178373B0009 for ; Sun, 18 Jun 2006 15:32:18 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id EF61583C26 for ; Sun, 18 Jun 2006 21:11:21 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03870-02 for ; Sun, 18 Jun 2006 21:11:15 +0200 (CEST) Received: from [192.168.0.161] (206-158.242.81.adsl.skynet.be [81.242.158.206]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 657C683C23 for ; Sun, 18 Jun 2006 21:11:15 +0200 (CEST) From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <1150575098.10433.5.camel@siti> References: <1150575098.10433.5.camel@siti> Content-Type: text/plain; charset=ISO-8859-15 Date: Sun, 18 Jun 2006 21:31:27 +0200 Message-Id: <1150659087.2477.3.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.256 tagged_above=-999 required=2 tests=[AWL=0.208, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.256 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] IAX2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 19:32:22 -0000 Le dimanche 18 juin 2006 à 08:11 +1200, Stephen Cook a écrit : > Hello, > > It's been a long time I gave you guys an update. > > In IAX2 in opal I have got music on hold going which is nice :). I will > be doing registration next as this is probably the most important > feature for users. Also I have not run in to any stability problems > with IAX2. > > My iax2/ekiga integration is working well as a tester with my asterisk > server. It basically has all the functionality there but needs more > integration and bug/quirky fixes. Also some refactoring in the future > would be nice depending if I get time or not... Hi, I've seen Derek committed some code from you. I think it is important that you keep a repository with your patches so that we really know what you have fixed/added for Google SoC. (Actually, I should see the patches, even though it is perfectly acceptable that Derek commits them). Thank you, -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From gcgagd-gnomemeeting-devel-list@m.gmane.org Sun Jun 18 16:15:08 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8DDA23B0114 for ; Sun, 18 Jun 2006 16:15:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09248-09 for ; Sun, 18 Jun 2006 16:15:07 -0400 (EDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by menubar.gnome.org (Postfix) with ESMTP id 662BD3B00B2 for ; Sun, 18 Jun 2006 16:15:07 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Fs3eO-0006gT-LO for gnomemeeting-devel-list@gnome.org; Sun, 18 Jun 2006 22:13:40 +0200 Received: from jupiter.physics.ubc.ca ([142.103.234.78]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Jun 2006 22:13:40 +0200 Received: from johan_brn by jupiter.physics.ubc.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Jun 2006 22:13:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gnomemeeting-devel-list@gnome.org From: Johan Brannlund Date: Sun, 18 Jun 2006 13:13:29 -0700 Lines: 22 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: jupiter.physics.ubc.ca User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux)) Sender: news X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.752 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_YAHOO_RCVD=1.849, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.752 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Main window size X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 20:15:08 -0000 I posted the below as a wishlist bug, but apparently the developers prefer carrying out the discussion on this mailing list. This is what I wrote: "I just tried the 20060615 cvs snapshot of ekiga, and it's getting better all the time. I have a small request though: I don't use video, which means that the main window is much bigger than it has to be. Would it be possible to add a resizing widget, or to automatically make the window smaller when video is disabled?" Damien also added the following comment: "I would also say that it will look less bigger when having a contacts list. :) " ... which I don't quite understand. At least in my snapshot, the contacts are in a separate window. Regards, Johan From siti@orcon.net.nz Sun Jun 18 21:23:06 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 415B73B0387 for ; Sun, 18 Jun 2006 21:23:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18559-06 for ; Sun, 18 Jun 2006 21:23:01 -0400 (EDT) Received: from dbmail-mx2.orcon.net.nz (loadbalancer2.orcon.net.nz [219.88.242.4]) by menubar.gnome.org (Postfix) with ESMTP id 66E1B3B0196 for ; Sun, 18 Jun 2006 21:23:01 -0400 (EDT) Received: from [192.168.1.103] (203-97-120-161.cable.telstraclear.net [203.97.120.161]) (authenticated bits=0) by dbmail-mx2.orcon.net.nz (8.13.6/8.13.6/Debian-1) with ESMTP id k5J1Lujn017301 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 19 Jun 2006 13:21:57 +1200 From: Stephen Cook To: GnomeMeeting development mailing list In-Reply-To: <1150659087.2477.3.camel@golgoth01> References: <1150575098.10433.5.camel@siti> <1150659087.2477.3.camel@golgoth01> Content-Type: text/plain; charset=utf-8 Date: Mon, 19 Jun 2006 13:21:55 +1200 Message-Id: <1150680115.31741.1.camel@siti> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on dbmail-mx2.orcon.net.nz X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.547 tagged_above=-999 required=2 tests=[AWL=0.052, BAYES_00=-2.599] X-Spam-Score: -2.547 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] IAX2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 01:23:06 -0000 On Sun, 2006-06-18 at 21:31 +0200, Damien Sandras wrote: > Le dimanche 18 juin 2006 à 08:11 +1200, Stephen Cook a écrit : > > Hello, > > > > It's been a long time I gave you guys an update. > > > > In IAX2 in opal I have got music on hold going which is nice :). I will > > be doing registration next as this is probably the most important > > feature for users. Also I have not run in to any stability problems > > with IAX2. > > > > My iax2/ekiga integration is working well as a tester with my asterisk > > server. It basically has all the functionality there but needs more > > integration and bug/quirky fixes. Also some refactoring in the future > > would be nice depending if I get time or not... > > Hi, > > > I've seen Derek committed some code from you. > > I think it is important that you keep a repository with your patches so > that we really know what you have fixed/added for Google SoC. > (Actually, I should see the patches, even though it is perfectly > acceptable that Derek commits them). I'll try and get you to review them first. I'll also put the patches on my website and give you guys a link soon. > > Thank you, From jpuydt@free.fr Mon Jun 19 01:26:43 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E9CF83B09E1 for ; Mon, 19 Jun 2006 01:26:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25898-10 for ; Mon, 19 Jun 2006 01:26:41 -0400 (EDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by menubar.gnome.org (Postfix) with ESMTP id 737143B03C7 for ; Mon, 19 Jun 2006 01:26:41 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-60-82-254-197-114.adsl.proxad.net [82.254.197.114]) by smtp1-g19.free.fr (Postfix) with ESMTP id C5B1D10170 for ; Mon, 19 Jun 2006 07:25:07 +0200 (CEST) Message-ID: <44963539.6080309@free.fr> Date: Mon, 19 Jun 2006 07:25:13 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.567 tagged_above=-999 required=2 tests=[AWL=0.032, BAYES_00=-2.599] X-Spam-Score: -2.567 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Main window size X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 05:26:43 -0000 Johan Brannlund a écrit : > I posted the below as a wishlist bug, but apparently the developers prefer > carrying out the discussion on this mailing list. This is what I wrote: Well, bug reports are nice for a beta or a stable release ; during the development cycle, discussing on the -devel- mailing-list is better (especially right at the beginning). :-) > "I just tried the 20060615 cvs snapshot of ekiga, and it's getting better > all the time. I have a small request though: I don't use video, which > means that the main window is much bigger than it has to be. > > Would it be possible to add a resizing widget, or to automatically make the > window smaller when video is disabled?" > > Damien also added the following comment: > > "I would also say that it will look less bigger when having a contacts > list. :) " > > ... which I don't quite understand. At least in my snapshot, the contacts > are in a separate window. He means that you should see some of your contacts in the main window in the future, with presence information about them. Snark From dsandras@seconix.com Mon Jun 19 04:55:21 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 539283B00A5 for ; Mon, 19 Jun 2006 04:55:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01183-02 for ; Mon, 19 Jun 2006 04:55:13 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id CCC843B0004 for ; Mon, 19 Jun 2006 04:55:11 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id D5FC083C1F for ; Mon, 19 Jun 2006 10:34:14 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32316-06 for ; Mon, 19 Jun 2006 10:34:11 +0200 (CEST) Received: from [172.17.100.222] (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id 694B183C1A for ; Mon, 19 Jun 2006 10:34:11 +0200 (CEST) From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: <44963539.6080309@free.fr> References: <44963539.6080309@free.fr> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 19 Jun 2006 10:54:04 +0200 Message-Id: <1150707244.2904.2.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Main window size X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 08:55:21 -0000 Le lundi 19 juin 2006 à 07:25 +0200, Julien PUYDT a écrit : > Johan Brannlund a écrit : > > I posted the below as a wishlist bug, but apparently the developers prefer > > carrying out the discussion on this mailing list. This is what I wrote: > > Well, bug reports are nice for a beta or a stable release ; during the > development cycle, discussing on the -devel- mailing-list is better > (especially right at the beginning). :-) > Yes, because it is a work in progress. So it will change with time, and get improved. No worries :) -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From firstone5@hotmail.com Wed Jun 21 13:09:10 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C9A9D3B02A4 for ; Wed, 21 Jun 2006 13:09:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23702-03 for ; Wed, 21 Jun 2006 13:09:09 -0400 (EDT) Received: from hotmail.com (bay101-f15.bay101.hotmail.com [64.4.56.25]) by menubar.gnome.org (Postfix) with ESMTP id C2B763B01C1 for ; Wed, 21 Jun 2006 13:09:09 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Jun 2006 10:09:08 -0700 Message-ID: Received: from 64.4.56.200 by by101fd.bay101.hotmail.msn.com with HTTP; Wed, 21 Jun 2006 17:09:07 GMT X-Originating-IP: [69.245.3.192] X-Originating-Email: [firstone5@hotmail.com] X-Sender: firstone5@hotmail.com From: "M. Renee Hopkins" To: gnomemeeting-devel-list@gnome.org Date: Wed, 21 Jun 2006 17:09:07 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 21 Jun 2006 17:09:08.0863 (UTC) FILETIME=[68BD40F0:01C69555] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=0.607 tagged_above=-999 required=2 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: 0.607 X-Spam-Level: Subject: [GnomeMeeting-devel-list] Mingw build of CVS ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:09:11 -0000 Greetings all, I am now building ekiga from cvs with the mingw tools on linux with some success, thanks to help from the list developers and patches. Most all features seem to be working. However, my builds don't detect the videoforwindows devices even though other ekiga.exe (not mine) versions correctly see the camera. Any ideas for missing switches on compile before I began greping through pwlib? I'm rather new to the code so any help is appreciated. Congrads to all developers on great work, MR From dsandras@seconix.com Wed Jun 21 13:42:37 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C742A3B05E9 for ; Wed, 21 Jun 2006 13:42:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25791-05 for ; Wed, 21 Jun 2006 13:42:36 -0400 (EDT) Received: from ns20085.ovh.net (ekiga.net [213.186.62.145]) by menubar.gnome.org (Postfix) with ESMTP id 0647C3B00B0 for ; Wed, 21 Jun 2006 13:42:35 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ns20085.ovh.net (Postfix) with ESMTP id AC0EF83C1C for ; Wed, 21 Jun 2006 19:22:12 +0200 (CEST) Received: from ns20085.ovh.net ([127.0.0.1]) by localhost (ns20085.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05950-02 for ; Wed, 21 Jun 2006 19:22:11 +0200 (CEST) Received: from [192.168.0.161] (185.1-247-81.adsl-dyn.isp.belgacom.be [81.247.1.185]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ns20085.ovh.net (Postfix) with ESMTP id C5DD783C1B for ; Wed, 21 Jun 2006 19:22:10 +0200 (CEST) From: Damien Sandras To: GnomeMeeting development mailing list In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-15 Date: Wed, 21 Jun 2006 19:43:29 +0200 Message-Id: <1150911809.2537.7.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnomemeeting.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.461 tagged_above=-999 required=2 tests=[AWL=0.003, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.461 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Mingw build of CVS ekiga X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:42:38 -0000 Le mercredi 21 juin 2006 à 17:09 +0000, M. Renee Hopkins a écrit : > Greetings all, > > I am now building ekiga from cvs with the mingw tools on linux with some > success, thanks to help from the list developers and patches. > > Most all features seem to be working. However, my builds don't detect the > videoforwindows devices even though other ekiga.exe (not mine) versions > correctly see the camera. > > Any ideas for missing switches on compile before I began greping through > pwlib? > I'm not an expert of the win32 build, but the first guess would be that the pwlib plugins are not compiled in. > I'm rather new to the code so any help is appreciated. > > Congrads to all developers on great work, > MR > > > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:dsandras@ekiga.net sip:600000@ekiga.net From tonim@telefonica.net Wed Jun 28 04:13:24 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9083D3B0079 for ; Wed, 28 Jun 2006 04:13:24 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31830-06 for ; Wed, 28 Jun 2006 04:13:23 -0400 (EDT) Received: from lothlorienng.sisman.info (157.Red-83-58-24.dynamicIP.rima-tde.net [83.58.24.157]) by menubar.gnome.org (Postfix) with ESMTP id C1F293B0002 for ; Wed, 28 Jun 2006 04:13:22 -0400 (EDT) Received: from gandalf.sisman.info (gandalf.sisman.info [192.168.16.201]) by lothlorienng.sisman.info (Postfix) with ESMTP id B33D71D8437 for ; Wed, 28 Jun 2006 08:18:54 +0200 (CEST) From: Toni Moreno To: gnomemeeting-devel-list@gnome.org In-Reply-To: <1150680115.31741.1.camel@siti> References: <1150575098.10433.5.camel@siti> <1150659087.2477.3.camel@golgoth01> <1150680115.31741.1.camel@siti> Content-Type: text/plain Date: Wed, 28 Jun 2006 08:09:46 +0200 Message-Id: <1151474986.5988.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: Yes, score=2.597 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046, SPF_NEUTRAL=1.069] X-Spam-Score: 2.597 X-Spam-Level: ** X-Spam-Flag: YES Subject: [GnomeMeeting-devel-list] A bit OFF-TOPIC, but usefull X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 08:13:24 -0000 I have found a report of skype, which shows the huge network activity it has (apart from voice network usage). Interesting to pinpoint differences between Skype & Ekiga, or other VoIP hardware phones. Enjoy, and excuse me the off-topic. http://www.ja.net/development/voip/skype&janet.pdf -- Toni Moreno From lurch@gmx.li Thu Jun 29 03:50:09 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A67023B011E for ; Thu, 29 Jun 2006 03:50:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26540-04 for ; Thu, 29 Jun 2006 03:50:02 -0400 (EDT) Received: from asclepius.uwa.edu.au (unknown [130.95.128.56]) by menubar.gnome.org (Postfix) with ESMTP id 6733A3B04C2 for ; Thu, 29 Jun 2006 03:50:01 -0400 (EDT) Received: from asclepius.kas (localhost.localdomain [127.0.0.1]) by asclepius.uwa.edu.au (Postfix) with SMTP id E6028183A6F for ; Thu, 29 Jun 2006 15:49:45 +0800 (WST) Received: from asclepius (localhost.localdomain [127.0.0.1]) by asclepius.prekas (Postfix) with SMTP id CC7321841AD for ; Thu, 29 Jun 2006 15:49:45 +0800 (WST) X-UWA-Client-IP: 130.95.28.15 (UWA) Received: from ns1.watri.uwa.edu.au (ns1.watri.org.au [130.95.28.15]) by asclepius.extinput (Postfix) with ESMTP id B3012183CC9 for ; Thu, 29 Jun 2006 15:49:45 +0800 (WST) Received: from [130.95.29.76] (gluttony.watri.org.au [130.95.29.76]) by ns1.watri.uwa.edu.au (8.13.1/8.13.1) with ESMTP id k5T7nflM013861 for ; Thu, 29 Jun 2006 15:49:44 +0800 (WST) Message-ID: <44A386D4.8040708@gmx.li> Date: Thu, 29 Jun 2006 15:52:52 +0800 From: =?ISO-8859-1?Q?Stefan_Br=FCns?= User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <200606081002.37875.conrad_videokonferenz@gmx.de> <1150380224.6599.22.camel@ganymede.verfaction.de> In-Reply-To: <1150380224.6599.22.camel@ganymede.verfaction.de> Content-Type: multipart/mixed; boundary="------------030008030501050603080306" X-SpamTest-Info: Profile: Formal (405/060628) X-SpamTest-Info: Profile: Detect Hard [UCS 290904] X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking Spam - Subject (UCS) [02-08-04] X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.358 tagged_above=-999 required=2 tests=[AWL=-0.036, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142] X-Spam-Score: -1.358 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 07:50:09 -0000 This is a multi-part message in MIME format. --------------030008030501050603080306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> The last version I can install using apt-get a couple of days old (May 25 - or >> somethin) - at least this is a version with the nonfunctional German locale. >> (defaults to English) >> >> What's up? > > > /me is having a sheer lack of time and thus it took me a while to get > everything polished and fixed just like i love to have it. =) > Everything should be back to normal as of tonight (eventually sarge cvs > snaps and win32 will remain for the weekend - we'll see) I think I have found the problem with the missing tranlations - it is caused by the recent change from the ALL_LINGUAS variable to the po/LINGUAS file. Patch attached. @Kilian: can you try the patch and submit it upstream, if successfull? Lurchi --------------030008030501050603080306 Content-Type: text/plain; name="configure_in_fix_all_linguas.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="configure_in_fix_all_linguas.diff" --- configure.in_orig 2006-06-29 07:59:40.000000000 +0200 +++ configure.in 2006-06-29 09:10:08.000000000 +0200 @@ -527,7 +527,8 @@ dnl Support for internationalization dnl ######################################################################## AC_SUBST([CONFIG_STATUS_DEPENDENCIES],['$(top_srcdir)/po/LINGUAS']) -ALL_LINGUAS="`grep -v '^#' "$srcdir/po/LINGUAS"`" +# ALL_LINGUAS="`grep -v '^#' "$srcdir/po/LINGUAS"`" +ALL_LINGUAS="`sed -ne '/\#.*/ d; H; $ {x; s/^\\n//g; s/\\n/ /g; p}' "$srcdir/po/LINGUAS"`" GETTEXT_PACKAGE=AC_PACKAGE_NAME AC_SUBST(GETTEXT_PACKAGE) --------------030008030501050603080306-- From jpuydt@free.fr Thu Jun 29 06:15:38 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0617C3B050F for ; Thu, 29 Jun 2006 06:15:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03057-05 for ; Thu, 29 Jun 2006 06:15:36 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 17C0C3B02CE for ; Thu, 29 Jun 2006 06:15:36 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-61-82-250-109-134.adsl.proxad.net [82.250.109.134]) by smtp5-g19.free.fr (Postfix) with ESMTP id 08B3E27766 for ; Thu, 29 Jun 2006 12:15:34 +0200 (CEST) Message-ID: <44A3A865.7000201@free.fr> Date: Thu, 29 Jun 2006 12:16:05 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <200606081002.37875.conrad_videokonferenz@gmx.de> <1150380224.6599.22.camel@ganymede.verfaction.de> <44A386D4.8040708@gmx.li> In-Reply-To: <44A386D4.8040708@gmx.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.596 tagged_above=-999 required=2 tests=[AWL=0.003, BAYES_00=-2.599] X-Spam-Score: -2.596 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 10:15:38 -0000 Stefan Brüns a écrit : > @Kilian: can you try the patch and submit it upstream, if successfull? You can call me "Snark", you know ;-) Snark From jpuydt@free.fr Thu Jun 29 06:20:46 2006 Return-Path: X-Original-To: gnomemeeting-devel-list@gnome.org Delivered-To: gnomemeeting-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5F2F33B0286 for ; Thu, 29 Jun 2006 06:20:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03470-04 for ; Thu, 29 Jun 2006 06:20:45 -0400 (EDT) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by menubar.gnome.org (Postfix) with ESMTP id 5A2F43B01CE for ; Thu, 29 Jun 2006 06:20:45 -0400 (EDT) Received: from [192.168.1.2] (lns-bzn-61-82-250-109-134.adsl.proxad.net [82.250.109.134]) by smtp5-g19.free.fr (Postfix) with ESMTP id 4DBBF2765B for ; Thu, 29 Jun 2006 12:20:44 +0200 (CEST) Message-ID: <44A3A99B.8030605@free.fr> Date: Thu, 29 Jun 2006 12:21:15 +0200 From: Julien PUYDT User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: GnomeMeeting development mailing list References: <200606081002.37875.conrad_videokonferenz@gmx.de> <1150380224.6599.22.camel@ganymede.verfaction.de> <44A386D4.8040708@gmx.li> <44A3A865.7000201@free.fr> In-Reply-To: <44A3A865.7000201@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.596 tagged_above=-999 required=2 tests=[AWL=0.003, BAYES_00=-2.599] X-Spam-Score: -2.596 X-Spam-Level: Subject: Re: [GnomeMeeting-devel-list] Debian Packages for Ekiga 2.0.2 X-BeenThere: gnomemeeting-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: GnomeMeeting development mailing list List-Id: GnomeMeeting development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 10:20:46 -0000 Julien PUYDT a écrit : > Stefan Brüns a écrit : >> @Kilian: can you try the patch and submit it upstream, if successfull? > > You can call me "Snark", you know ;-) Hmmmm... which "upstream" are we talking about ? :-) /me should read before answering ;-) Snark