Hexapixel

Still no news!

Emil — Tue, 06 Sep 2011 13:21:35 +0000

I’m still here, but I’m still swamped with a thousand projects, so both bugfixing and other stuff has suffered. I’m trying to catch up but I’m making no promises right now (such is life in open source). If there’s an urgent bug that you reported that I missed responding to, feel free to ping me and I’ll try to take a look. New features will have to come later!

Various Tidbits

Emil — Wed, 10 Nov 2010 03:12:01 +0000

I know it’s been ages since any updates, but I have not had much time to write long articles between work and other projects. I’m also still rather stuck in the world of Silverlight, which is a whole different story. Microsoft is doing funny things there as well, it might not even survive beyond a mobile platform.

It’s worth mentioning however, that the GanttChart has had quite a few bug fixes lately as well as improvements (new features) so if you’re a user of that it may be worth testing the latest nightly build and see if it makes life better on your end. I know there’s requests for Millisecond and Second “zoom views” but apart from some sketchy code that isn’t working as I want it, it hasn’t made it into any release yet, but it’s on the big TODO list and a priority.

Also, the Eclipse Nebula project “build system” has been broken for quite a while, so if you want the latest code (as always), use CVS or grab it from the nightly builds section on this site.

I’m hoping I’ll find time for some new articles going forward.

XAML in SWT / Where The Ribbon Is

Emil — Wed, 06 Jan 2010 15:04:11 +0000

I get loads of traffic and email thanks the Ribbon. It’s truly an alpha project that went completely beyond what I had imagined. It’s exciting of course, but as much as it should give me a warm fuzzy feeling, it actually makes me rather nauseous. The thing is, a lot of the code is a total mess, it’s embarrassing, and I’ll freely admit it. It was never written as a “thought out” project, it was simply written as a not-so-quick “test” to see if it was possible to do a Ribbon component in pure SWT. The answer was “kind of”, and that’s where it got left off.

After having worked with Microsoft Silverlight and XAML lately I realized how simple XAML makes it to do stuff that I spent hours writing code for in the Ribbon. For example; rounded corners, gradient borders, multi-gradient fills, etc. It’s a pleasure to work with, easy to change, and it moves you forward at a good pace – and that’s how I feel it should be. I doubt anyone would download the Ribbon source as it is now, look at the render classes and think “great, I’ll make a change riiiight here”, it’s just too complicated and non-customizable. A user wanting to change colors would have to spend hours, days even, just to figure out what pixel is drawn where, and when I look at the code now, I get the same feelings.

Instead of continuing work on the Ribbon to finish “the mess”, I decided that if it was ever going to finish the project and take it out of Alpha, I was going to do all the rendering stuff the right way. And thus started a little test project with Brushes with the intention that if I could make things as easy as writing XAML, I could write all the Ribbon widgets in no-time.

Brushes

A Brush object in XAML (and in a lot of other languages) is like a paint brush, it defines a direction and a stroke, colors, etc. The Ribbon basically uses a whole ton of Brushes.

Here’s a quick list of the things that the Ribbon currently uses lots of:

2-color and Multi-color gradients in Horizontal and Vertical orientation, there are no diagonal or radial gradients (although brushes in XAML support any angle).
“Border” controls that contain other controls (pretty much all controls have some sort of border around them). A Border control in WPF is a control that can contain only 1 other control, and it can display a border and a background and allows for rounding of the borders.
Various paddings and margins between controls to space them out between one another.
Colors, colors and more colors.

If you think about it, that’s pretty much any control in an normal GUI library as at some level of the OS, there will be a programmatic “pen” that is drawing everything you see, pixel by pixel. Everything built on top of that is convenience to the user. And how many people know how to programatically draw a gradient between 2 colors if there isn’t an API to do it with? Probably very few.

(If you want to see a fully functional Ribbon in Silverlight (built on XAML) do a google search for “SandRibbon”. I’d link to it here but it’s commercial and costs a fortune, so I don’t feel like promoting it with a cross-link.)

Multi-color Gradients

My “Pseudo” code that I started from to “realize” this was the following:

LinearGradientBrush yrb = new LinearGradientBrush(new DPoint(0.5, 0), new DPoint(0.5, 1));
yrb.addGradientStop(new AlphaColor("#FFfff900"), 0);
yrb.addGradientStop(new AlphaColor("#FFf90005"), 0.5);
yrb.addGradientStop(new AlphaColor("#FF1100ad"), 1);

It’s very WPF/XAML, and what it says is “Create a brush that will draw a gradient vertically (each DPoint is x/y coordinates of how the fill should draw), add 3 color stops, one at 0%, one at 50% and one at 100%”.

XAML, by the way, for a typical LinearGradientBrush looks like this:

If we were to do this in Photoshop it’d look exactly like this (on a 400×400 canvas):

To support multi-color gradients when using pattern fills (as SWT doesn’t), I had to write some code that split each section that I intend to fill into smaller rectangles and fill each one. Each section is 2 colors. So in the above case, we have 2 patterns we need to create, one from 0% to 50% and one from 50% to 100%. In the picture this would be from 1 to 2, and from 2 to 3.

Implementing it wasn’t that hard, and despite the code not being that long I think it’s easier you look at the source itself if you want the details as it’s a bit spread out. The source is at the bottom of the article.

A SWT Border Control

The “Border” control in WPF takes a few interesting attributes. One is the Brush that is used to fill the border, the second is the Brush used to fill the background. Then it allows for a setting the border “roundness”, the padding and the margin, and a few other things. All of that is mostly getters/setters and in the end we will have a GraphicsObjectRenderer class that deals with actually drawing it. If there was a border control in SWT it might look a bit like this:

Border b = new Border(parentControl);
b.setBorderBrush(ourBorderBrush);
b.setFillBrush(ourFillBrush);
b.setBorderThickness(1);
b.setCornerRadius(20);
b.setWidth(100);
b.setHeight(100);
b.setMargin(new Margin(50));

Pretty straight forward.

The result from running this code looks something like this:

Oh no, Issues…

