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

[Julien Puydt]

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 started to write some code. There needs three stages :
- an engine framework (abstract) ;


I have something for that, which is mostly what used to be there...


- an opal implementation (concrete) ;


I'm working on that part now, and I have a question: what goes in the 
process/ subdirectory of lib/engine/components/opal/ ?



- a GUI (concrete).


Nothing done on that part, even though I keep it in mind.

Cheers,

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

[Julien Puydt]

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 three stages :
- an engine framework (abstract) ;
- an opal implementation (concrete) ;
- a GUI (concrete).

I know what to write for the first stage, I have started reading the 
opal code in ekiga to find out what to write for the second stage, and I 
have no clue yet for the third stage. I only saw there was no heap 
widget... But for a first simple run, we can probably get away without 
it.

It's slow, but I have my hands full...

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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:   Mon, 09 Nov 2015 08:57:17 +0100
X-Feed2Imap-Version:1.2.5
Message-Id: 
Subject:Daniel Pocock: debian.org RTC: announcing XMPP, SIP presence
and more
Content-Type:   multipart/related; type="multipart/alternative";
boundary="=-1447059604-756562-14095-7398-3-="
MIME-Version:   1.0



*Feed:* *Planet Debian* 
*Item:* *Daniel Pocock: debian.org RTC: announcing XMPP, SIP presence
and more*
 




/Announced 7 November 2015

on the debian-devel-announce mailing list
./

The Debian Project now has an XMPP service available to all Debian
Developers. Your Debian.org email identity can be used as your XMPP address.

The SIP service has also been upgraded and now supports presence. SIP
and XMPP presence, rosters and messaging are not currently integrated.

The Lumicall app has been improved to enable rapid setup for Debian.org
SIP users
.

This announcement concludes the maintenance window on the RTC services.
All services are now running on jessie (using packages from
jessie-backports).

XMPP and SIP enable a whole new world of real-time multimedia
communications possibilities: video/webcam, VoIP, chat messaging,
desktop sharing and distributed, federated communication are the most
common use cases.

Details about how to get started and get support are explained in the
User Guide

in the Debian wiki. As it is a wiki, you are completely welcome to help
it evolve.

Several of the people involved in the RTC team
 were also at the Cambridge
mini-DebConf (7-8 November)
.

The password for all these real time communication services can be set
via the LDAP control panel . Please
note that this password needs to be different to any of your other
existing debian.org passwords. Please use a strong password and please
keep it secure.

Some of the infrastructure, like the TURN server, is shared by clients
of both SIP and XMPP. Please configure your XMPP and SIP clients to use
the TURN server for audio or video streaming to work most reliably
through NAT.

A key feature of both our XMPP and SIP services is that they support
federated inter-connectivity with other domains. Please try it. The
FedRTC service for Fedora developers  is one example
of another SIP service that supports federation. For details of how it
works and how we establish trust between domains, please see the RTC
Quick Start Guide . Please reach out to other
communities you are involved with and help them consider enabling SIP
and XMPP federation of their own communities/domains: as Metcalfe's law
 suggests, each extra
person or community who embraces open standards like SIP and XMPP has
far more than just an incremental impact on the value of these standards
and makes them more pervasive.

If you are keen to support and collaborate on the wider use of Free RTC
technology, please consider joining the Free RTC mailing list
 sponsored by FSF
Europe. There will also be a dedicated debian-rtc list
 for discussion of these
technologies within Debian and derivatives.

This service has been made possible by the efforts of the DSA team
 in the original SIP+WebRTC project
 and the more recent
jessie upgrades and XMPP project. Real-time communications systems have
specific expectations for network latency, connectivity, authentication
schemes and various other things. Therefore, it is a great endorsement
of the caliber of the team and the quality of the systems they have in
place that they have been able to host this largely within their
existing framework for Debian services. Feedback from the DSA team has
also been helpful in improving the upstream software and packaging to
make them convenient for system administrators everywhere.

Special thanks to Peter Palfrader and Luca Filipozzi from the DSA team,
Matthew Wild from the Prosody XMPP server  project,
Scott Godin from the reSIProcate 

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

[Julien Puydt]

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, 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.



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.


Yes.


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


Well, GUI isn't my strong point, but I think having the text in a window 
and the fact of the other person in another is pretty inconvenient, so 
there should be a way to put both side-to-side.



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."


That's a good thing to have in mind for the one implementation, thanks 
for the reminder. And it can help to see how things are organised there. 
I'm also having a look at pidgin's sources.



Happy hacking,


Well, I'm still on the thinking side of things : writing comes later.

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 (named roster) is ; the presence exchange is at
the server level ;

- you can send messages one-to-one or join/create a room. One-to-many
exists, but isn't natural (even with XEP-0033) ;

- the interesting thing about one-to-one is that you can either send
the messages in a one-off fashion or with a threading information (see
5.1 in RFC 6121). In this case it's possible to have different
conversations with the same contact, and it's possible to turn a
private conversation into a group conversation, which others can join
(see section 7.9 of XEP-0045 - notice how the client is supposed to
send the history to the room) ;

- a chat room has a title, a list of occupants with their own presence
(you might in fact not even know the "real identity" of the occupants:
the nickname is per-room!) with roles ; it also has a history which
new joiners will receive.


With SIP: here I shall wait for a reply, as I'm definitely not qualified 
to discuss it at length.


I'm not sure I'm 100% right on all of the above: feedback is welcome!


Cheers,

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

[Julien Puydt]

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 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!



Eh, my pragmatism says that it's the contrary : if we have few 
developers with little spare time, it's vitally important to make sure 
that code which compiles is code which works. Let the tools handle as 
much as possible. Let's get out of the way so they can help. Will you 
buy it if I call it hardened design ?



I call very bad a situation where a code modification somewhere will 
compile perfectly, but silently and subtly break a few other places, 
which will have to be found out by manual testing, hopefully before a 
release by a tester... but more realistically after the release by a 
user, tracked and fixed one by one with no help from the tools.



You can get the impression that things are easy and your productivity is 
extremely high when you get something working in five minutes. But if 
hours of debugging and fixing are hidden around the corner, I don't 
think it's wise.



I have seen students write a fusion sort implementation which worked 
wonderfully when given a list/array of length a power of two, and broke 
in all other cases. But the code was so wonderfully short !



Let's not forget there's a fine line between simple and stupid!


Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 builder code, one of the things I wanted was make 
sure that providing actions would be *simple*, and indeed :


1. if you only need to add a few actions, it is mostly trivial (look at 
evolution-book.cpp's populate_menu : for a single action, there are very 
few lines!) ;


2. if you don't provide the actions yourself, it is also easy to 
accumulate the actions of various sources : just pass the builder around.



This is why the live object pushes what can be done (calls add_action, 
etc on the menu builder), rather than the gui pulling it (calls  some 
get_action). That way most of the api is in Ekiga::MenuBuilder (which 
has few implementations, but rich ones) and not Ekiga::LiveObject (which 
has many, and shouldn't be rich : when you write an evolution book, you 
want to spend your time writing how to interact with it, not writing 
boilerplate to create objects).



Another goal was to make it easy to extend ; the first version of 
Ekiga::MenuBuilder had only the add_action method : add_separator and 
add_ghost were added later. And adding them was rather trivial! I just 
added them to the base class, which of course directly broke the 
MenuBuilderGtk class (the compiler complained and made a todo-list)... 
but *nothing else*. Again, because the api was in Ekiga::MenuBuilder and 
not Ekiga::LiveObject.



I could have gone with a framework similar to other parts of the engine 
with an abstract Ekiga::Actionnable and an Ekiga::ActionnableImpl 
duality, which would have had quite nice properties too (with respect to 
using the compiler to detect problems, for exemple -- see my other 
mail), but that would have made things too complex for something which I 
wanted as dynamic as possible. Indeed, I thought we could have objects 
which would provide some actions in some cases, and others in other 
cases -- and switching would happen in the snap of fingers during 
runtime! So with a several-methods framework, that would have given 
complex code, while the menu builder trick makes it easy : check the 
state at the start of your populate_menu implementation, and build your 
menu accordingly!



There is still something in common with the abstract+Impl I would like 
to mention : the idea that the base doesn't provide anything and hence 
doesn't get in the way, but that other things can come in and allow one 
to be lazy. For example, if you want to trigger a call action on an 
Ekiga::LiveObject, but nothing if it doesn't, you can use the 
Ekiga::Activator implementation of Ekiga::MenuBuilder. See 
menu-builder-tools.h for other examples. You don't have to use them, but 
they're available. And it's easy to come up with other such tools, and 
trivial to *combine* them.



Now, here is what I notice when reading the lib/engine/action/ framework 
code :


1. The Ekiga::ActionProvider class definitely looks like the 
Ekiga::LiveObject : it doesn't have a populate_menu getting an 
Ekiga::MenuBuilder, but a pull_actions getting an Ekiga::ActionStore, 
but really it's the same idea ! So the menu builder idea is built right 
inside the new action framework...


2. The Ekiga::ActionStore class is dumb (a dead list) when 
Ekiga::MenuBuilder is smart (either directly or by composition, see 
above), and I fear that will limit the features at one point.


3. The Ekiga::Action class is both too smart (as everything is already 
implemented and fixed) and too dumb (it's a struct turned into a class 
with direct accessors added to make up for the change). Again, that 
might hinder us at one point. I would suggest making Ekiga::Action 
purely abstract and providing an Ekiga::SimpleAction for a trivial 
implementation.


4. Where are the separators ? Ekiga::ActionStore will not allow us to 
add those... and if we do, we'll end up with an Ekiga::MenuBuilder under 
another name...


5. I guess the ghosts actions of Ekiga::MenuBuilder are just disabled 
actions (but they still need a callback -- Ekiga::Action has a single 
ctor!)...


6. I don't get the point of the 'activated' signal of actions. An action 
asks an object to do something, and actually doing something should 
trigger a signal : the gui should react to changes (the contact was 
removed) not to would-be-changes (the user clicked to remove the contact).


