Re: Empathy: No protocol installed

(Shaun, you get double mail, I forgot to reply all. Sorry guys.)


2009/8/24 Shaun McCance <shaunm gnome org>:
> If you don't have any Telepathy backends installed,
> the Accounts dialog gives tells you this:
>  No protocol installed
>  To add a new account, you first have to install
>  a backend for each protocol you want to use.

good catch... I happen to have all the protocols installed, and Ubuntu
has some of those protocols as default.

> Should we add a page for this?

Yes, I think we need to add a page about that.

> Is this something
> we can even talk about in a generic way, or is it
> too distro-dependent?  Are enough distros using
> PackageKit that we can talk about that?
> I suspect most distros install at least the Jabber
> backend by default, if they install Empathy, so
> this error is probably rare.  But we might need
> generic instructions for installing backends to
> reference from pages for IRC or other protocols
> that might not have backends installed by default.

I have been looking at the packages naming convention of three
distros: Debian [1], Ubuntu [2] and Fedora [3].

Those three distros use the same package name for all telepathy stuff, namely:

telepathy-salut (Salut support)
telepathy-gabble (XMPP/Jabber support)
telepathy-idle (IRC support)
telepathy-sofiasip (SIP support)
telepathy-butterfly (MSN support)
telepathy-haze (support for Pidgin libpurple)

I don't know if we can generalize and use those names in the help,
since there might be a distro that has a different naming scheme.

Ubuntu has a telepathy-gnome package that should install all the
necessary, didn't find it in Debian nor in Fedora.

Anyway, I wouldn't rely solely on the package name, what I would
really like to see here is downstream plugging into the documentation
what they need in order to address the differences that exists between
upstream and them.

2009/8/24 Shaun McCance <shaunm gnome org>:
> All right, this makes me think of something else.  Going
> forward, is there a way we could have a set of pages we
> expect distros to provide?  So we could say something
> like this:
>  See <link xref="gnome-desktop-help#installing-packages"/>
>  for information on installing packages.
> And we wouldn't provide the installing-packages page,
> because we can't, but it's an extension page that we
> expect distros to provide.

I really love the idea.

What I'm thinking of right now is how Ubuntu ships GNOME
documentation: it's kind of a separate set of documents. If you browse
Ubuntu docs you have the Ubuntu specific docs, plus a couple of
sections where GNOME user guide sections are linked, but they are not
really part of the same set of docs. Sometimes they feel separate and
there might be differences in the way they are written. Ubuntu has an
"installing-package" topic, a rather big one too. Maybe they would
like to link that one instead of the GNOME specific one, or they might
need to rethink that section.

There might also be translations problems: some distros don't touch
upstream translations, in this specific case Ubuntu does handle g-u-g
translations because it has been customized, I don't know other
distros how they handle such things, or how they ship upstream docs
and all that stuff (does Fedora ship the g-u-g?).

> Maybe we should provide those pages with crappy stub
> content, and tag them in some way to say "Hey, distros,
> replace me!"  And they could grep for that tag.

I think we should provide a stub page that distros need to take care
of, but what about distros that rely only on upstream documentation or
that don't have an active documentation team (or a translation team)?
Can we have a way to hide those pages by default? (maybe using
revision and status: if status != review|final|complete don't show it;
if  there's no revision, show it by default; downstream should then
take care of modifying that value).

Don't take me wrong, I really really love this idea. Those are the
problems that I think we might face implementing it, but I'm also of
the idea that if we want to give users the best experience ever, we
need to go on with our ideas.



Milo Casagrande <milo casagrande name>

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