This is how far I got before I hit a wall. I actually started writing the article as I wrote the code because I was quite excited how seemingly well it worked. So what halted me? A few bugs in SWT. Normally a lot of things can be worked around if they don’t work 100% as intended, however, the bugs I came across were not of that type. The main issues are as follows:

Pattern fills in SWT start drawing the pattern in the wrong place. I’ve filed a bug for this which can be found here. This one is rather critical as most of the brush drawing depends on it.
A rounded rectangle is not drawn in the same way as a round rectangle, causing the border around it to be in weird places around the rectangle itself. An old bug is filed here.
Other GC draw-related bugs.

Conclusion

Probably not the conclusion you or I wanted, but as I see it, I cannot really continue this project until the bugs are fixed (or worked around), and considering GC-related bugs are probably low on the fix-list, the Ribbon will have to sleep for a while longer, along with this project. AWT has a very good MultipleGradientPaint implementation and I successfully manged to convert AWT drawings to SWT, but the AWT code is rather slow and converting it over is also slow, so it’s not really an option.

Code

If you want to play with the code I have so far, you can download it here. Under the “test” package directory you’ll find various classes. BorderTester.java is the main test class. The code is truly “as is”, it’s just zipped up from what I had at the time I ran into issues.

Download Source

Printing SWT Tables with PaperClips

Emil — Fri, 18 Sep 2009 06:56:33 +0000

In this article I will explain how to print a table using PaperClips (as of this writing PaperClips is in process of moving to the Eclipse Nebula project). When I say print, I mean print literally, as in printing on a printer. PaperClips is a lightweight API that makes building printable pages very easy. It uses a simple and logical structure that has many useful features and it’s surprisingly flexible. One of the many possibilities is the ability to print tables quite nicely as it has a “GridPrinter” (which is what this article will cover. But you can of course use PaperClips to print nearly anything).

The code for this article will let you print pretty much any SWT table widget of your choice as all you need to do is wrap your table in an interface and off you go. But since this is an article, let’s stick to the plain old SWT table for the sake of the demo. I will mostly go over important snippets of the code and the rest you can download and re-use (download link is at the bottom of the article).

Let’s list a few things we want to achieve with our implementation:

Print preview (PaperClips gives us most of this already).
The option to print either just a selection or all items.
Customizable header and footer.
Printing table with column sizes as they are in the table.
Options to specify if headers are printed, where lines are drawn and so on.

The table that we intend to print for this article looks like this (just run the Tester.java class in Eclipse):

We use Snippet38 and add a button at the bottom for printing.

Understanding Paperclips

It’s probably ideal that you understand the PaperClips syntax before you keep reading. PaperClips has certain letters and things that let you specify column widths, how things span and wrap etc. Please do a quick scan of this page if you are unfamiliar with the syntax. It will take no more than a few minutes to learn, it’s that easy.

Creating a GridPrint

As mentioned, the GridPrint class is basically a class for printing grids. It will allow you to set things such as columns, headers etc. Think of it as a table widget, but as if it was drawn on a piece of paper.

Our main class that will handle all the printing will be called GridPrinter.java, and the constructor looks like this:

public PrintResultCode printTable(IGenericTable tableImpl, boolean printSelectionOnly, boolean showPreview, String docTitle, final Shell parentShell) {
 ...
}

The IGenericTable is an interface that you use to wrap the SWT table you want to print. It contains simple methods such as getting the name or width of a column, or an item on a specific row (methods that most table implementations already have). The second attribute defines whether everything is printed or only what the user has selected is printed. The third defines if we show a Print Preview dialog or just print straight to the printer. The fourth is the title of our document that we are printing and finally it’s the shell that will be the parent shell of the print preview dialog (if we are previewing). 
Now that we have all the “data” we need, the first thing we want to do is to create the column headers. This is done via a very short loop;
for (int i = 0; i < cols.size(); i++) {
    String name = concat(tableImpl.getColumnTitle(cols.get(i)), widths.get(i), concatGc, headerFont);
    print.addHeader(new TextPrint(name, _headerFontData));
}

We get the table column text and then concatenate it if it’s longer than the actual width of the column itself (just like the table does as a widget). print is our GridPrint, and to that we simply say “add this header”, and then create a TextPrint with the name and our specified header font. A TextPrint can be thought of as a basic cell that contains text with or without a font. Do note that pretty much everything is a “print”, so you can add a GridPrint to a GridPrint to a GridPrint etc. You get the idea.
Now that we have our table column header added, let’s add the cell data that goes below.
for (IDataObject gi : sel) {
    for (int i = 0; i < cols.size(); i++) {
        String colText = gi.getColumnText(cols.get(i));
        if (colText == null) {
            colText = "";
        }
        String text = concat(colText, widths.get(i), concatGc, cellFont);
        print.add(tp(text, _cellFontData));
    }
}

It’s nearly identical but instead of adding it as a header to the GridPrint we just add it normally. We do the same concatenation as in the header as we want to print exactly what the table looks like (so if the user resizes a column in the table widget, that’s the size that is used for the printed version as well). The sel array represents all selected items. If we called our constructor with the option to print all items, it will contain all items, and if we called it and said “only print the selected items”, it will contain those. The code also contains logic for spacing out cells, so if you were to select individual cells like this…
# - - # - -
- # # - - -
- - - - - #

… it would print it in the way you would expect it to.
Multiple Pages and Large Prints
As the code is not a human and has no idea of how big your table actually is, it’s quite possible it spans multiple pages both horizontally or vertically. A GridPrint does not handle this by default. But remember that pretty much all print-classes can be children of each other? To support large prints (basically anything beyond the size of a single printed sheet of paper), we need to wrap our page (the GridPrint) in a BigPrint. Just by doing that via a simple…
BigPrint big = new BigPrint(print);

… we can now support multiple pages. Easy wasn’t it? 
Headers, Footers and Spacing
Normally you will want headers and footers on the printed paper. The header tends to contain your company logo and the document title. The footer usually contains what page it is and perhaps a date or such. To accommodate this, there is a PagePrint class that will let you customize all of these aspects. To use it we want that to be our “outermost” parent, so the order is: PagePrint -> BigPrint -> GridPrint.
Here’s how we create the PagePrint:
PagePrint pp = new PagePrint(new PrintHeader(_printHandler, docTitle), big, new PrintFooter(getFooterText()));
pp.setHeaderGap(9);
pp.setFooterGap(18);

