Re: [Ekiga-devel-list] Re: On rewriting the text chat stack

Hi, Le 17/11/2015 17:13, Julien Puydt a écrit : Le mardi 17 nov. 2015 à 11:18:16 (+0100), Eugen Dedu a écrit : 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. Well, I

Re: [Ekiga-devel-list] On rewriting the text chat stack

Hi, Le mardi 17 nov. 2015 à 11:18:16 (+0100), Eugen Dedu a écrit : > 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. Well, I started to write some code. There needs

[Ekiga-devel-list] Fwd: Daniel Pocock: debian.org RTC: announcing XMPP, SIP presence and more

Hi, the below blog post is interesting. Snark PS1: I still haven't written code for the chat, but I have looked at the ptlib api and thought about it. PS2: the message Message transféré From: Planet Debian To: Planet Debian Date:

Re: [Ekiga-devel-list] On rewriting the text chat stack

Hi, Le 16/10/2015 18:36, Eugen Dedu a écrit : Thanks, Julien, if you could implement the chat, right now it is the only important regression I think (compared to v4). In which chat was pretty bad... First of all, I think it is essential to implement ONLY ONE METHOD, completely and bug-free,

Re: [Ekiga-devel-list] ekiga chat - Suggestion -> LINE

Le 10/10/2015 05:35, a a écrit : Don't forget Naver's LINE: http://line.me/en/ This program doesn't even have a linux version yet! Does it have an open protocol which might make it relevant in this discussion ? Snark ___ ekiga-devel-list mailing

[Ekiga-devel-list] On rewriting the text chat stack

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

Re: [Ekiga-devel-list] Design of the engine : why abstract Ekiga::Foo and Ekiga::FooImpl matter

Hi, Le 14/01/2015 10:32, Eugen Dedu a écrit : On 14/01/15 08:43, Julien Puydt wrote: 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

[Ekiga-devel-list] Design of the engine : LiveObject and MenuBuilder aren't bad

Hi, this mail starts by explaining why I chose to make Ekiga::LiveObject have a single populate_menu taking an Ekiga::MenuBuilder method, instead of having the action system as now found in lib/engine/action, and comments (and questions and ideas) on that new system. When I wrote the menu

[Ekiga-devel-list] Lecture de lib/engine/action/

Hi, I finally found some time for ekiga yesterday evening and this morning. It turns out my chat_opal_v314 branch was dead : it didn't rebase cleanly and anyway it was not working and I don't remember anything about it. I'll just start from scratch. I saw my loudmouth code didn't compile

Re: [Ekiga-devel-list] Lecture de lib/engine/action/

Le 05/01/2015 11:46, Damien Sandras a écrit : (6) The fact that a base class isn't purely virtual is annoying... In the rest of the engine, a base class Ekiga::Foo is purely virtual for 100% of cases, and an Ekiga::FooImpl is provided with an implementation to cover 99% of use cases. Don't get

Re: [Ekiga-devel-list] Actually using the friend-or-foe code

