Home | Trees | Indices | Help |
|
---|
|
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
Inherited from Inherited from Inherited from |
|
|||
Inherited from |
|
OverviewThe bridge controls many "global" functionality, and in some cases may want to alter something in the main window or application. Also, and probably most importantly, the bridge serves as a universal interconnection between any class you want. It makes it incredibly easy for the open file menu to send a command to the ipython shell which is going to perform a command and then update the region and variable viewers.
|
OverviewThis method will load the contents of the configuration file: ~/.basin/client/general.conf These correspond to the general preferences found within the BASIN_preferences.Preferences class. This method is called upon the instantiation of the bridge as well as whenever the general.conf is overwritten by the preferences menu. |
OverviewThis gives the bridge a reference to the menubar. This isn't done during initialization since the bridge is created before the menu bar exists.
|
OverviewThis gives the bridge a reference to the menubar. This isn't done during initialization since the bridge is created before the tool bar exists.
|
OverviewThis gives the bridge a reference to the actions. This isn't done during initialization since the bridge is created before the actions exists.
|
OverviewThis gives the bridge a reference to the region viewer. This isn't done during initialization since the bridge is created before the region viewer exists.
|
OverviewThis gives the bridge a reference to the variable viewer. This isn't done during initialization since the bridge is created before the variable viewer exists. |
OverviewThis gives the bridge a reference to the dock. This isn't done during initialization since the bridge is created before the dock exists.
|
OverviewThis gives the bridge a reference to the status bar. This isn't done during initialization since the bridge is created before the status bar exists. |
OverviewThis gives the bridge a reference to the IPython Shell. This isn't done during initialization since the bridge is created before the IPython Shell exists. |
OverviewThis method returns the cursor to its former state. This means that you shouldn't change a cursor until it has been returned to its original state, because returning it twice has no effect. |
Bridge.CursorBusy (self) This method changes the cursor to a busy cursor. This should really only be called if the cursor is in a nromal state to begin with. |
Bridge.CursorBusy (self) This method changes the cursor to an open hand cursor. This should really only be called if the cursor is in a nromal state to begin with. |
Bridge.CursorBusy (self) This method changes the cursor to a closed hand cursor. This should really only be called if the cursor is in a nromal state to begin with. |
Bridge.Update (self) This is the updating function that should be used to perform an update across the entie basin_client. While the individual region viewer and free variable viewer have update methods, this should be the only point at which they are called. That being said, the roder in which they are called is of great importance. The Region Viewer must be updated first, then the free variable viewer. This is because the variable viewer has to check for aliases after it sets its cotnents up, and if the region viewer is not already updated, then it would be providing possibly false, and certainly old, results. As this operation can take some noticeable time, the cursor is changed to busy during this oepration. After the update is complete, the _lastUpdated member is also updated to reflect the ipython line number at which the client is updated to. This gets used because every few seconds a timer checks if an update is needed, by comparing this _lastUpdated member to the current line. |
Bridge.PopDrugItem (self) This will retrieve an item tacked onto the bridge from a drag operation. On top of that, it also erases from the bridge in a traditional "pop" fashion. |
Bridge.SaveIPythonSession (self) This method will create a File Saving dialog designed to save the contents of the IPython Shell's History to a log file. If the dialog is successful in getting a file name, it will save the entire contents of the history in clear text format, dis- regarding any formating that is actually seen in the IPython History. |
Bridge.Connect (self) This method should be called whenever the user makes a successful connection. This is done automatically through the Connection module. It will enable the command line for ipython, make everything aware that it is connected, and set the menu actions to reflect connectivity. The only real way to connect is via the Connection module, so there is little need for this method to be called anywhere else. |
Bridge.Disconnect (self) This method should be called whenever the user disconnects from the basin session. This can either happen manually by the user, or if the bridge's method Error deems it necessary to automatically kill the session. Generally speaking it looks for specific types of connectivity errors to decide if it should pull the plug on the session or if it will be ok. Manually killing the basin_start.sh session, along with segfaults within the C-code will result in this type of disconnection. This method really only disables the ipython command line along with clearing the region/variable viewers, and changing menu's to reflect a disconnected status. |
Bridge.parallelOn (self) This method simply makes the data viewers available as well as making the application aware that it is in parallel mode. This is not meant to change any behaviour, but rather reflect that state of the program. |
Bridge.parallelOff (self) This method simply makes the data viewers disabled as well as informing the application as to its non-parallel status. This method will not affect any real behaviour, but rather reflects the state of the program. |
Bridge.pythonStatus (self) This method will update the IPython status, which is displayed in between the command history and command lines of the shell. The status string is dependant on the status of basin_client's connectivity as well as its parallel status. Assuming it is both conencted and parallel, it will also inform the user of the number of nodes that it is currently working with in the session. |
Bridge.AddToDock (self, item) This method is generally called from the region or free variable viwer. It will send an item that it wants to send to the dock here first, since the viewers don't directly know which widget is currently docked (even though the user can obviously tell this). It will determine the proper widget in the dock to send the item to. This does not imply that the dock can actually do anythung with the item, that is up to the dock widget to decide. |
Bridge.makeParallel (self) This is just a method from the bridge to force the client into a parallel mode. If it already is parallel, it does nothing. |
Bridge.makeParallel (self) This is just a method from the bridge to force the client into a non-parallel mode. If it isn't parallel currently, it does nothing. |
Bridge.timerEvent (self, ev) In the Bridge's initialization it sets a timer event, currently for every 3 seconds. Every 3 seconds, this method is called. If the client is connected, parallel, and the user has nothing currently typed on the command line, it will go ahead and see if it needs to bother updating. In the bridge, there is a variable keeping track of the last updated line in the ipython shell. It will check that against a variable that keeps track of the latest relevant update line in ipython. This assumes that code in the ipython shell knows when it is and isn't relevant to updates. If it finds that its update line is less than the ipython's last relevant update line, then it will go ahead and perform an Update, as well as setting its newly updated lastUpdated variable.
|
Bridge.Error (self, _file, _class, _function, _message = "", silent) This error method should be called whenever ipython makes a boo-boo. It is up the the coder to determine if an error has occurred, I lazily do this by doing a quick search through the return string for error. All of the arguments are for the purpose of reporting where in this basin_client code that the error occurred in. Of course the error may have nothing to do with the client code, however, it is possible that the error occurred from a mal-constructed ipython command being sent to the ipython shell, in which case it is important. _file refers to the actual scrip file, _class to the python class it occurred in, _function for the method in the class it occurred. _message should be a copy of the ipython error received. Silent hasn't been implemented yet, but was intended to be a way of suppressing error messages to the user, while still logging them in ~/.basin/client/error.log |
Home | Trees | Indices | Help |
|
---|
Generated by Epydoc 3.0.1 on Fri Mar 21 09:10:08 2008 | http://epydoc.sourceforge.net |