In the constructor, we tell it “here’s our header, our BigPrint and our footer”. We also tell it how much spacing we want between the header/footer and the content of the page. It’s usually nice to space them out slightly so it’s not too packed together. 
The header and footer classes are both classes that implement the PaperClips PageDecoration interface. They’re very simple to use and only require one method. All this method forces you to return is a “Print” that represents your header (or footer). They can be of any print-class you like, a GridPrint, a TextPrint, etc. For example, here’s our header:
@Override
public Print createPrint(PageNumber arg0) {
    DefaultGridLook dgl = new DefaultGridLook(0, 3);
    GridPrint gp = new GridPrint("p, C:D:GROW", dgl);
    FontData fd = Display.getDefault().getSystemFont().getFontData()[0];
    fd.height = 14;
    fd.setStyle(SWT.BOLD);

    if (_handler.getActivePrintLogo() != null) {
        gp.add(new ImagePrint(_handler.getActivePrintLogo().getImageData(), Display.getDefault().getDPI()));
        gp.add(new TextPrint(""));
        gp.add(SWT.CENTER, new TextPrint(_title, fd, SWT.CENTER), GridPrint.REMAINDER);
    }

    return gp;
}

In this code we create a new “Grid Look and Feel” (this is a PaperClips class that simply draws borders around cells etc). Then we create a very simple GridPrint that has 2 columns. The first is in a preferred size as we don’t know the size of the image that will go there (there might be no image even). The second takes up all available space and is centered so that the text shows the title of the document in the middle, but we push it down a row to make it truly centered or the size of the image would push it off.
Previewing the Print
Once we have our PagePrint all set up it’s finally time to print! PaperClips has a “ui” package that contains a PrintPreview dialog. In the downloadable code you will find that this class has been wrapped as I wanted button images in the dialog to be customizable. To show our print preview dialog we call:
PrintPreviewDialog ppd = new PrintPreviewDialog(pp, parentShell, _printHandler);
ppd.open();

(The PrintHandler is an interface that lets us define what images we use etc)
The result is more or less the following (when fully zoomed out):

And when zoomed in a bit:

Do note that even if the preview may not be 100% perfect look-wise (pixelated etc), the printed version will come out fine. 
Conclusions
With PaperClips you can go from zero print-functionality in your application to some pretty fancy reports in just a few hours of work. That’s its #1 strength and it’s a very strong argument for using PaperClips. Sure, you can create very fancy reports using Eclipse BIRT or JasperReports (which has sadly gone mostly commercial). For “normal printing” however, there’s no reason to dig into a big reporting engine, just stick to PaperClips!
Download The Code
The code for this article is an Eclipse Project that contains everything necessary to run what you have seen in this Article (you may need to adjust the SWT-jar import paths). It may seem like there’s a lot of code but in reality it’s mostly some extra interfaces to make things customizable. That way it’s not just article code, but code you can actually use. That’s how I prefer to write articles. Most people want as much customization as possible, and for those that don’t, they can take out the parts that they need.
Download Code
Happy printing!
(PaperClips version 1.0.4 was used in this article).

Server Move

Emil — Wed, 16 Sep 2009 11:37:26 +0000

The Hexapixel.com server is moving to a new data center. Hopefully downtime should be minimal but it’s possible DNS propagation can take a little longer for some people (depending on ISP). The move is taking place over the next week.

The lack of recent articles is due to being completely swamped. I’m hoping to find some time to write a few more soon!

Also, a new version of the Source Helper should arrive soon, with Eclipse 3.5 support and a whole lot of fixes.

Creating a Notification Popup Widget

Emil — Tue, 30 Jun 2009 12:00:24 +0000

In this article I will explain how to create a custom widget that displays a popup notification dialog in the bottom right corner of your screen (usually above the toolbar on Windows). Here’s what it will look like when we’re done:

We could custom draw everything which would allow us more control over the widget, but for the sake of this article lets stick to using basic SWT components inside a normal Shell that we will make a bit prettier than your typical SWT Shell.

(Do note this has only been tested on Windows, it’s quite possible tweaks are necessary for other platforms).

The Shell

What we want is a Shell that stays on top of our application (but not on top of all applications) and doesn’t steal the active focus or else it would show up in your task manager or move focus away from where the user is now. We also don’t any normal Shell “trim” borders, we’ll draw our own. Creating it is easy as all of our requirements are available via SWT flags. Thus we can create the Shell as follows:

_shell = new Shell(Display.getDefault().getActiveShell(), SWT.NO_FOCUS | SWT.NO_TRIM);

As we have SWT widgets inside our shell and we intend to use a gradient background on the shell itself, all the widgets need to be transparent. This is done by setting the Background Mode on the shell to SWT.INHERIT_DEFAULT. This tells the widgets to inherit the background of their parents, and gives us what we want. So after we create the shell we simply call;
_shell.setBackgroundMode(SWT.INHERIT_DEFAULT);

So how do we get a gradient background on a shell? It certainly don’t support it by default. You can set a foreground and a background but that’s about it. The trick is to paint an image with the colors we want and use that as the shell’s background. To set it at the right time, we listen to the SWT.Resize event on the shell and do it then with the following code;
_shell.addListener(SWT.Resize, new Listener() {
    @Override
    public void handleEvent(Event e) {
	try {
	    // get the size of the drawing area
	    Rectangle rect = _shell.getClientArea();                    
	    // create a new image with that size
	    Image newImage = new Image(Display.getDefault(), Math.max(1, rect.width), rect.height);
	    // create a GC object we can use to draw with
	    GC gc = new GC(newImage);

	    // fill background
	    gc.setForeground(_bgFgGradient);
	    gc.setBackground(_bgBgGradient);
	    gc.fillGradientRectangle(rect.x, rect.y, rect.width, rect.height, true);

	    // draw shell edge
	    gc.setLineWidth(2);
	    gc.setForeground(_borderColor);
	    gc.drawRectangle(rect.x + 1, rect.y + 1, rect.width - 2, rect.height - 2);
	    // remember to dipose the GC object!
	    gc.dispose();

	    // now set the background image on the shell
	    _shell.setBackgroundImage(newImage);

	    // remember/dispose old used iamge
	    if (_oldImage != null) {
		_oldImage.dispose();
	    }
	    _oldImage = newImage;
	}
	catch (Exception err) {
	    err.printStackTrace();
	}
    }
});

