[PATCH 1/2] Expose voice call direction synchronously

[PATCH 1/2] Expose voice call direction synchronously

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

Currently, the call direction can only be inferred from the signals.
This adds a property to keep it visible also from GetCalls().
---
 src/voicecall.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/src/voicecall.c b/src/voicecall.c
index 97fc36b..2baf2d6 100644
--- a/src/voicecall.c
+++ b/src/voicecall.c
@@ -352,7 +352,7 @@ static void append_voicecall_properties(struct voicecall *v,
 	const char *callerid;
 	const char *timestr;
 	const char *name;
-	ofono_bool_t mpty;
+	ofono_bool_t mpty, originated;
 	dbus_bool_t emergency_call;
 
 	status = call_status_to_string(call->status);
@@ -382,6 +382,10 @@ static void append_voicecall_properties(struct voicecall *v,
 					&timestr);
 	}
 
+	originated = call->direction == CALL_DIRECTION_MOBILE_ORIGINATED;
+	ofono_dbus_dict_append(dict, "Originated", DBUS_TYPE_BOOLEAN,
+				&originated);
+
 	if (g_slist_find_custom(v->vc->multiparty_list,
 				GINT_TO_POINTER(call->id),
 				call_compare_by_id))
-- 
1.7.1

[PATCH 2/2] Document voicecall direction

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

---
 doc/voicecall-api.txt |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/doc/voicecall-api.txt b/doc/voicecall-api.txt
index 4f38e6a..682b46b 100644
--- a/doc/voicecall-api.txt
+++ b/doc/voicecall-api.txt
@@ -92,6 +92,11 @@ Properties	string LineIdentification [readonly]
 			Contains the Name Identification information returned
 			by the network, if present.
 
+		boolean Originated [readonly]
+
+			Indicates whether the call was mobile-originated
+			(true) or mobile-terminated (false).
+
 		boolean Multiparty [readonly]
 
 			Contains the indication if the voice call is part
-- 
1.7.1

RE: [PATCH 1/2] Expose voice call direction synchronously

[Kai.Vehmanen]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

Hi,

On 10 Jan 2010, Rémi Denis-Courmont wrote:
> Currently, the call direction can only be inferred from the signals.
> This adds a property to keep it visible also from GetCalls().

just adding one more do { ++votes; } while(0) for this.
telepathy-ring needs this as well when it is (re)started and there
are existing calls: 
https://bugs.freedesktop.org/show_bug.cgi?id=32990

Re: [PATCH 1/2] Expose voice call direction synchronously

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

Hi Kai,

On 01/11/2011 06:47 AM, Kai.Vehmanen(a)nokia.com wrote:
> Hi,
> 
> On 10 Jan 2010, Rémi Denis-Courmont wrote:
>> Currently, the call direction can only be inferred from the signals.
>> This adds a property to keep it visible also from GetCalls().
> 
> just adding one more do { ++votes; } while(0) for this.
> telepathy-ring needs this as well when it is (re)started and there
> are existing calls: 
> https://bugs.freedesktop.org/show_bug.cgi?id=32990
> 

I'm still waiting for someone to give me a proper usecase for how the
Dialer UI is going to use this information.  Neither the Meego dialer
nor any other dialer I have ever used has provided this information.
Call direction for call history purposes is already provided to the
history plugin.

So right now Section 4.2 of doc/ofono-paper.txt still applies.

Regards,
-Denis

Re: [PATCH 1/2] Expose voice call direction synchronously

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

[-- Attachment #1: Type: text/plain, Size: 1291 bytes --]

On Wednesday 12 January 2011 07:14:20 ext Denis Kenzior, you wrote:
> Hi Kai,
> 
> On 01/11/2011 06:47 AM, Kai.Vehmanen(a)nokia.com wrote:
> > Hi,
> > 
> > On 10 Jan 2010, Rémi Denis-Courmont wrote:
> >> Currently, the call direction can only be inferred from the signals.
> >> This adds a property to keep it visible also from GetCalls().
> > 
> > just adding one more do { ++votes; } while(0) for this.
> > telepathy-ring needs this as well when it is (re)started and there
> > are existing calls:
> > https://bugs.freedesktop.org/show_bug.cgi?id=32990
> 
> I'm still waiting for someone to give me a proper usecase for how the
> Dialer UI is going to use this information.

The dialer UI is not going to use GetCalls anyway. It is going to watch the 
signals, or place the call itself. So this question makes no sense.

I am not interested in playing politics on whether Telepathy should be used or 
something, whether oFono should be the AT commands emulator or not, or whether 
some operator or UI requirements make sense. I am interested in getting my 
work done.

We know this is required for TP-Ring and required for matd. Besides, it's two 
line, it's consistent and it's clear.

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki