Re: [Ekiga-devel-list] Handling ordinary phone numbers ( Yet Another Approach)
- From: Alec Leamas <leamas alec gmail com>
- To: Ekiga development mailing list <ekiga-devel-list gnome org>
- Subject: Re: [Ekiga-devel-list] Handling ordinary phone numbers ( Yet Another Approach)
- Date: Mon, 30 Mar 2009 00:37:55 +0200
Eugen Dedu wrote:
I'll be actually be offline for a week, so its no hurry. And for the
same reason I will try to comment issues which I feel I have actual now,
and not later. I'll try to attach a new version of the files to the bug
before I leave.
Thanks, Alec, for this. Let's try to check it in while it is "fresh",
otherwise it will be forgotten and the chances to be integrated are
Also, let's wait with the check in a few days (until Tuesday?) for
other people comments.
(I welcome the "make easy the user work" subject; there is room here
for other sub-domains too, we will speak later about that.)
I can use PTRACE with some loss of information in error messages. Same
for classical assert, to a much higher degree. Note "my" Trace/Assert
uses the PTRACE backend when it's available, so there is really no
conflict. But it's some extra code, yes.
Alec Leamas wrote:
Trying to explain this once again, hopefully better. Questions in the
The problem I try to solve is that users typically stores telephone
numbers, often formatted and without countrycode, whereas Ekiga today
requires a complete URL to place even an ordinary PSTN call. This
makes the basic process to call a PSTN number hard, user has to
manually convert e. g., '070-543 22 11' to
sip:+46705432211 sip diamondcard com
I have written a piece of code which converts numbers to sip: urls.
It's partly a question of handling missing country codes, partly to
remove formatting characters as in '070- 543 11 22'. This code of
course requires some configuration to define user's own countrycode
etc. (all in total four values). It generates default config values
usable for most users, and seems to work. It has the potential to let
users just enter e. g., 070-543 22 11 in Ekiga to place a call
instead of a complete URL.
My problem is if/how to integrate this into Ekiga. More precise, I
need help to integrate it. The Ekiga code is big, and although I
think I'm able to produce a set of patches, I will at least need help
with where in the code I should begin, and certainly other things as
well. I really can't be on my own in this, it's to much for a newbie...
So: first question: Would this overall be a Good Thing, something
that makes Ekiga more usable, and thus worth some effort?
Second question. I have done a simple plan:
http://mumin.dnsalias.net/ekiga-callto-ui/patches.html. Is this
Third question. There is some UI impact, described in
http://mumin.dnsalias.net/ekiga-callto-ui/index.html. Does this seems
For the moment, let's just do nothing (the current error is shown).
Later, we can add a menu entry, or a tab in preferences etc.
Last question: Depending on the outcome of the other questions, how
should I proceed with the first patch, to integrate a set of new
source files related to PSTN management into Ekiga?
There are three files involved (Pstn* and .csv); I would propose to
use PTRACE from ptlib; as for assert, isn't possible to use classical
I have actually refactored the code, so wait a little with checking in.
One of the thing I was thinking about is if there should be a separate
directory for this, or which existing should be used. There is currently
four source files besides the Trace/Assert stuff., + the csv file.
The csv file is an issue. The app must be able to locate it, it's just a
hardcoded path now. No idea how handle it.
To be honest: I have absolutely no idea where to make the changes. But I
think that in this case it's the code executed when user user pushes the
"Call" context menu option for a contact.
The first thing is to add a hook when the user clicks on green button.
Later, we will add a hook for adding in dbus, roster etc., as you
wrote. I see in the bug report there are several things involved, such
as PresenceCode; so is it there to add this hook? The change to ekiga
current code should be very small, only 2 lines (call your pstn file
and replace the URL bar value).
Yes, most of these patches should be really small. The problem is to
find out where to do it...
No, not really. The problem is when you expand a number supposed to be
evaluated in another country e. g., when using a number on a US website.
The user must then have a chance to review and edit the number before
it's used. (it's the second example in my UI sketch and "story" 2.) So
there *is* a need for a three-step approach: first convert, review/edit
and call. The situation is the same whether called from the browser or
when a number is pasted into Ekiga. The "just push button" is a shortćut
possible on numbers that are unambiguous: starting with +, or from the
In fact, all your work can be resumed like this: when the user pushes
the green button (or dbus, roster etc.), the number in the URL bar is
transformed, that's all, isn't it?
There is a specific account in the PSTN configuration, effectively the
default PSTN account. Given that ekiga gets requests to connect to a
plain number, such an option is more or less necessary.
Some background material: usecases defined in a few "stories:"
Additionally, I have some comments:
1. Note that ekiga already adds the suffix (it shows it in the combobox,
but it adds it too)
2. What happens when you have two accounts? Which one does it choose?
(We can think about this later, let's do it step by step, as you
My goal is that Ekiga should do the conversion. There are many reasons
for this: better UI, better on Windows where python + GTK is a less
attractive alternative. When all is in place, Ekiga will serve as a
general purpose handler of callto: links. The current python code can be
dropped, Ekiga will connect directly to Firefox with the same functionality.
3. How does this integrate with ekiga-callto program/package, i.e. who
does the url changing, ekiga-callto or ekiga itself?
I just use curl to "read" an url, there is a single method (now class)
which is fed an URL, returning the contents. Its used to determine
country, a central part of the default values routines. I know for sure
that something like this takes place somewhere already today e. g. when
using http://www.ekiga.net/ip to determine the IP address so there is
most likely routines handling this already. OTOH, libcurl/curl is a
widespread and well maintained package also working an windows, so it
might make sense to use it in more places. Don't know, but we should
probably streamline one way or the other.
4. I do not know curl well, why is it needed? What should you
retrieve? Does regex create problems on windows or macos?
Regex "should" not be a problem, I have done some checks. But I have not
compiled it, and I need som help with this. If I provide a small test
program, is there folks out there who can compile it on these platforms?
I think a wiki page is a Good Idea :-) I'd prefer to make the patches
step by step.
Do you think it is useful to add a wiki page and add there the steps
we will to implement, to avoid errors later? Or do you prefer to push
your current patches, in one step or step by step?
Thanks for taking the time to read and think about this!
] [Thread Prev