7. Ekiga::Actor has add_action methods... that is very wrong : the 
Foo::Bar objects knows what it's able to do, you don't dictate its conduct.


8. Ekiga::Actor has signals for when an action is enabled/disabled which 
just transmit what happens to the actions, and 
action_added/action_removed to know how the list evolves, and that's good.


9. Ekiga::Actor should also have an 'updated' signal which is triggered 
when any 

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

[Julien Puydt]

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 anymore because of a new action 
system : this morning I tried to understand it... so I have questions 
(and critics...) :


(1) An action name has a global meaning... but one can have one call 
action per presentity, so how does one know which one the global one is 
about? The last which was clicked and declared it provided it?


(2) An action has two signals : enabled and disabled... which means it 
can get back and forth to both states. But how is it related to the 
lifetime management of objects? We don't want a dead object to be called 
through an action, or a would-be-dead object to be kept alive because an 
action somewhere still has a callback on it...


(3) I really think it is very bad that the base class Ekiga::Action has 
enable/disable methods : the loudmouth presentity knows if it can be 
called or not, nobody has to dictate whether or not this is possible! 
The only thing a UI can ask is to trigger an enabled action, it doesn't 
get to decide more than that! The UI's job is be pretty : let the 
serious code handle the serious work!


(4) I really don't get what this private on_activated is about...

(5) Ekiga::ActionStore is too stupid : how can one put an UI on that?! 
There's no signal to know when an action is 
added/removed/enabled/disabled... for the last two I can get around that 
by putting callbacks directly on the child actions (but then I have more 
connections to manage), but for the first two? The Ekiga::RefLister api 
is better in that respect : it was meant for dynamic situations.


(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 in the way of the last percent!


(7) The difference between Ekiga::Actor and Ekiga::ActionProvider eludes 
me...


(8) Ekiga::Actor has a friend on GActorMenu : that is a huge design 
flaw, as that means the base code isn't GUI-independent anymore!


It's hard to get back :-(

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 in the way of the last percent!


Yes, and I tend to disagree with that design which is too restrictive. I
have already discussed this design with many people
whose job is to program and design object-oriented code and they all
told me that it was really a weird design. However, it
just works, so that's ok for me now.



Uh... they never heard of separating the interface from the 
implementation? They never found it useful to quarantine code behind an 
interface so deps don't spread to the whole code base? They never used 
an interface to make polymorphism work?


I don't mean the idea of an action system is bad, it's just that I'm not 
convinced the current framework is sound. Notice that the current 
LiveObject framework with the MenuBuilder is already making it possible 
to export actions in a very dynamic way, so it has good things. It does 
lack centralization... I think the answer to my question (1) would help 
me understand more precisely what you want.


Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 somewhere in the ui.


Ok, I have pushed code which is supposed to do the above five points 
(out of six points) ; I had a hard time testing it as I get crashes 
(afaict unrelated to what I did). Running ekiga through a slogin -X 
might not be the best way to do serious tests, though, so I'll need to 
have a look directly on the culprit box.


Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 object which is able to classify, asking delegates ;
- the roster is such a delegate : people in the roster are at least 
neutral, and if they've been marked as preferred, then they're even friends.


And that's all! The call core doesn't even know about the feature, and 
we have no blacklist about foes! So what is needed is:

(1) make the call core reject foes ;
(2) add a blacklisting delegate ;
(3) make so the call core, depending on the state (do not disturb or 
normal) will reject all calls from not-friends (hence foes, unknowns and 
neutrals), directly accept the calls from friends, ask for friends only 
or ask for friends and neutrals...

(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 somewhere in the ui.


I started by the easiest thing to do: (1). The problem is that I'm not 
quite sure what the proper way to reject a call is ; my current patch 
has the following :

+void
+CallCore::add_call (boost::shared_ptrCall call,
+   boost::shared_ptrCallManager manager)
 {
+  Ekiga::FriendOrFoe::Identification id = iff-decide (call, 
call-get_remote_uri ());

+
+  if (id == Ekiga::FriendOrFoe::Foe) {
+
+call-hang_up ();
+return;
+  }
+

does that look sane?

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

[Julien Puydt]

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 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:~$


So it doesn't look at all like the first window shot in this page: 
http://wiki.oz9aec.net/index.php/Gstreamer_cheat_sheet

? Only the lower right corner should move.



2. gst-launch videotestsrc ! agingtv ! ximagesink


The same erroneous window, with the same output.


It should be only slightly the same, with an aging special effect so the 
streams can be discerned apart (as I write apart I wonder if it 
shouldn't have been one another or something like this...).



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


Yes. And the same code should work regardless of the platform.

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

[Julien Puydt]

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
2. gst-launch videotestsrc ! agingtv ! ximagesink
?


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.


At least, that's the goal.

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

[Julien Puydt]

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!


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

[Julien Puydt]

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://lbalbalba.url.ph/cppcheck/ekiga/



I fixed them too, but I'm quite unhappy: the default C++ constructors 
were adequately taking care of things, so those weren't worth it. In 
fact, to get more correct core, one should probably *remove* the lines I 
added, and then some more for good measure...


It's disappointing that those tests found out so little to complain 
about... :-/


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

[Julien Puydt]

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.


The GStreamer api for device detection (see bug #678402) will be 
discussed at a hackfest on 14-16 March... let's hope it will find its 
way in a release soon.


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

[Julien Puydt]

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!

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Ekiga-devel-list] About GUDev in ekiga

[Julien Puydt]

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.

Enjoy,

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 :-/


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

[Julien Puydt]

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 :-(

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

[Julien Puydt]

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... :-(


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

[Julien Puydt]

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!


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

[Julien Puydt]

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

Ah, the joys of working on the bleeding edge. Though I'm currently more
on the bleeding side than the edge's...

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

[Julien Puydt]

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 :'-(

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

[Julien Puydt]

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

[Julien Puydt]

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

[Julien Puydt]

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 with it's base plugins
compared to the gstreamer-on-others?

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

[Julien Puydt]

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' 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?


The gm-text-buffer-enhancer code is only be used in the chat window as 
far as I know, so I doubt it could trigger something in the about window :-/


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

[Julien Puydt]

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 -- ie: not on win32...

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] gsettings trouble

[Julien Puydt]

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.

 - why in linux this error does not appear

Good question!

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] gsettings trouble

[Julien Puydt]

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

Snark

___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] Broken compilation

[Julien Puydt]

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.
 
 I cloned it anew and end up in the same bad situation...

I inquired, understood and fixed the src/Makefile.am situation.

The fact that ekiga didn't run after the compilation was due to the fact
that I was trying to run using ./src/ekiga on a box where the
gsettings-enabled ekiga was never installed. That means ekiga can't be
run from the build tree without installation whenever the gsettings
setup is modified.

Now I'll be able to test my last changes.

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

[Julien Puydt]

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 opal accounts bugs Damien reported
 privately.

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).

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

[Julien Puydt]

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

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] Broken compilation

[Julien Puydt]

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 situation...

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

[Julien Puydt]

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 to Julien about that, but I do not know if he intends doing
 something for it or not. Julien, can you comment ?
 Yes, we discussed it ; it's technically possible, but :

 - it means adding back gmconf (the code, the configure lines, the
 Makefile.am lines, the old schema...) ;
 
 Yes, and no...
 
 Actually, there is a gsettings-data-convert utility that reads a
 .convert file and move the old settings into GSettings. This .convert
 file is present in the Ekiga tree and installed at the right place so
 that all settings are magically converted when the user logs in.
 
 The idea would be add the a method to Opal::Account able to read the old
 format from a converted GSettings key, and to save it into the new XML
 format in the new key.
 
 Of course, that won't work with Windows.

That makes things much simpler! I would rather see opal-main.cpp do
something like this :

- check if there is an old gsettings key around ;
- if so, call a static method of Opal::Bank to migrate (let's call it
migrate_from_gmconf) ;
- if so, delete the old key so we don't do it again next time.

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 opal accounts bugs Damien reported
privately.

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Ekiga-devel-list] Broken compilation

