Re: [Ekiga-devel-list] On rewriting the text chat stack
On 16/11/15 21:10, Julien Puydt wrote: Hi, Le 16/11/2015 10:58, Julien Puydt a écrit : Le 17/10/2015 23:20, Julien Puydt a écrit : Well, I'm still on the thinking side of things : writing comes later. I'm still thinking, but now also poking around ekiga's code to see what changed. I'm a bit annoyed I didn't find a heap-view widget, because I thought we had one and wanted to make good use of it :-/ I propose to extend the base Ekiga::Presentity class with this api call: virtual const std::list get_emblems () const = 0; The said emblems would appear in the GUI as little icons decorating the presentity and be used in the following use-cases : - in the main contact view, we could have information about how privileged the contact is (for example those able to call us even in do-not-disturb would have a star/heart shape in their emblems list) ; - in a chat room's heap view, the emblems could materialize people having voice or operator privileges ; - in chat room's heap view again, the is-composing feature could be just a "is-composing" emblem... Hi Julien, Is this about the chat? If you could work on the chat, it would be excellent, as this is what we need now. We could let the emblems for later, once the chat is working. Have a good day, -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] On rewriting the text chat stack
On 17/10/15 23:20, Julien Puydt wrote: Hi, Le 16/10/2015 18:36, Eugen Dedu a écrit : First of all, I think it is essential to implement ONLY ONE METHOD, completely and bug-free, so that it becomes usable by all users. It should especially be avoided to implement several protocols and none of them working. Better to have one protocol working in 2 months than all of them working only in several years by now. In my opinion, 200-400 lines dealing with chat backend can be later updated to another protocol, if really needed. The goal isn't to implement all protocols -- it's to build things cleanly enough so it doesn't become a headache later. Second point, currently we do not have enough man-power to implement all the open chat protocols you mentioned. I wonder if we will ever have, knowing that there are other things in Ekiga which are more important in my opinion (secure videoconferencing, Ekiga.net, multi-user conference, echo cancelling etc. etc.) Again, let's work on only one of them so that a person can send a message to another one (one to one, not one to many), in particular to the one he is doing videoconference with. Yes, one implementation, but the framework must be sound and not get in the way of a second. This is exactly the point I wanted to address. I see that you do not agree with me, but I think it is better for Ekiga project to implement ONE protocol/framework as fast and simple as possible, and only when you or someone else wants to implement another protocol, change the code/framework so that both can coexist gracefully. Of course, if the code/framework has almost the same complexity (e.g. 10 lines more and no additional class/variable), then it is fine to think at a global framework right now. But, after reading characteristics of the protocols you cited, I see that they are too different (one to one / one to many, create rooms or not, nickname / account, room titles or not, presence, history etc.) To resume, I suggest to implement something functional in a short time, instead of having a currently-good global framework with a more complex code and only one implementation and which takes more time. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] On rewriting the text chat stack
Hi, Thanks, Julien, if you could implement the chat, right now it is the only important regression I think (compared to v4). First of all, I think it is essential to implement ONLY ONE METHOD, completely and bug-free, so that it becomes usable by all users. It should especially be avoided to implement several protocols and none of them working. Better to have one protocol working in 2 months than all of them working only in several years by now. In my opinion, 200-400 lines dealing with chat backend can be later updated to another protocol, if really needed. Second point, currently we do not have enough man-power to implement all the open chat protocols you mentioned. I wonder if we will ever have, knowing that there are other things in Ekiga which are more important in my opinion (secure videoconferencing, Ekiga.net, multi-user conference, echo cancelling etc. etc.) Again, let's work on only one of them so that a person can send a message to another one (one to one, not one to many), in particular to the one he is doing videoconference with. Third, as far as I understand, SIP MESSAGE, or better MSRP if possible in a reasonable time, is the most appropriate chat protocol in our case. Ekiga's main mission is videoconferencing, not supporting all chat protocols, for which there are other programs, much more advanced than Ekiga. Finally, would you mind to contact us when you will work on GUI for chat? For example, should text chat be in the same window as the video, or on its own? I do not yet have an idea... As a side note, see also https://bugzilla.gnome.org/show_bug.cgi?id=651837: "The correct way to receive Instant Messages is via the new OpalIMContext class. This will allow for future non-SIP IM to be used. For example, there are a lot of Jabber (XMPP) classes already in PTLib, one day in the not too distant future, I hope, we will bolt that into the OPAL system and there will be OpalPresentity and OpalIMContext derived concrete classes so the user application will barely change at all." Happy hacking, Eugen On 10/10/15 13:58, Damien Sandras wrote: Hi Julien, Thanks for getting back into this. In SIP, I see two basic ways of having Chat sessions : - Using the SIP MESSAGE request. It works like an SMS. You do not have a notion of "conversation", you just send a simple text message somewhere. That is what Ekiga supports until now. - Using the MSRP protocol. It works like a "Text Call". You have a notion of "conversation" between two peers and notifications indicating that the remote is typing. However, MSRP brings more features than simple text chat : - File Transfer over MSRP - Screen Sharing over MSRP You also have extensions : - Multi-participants chat rooms - Conference information through the "conference-info" Event package I think we should keep this in mind, but limit ourselves to 1-to-1 conversations for now. Le vendredi 09 octobre 2015 à 18:18 +0200, Julien Puydt a écrit : Hi, I would like to help redesign the ekiga chat core. Of course, that means one should have a look at how text chat happens within various protocols beforehand. With IRC (https://tools.ietf.org/html/rfc1459): - you connect to a server, where you have a nickname, and the server will send you messages (welcome, notices...) -- notice you can't connect as the same nickname from different places simultaneously ; - you can then join (and even create) a room [called a channel] where you can see the list of members, each with some notion of presence (away state), and a notion of role (voice, op). It can have a title and you can get kicked or banned from a room, or invited to one ; - you send messages to a single user, to a list of users or to a room and as far as I know the server doesn't send you back your own messages (so you have to note them yourself!) ; - I don't think a one-to-one conversation is more than messages with the same person (nickname, in fact) -- so there's no way to have various conversations with the same person, and no way to turn a one-to-one into a many-many one ; and also in a one-to-many I'm not sure recipients know of each other, so they can't just reply to all. With MSN (I haven't found decent documentation): - you connect to a server with an account, and you can connect to it from several places ; I think you can have a nickname on the server ; it's also where the contact list is ; - you can then send one-to-one messages, or join/create rooms (multiparty) ; I don't think you can have a room-specific nickname and I don't know if the server sends you your own messages ; - I don't think a one-to-one conversation is more than messages with the same person -- so again, no way to have various conversations with the same person ; - I don't know if rooms have title, if there is special presence and roles. With Jabber (http://xmpp.org/): - you connect to a server, and you can connect to it from several places ; it's also where the contact list
Re: [Ekiga-devel-list] STUN usage with SIP
On 01/07/15 22:32, schwa...@web.de wrote: Am 01.07.2015 um 11:43 schrieb Eugen Dedu: On 06/06/15 15:04, schwa...@web.de wrote: Hi, Sorry Scwatzi to answer so late, we are too busy. How does STUN work in ekiga? STUN is normaly used as followed: The STUN client should use the same socket as SIP and the received IP and Port should then be used for constructing Contact- , Via- field and SDP. Then a keepalive is needed to keep the NAT Session in the router alive ( to refresh the mapping table entry). This could be a done in many ways. 1. sending registers more frequently 2. sending empty SIP packets 3. sending SIP Request like OPTIONS or NOTIFY(Event: keepalive). A STUN Request should be done frequently in case the public address (IP or port) changes( i.e. after a router restart ) Looking at Ekiga - it uses a different socket for SIP and STUN ( therefor it cannot use the discovered port to build the contact SIP packets. So a user needs to configure his router, too. i.e. Portforwarding or SIP-ALG) - it adds the public IP in the contact but doesn't change the Via. Well, it does change the Via with the public address, see example below. really ? what about contact uri and the contact in SDP For my case (symatric NAT+SIP-ALG) ekiga does behave like i want it to. In my specific case, ekiga writes port 5061(returned by stun) in the Uri but it really should be 5060. is there a way to set the extern port manually ? I do not know. - it only sends one STUN Request when registering, and don't updates its public address - it has no keepalive It does have a keepalive (OPTIONS), for example: ... Housekeepe...baac34b700 SIP Sending PDU (586 bytes) to: rem=udp$86.64.162.35:5060,local=udp$82.238.108.175:5060,if=192.168.0.1%wlan0 OPTIONS sip:ededu@86.64.162.35 SIP/2.0 CSeq: 3 OPTIONS Via: SIP/2.0/UDP 82.238.108.175:5060;branch=z9hG4bK9a00c7ec-a144-e211-80bf-0024d693d8e8;rport User-Agent: Ekiga/4.1.0 From: Eugen Dedu sip:ededu@82.238.108.175;tag=e6f5c6ec-a144-e211-80bf-0024d693d8e8 Call-ID: 22a3bfec-a144-e211-80bf-0024d693d8e8@snoopy To: sip:ededu@86.64.162.35 Accept: application/sdp, application/media_control+xml, application/dtmf, application/dtmf-relay Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK Expires: 3600 Content-Length: 0 Max-Forwards: 70 Also in my case ekiga does not send keepalives. How can I force ekiga to do so ? You cannot, in my opinion. It is strange it does not send keepalive in your case. I would investigate this, but I prefer spending time on development code instead of the current 4.0 releases. Sorry, but we have limited time. The two other remarks are important, especially the first one!! However, note that STUN is being dropped in ekiga, so this should no longer apply for the next Ekiga release. This is interesting. How will ekiga handle NAT in the future? I do not know exactly, Damien is working on this. Personally I don't wanna miss it. Well, its usage in ekiga should to be enhance though. (If you don't want to make the UI to complicated you could still provide some options which can only be set directly via gsettings (or whatever ekiga is using). i.e. lot of phones have parameters you can only set when using provisioning. just some thoughts.) If you come up with something different that works i think am fine with that, too. I put this on my TODO list also, if it will still be relevant. Thank you for your effort. I really appreciate it. Ekiga is awsome Cheers, Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Bug report: Crashes upon starting
On 05/07/15 19:37, a wrote: Ekiga, I use Lubuntu 14.04 (lxde, openbox). Ihave installed Ekiga softphone 4.0.1-4 via synaptic package manager(first I updated my system, checked ekiga, ekiga-dbg and sound-theme-freedesktop). I then start the software, get a Ekiga did not manage to set you network settings... Dialog box with a 'do not enter' traffic sign, and then it crashes (all within 7 seconds). I uninstall and then reinstall. Same response. My system info: a@a-NC210-NC110:/etc/apt/sources.list.d$ uname -a Linux a-NC210-NC110 3.13.0-53-generic #89-Ubuntu SMP Wed May 20 10:34:28 UTC 2015 i686 i686 i686 GNU/Linux When I enter in 'gdb ekiga' I get the following results: a@a-NC210-NC110:/$ gdb ekiga GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-linux-gnu. Type show configuration for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type help. Type apropos word to search for commands related to word... Reading symbols from ekiga...Reading symbols from /usr/lib/debug/.build-id/7d/fb7ed13bafea0be5b9bcf1095a853fb7ea2209.debug...done. done. (gdb) [1]+ Stopped gdb ekiga The only reason I quit and stop gdb is because it is at that point the command causes the terminal to just 'hang' I do not understand. At (gdb) prompt, you must write run. Cannot you do it? This is shown at http://wiki.ekiga.org/index.php/Debugging_Ekiga#How_to_get_a_stack_backtrace_from_a_crash_or_freeze. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] STUN usage with SIP
On 06/06/15 15:04, schwa...@web.de wrote: Hi, Sorry Scwatzi to answer so late, we are too busy. How does STUN work in ekiga? STUN is normaly used as followed: The STUN client should use the same socket as SIP and the received IP and Port should then be used for constructing Contact- , Via- field and SDP. Then a keepalive is needed to keep the NAT Session in the router alive ( to refresh the mapping table entry). This could be a done in many ways. 1. sending registers more frequently 2. sending empty SIP packets 3. sending SIP Request like OPTIONS or NOTIFY(Event: keepalive). A STUN Request should be done frequently in case the public address (IP or port) changes( i.e. after a router restart ) Looking at Ekiga - it uses a different socket for SIP and STUN ( therefor it cannot use the discovered port to build the contact SIP packets. So a user needs to configure his router, too. i.e. Portforwarding or SIP-ALG) - it adds the public IP in the contact but doesn't change the Via. Well, it does change the Via with the public address, see example below. - it only sends one STUN Request when registering, and don't updates its public address - it has no keepalive It does have a keepalive (OPTIONS), for example: ... Housekeepe...baac34b700 SIP Sending PDU (586 bytes) to: rem=udp$86.64.162.35:5060,local=udp$82.238.108.175:5060,if=192.168.0.1%wlan0 OPTIONS sip:ededu@86.64.162.35 SIP/2.0 CSeq: 3 OPTIONS Via: SIP/2.0/UDP 82.238.108.175:5060;branch=z9hG4bK9a00c7ec-a144-e211-80bf-0024d693d8e8;rport User-Agent: Ekiga/4.1.0 From: Eugen Dedu sip:ededu@82.238.108.175;tag=e6f5c6ec-a144-e211-80bf-0024d693d8e8 Call-ID: 22a3bfec-a144-e211-80bf-0024d693d8e8@snoopy To: sip:ededu@86.64.162.35 Accept: application/sdp, application/media_control+xml, application/dtmf, application/dtmf-relay Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK Expires: 3600 Content-Length: 0 Max-Forwards: 70 The two other remarks are important, especially the first one!! However, note that STUN is being dropped in ekiga, so this should no longer apply for the next Ekiga release. I put this on my TODO list also, if it will still be relevant. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] building latest ekiga master
On 30/04/15 13:28, Peter Robinson wrote: On Thu, Apr 30, 2015 at 10:04 AM, Eugen Dedu eugen.d...@univ-fcomte.fr wrote: On 29/04/15 12:29, Peter Robinson wrote: On Wed, Apr 29, 2015 at 10:38 AM, Eugen Dedu eugen.d...@univ-fcomte.fr wrote: On 29/04/15 11:04, Peter Robinson wrote: Hi All, I thought I'd try to build the latest ekiga dev on Fedora 22 to see how it looks (and add a copr build [1] for other interested people) but I was stumped at the first hurdle. It seems between ptlib 2.10.x and 2.14.x the build system was changed around quite a lot and has issues on regular distro style packaging where things like install directory are specified and don't work any more. They also use things like old config.guess/config.sub dating back to 2003 so most new architectures are missing too. I didn't have much time to spend but overall it seems like some regressions in the newer ptlib/opal side of things so I thought I'd just give people a heads up. Thanks a lot for trying! Could you be more specific about what install directory does not work? Here on debian ptlib and opal package and install fine. One note: you need to use make opt in ptlib and opal in order for plugins to be installed too. It's the same mechanism used to build 2.10 and all preceding releases for years, as it looking at the git logs from the first release we used in Fedora back to when it changed name from pwlib to ptlib back in 2008. What exactly version of ptlib/opal have you tried (also: release or branch)? ptlib 2.14.3 Could you give me the log of the failed build? Except updating config.guess/sub, I do not know what to do. Full logs at [1] but basically the problem is if I run the make install command below it tries to installer it in /usr/lib64 eveen though it's explicitly specified. make PREFIX=/builddir/build/BUILDROOT/ptlib-2.14.3-1.fc23.x86_64/usr LIBDIR=/builddir/build/BUILDROOT/ptlib-2.14.3-1.fc23.x86_64/usr/lib64 install [1] https://kojipkgs.fedoraproject.org//work/tasks/6670/9606670/build.log In [1] I see: + ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --prefix=/builddir/build/BUILDROOT/ptlib-2.14.3-1.fc23.x86_64/usr --disable-static --enable-plugins --disable-oss --enable-v4l2 --disable-avc --disable-v4l --enable-pulse so you specify --libdir=/usr/lib64. Afterwards I see (as you also wrote): + make PREFIX=/builddir/build/BUILDROOT/ptlib-2.14.3-1.fc23.x86_64/usr LIBDIR=/builddir/build/BUILDROOT/ptlib-2.14.3-1.fc23.x86_64/usr/lib64 install As far as I know, the usual (right?) way is to use PREFIX and LIBDIR with make (as you did), and DESTDIR with make install. I think you need to change the make install command into this: make DESTDIR=/builddir/build/BUILDROOT/ptlib-2.14.3-1.fc23.x86_64/usr install What do you think? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] building latest ekiga master
On 29/04/15 11:04, Peter Robinson wrote: Hi All, I thought I'd try to build the latest ekiga dev on Fedora 22 to see how it looks (and add a copr build [1] for other interested people) but I was stumped at the first hurdle. It seems between ptlib 2.10.x and 2.14.x the build system was changed around quite a lot and has issues on regular distro style packaging where things like install directory are specified and don't work any more. They also use things like old config.guess/config.sub dating back to 2003 so most new architectures are missing too. I didn't have much time to spend but overall it seems like some regressions in the newer ptlib/opal side of things so I thought I'd just give people a heads up. I updated config.guess and config.sub, as shown at http://sourceforge.net/p/opalvoip/code/log/ Could you use the HEAD for your tests instead of last release? You can use the same commands to build it, only the source code is different. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] building latest ekiga master
On 29/04/15 12:29, Peter Robinson wrote: On Wed, Apr 29, 2015 at 10:38 AM, Eugen Dedu eugen.d...@univ-fcomte.fr wrote: On 29/04/15 11:04, Peter Robinson wrote: Hi All, I thought I'd try to build the latest ekiga dev on Fedora 22 to see how it looks (and add a copr build [1] for other interested people) but I was stumped at the first hurdle. It seems between ptlib 2.10.x and 2.14.x the build system was changed around quite a lot and has issues on regular distro style packaging where things like install directory are specified and don't work any more. They also use things like old config.guess/config.sub dating back to 2003 so most new architectures are missing too. I didn't have much time to spend but overall it seems like some regressions in the newer ptlib/opal side of things so I thought I'd just give people a heads up. Thanks a lot for trying! Could you be more specific about what install directory does not work? Here on debian ptlib and opal package and install fine. One note: you need to use make opt in ptlib and opal in order for plugins to be installed too. It's the same mechanism used to build 2.10 and all preceding releases for years, as it looking at the git logs from the first release we used in Fedora back to when it changed name from pwlib to ptlib back in 2008. What exactly version of ptlib/opal have you tried (also: release or branch)? ptlib 2.14.3 Could you give me the log of the failed build? Except updating config.guess/sub, I do not know what to do. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Design of the engine : why abstract Ekiga::Foo and Ekiga::FooImpl matter
On 14/01/15 08:43, Julien Puydt wrote: Hi, this mail is meant to explain why having two classes doesn't make the code more complex just for the sake of it, but because it brings nice features. The fact that Ekiga::Foo is purely abstract means : 1. that anyone trying to write an instance of it, say Bar::Foo, will get notified by the compiler if they forget to implement one of the methods, or if they mispell one of them -- the compiler is helpful! 2. that anyone trying to write a very specific implementation is completely free to do so, as the abstract class is, well, abstract ; 3. that anyone trying to write an implementation with no special needs can just inherit Ekiga::FooImpl and be done! So when writing new code, the presence of two classes doesn't get in the way, and even gets the compiler to help : that is a bonus. Now, now... we decide that Ekiga::Foo is too weak and add a method. This immediately : 1. breaks Ekiga::FooImpl, which immediately gets fixed ; of course it also breaks every class inheriting from Ekiga::FooImpl, but they all get fixed at the same time -- and the fix can only be correct (more on that later) ; 2. breaks every class inheriting from Ekiga::Foo, and the compiler says so : the code won't compile as-is, someone will have to have a look at all classes with very specific needs, and write correspondingly specific implementations, so everything is correct. And that's all : we made sure we either had all methods reimplemented or none -- no in-between! So when modifying existing code, the presence of the two classes ensures that the compiler will push every problem explicitly under our eyes : there will be no silent break. Compare with a situation where Ekiga::Foo has naive implementations of everything directly in the base class: 1. Anyone writing an instance of Ekiga::Foo with an overriden populate_memu (where the base had populate_menu) will have a hard time knowing they made a typo : the compiler won't catch it. Silent break! 2. Anyone writing an instance of Ekiga::Foo may implement only two thirds of the method, get something which won't run, but will gladly compile. Silent break! 3. Anyone writing an instance with very specific needs will find the variables used by the base class implementation in the way : if they want to put some information in a 'tokens' variable the base class said was a list of strings, but should now be a list of Bar::Token, will need to name it my_tokens, but tokens will still take some room, and if they forget a my_ somewhere, the compiler might not complain if they don't use string/Bar::Token-specific api. Silent break! 4. You've been lucky : you only reimplemented populate_menu, and kept the other base implementations because they fit. Someone modifies the base implementation (added a method and made the default implementations follow : all nice and clean!). Your code still compiles, but of course, won't work. Silent break! I think the purely abstract Ekiga::Foo and Ekiga::FooImpl is better : it is more expensive, but you do get what you paid for. Hi Julien, In case my opinion is useful: I think you are right in theory and also in a big program with many developers working 100% on it. However, I personnaly vote for pragmatism, for simple code (simple is better!) In our case, each time the code gets better from theory point of view, gets harder to understand by someone wishing to be involved of. Cheers! -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Encryption on Ekiga
On 09/12/14 21:50, Fountain Head wrote: What's the entry point where I can encrypt and decrypt video/audio? Would it be in the Ekiga source code or Opal? Encryption is done in opal. Ekiga stable code (v 4.0) works with an old opal code, which does not have encryption. Ekiga development (master) uses a new opal code (v14) which provides encryption; however, ekiga does not uses it currently. We are working to make the development code stable. I think the only thing to do is that ekiga uses sips: instead of sip: in order to instruct opal to use encryption. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] New user interface
On 16/11/14 18:39, Damien Sandras wrote: Hi, I am now progressing on the address book window. This is the last part that needs to be refreshed. When I am done, I will be able to merge into master and work on new SIP features. Congratulations, Damien! Looking forward to seeing it in master and take it a glance. If some of you want to help, in any area, including the website, the ekiga.net website, the ekiga.net web user interface, please feel free to propose yourself. I have a busy period, but I will resume working afterwards. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Hello World.
On 06/11/14 22:49, Fung Lee wrote: I'm just sending an email to this community because I am interested in getting involved. I'm a noob so please bare with me. I hope to learn much and contribute many patches to this project. Well, ptlib/opal/ekiga is a big project and difficult to approach for beginners. If you really want to do it, I propose you for ex. to build the current master and test if the new opus and webm codecs work as expected. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Snapshots
Hi, I have just added Windows snapshots to http://wiki.ekiga.org/index.php/Snapshots. Currrently, using video on Windows leads to a crash. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Using gstreamer for everything audio and video in ekiga
On 22/04/14 15:16, Julien Puydt wrote: Le 21/04/2014 17:18, Eugen Dedu a écrit : On 02/04/14 09:34, Julien Puydt wrote: Hi, here is a new version of the test code. Now the user interface is a series of buttons and two combo boxes to choose from a few devices, both for audio and video (no proper device detection yet -- the V4L2 choice might fail if you don't have such a device). The next step is to add more comments, then make it possible to stop the call and start a new one. I compiled your code: everything goes well. When executing, I noticed two things: - video is slow: perhaps 2-4 images per second That is extremely surprising, as I have been working on a quite slow box where I should have known about performance issues... - the other video window is always several coloured vertical lines Can you try the following two commands: 1. gst-launch videotestsrc ! ximagesink It shows several coloured vertical lines. The output is: snoopy:~$ gst-launch-1.0 videotestsrc ! ximagesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock ERROR: from element /GstPipeline:pipeline0/GstXImageSink:ximagesink0: Output window was closed Additional debug info: ximagesink.c(686): gst_ximagesink_handle_xevents (): /GstPipeline:pipeline0/GstXImageSink:ximagesink0 Execution ended after 0:00:04.347078564 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... snoopy:~$ 2. gst-launch videotestsrc ! agingtv ! ximagesink The same erroneous window, with the same output. Could you explain what is the ekiga architecture for video? We have clutter thing, v4l2 plugin thing, X code thing in ekiga, now you propose gstreamer thing... how are they related? What precisely will gstreamer code replace? Gstreamer should replace mostly everything... connecting on one hand to opal for the network part and to Damien's clutter code for the video display. So will it replace all ptlib plugins? Currently there is: /usr/lib/ptlib-2.10.12/devices/videoinput/v4l2_pwplugin.so /usr/lib/ptlib-2.10.12/devices/sound/oss_pwplugin.so /usr/lib/ptlib-2.10.12/devices/sound/pulse_pwplugin.so /usr/lib/ptlib-2.10.12/devices/sound/alsa_pwplugin.so -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Using gstreamer for everything audio and video in ekiga
On 02/04/14 09:34, Julien Puydt wrote: Hi, here is a new version of the test code. Now the user interface is a series of buttons and two combo boxes to choose from a few devices, both for audio and video (no proper device detection yet -- the V4L2 choice might fail if you don't have such a device). The next step is to add more comments, then make it possible to stop the call and start a new one. I compiled your code: everything goes well. When executing, I noticed two things: - video is slow: perhaps 2-4 images per second - the other video window is always several coloured vertical lines Could you explain what is the ekiga architecture for video? We have clutter thing, v4l2 plugin thing, X code thing in ekiga, now you propose gstreamer thing... how are they related? What precisely will gstreamer code replace? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] CFLAGS for ptlib and opal
At the time I noticed this (maybe 1 year ago), it was not so simple to get rid of CFLAGS, or perhaps I looked only at opal. I will take a new look as soon as I find time, thanks. On 13/04/14 22:16, John Smith wrote: Hrm. ptlib's configure seems to modify CFLAGS like this: CFLAGS=-g -O2 overwriting the current values instead of CFLAGS+=-g -O2 adding to the current values Looks like that needs fixing On Sun, Apr 13, 2014 at 9:52 PM, Eugen Dedu eugen.d...@pu-pm.univ-fcomte.fr wrote: On 13/04/14 21:43, John Smith wrote: Hi, In the compiling instructions (http://wiki.ekiga.org/index.php/Compiling_Ekiga#Compiling_instructions) it is stated that the use of the CFLAGS variable is not reliable. I was wondering if this is still the case ? And if so, what seems to be the issue ? I would like to use the CFLAGS var. I think this is still the case. ptlib and opal wrongly define some configuration flags in CFLAGS, and if you use CFLAGS then those flags are not used anymore. The end result is that compilation fails or that execution of ekiga fails, I do not remember exactly which one. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ptlib build failure
On 14/04/14 10:38, John Smith wrote: On Mon, Apr 14, 2014 at 10:11 AM, Eugen Dedu eugen.d...@pu-pm.univ-fcomte.fr wrote: On 14/04/14 10:02, Eugen Dedu wrote: I thought I fixed this. What version of ptlib do you compile? Err, sorry, I fixed it in the repository, but no release has been done afterwards... Please use the branch v2_10 of ptlib, OR apply manually commits 31087 and 31392, you can take them from http://sourceforge.net/p/opalvoip/code/log. I used the version specified here : http://wiki.ekiga.org/index.php/Download_Ekiga_sources which is v2_10 : svn export https://opalvoip.svn.sourceforge.net/svnroot/opalvoip/ptlib/branches/v2_10 ptlib im pretty new to svn, how do i manually apply commits 31087 and 31392 ? If you used the line above (svn export...), then you have already the good source code. So the error is elsewhere, and I was wrong about it. Don't you have the file ./src/ptlib/common/getdate.tab.c in ptlib directory? What is the complete line: #define SVN_REVISION ... in revision.h? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ptlib build failure
On 14/04/14 11:01, John Smith wrote: On Mon, Apr 14, 2014 at 10:56 AM, Eugen Dedu eugen.d...@pu-pm.univ-fcomte.fr wrote: If you used the line above (svn export...), then you have already the good source code. So the error is elsewhere, and I was wrong about it. Don't you have the file ./src/ptlib/common/getdate.tab.c in ptlib directory? What is the complete line: #define SVN_REVISION ... in revision.h? I dont seem to have that file. revision.h states : #define SVN_REVISION 30295 Ok, so you do not use the latest code from the branch, but the release, that is the reason of the error. Remove your ptlib directory, and use: svn export https://opalvoip.svn.sourceforge.net/svnroot/opalvoip/ptlib/branches/v2_10 ptlib to get it. The compilation should work afterwards. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] opal build failure
On 14/04/14 15:16, John Smith wrote:
Hi,
I am getting an error [1] building opal.
Regards,
John Smith
[1]
h263-1998.cxx:97:58: note: candidates are:
In file included from h263-1998.cxx:58:0:
../common/dyna.h:88:7: note: FFMPEGLibrary::FFMPEGLibrary()
class FFMPEGLibrary
^
../common/dyna.h:88:7: note: candidate expects 0 arguments, 1 provided
../common/dyna.h:88:7: note: FFMPEGLibrary::FFMPEGLibrary(const FFMPEGLibrary)
../common/dyna.h:88:7: note: no known conversion for argument 1 from
âAVCodecIDâ to âconst FFMPEGLibraryâ
h263-1998.cxx:206:37: error: âbool H263_Base_EncoderContext::Initâ is
not a static member of âclass H263_Base_EncoderContextâ
bool H263_Base_EncoderContext::Init(CodecID codecId)
^
h263-1998.cxx:206:37: error: âCodecIDâ was not declared in this scope
h263-1998.cxx:207:1: error: expected â,â or â;â before â{â token
{
^
Do you use libav or ffmpeg? Which version?
Do you need H263 and H264 video codecs or not? If not, it is simpler.
--
Eugen
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Static source code analysis of ekiga
On 14/04/14 20:27, Julien Puydt wrote: Hi, Le 14/04/2014 18:24, John Smith a écrit : Hi, Just for fun, I decided to run the llvm/clang static source code analyzer on ptlib, opal, and ekiga. The results can be found here: ptlib http://lbalbalba.url.ph/clang/ptlib/ opal http://lbalbalba.url.ph/clang/opal/ ekiga http://lbalbalba.url.ph/clang/ekiga/ I pushed a commit to fix those in ekiga... I'm actually quite surprised there was so little to complain about! ptlib and opal are too old to bother with those issues. We are working to use the newest ptlib/opal code... -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Static source code analysis of ekiga
On 14/04/14 21:08, John Smith wrote: On Mon, Apr 14, 2014 at 9:05 PM, Eugen Dedu eugen.d...@pu-pm.univ-fcomte.fr wrote: ptlib and opal are too old to bother with those issues. We are working to use the newest ptlib/opal code... I can checkout the latest revisions of ptlib/opal and run the analyzer on that. Good, please try versions ptlib 2.14 and opal 3.14 (latest stable releases) and post the results not here, but on opalvoip-u...@lists.sourceforge.net mailing list. Thank you! -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] CFLAGS for ptlib and opal
On 13/04/14 21:43, John Smith wrote: Hi, In the compiling instructions (http://wiki.ekiga.org/index.php/Compiling_Ekiga#Compiling_instructions) it is stated that the use of the CFLAGS variable is not reliable. I was wondering if this is still the case ? And if so, what seems to be the issue ? I would like to use the CFLAGS var. I think this is still the case. ptlib and opal wrongly define some configuration flags in CFLAGS, and if you use CFLAGS then those flags are not used anymore. The end result is that compilation fails or that execution of ekiga fails, I do not remember exactly which one. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] About GUDev in ekiga
On 04/03/14 15:31, Julien Puydt wrote: Le 03/03/2014 19:02, Julien Puydt a écrit : Hi, I just pushed a GUDev-based device monitor in ekiga. The current state of matters is that it detects video input devices when you plug/unplug them when ekiga runs. It compiles, and it looks like it works (I have various notifications... and the device appears in the list... is it supposed to do more?). The next steps are: - see if people report success with it too ; - try to do the same for audio input/output (shouldn't be too hard...) ; - remove the hal-dbus code. I tried to get to the core of the matter today, and my findings are the following: (1) For video, what I have done should just work (hence I removed those parts from the hal-dbus code). (2) For audio, GUDev won't give what we want. In fact, according to http://www.freedesktop.org/wiki/Software/DeviceKit, for audio devices, one should use the same library for device enumeration and for device use. That doesn't work for us, since we can use pulseaudio, oss, alsa, etc... So I don't think we can actually replace HAL yet. (3) For network interfaces, what we have uses NetworkManager through DBUS to trigger signals... and that's all. The signals aren't used! We have code for nothing! I would suggest getting rid of the whole stack (including my new code), to be replaced by something better later. As you wish. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ptlib/opal v14 news
On 03/03/14 17:17, Peter Robinson wrote: Except the bug with make opt instead of make: - ptlib compiles fine on linux and on windows - opal compiles fine on linux, not yet tested on windows - ekiga does not compile, for ex. ptbuildopts.h does not exist anymore Now ptlib and opal build fine for linux and windows. It remains ekiga. Is there plans to cut an alpha release tarball if you want wider testing? What's the plans for heading towards the next release? I personnaly would like to make at least two preview releases before getting the stable out. It is very important to get wide testing, given the myriad of cases to be dealt with. I would release the first preview when it works well on my machine. Difficult to make a prediction for this first preview, I would say 1-6 months. As for features still waiting to be integrated, I see Damien's work on gtkapplication/gmenumodel, the switch to ptlib/opal v14, both undergoing, and some polishes and bug fixes here and there. This is only my view of things. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ptlib/opal v14 news
On 04/03/14 16:19, Eugen Dedu wrote: On 03/03/14 17:17, Peter Robinson wrote: Except the bug with make opt instead of make: - ptlib compiles fine on linux and on windows - opal compiles fine on linux, not yet tested on windows - ekiga does not compile, for ex. ptbuildopts.h does not exist anymore Now ptlib and opal build fine for linux and windows. It remains ekiga. Is there plans to cut an alpha release tarball if you want wider testing? What's the plans for heading towards the next release? I personnaly would like to make at least two preview releases before getting the stable out. It is very important to get wide testing, given the myriad of cases to be dealt with. I would release the first preview when it works well on my machine. Difficult to make a prediction for this first preview, I would say 1-6 months. As for features still waiting to be integrated, I see Damien's work on gtkapplication/gmenumodel, the switch to ptlib/opal v14, both undergoing, and some polishes and bug fixes here and there. This is only my view of things. Just to add that I would also like to check the new features bought by the new ptlib/opal: data encryption, webm, opus codecs, ipv6 etc., before releasing, and this could take time. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Migrating to GTK+3.10
On 03/03/14 13:25, Thierry Simonnet wrote: Hello, I get last version of ekiga from git and have : checking for perl = 5.8.1... 5.18.2 checking for XML::Parser... ok checking for GTK... no configure: error: Package requirements (gtk+-3.0 = 3.10.0) were not met: Requested 'gtk+-3.0 = 3.10.0' but version of GTK+ is 3.8.2 Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables GTK_CFLAGS and GTK_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. make: *** [/root/win32/ekiga/config.status] Error 1 The trouble is that 3.10 package for win32 from http://win32builder.gnome.org/ is not well packaged. gtk+-3.0.pc is missing for example. Package for win64 seems to have all files. Hm, we are in bad shape then... Could you contact people creating gtk 3.10 for windows and tell them about the .pc error? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ptlib/opal v14 news
On 03/03/14 11:38, Eugen Dedu wrote: Hi, Except the bug with make opt instead of make: - ptlib compiles fine on linux and on windows - opal compiles fine on linux, not yet tested on windows - ekiga does not compile, for ex. ptbuildopts.h does not exist anymore Now ptlib and opal build fine for linux and windows. It remains ekiga. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Please remove me form your list
On 03/03/14 14:22, ARUN THAKER wrote: Please remove me form your list With Gr8 Regards-arun thaker *A real 'karma-yogi', who first acquires knowledge and then works for the welfare of people, quite naturally becomes popular and famous. There is no enemy of such a man but even if there are, he is able to vanquish them. His popularity in the society increases on account of his successes and good deeds.* If you don't understand my silence, you will not understand my words ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list Go to https://mail.gnome.org/mailman/listinfo/ekiga-devel-list and put your address at the bottom of the page. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] About GUDev in ekiga
On 03/03/14 20:18, Julien Puydt wrote: Le 03/03/2014 20:14, Julien Puydt a écrit : Le 03/03/2014 19:15, Eugen Dedu a écrit : On 03/03/14 19:02, Julien Puydt wrote: Hi, I just pushed a GUDev-based device monitor in ekiga. Why have you called the files hal-gudev-... and not gudev-... ? Is there hal involved?! -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Call history view bug, GmCellRendererBitext and gtk+
On 28/02/14 15:03, Julien Puydt wrote: Hi, this is the tale of a bug hunt. It doesn't end as well as I would like. A strange bug, in fact: at startup, Eugen only sees one line per entry in his call history ; it becomes better only later. At startup, Julien (me) has one line and a half par entry (and it doesn't get better later because of the infamous clutter crash). The common problem is that two full lines should be there. So there might be something wrong with the initial population of the view, so the first thing is to try to print what data the call history view receives ; and the answer is : the engine part works! Only the view is to blame. So what exactly do we use to display that information, since obviously that is where the fault lies? The GmCellRendererBitext class, which is inheriting from GtkCellRendererText. If there's only one and a half line per entry, then that means that entries are overlapping, and that points to a problem with the get_size in that code. But why does it fail in the call history view and not in the roster view? In both case, our renderer is to the right of a pixbuf renderer. But in the roster view, the images are quite big images, while in the call history, those images are quite small. So in both cases, the size of our renderer in wrong, but in the roster, the presence of the big images means the lines are tall enough and there is no overlapping anyway. So I just had to fix the size computation. Unfortunately it turns out our gm_cell_renderer_bitext_get_size method wasn't called, ever. It's deprecated in gtk+ 3.something! There is some provision in the code to still call the obsolete api, but it apparently doesn't work. So yesterday I just added a few methods of the new api to detect the sizes, and committed that because it fixed the display problem (yes, I ran ekiga, and no, I didn't test calling because of the clutter crash). That made Eugen unhappy: I had added dozens of lines of code... and now it crashed after a while! Indeed, I was able to reproduce the crash. So today I made another try, this time trying to rework the code to be much, much simpler. In fact, I removed much of the code, trying to use as much as possible the underlying GtkCellRendererText class to avoid any problem. The code is simpler code, but even yesterday's code shouldn't have crashed, and did ; the dirty secret is a two year old bug: http://bugzilla.gnome.org/show_bug.cgi?id=668779 As you can see with the sample code in comment #8, there are simple uses of the gtk+ code which can easily give crashes. The fix from yesterday (fix for the display issues) was apparently putting us in exactly the right conditions to trigger the bug. The commit I pushed today has simplified the code much, and it looks like it doesn't trigger the crash... at least not as much, but I can hardly guarantee anything. That is were things stand for now: the good news is that the display bug is gone and the code is (much) lighter and simpler... but we know there is a crashing bug lurking :-/ Thanks, Julien, for the description and for code simplification! I will test it. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Standby when being called
When 520 calls me back, the call window shows Standby at the bottom of the window. I suppose it should have shown Calling, Being called or something like this. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Call window does not close when ending a call
When I receive the call back from 520 the call window opens (this is normal). I press red phone, the call ends but the call window remains open. Pressing the X from window does not close it. I need to press twice the camera icon in main screen to close the call window. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
On 17/02/14 08:41, Julien Puydt wrote: Hi, The problem description is: When starting ekiga and showing the call history, only one line per entry is shown (destination address). If I make a call, the call history shows two lines per entry: destination and info about the call (duration etc.) It should show all the information from the beginning. What I saw last time I managed to make ekiga run was that for each call history entry, I had a line and a half. Yes, I had a second line, but it was half-hidden. I'd love to say that it was the next line hiding the last half of the previous, but even the last one had that... I couldn't have a look at what happens when adding a new call because when I clicked to make one, I goofed and clicked on video preview... and now I'm stuck :-P I do not know if you have found it yet: there is dconf-editor, org-gnome-ekiga-devices-video. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
On 16/02/14 18:17, Julien Puydt wrote: On 02/14/2014 10:59 AM, Eugen Dedu wrote: On 06/02/14 18:39, Eugen Dedu wrote: On 24/01/14 12:02, Eugen Dedu wrote: On 24/01/14 10:30, Thierry Simonnet wrote: Le 24/01/2014 10:03, Eugen Dedu a écrit : On 08/01/14 16:35, Thierry Simonnet wrote: I made more tests : * I can register to ekiga.net and use it only when creating account with SIP user profile. Ekiga.net profile doesn't work. At enabling it write : processing Do you still have this error? Yes with ekiga-setup-4.1.0-git-711_gd2795be.exe ftp://simonnet:toto1...@greg.esiee.fr/../../www/archive/tmp/ekiga-win32/trunk/ekiga-setup-4.1.0-git-711_gd2795be.exe. I'm building the next package. I can register to ekiga.net using add a SIP account, but when doing this with add a ekiga.net account, process stays at processing The problem is when you create the account using Add an Ekiga.net account, it creates it as if it was an H323 account. This can be noticed when editing that account afterwards: it shows a Gatekeeper entry. I let Julien or Damien take care of this bug. Any hearty soul to take care of this? Since the developer who introduced the regression has not fix it :(, I fixed it myself, https://git.gnome.org/browse/ekiga/commit/?id=3df23a0aa. I think I was the culprit and didn't react in time. Sorry :-( There is also the call history refresh e-mail, if you have time, thanks!... -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
On 16/02/14 20:16, Julien Puydt wrote: On 02/16/2014 07:32 PM, Eugen Dedu wrote: There is also the call history refresh e-mail, if you have time, thanks!... Uh... You'll have to refresh my memory about that one, I fear :-( Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list -- Eugen ---BeginMessage--- Hi, When starting ekiga and showing the call history, only one line per entry is shown (destination address). If I make a call, the call history shows two lines per entry: destination and info about the call (duration etc.) It should show all the information from the beginning. -- Eugen ---End Message--- ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Roster groups
On 16/02/14 20:29, Julien Puydt wrote: On 02/16/2014 06:19 PM, Julien Puydt wrote: On 02/14/2014 12:11 PM, Eugen Dedu wrote: Hi, When I create a SIP account with random settings, no corresponding group appears in the roster. However, if I restart ekiga I do see the new group in the roster. Conclusion: the new group should be visible in the roster right after account creation. The same bug exists when an account is removed: its corresponding group in roster disappears only after restarting ekiga. I have a clue what's wrong... and I'll try to fix it. If I don't forget... :-( I pushed what should be a fix, with the caveat that since I upgraded gtk+ on my box today, the gui code doesn't compile anymore. So I only tested my patch by seeing that it compiled well with make -k -- I'm currently quite unable to run ekiga! This is because deprecated symbols, if you compile without gtk-debug then compile works. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Errors on Windows with clutter
On 15/02/14 13:22, Damien Sandras wrote: Le 14/02/14 16:23, Eugen Dedu a écrit : On 05/02/14 21:54, Eugen Dedu wrote: I have not yet looked at the errors, here is what I obtain after finally succeeding in opening the call window on Windows. Damien, both warnings come because in ekiga code we have both gtk_clutter_init and gtk_init functions, whereas it should not, cf. https://developer.gnome.org/clutter-gtk/0.91/clutter-gtk-Utility-Functions.html#gtk-clutter-init: This function should be called instead of clutter_init() and gtk_init(). (It's gtk_clutter_init function which gives these warnings.) Strange enough, even if I remove gtk_init, those warnings do not disappear. But perhaps you have a better idea than removing gtk_init(). In my current GtkApplication branch (probably merged next week), gtk_init does not exist anymore. Probably you should ask for help, if possible, on the clutter mailing list. I posted an e-mail one month ago, and pinged them too: no answer. I will ask again, but after being sure it is not something evident in ekiga code itself. That's a pitty things do not work yet on WIN32 given the fact I ported to Clutter to have less problems :( -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
On 06/02/14 18:39, Eugen Dedu wrote: On 24/01/14 12:02, Eugen Dedu wrote: On 24/01/14 10:30, Thierry Simonnet wrote: Le 24/01/2014 10:03, Eugen Dedu a écrit : On 08/01/14 16:35, Thierry Simonnet wrote: I made more tests : * I can register to ekiga.net and use it only when creating account with SIP user profile. Ekiga.net profile doesn't work. At enabling it write : processing Do you still have this error? Yes with ekiga-setup-4.1.0-git-711_gd2795be.exe ftp://simonnet:toto1...@greg.esiee.fr/../../www/archive/tmp/ekiga-win32/trunk/ekiga-setup-4.1.0-git-711_gd2795be.exe. I'm building the next package. I can register to ekiga.net using add a SIP account, but when doing this with add a ekiga.net account, process stays at processing The problem is when you create the account using Add an Ekiga.net account, it creates it as if it was an H323 account. This can be noticed when editing that account afterwards: it shows a Gatekeeper entry. I let Julien or Damien take care of this bug. Any hearty soul to take care of this? Since the developer who introduced the regression has not fix it :(, I fixed it myself, https://git.gnome.org/browse/ekiga/commit/?id=3df23a0aa. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Roster groups
Hi, When I create a SIP account with random settings, no corresponding group appears in the roster. However, if I restart ekiga I do see the new group in the roster. Conclusion: the new group should be visible in the roster right after account creation. The same bug exists when an account is removed: its corresponding group in roster disappears only after restarting ekiga. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] pixmap package name
On 06/02/14 21:42, Eugen Dedu wrote: On 01/02/14 17:09, Damien Sandras wrote: Le 26/01/14 19:58, Eugen Dedu a écrit : On 25/01/14 16:06, Damien Sandras wrote: Le 25/01/14 15:22, Eugen Dedu a écrit : On 25/01/14 14:45, Damien Sandras wrote: Le 23/01/14 14:04, Eugen Dedu a écrit : In pixmaps/Makefile.am, the word ekiga is used twice. Shouldn't PACKAGE_NAME be used instead? You can change it if you prefer. In order to have both stable and unstable packages on my machine, I change the name to ekiga-snapshot. The modification I proposed should help, in my opinion. I will do it. I have just done it. I think there is an error in pixmap/Makefile.am file: IMAGES_FILES= \ [...] inlines.h: $(IMAGE_FILES) $(nobase_dist_icon_DATA) Makefile.am Shouldn't the last line use IMAGES_FILES instead of IMAGE_FILES? There is no other IMAGE_FILES in whole ekiga code. Yes, but it raises the question : is inlines.h still used at all ? I think not... It is used in lib/gui/gmstockicons.c. Fixed (and tested) with https://git.gnome.org/browse/ekiga/commit/?id=ca309540b471. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Errors on Windows with clutter
On 05/02/14 21:54, Eugen Dedu wrote: I have not yet looked at the errors, here is what I obtain after finally succeeding in opening the call window on Windows. Damien, both warnings come because in ekiga code we have both gtk_clutter_init and gtk_init functions, whereas it should not, cf. https://developer.gnome.org/clutter-gtk/0.91/clutter-gtk-Utility-Functions.html#gtk-clutter-init: This function should be called instead of clutter_init() and gtk_init(). (It's gtk_clutter_init function which gives these warnings.) Strange enough, even if I remove gtk_init, those warnings do not disappear. But perhaps you have a better idea than removing gtk_init(). -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Errors on Windows with clutter
The current state of affairs on Windows is that ekiga shows the two warnings below and, when the call window is opened, crashes. gdb shows: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 5816.0x10ac] 0x053aefd5 in ig4icd32!DrvSetPixelFormat () from C:\Windows\SysWOW64\ig4icd32.dll (gdb) bt #0 0x053aefd5 in ig4icd32!DrvSetPixelFormat () from C:\Windows\SysWOW64\ig4icd32.dll #1 0x8872 in ?? () #2 0x0432f69c in ?? () #3 0x66dc40a4 in libgstclutter!clutter_gst_video_sink_get_type () from C:\Program Files (x86)\Ekiga\lib\gstreamer-1.0\libgstclutter.dll #4 0x03f776f0 in ?? () #5 0x63a4d10e in libgobject-2!g_object_new_valist () from C:\Program Files (x86)\Ekiga\libgobject-2.0-0.dll #6 0x63a4cbe7 in libgobject-2!g_object_newv () from C:\Program Files (x86)\Ekiga\libgobject-2.0-0.dll #7 0x63a4d0b3 in libgobject-2!g_object_new_valist () from C:\Program Files (x86)\Ekiga\libgobject-2.0-0.dll #8 0x63a4c72d in libgobject-2!g_object_new () from C:\Program Files (x86)\Ekiga\libgobject-2.0-0.dll #9 0x61469218 in libgstreamer-1!gst_element_factory_create () from C:\Program Files (x86)\Ekiga\libgstreamer-1.0-0.dll #10 0x in ?? () and the log is attached. On 06/02/14 09:00, Damien Sandras wrote: Most probably you should get help from the clutter mailing list. That's sad. I introduced Clutter to simplify everything, and knowing that Clutter will finally be merged into GTK+ itself. Le 05/02/14 21:54, Eugen Dedu a écrit : I have not yet looked at the errors, here is what I obtain after finally succeeding in opening the call window on Windows. ekiga-stderr.txt.gz Description: GNU Zip compressed data ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Ekiga 4.0.1 crashes
On 08/02/14 10:51, Damien Sandras wrote: Hi Sebastian, Le 07/02/14 15:18, Sebastian Spaeth a écrit : On 05.02.2014 20:14, Damien Sandras wrote: I'm not aware of this. I suppose the ALSA plugin works fine. Have you been able to determine what the issue could be ? (the PulseAudio plugin being PTLIB) Hi Damien, no I have not found out the issue yet. My up-to-date debian testing crashes independent of whether I select ptlib/pulse or ptlib/alsa for my sound devices. That sounds weird. Eugen, are you aware of this ? The only crash involving pulse I am aware of is one bug in bugzilla redhat (https://bugzilla.redhat.com/buglist.cgi?quicksearch=ekigalist_id=2198077). I looked a bit for it but I did not find it, I will look for it again if needed. Anyway, I intend porting to a newer OPAL/PTLIB anytime soon. That could be a good idea to test again. I agree. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] gstreamer error on Windows
On 05/02/14 20:14, Damien Sandras wrote: Le 05/02/14 18:35, Eugen Dedu a écrit : On 05/02/14 18:17, Eugen Dedu wrote: On 03/02/14 14:07, Thierry Simonnet wrote: Le 03/02/2014 13:39, Thierry Simonnet a écrit : Le 03/02/2014 12:36, Eugen Dedu a écrit : On 03/02/14 10:57, Thierry Simonnet wrote: Le 01/02/2014 16:49, Eugen Dedu a écrit : Hi, If one of you knows what is the problem, it would be wonderful. Details are at http://lists.freedesktop.org/archives/gstreamer-devel/2014-January/045945.html. I was finally been able to fix the issue. C'est tout con :) I copied bin/libgstapp-1.0-0.dll only to the installer, whereas lib/libgstapp.dll must be added too!!! In fact, it is the last file which is the plugin (?!) Did you know that there are two libgstapp? In linux for ex. there is: /usr/lib/x86_64-linux-gnu/libgstapp-1.0.so.0 -- library /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstapp.so -- plugin ... Now I clean up the .exe generation, do the commit and investigate a crash related to clutter, I will keep you informed. Do you know what plugins are needed for ekiga? Otherwise said, how can we find out what plugins are needed in the following code (videooutput-manager-clutter.gst.cpp): std::ostringstream name; name std::string (appsrc) i; pipeline[i] = gst_pipeline_new (NULL); videosink = gst_element_factory_make (autocluttersink, videosink); if (videosink == NULL) videosink = gst_element_factory_make (cluttersink, videosink); g_object_set (videosink, texture, texture[i], NULL); appsrc = gst_element_factory_make (appsrc, name.str ().c_str ()); conv = gst_element_factory_make (videoconvert, NULL); We also need to check for those plugins in configure.ac, so that ekiga do not fail silently if they are not available. Yes, sure. I just thought they were standard. I think only appsrc, videoconvert (ffmpeg-based) and clutterskink are plugins. I do not find cluttersink. I will copy all gstreamer plugins for the moment, and we will see later, when it works flawlessy, what can be omitted. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Is panel section string or int?
On 25/01/14 14:46, Damien Sandras wrote: Le 24/01/14 11:21, Eugen Dedu a écrit : Choosing Chat-Call a number yields an error: (ekiga-snapshot:30055): GLib-GIO-CRITICAL **: g_settings_set_value: key 'panel-section' in 'org.gnome.ekiga-snapshot.general.user-interface.main-window' expects type 's', but a GVariant of type 'i' was given Should this key be a string or an integer? I let Damien answer and fix the issue :) I'll fix it. I'm reviewing the menu right now. Ping, seems you forgot this one :) -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Errors on Windows with clutter
I will analyse this. Perhaps it has been fixed in a newer release, I use clutter 1.14.6, because 1.16 needs a gtk newer than 3.6, currently used by ekiga because it is the recommended Windows gtk version. clutter allowed to remove a few thousands lines of ekiga code, and will be the future, so it is a very good thing! On 06/02/14 09:00, Damien Sandras wrote: Most probably you should get help from the clutter mailing list. That's sad. I introduced Clutter to simplify everything, and knowing that Clutter will finally be merged into GTK+ itself. Le 05/02/14 21:54, Eugen Dedu a écrit : I have not yet looked at the errors, here is what I obtain after finally succeeding in opening the call window on Windows. ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
On 24/01/14 12:02, Eugen Dedu wrote: On 24/01/14 10:30, Thierry Simonnet wrote: Le 24/01/2014 10:03, Eugen Dedu a écrit : On 08/01/14 16:35, Thierry Simonnet wrote: I made more tests : * I can register to ekiga.net and use it only when creating account with SIP user profile. Ekiga.net profile doesn't work. At enabling it write : processing Do you still have this error? Yes with ekiga-setup-4.1.0-git-711_gd2795be.exe ftp://simonnet:toto1...@greg.esiee.fr/../../www/archive/tmp/ekiga-win32/trunk/ekiga-setup-4.1.0-git-711_gd2795be.exe. I'm building the next package. I can register to ekiga.net using add a SIP account, but when doing this with add a ekiga.net account, process stays at processing The problem is when you create the account using Add an Ekiga.net account, it creates it as if it was an H323 account. This can be noticed when editing that account afterwards: it shows a Gatekeeper entry. I let Julien or Damien take care of this bug. Any hearty soul to take care of this? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Call history refresh
Hi, When starting ekiga and showing the call history, only one line per entry is shown (destination address). If I make a call, the call history shows two lines per entry: destination and info about the call (duration etc.) It should show all the information from the beginning. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Regression - crash when video preview is on
dconf-editor, org-gnome-ekiga-devices-video. If enable-preview is on, ekiga always crashes at startup. I think this regression was introduced with clutter changes, it is the first time I have it. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] cout in gtk-frontend
In on_history_selection_changed: std::cout menu std::endl std::flush; Is it on the TODO list? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] pixmap package name
On 01/02/14 17:09, Damien Sandras wrote: Le 26/01/14 19:58, Eugen Dedu a écrit : On 25/01/14 16:06, Damien Sandras wrote: Le 25/01/14 15:22, Eugen Dedu a écrit : On 25/01/14 14:45, Damien Sandras wrote: Le 23/01/14 14:04, Eugen Dedu a écrit : In pixmaps/Makefile.am, the word ekiga is used twice. Shouldn't PACKAGE_NAME be used instead? You can change it if you prefer. In order to have both stable and unstable packages on my machine, I change the name to ekiga-snapshot. The modification I proposed should help, in my opinion. I will do it. I have just done it. I think there is an error in pixmap/Makefile.am file: IMAGES_FILES= \ [...] inlines.h: $(IMAGE_FILES) $(nobase_dist_icon_DATA) Makefile.am Shouldn't the last line use IMAGES_FILES instead of IMAGE_FILES? There is no other IMAGE_FILES in whole ekiga code. Yes, but it raises the question : is inlines.h still used at all ? I think not... It is used in lib/gui/gmstockicons.c. What do you think, Julien? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] gstreamer error on Windows
On 03/02/14 14:07, Thierry Simonnet wrote: Le 03/02/2014 13:39, Thierry Simonnet a écrit : Le 03/02/2014 12:36, Eugen Dedu a écrit : On 03/02/14 10:57, Thierry Simonnet wrote: Le 01/02/2014 16:49, Eugen Dedu a écrit : Hi, If one of you knows what is the problem, it would be wonderful. Details are at http://lists.freedesktop.org/archives/gstreamer-devel/2014-January/045945.html. I was finally been able to fix the issue. C'est tout con :) I copied bin/libgstapp-1.0-0.dll only to the installer, whereas lib/libgstapp.dll must be added too!!! In fact, it is the last file which is the plugin (?!) Did you know that there are two libgstapp? In linux for ex. there is: /usr/lib/x86_64-linux-gnu/libgstapp-1.0.so.0 -- library /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstapp.so -- plugin ... Now I clean up the .exe generation, do the commit and investigate a crash related to clutter, I will keep you informed. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Errors on Windows with clutter
I have not yet looked at the errors, here is what I obtain after finally succeeding in opening the call window on Windows. -- Eugen attachment: a.png___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] gstreamer error on Windows
On 03/02/14 13:39, Thierry Simonnet wrote: Le 03/02/2014 12:36, Eugen Dedu a écrit : On 03/02/14 10:57, Thierry Simonnet wrote: Le 01/02/2014 16:49, Eugen Dedu a écrit : Hi, If one of you knows what is the problem, it would be wonderful. Details are at http://lists.freedesktop.org/archives/gstreamer-devel/2014-January/045945.html. I read your post, but I didn't have this error when cross compiling clutter, gstreamer, gst-plugins Could you send me version numbers of your source packages. I started with clutter 1.14 but I found that 1.16 is easier to build with compliant dependencies. The error I posted is the same error given by Ekiga: Error on initializing Clutter, or something like this. I will commit my current patch. The trouble can be libgobject. If I use the lib provided by gtk package (? - the one usually used by ekiga), I have a message that says libgstapp...dll is missing. It is mandatory to use a libgobject built against clutter, gstreamer. I attach my current Makefile, if it is useful to you, I would like to test some things before committing. -- Eugen Makefile2.gz Description: GNU Zip compressed data ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] gstreamer error on Windows
On 04/02/14 13:57, Thierry Simonnet wrote: Using your Makefile with native Win7 Professional 32bits : It compiles... but;-) Your but means that the following points do not apply to your packaging? Or do you too have them? * on console window : CRITICAL : gst_app_src_push_buffer_full: assertion `GST_APP_SRC appsrc' failed. I have not this error when using my (heavy) script. I hesitate : package version or compilation trouble. I think you have the same error, but you do not see it because you do not show the console, as I do in my Makefile. * windows with a message saying that it is unable to use accelerated video, then no display. You have the same error, doesn't you? * main frame buttons are not working (to test camera). I need to use Do you mean the toolbar (icons) in the call window? * no video (white screen) You do not have either, isn't it? * Good point : more compact package. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] gstreamer error on Windows
On 04/02/14 14:19, Thierry Simonnet wrote: Le 04/02/2014 14:13, Eugen Dedu a écrit : On 04/02/14 13:57, Thierry Simonnet wrote: Using your Makefile with native Win7 Professional 32bits : It compiles... but;-) Your but means that the following points do not apply to your packaging? Or do you too have them? I only test your version. Mine is quite different (patched version of opal and ptlib, clutter 1.16, specific addons). I will update my Makefile to make some tests. * on console window : CRITICAL : gst_app_src_push_buffer_full: assertion `GST_APP_SRC appsrc' failed. I have not this error when using my (heavy) script. I hesitate : package version or compilation trouble. I think you have the same error, but you do not see it because you do not show the console, as I do in my Makefile. I will modify my Makefile to check * windows with a message saying that it is unable to use accelerated video, then no display. You have the same error, doesn't you? I have the same error. * main frame buttons are not working (to test camera). I need to use Do you mean the toolbar (icons) in the call window? Yes. To display the video, I have to use menu. I also have the same trouble. * no video (white screen) You do not have either, isn't it? Unfortunately, yes. Could be the result of gst_app error. The question is whether your Makefile has something better compared to mine, in order to integrate those changes. It seems not. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] gstreamer error on Windows
On 04/02/14 17:15, Thierry Simonnet wrote: Le 04/02/2014 14:44, Eugen Dedu a écrit : On 04/02/14 14:19, Thierry Simonnet wrote: Le 04/02/2014 14:13, Eugen Dedu a écrit : On 04/02/14 13:57, Thierry Simonnet wrote: Using your Makefile with native Win7 Professional 32bits : It compiles... but;-) Your but means that the following points do not apply to your packaging? Or do you too have them? I only test your version. Mine is quite different (patched version of opal and ptlib, clutter 1.16, specific addons). I will update my Makefile to make some tests. * on console window : CRITICAL : gst_app_src_push_buffer_full: assertion `GST_APP_SRC appsrc' failed. I have not this error when using my (heavy) script. I hesitate : package version or compilation trouble. I think you have the same error, but you do not see it because you do not show the console, as I do in my Makefile. I will modify my Makefile to check * windows with a message saying that it is unable to use accelerated video, then no display. You have the same error, doesn't you? I have the same error. * main frame buttons are not working (to test camera). I need to use Do you mean the toolbar (icons) in the call window? Yes. To display the video, I have to use menu. I also have the same trouble. * no video (white screen) You do not have either, isn't it? Unfortunately, yes. Could be the result of gst_app error. The question is whether your Makefile has something better compared to mine, in order to integrate those changes. It seems not. Only some updated package version and the complete build of clutter. What does it mean the complete build of clutter? Your solution is far better than mine. I also adapt some things for my RD projects using a voip infrastructure. (vassist.cure.at). -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Useful files
On 26/01/14 20:30, Eugen Dedu wrote: On 25/01/14 14:45, Damien Sandras wrote: Le 23/01/14 14:21, Eugen Dedu a écrit : Are lib/gui/xvwindow.* and xwindow.* files still used/useful? I removed them. Shouldn't xwindow.[ch] be removed as well? (I see no occurrence of XWindow in other files...) Removed. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] gstreamer error on Windows
Hi, If one of you knows what is the problem, it would be wonderful. Details are at http://lists.freedesktop.org/archives/gstreamer-devel/2014-January/045945.html. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
On 29/01/14 08:25, Thierry Simonnet wrote: Le 28/01/2014 19:58, Damien Sandras a écrit : Le 28/01/14 16:32, Eugen Dedu a écrit : On 20/01/14 14:09, Thierry Simonnet wrote: Here is my script for clutter, gstreamer generation I generated an ekiga-installer.exe Remarks : * it is a little bit dirty. When linking ekiga, library from clutter-1.16 are used. I need to modify some .pc files * I tried to reduce generated code but I think it is possible to reduce more. * package size grows from 20MB to 50MB * some dll are not well included in Makefile but I work on it * I tested application with echo test. I registered on ekiga.net and on my own pbx. I have audio, video screen animation but only a white screen an no realvideo. I also be impossible to hang up the call. * when testing camera I only have a blank screen * I have a message : error when opening or initializing the video output. please verify that no other application is using the accelerated video output. No video will be displayed on your machine during this call. I succeeded in building a .exe. I have the same problem: no video shown. The call window opens and the following error is shown numerous times in the console: gst_app_src_push_buffer_full: assertion 'GST_IS_APP_SRC (appsrc)' failed Damien, do you have an idea of what could be wrong? This happens in lib/engine/components/clutter-gst-videooutput/videooutput-manager-clutter-gst.cpp I guess the appsrc object is not created. You can probably add debug code there, but I would suspect a missing GStreamer package... (appsrc for example) Damien SANDRAS *Ekiga Project* http://www.ekiga.org ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list In my case, libgstapp-1.0-0.dll is compiled, linked and present in the installation package. If not, it is impossible to launch ekiga with the following message : impossible de demarrer le programme car il manque libgstapp-1.0-0.dll (unable to launche ekiga.exe, because libgstapp is missing) I compiled gstreamer, gst-plugin-base version 1.2.2 I have that library too. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
On 29/01/14 04:05, Julien Puydt wrote: Le 28/01/2014 22:17, Eugen Dedu a écrit : Note however, I do not have any appsrc in linux, and it works. gst-inspect appsrc will tell you the AppSrc element is found in the app plugin, and locate gstapp will then show you the plugin is on your system. It shows several lines of info on linux, but on windows it generates: No such element or plugin 'appsrc' Is this a separate file or it is in libgstreamer-1.0-0.dll ? Does gstreamer-on-win32 do special things with it's base plugins compared to the gstreamer-on-others? I do not know. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
On 20/01/14 14:09, Thierry Simonnet wrote: Here is my script for clutter, gstreamer generation I generated an ekiga-installer.exe Remarks : * it is a little bit dirty. When linking ekiga, library from clutter-1.16 are used. I need to modify some .pc files * I tried to reduce generated code but I think it is possible to reduce more. * package size grows from 20MB to 50MB * some dll are not well included in Makefile but I work on it * I tested application with echo test. I registered on ekiga.net and on my own pbx. I have audio, video screen animation but only a white screen an no realvideo. I also be impossible to hang up the call. * when testing camera I only have a blank screen * I have a message : error when opening or initializing the video output. please verify that no other application is using the accelerated video output. No video will be displayed on your machine during this call. I succeeded in building a .exe. I have the same problem: no video shown. The call window opens and the following error is shown numerous times in the console: gst_app_src_push_buffer_full: assertion 'GST_IS_APP_SRC (appsrc)' failed Damien, do you have an idea of what could be wrong? Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] 2 icons in the taskbar
On 25/01/14 15:21, Eugen Dedu wrote: On 25/01/14 14:41, Damien Sandras wrote: Le 23/01/14 11:23, Eugen Dedu a écrit : When I start ekiga (the first time with gsettings on linux), the assistant opens. Is this normal? Also, I have two icons in the taskbar. Opening another window (accounts, AB etc.) does not show a third icon. I don't understand... Wouldn't it be a bug in your window manager? I don't think we can control this... Before clutter changes only one icon was shown. I will look into it. The double icon disappears if I revert the last lines of the commit https://git.gnome.org/browse/ekiga/commit/?id=e97f13bf (the changes to gtk-frontend.cpp file). -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Clutter error in virtualbox
In virtualbox ekiga stops at startup, and I have the following error in the -d 4 log: Unable to initialize Clutter: unable to find a suitable GL pixel format plus an error in shared_ptr.hpp, probably related to clutter error. Note that in virtualbox I do not have the camera available. With pre-clutter ekiga I could however start ekiga. It is very convenient for me to start ekiga in virtualbox. How can I test ekiga in virtualbox? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
On 27/01/14 09:58, Thierry Simonnet wrote: Le 25/01/2014 15:28, Eugen Dedu a écrit : On 20/01/14 14:09, Thierry Simonnet wrote: Here is my script for clutter, gstreamer generation I generated an ekiga-installer.exe Thierry, have you had a build error on clutter like this: CCLD libclutter-1.0.la .libs/clutter-event-win32.o: In function `clutter_win32_handle_event': /home/ededu/softs/ekiga/windows-svn/clutter-1.14.6/clutter/./win32/clutter-event-win32.c:373: undefined reference to `cogl_win32_renderer_handle_event' .libs/clutter-stage-win32.o: In function `clutter_stage_win32_realize': /home/ededu/softs/ekiga/windows-svn/clutter-1.14.6/clutter/./win32/clutter-stage-win32.c:488: undefined reference to `cogl_win32_onscreen_set_foreign_window' collect2: error: ld returned 1 exit status ? I have not. The trouble with clutter is coherency between ./configure and build/mingw. When using provided mingw-fetch-dependencies.sh, it get some packages with specific version. When going up, ./configure ask for more up to date version. The only way I found is using 1.16.2 ming-fetch-dependencies.sh for a 1.14.4 clutter. No very clean. I trying to find a cleaner method. I succeeded, no need to search! -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] pixmap package name
On 25/01/14 16:06, Damien Sandras wrote: Le 25/01/14 15:22, Eugen Dedu a écrit : On 25/01/14 14:45, Damien Sandras wrote: Le 23/01/14 14:04, Eugen Dedu a écrit : In pixmaps/Makefile.am, the word ekiga is used twice. Shouldn't PACKAGE_NAME be used instead? You can change it if you prefer. In order to have both stable and unstable packages on my machine, I change the name to ekiga-snapshot. The modification I proposed should help, in my opinion. I will do it. I have just done it. I think there is an error in pixmap/Makefile.am file: IMAGES_FILES= \ [...] inlines.h: $(IMAGE_FILES) $(nobase_dist_icon_DATA) Makefile.am Shouldn't the last line use IMAGES_FILES instead of IMAGE_FILES? There is no other IMAGE_FILES in whole ekiga code. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Useful files
On 25/01/14 14:45, Damien Sandras wrote: Le 23/01/14 14:21, Eugen Dedu a écrit : Are lib/gui/xvwindow.* and xwindow.* files still used/useful? I removed them. Shouldn't xwindow.[ch] be removed as well? (I see no occurrence of XWindow in other files...) -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] statusicon.cpp - taskbaricon.cpp
I propose to change the name of the file statusicon.cpp (which deals with the icon in the task bar) to something like taskbaricon.cpp. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] 2 icons in the taskbar
On 25/01/14 15:21, Eugen Dedu wrote: On 25/01/14 14:41, Damien Sandras wrote: Le 23/01/14 11:23, Eugen Dedu a écrit : When I start ekiga (the first time with gsettings on linux), the assistant opens. Is this normal? Also, I have two icons in the taskbar. Opening another window (accounts, AB etc.) does not show a third icon. I don't understand... Wouldn't it be a bug in your window manager? I don't think we can control this... Before clutter changes only one icon was shown. I will look into it. I was wrong. It is not clutter changes, but gsettings changes or some other change in the same time span. The double icon appears in Windows too. I will look into it. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] 2 icons in the taskbar
On 25/01/14 14:41, Damien Sandras wrote: Le 23/01/14 11:23, Eugen Dedu a écrit : When I start ekiga (the first time with gsettings on linux), the assistant opens. Is this normal? Also, I have two icons in the taskbar. Opening another window (accounts, AB etc.) does not show a third icon. I don't understand... Wouldn't it be a bug in your window manager? I don't think we can control this... Before clutter changes only one icon was shown. I will look into it. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] pixmap package name
On 25/01/14 14:45, Damien Sandras wrote: Le 23/01/14 14:04, Eugen Dedu a écrit : In pixmaps/Makefile.am, the word ekiga is used twice. Shouldn't PACKAGE_NAME be used instead? You can change it if you prefer. In order to have both stable and unstable packages on my machine, I change the name to ekiga-snapshot. The modification I proposed should help, in my opinion. I will do it. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] About dialog warnings
On 25/01/14 14:46, Damien Sandras wrote: Le 24/01/14 11:34, Eugen Dedu a écrit : Showing Help-About, and pressing Licence shows warnings in terminal: (ekiga-snapshot:30910): GLib-GObject-WARNING **: g_object_set_valist: object class `GtkTextTag' has no property named `font-scale' (ekiga-snapshot:30910): Gtk-CRITICAL **: gtk_text_buffer_apply_tag: assertion `tag-priv-table == buffer-priv-tag_table' failed I think it is GTK-related. As you can see in gmcallbacks.cpp, I do not use those methods myself in the code. I noticed that gtk_text_buffer_apply_tag is used in lib/gui/gm-text-buffer-enhancer.c, I thought there relies the problem. I had not time to investigate it, since I work on clutter for windows. Do you have the warning? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
On 20/01/14 14:09, Thierry Simonnet wrote: Here is my script for clutter, gstreamer generation I generated an ekiga-installer.exe Thierry, have you had a build error on clutter like this: CCLD libclutter-1.0.la .libs/clutter-event-win32.o: In function `clutter_win32_handle_event': /home/ededu/softs/ekiga/windows-svn/clutter-1.14.6/clutter/./win32/clutter-event-win32.c:373: undefined reference to `cogl_win32_renderer_handle_event' .libs/clutter-stage-win32.o: In function `clutter_stage_win32_realize': /home/ededu/softs/ekiga/windows-svn/clutter-1.14.6/clutter/./win32/clutter-stage-win32.c:488: undefined reference to `cogl_win32_onscreen_set_foreign_window' collect2: error: ld returned 1 exit status ? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] About dialog warnings
On 25/01/14 16:05, Damien Sandras wrote: Le 25/01/14 15:25, Eugen Dedu a écrit : On 25/01/14 14:46, Damien Sandras wrote: Le 24/01/14 11:34, Eugen Dedu a écrit : Showing Help-About, and pressing Licence shows warnings in terminal: (ekiga-snapshot:30910): GLib-GObject-WARNING **: g_object_set_valist: object class `GtkTextTag' has no property named `font-scale' (ekiga-snapshot:30910): Gtk-CRITICAL **: gtk_text_buffer_apply_tag: assertion `tag-priv-table == buffer-priv-tag_table' failed I think it is GTK-related. As you can see in gmcallbacks.cpp, I do not use those methods myself in the code. I noticed that gtk_text_buffer_apply_tag is used in lib/gui/gm-text-buffer-enhancer.c, I thought there relies the problem. I had not time to investigate it, since I work on clutter for windows. Do you have the warning? gm-text-buffer-enhancer.c is used for the chat window. See gmcallbacks, the code for the About dialog is only a few lines... You are right. The bug is in gtk+, https://bugzilla.gnome.org/show_bug.cgi?id=701119. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] About dialog aesthetics
On 25/01/14 14:47, Damien Sandras wrote: Le 24/01/14 11:37, Eugen Dedu a écrit : I think the ekiga icon in the dialog is too big, since it takes more than half of the dialog height (c'est moche). Also, licence text and credits text have a small font size, a bit difficult to read on my monitor. Credits text is a vertical long list, whereas the dialog has a big width because of the logo image. I have reduced the picture size. I do not control the font size myself. It is automatically handled by GTK+. Perhaps your default setup is not good? It is gtk again. The same bug https://bugzilla.gnome.org/show_bug.cgi?id=701119 shows in comment 2: g_object_set (tag, font-scale, PANGO_SCALE_SMALL, NULL); which means that it's gtk+ which reduces the text. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
On 08/01/14 16:35, Thierry Simonnet wrote: I made more tests : * I can register to ekiga.net and use it only when creating account with SIP user profile. Ekiga.net profile doesn't work. At enabling it write : processing Do you still have this error? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
On 08/01/14 20:08, Damien Sandras wrote: No more messages. but : 1. I loose my previous config and address book I wrote a .convert file. There is a conversion utility called gsettings-data-convert (see http://manpages.ubuntu.com/manpages/maverick/man1/gsettings-data-convert.1.html) Does conversion work for you? When I started ekiga with yesterday master I had no setting took from gconf. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
On 12/01/14 16:22, Julien Puydt wrote: Le 12/01/2014 14:02, Julien Puydt a écrit : I wrote and pushed a skeleton of the migrate_from_gconf method ; it lacks the strtok dirty code, but it compiles. I'll finish it some time later (it's a question of putting the old code in the FIXME hole). After a nice stroll in the nice weather, I finished the implementation of migrate_from_gconf. Now someone needs to hook it up and test it works... Does the conversion work for you? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
On 24/01/14 10:46, Thierry Simonnet wrote: Le 24/01/2014 10:06, Eugen Dedu a écrit : On 08/01/14 20:08, Damien Sandras wrote: No more messages. but : 1. I loose my previous config and address book I wrote a .convert file. There is a conversion utility called gsettings-data-convert (see http://manpages.ubuntu.com/manpages/maverick/man1/gsettings-data-convert.1.html) Does conversion work for you? When I started ekiga with yesterday master I had no setting took from gconf. Unfortunately, I do not get back my old contacts under windows. And you, Damien, Julien? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Is panel section string or int?
Choosing Chat-Call a number yields an error: (ekiga-snapshot:30055): GLib-GIO-CRITICAL **: g_settings_set_value: key 'panel-section' in 'org.gnome.ekiga-snapshot.general.user-interface.main-window' expects type 's', but a GVariant of type 'i' was given Should this key be a string or an integer? I let Damien answer and fix the issue :) -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Full screen not working in awesome
I open the call window and press F11. The video takes the whole place of the window, but the window does not change its size. There are two errors here: 1. The ratio of the video is changed, the height is greater than the width (proportionally) 2. The full screen is not full screen, but full window Note that I use awesome as window (desktop) manager. However, vlc and firefox for example go well in fullscreen. On the other hand, cheese goes in fullwindow mode the first time I press F11, subsequent F11 presses makes it enter fullscreen mode. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] About dialog warnings
Showing Help-About, and pressing Licence shows warnings in terminal: (ekiga-snapshot:30910): GLib-GObject-WARNING **: g_object_set_valist: object class `GtkTextTag' has no property named `font-scale' (ekiga-snapshot:30910): Gtk-CRITICAL **: gtk_text_buffer_apply_tag: assertion `tag-priv-table == buffer-priv-tag_table' failed -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] About dialog aesthetics
I think the ekiga icon in the dialog is too big, since it takes more than half of the dialog height (c'est moche). Also, licence text and credits text have a small font size, a bit difficult to read on my monitor. Credits text is a vertical long list, whereas the dialog has a big width because of the logo image. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
On 24/01/14 11:03, Thierry Simonnet wrote: I don't have video. Can you give me the -d 4 output when trying video? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
On 24/01/14 10:30, Thierry Simonnet wrote: Le 24/01/2014 10:03, Eugen Dedu a écrit : On 08/01/14 16:35, Thierry Simonnet wrote: I made more tests : * I can register to ekiga.net and use it only when creating account with SIP user profile. Ekiga.net profile doesn't work. At enabling it write : processing Do you still have this error? Yes with ekiga-setup-4.1.0-git-711_gd2795be.exe ftp://simonnet:toto1...@greg.esiee.fr/../../www/archive/tmp/ekiga-win32/trunk/ekiga-setup-4.1.0-git-711_gd2795be.exe. I'm building the next package. I can register to ekiga.net using add a SIP account, but when doing this with add a ekiga.net account, process stays at processing The problem is when you create the account using Add an Ekiga.net account, it creates it as if it was an H323 account. This can be noticed when editing that account afterwards: it shows a Gatekeeper entry. I let Julien or Damien take care of this bug. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] XML in schema in Windows
Looking at an XML entry for example in Windows I see squares between keys, which is confusing. The square surely is for \n, whereas Windows uses \r\n. I wonder if we can use \r\n on Windows; I do not know if values can have \r\n in Windows, do you know? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
Is it the whole script or are some piees missing? Why do you use both clutter 1.16 and 1.14? On 20/01/14 14:09, Thierry Simonnet wrote: Here is my script for clutter, gstreamer generation I generated an ekiga-installer.exe Remarks : * it is a little bit dirty. When linking ekiga, library from clutter-1.16 are used. I need to modify some .pc files * I tried to reduce generated code but I think it is possible to reduce more. * package size grows from 20MB to 50MB * some dll are not well included in Makefile but I work on it * I tested application with echo test. I registered on ekiga.net and on my own pbx. I have audio, video screen animation but only a white screen an no realvideo. I also be impossible to hang up the call. * when testing camera I only have a blank screen * I have a message : error when opening or initializing the video output. please verify that no other application is using the accelerated video output. No video will be displayed on your machine during this call. On 01/13/2014 10:30 PM, Chris Vine wrote: On Mon, 13 Jan 2014 20:18:49 +0100 Damien Sandras dsand...@seconix.com wrote: Ouch... Before porting, I read that there were available packages for WIN32 and other platforms. Clutter-GST is the GStreamer Clutter backend. I think it is part of GStreamer itself. No. You can get it from http://ftp.gnome.org/pub/gnome/sources/clutter-gst/2.0/ Since both clutter and gstreamer will reputedly compile on windows, it is a reasonable bet that clutter-gst will too. But the proof of the pudding is in the eating. ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] FIXME in the code
I have finally found the time to build the latest code. On execution, I have: snoopy:~$ ekiga-snapshot FIXME: where is H323 Is this normal? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] 2 icons in the taskbar
When I start ekiga (the first time with gsettings on linux), the assistant opens. Is this normal? Also, I have two icons in the taskbar. Opening another window (accounts, AB etc.) does not show a third icon. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Make preferences window non-modal
I have call window open. When I open preferences, it is modal, which prevents me to use the menu in call window. Is there any reason to have preferences window modal? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Enable PIP is shown twice
Hi, Enable PIP mode preference is found both in Preferences and in Video menu of the call window. I think it is an error to present the same configuration option in two different places, better show it only in Video menu of the call window. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Default device does not work
By default (running ekiga without any configuration done), on my linux it took as video device MovingLogo instead of ...PTLIB/V4L2. I will look into this bug if nobody pops up. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Video size names
In Preferences window, video tab, Size option I see: small medium medium 480p 4:3 HD dvd For heteregenity reasons, I think the 4th one should be changed to something like large - 480p 4:3 HD. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Useful files
Are lib/gui/xvwindow.* and xwindow.* files still used/useful? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
On 07/01/14 19:30, Damien Sandras wrote: Perhaps this should help : https://mail.gnome.org/archives/gtk-list/2011-April/msg00094.html Of course, schema compilation and installation should be automated. A bug in the Makefile ? I added code to recompile schema, https://git.gnome.org/browse/ekiga/commit/?id=337eb223b. Le 07/01/14 11:38, Thierry Simonnet a écrit : I generated a win32 package and have the following message (ekiga.exe:8364):GLib-GIO-ERROR **: Settings schema 'org.gnome.ekiga.general.user-interface.video-display' is not installed Any idea? -- Thierry Simonnet ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] gsettings trouble
On 13/01/14 20:08, Julien Puydt wrote: Le 13/01/2014 13:05, Eugen Dedu a écrit : On 07/01/14 10:15, Julien Puydt wrote: Le 07/01/2014 09:52, Thierry Simonnet a écrit : I manually corrected this trouble adding -lgio-2.0 in GLIB_LIBS in ekiga/plugins/ldap/Makefile The correct fix is probably to change the PKG_CHECK_MODULES line for glib in configure.ac... Julien, I do not understand: - why do you point on configure.ac, whose role is only to check that all libraries are there (and not to add -lgio) The configure.ac file sets GLIB_LIBS to what is needed, so if you want to change that, that is the correct place. Ok, I have fixed it as you proposed. - why in linux this error does not appear Good question! -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio
On 20/01/14 14:21, Eugen Dedu wrote: Good, thank you. I will use them when I do the official commit. Eugen On 20/01/14 14:09, Thierry Simonnet wrote: Here is my script for clutter, gstreamer generation I generated an ekiga-installer.exe Remarks : * package size grows from 20MB to 50MB This is surely because they are not stripped... -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] gsettings trouble
On 13/01/14 20:08, Julien Puydt wrote: Le 13/01/2014 19:57, Eugen Dedu a écrit : On 13/01/14 13:05, Eugen Dedu wrote: On 07/01/14 10:15, Julien Puydt wrote: Le 07/01/2014 09:52, Thierry Simonnet a écrit : I manually corrected this trouble adding -lgio-2.0 in GLIB_LIBS in ekiga/plugins/ldap/Makefile The correct fix is probably to change the PKG_CHECK_MODULES line for glib in configure.ac... Julien, I do not understand: - why do you point on configure.ac, whose role is only to check that all libraries are there (and not to add -lgio) - why in linux this error does not appear I notice that the error appears on linux too... Don't you have it too, Julien and Damien?? Is it fixed with current master (so that I do not bother)? I don't have the problem... Do you have -lgio which gets added when you build plugins? What does snoopy:~$ grep lgio /usr/lib/x86_64-linux-gnu/pkgconfig/*pc snoopy:~$ grep lgio /usr/lib/pkgconfig/*pc show? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] gsettings trouble
On 07/01/14 10:15, Julien Puydt wrote: Le 07/01/2014 09:52, Thierry Simonnet a écrit : I manually corrected this trouble adding -lgio-2.0 in GLIB_LIBS in ekiga/plugins/ldap/Makefile The correct fix is probably to change the PKG_CHECK_MODULES line for glib in configure.ac... Julien, I do not understand: - why do you point on configure.ac, whose role is only to check that all libraries are there (and not to add -lgio) - why in linux this error does not appear -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