Hi, Le 22/06/2014 11:03, Julien Puydt a écrit : (1) make the call core reject foes ; (2) add a blacklisting delegate ; (4) add a blacklist button to the call popup ; (5) add a blacklist action to the call history items (if they're currently unknown) ; (6) add some way to edit the blacklist

[Ekiga-devel-list] Actually using the friend-or-foe code

Hi, let me start by reminding what friend-or-foe is about: when a call (or a message) comes in, the system classifies the event as unknown, foe, neutral or friend. The goal is then to use the classification to reject, ask the user or auto-accept the call. The current code has: - a central

Re: [Ekiga-devel-list] Using gstreamer for everything audio and video in ekiga

Hi, Le 23/04/2014 18:28, Eugen Dedu a écrit : On 22/04/14 15:16, Julien Puydt wrote: 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

Re: [Ekiga-devel-list] Using gstreamer for everything audio and video in ekiga

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

Re: [Ekiga-devel-list] Static source code analysis of ekiga

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

Re: [Ekiga-devel-list] Static source code analysis of ekiga

Le 14/04/2014 21:06, John Smith a écrit : On Mon, Apr 14, 2014 at 8:27 PM, Julien Puydt jpu...@free.fr wrote: I pushed a commit to fix those in ekiga... I'm actually quite surprised there was so little to complain about! Cool. 'cppcheck' hasnt got much more to complain about either: http

Re: [Ekiga-devel-list] About GUDev in ekiga

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

Re: [Ekiga-devel-list] ptlib/opal v14 news

Le 03/03/2014 11:38, Eugen Dedu a écrit : 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 It's still a good start!

[Ekiga-devel-list] About GUDev in ekiga

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

[Ekiga-devel-list] Call history view bug, GmCellRendererBitext and gtk+

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

Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio

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

Re: [Ekiga-devel-list] Roster groups

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

Re: [Ekiga-devel-list] Roster groups

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

Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio

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

Re: [Ekiga-devel-list] Roster groups

Le 17/02/2014 08:34, Julien Puydt a écrit : And one bad news: I clicked on the video preview button, which made ekiga crash. Now it's crashing on every restart because it tries to set that up ; I have clues what happens and will investigate. My clues were wrong :-/ It crashes in clutter

Re: [Ekiga-devel-list] pixmap package name

Le 06/02/2014 21:42, Eugen Dedu a écrit : What do you think, Julien? That I don't know... Snark ___ 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

Le 28/01/2014 19:58, Damien Sandras a écrit : I don't remember why that code is like that. Feel free to fix ! Done. Snark ___ 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

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. Does gstreamer-on-win32 do special things

Re: [Ekiga-devel-list] About dialog warnings

On 01/25/2014 03:25 PM, Eugen Dedu wrote: 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'

Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio

Le 08/01/2014 13:35, Thierry Simonnet a écrit : 1. I loose my previous config and address book Sorry to answer this late, but we don't have anything to push forward the previous config... the only thing we have is for the accounts, and I think it's only for configuration which was in gconf --

Re: [Ekiga-devel-list] [Win32] gsettings trouble

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

Re: [Ekiga-devel-list] [Win32] gsettings trouble

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

Re: [Ekiga-devel-list] Broken compilation

Le 11/01/2014 19:38, Julien Puydt a écrit : Le 10/01/2014 21:35, Eugen Dedu a écrit : ekiga-config-tool has been removed, see https://git.gnome.org/browse/ekiga/commit/?id=c0c65ccbdd0. bin_SCRIPTS has been removed in that commit, you have something wrong in your repository in my opinion

Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio

Le 10/01/2014 19:19, Julien Puydt a écrit : I'll write the migrate method in that case; it would take a std::liststd::string and return void -- or do we want to do something on error? It will take a few days : the little spare time I have in the coming days will be used to work on a few

Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio

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

Re: [Ekiga-devel-list] Broken compilation

Le 10/01/2014 21:35, Eugen Dedu a écrit : ekiga-config-tool has been removed, see https://git.gnome.org/browse/ekiga/commit/?id=c0c65ccbdd0. bin_SCRIPTS has been removed in that commit, you have something wrong in your repository in my opinion. I cloned it anew and end up in the same bad

Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio

Le 10/01/2014 12:49, Damien Sandras a écrit : Le 09/01/14 06:49, Julien Puydt a écrit : Le 08/01/2014 20:08, Damien Sandras a écrit : The annoying thing is that we changed the way Accounts are stored and there is currently no way to convert from the old format to the new one. I talked

[Ekiga-devel-list] Broken compilation

Hi, is it normal that I had to do the following in src/Makefile.am to avoid a compilation error: -bin_SCRIPTS = ekiga-config-tool +#bin_SCRIPTS = ekiga-config-tool ? Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org

Re: [Ekiga-devel-list] Broken compilation

Le 10/01/2014 21:18, Julien Puydt a écrit : Hi, is it normal that I had to do the following in src/Makefile.am to avoid a compilation error: -bin_SCRIPTS = ekiga-config-tool +#bin_SCRIPTS = ekiga-config-tool ? Ah, that fixes the compilation, but doesn't make it run : (lt-ekiga:7620

Re: [Ekiga-devel-list] [Win32] Trouble with glib/gio

Le 08/01/2014 20:08, Damien Sandras a écrit : The annoying thing is that we changed the way Accounts are stored and there is currently no way to convert from the old format to the new one. I talked to Julien about that, but I do not know if he intends doing something for it or not. Julien, can

Re: [Ekiga-devel-list] [Win32] gsettings trouble

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... Snark ___

Re: [Ekiga-devel-list] Strange critical warning in ekiga

On 12/20/2013 08:41 PM, Eugen Dedu wrote: On 24/07/13 18:48, Julien Puydt wrote: On Wed, 24 Jul 2013 05:36:28 +0200 Eugen Dedu eugen.d...@pu-pm.univ-fcomte.fr wrote: On 22/06/13 09:54, Julien Puydt wrote: Le 19/06/2013 15:29, Julien Puydt a écrit : And I also have a ton of: GLib-GObject

Re: [Ekiga-devel-list] [Win32] Last modifications

Le 17/09/2013 10:22, Julien Puydt a écrit : Le 16/09/2013 16:00, Thierry Simonnet a écrit : from ../lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp:38: What happens if you add a #include runtime.h to lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp ? I just

Re: [Ekiga-devel-list] [Win32] Last modifications

Hi, Le 16/09/2013 16:00, Thierry Simonnet a écrit : Hello, I applied the last modifications from git. The trace you give point to ptlib headers ; you updated them also, didn't you? Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org

Re: [Ekiga-devel-list] Missing menu in the main window

Le 12/08/2013 11:28, Eugen Dedu a écrit : On 11/08/13 21:21, Julien Puydt wrote: Hi, in the main window, we used to have a menu for actions coming from the cores (most notably the contact and presence cores). This was fixing #564831 and #548952. The function which was responsible

Re: [Ekiga-devel-list] Missing menu in the main window

Le 12/08/2013 12:04, Eugen Dedu a écrit : I do not remember of any lost menu... What did it contain? How was it called? I added it with f548626c9cef1d4326d5daa0f8e682ef5bebda61, and removed it with 9c6c48f0cc73c4cb41b9cd9de94c7d44d9d3e95a. Perhaps I should add it back, but this time live :-/

Re: [Ekiga-devel-list] Missing menu in the main window

Le 12/08/2013 12:45, Eugen Dedu a écrit : On 12/08/13 12:40, Julien Puydt wrote: Le 12/08/2013 12:04, Eugen Dedu a écrit : I do not remember of any lost menu... What did it contain? How was it called? I added it with f548626c9cef1d4326d5daa0f8e682ef5bebda61, and removed

[Ekiga-devel-list] Missing menu in the main window

Hi, in the main window, we used to have a menu for actions coming from the cores (most notably the contact and presence cores). This was fixing #564831 and #548952. The function which was responsible for that is on_some_core_updated in main_window.cpp. Unfortunately, this function does

Re: [Ekiga-devel-list] Strange critical warning in ekiga

Le 19/06/2013 15:29, Julien Puydt a écrit : And I also have a ton of: GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed but I have no clue where they happen... the trace only says it's in the gtk+ main loop... :-/ Am I the only one to get them? Snark

[Ekiga-devel-list] Strange FIXME in the call window sources

Hi, I have been playing again with ekiga's code recently, and trying to have a look at FIXME items in the code ; that one has me really puzzled: lib/engine/gui/gtk-frontend/call-window.cpp:759://FIXME Set_stay_on_top window_show object The lines before and after don't give a clue what this

[Ekiga-devel-list] Strange critical warning in ekiga

Hi, since I restarted toying around, I noticed the following critical warning: (ekiga:15134): GLib-CRITICAL **: g_sequence_iter_get_position: assertion `iter != NULL' failed Program received signal SIGTRAP, Trace/breakpoint trap. 0x74dc217d in g_logv () from

Re: [Ekiga-devel-list] Strange critical warning in ekiga

Le 19/06/2013 15:27, Eugen Dedu a écrit : On 19/06/13 15:24, Julien Puydt wrote: since I restarted toying around, I noticed the following critical warning: (ekiga:15134): GLib-CRITICAL **: g_sequence_iter_get_position: assertion `iter != NULL' failed Program received signal SIGTRAP, Trace

[Ekiga-devel-list] Debian GSoC on Enabling free multimedia real-time communications (RTC) with Debian

Hi, would that concern ekiga too: http://wiki.debian.org/SummerOfCode2013/StudentApplications/CatalinUsurelu ? Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] Gstreamer in ekiga

Le 28/03/2013 07:48, Genghis Khan a écrit : Is there a discussion about this issue at GStreamer mailing list concerning to Ekiga? No. There is: https://bugzilla.gnome.org/show_bug.cgi?id=678402 The other projects just use gudev to learn about devices. But that's linux-only : we would lose

Re: [Ekiga-devel-list] Gstreamer in ekiga

Le 22/03/2013 18:47, Peter Robinson a écrit : On 22 Mar 2013 17:44, Julien Puydt jpu...@free.fr mailto:jpu...@free.fr wrote: Le 22/03/2013 18:31, Peter Robinson a écrit : Is it with gst 0.10 or 1.0? 0.10 It would be worth to move it to 1.0 as that's where most distros are going

Re: [Ekiga-devel-list] Ekiga Port

Le 21/03/2013 14:47, Eugen Dedu a écrit : On 21/03/13 12:34, Julien Puydt wrote: Le 18/03/2013 09:34, Damien Sandras a écrit : Le 17/03/13 20:59, Julien Puydt a écrit : GSettings is part of glib, so it should be available everywhere it is. And gmconf is mostly an api, with two

[Ekiga-devel-list] Gstreamer in ekiga

Hi, since a few weeks, the experimental gstreamer code in ekiga is supposed to work much better. Could you give it a try? I would like to rework the audio+video code to shoot for more features. Snark ___ ekiga-devel-list mailing list

Re: [Ekiga-devel-list] Gstreamer in ekiga

Le 22/03/2013 18:31, Peter Robinson a écrit : Is it with gst 0.10 or 1.0? 0.10 Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] Gstreamer in ekiga

