Hi! intrigeri <intrig...@boum.org> wrote: > Alan wrote (20 Feb 2015 19:43:10 GMT) : > > On Thu, 19 Feb 2015 14:23:03 +0000 > > sajolida <sajol...@pimienta.org> wrote: > >> intrigeri: > >> > sajolida wrote (18 Feb 2015 11:32:17 GMT) : > >> >> intrigeri: > > [About the green onion] > > >> >> but would it be conceivable to have Tor Monitor > >> >> appear as green onion on the desktop as Vidalia does until now? > >> > > > I don't think it's the way to go: > > > - I'd like Tor Monitor to stay a generic application, with a clear > > focus on being a monitor for Tor and showing whatever icon on the > > desktop doesn't look like the same task for me. > > IMO the "providing feedback regarding Tor connectivity status" feature > fits pretty well into the "monitoring Tor" mission. Perhaps we don't > put the same meaning behind "monitoring Tor". > Ok. You have a point here. This could be argued as some "desktop integration" of the application.
> Now, I do appreciate that you have a strong vision for what Tor > Monitor should be, and this is very useful to avoid feature-bloating > it :) > > > - System Tray Icons were deprecated in Gtk since 3.14. A proper > > implementation of this "green onion" for GNOME 3 desktop would be a > > (very simple) Shell extension, to which "we" (the NetworkManager > > hook) should send a DBus signal (or the opposite). That might be a > > tiny funny project. > > Ah, right. And glad you find it potentially funny :) > > IMO, that Shell extension could very well be shipped in the same > upstream project as Tor Monitor, at least to start with: it would > benefit GNOME Shell users who would only have to install one single > package to get everything they need. And it wouldn't prevent the DBus > interface from being well-documented, stable, and re-usable by other > kinds of user feedback providers, be them desktop indicators > or whatever. > That makes sense. > > I'm not opposed to exposing a DBus interface in a future version of > > TorMonitor to provide the "green onion" or other applications more > > information that our hooks could. But I'm not sure it is the right > > place to do it yet. > > What would be a better place to do it in your opinion? > In my opinion, the easiest method to replace vidalia's green onion would be to write a very small GNOME Shell extension that would listen to a very simple DBus service. The very same mechanism that currently displays the "Tor is ready" notification in Tails would trigger a notification to this DBus service that would update this onion. I admit this would be very Tails specific. > (/me enters Alan's-mind-reading mode, let's try to guess what your > answer could be :) > > I can imagine that we have a totally separate backend that monitors > Tor's connectivity status Please note that I'm not aware of such a concept of "connectivity status" in Tor. If you know about it, don't hesitate to point me to relevant documentation. > and sends DBus signals that e.g. a GNOME > Shell extension can receive and then provide feedback to the user. > I can see why there is no technical reason to couple this specific > feature with the rest of Tor Monitor's codebase. However, splitting it > out has a few clear disadvantages: > > 1. That's one more (presumably Python) process to run, which eats > memory etc. If there were a Tor controller C library, we could use directly from the extension through GI by writing a .typelib file for the interfaces we need. However, I didn't find such a library. So yes, we'd need a Python (of whatever language that has a Tor controller library) process running. > Of course, if we go this way, then we don't have to > run Tor Monitor by default, so it's only one *more* process for > users who manually start Tor Monitor, but still. > Looks to me that you basically destroyed you own argument... > 2. I suspect that this program will be doing very similar things to > Tor Monitor under the hood, and then we may quickly have more code > duplication than reasonable. > If we only care about "connectivity status" I'm very unsure that there would be code duplication. > 3. For anyone who runs both Tor Monitor and that backend process, > we'll be putting additional load on the Tor control port. No idea > if/how it's measurable in practice, perhaps Stem's polling loop is > so efficient that it's not. > No idea either. > 4. That's one more upstream project to manage, release, tag, package, > import, etc. => not sure the overhead is worth it. > Good point. > Granted, none of these arguments is very strong, except perhaps the > last one. If that backend program + Shell extension were shipped in > the same upstream project as Tor Monitor, then #2 and #4 are done > with, and I'm happy. Maybe we can reach a consensus on this design? > I'd agree on that. But I'm not opposed either on integrating a DBus interface more strongly in the current Tor Monitor application if: - it proves to be actually useful; - I get some help with the programming design. If you have a look at current code, you'll see that UI code is highly mixed with communicating with Tor. That didn't look ugly to me as stem already implements most of the logic. But to expose the same (or a subset of) this data on DBus, we'd need to redesign this a lot. An advantage if such an approach is that there is no reason why the DBus service would run the same unix user as the UI. So if the UI would only get its information from the DBus service, then we don't need any access to the Tor control port for the user running the UI. 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; 2. through a DBus service that would be a separate process that the Tor Monitor application (but managed in the same project); 3. through a DBus service that would be tightly integrated in the Tor Monitor application. Cheers _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
