You can check out current progress here. Notice the top toolbar (which looks great in my opinion) and beginnings of the HerdictWeb plugin. After some talks with the Berkman Center, we are finally moving forward with the HerdictWeb plugin. We are going to adapt an existing tor connection class we've previously made to allow for HerdictWeb reporting over Tor. On top of this, we are going to give an interactive, side-by-side comparison of the website over Tor and the website over the regular internet connection. In my opinion this is a large security risk (because for Tor, it is) but this is what they want, so this is what they get.
The toolbar may look nice, but its causing a few problems of its own. This is me moving the tabs. Notice the toolbar icons painting over the tab bar? This is a bug in Qt (we assume) involving the use of the setUnifiedTitleandToolBaronMac function for windows. By setting that function to true, we get the chrome statusbar and toolbar. But, when that function is set to true the tabbar gets a fresh coat of toolbar icons painted over it. As far as we can tell, outside of reimplementing parts of patching Qt there is nothing we can do about this. So, mac users can't move tabs! On top of this, when the user stops tor and the toolbar message changes, this happens. Where'd help go? The MainWindow apparantly picks a size for the ToolBar and sticks to it no matter how much space remains in the ToolBar space. Resizing it does nothing to stop this. So, mac users get only icons in the toolbar! And all this only happens if setUnifiedTitleandToolBaronMac is set to true. If this is set to false, these bugs don't occur but the window looks uglier. Decisions, decisions.
Thats all for updating right now. More coming soon!
Wednesday, July 22, 2009
Thursday, July 9, 2009
Significant progress
Its been about a month since I last posted so naturally there are a plethora of updates. As far as the interface goes, it is nearly at the point where it can be pushed aside to worry about other parts of the project. You can view a screen shot of it here. All of the tabs are plugins and the home interface is completely dynamic. The file menu and tray menu also allows plugins to have their own entries meaning the gui interface API is nearly feature complete. Remaining issues as far as that goes include allow plugins to have their own translation files (and subsequently implementing the re-translation API for the plugins) and figuring out how dynamic plugins will link their own platform independent resources.
As far as the API goes, we've had a number of significant design decisions we didn't originally know we were going to have to. Plugins as they stand are hubs for functionality. The home plugin for example includes a panel for viewing the home plugin with the tabbed interface, tray and file menus for quick access to functionality as well the catching and sending of a number of signals to and from the plugin manager. This requires for example the home panel object to be seperate from the home plugin object. Thus, when the home panel wants to send a torStart signal to the Plugin Manager (who handles such requests), the panel calls a function in the home plugin, who calls a function in the plugin manager. Even more awkward, since we want to seperate all of the plugin logic from the main vidalia logic (since we intend on shipping a plugin library to allow for dynamic plugin creation), the plugin manager can't send any messages to MainWindow since they are seperate. However, MainWindow can send messages to the plugin manager. Thus, in order to send a message to MainWindow, the plugin manager needs to emit a Qt signal which MainWindow catches. Any response from MainWindow is done by MainWindow calling a plugin manager function. At first I thought this reeked of terrible design, but then I realized its not too different from the system used by OS's for system calls.
At this point going forward myself and the Vidalia Project will be working on the plugin API and the HerdictWeb plugin simultaneously. There are enough pieces in place that this is easily doable. Hopefully within the next two weeks the HerdictWeb plugin will be nearly complete. Check back in to find out!
As far as the API goes, we've had a number of significant design decisions we didn't originally know we were going to have to. Plugins as they stand are hubs for functionality. The home plugin for example includes a panel for viewing the home plugin with the tabbed interface, tray and file menus for quick access to functionality as well the catching and sending of a number of signals to and from the plugin manager. This requires for example the home panel object to be seperate from the home plugin object. Thus, when the home panel wants to send a torStart signal to the Plugin Manager (who handles such requests), the panel calls a function in the home plugin, who calls a function in the plugin manager. Even more awkward, since we want to seperate all of the plugin logic from the main vidalia logic (since we intend on shipping a plugin library to allow for dynamic plugin creation), the plugin manager can't send any messages to MainWindow since they are seperate. However, MainWindow can send messages to the plugin manager. Thus, in order to send a message to MainWindow, the plugin manager needs to emit a Qt signal which MainWindow catches. Any response from MainWindow is done by MainWindow calling a plugin manager function. At first I thought this reeked of terrible design, but then I realized its not too different from the system used by OS's for system calls.
At this point going forward myself and the Vidalia Project will be working on the plugin API and the HerdictWeb plugin simultaneously. There are enough pieces in place that this is easily doable. Hopefully within the next two weeks the HerdictWeb plugin will be nearly complete. Check back in to find out!
Subscribe to:
Posts (Atom)