Le 22/03/2013 18:16, Eugen Dedu a écrit : On 22/03/13 18:14, Julien Puydt wrote: since a few weeks, the experimental gstreamer code in ekiga is supposed to work much better. Could you give it a try? I would like to rework the audio+video code to shoot for more features. Does it work on your

Re: [Ekiga-devel-list] Ekiga Port

Le 18/03/2013 09:34, Damien Sandras a écrit : Le 17/03/13 20:59, Julien Puydt a écrit : GSettings is part of glib, so it should be available everywhere it is. And gmconf is mostly an api, with two implementations : - a glib one (used on win32 -- in fact made the port possible) ; - a gconf one

Re: [Ekiga-devel-list] Ekiga Port

Le 17/03/2013 17:56, Damien Sandras a écrit : I have started GSettings migration in a ds-gsettings branch. Feel free to help. Did you start by putting GSettings below gmconf, then replacing each and every use of gmconf by GSettings? Snark ___

Re: [Ekiga-devel-list] Ekiga Port

Le 17/03/2013 18:29, Damien Sandras a écrit : Le 17/03/13 18:13, Julien Puydt a écrit : Le 17/03/2013 17:56, Damien Sandras a écrit : I have started GSettings migration in a ds-gsettings branch. Feel free to help. Did you start by putting GSettings below gmconf, then replacing each and every

