Mar 18, 2009

Searching Eclipse Bugzilla

There are many times you would want to search for a bug, say with a class name / stack trace. Using Bugzilla for this kind of searches is really painful. First the UI that it presents is not an elegant one (esp. if you are used to one single text box of Google) and then its very slow. It would have been much better if our Bugzilla allows Search Engines to index, but its still a work in progress. Meanwhile, Gunnar Wagenknecht has come up with an incubation project that allows searching the bugzilla. It just features one text box as opposed to the Bugzilla:

Eclipse Bug Search

and you can type in the Bug Number or key words (like 'About Dialog') or a class name and search. Results are usually within a second. Whats even more nice is the right side bar, which has a tag-clouds-style attributes of the bug:

Eclipse Bug Search Tags

Click on the items and it will filter your results accordingly:

Eclipse Bug Search Filters

If you use Bugzilla frequently, this is very effective tool and I strongly recommend you to try it.

Mar 14, 2009

Do you need PDE custom attribute?

One of the features that I was very eagerly expecting in 3.5 M6 is PDE's Custom Attribute. As of now, the Manifest editor has very limited ways of editing an attribute in the plug-in. It could be either String/boolean/Java/Resource/Id. What if PDE provides an extension point and you could plug in your own controls in the editor? Well thats exactly the Custom Attribute feature that I'm talking about. I've been playing it with for a while, and its awesome. The possibilities are really endless and here are some samples:

Pick your favourite color:

Color Picker 

Select the SWT Platforms you support:

SWT Platform

Choose an icon from your plug-in or shared images:

Image Chooser

Or the best I've seen - define the location URI for a menu/toolbar contribution:

Location URI

You can even provide auto complete in the text editor tab:

This feature is not just cool one, but also a useful one and will boost productivity. Its very unfortunate that it slipped this milestone (M6) due to work load. Its even unfortunate that beyond M6 no API/extension point can be added. What this means, we have to wait till 3.6 (released in 2010) to get this feature. Or somehow convince *everyone* that its should be pushed into 3.5 itself. Martin says "that is not impossible",  and the way is: "to go through the process (e-mail and public discussion on eclipse-pmc list)". As everyone is busy with EclipseCon, I think that this process would start after EclipseCon.

Meanwhile, if you like this feature and want it in 3.5 itself, why don't you vote for this bug? I'm sure community's voice will be heard. If this gets into next milestone, I'll promise that I'll write a tip on how to use this extension point :-)

Mar 11, 2009

Eclipse Search - now with an Eclipse Plugin!

 

Searching for Eclipse related material in Google is a painful task. It shows up lots of irrelevant results. With Eclipse Search, this was pretty much eliminated. It searches only our Eclipse related sites and provides relevant results. The results are even categorized into Blogs, Source, etc. To make things simple, I added a search plugin for the browsers. This helps to search help right from your search box of your browser. Still this has one problem - you need a browser to search. You need to copy & paste the class/method name from your Eclipse to Browser and start searching. Switch back to Eclipse and resume the work. Now this can be simplified by a search plugin for Eclipse.

Eclipse Search

 

When you open Search Page, you can see an Eclipse Search tab there. You don't even need to copy a text for searching - just a selection would do. The plug-in takes the current selection as the initial input. You can select the labels you want to search for and hit Enter. You get the results right there inside Eclipse itself:

Eclipse Search - Results

 

The recent searches are available in the History Menu:

Eclipse Search - History

 

And in case want to switch to a browser from the current results:

Eclipse Search - New Browser

 

Me and few of my team mates are using it regularly and find it very handy. Download and try it yourself.

Mar 8, 2009

Commands Part 6: Toggle & Radio menu contributions

In the previous parts of the series, we saw how Commands contribute to push style menu items. But commands allow you to contribute menu items with 'toggle' and 'radio' style as well. Let us see how to contribute the familiar "Format" menu thru Commands:

image

 

First we will look at the toggle style menu contribution. Commands can have states associated with it. A state id known by its id and it can have any value, which is stored in a subclass of org.eclipse.core.commands.State. To know whether a command is checked or not, the Command Framework looks for a state with the id 'org.eclipse.ui.commands.toggleState'. Lets specify the default checked state of Bold to true and Italic to false:

<command
      defaultHandler="com.eclipse_tips.commandstate.BoldHandler"
      id="com.eclipse-tips.commandState.boldCommand"
      name="Bold">
   <state
         class="org.eclipse.ui.handlers.RegistryToggleState:true"
         id="org.eclipse.ui.commands.toggleState">
   </state>
</command>
<command
      defaultHandler="com.eclipse_tips.commandstate.ItalicHandler"
      id="com.eclipse-tips.commandState.italicCommand"
      name="Italic">
   <state
         class="org.eclipse.ui.handlers.RegistryToggleState:false"
         id="org.eclipse.ui.commands.toggleState">
   </state>
</command>

