[vidalia-users] Vidalia and IRIX

[Matt Edman]

On Tue, Feb 17, 2009 at 02:05:52PM +0000, Matthew Saunier wrote:
> 	Hello, all. I've been working on porting Vidalia to IRIX, and have a 
> patch that allows Vidalia to compile with MIPSPro.
>
> 	It turns out to be pretty trivial, there's one spot where a variable 
> is redeclared in a foreach, which was no good - the fix there was to  
> change the variable name in the foreach. The other issue is that  
> SGI's math library handles floor differently, so I had to change  
> floor to trunc in the 4 places where it's used.

Thanks for the patch. I took a quick look through it and noticed a couple
things. Your changes to servicesettings.cpp were actually made in Vidalia
trunk in r3235 back in October 2008. Unforuntaely, it never got backported
to the 0.1.x branch. I've done that just now. Thanks for pointing that out.

Second, your changes to tormapwidget.cpp don't actually apply to trunk
since the map-related files moved around a bit with the recent integration
of KDE's Marble widget. It's usually best to make sure a patch applies to
SVN trunk, rather than a previously released tarball.

Also, the switch from floor() to trunc() changes the results slightly. The
differences may not be enough to affect relay placemarks locations much,
but I'd like to avoid changing the behavior if possible. Can
you paste the build errors that you get when trying to build without
patching tormapwidget.cpp? Does IRIX prefer a different function that does
the same thing as floor()? 

> 	The larger issue is that while Vidalia compiles and runs, our window 
> manager, 4Dwm, is pretty close to being plain X11, and as such has no  
> concept of a notification area. I've poked around some, and it looks  
> like Vidalia wants to minimize to the tray / dock upon startup. The  
> result is that while any initial dialogs (could not connect to Tor,  
> etc) pop up and Vidalia starts Tor properly, there's no way to get to  
> the GUI. Our Qt implementation simply gets rid of the window, with no  
> way to get it back.

This is odd. If you look in mainwindow.cpp, Vidalia asks Qt if the current
window manager supports a system notification area. If it doesn't, Vidalia
will remove the "Hide" button and "Show this window on startup" checkbox,
and always show the main window. Perhaps Qt's
QSystemTrayIcon::isSystemTrayAvailable() is lying on your window manager?

Does your ~/.vidalia/vidalia.conf have a line in it that starts with
"ShowMainWindowAtStart"?

> 	I think that the hack for this is to hard-set the "Show this window  
> on start" pref in the code that reads the preferences, but the proper  
> solution would be either to check the host type for IRIX at startup  
> and have an if-then at every point in the code that minimizes to the  
> notification area , or to add the option when Vidalia is invoked from  
> the commandline while it is already running to connect to the  
> existing instance. In other words, change the window from "There is  
> another instance of Vidalia running, are you sure you want to start  
> another one?" to  "There is another instance of Vidalia running, do  
> you want to start another one or do you want to connect to the  
> running instance?", which would send a signal to the running Vidalia  
> to pop up the GUI. (Sidebar: Is SIGHUP used in Vidalia? That'd seem  
> to be a logical choice...)
> 
> 	Anyway, I don't know if this is the right place to discuss code  
> changes - if it isn't, let me know. I'd like to join as a  
> contributor, but all I'd want to do is get it running properly on  
> IRIX and test new releases. 

Great! I'm always happy to have more contributors. The best place for
development discussion is usually in our IRC channel (#vidalia on
irc.oftc.net). It's more active than this mailing list, and most of the
development discussion happens there.

--Matt