Hi,
intrigeri <intrigeri@???> wrote:
> Alan wrote (06 Mar 2015 21:04:46 GMT) :
> > intrigeri <intrigeri@???> wrote:
> >> Now, in the first iteration, the information we want to convey to that
> >> Shell extension is exactly one bit ("Tor is ready", and possibly "Tor
> >> is down" on network post-down).
>
> > Really? I though we wanted bootstrap progress too, that current
> > vidalia's onion provides (no onion/red > yellow > green)
>
> Sadly, this assumption is not correct... which gives us yet another
> demonstration that even *we* don't understand what these colors are
> about (hence my doubts about whether it's really useful, but
> thankfully I've given up on arguing about that already). In current
> Tails:
>
[...]
Thanks for the explanation.
> The only information in there that is about Tor's bootstrap progress
> is "display an onion at all, or not", which is 1 bit of information.
> The rest is about Vidalia's own bootstrap progress.
>
OK
> I don't think that the onion Shell extension needs to differentiate
> between cases (b) and (c): IIRC we want it to provide some way to
> start Tor Monitor, and then Tor Monitor can itself convey to the user
> any relevant message regarding its own bootstrap status, that is how
> much it's ready to display complete information. As I understand it,
> we want the onion icon to say something about the state of Tor, not
> about the state of Tor Monitor.
>
There is no such concept op tor monitor bootstrap anymore, so let's
stop thinking about this.
> So, we don't need to convey any additional information to the onion
> Shell extension than "we've started you, display that green onion" and
> "stop displaying that green onion" (possibly by disabling the
> extensions altogether).
>
> Thoughts?
>
OK
> >> An alternative, for the initial iteration, is to do exactly what we're
> >> doing now: when we display "Tor is ready", simply enable the Shell
> >> extension that displays the green onion. And disable it when the
> >> network gets disconnected. This way, we don't even need any
> >> communication channel :)
> >>
> > This can be done by changing a GSetting. I do not find it very elegant
> > to change a setting at each network status change, but it may work. I
> > didn't found a DBus interface to enable/disable extensions. At first
> > glance, I think DBus might still be the more appropriate.
>
> I don't understand why,
Because a GSetting is not meant to be changed programatically in
response to the state of the world. It's a setting.
> but I guess that's probably a matter of
> taste... and it now seems clear that our personal taste differs a lot
> regarding what's an appropriate IPC mechanism to convey one single bit
> of information. Now, if there's any technical reason why you still
> prefer using DBus, I'm all ears :)
>
I don't prefer DBus, I'm only reluctant to change a setting. Monitoring
a file or any proposal that doesn't obviously misuse a system (e.g. the
GSetting) would suit me.
> > Tor always tries to build circuits, so it has circuits in "launched"
> > state. We could consider Tor as "connected" as long as it has at least
> > one circuit in "built" state.
>
> This seems worth trying, but doesn't seem necessarily part of the
> first iteration about replacing what we have currently (since we don't
> have that feature yet).
>
> >> > To sum up, I see three options (on order of complexity) to feed this
> >> > GNOME shell extension that would provide the onion:
> >>
> >> > 1. through the same mechanism that displays the "Tor is ready"
> >> > notification;
> [...]
> >> I say let's go with (1) as far as #6841 is concerned.
> >>
> > I agree it's the easiest way to start with.
>
> Oooh yeah. Are you interested in taking care of this Shell extension?
Yes.
> Do you want me to file whatever tickets are needed about it?
>
I'd appreciate it.
Cheers