[Ekiga-devel-list] Another try at gstreamer in ekiga

Hi, I'm trying again to make audio output work with ekiga. The current situation is: - it works for sound events ; - it doesn't work during calls ; The reason for the difference is that during sound events, the sound format is supposed to be : audio/x-raw-int, rate=44100, channels=2,

Re: [Ekiga-devel-list] Another try at gstreamer in ekiga

Le 22/02/2013 06:11, Craig Southeren a écrit : If you are reading from any input device, that device must block for the appropriate amount of time. The problem is about audio output, not input (yet). I push data in gstreamer as fast as ptlibopal push it to my code :-/ Snark

Re: [Ekiga-devel-list] Another try at gstreamer in ekiga

Le 22/02/2013 06:11, Craig Southeren a écrit : On write, the timing will be provided by the incoming RTP data or the jitter buffer, depending on which type of media you are using. I push data as I receive it on a set_frame_data method: bool GST::AudioOutputManager::set_frame_data

Re: [Ekiga-devel-list] Another try at gstreamer in ekiga

Le 22/02/2013 07:41, Julien Puydt a écrit : Le 22/02/2013 06:11, Craig Southeren a écrit : On write, the timing will be provided by the incoming RTP data or the jitter buffer, depending on which type of media you are using. I push data as I receive it on a set_frame_data method: bool GST