The Contents
Our shell consists of 3 sections, an image at the top left (which is a normal CLabel). Then a label that contains the header text (also a CLabel), and finally a label which represents our message (a normal Label). We use a Label at the end instead of a CLabel as Labels support wrapping and multi-lines better than the CLabel does. You could of course use pretty much any widgets you want. Here’s an outline of what section each label covers:

We use a GridLayout with some 5px margins (except at the top) and the widgets are created normally without any special magic, so I won’t show that code here (it’s all at the bottom for you to download). 
Some Eye Candy – Fading
Shells support alpha values as of SWT 3.4, so we’ll use this to make our “appearing” and “disappearing” a bit prettier. All we need to do to make a shell fade in and out is to have a thread that loops and increases/decreases the alpha channel value for the shell. As we need to be on the Display thread to do this it’s easiest to do it all via a runnable that we let the Display object run for us at a given interval. 
We need to remember to continuously check to see if the shell is disposed as it can happen when we’re on a thread. When we’re finished fading in, we want the shell to stay visible for a certain amount of time, and then we want to fade out. So basically the chain is this:

Create shell
Fade in shell
Stay visible for X seconds
Fade out shell
Dispose shell

All these timers are more or less similar in terms of how the code looks, so I’ll show one example here and for the rest you can look at the complete source downloadable below. We have some global variables here that should be explained. 

FADE_IN_STEP is how much we increase the alpha value for each iteration.
FINAL_ALPHA is a value that declares what the final alpha value will be for the shell when it stays visible. I find that a slightly transparent shell gives a better effect, so by default this value is 225 (out of 255 which is a solid [opaque] shell).
FADE_TIMER is how long we wait until increasing the Alpha value again. When the shell has reached it’s max-alpha value we call the startTimer() method, which is a thread that sleeps for a certain number of seconds before calling the fadeOut() method.

private static void fadeIn(final Shell _shell) {
    Runnable run = new Runnable() {

        @Override
        public void run() {
            try {
                if (_shell == null || _shell.isDisposed()) { return; }

                int cur = _shell.getAlpha();
                cur += FADE_IN_STEP;

                if (cur > FINAL_ALPHA) {
                    _shell.setAlpha(FINAL_ALPHA);
                    startTimer(_shell);
                    return;
                }

                _shell.setAlpha(cur);
                Display.getDefault().timerExec(FADE_TIMER, this);
            }
            catch (Exception err) {
                err.printStackTrace();
            }
        }

    };
    Display.getDefault().timerExec(FADE_TIMER, run);
}

Stacked Notifications
There’s one last thing we want to support, which is stacked notifications. Assume our notification shell’s entire life-span is about 5 seconds, what if we have another notify call before the first one has finished showing? We could dispose the first shell and replace it with the new one of course, but a much prettier approach is to simply move the previous shell up, and show the new notification below it. The effect of this is something like this (this screenshot was taken just as the old shells started to fade out, hence the higher alpha on them):

What we do to achieve this effect is rather simple. Every time a notification shell is opened, we keep a reference of it in a static array of shells. When it’s faded out (and disposed), it’s removed from the list. Thus, when a new shell is created we simply check to see what’s already in the array and then set the location for each old shell in the array to -heightOfNewNotificationShell (so to speak). Thus, the old shells move up to make room, but continue their fade-in/fade-out cycles just like before. 
Further Improvements
Everything could be made prettier than it already is of course, perhaps you want an “X” close button, or different colored text, or rounded shell corners. None of that is in the current code, but the code should give you enough to go on to implement most of that without any major problems. 
Also note that I currently use Display.getDefault().getActiveShell() for the parent shell of the popup. You may want to refactor it to use a more permanent shell as otherwise a disposal of whatever the parent shell was whenever the popup was displayed will cause the notification to dispose as well.
The code is not perfect, it’s an example to build on (if you so wish).
Download Code
I’ve created an Eclipse project with the code and also the ImageCache/FontCache/ColorCache classes I use in the code (all they do is keep already used images etc in memory so that they don’t need to be re-created). There’s also a jar with the images I’ve used in this example. If you like them and want more like it, there’s a massive image pack with exactly these icons and more here: Gnome Colors Icons.
Do note you may need to adjust your CLASSPATH settings for the project to reflect the location of your SWT jars.
To run the code, simply run the Tester.java class and push the big button to create a notification. Push it again before the first one fades away to see the stacking. A random image will be used every time you push it.
DOWNLOAD CODE
Conclusion
Hopefully this gives you an insight into how to create a “custom widget” (without much custom painting). Have fun!

The Secondary ID

Emil — Tue, 16 Jun 2009 13:36:25 +0000

In many RCP applications your views (ViewParts) will not be singletons. Perhaps you have a tree or project view which is probably a “show only once” view, but for others it’s more likely you have them flagged in the plugin xml to say allowMultiple="true" in the tag. For multiple views sharing the same primary ID you are probably already aware that you can (and have to) set a secondary id on them to make them unique. This secondary id will stay with the view as long as that view is open (even if you restart your application as the secondary id is saved in the Eclipse metadata and then re-set when your RCP application starts up again – assuming the view is set to be restorable).

But there’s some things that can be a bit frustrating, which is the point of writing this article. First, as your view has to be defined in the plugin.xml and [should you want to] Eclipse/RCP has currently no way of hiding views in “Show View” (see Bug 249451 for details and possible workaround to hiding views from “show view”). Any view opened with Show View won’t have a secondary id.

Second, you may want to control what that secondary id looks like, as you may want to use it as an “ID” for saving custom view-specific settings (for example, grid-specific data such as column widths, column orders etc).