[Julien Puydt]

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
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] Broken compilation

[Julien Puydt]

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): GLib-GIO-ERROR **: Settings schema
'org.gnome.ekiga.general.user-interface.video-display' does not contain
a key named 'enable-pip'

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

[Julien Puydt]

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 you comment ?

Yes, we discussed it ; it's technically possible, but :

- it means adding back gmconf (the code, the configure lines, the
Makefile.am lines, the old schema...) ;

- the gsettings code needs to call a function
convert_gmconf_opal_accounts somewhere after some condition is met (I
musts admit I don't know much about GSettings) ;

- I fear starting to do a conversion for opal accounts will open the way
to do the same for addressbooks and the rest...

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] gsettings trouble

[Julien Puydt]

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
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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-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?


Julien, do you have time to fix this issue any time soon?


Honestly, I don't think so :-(


Julien, you are the only hope to fix these warnings :)  Would you be 
able to look again into them?


Sigh... I have no clue when, but I'll have a look. I fixed ekiga's 
compilation yesterday, but didn't find the time to run it...


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] Last modifications

[Julien Puydt]

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 pushed a commit doing just that, because I think it is needed.

Now the question is: was it enough to fix the break?

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] Last modifications

[Julien Puydt]

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
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 for that is
 on_some_core_updated in main_window.cpp. Unfortunately, this function
 does nothing if the main window doesn't contain a core-actions submenu
 -- and there's none anymore, so it's just sitting there...
 
 Do you mean that you do not have a Chat-Contact menu anymore?

I have it. And it's a dynamic menu which is related to the actions on
the selected contact, which is empty if no contact is selected.

No, what has been lost is a menu which is independent of any selected
contact.

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 :-/

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 it
 with 9c6c48f0cc73c4cb41b9cd9de94c7d44d9d3e95a.
 
 Ah ok, the undef is the reason I have not seen it.
 
 Perhaps I should add it back, but this time live :-/
 
 this time live = ?
 
 So the issue is closed, right?

Yes.