Re: [Ekiga-devel-list] Another try at gstreamer in ekiga

Le 22/02/2013 06:04, Julien Puydt a écrit : He made those computations at an advanced hour of the night though, so I'll have to double-check. I haven't seen him since, but according to the logs the first queued buffer is at 13.407539048, the last one at 17.823645673 ; grep says

Re: [Ekiga-devel-list] What's missing for 4.0.1

Le 18/02/2013 21:28, Peter Robinson a écrit : https://bugzilla.redhat.com/show_bug.cgi?id=912503 Could it be that one of the evolution headers contains a G_BEGIN_DECL, but miss the G_END_DECL or something like this? What happens if you shuffle the order of the #include lines in

Re: [Ekiga-devel-list] What's missing for 4.0.1

Le 19/02/2013 18:36, Peter Robinson a écrit : well gcc 4.8 is in regressions only and the developers believe it's pretty close to final so if it's a change there it's a reason for it, it could be boost. I'm can cope with it waiting for 4.0.2 but be aware people that are using rawhide are already

Re: [Ekiga-devel-list] What's missing for 4.0.1

Le 13/02/2013 10:20, Eugen Dedu a écrit : On 13/02/13 10:18, Peter Robinson wrote: Hasn't the freeze on Windows bug been around for ages? If so I think Indeed, but we are very near to fix it. Does that mean you are about to give me a golden hint on what exactly is freezing? Snark

[Ekiga-devel-list] What's missing for 4.0.1 ?

Hi, what are the showstoppers for 4.0.1 ? Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] What's missing for 4.0.1

Le 12/02/2013 21:11, Julien Puydt a écrit : what are the showstoppers for 4.0.1 ? Sorry for the double post : I had forgotten the '?' and thought I had managed to cancel this post :-/ Snark ___ ekiga-devel-list mailing list ekiga-devel-list

Re: [Ekiga-devel-list] What's missing for 4.0.1

Le 12/02/2013 21:16, Eugen Dedu a écrit : - freeze on quit on windows For that one, if it's still there after all I have done... I'll definitely need a nice -d 4 and a good stacktrace :-/ Snark ___ ekiga-devel-list mailing list

Re: [Ekiga-devel-list] Recent changes to the opal code

Le 11/02/2013 19:13, Eugen Dedu a écrit : - for windows the freeze is still there, at the same place (win32.cxx:1146). I really think that this is a Windows port specific issue If we don't have a good backtrace, I don't see how to track that down :-/ Snark

[Ekiga-devel-list] Uses of the sip endpoint in the opal account code

Hi, I have just hidden the H323 endpoint below the opal call manager, meaning that now the account code asks the call manager to do the presence subscribing/unsubscribing, and it's the call manager which does the forwarding of the request to the right protocol endpoint. I can't do the same

Re: [Ekiga-devel-list] Uses of the sip endpoint in the opal account code

Le 08/02/2013 16:11, Julien Puydt a écrit : Hi, I have just hidden the H323 endpoint below the opal call manager, meaning that now the account code asks the call manager to do the presence subscribing/unsubscribing, and it's the call manager which does the forwarding of the request

Re: [Ekiga-devel-list] Recent changes to the opal code

