GNOME.org
 

Re: [Ekiga-devel-list] Handling ordinary phone numbers ( Yet Another Approach)



Eugen Dedu wrote:

Hi,

Hi :-)
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 small.
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'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. 

Alec Leamas wrote:
Trying to explain this once again, hopefully better. Questions in the end...
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? 

I agree.
Second question. I have done a simple plan: http://mumin.dnsalias.net/ekiga-callto-ui/patches.html. Is this reasonable? 

I agree.
Third question. There is some UI impact, described in http://mumin.dnsalias.net/ekiga-callto-ui/index.html. Does this seems OK?
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 assert?
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.
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.
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).
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.
Yes, most of these patches should be really small. The problem is to find out where to do it...
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?
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 address book.
Some background material: usecases defined in a few "stories:" http://mumin.dnsalias.net/ekiga-callto-ui/stories.html 

I agree.

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

3. How does this integrate with ekiga-callto program/package, i.e. who
does the url changing, ekiga-callto or ekiga itself?
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.
4. I do not know curl well, why is it needed? What should you retrieve? Does regex create problems on windows or macos?
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.
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?
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?
I think a wiki page is a Good Idea :-) I'd prefer to make the patches step by step. 

Thanks for taking the time to read and think about this!

--a
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]