Third, you want a central place where the creation of those multi-views are handled where you know that the ID set on them will be of the format you defined.

And lastly, you probably want some of them to be automatically opened in your “default” perspective with proper secondary ids. So let’s get to it and see how we can make all this work for us with the goal of us not having to think about it any more once we’ve created the necessary code.

The ActionNewView Action

As we will continuously reference “the place” where the secondary id is set on the view, lets start with the “view creator”. This could be considered a Factory, but as it’s kind of nice to tie it in with Actions lets make this factory an Action which also allows us to use it in menus, toolbars, etc.

The action will take the [primary] ID of the view that should be opened as a parameter in the constructor (the same ID you specify in plugin.xml) and in the run() method it will create the view with a secondary id of our choice. This is all quite easy and we don’t have to write much code to accomplish it, in fact, you’ve undoubtedly done something like this already. In this article we will use a UUID as our secondary ID as it’s unique and the structure of it is good as it’s a long string without strange characters (except the ‘-’ character) and it’s more or less guaranteed to be unique. You may of course use whatever you prefer as a unique ID.

Our action class will look like this:

public class ActionNewView extends Action {

    private String _viewIdToOpen = null;

    public ActionNewView(String viewIdToOpen) {
        _viewIdToOpen = viewIdToOpen;
    }

    @Override
    public void run() {
        try {
            // this will become the secondary ID used in the view
            String secondaryId = UUID.randomUUID().toString();

            IWorkbenchWindow window = Activator.getDefault().getWorkbench().getActiveWorkbenchWindow();
            if (window != null) {
                IWorkbenchPage page = window.getActivePage();
                if (page != null) {
                    // these two lines open (create) and focus on the view
                    page.showView(_viewIdToOpen, secondaryId, IWorkbenchPage.VIEW_CREATE);
                    IViewPart justActivated = page.showView(_viewIdToOpen, secondaryId, IWorkbenchPage.VIEW_ACTIVATE);

                    // ... do something with justActivated if needed
                }
            }

        }
        catch (Exception err) {
            //TODO: deal with exception
        }
    }
}

I don’t think it needs much explanation as it’s a pretty straight forward “view creation” call with a secondary id, as specified in the Eclipse manual etc. 
Dealing With “Show View”
Now that we have our “view opener class” we’re ready to deal with some of the aspects mentioned in the beginning. The next stop is to get secondary id’s onto views opened via “Show View” as they don’t get one by default. If you don’t already have an abstract parent class for all of your multi views, perhaps now is the time to create one as it will make it easier, but you can of course put the same snippet of code elsewhere. 
One method is always called upon view creation, and that’s where we want to check if the view being created has a secondary id. If it doesn’t, we want to dispose (hide) that view right away and call our ActionNewView instead and open the same view again but with a secondary id. The method we check in is the createPartControl(Composite parent) method which is an implementation of the IWorkbenchPart interface. Here’s what our code will look like:
@Override
public void createPartControl(final Composite parent) {
    try {
        // get the secondary id that the view was created with
        String secondaryId = getViewSite().getSecondaryId();

        // If the secondary id was null that means that Eclipse opened the view, and not us. That's bad because it
        // creates a view without a secondary ID and causes the view to be "different" from one that we opened ourselves.
        // Thus, if we see a view opened without an ID, we quickly close it and tell the "open new action" to open
        // the same view right away. The result may be a very slight flicker as the old view comes to existance and is
        // destroyed right away, but it's mostly not noticeable by the end user.
        if (secondaryId == null) {
            // we need to do it asynchronously as we can't close the view until the create code has finished
            Display.getDefault().asyncExec(new Runnable() {
                @Override
                public void run() {
                    // destroy ourselves
                    getViewSite().getPage().hideView(ThisAbstractClass.this);
                    // open the same view our way
                    ActionNewView anv = new ActionNewView(getViewSite().getId());
                    anv.run();
                }
            });
            
            // return now as we're done with the non-secondary-id view
            return;
        }

        // do normal view creation stuff here...
    }
    catch (Exception err) {
        //TODO: deal with exception
    }
}

ThisAbstractClass is of course whatever class you put this code in, but most likely it’s your abstract multi-view parent class.
So, as the comment states, when a view is created and it doesn’t have a secondary id, that view is discarded as soon as it finished being created and the same view is opened again but this time via our action, which in turn ensures it gets a secondary id to our standards. 
Dealing With Perspectives
We’re almost done, but there’s one more place where views may get secondary id’s that aren’t what we want, and that’s the views that are opened when the Perspective is new or reset. In our DefaultPerspective class (or whatever perspective class you want) we define the layout in the createInitialLayout(IPageLayout layout) and we also set whatever views are open at the start and where non-opened views go (placeholders). In here we need to change a few things so that whatever views are opened from the start get opened with a secondary id like above.
The API documentation for IPageLayout states:
In some cases, multiple instances of a particular view may need to be added to the same layout. These are disambiguated using a secondary id. In layout methods taking a view id, the id can have the compound form: primaryId [':' secondaryId]. If a secondary id is given, the view must allow multiple instances by having specified allowMultiple="true" in its extension. View placeholders may also have a secondary id.
So we can either create the secondary id on the fly and call layout.showView("primaryId:secondaryId") or we can just add placeholders and asynchronously call our Action to create the views. It’s really up to you how you want to do it, if your ID generator is a simple static call, you may just want to put the secondary ID’s in there and be done. But for the sake of the article, lets have everything go through our action. 
Presume we have a perspective layout of 1 folder on the left, and 3 folders on the right, each taking up 33% of the space vertically. Something like this:
+-----------+--------+
|           |folder 1|
|           +--------+
| folder 0  |folder 2|
|           +--------+
|           |folder 3|
+-----------+--------+

The “folder 0″ will get a non-multi view, and folder 1,2,3 will get multi-views, 1 each for this example. We will tell the folder 1,2,3 that they contain view placeholders, and folder 0 will get a view right away. Our code will look like this:
public class DefaultPerspective implements IPerspectiveFactory {

    // Marker for saying "any id following the primary id" (which is the secondary id)
    private static final String MULTI_VIEW = ":*";