By this time live, I meant: I'll make it appear unconditionally.

Snark


___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 nothing if the main window doesn't contain a core-actions submenu 
-- and there's none anymore, so it's just sitting there...


Why did it disappear?

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 is about...

Can someone shed a light on it?

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 /lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) bt
#0  0x74dc217d in g_logv () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x74dc2342 in g_log () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0

#2  0x74dd455e in g_sequence_iter_get_position ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x77159979 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#4  0x7715c851 in 
gtk_tree_model_filter_convert_child_path_to_path ()

   from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#5  0x7715c92e in 
gtk_tree_model_filter_convert_child_iter_to_iter ()

   from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#6  0x7775c262 in on_presentity_added (self=0xf40a80, cluster=...,
heap=..., presentity=...)
at ../../ekiga.git/lib/engine/gui/gtk-frontend/roster-view-gtk.cpp:1047
#7  0x7775d214 in visit_presentities (self=optimized out,
cluster=..., heap=..., presentity=...)
at ../../ekiga.git/lib/engine/gui/gtk-frontend/roster-view-gtk.cpp:1006
#8  0x7775ec01 in operator()bool, bool (*)(_RosterViewGtk*, 
boost::shared_ptrEkiga::Cluster, boost::shared_ptrEkiga::Heap, 
boost::shared_ptrEkiga::Presentity), 
boost::_bi::list1boost::shared_ptrEkiga::Presentity  (

a=synthetic pointer, f=optimized out, this=optimized out)
at /usr/include/boost/bind/bind.hpp:447


The thing is that I had a look at the code, and it looks sane ; in fact, 
it looks like old code...


I'm suspecting a(nother) GtkTreeModelFilter bug... I'm using gtk+ as 
found in debian/unstable, version 3.8.2-2.


Am I the only one to see this?

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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/breakpoint trap.
0x74dc217d in g_logv () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0


I do not know, I have not tested it recently.


Just launching is enough to make it happen : it's in the roster view 
initial population.


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... :-/


Snark

___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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

[Julien Puydt]

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 *BSD and win32 (and MOSX?).


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

[Julien Puydt]

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 and it has better windows/Mac support.


I had a look, and gstreamer 1.0 doesn't have GstPropertyProbe anymore ; 
the gstreamer developers suggest using gudev, which is linux-only.


That is quite a big loss of feature, so I think we should stick to 0.10 
until they get their *future* new api into a *now* new api!


Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] Ekiga Port

[Julien Puydt]

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 implementations :
- a glib one (used on win32 -- in fact made the port possible) ;
- a gconf one (used everywhere else).
The glib implementation of gmconf runs everywhere.


And a DConf one.

The WIN32 backend is supposed to use the registry. But I would like to
be sure of that before kicking GmConf out.

Most probably it won't be possible to port current GConf settings to
GSettings though (just because it would force us to keep a GConf
dependancy).



Should I try to write a GSettings implementation of the gmconf api?


I have no comment, do as you think.


Well, would I step on someone's toes if I were to do that?

Snark

___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Ekiga-devel-list] Gstreamer in ekiga

[Julien Puydt]

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
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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

[Julien Puydt]

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 machine?


Yes, but I generally launch ekiga, do a short call and quit, so more 
broad testing would be nice.


Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] Ekiga Port

[Julien Puydt]

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 (used everywhere else).
The glib implementation of gmconf runs everywhere.


And a DConf one.

The WIN32 backend is supposed to use the registry. But I would like to
be sure of that before kicking GmConf out.

Most probably it won't be possible to port current GConf settings to
GSettings though (just because it would force us to keep a GConf
dependancy).



Should I try to write a GSettings implementation of the gmconf api?

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] Ekiga Port

[Julien Puydt]

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
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] Ekiga Port

[Julien Puydt]

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 use of gmconf by GSettings?


I'm not so far yet. I have just converted the schema file and made sure
it gets installed.

My plan is to do a GSettings backend for GMConf.

Then, if we are sure that there is a WIN32 backend for GSettings, we can
drop gmconf. But perhaps gmconf is more convenient to use than GSettings
directly I don't know yet.


What I had in mind was:
(1) make a GSettings implementation of gmconf ;
(2) convert every directory to direct GSettings use (easy to share 
between several persons)

(3) kick gmconf out.

The thing is I don't know how to trigger events in GSettings.

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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,
  width=16,
  depth=16,
  signed=true,
  endianness=1234

while during calls, it is as far as I know :

  audio/x-raw-int,
  rate=8000,
  channels=1,
  width=16,
  depth=16,
  signed=true,
  endianness=1234

Last night's debugging session made something strange appear : the log 
shows that gstreamer feels flooded by data during calls. In fact, one 
gstreamer developper had the impression we were getting about 120 times 
more data than expected. He made those computations at an advanced hour 
of the night though, so I'll have to double-check.


Still, does that somebody go O! ?

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 (Ekiga::AudioOutputPS ps,
 const char* data,
 unsigned size,
 unsigned written)
{
  bool result;
  unsigned ii = (ps == Ekiga::primary)?0:1;

  if (worker[ii]) {

gst_helper_set_frame_data (worker[ii], data, size);
written = size;
result = true;
  } else {

// we're closed already!
written = 0;
result = false;
  }
  return result;
}