Le 06/02/2013 15:10, Julien Puydt a écrit : Le 06/02/2013 13:07, Eugen Dedu a écrit : On 06/02/13 12:51, Julien Puydt wrote: - have removed the crash-on-exit ; Do you speak about the crash on Windows? I can't test that, but the crash on linux is gone for me (but not for Damien apparently

[Ekiga-devel-list] Recent changes to the opal code

Hi, the recent changes to the opal code : - have removed the crash-on-exit ; - made sure no Ekiga::Service is leaked on exit. This code is still in need of restructuring in various places, but at least it should work well enough. I'll wait a few days for feedback before I start another

Re: [Ekiga-devel-list] Code in lib/engine/components/opal/

Le 31/01/2013 10:32, Eugen Dedu a écrit : Instead of dialect, couldn't we use Chat or IM? IM is too short, and we already use Chat for an ongoing discussion (in the form of Ekiga::SimpleChat and Ekiga::MultipleChat... I hate those names :-/ ) Snark

Re: [Ekiga-devel-list] Code in lib/engine/components/opal/

Le 31/01/2013 10:49, Eugen Dedu a écrit : On 31/01/13 10:42, Julien Puydt wrote: Le 31/01/2013 10:32, Eugen Dedu a écrit : Instead of dialect, couldn't we use Chat or IM? IM is too short, and we already use Chat for an ongoing discussion (in the form of Ekiga::SimpleChat and Ekiga

Re: [Ekiga-devel-list] Challenges for generation of Ekiga 4.x

Le 01/02/2013 08:56, Markus Elfring a écrit : Those symbols are supposed to come from ffmpeg. I know that ... ;-) https://sourceforge.net/tracker/?func=detailatid=989748aid=3602510group_id=204472 When I can not change the reused source files directly, I'll have to extend/adapt my build

Re: [Ekiga-devel-list] Challenges for generation of Ekiga 4.x

Le 30/01/2013 22:22, Markus Elfring a écrit : If your kdevelop uses gcc 4.4.1, then this could easily be explained, since recent gcc have become stricter and stricter about the C syntax. No - This integrated development environment calls just the compiler version (g++ 4.7.1) that is provided

[Ekiga-devel-list] Code in lib/engine/components/opal/