    @Override
    public void createInitialLayout(IPageLayout layout) {
        String editorArea = layout.getEditorArea();
        layout.setEditorAreaVisible(false);

        // list of ID's that will be created at "reset perspective" / first startup
        final String[] ids = new String[] { ViewForFolder1.ID, ViewForFolder2.ID, ViewForFolder3.ID };

        layout.addShowViewShortcut(OurWorkspaceView.ID);        
        layout.addShowViewShortcut(ViewForFolder1.ID);
        layout.addShowViewShortcut(ViewForFolder2.ID);
        layout.addShowViewShortcut(ViewForFolder3.ID);

        // left side
        IFolderLayout workspace = layout.createFolder("Folder0", IPageLayout.LEFT, 0.2f, editorArea);
        workspace.addView(OurWorkspaceView.ID);

        // right side
        IFolderLayout f1 = layout.createFolder("Folder1", IPageLayout.RIGHT, 0.25f, editorArea);
        f1.addPlaceholder(ViewForFolder1.ID + MULTI_VIEW);

        IFolderLayout f2 = layout.createFolder("Folder2", IPageLayout.BOTTOM, 0.33f, "Folder1");
        f2.addPlaceholder(ViewForFolder2.ID + MULTI_VIEW);

        IFolderLayout f3 = layout.createFolder("Folder3", IPageLayout.BOTTOM, 0.5f, "Folder2");
        f3.addPlaceholder(ViewForFolder3.ID + MULTI_VIEW);

        // create all views asynchronously as they need to be created after the folders etc
        // have been laid-out. This ensures they have a secondary id according to our standards.
        Display.getDefault().asyncExec(new Runnable() {

            @Override
            public void run() {
                for (String id : ids) {
                    ActionNewView anv = new ActionNewView(id);
                    anv.run();
                }
            }

        });

        // rest of your code...
    }
}

So when the Perspective is opened for the first time (or reset) we create the layout, set multi-view placeholders and then asynchronously call our action to create the views. As we told them where to go, they will show up in each respective folder in the order specified by the string array. As mentioned previously you can of course call addView directly with a secondary id, but I’m showing the “route it through our ActionNewView class” way here.
Done!
This concludes the article on harnessing the Secondary ID in your RCP (or Eclipse) applications. This is by no means the only way to do it as everyone seem to find their own way of doing similar things. This is simply “one way”, but the above way works well. Hopefully the article gave you an insight into how the Secondary ID is used in a multi-view environment and the places you may need to “catch it” as views can be created from the Eclipse framework without your direct interaction.

MenuManagers and You

Emil — Fri, 22 May 2009 10:23:13 +0000

If you’re using Eclipse RCP (or even standalone SWT with JFace) you are most likely using MenuManagers in various places, for popup menus, toolbar menus, etc. You might be happily using them without much of a thought or care of where they end up after they have been shown or how their internal workings actually “work”. Danger lies down that happy path.

You probably never paid much attention to the disposal of widgets except that “master widget” you call dispose() on (usually a shell).. and just because of this, it’s time to dig into the “why”, “what” and “no kidding” of MenuManagers as there are undoubtedly a few of the “no kidding” unless you are already fully familiar with them.

If you look at the MenuManager API, you’ll see an often overlooked dispose() method. MenuManagers need disposal?! Yep, they sure do. Here’s a seemingly harmless sample snippet. We create a Shell, a Toolbar, on which we create a MenuManager, and then we dispose the toolbar. You’d think that the MenuManager would get disposed also wouldn’t you? It doesn’t. Where is it? In memory.

import org.eclipse.jface.action.Action;
import org.eclipse.jface.action.MenuManager;
import org.eclipse.jface.action.ToolBarManager;
import org.eclipse.swt.SWT;
import org.eclipse.swt.layout.FillLayout;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.swt.widgets.ToolBar;

public class MenuManagerTest1 {

    public MenuManagerTest1() {
        Display display = new Display();
        Shell shell = new Shell(display, SWT.SHELL_TRIM);
        shell.setLayout(new FillLayout());

        ToolBarManager tbm = new ToolBarManager(SWT.FLAT | SWT.RIGHT);
        tbm.add(new OneAction());
        ToolBar tb = tbm.createControl(shell);

        MenuManager mm = new MenuManager("Test Menu");
        mm.add(new OneAction());
        tbm.setContextMenuManager(mm);

        // dispose shell, this will dispose all sub-widgets as well
        shell.dispose();
        
        // check status of our stuff
        System.out.println("Toolbar is disposed? - " + tb.isDisposed());
        System.out.println("Menu is disposed? - " + mm.getMenu().isDisposed());
        System.out.println("ToolbarManager contains what? " + tbm.getItems());
        System.out.println("MenuManager contains what? " + mm.getItems());
    }

    class OneAction extends Action {
        public OneAction() {
            super("Test Action");
        }

        @Override
        public void run() {
            System.out.println("Action was run");
        }     
    }

    public static void main(String[] args) {
        new MenuManagerTest1();
    }

}

The printout when running this will look like;