and:

void
gst_helper_set_frame_data (gst_helper* self,
   const char* data,
   unsigned size)
{
  //g_message (%s\n, __PRETTY_FUNCTION__);
  gchar* tmp = NULL;
  GstBuffer* buffer = NULL;
  static bool done = false;

  if (!done) {

done = true;
GST_DEBUG_BIN_TO_DOT_FILE(GST_BIN(self-pipeline), 
GST_DEBUG_GRAPH_SHOW_ALL, pipeline);

  }

  if (self-active) {

tmp = (gchar*)g_malloc0 (size);
memcpy (tmp, data, size);
buffer = gst_app_buffer_new (tmp, size,
 (GstAppBufferFinalizeFunc)g_free, tmp);
gst_app_src_push_buffer (GST_APP_SRC (self-active), buffer);
  }
}

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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::AudioOutputManager::set_frame_data (Ekiga::AudioOutputPS ps,
const char* data,
unsigned size,
unsigned written)
{
cut
}

and:

void
gst_helper_set_frame_data (gst_helper* self,
const char* data,
unsigned size)
{
cut
}


I forgot a link in the chain ptlibopal-gstreamer ; the first one:

bool PSoundChannel_EKIGA::Write (const void *buf, PINDEX len)
{
  unsigned bytesWritten = 0;

  if (direction == Player) {
audiooutput_core-set_frame_data((char*)buf, len, bytesWritten);
  }

  lastWriteCount = bytesWritten;
  return true;
}

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 
there are 18906 of them and they are of size 160... if I don't err that 
makes 684983 byte/s... it looks unreasonably big indeed!


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

[Julien Puydt]

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 evolution-contact.h?


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

[Julien Puydt]

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 moaning about it and the
build only failed a couple of days ago.


It really looks like it's g++ not liking boost... in which case we can't 
do much, and probably other packages are hit by the problem... I would 
push the bug from the ekiga package to the boost package.


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

[Julien Puydt]

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 mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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

[Julien Puydt]

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@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 with the SIP endpoint because of the following two 
lines :

sip_endpoint-Unsubscribe (SIPSubscribe::MessageSummary, get_aor ());
sip_endpoint-Subscribe (SIPSubscribe::MessageSummary, 3600, get_aor ());

what does that MessageSummary mean?

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 to the right protocol endpoint.

I can't do the same with the SIP endpoint because of the following two
lines :
sip_endpoint-Unsubscribe (SIPSubscribe::MessageSummary, get_aor ());
sip_endpoint-Subscribe (SIPSubscribe::MessageSummary, 3600, get_aor ());

what does that MessageSummary mean?


Is that related to the Message Waiting Information feature?

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 :-/ )


Could people who run the latest master tell me if they have a 
crash-on-exit (be it on win32 or linux)? (with a backtrace if possible)


Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 round of cleaning.

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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::MultipleChat... I hate those
names :-/ )


Opal uses OpalIM, maybe use EkigaIM ? It is fairly descriptive...


Ekiga::EkigaIM doesn't look more descriptive than Ekiga::IM... I still 
think IM is too short and undescriptive.



Still, I do not understand: is Dialect a variant of something? Which is
the name of that Something? Is there other Dialect class, which is its
name?

Or it is generic, and in that case Dialect does not make much sense?


Ekiga::Dialect is an abstract class, and we have a Loudmouth::Dialect 
and an Opal::Dialect (perhaps also an Echo::Dialect in some test code), 
and I think that a name like Protocol::Dialect is quite descriptive!


Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 environment, won't I?

Is another developers game dependency hell going on here?

Which corresponding source file versions should I try to reactivate?


ffmpeg keeps on making incompatible changes to their api ; that is the 
reason why opal's sources contain a known-compatible version : just let 
opal use those sources, and things will go smoothly.


Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 by the openSUSE distribution here.



If you need ekiga as a user, then use v10.


I can refer also to this version level if I pass appropriate values for
parameters like PTLIB_CFLAGS and OPAL_CFLAGS to the command configure. But
I still wonder about results like the following.


Why do you wonder? Obviously the code isn't supposed to be compatible 
with v12, and the configure script has a bug in that it doesn't detect 
this problem.


Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 happens ; which means 
it's above it from an abstract point of view. This is confirmed by 
inspection of methods Opal::Sip::EndPoint::menu_builder_add_actions and 
Opal::Sip::EndPoint::account_updated_or_removed, which ping the bank to 
know what to do. The endpoints also asks things to Opal::SIP::Dialect!


On the other hand, Opal::Bank delegates everything to Opal::Account. And 
what does Opal::Account do? Whenver it has something to do, it asks 
Opal::Sip::EndPoint!



In short, the code in this directory is structurally bound to give problems.


I suggest the following organization:

- Opal::Sip::EndPoint does everything low-level (register/unregister 
accounts, call and presence management) ; when something happens, it 
emits signals. It shouldn't ping the bank for anything, as it's not its 
business!