Hi, I just had a deeper look at what the code in this directory does (and commit something which shouldn't change things much, we just use Ekiga::ServiceCore only at startup). In Opal::Sip::EndPoint::update_bank, I see that the endpoint is connecting to Opal::Bank's signals to know what

Re: [Ekiga-devel-list] Code in lib/engine/components/opal/

Le 28/01/2013 10:24, Julien Puydt a écrit : The current memory handling is also unsatisfying (cf opal-main.cpp), since we put the endpoints in boost shared pointers, but with a null_deleter, which means we don't really manage them. This hits the current ekiga master : as Damien noted

Re: [Ekiga-devel-list] Code in lib/engine/components/opal/

Le 28/01/2013 11:21, Craig Southeren a écrit : On 28/01/2013, at 8:43 PM, Julien Puydtjpu...@free.fr wrote: ...deleted From what I saw in the opal headers: - when we create an endpoint, it automatically gets registered to the call manager (and we can't prevent that) ; - the call manager

Re: [Ekiga-devel-list] Code in lib/engine/components/opal/

Le 28/01/2013 10:24, Julien Puydt a écrit : - Opal::Bank should become Ekiga::PresentityDecorator+Ekiga::ContactDecorator, and when one of the populate_menu methods gets called, loop on the account, and call their own populate_menu methods, which will then call a method in the endpoint, which

[Ekiga-devel-list] New gobject warning

Hi, I noticed the following this morning (latest master): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed Isn't this new? Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org

Re: [Ekiga-devel-list] Real Issue is Opal::Call virtual table missing

Le 15/01/2013 21:18, Lorin Melander a écrit : I use your latest patch and I run the test. here new result file. Where is the crash? Does that mean the problem is solved? Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org

Re: [Ekiga-devel-list] Leaked services on shutdown

Le 14/01/2013 12:00, Eugen Dedu a écrit : On 13/01/13 21:31, Julien Puydt wrote: Le 13/01/2013 20:18, Julien Puydt a écrit : I haven't found where it is leaked yet ; some further debugging showed that it's a single dangling reference :-/ I have found what leaked it, found what leaked what

Re: [Ekiga-devel-list] Leaked services on shutdown

Le 14/01/2013 12:13, Eugen Dedu a écrit : On 14/01/13 12:07, Julien Puydt wrote: Le 14/01/2013 12:00, Eugen Dedu a écrit : On 13/01/13 21:31, Julien Puydt wrote: Le 13/01/2013 20:18, Julien Puydt a écrit : I haven't found where it is leaked yet ; some further debugging showed that it's

Re: [Ekiga-devel-list] Real Issue is Opal::Call virtual table missing

Le 07/01/2013 16:22, Lorin Melander a écrit : I observed the Virtual Table of Opal::Call is missing at second answer or hungup. Here is another patch to test : this makes sure we keep references to calls in the actions. I think I'll commit that one even if it doesn't fix the problem at hand.

[Ekiga-devel-list] Leaked services on shutdown

Hi, I just committed some more debugging code to the service core : now at shutdown, after it released services (which is supposed to trigger their destruction), it tries to see if some are still there, and prints their names (of course, you have to set DEBUG to 1 at the start of

Re: [Ekiga-devel-list] Leaked services on shutdown

Le 13/01/2013 17:13, Julien Puydt a écrit : On my system, it shows the service named videooutput-core isn't freed correctly. I haven't found where it is leaked yet ; some further debugging showed that it's a single dangling reference :-/ Snark

Re: [Ekiga-devel-list] Leaked services on shutdown

Le 13/01/2013 20:18, Julien Puydt a écrit : I haven't found where it is leaked yet ; some further debugging showed that it's a single dangling reference :-/ I have found what leaked it, found what leaked what leaked it, and finally what leaked what leaked what leaked it, and fixed the whole

[Ekiga-devel-list] Code cleaning

Hi, I tried to make some old cruft either disappear or go to another place this evening. I noticed that : - dbus.cpp does smart things with the main window instead of just calling gm_window_show ; - assistant.cpp calls gtk_widget_show on the main window instead of just calling

Re: [Ekiga-devel-list] Real Issue is Opal::Call virtual table missing

Le 11/01/2013 20:18, Lorin Melander a écrit : I run with new patch. here new result. The object call still is lost. Sigh... Let's try with a variant of the first patch :-/ Snark diff --git a/plugins/libnotify/libnotify-main.cpp b/plugins/libnotify/libnotify-main.cpp index b4ea8f2..dd04aa0

Re: [Ekiga-devel-list] Real Issue is Opal::Call virtual table missing

Le 11/01/2013 20:47, Lorin Melander a écrit : I got reject from the new patch You have to unapply the first version before applying the second. Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org

Re: [Ekiga-devel-list] Real Issue is Opal::Call virtual table missing

Le 11/01/2013 21:03, Lorin Melander a écrit : to apply patch patch 1Np patch file patch -p1 /path/to/patch to unapply patch patch 1Rp patch file patch -R -p1 /path/to/patch Beware I gave the second patch file the same name as the first. Snark

Re: [Ekiga-devel-list] Real Issue is Opal::Call virtual table missing

Le 11/01/2013 21:33, Lorin Melander a écrit : patch -R -p1 libnotify-main.cpp libnotify_fix_for_wrong_use_of_get_on_smart_pointer.patch (Stripping trailing CRs from patch.) patching file libnotify-main.cpp patch -p1 libnotify-main.cpp patchfile2 (Stripping trailing CRs from patch.) patching

Re: [Ekiga-devel-list] Real Issue is Opal::Call virtual table missing

Le 11/01/2013 22:07, Lorin Melander a écrit : I modify the libnotify-main.cp by reading the patch. How would I can verify patch is match expected? Does it compile? Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org

  1   2   3   4   5   >