Toolbar is disposed? - true
Menu is disposed? - true
ToolbarManager contains what? [Lorg.eclipse.jface.action.IContributionItem;@16fe0f4
MenuManager contains what? [Lorg.eclipse.jface.action.IContributionItem;@19d0a1

Ok, so that's not the most intriguing printout ever, but it's mostly to show that the items are still there. The reason a manager doesn't get disposed should be pretty obvious: It's not a widget, it has no disposable parent (which would also have to be a widget), thus, it exists as long as you let it exist. There is of course a reference to the actual Menu inside the MenuManager, which is disposed as you can see above.
So why aren't MenuManagers auto-disposed in some other fashion, like when the menu is disposed? For good reason. You can create them without a parent widget which means you can keep them around and re-use them like a Factory and because of this, there is no auto-dispose when the menu is hidden. It's actually to make life easier for you even if it sometimes doesn't feel that way.
Disposing MenuManagers
There's two ways you can go about dealing with disposing your MenuManagers. Here's the first one (which might be obvious);
Assume you have a few MenuManagers in your ViewParts or EditParts. If you are creating them inside methods, you will want to refactor them out and create them only once for your class. They should be accessible and re-used throughout the life of the ViewPart and disposed when the ViewPart is disposed. This is very important! If you do not dispose it, it will not be gone, and you will most likely end up with a memory leak (as the above snippet showed). Here's a typical ViewPart dispose() override:
@Override
public void dispose() {
        try {
            if (_toolbarMenu != null) {
                _toolbarMenu.dispose();
                _toolbarMenu = null;
            }

        }
        catch (Exception err) {
            // do something with exception
        }

	    // remember to keep it going!
        super.dispose();
}

The second option is for the "show once" menus that you may have. How do you dispose those? Ideally the same as #1 but if you really have to dispose them differently, the easiest way to do it is to "auto dispose" them once the user has seen the menu and closed it or selected something from it. You will most likely create your Menu object from a call to menuManager.createContextMenu(...), so after this when you have the Menu object available, you do something like this;
final MenuManager mm = new MenuManager("Menu");

// ... various manager-related code here

// create menu object on widget
Menu menu = mm.createContextMenu(parentWidget);

// add a listener that disposes the MenuManager once user has seen the menu
menu.addMenuListener(new MenuListener() {

	 @Override
	 public void menuHidden(MenuEvent e) {
	     // dispose asynchronously or it'll dispose too fast and menu item clicked won't be run
	     Display.getDefault().asyncExec(new Runnable() {

		 @Override
		 public void run() {
		     mm.dispose();
		 }

	     });
	 }

	 @Override
	 public void menuShown(MenuEvent e) {
	 }

});

It's not the prettiest solution, but it works. Ok, so the disposal is covered now, no more leaks. Yay for us!
There is one more thing to bring up that you may/may not encounter, but if you do, it would probably be a head-scratcher. 
Dynamic Menu Items
Here's a scenario that happened to me and at first seemed to be a bug:
We have a lot of tables in our application. We also have a section where users can create their own custom filters. These filters show up in our menus when you right click a table or open a menu on the toolbar. When a filter is in use, the corresponding menu item for that filter is checked. Each filter is wrapped in an IAction that overrides equals() and hashCode() that both check to see if the wrapped Filter object is the same. Thus, any action using the same filter object will return true in the equals() check. 
We have an IMenuListener on the menu, so whenever the user opens the menu, just as it's being shown, we remove all old menu items in the "Filters" menu and re-create them (as filters may have changed by the user without our knowledge). We then "check" (checkbox) them according to what filters are active in the table. All this works fine, and here's where the issue arose;
We also have a MenuManager on our toolbar (ToolbarManager) associated with the table. This toolbar menu shows the exact same filter menu when popped up, through the same methods. The issue is easiest described through this chain of events...

User opens right click filter menu, selects a filter, item is checked, filter is applied to table.
User looks at toolbar menu, sees filter checked (do note this is the first time the toolbar menu was opened). Closes menu without selecting anything.
User opens right click filter menu again, selects same filter as before (the now checked one). Item is no longer checked, filter is removed from table.
User opens toolbar menu again, sees the recently cleared filter still checked(!). At this point it will always stay checked. Had we looked at the menu when stuff was unchecked, it would forever be unchecked.

I debugged this for a long time until I to my horror realized that despite me calling removeAll() and re-creating all MenuManager items in the "Filters" menu on each popup, internally, in the Menu widget itself, the removeAll() on the MenuManager removed nothing on the Menu widget. All MenuItems were still there! Hmm, what was going on? what was I missing? Why didn't removeAll() remove all MenuItems as well? 
I debugged some more and noticed some code inside the MenuManager source code that looks like this:
for (int i = 0; i < mi.length; i++) {
    Object data = mi[i].getData();

    if (data == null || !clean.contains(data)) {
	mi[i].dispose();
    } else if (data instanceof IContributionItem
	    && ((IContributionItem) data).isDynamic()
	    && ((IContributionItem) data).isDirty()) {
	mi[i].dispose();
    }
}

This loop first of all removes all items that are not the same as before (that are in the clean array), that's good. But as I checked what got disposed, our filter items were never removed... as they are the same as before! Aha! So the second part of the if-statement checks to see if the item is Dirty or Dynamic. This was the first I had heard of Dynamic menu items and it felt like I had read the API through and through many times. The API for isDynamic() says:
Returns whether this contribution item is dynamic. A dynamic contribution item contributes items conditionally, dependent on some internal state.
Cryptic to say the least, and easily overlooked as it's very non-descriptive, but with the above looping code and how we deal with these special actions - it kind of fits. We depend on the items having checkmarks which depend on an internal state (which is; if the table filter is active or not). The MenuManager can't figure that out by itself of course, so we need to help it. The solution to this problem is obvious at this point. If isDynamic() returns true it will be disposed for us, so we need to implement that and return true.
In our code more or less everything is an IAction, for our FilterAction we create a DynamicFilterAction class that extends ActionContributionItem and then we override isDynamic() and return true. 
This ensures that there is no "old" items in the menu (as now our Dynamic menu items get disposed) when we create the new one, and as such, the "checkbox issue" goes away and everything works as intended. The final code looks something like this;
class DynamicFilterAction extends ActionContributionItem {
        
        private FilterAction _action;
        
        public DynamicFilterAction(DataFilter df) {
            super(new FilterAction(df));
            _action = (FilterAction)super.getAction();
        }
                
        public void setChecked(boolean checked) {
            _action.setChecked(checked);
        }

        @Override
        public boolean isDynamic() {
            return true;
        }                
}

Final Words
Hopefully this gives you a better insight into the rather simple but tricky world of MenuManagers and how they work. Taking good care of them will ensure that you at least don't have to worry about them sticking around in memory or doing things you didn't expect.
Happy menu managing!

Java Source Helper 0.2.4

Emil — Sat, 09 May 2009 15:26:16 +0000

I’ve released a new version of the JavaSourceHelper, 0.2.4, which fixes the following:

Brackets inside comments are no longer mistaken for “matching” brackets
If the starting bracket and end bracket were not in the same location, the connecting line would draw funny, now it draws a bend
Preferences page moved to under Java then “Java Editor”. Search for helper if you can’t find it in the Preferences dialog.

Here’s a picture of the “fixed” line drawing:

You can update via the update site or download and install/update manually. For more info go to the java source helper page.

Maven Version Clash Detection (and Software)

Emil — Tue, 17 Mar 2009 17:26:46 +0000

Maven is a great tool for building Java projects, there’s no doubt about that. Unfortunately there is one great feature still lacking of Maven which is important when you use third party dependencies, namely detecting when your components use dependencies of different versions without your knowledge.

What does that mean? It’s probably easier to explain by example. Imagine you have a project that has two dependencies (can be your own created jars or third party, or anything Maven-buildable really). Your first dependency uses Log4J v1.0. Your second dependency uses Log4J v1.1. When you compile this project Maven will by default use the “nearest wins” strategy, meaning it might pick Log4J v1.0 or Log4J v1.1, whichever is nearer in the transitive hull of dependencies. What you probably wanted however, was for the compilation to tell you that you have two “modules” depending on the same library, but different versions of that library. Log4J is perhaps not the best example, but imagine that the dependency in question is a mission-critical dependency, and that any version discrepancy may cause catastrophic failures that can be very hard to track down via debugging.

To solve this I wrote a Maven plugin nearly a year ago that we are now using for every Maven-built project in our company. It’s a simple plugin that does the complex task of detecting all version clashes (even deeply nested ones) and will report them back to you either as warnings or errors (or ignore them). This project was submitted to the Maven team a while back but has not been integrated as a default Maven plugin yet, so it will now become a downloadable Software Project on Hexapixel until it hopefully becomes a standard module.

So how do you use it? Here’s a brief explanation and some examples of usage. If you’d rather skip to the plugin “homepage”, please follow this link.

Usage / Configuration

You can either run the clash-detector manually from the command line, or (the best option) is to add it to your POM (ideally your parent POM that all your projects use, you do have one right?) so that it is run automatically whenever you do builds.

There are only two options you can configure, one is the level of warning the plugin should do. By default the level is FAIL, meaning your build will fail if the plugin detects any clashes. The level can be changed either on the command line by supplying the parameter -Dhalt= where the right hand of the equals sign is one of FAIL, WARN or DEBUG. For the POM the same parameter is configured by supplying the same keyword inside a tag such as: WARN

The second parameter is the level of detection the plugin should do. There are two modes, SHALLOW and DEEP. By default the level is DEEP where clash detection is not limited to the immediate level of the dependency, but also deeply nested dependencies. Shallow detection is only one level down and will not detect deeply nested dependency clashes. This is for example good for when you only care about clashes of your own jars (although I would strongly advice never using it unless really necessary).

Here are two snippets showing how to run the clash detector from the command line and how to configure it inside your POM.

Command Line

To invoke it from the command line you simply run it like this:

mvn breakonversionclash:clash-detection -Dhalt=FAIL -Ddepth=SHALLOW

In your POM


	
		
			com.hexapixel.maven.plugins
			
				maven-breakonversionclash-plugin
			
			1.0.1
			
				
					
						
						WARN
						
						DEEP
					
					compile
					
						clash-detection

Plugin in Action

Here is a typical output the plugin will produce:

 [INFO] [breakonversionclash:clash-detection {execution: default}]
 [INFO] Checking for dependency version clashes...
 [INFO] Halt mode is: 'warn'. Depth mode is: 'deep'.
 [WARNING] ------------------------------------------------------------------------
 [WARNING] Dependency version clash on 'commons-logging' [1.0.4, 1.1.1]
 [WARNING] ------------------------------------------------------------------------
 [WARNING] Clash 1: commons-logging:commons-logging:1.0.4
 [WARNING] Clash 2: commons-logging:commons-logging:1.1.1
 [WARNING]
 [WARNING] Artifacts using different versions of 'commons-logging:commons-logging':
 [WARNING] - org.hibernate:hibernate:jar:3.2.6.ga
 [WARNING] - com.our.project:plugin-domain:jar:1.0.0.0-SNAPSHOT
 [WARNING]
 [WARNING] Dependency trail for 'commons-logging:commons-logging:1.0.4'
 [WARNING] - Node 1: com.our.project:plugin-testdata:pom:1.0.0.0-SNAPSHOT
 [WARNING] - Node 2: com.our.project:plugin-testdata-source:zip:small-datasets:1.0.0.0-SNAPSHOT
 [WARNING] - Node 3: com.our.project:plugin-testdata-generator:jar:1.0.0.0-SNAPSHOT
 [WARNING] - Node 4: com.our.project:plugin-domain:jar:1.0.0.0-SNAPSHOT
 [WARNING] - Node 5: org.hibernate:hibernate:jar:3.2.6.ga
 [WARNING]
 [WARNING] Dependency trail for 'commons-logging:commons-logging:1.1.1'
 [WARNING] - Node 1: com.our.project:plugin-testdata:pom:1.0.0.0-SNAPSHOT
 [WARNING] - Node 2: com.our.project:plugin-testdata-source:zip:small-datasets:1.0.0.0-SNAPSHOT
 [WARNING] - Node 3: com.our.project:plugin-testdata-generator:jar:1.0.0.0-SNAPSHOT
 [WARNING] - Node 4: com.our.project:plugin-domain:jar:1.0.0.0-SNAPSHOT
 [WARNING] Found 1 dependency version clash

Let’s go over this even though it might be mostly self explanatory.

We have configured the plugin to only warn us when there is a clash, and to do a “deep” check, meaning it will not only check immediate dependencies, but also dependencies of dependencies.

It tells us that we have a clash on the usage of ‘commons-logging’ and that the two clashing versions are version 1.0.4 and version 1.1.1 of commons-logging.

Then it tells us what jars are using commons-logging, in this case it’s our dependency on Hibernate and our own plugin-domain project.

It then shows us the dependency “trail” for each clash, meaning, it shows what depends on what all the way to the actual dependency of ‘commons-logging’, so that you can easily pinpoint what jars need adjusting so that the clash goes away.

Download / More Info

For downloads (binary and source) and more info, please go to the Version Clash Plugin Page.