The Framework expects a Boolean value from the state. It doesn't care about which class that holds the state. So why should we use the RegistryToggleState instead of our own state class? Two reasons:

  1. It implements IExecutableExtension. So you can specify the default values in the plugin.xml as I've done above.
  2. It extends PersistentState, so it can remember the value between Eclipse sessions. So if the user had checked/unchecked the menu, restarts Eclipse, he will get the same state as he left before - all this, you get without even your plugin being loaded.

So how should the handler work for this command?

public Object execute(ExecutionEvent event) throws ExecutionException {
     Command command = event.getCommand();
     boolean oldValue = HandlerUtil.toggleCommandState(command);
     // use the old value and perform the operation

    return null;
}

Basically, its the Handler's responsibility to update the Command's state. The HandlerUtil has a convenient method which toggles the state and gives you the old value of the state. You can use the value to perform the operation.

The radio state is also similar, which expects the state with a predefined id. Since the same command is contributed for various option, its should be a parameterized command. The id of the parameter which denotes the radio state is also predefined:

<command
      defaultHandler="com.eclipse_tips.commandstate.AlignHandler"
      id="com.eclipse-tips.commandState.alignCommand"
      name="Align Command">
   <commandParameter
         id="org.eclipse.ui.commands.radioStateParameter"
         name="State"
         optional="false">
   </commandParameter>
   <state
         class="org.eclipse.ui.handlers.RadioState:left"
         id="org.eclipse.ui.commands.radioState">
   </state>
</command>

Just like toggle state, the state must have the id and the class could be anything that stores the value as String. The RadioState class provides initializing from plugin.xml and also persists the value across sessions.

The menu contribution would specify the parameter value:

<menuContribution
      locationURI="menu:org.eclipse.ui.main.menu?after=additions">
   <menu
         label="Format">
      ... other contributions here
      <command
            commandId="com.eclipse-tips.commandState.alignCommand"
            label="Align Left"
            style="radio">
         <parameter
               name="org.eclipse.ui.commands.radioStateParameter"
               value="left">
         </parameter>
      </command>
      <command
            commandId="com.eclipse-tips.commandState.alignCommand"
            label="Align Center"
            style="radio">
         <parameter
               name="org.eclipse.ui.commands.radioStateParameter"
               value="center">
         </parameter>
      </command>
      <command
            commandId="com.eclipse-tips.commandState.alignCommand"
            label="Align Right"
            style="radio">
         <parameter
               name="org.eclipse.ui.commands.radioStateParameter"
               value="right">
         </parameter>
      </command>
   </menu>
</menuContribution>

The Command Framework understands this parameter and sets the UI contributions according to this value. Again its the handler's job to set the correct state from the command's parameter during execution. You have helper methods in the HandlerUtil to perform this:

public Object execute(ExecutionEvent event) throws ExecutionException {
    if(HandlerUtil.matchesRadioState(event))
        return null; // we are already in the updated state - do nothing
    String currentState = event.getParameter(RadioState.PARAMETER_ID);
    // perform task for current state
    if(currentState.equals("left"))
    // perform left alignment
    else if(currentState.equals("center"))
    // perform center alignment
    // and so on ...

    // and finally update the current state
    HandlerUtil.updateRadioState(event.getCommand(), currentState);

    return null;
}

Bonus:

Q: I want the initial value always loaded from the plugin.xml, the state should not be remembered between sessions. Should I write my own State class?

A: Not necessary. You can specify both the default value of the state and whether to persist or not in the plugin.xml itself:

<command
      defaultHandler="com.eclipse_tips.commandstate.AlignHandler"
      id="com.eclipse-tips.commandState.alignCommand"
      name="Align Command">
   <commandParameter
         id="org.eclipse.ui.commands.radioStateParameter"
         name="State"
         optional="false">
   </commandParameter>
   <state
         id="org.eclipse.ui.commands.radioState">
      <class
            class="org.eclipse.ui.handlers.RadioState">
         <parameter
               name="default"
               value="left">
         </parameter>
         <parameter
               name="persisted"
               value="false">
         </parameter>
      </class>
   </state>
</command>

This applies for toggle state as well.

Q: I want to know the state of the command elsewhere in the code. How do I get it?

A: Just use Command.getState(<state id>).getValue(). The state ids are available as constants at RegistryToggleState.STATE_ID and RadioState.STATE_ID

My patch for this feature has just been checked in and should be available from 3.5 M6 onwards. If you are curious, pick up a recent Nightly build and play with this.

Followers

Disclaimer

Any opinion expressed here, in any other blogs, forums, websites, "Letters to the Editor" column in "The Hindu" daily, weekly magazine’s sudoku column, my daughter’s drawing book and scribbling on the toilet papers, are not necessary my employers opinion, but all my own :-P

Unless specified, all the content of this blog is made available under Eclipse Public License
 
Design by Wpthemedesigner. Converted To Blogger Template By Anshul .