[Bug 47100] add a way to create accounts with properties, without knowing property names/namespaces

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47100

--- Comment #18 from Jonny Lamb <jonny.lamb at collabora.co.uk> 2012-05-09 02:51:01 PDT ---
(In reply to comment #15)
> Strictly speaking you should use _TP_AVAILABLE_IN_UNRELEASED but this will be
> part of 0.20 so that's fine.

Oh yes, good point. Oh well, I'll leave it now.

> (In reply to comment #13)
> > Well, so is every other symbol? I thought Since: things were only useful for
> > methods added to objects where the object has existed for a while. I added
> > Since: UNRELEASED for the main TpFutureAccount header. Adding Since to each
> > symbol/property makes it feel like there is one which isn't the same version as
> > the others, which is wrong. What do you think? I can add them if you feel
> > strongly about it.
> 
> I generally add it to all the API if only to be exhaustive and I think GLib
> does as well.

Fair enough, done.

> Cool, now you just have to review and fix all the code you wrote these last 3
> years.

http://jonnylamb.com/lol.gif

> > Well I wondered what to do about this. You think I should make _set_ and
> > _create_account be no-ops if the account has been created?
> 
> Or at least raise a warning as in tp_future_account_create_account_async().

OK, let's add some g_return_if_fails.

> http://cgit.freedesktop.org/~jonny/telepathy-glib/commit/?h=future-master-47100&id=09ece4e16b3a8b99d92a9f48610d92949edfa732
> 
> Looks a bit weird to me. I think we should either requires users to pass the
> display name when constructing the object or have a sensible default.
> Empathy uses (the first where we have the data):
> - $service ($param-account)
> - $param-account
> - $protocol account
> - New account

Yeah I think you're right. We can't have a default as it should be localised,
so we could just require the display name and get empathy to have a good
localised fallback? Okay done.

> Consistency is good indeed. I opened bug #49616 to consider changing this in
> next.

Exciting.

> Did you try valgrinding the test to check for leaks?

I hadn't actually. I just did now and found another leak in the simple account.

(In reply to comment #16)
> You forgot to add API to set TP_PROP_ACCOUNT_SERVICE.

I was hoping no-one would notice. Done.

> Add G_GNUC_WARN_UNUSED_RESULT for (transfer full) functions ?
> tp_future_account_create_account_finish and the _new().

It's already there for _new() but yes I forgot for _finish.

(In reply to comment #17)
> I ported Empathy

Do you want a medal?

> As I said in Comment 12, it would be ace to be able to get rid of
> EmpathyAccountSettings (or at least removing most of its code). I'm not saying
> that TpFutureAccount is the right answer to that but I think we should at least
> considering it.
> Should TpFutureAccount be renamed to TpAccountSettings and basically turned to
> EmpathyAccountSettings?

Well, this kind of has a different purpose, doesn't it? If you could file a bug
with your exact requirements listed that would be really useful.

btw I'm going to strongly veto the name TpAccountSettings for this object as it
is now as it's completely misleading.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.