- Opal::Account is connected on the endpoint, and gives orders 
(registration, presence subscription/unsubscription), and watches the 
signals to know when something happens (registration, mwi, presence) (it 
is above abstractly).


- Opal::SIP::Dialect should also be above the endpoint : when it wants 
to send a message, it asks the endpoint, and when a message comes, it 
knows about it through a signal.


- 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 will actually add actions (to each its own business!)



The big picture is that I would like to replace the Gordian knot that we 
now have with a nice tree (ie: no dependency cycle) :


Opal::CallManager ---\
  \
Opal:: Bank - Opal::Account --- Opal::Sip::EndPoint
   /
Opal::SIP::Dialect ---/


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 (in a private email), the 
endpoints get freed before the accounts, so the accounts call some 
endpoint and we get a crash! Somewhere else in ekiga, there must be some 
code which says to dispose of the endpoints ; that is wrong.


The good solution is to remove that other code, and put our endpoints in 
the boost shared pointers with a deleter which will shut them down 
gently, then call delete. This way, we'll be sure that the endpoints 
will live as long as something in the ekiga needs them, and that they 
are properly closed whenever they're not needed anymore. It's the code 
which creates the objets, which should take care of disposing of the 
objects!


Snark

(PS: notice how we sometimes have SIP and sometimes Sip in the namespaces)
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 (in a private email), the
endpoints get freed before the accounts, so the accounts call some
endpoint and we get a crash! Somewhere else in ekiga, there must be some
code which says to dispose of the endpoints ; that is wrong.

The good solution is to remove that other code, and put our endpoints in
the boost shared pointers with a deleter which will shut them down
gently, then call delete. This way, we'll be sure that the endpoints
will live as long as something in the ekiga needs them, and that they
are properly closed whenever they're not needed anymore. It's the code
which creates the objets, which should take care of disposing of the
objects!


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 gets to clean the endpoints when it disappears (or 
when asked to remove it)


There doesn't seem to be anything to keep managers alive separately from 
the call manager, so the tree I proposed should perhaps become :


Opal::Bank - Opal::Account -\
  \
Opal::SIP::Dialect  Opal::CallManager
   |
   v
 Opal::Sip::Endpoint


And everything I said about signals/orders/populate menu should go 
through the call manager. And we keep the null deleters.


Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 gets to clean the endpoints when it disappears (or when 
asked to remove it)

There doesn't seem to be anything to keep managers alive separately from the 
call manager,


...deleted

You have correctly described how it works. Let us know if we can help



Thanks for the confirmation ; I don't think you can help : this is 
definitely an ekiga-only problem, and I think I have (the idea of) a 
solution.


Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 will actually add actions (to each its own business!)


I had a look, but I don't quite get what 
Opal::Sip::EndPoint::menu_builder_add_actions does:


(1) I get the impression that if I give it an uri looking like 
h323:foo and I have an ekiga.net account enabled, it will turn it into 
a sip:h323:f...@ekiga.net...


(2) it also seems to do some voodoo to remove spaces and dashes (and 
does it in a loop even though it looks like it doesn't depend on the 
loop iterator)...


(3) the final loop on two lists looks strange... shouldn't it have been 
a std::liststd::pairstd::string, std::string instead of two 
different std::liststd::string ?


Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Ekiga-devel-list] New gobject warning

[Julien Puydt]

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
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 leaked it, and
finally what leaked what leaked what leaked it, and fixed the whole mess.

Now Ekiga::ServiceCore doesn't see any service left alive after shutdown.

Eugen, can you check whether this fixes the freeze-on-exit on win32?


With current stable branch, it still freezes on Windows.  Tested three
times with and three without, all freeze.


Sigh. And with latest master + #define DEBUG 1 in services.cpp, does it 
complain that some services are still live?


Snark

___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 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
mess.

Now Ekiga::ServiceCore doesn't see any service left alive after
shutdown.

Eugen, can you check whether this fixes the freeze-on-exit on win32?


With current stable branch, it still freezes on Windows. Tested three
times with and three without, all freeze.


Sorry, wanted to say with latest master.


I had understood :-P


Sigh. And with latest master + #define DEBUG 1 in services.cpp, does it
complain that some services are still live?


Still needed?


Yes, just to be sure there is no platform-specific leak lurking which 
might explain the freeze. After all, if something leaks, perhaps it 
doesn't close some thread correctly, and that would give a freeze in 
some condition (and no freeze with -d 4 with timing luck).


I'm not very hopeful, but it's worth looking at :-/

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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.


Snark
diff --git a/plugins/libnotify/libnotify-main.cpp b/plugins/libnotify/libnotify-main.cpp
index ce05e9a..e6b7f9d 100644
--- a/plugins/libnotify/libnotify-main.cpp
+++ b/plugins/libnotify/libnotify-main.cpp
@@ -81,18 +81,32 @@ private:
   container_type live;
 };
 
+struct call_reference
+{
+  call_reference(boost::shared_ptrEkiga::Call _call): call(_call)
+  {}
+
+  boost::shared_ptrEkiga::Call call;
+};
+
+static void
+delete_call_reference (gpointer data)
+{
+  delete (call_reference *)data;
+}
+
 static void
 call_notification_action_cb (NotifyNotification *notification,
  gchar *action,
  gpointer data)
 {
-  Ekiga::Call *call = (Ekiga::Call *) data;
+  call_reference* ref = (call_reference *) data;
 
   notify_notification_close (notification, NULL);
   if (!g_strcmp0 (action, accept))
-call-answer ();
+ref-call-answer ();
   else
-call-hangup ();
+ref-call-hangup ();
 }
 
 static void
@@ -250,6 +264,7 @@ LibNotify::on_call_notification (boost::shared_ptrEkiga::CallManager manager,
  boost::shared_ptrEkiga::Call call)
 {
   NotifyNotification *notify = NULL;
+  call_reference* ref = NULL;
 
   if (call-is_outgoing () || manager-get_auto_answer ())
 return; // Ignore
@@ -267,8 +282,10 @@ LibNotify::on_call_notification (boost::shared_ptrEkiga::CallManager manager,
 #endif
 #endif
 );
-  notify_notification_add_action (notify, reject, _(Reject), call_notification_action_cb, call.get (), NULL);
-  notify_notification_add_action (notify, accept, _(Accept), call_notification_action_cb, call.get (), NULL);
+  ref = new call_reference (call);
+  notify_notification_add_action (notify, reject, _(Reject), call_notification_action_cb, ref, delete_call_reference);
+  ref = new call_reference (call);
+  notify_notification_add_action (notify, accept, _(Accept), call_notification_action_cb, ref, delete_call_reference);
   notify_notification_set_timeout (notify, NOTIFY_EXPIRES_NEVER);
   notify_notification_set_urgency (notify, NOTIFY_URGENCY_CRITICAL);
 
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Ekiga-devel-list] Leaked services on shutdown

[Julien Puydt]

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 
services.cpp to trigger this debugging output).


On my system, it shows the service named videooutput-core isn't freed 
correctly.


Could this be the reason of the win32 freeze on exit?

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 mess.


Now Ekiga::ServiceCore doesn't see any service left alive after shutdown.

Eugen, can you check whether this fixes the freeze-on-exit on win32?

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Ekiga-devel-list] Code cleaning

[Julien Puydt]

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 gm_window_show.


I didn't dare change that code, but perhaps that would have been ok too?

Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 100644
--- a/plugins/libnotify/libnotify-main.cpp
+++ b/plugins/libnotify/libnotify-main.cpp
@@ -81,18 +81,34 @@ private:
   container_type live;
 };
 
+struct call_notification_keep_call_alive
+{
+  boost::weak_ptrEkiga::Call call;
+};
+
+static void
+delete_call_notification_keep_call_alive (struct call_notification_keep_call_alive* data)
+{
+  data-call.reset();
+  delete data;
+}
+
 static void
 call_notification_action_cb (NotifyNotification *notification,
  gchar *action,
  gpointer data)
 {
-  Ekiga::Call *call = (Ekiga::Call *) data;
+  boost::shared_ptrEkiga::Call call = ((struct call_notification_keep_call_alive *) data)-call.lock();
 
   notify_notification_close (notification, NULL);
-  if (!strcmp (action, accept))
-call-answer ();
-  else
-call-hang_up ();
+
+  if (call) {
+
+if (!strcmp (action, accept))
+  call-answer ();
+else
+  call-hang_up ();
+  }
 }
 
 static void
@@ -267,8 +283,12 @@ LibNotify::on_call_notification (boost::shared_ptrEkiga::CallManager manager,
 #endif
 #endif
 );
-  notify_notification_add_action (notify, reject, _(Reject), call_notification_action_cb, call.get (), NULL);
-  notify_notification_add_action (notify, accept, _(Accept), call_notification_action_cb, call.get (), NULL);
+  struct call_notification_keep_call_alive* dcnkca1 = new struct call_notification_keep_call_alive;
+  dcnkca1-call = call;
+  notify_notification_add_action (notify, reject, _(Reject), call_notification_action_cb, dcnkca1, (GFreeFunc)delete_call_notification_keep_call_alive);
+  struct call_notification_keep_call_alive* dcnkca2 = new struct call_notification_keep_call_alive;
+  dcnkca2-call = call;
+  notify_notification_add_action (notify, accept, _(Accept), call_notification_action_cb, dcnkca2, (GFreeFunc)delete_call_notification_keep_call_alive);
   notify_notification_set_timeout (notify, NOTIFY_EXPIRES_NEVER);
   notify_notification_set_urgency (notify, NOTIFY_URGENCY_CRITICAL);
 
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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 file libnotify-main.cpp
Hunk #1 FAILED at 81.
1 out of 2 hunks FAILED -- saving rejects to file libnotify-main.cpp.rej


Sigh. Could you take the libnotify-main.cpp from the original ekiga 
sources to replace the one you have, and then use the second patch?


Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

[Julien Puydt]

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
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list