Perspectives for the biocep workbench
By romain francois on Sunday, February 22 2009, 11:44 - Permalink
The need for perspectives
The virtual R Workbench of the biocep project uses Info Node as a flexible docking framework, giving the possibility the move parts of the user interface (called views) anywhere. However, views have be to moved manually each time to reconstruct the layout you are using, which to me is one major usability misfeature of the workbench. At the moment, workbench plugins add views by calling the createView
method of the RGui
interface, which adds the requested view next to the Working Directory view of the workbench.
As an example, if I add the view supplied by this tutorial, it appears as this:
and unless your plugin uses tricks, that is the only place where the view can be added, and you have to move it around to compose the layout you want to use. This is fine if your plugin only defines one view, but if you define many views (such as the power editor plugin), then asking the user to arrange the views each time is not so great.
Typically, programs using flexible docking frameworks (most notably eclipse) also use perspectives as a way to save and load the layout of the user interface.
Perspectives for the power editor
I have added support for perspectives in the power editor so that the many views supplied by the power editor are arranged in a useful way when the plugin is started, which can be configured by the user. Here is the default layout:
That is stored in this xml file in the pesrepectives directory of the Editor plugin
1 <RootWindow> 2 <WindowBar direction="Up" /> 3 <WindowBar direction="Right" /> 4 <WindowBar direction="Down" /> 5 <WindowBar direction="Left" /> 6 <SplitWindow horizontal="true" dividerLocation="0.2"> 7 <SplitWindow horizontal="false" dividerLocation="0.5407166"> 8 <TabWindow selected="0" direction="Up" tabAreaOrientation="Left"> 9 <JEditDockableView name="vfs.browser" title="File Browser" /> 10 <JEditDockableView name="projectviewer" title="Project Viewer" /> 11 </TabWindow> 12 <TabWindow selected="0" direction="Up" tabAreaOrientation="Left"> 13 <JEditDockableView name="robjectexplorer" title="R Objects Explorer" /> 14 </TabWindow> 15 </SplitWindow> 16 <SplitWindow horizontal="true" dividerLocation="0.75"> 17 <SplitWindow horizontal="false" dividerLocation="0.7654723"> 18 <TabWindow selected="0" direction="Right" tabAreaOrientation="Up"> 19 <JEditView /> 20 <View title="R Console" urls="/opt/biocep/biocep.jar" class="org.kchine.rpf.gui.ConsolePanel" /> 21 <View title="Main Graphic Device" class="javax.swing.JPanel" /> 22 </TabWindow> 23 <TabWindow selected="0" direction="Right" tabAreaOrientation="Down"> 24 <JEditDockableView name="console" title="Console" /> 25 <View title="Working Directory" class="javax.swing.JPanel" /> 26 </TabWindow> 27 </SplitWindow> 28 <SplitWindow horizontal="false" dividerLocation="0.66"> 29 <SplitWindow horizontal="false" dividerLocation="0.5124378"> 30 <TabWindow selected="0" direction="Down" tabAreaOrientation="Right"> 31 <JEditDockableView name="sidekick-tree" title="Sidekick" /> 32 </TabWindow> 33 <TabWindow selected="0" direction="Down" tabAreaOrientation="Right"> 34 <JEditDockableView name="hypersearch-results" title="HyperSearch Results" /> 35 </TabWindow> 36 </SplitWindow> 37 <TabWindow selected="0" direction="Down" tabAreaOrientation="Right"> 38 <JEditDockableView name="error-list" title="Error List" /> 39 </TabWindow> 40 </SplitWindow> 41 </SplitWindow> 42 </SplitWindow> 43 </RootWindow>
Implementation of perspectives in the power editor
I have recently added support for perspectives in the power editor (this feature should really belong to the biocep project itself, but is not high priority to the author at the moment) by using XML. For example, the default layout that appears when the workbench is started
can be represented by this perspective
1 <RootWindow> 2 <SplitWindow horizontal="true" dividerLocation="0.2"> 3 <View title="R Console" 4 urls="/opt/biocep/biocep.jar" 5 class="org.kchine.rpf.gui.ConsolePanel" /> 6 <SplitWindow horizontal="false" dividerLocation="0.5407166"> 7 <View title="Main Graphic Device" class="javax.swing.JPanel" /> 8 <TabWindow selected="0" direction="Up" tabAreaOrientation="Up"> 9 <View title="Working Directory" class="javax.swing.JPanel" /> 10 </TabWindow> 11 </SplitWindow> 12 </SplitWindow> 13 </RootWindow> 14 15
Basically, each node of the XML represents one info node window below the root window. Info Node defines a class for each type of window, see the api for the net.infonode.docking
package. Theses are of particular interest:
- RootWindow: top level container for docking windows
- SplitWindow: A window with a split pane that contains two child windows
- TabWindow: A docking window containing a tabbed panel
- View: A docking window containing a component
The implementation of perspectives that is available in the Power Editor plugin relies on two classes for each docking window class, a class that is responsible for exporting the view to an XML node (called FooExporter if the docking window class is Foo), and a class that is responsible for reading the XML representation and recreate the window from it.
The implementation provides importer and exporter classes for all Info Nodes docking window classes, most importantly classes ViewExporter and ViewImporter that dumps the sufficient information about the view into XML and reads this information to recreate the view. Plugins are encouraged to create classes that inherit from View, say MyPluginView and create the classes MyPluginViewExporter and MyPluginViewImporter to handle the information that this view need to store sufficient information as attributes of the <MyPluginView> node
The exporter is the easiest to implement, all the MyPluginView
class needs to do is extend the DefaultExporter
class and use the setAttribute
method somewhere in the constructor. As an example, the constructor for the JEditDockableViewExporter
looks like this:
13 /** 14 * Constructor for the ViewExporter 15 * 16 * @param window The View to stream to XML 17 */ 18 public JEditDockableViewExporter( JEditDockableView window){ 19 super( window ) ; 20 setAttribute( "name", window.getName() ) ; 21 setAttribute( "title", window.getTitle() ) ; 22 } 23
... so that the <JEditDockableView> node will have the attributes title
and name
To implement custom importers, the easiest way is to extend the ViewImporter
class and define the newView
method that takes no parameter and builds the view from the attributes, the DefaultImporter
defines the
getAttribute
method that can be used to retrieve an attribute from the xml node. See the implementation of newView
for the JEditDockableView
class below:
28 /** 29 * Creates the JEditDockableView 30 * 31 * @return the JEditDockableView for the <JEditDockableView> node 32 */ 33 @Override 34 public View newView( ) throws Exception { 35 return new JEditDockableView( name ) ; 36 }
Future
At the moment, this feature is implemented in the Power editor only, and even if it could be used outside of it by using some tricks, the best course of action is probably to add the feature into the biocep workbench itself so that all plugins can take advantage of it and potentially arrange views from other plugins as well. We can also imagine these features
- user specific perspectives
- restore the perspective of the previous session
- plugin specific perspectives
Comments
I, for one, cannot stand to work within the constraints of the workbench. Have you considered that the average R user may be a power user and have all kind of keyboard shorcuts and customizations in his R environment/editor?
The fact that the workbench does not allow kb shortcuts and forces 'tiling' window arrangements is really a turn off for me. And I find the jedit editor too slow scrolling around, to a point that I cannot stand it.
Ideally, I'd like to use all the nice features of the workbench from my own editor and under my own terms (I also like html help and graphics popping out in indepenent windows)
Thanks!
Hi Jose,
I agree with you that the workbench should allow keyboard shortcuts, this is a feature request you can send to the main biocep. http://r-forge.r-project.org/tracke... which I am not responsible for.
Jedit, on the other hand, allows for keyboard shortcuts, so when you are on the main jedit window, you can customize it to perform any kind of power user stuff. You acces this via Utilities > Global Options > Shortcuts. See this section of the jedit manual http://www.jedit.org/users-guide/gl...
I am happy to show you around if you define what sort of keyboard shortcut you have in mind.
The workbench allows to float windows (see the screenshot below), which might do what you want, otherwise please let me know what is it that you are looking for.
Jedit works fine for me, it might not have the speed of vi or emacs, what editor are you using and can you point areas in which jedit is too slow. Again, you might want to consider sending a request to jedit tracking system http://sourceforge.net/tracker/?ati...
If you want to use the features of the workbench outside of the workbench, it is possible just include the biocep.jar file in your classpath. What features do you want to borrow, in which editor, I really cannot help you if are not more specific ...
As far as the power editor is concerned, most of the features are (on the R side) implemented in the svTools package part of the sciviews project. http://r-forge.r-project.org/projec...
Like Jose, I find the UI of the biocep workbench its biggest drawback: no keyboard shortcuts, no toolbars, no integration of jEdit menus in the main menu bar, etc.
Biocep is really promising in terms of architecture and has some great components, which are being greatly improved in your power editor plugin. Nevertheless, I'm not sure it will really get a decent UI.
It's a real pity that the Biocep workbench did not use the Eclipse framework (the author told us in a conference that it would have taken much longer, as Eclipse is much more complex): elements like the perspectives you're adding are already there, and I find the base editor environment provided by Eclipse+StatET much more compelling... Joining both projects would be my dream
Great work.
Hi Enrique,
I do agree that flexible keyboard shortcuts are missing (and at the very least mnemonic shortcuts for the menu), I have some ideas on how this could be added, basically borrowing some concepts from the jedit API
I already have asked for toolbars, it would be a good improvement, look more like many applications around, and instead of having toolbars in each view, a central unique toolbar would be nice, plugin could register their toolbar, ... this is also a feature request for me
When I first worked on the power editor, the jedit menu appeared on top of the jedit view, which did look weird, and I was advised that this was not good design and that views should not have menus. My workaround was to integrate the jedit menu within the toolbar (the button with the jedit icon contains the jedit menu). Similarly to the toolbar, having the menu configurable would be a good.
The core biocep functionality (communication with R, ...) is independent of swing and could easily be integrated into RCP/eclipse to use eclipse components and architechture. I am coming from an angle of having used jedit for many years and being very happy with it. I am also aware of the Stat/ET plugin, I (for one) don't like eclipse, and am not very familiar with the RCP platform, but I am also aware that the reason why so many R GUI projects have failed is that because there are so many of them, so I would consider joining forces with StatET if I get convinced.
My idea is to keep going with the biocep and let the StatET plugin improve as well, and at some point maybe join forces.
Some of the functionality I am doing for biocep are implemented in R code, and can potentially used in other platforms (I actually am using some of the R code in the sciviews project http://www.sciviews.org/SciViews-K/...)
The next big thing for me will be implementing a debugger for R code within the power editor. I probably will need extra support to do it. I am considering submitting this as a Google Summer of Code project, but what I would really like is to hire someone to share that load, but I need some funding first
The ui of biocep somewhat suffers from swing, but also (and most importantly) suffers from the lack of a good, clear, and well documented design. The code of the ui needs a lot more abstraction than it currently has. As an example the main class the the workbench ui contains about 5500 lines of code, and does everything from creating the menus, create the view, connect to R, .... I am not a java programmer, but this looks too much to me and the same functionality should be implemented by several classes with a clearer design that would be easier for other people to get into. I have made private proposals to karim, for example I offered to implement perspectives in biocep directly, but there will be no commiters in biocep for some time because it might lead to unstable code.
I personally believe that with a sensible design encouraging extension points, the biocep UI could be a winner. I am showing this work at useR this year (if the not yet submitted abstract gets accepted). If many people share your fealing about the ui (which to be honest was my first reaction as well), then I will consider alternatives, I do not want this to end on yet another failing R gui project
Hi Romain, thanks for your detailed answer! Very interesting discussion.
I've been long looking for editors/GUIs for R, and after a long time programming interfaces using COM technology, after trying Biocep & StatET I'm now sold on Java as a much better solution.
I'm a special kind of user as I only use programs that allow me to do almost everything with the keyboard (RSI is a serious problem for me). As much as I liked the Biocep workbench when I tried it, I find it really unusable as it is. And I feel that it still needs a long way to go before plugins can really be "integrated" (common menus, toolbars, etc.) which I feel as an absolute must to offer a true GUI.
I find that "views should not have menus" a bad design choice. While it may make some sense from a "pure" architectural point of view, it's an irrelevant constraint for users. A programmer-centric design instead of user-centric, is a big drawback of many programs, in my opinion. For users of the workbench, an R editor (be it the default or the power one), an object browser, etc, are primary components, and its functionality should be accessible via integrated (main) menus and toolbars, whether they're implemented via core functionality or via plugins (as a user, I don't care how they're implemented!).
Also as a user, I much prefer SWT to Swing. More responsive and with its native-look & behaviour, I find it was the piece that was missing to have really good Java GUIs.
Biocep is a bigger project, and the Workbench is only a part of it. As such, I'm not sure it will reach a state that it can behave both as a full R programming IDE and as a GUI, which is what I would dream of. My feeling is that Biocep is much stronger in the architectural aspects (connections to R, web services, mapping of R-to-Java objects...) than Eclipse+StatET, but that it is seriously lacking in the IDE & GUI framework portions.
At the moment, what I would love to have is the base IDE power of Eclipse (as that is the only usable alternative to me now), with some of the components of the Biocep workbench/power editor -like the object browser, or the integrated plots. I'll likely make a try to integrate some of them myself in the future, being both open source. At the moment I'm just trying to understand both Eclipse plugin development, and the source code base of Biocep.
Best regards,
Enrique
Hi,
I agree with Enrique in all his points (but one: I despise Eclipse ). I look forward to that presentation at useR 2009.
One other contender is JGR. The way it completes functions and suggests parameters in the command line is awesome.
I'm currently using vim + self-backed shortcuts to send things to an independent R window.
Another (very!) interesting alternative is NetBeans. I think it's way more usable than the abomination that eclipse is, and it's also open-source.
The only qualm that I have with Jedit is that is horribly slow scrolling. I disabled all plugins and if you go up and down with the arrows (I have them mapped to bypass OS limitations; they send more keypresses than expected when kept pressed) you can see Jedit cannot cope. Other than that, a very nice editor.
Hi Jose,
JGR has several features I like, all missing from StatET but available or under development in Biocep or the power editor plugin:
- Function completion (see http://romainfrancois.blog.free.fr/... )
- R object browser
- Plots / iplots integration
- Data editor
On the other hand, while JGR is a nice GUI, it lacks the "workbench" features of StatET & Biocep, which are key factors to me:
- Multiple R connection options (local / remote, console / R GUI, etc.)
- IDE features, specially for package development (templates, projects, workspaces, perspectives...)
- A windowing / docking framework
- A plugin arquitecture for user extensions and building custom GUIs
Regards
to top enrique comment about completion in JGR and biocep, the way the biocep does it (in the power editor) is based on the mechanism R uses for completion (same as the standard R console) with tiny layer above to fetch information about each completion item (available in the svMisc package of Sciviews). JGR uses heuristics instead. I do believe the one I amusing is better.