April 24, 2014

Followup To Themes

As a quick followup to the helpful article on themes posted to the Eclipse Tips blog, I would like to point out that all of the values that are in the currently active theme are also in the JFace registry. Yes, it is possible to get the current ITheme from the workbench IThemeManager, but that’s […]

So Long, And Thanks For All The Fish

I was hoping to post this a little closer to the date but the cat has been let out of the bag.  I’ve decided to leave IBM for a position at RIM.  It wasn’t an easy decision to make but in the end I thought it was best for me.  I feel like I’ve gotten […]

April 23, 2014

JFreeSVG vs Batik

Overview

JFreeSVG is a lightweight SVG generator for the Java platform, that is growing in popularity with Java developers who are seemingly attracted by its compact size---the JFreeSVG jar file weighs in at just 44Kb (and you could make it smaller with pack200).

In addition to being lightweight, we also make the claim that JFreeSVG is fast. To back that up, we've done some performance testing to compare JFreeSVG against the Apache Batik toolkit which, amongst many other things, also provides an SVGGraphics2D implementation. Bear in mind that the comparison is only looking at the Graphics2D implementations provided by these libraries. Apache Batik provides a *lot* of other SVG-related functions that are outside the scope of JFreeSVG.

The Benchmark

The benchmark program creates the following chart of the quarterly revenues for some well-known technology companies, using Orson Charts, and then exports it to SVG. The chart itself is quite interesting because it puts into perspective how much larger Apple's revenues are compared to those of other technology companies (when you get a chance, download Orson Charts and try out the interactive version):

barchart.png

The two source files are here: PerformanceJFreeSVG.java and PerformanceBatik.java. Both programs generate the chart in SVG format 1,000 times during a "warm-up" phase, then a further 1,000 times during the testing phase. The warm-up phase is intended to give the JVM a chance to perform optimisations on the running code.

Accurate benchmarking is notoriously difficult and we certainly don't have a lot of benchmarking experience. We've strived to make the tests transparent and reproducable and welcome any feedback on our results. Bear in mind that we've tested only one use case and this cannot be representative of all use cases. It's just intended to be indicative. If performance is important for your application, you should test with your own benchmarks, using a work load that is relevant for your application.

Dependencies

Both benchmark programs require the orsoncharts-1.3-eval.jar file that you can download from the Orson Charts home page. For the test we require some code that produces output via Java2D's Graphics2D API, and Orson Charts fills this need. There are, of course, many other libraries that generate output via Graphics2D, because it has been a standard part of the Java runtime since version 1.2 (which was released in 1998!).

For the JFreeSVG version, we included the following jar file on the classpath:

  • jfreesvg-1.8.jar (45,462 bytes).

For the Batik version, we included the following jar files on the classpath (to our knowledge, this is the minimum set required to use the SVGGraphics2D class):

  • batik-dom.jar (173,750 bytes);
  • batik-svggen.jar (215,802 bytes);
  • batik-awt-util.jar (403,287 bytes);
  • batik-util.jar (128,334 bytes);
  • batik-ext.jar (10,261 bytes);
  • batik-xml.jar (30,862 bytes);

The six Batik jars add up to 962,296 bytes, which is a factor of ~20 times larger than the 45,462 bytes for the JFreeSVG jar file.

The Results

There are two aspects of the results that we are interested in. First, the size of the SVG output that is generated and, second, the time it takes to generate the SVG.

We ran the benchmark programs using Java 1.8.0 update 5, on a MacBook Air.

Output Size

Batik creates an SVG file with size 72,996 bytes while JFreeSVG creates an SVG file with size 81,452 bytes. The Batik-generated file is approximately 10% smaller, so Batik does better on this metric.

Processing Time

For the processing time, the following table shows the results:

table, td, th { border:1px solid gray; padding:5px; } th { font-weight:bold; background-color:#7cbc20; color:white; }

JFreeSVGBatik
Warm-up Phase (1,000 repetitions)7,445 milliseconds24,448 milliseconds
Testing Phase (1,000 repetitions)4,297 milliseconds21,022 milliseconds

JFreeSVG is converting the chart to SVG approximately five times faster than Batik. That surprised us a little, it has to be said, but it is a nice backup to our claim that JFreeSVG is fast.

We used JFreeChart with JFreeSVG to visualise these results:

Performance: JFreeSVG vs Apache BatikWarm-upTestTime to generate 1,000 charts in SVG (lower bars = better performance)JFreeSVGBatik02,0004,0006,0008,00010,00012,00014,00016,00018,00020,00022,00024,000

Conclusions

JFreeSVG is certainly compact relative to Batik as a dependency for Java programs that need to generate SVG output via the Graphics2D API. This analysis has shown that JFreeSVG can have a small output size penalty relative to Batik, but compensates for this by being many times faster.

The original version of this blog entry can be found at http://www.object-refinery.com/blog/blog-20130423.html.

April 21, 2014

FindBugs Eclipse plugin and Java 8

In case you already use Java 8 for development (or at least plan it), here is the Eclipse update site for the nightly builds of the FindBugs Eclipse plugin: http://findbugs.cs.umd.edu/eclipse-daily/ which supports new Java 8 class file format.

Enjoy. 

IntelliJ IDEA 13.1.2 Update is Available

Great news! Start the week by downloading IntelliJ IDEA 13.1.2, a fresh new update with a lots of enhancements and bugfixes (including the fixes for performance issues).

If you’re already running IntelliJ IDEA 13.1 and haven’t yet received a notification about the update then go ahead and press Check for Updates.

Develop with Pleasure!

April 16, 2014

IntelliJ IDEA 13.1.2 RC is Out

In case you haven’t noticed, yesterday we published a fresh EAP build which is likely to become the IntelliJ IDEA 13.1.2 update if no serious problems found.

Read the release notes for the complete list of changes.

Develop with Pleasure!

March 12, 2014

Going to EclipseCon, see you there!

The closer we get, the more exiting it is.

The conference is packed with lots of interesting content. I’m also looking forward to the new special days at EclipseCon which are new this year. Read more about EclipseCon and why you should attend on Ian Skerrett’s blog and also on the EclipseCon website.

FWIW, I’ll give two talks myself this year:

Unshackling Mylyn from the desktop
Grand Peninsula A – Tuesday, March 18, 2014 – 13:30 to 14:05

Andrew Eisenberg and myself been working on a prototype to extend Mylyn from the Eclipse IDE into web IDEs. While doing that, Andrew also came up with a few other interesting extensions using the same open web APIs to bring Mylyn into basically any other application. That’s pretty cool. There will be some slides in the beginning and then a full set of demos.

Gerrit reviews from within Eclipse
Grand Peninsula C – Tuesday, March 18, 2014 – 16:15 to 16:50

This one was originally proposed by Ericsson but the speaker isn’t able to attend EclipseCon. However, I was involved in the work that happened last year from the beginning and it’s now available in Mylyn Reviews. With the Gerrit dashboard now being available within Eclipse it’s no longer necessary to switch between the web and Eclipse back and forth when doing code reviews.

For me personally, it really is like a big family anniversary. It will be my ninth EclipseCon in North America and I’m pretty sure it’s not getting any less interesting then my first one. I also look forward to the Hyatt, which I never been at before.

See you all there on Sunday and throughout the whole week!

March 10, 2014

Orson Charts 1.2

I just released a new version of Orson Charts, a 3D chart library for the Java platform. Version 1.2 contains significant new features driven by customer requirements:
  • logarithmic axis support;
  • value and range markers for all numerical axes (to match a similar feature in JFreeChart);
  • localisation support (with German and Italian localisations initially);
  • improved axis labelling with new tick label orientation options plus "stepped" labelling for category axes;
  • chart theme support, with some built-in themes plus the ability to create your own;
  • a JPEG export option (to add to the existing PNG, PDF and SVG export options).

In this release, we've also made efficiency improvements in the rendering engine and fixed a number of bugs that have been identified by clients and through our own testing (the recent exercise of creating the Orson Charts for HTML5 port uncovered a few issues, for example).

I can't have a blog post without a few screenshots so first up here is an example of the logarithmic axis (on the y-axis here, but it is possible to use a log scale on any numerical axis):

ScatterPlot3DDemo2_2.png

Next up, an example showing the highlighting that can be done with the new marker feature (see that the categories "Apple" and "Q4/12" have been highlighted, plus the bar is rendered in red to draw attention to that particular data value...Apple makes a *lot* of money, but you already knew that):

CategoryMarkerDemo1.png

Finally, some range markers on an XYZ plot to highlight particular ranges of values (and a custom color source to highlight those items that fall within the intersection of the three ranges). The most typical usage would be to show a range of y-values in some target range, but for demo purposes the example below adds a range marker to each axis:

RangeMarkerDemo1.png

Our focus for the next release is to continue improving the interactivity of the charts. While we are working on that, please go and download the free evaluation of Orson Charts 1.2 and send us your feedback.

February 14, 2014

I've moved

I got tired of dealing with Blogger's crappy spam management system and I wanted to play with a little server I have in the cloud. I'm now at http://cdtdoug.ca and a happy WordPress user. See you there.

February 08, 2014

AnyEdit on bintray

I've just released new version of AnyEdit plugin (2.4.6).

There is a one small new feature ("Open File under Cursor" actions understands now paths with leading variables, like $HOME/anyedit/is/cool.txt or $(HOME)/anyedit/is/cool.txt or ${HOME}/anyedit/is/cool.txt) and one compatibility fix for coming Eclipse 4.4 (looks like there is a bug with merging of action contributions to the same menu defined in both "org.eclipse.ui.menus" and old "org.eclipse.ui.popupMenus" extension points).

But the reason for this post is different one:  this is the first time I've made a release by using bintray service and not Eclipse Labs as a host for my binaries. Why? Google decided to discontinue offering "downloads" for Google Code projects, and Eclipse Labs is unfortunately based on it. From one side I can understand Google (they want to promote Google Drive), but from another side it is just plain stupid. The last thing one should do as a public service is to upset developers, but this is what actually happened. I've filed bug 427525 but I honestly don't think this will change much.

P.S:

Always look on the bright side of life - I've now learned pretty useful hosting service which looks really nice (thanks to bintray guys).

February 01, 2014

Eclipse Bundle Recipes

The Eclipse Bundle Recipes project (EBR) was created with the intention to develop and host a technology and recipes for creating OSGi bundles out of regular non-OSGi Java libraries. Unfortunately, not a lot has happened after it’s creation. Frankly, as the Git repository and the history unveils, it has been just a code drop of the SpringSource Enterprise Bundle Repository recipes. I’m here to change that!

As an Orbit committer, it’s has been my pleasure to convert Java libraries to OSGi for quite some time now. If you know how Orbit bundles are created, you know it’s an exercise. Thus, I also have a high motivation for the Eclipse EBR project to be successful. Last week was one of those where I looked at upgrading a few of the Orbit bundles I’m maintaining. Turns out, the libraries are actually quite active and – as every good OS project does these days – they also release very frequently. That’s really turning into a boring exercise. Thus, I decided to craft together a process that would simplify things for me.

The result is very promising. With just one nice little Maven plug-in I created, a small Maven POM and an OSGi BND descriptor file I’m now able to consume the libraries directly from Maven central (or whatever Maven repo they come from), push them through a filtering step which may remove or add files, generate the OSGi manifest headers, add p2 metadata information and deploy them back into a Maven repository (eg. a local one). Then, in a second step, I’ll let Tycho run and it creates a p2 repository where the bundles are published together with a source bundle containing the library source code. Done.

Over the next few days I’m hoping to make that available in the EBR Git repository. For the time being I pushed it to Github*[1]. I first need to review the dependencies and push them through the Eclipse.org IP process. Once that is done, we should have a pretty neat solution for EBR. However, remember that EBR will only host and distribute the recipes, not the actual libraries. You have to generate them yourself.

For Eclipse projects, this is where Orbit comes back into the game. Orbit can take and run the recipes of all IP approved libraries from EBR (or create its own) and publish the bundles as today in p2 repositories.

Stay tuned!

[1]: Update, Feb. 28

I pushed the Maven plug-in as well as the first recipes to the Eclipse Git repository. You can browse them at git.eclipse.org.

January 24, 2014

Results: EclipseCon 2014 is returning to California... What are your thoughts?

The results are in!!  Earlier this week I posted a whacky poll, asking you what your thoughts were on EclipseCon's return to the Bay area.  Here are the results:


36 Im-glad-its-back-in-SF-I-hope-the-weather-is-nice

32 Im-still-hopeful-for-an-EclipseCon-in-Maui-make-it-happen

30 I-prefer-the-east-coast-less-time-on-a-plane

No surprise there.  I enjoyed driving to the last two EclipseCons but I'm looking forward to sunny California!

16 doesnt-matter-where-ECon-is-I-will-be-there

11 Im-glad-its-back-in-SF-I-will-visit-with-family-and-friends



6 what-no-beer

I have to keep my material fresh, so there were no choices for beer.  Sorry.  But that didn't stop some poll veterans from making up some choices.

SF-is-the-best-so-are-Eclipse-webmasters
Im-glad-its-back-in-SF-and-twice-as-glad-to-join-the-EF-staff

Hi-Dennis-This-is-me-again-will-you-give-me-a-beer-somedays

Looks like I owe some kind folks a beer or two.  Less than 2 months to EclipseCon North America, see you there!

January 22, 2014

Poll: EclipseCon 2014 is returning to California... What are your thoughts?

There was a time when EclipseCon was as West Coast USA as the Golden Gate bridge.  However, unlike the bridge, EclipseCon has been to Washington, D.C. and to Boston, Massachusetts to broaden its horizons.  Next March, the favourite gathering point for the Eclipse community is returning to the bay area for its 10th anniversary.

So here's the poll: What do you think about going back to San Francisco?  Clickety-click the links below to cast your votes:


http://eclipsecon.org/webmaster/Im-glad-its-back-in-SF-I-hope-the-weather-is-nice


http://eclipsecon.org/webmaster/Im-glad-its-back-in-SF-I-will-visit-with-family-and-friends


http://eclipsecon.org/webmaster/I-prefer-the-east-coast-less-time-on-a-plane


http://eclipsecon.org/webmaster/doesnt-matter-where-ECon-is-I-will-be-there


http://eclipsecon.org/webmaster/Im-still-hopeful-for-an-EclipseCon-in-Maui-make-it-happen


Next week I'll post the results!  Remember, no ballot stuffing or reverse-engineering of the polling process!

November 22, 2013

Iterative Binary Tree Traversals

Iterative Binary Tree Traversals
In internet you will find many posts describing how to implement preorder/postorder/inorder iteratively.

for example http://en.wikipedia.org/wiki/Tree_traversal has iterative algorithms for preorder, postorder and inorder.

I found them to be difficult to understand the logic behind them.
even if you banged your head to understand iterative versions of all three traversals, it is difficult to memorize them when needed (say in interviews)

why can't we implement single iterative algorithm which computes all the traversals.
So first I implemented iterative DFS, and then carefully worked out, how to compute all traversals during DFS.
 


        preorder                 inorder                 postorder                
   
   F B A D C E G I H        A B C D E F G H I        A C E D B H I G F
 
void dfs(Node n, List preorder, List inorder, List postorder){
    Stack path = new Stack();
    path.push(n);

    while(true){
        n = path.peek();
        preorder.add(n);
        if(n.left!=null){
            path.push(n.left);
        }else{
            inorder.add(n);
            if(n.right!=null)
                path.push(n.right);
            else{
                while(true){
                    n = path.pop();
                    postorder.add(n);
                    if(path.isEmpty())
                        return;
                    else if(path.peek().left==n){
                        inorder.add(path.peek());
                        if(path.peek().right!=null){
                            path.push(path.peek().right);
                            break;
                        }
                    }
                }
            }
        }
    }
}

preorder:
          when you are about to visit left child, append it to preorder
inorder:
          when you are about to visit right child, append it to inorder
postorder:
          when visiting of a node's subtree finished, append to postorder
          i.e when we do path.pop()  append popped node to postorder

The above algorithm can further be simplified:

final int VISIT_LEFT     = 0;
final int VISIT_RIGHT    = 1;
final int VISIT_FINISHED = 2;

void dfs(Node n, List preorder, List inorder, List postorder){
    Stack path;
    path.push(n);

    List lists[] = { preorder, inorder, postorder };
    int index = VISIT_LEFT; // tells the action to be taken an path.peek()
    while(true){
        n = path.peek();
        lists[index].add(n);
        if(index==VISIT_LEFT){
            if(n.left!=null)
                path.push(n.left);
            else
                index++; // i.e VISIT_RIGHT
        }else if(index==VISIT_RIGHT){
            if(n.right!=null){
                path.push(n.right);
                index = VISIT_LEFT;
            }else
                index++; // i.e VISIT_FINISHED
        }else{
            path.pop();
            if(path.isEmpty())
                break;
            if(path.peek().left==n)
                index = VISIT_RIGHT;
        }
    }
}


August 20, 2013

A Great Comment about the Eclipse IDE

My favorite thing about blogging is the comments that come in telling me I'm full of crap and here's why :). It's a great way find out whether I am full of crap and I usually learn from those comments which helps me make decisions. It's a great resource and highly recommended, assuming you don't mind being told you're full of crap.

Anyway, BrunoM commented on my post about the Eclipse IDE being dead-ish and I thought I'd repost them here so everyone can see and he's given permission to do that. He makes some great points. I think I end up agreeing with him. Making the Eclipse IDE cool is just to get people looking again. At the end of the day, it just needs to be a great multi-language IDE. And bringing the IDE community together, break down the project silos, is a great idea on how we could do that. More on my ideas on that later. First, here's Bruno.

"Hello Doug. It's an interesting post you have here.

"First, like many others here, I do agree that Eclipse is losing a lot of momentum, even regressing in some aspects (more on than later). But I don't agree with your vision of what Eclipse should look forward to be. I've been following your Twitter and blog posts for quite some time, and I see this recurring pattern: the desire to make Eclipse more exciting, but exciting not necessarily in a functional and technical sense, but more in a visual way: by means of making it more "cool" or "hip". You often draw comparisons to the all the new "sexy" and cool games, mobile apps, and "Web 2.0" websites and technologies we see out there.

"Again, I respectfully disagree with this vision. Eclipse is a tool a for developers, as its goal should be first and foremost to be as productive, easy and functional to use as it can be. Cool and interesting, but in matter of *substance*, not style. (PS: I'm quite the gamer, but it doesn't change my opinion. Eclipse is not a game.)

"Now, second, regarding the main subject: Is Eclipse, as an IDE, losing momentum? It sure feels that way! And not just because it is a large and accomplished project that achieved a lot already... if it was just that case it would be okay to lose momentum in a sense, but it seems that the quality of Eclipse has actually been regressing (and a lot of opportunities have been missed). Let me be more concrete about what I mean here.

"I am an user of the Eclipse IDE in two ways. Both as a user of the JDT IDE, to develope Java, but also I am user/consumer of the Eclipse IDE API, as I develop plug-ins for Eclipse. (I worked on Eclipse RCP apps, but more significantly I head the developer of an Eclipse based IDE for the D programming language: DDT)

"As a user of JDT, and the Eclipse IDE in general, let me tell about my experiences. I've always loved Eclipse, but when I started trying out the 4.x series, I felt a bit disappointed. The new themes looked horrible, to be honest. Not just in a subjective sense, but there was several visual/rendering bugs as well. This was the 4.1 release if I recall correctly. I decided to stick with 3.x as long it was the main Eclipse release. Then 4.2 came, and Eclipse 4 became the main version. I decided to switch finally. After several months of use I noticed it was way buggier than the 3.x series. A few JDT bugs, but most where Platform bugs (views getting lost, icon/action sets getting lost or misplaced to wrong places, view setting not getting saved/persistend, workbench broken with views/editors getting partial focus - they would receive the normal keystrokes, but command shortcuts would be sent to a different view/editor! This last one drove me nuts, as it happened quite frequently, and after the workbench was broken like this I had to restart Eclipse to fix it).

"The frequency and severity of these bugs, for very common tasks, left me with a bad taste in my mouth. This was compounded by the fact that this was the 4.2 release, ie, there had been two previous releases of the 4.x series already! I know that Eclipse 4 involved a major rewrite of Platform internals, but two releases should have been more than enough to wring out nearly all of these major issues.

"This (combined with news like IBM not investing as much in Eclipse as it used to) gave me the impression that the technical excellence of the core components of Eclipse was not as good as before.
Other news do not looked favorably on this either, such as the recent one about ADT moving over to IDEA... Guys that should have been a major wake up call!

"As a user of the Platform and IDE API to develop new plugins, I also think a few opportunities are being missed. I was in love with Eclipse since the early days of 3.x, and by then, it was one of the best options to develop IDEs for other languages. I was involved with this area since 2008, which was when I first started working with Eclipse to develop an IDE for the D language. But this area appears to have stagnated ever since, despite the fact that a lot of improvements and technology could be developed. Whereas a fair amount of innovation has happened for developers of RCP applications, what new developments have occurred that make it easier or more powerful to write new IDEs in Eclipse?

"None really, with the exception of Xtext, and the DLTK (Dynamic Language Toolkit) project. There was also another project similar in scope to DLTK, IMP, but it pretty much seems to have died. Xtext has been quite interesting and looks fairly mature, but I would argue that it is not that adequate for more complex, general purpose programming languages.

"DLTK is actually a great idea for a project, and very useful. And indeed target for programming languages. The way it's done, at least with most of it's codebase, is that it copies a lot (really, a lot) of JDT code, and adapts it to be usable to other languages. Code such as JDT's project model, indexing functionality, compiler/interpreters setup, source editor, and lots UI boilerplate code. So for example, DLTK IDE projects usually have a project layout and view similar to JDT: with source folders, hierarchical packages, source modules, model elements nested within, etc.. The D IDE I work on is actually based on DLTK as well, even though D is not a dynamic language at all. It just happens that a lot of DLTK functionality is useful for non-dynamic languages as well.

"The problem here is that DLTK is quite rough on the edges, both in terms of functional limitations, API limitations, bugs, and brittle documentation. That's not surprising, it is a massive undertaking, and it doesn't have that much manpower allocated to it, from what I understand. It has been improving steadily, which is good at least, but at a slow rate.

"Now, the point to take from the comment above, is that there is a huge missed opportunity here. You see, I understand that it's not reasonable to expect a faster rate of progress with a project like DLTK, since it's mostly developed by people from one or two smaller companies with their own specific commercial interests, goals, and resource limitations. The thing is, why couldn't the JDT team work toghether with DLTK? Why couldn't all (or some) of those components of JDT be adapted for more general IDE use, by the JDT team itself? It's likely a major undertaking still, but it certainly would have been more effective than having a third party team adapt JDT for general purpose use, in hindsight (and the gains could have come much sooner). There are also a lot of problems with code duplication here. How bad these will be in practice, will depend, I guess, on how often the affect JDT code based changes in the future.

"As a participant in the D community, I've also been taking a look at developments of D IDEs in other platforms. There are two quite significant D IDE projects based on Visual Studio and MonoDevelop. People have toyed a bit with Netbeans and IntelliJ IDEA, but nothing signicant has come of it so far. I was quite surprised with the MonoDevelop one though: both the base platform, and the D IDE for it are quite full featured. And this is for a platform (MonoDevelop) that is a quite recent newcomer in the scene.

"Guys, the way I see, Eclipse feels like Subversion. It's fairly good and useful, and it's much better than CVS (which could be say, Visual Studio or CodeBlocks or something). But one day, a team with superior technical excellence could well create the equivalent of Git for an IDE platform, and it will just blow away Eclipse completely, in a heartbeat... :/"

April 09, 2013

Laptop do biura, firmy

Tytuł posta mówi o wybieraniu laptopa firmowe, czyli do pracy (tutaj: laptop do gier). No ale tu się rodzi pytanie czy w każdym biurze wykonuje się na laptopie jedynie prace biurowe. Oczywiście że nie, dlatego laptopy zaproponowane poniżej nie będą się nadawały do firm, w których nie używa się wymagających programów komputerowych i nie wykonuje na laptopach wiele obciążających komputer prac (tzn.

January 24, 2013

Moja opinia o Unixstorm.org + kod promocyjny (20% zniżki)

Na serwery Unixstorm musiałem przenieść się jakiś rok temu. Miałem wtedy sporo problemów z małymi hostingami (aczkolwiek znanymi), bo przetrzymywałem na tych kontach dość spore ilości serwisów :) Założeniem było wybranie i przeniesienie dobrych stron na dobry, stabilny i niedrogi hosting. Po wielu przeczytanych wątkach na forach i innych opiniach, wybrałem w końcu Unixstorm.org. Przeniosłem

September 27, 2012

Looking for Job Opportunities

Looking for Job Opportunities

I am looking for job opportunities in Bangalore.

My resume is available in here.

Please contact me, for any further information.


June 28, 2012

Eclipse p2 Frustrations


Eclipse p2 continually frustrates me. For years I have been working around it and we have been peacefully coexisting. I recently tried to dip my toes back in the water to see if I could better understand it and use it better.  I have what seems to me a simple situation that would be common in the Eclipse world but I cannot find a satisfactory solution.

I have an Eclipse feature comprised of many plugins. These are intended to be installed in an Eclipse-based IDE and the assumption is that it should be possible to install it via the update manager UI of Eclipse or the Marketplace client. My feature extends a lot of other Eclipse plugins that need to be installed.  For example, it needs Subclipse, Mylyn, GEF and several other plugins.  Some of these are hosted on eclipse.org and some are on other sites.  I want someone to be able to install my feature and have any other features that are needed discovered and installed automatically and seamlessly.

The peaceful coexistence I have talked about is that I have been able to make this work by hosting all of the dependencies on the same update site as my feature.  This is labor intensive and kind of annoying but it worked so that is what I did.  I would much prefer to just publish a site that contains only my features and whatever pointers are needed for Eclipse to go get the rest of the plugins.  I cannot figure out any way to do it and I have not seen any other sites that do this successfully so I just assume Eclipse cannot do this.

Am I wrong in thinking this should not only be possible, but easy?

I have tried adding associate sites to the site.xml.  That did not do anything.   I tried adding a p2.inf file to my feature JAR's.  I could see that the UpdateSitePublisher added the instructions to the content.xml file, but it appears to add them in a place that would only be applied after my feature is installed.  So it does not help for my scenario of needing to add these sites to find required dependencies.  I am at a loss and about to go back to my ugly workaround.

August 03, 2011

Debugging Eclipse Indigo plugins on OSX

I do not why this took me so long to figure out, but I have been having a problem with Indigo that whenever I fire up the Eclipse Runtime workbench to debug a plugin it would crash almost immediately. At first, I thought it had something to do with my plugins, but eventually I took the time to do a clean install without any of my plugins and saw the problem just by creating a simple demo project in the runtime. Since I already had a working Helios installation, I just shrugged and went back to using that for now and set the problem aside.

Well, last week I got a new Macbook Air with Lion preinstalled and so I am setting up a new system from scratch. This time I only have Indigo installed and lo and behold I am still seeing the same problem. Realizing that there must be a simple explanation, I now looked closer and see that there is a simple explanation. For some reason, on Indigo when it Eclipse creates your default configuration it is not including the PermGen settings by default. So I was just crashing due to not enough PermGen space errors. Pretty obvious, it has just been a long time since I had seen these problems.

Adding "-XX:MaxPermSize=256m" to the -vm arguments in my Runtime Configuration has everything working great again.

April 28, 2011

Back to Oracle!

Summary: I’ve loved my last five years at the Eclipse Foundation. It’s time for me to move on. I’m going to Oracle to work on OpenJDK and other things.

The longer version:

It was over five years ago that I joined the Eclipse Foundation. I had just finished an MBA and was working at Oracle in a well regarded technical swat team in Java middleware. The Eclipse Foundation had launched in my hometown of Ottawa, and here I was, eager to learn about open source, the rapidly changing business model of enterprise software, ecosystems and to do something fresh. So I took advantage of this unique opportunity and convinced Mike that I should help run the Eclipse Foundation membership.

My 5+ years at Eclipse were incredibly rewarding both personally and professionally. I’ve made countless new friends and acquaintances from all the organizations that I’ve had the pleasure of working with. I was privileged to be working directly with many great thinkers in the software industry, and learning about how big ideas, like Eclipse, happen.

All the staff at the Eclipse Foundation that I’ve ever worked with have been high performing and maniacal about driving the Eclipse Ecosystem forward. I believe the Eclipse Foundation has done great things by helping hundreds of organizations keep pace with evolving business models and to make available a lot of high value free software. I leave the Eclipse Foundation with complete respect and admiration for every single person there. They do incredible things with limited resources and many constraints. I will continue to be a fierce advocate and supporter of all things Eclipse.

I believe strongly that we are at the beginning of a renaissance period for Java. Once again there is real investment and participation in Java. There is a roadmap that has an immediate impact with Java SE 7, and plans far into the future – with many organizations and stakeholders keen to see it happen. Moreover, I’m convinced that once a world class modularity solution becomes part of core Java, we will see even more and faster innovation. It means great things from the biggest cloud, to the smallest device.

I have a matching skill set to help Java evolve for the decade to come, so I decided to jump at an opportunity to join the Oracle Java SE team. I will be working with OpenJDK and other things. I am truly proud to be working with folks like Dalibor Topic, Henrik Staal, Mark Reinhold and Adam Messinger.

The team I’m on has one simple mandate – keep Java the number one computing platform in the world. Period. I start May 9th, and will post some pointers when I land.

- Don

April 26, 2011

I've been hacked!

I was hacked today (or at least I learned of it today). Early this AM a SPAM was sent from my GMail account to all of the Contacts in my GMail -- which I believe is any address I have ever received an email from. Given all of the mailing lists I am on, this is a decent number of addresses. Since the email was DKIM-verified to come from GMail and it went to all my contacts, I have to assume someone was able to successfully login to my GMail. I have since changed my password a couple times, and turned on the 2-factor authentication feature. I would highly recommend everyone do this with their Google account if they have not. I also changed my password on every site I can think of, just for safe measure.

How did this happen? I have no way to know for certain, but I have a theory. The Sony Playstation Network has been down for several days now due to some kind of attack. My username for PSN was my GMail account and I was stupid enough to use the same password (or at least they matched last week, I may have recycled back to it). I mainly use PS3 and PSN for Netflix streaming. I suspect that when the site was first down last week that intruders were intercepting logins and they got the username and password. My main reason to doubt this theory is that hacking PSN seemingly was sophisticated to do, so why would they use the information they stole in such an amateurish way as to send an obvious SPAM that alerted me to the problem? I have to think they downloaded all my email and information before they did this. I wonder why they did not also change my password as it seems like they could have done so.

It is fairly disconcerting to wonder what private information, such as credit card numbers, that I might have in my GMail archive. For now, I at least think I have safely updated all of my accounts so that the passwords are different on every site.

Update (2011-04-26): Sony has now pretty much confirmed that this all originated with the hack of PSN. See this blog post: http://blog.us.playstation.com/2011/04/26/update-on-playstation-network-and-qriocity/ Of course it was still stupid on my part to use my GMail password anywhere outside of GMail.

March 24, 2011

Announcing EclipseCon Europe 2011, and EclipseCon North America 2012 Program Chair

As I mentioned this morning at EclipseCon, we're proud to announce EclipseCon Europe, 2011. New name, but same great conference. We wanted to demonstrate the equal importance of both our major events, and decided to unify on the "EclipseCon" brand. Bernd Kolb will be reprising his role as Program Chair and we hope he makes great use of the extra space. We sold out early last year, so plan to register early to avoid disappointment!

Also, we'd like to announce Doug Schaefer (CDT Project Lead) as the Program Chair for EclipseCon North America 2012 (exact dates and location TBA). We've had an excellent run of great Program Chairs who put their own touch on EclipseCon and we're looking forward to Doug's perspective and leadership.

- Don

January 03, 2011

Open Letter to WANDisco

Shortly before we all went away on our Christmas holiday, one of the companies that sponsors developers in the Subversion community, WANDisco, delivered a big fu#k you to the rest of the community in the form of a press release and blog post from their CEO Dave Richards.

I commend my fellow members of the Subversion PMC for being able to take a deep breath and wait a couple weeks to respond with a cool head. Had it been up to me alone, I am sure we would have said something that felt good at the time but that we regret later. You can read the official response here on the Apache Software Foundation blog:

Apache Subversion to WANdisco: +1 on the code contributions, -1 on the attitude

I was, and am, deeply offended by Dave Richards and WANDisco in general. Their business model seems to be to issue press releases rather than actually doing stuff. In my experience, companies that choose to issue press releases BEFORE they start working on something are usually to be ignored and I think that is the case here too. The difference is that WANDisco is attempting to portray themselves as leading the Subversion community and as such that they are speaking for the community. As the blog post from the Subversion PMC illustrates, they neither lead the community nor are the welcome to speak for it.

That said, I get it. No one knows or cares who WANDisco is and by issuing press releases and generating controversy a few more people will now have heard of you. Congratulations. Bully for you. However, in the process your actions are only damaging the product and community you claim to care so deeply about. This reveals your true motives.

If you are so desperate for attention that you feel the need to issue press releases we probably cannot stop you. If you absolutely have to to issue a press release to try to garner some attention, then why could you not simply issue something that says "Hey we think features X, Y and Z are important and we wanted to let you know that we intend to direct our resources to work on those features." I could live with that even though I would rather see you work on the features before you crow about it. As it stands, just as you did a year ago with the Obliterate feature, you are just setting your people up for failure. You have declared that you are going to implement new features that the Subversion committers that work for you already know cannot be solved in the near term. You have brought no new ideas to the table nor any idea how any of the known obstacles that have blocked these features will be overcome. To top it off you have attempted to slap a release date on it. Good luck with that.

I really hope that we implement some of the features in your list and it would be even better if we can get some of them done in 2011. Most of your list was already on the roadmap we published last year. Unfortunately, the way you are going about this is not going to help any of that happen and if we do have some success it will likely be in spite of your efforts not because of them.

September 02, 2010

A new direction for bindings?

I'm happy to report that I've been given company approval to port the relevant components of our Flex data binding library back to Eclipse Data Binding.

I haven't started the actual port yet--there are still some concepts on the Flex side that are not a perfect match to Java and existing idioms in Eclipse Data Binding. You'll see what I mean.

To avoid conflating the port to Java with the general API I'm going to just present what the Flex API looks like.

  Bind.from(source, "foo")
.to(target, "bar");

This binding watches the source.foo property, and writes the new value to target.bar each time a change it detected. Now add some validation and conversion magic:

  Bind.from(source, "foo")
.validate(Validators.stringToNumber)
.convert(Converters.stringToNumber)
.validate(Validators.greaterEqual(0))
.validate(Validators.lessThan(10))
.to(target, "bar");

Here we've added several additional steps in the pipeline.

  • After source.foo changes, we first validate that the string can be converted to a number. If so the pipeline continues to the next step, and terminates otherwise.
  • Next we convert the string to a number
  • Now validate that the number is greater than or equal to zero. If so the pipeline continues to the next step, and terminates otherwise.
  • Now validate that the number is less than 10. If so the pipeline continues and the number, now verified to be in the range [0,10), is written to target.bar.

Now suppose our binding is misbehaving somehow, and we want to troubleshoot. We can add logging steps to the pipeline in between the other steps so we can see exactly what is going on:

  Bind.from(source, "foo")
.log(LogEventLeven.INFO, "source.foo == {0}")
.log(LogEventLeven.INFO, "validate {0} is a number")
.validate(Validators.stringToNumber)
.log(LogEventLeven.INFO, "convert {0} to a number")
.convert(Converters.stringToNumber)
.log(LogEventLeven.INFO, "validate {0} >= 0")
.validate(Validators.greaterEqual(0))
.log(LogEventLeven.INFO, "validate {0}

.validate(Validators.lessThan(10))
.log(LogEventLeven.INFO, "set target.bar = {0}")
.to(target, "bar");

(In Flex, string formatting is done with {n} format instead of the %s syntax which Java inherited from C. The log statement passes the values in the pipeline as additional arguments which you can reference in log statements.)

These log steps are a real lifesaver for tracking down and squashing bugs in your binding code.

If you've already worked with Eclipse Data Binding you may have noticed something else: you are no longer constrained to the standard data-binding pipeline. You are free to add steps in the pipeline wherever you like and in any order you like.

Next up is two-way bindings. The bind class provides a twoWay method which connects two bindings to the other one's starting point:

  Bind.twoWay(
Bind.from(source, "foo"),
Bind.from(target, "bar") );

is equivalent to:

  var lock:Lock = new Lock();
Bind.from(source, "foo")
.lock(lock)
.to(target, "bar");
Bind.from(target, "bar")
.lock(lock)
.to(target, "foo");

Notice that each binding has a "lock" step in the pipeline. Only one binding can hold a lock at a time. This solves the common infinite loop problem:

  • source.foo changes. binding one executes, writing the value to target.bar
  • target.bar changes. binding two executes, writing the value to source.foo
  • source.foo changes. binding one executes, writing the value to target.bar
  • ...
  • stack overflow!

Since only one binding can hold the lock at a time, this is what happens instead:

  • source.foo changes. binding one acquires the lock and executes, writing the value to target.bar
  • target.bar changes. binding two attempts to acquire the lock but it is already acquired. binding two aborts.
  • binding one releases the lock

You should never add the same lock more than once to a single binding, since that would guarantee that the binding will never run.

Two-way bindings can use validations, conversions, logging, locks etc just like regular one-way bindings (since two-way bindings are just two one-way bindings wired up to eachother):

  Bind.twoWay(
Bind.from(person, "birthDate")
.convert(Converters.dateToString(dateFormat))
Bind.from(heightText, "text")
.validate(Validators.stringToDate(dateFormat))
.convert(Converters.stringToDate(dateFormat))
.validate(Validators.lessEqual(now))
);

We usually leave out the validations in the model-to-UI bindings. It's usually only important to apply validations when you're copying data back from the UI to the model, to make sure domain constraints are satisfied, such as ensuring that a birth date occurred in the past.

And now for my favorite part: binding from multiple sources, to multiple destinations. Raise your hand if you have ever had to wire up a UI form like this:

  Is there a foo? (o) Yes  ( ) No -- fooRadioGroup

Enter bar: ____________________ -- barText

Requirements:

  1. fooRadioGroup.selectedItem is bound to model.foo (a boolean)
  2. barText.text is bound to model.bar (a string)
  3. barText must be enabled iff fooRadioGroup selection is Yes.
  4. When the user clicks "No," set model.bar to null but do not clear the text box. If the user clicks "Yes" again, set model.bar back to the contents of barText

Requirements 1 and 3 are easy:

  var fooLock:Lock = new Lock();
Bind.twoWay(
Bind.from(model, "foo"),
Bind.from(fooRadioGroup, "selectedItem"),
fooLock); // explicitly provide the lock, see more below

Bind.from(fooRadioGroup, "selectedItem")
.to(barText, "enabled");

Requirements 2 and 4 are kind of related to eachother. The model-to-UI binding is simple enough: just write the value straight across:

  var barLock:Lock = new Lock();
Bind.from(model, "bar")
.lock(barLock)
.to(barText, "text");

However the inverse binding (UI-to-model) must also take fooRadioGroup.selectedItem into account to decide whether to write back barText.text (if Yes is selected) or null (if No is selected).

The Bind class has another trick up its sleeve:

  Bind.fromAll(

Bind.from(fooRadioGroup, "selectedItem")
.lock(fooLock),

Bind.from(barText, "text")

)
.lock(barLock)
.convert(function(foo:Boolean, bar:String):String {
return foo ? bar : null;
})
.to(model, "bar");

Look closely. The binding pipelines that we pass to fromAll(...) become the arguments, in the order they are provided, to the converter and validator functions further down the pipeline. The first pipeline is from fooRadioGroup.selectedItem and therefore that boolean value is the first argument to the converter. Likewise, the barText.text pipeline is provided second, so that string value becomes the second argument to the converter.

The converter takes multiple values but returns only a single value. This is where those values get coalesced into a single value that we can write to the model--in this case, a String value or null.

The outer pipeline adds a locking step on barLock, which is expected since we need to prevent infinite loops between the last two pipelines. However we are also locking on fooLock, on the first of the inner pipelines. We had a problem with our bindings overwriting values in the UI depending on the order things were initialized.

It turned out that without that lock, if a new model object was set, then the foo binding would fire first. Thus model.foo was copied to fooRadioGroup.selectedItem. But that would trigger our last binding to execute, so if the new foo value was false, then the last binding would override anything in the text box and set null on the model.bar field, before the model.bar => barText.text binding had a chance to execute!

A good rule of thumb is that any time you need to bind from multiple sources, you should make sure to create a lock to share between all the bindings to relate to the same field in the model.

Obviously there are several concepts that will have to be adapted to work elegantly with our existing APIs. Realms are a missing piece (Flex is single-threaded so we didn't even have to consider it). Also we would want to try to retrofit the existing binding classes to use this new API transparently, like we did with the transition from custom observables to custom properties.

So there you have it. This is my current vision of what Eclipse Data Binding should evolve toward.

Comments?

August 12, 2010

Back in the Saddle

I've been away (and neglecting Eclipse DataBinding) for a long time now. I want to offer my sincere apologies to any and all who've been affected by my lack of attention.

Now that I've settled back into my old routine, I have a new problem. There is a mountain of new / updated bugs in Bugzilla and not enough free time to catch up on all of them. Please help me prioritize by pinging the tasks important to you! Vote, comment, post patches, whatever you have time for--just let me know where the pain points are.

About the time I disappeared from Eclipse, I started a new job at Overstock.com and it's really an awesome place to work. We're always looking to hire new programmers, so send me a line if you're looking for something new.

While at Overstock I've been doing some Flex development, and (surprise!) working on a data binding library in Flex. Yes, technically Flex already has declarative data binding baked in. What I'm working on brings data binding to the ActionScript side, and gives you full support over the binding pipeline: conversions, validations (sound familiar?), synchronized access, one- and two-way bindings, bindings from multiple sources and coalescing the values together. It's really cool.

This work in Flex has been a golden opportunity to make a fresh start and use the lessons learned from Eclipse DataBinding. Pending company approval I hope to port all that goodness back to Java sometime soon. Stay tuned.

Disclaimer: Opinions are my own and do not reflect or represent my employer.

July 18, 2010

Archived

I've archived the 431 posts from this blog. If you're interested in a specific post, don't hesitate to contact me and I'll pull a copy out of storage for you.

June 25, 2010

Eclipse 3.6/Helios key-bindings changes?

We have had several Subclipse users point out that their key-bindings for Subclipse commands are not working in Helios. Does anyone have any ideas/pointers they can give as to what has changed that would make this feature stop working?

Key-bindings are working for the core Eclipse plugins, so it is not like the entire feature is broken, it just seems that something has changed. Usually Eclipse release are very good at backwards compatibility. We still are able to provide a single version of Subclipse that works on Eclipse 3.2 and higher. I would hate to have to provide a specific version for Eclipse 3.6 if we can avoid it. We still get lots of downloads for our Eclipse 3.0 version!

[Update] - It looks like a user figured out a cure for the problem. Now we have to figure out what to change in Subclipse to do this automatically.

May 13, 2010

Beauty of the Maven POM editor

It is great to see that people still like Maven POM editor I designed few years ago for Maven integration for Eclipse. The editor allows simple XML editing with number of code completions and template support, as well as structured form-based view of the entire Maven POM model. It also includes several tools, such as Dependency Hierarchy and Dependency Graph views for the current project.

Not many people know that POM editor can be used with pom.xml files outside of Eclipse workspace, including files opened from CVS or SVN Repositories, History view or Maven Repositories view. So, you can see a form-based representation of the project dependencies, as well as explore dependency hierarchy for projects without importing them into Eclipse workspace.

Unfortunately there is several regressions since Sonatype took over the project. For example you can't see form-based representation of an effective POM and editor pages had been shuffled in an odd order, but most of the features still there.

I believe that POM editor is playing a key role in Maven integration for Eclipse and it opens huge number of possibilities to help developer to do various common tasks, from analyzing project dependencies from artifact down to the class level, down to collaboration within project team. That is why I created extension points to allow 3rd party integrations. For example, you can add a custom POM editor page/tag using org.maven.ide.eclipse.editor.pageFactories extension point. Custom menus can be also added in various places using standard Eclipse's object contribution mechanism. So, it is now up to you to extend it.

March 23, 2010

Eclipse plug-in sightseeing: Ribbon IDE

The problem how to help user to only see what he need been attacked by several researches. Few weeks ago we saw a neat Code Bubbles project and older attempt landed as a well known Eclipse project, which unfortunately abandoned a great idea for other not so cool things...

However Elias Volanakis did a great job in changing the look of the modern IDE. His Ribbon IDE project looks really promising and best of all you can even try it today. The following video should give you idea what it is all about.

July 23, 2009

Hey Motorola HQ-Andoid Guys

Ahem Motorola HQ-Android guys, the blog has moved to:

 http://mobilebytes.wordpress.com

 You will find coverage of the AndCooper Android Dev tool there.

June 23, 2009

Subclipse and Eclipse 3.5/Galileo

With the Eclipse 3.5 final release now available, I thought it would be good to get a post up for Subversion users that are looking to install this release. Subclipse works great in Eclipse 3.5 and is easy to install. There are two versions of Subclipse available with support for Eclipse 3.5.

Subclipse 1.4.x is based on Subversion 1.5 client API
Subclipse 1.6.x is based on Subversion 1.6 client API

Install the version of Subclipse based on the version of Subversion you want to use. This is mainly an issue if you want to use multiple clients with the same Subversion working copy. If you do all of your work from Eclipse, then just grab the latest version. All Subversion 1.x clients can work with all Subversion 1.x servers. So, if possible, just use the latest version.

OSX and Linux users need to install the right version of the JavaHL library (1.5 or 1.6). Most Linux distros are still providing 1.5.x, but the RPM's from CollabNet include JavaHL and install on every Linux distro that I have tried (including Ubuntu). CollabNet also provides binaries and JavaHL for OSX.

I maintain a wiki on the Subclipse site with detailed information about getting JavaHL working on your system.

In other news, Subclipse 1.6.x now includes the CollabNet Merge client. This was developed as part of the merge tracking feature in Subversion 1.5 and makes merging from Eclipse very easy to do and manage. The CollabNet Merge client is part of the CollabNet Desktop - Eclipse Edition, which includes Mylyn and connectors for CollabNet's trackers. The merge client is now also available directly for Subclipse users with no other dependencies. Users that want the full merge client, which adds the change set merge option, can install the CollabNet Desktop.

June 10, 2009

New Resources at AndMob

Some new resources at AndMob have popped up including code examples, both links to Eclipse and Netbeans plugins and etc. You can find the link to AndMob on the right side of where this blog moved to, namely Mobilebytes. Also do not forget AndroidSnippets and Stackoverflow even has an Andorid area of questions and answers. Recent AndroidSnippets additions are featured on AndMob. You can reach Stackoverflow from my MobileBytes right menu and do an andoird word search in the search box to find the Android development questisn and answers.

June 07, 2009

I'm moving to Wordpress

In the last few days I moved this blog to wordpress and you can reach the content through http://tomsondev.bestsolution.at/

May 24, 2009

Useing Qt to write Equinox-OSGi-UI-Applications

I saw I didn't blogged since about 2 months. So I thought I'll start a series of blog entries showing off new things and paths I'm exploring.

I'll start with a Technical Topic because it's a really exciting thing I guess not only for me but also for the whole Equinox-OSGi/Java-Community.

Since some time Qt is released under LGPL and since some weeks now their Java-Binding named Qt-Jambi is released too under LGPL. I've been playing with Qt-Jambi (because my UFaceKit project has a Qt-Port) before but now that the code is under LGPL it's getting more interesting to the wider Java-audience and naturally also people who use Equinox-OSGi for their applications.

A simple QtJambi-Application


Before digging into the details what I've done let's look at a simply QtJambi-Application if we are not using Equinox-OSGi.


package at.bestsolution.qt;

import com.trolltech.qt.gui.QApplication;
import com.trolltech.qt.gui.QGridLayout;
import com.trolltech.qt.gui.QLabel;
import com.trolltech.qt.gui.QLineEdit;
import com.trolltech.qt.gui.QMainWindow;
import com.trolltech.qt.gui.QWidget;

public class HelloWorld extends QMainWindow {

public HelloWorld() {
setWindowTitle("Hello World!");

QWidget composite = new QWidget();

QGridLayout layout = new QGridLayout();
composite.setLayout(layout);

QLabel label = new QLabel();
label.setText("Label");
layout.addWidget(label,0,0);

QLineEdit text = new QLineEdit();
layout.addWidget(text,0,1);

setCentralWidget(composite);
}

public static void main(String[] args) {
QApplication.initialize(new String[0]);

HelloWorld world = new HelloWorld();
world.show();

QApplication.exec();
}
}

This looks not much different to a SWT-Application besides the fact that one doesn't has to pass a parent when creating a widget and instead of running the event loop one simply calls QApplication.exec().

QtJambi and Equinox-OSGi


Couldn't be hard you think when you've used other UI-Toolkits (SWT,Swing) in your Equinox-OSGi-Applications already but the problem is that Swing is not problematic because it is part of the JRE and SWT is shipped as an (in fact multiple) Equinox-OSGi-Bundle/Fragment.

What we need to do is to Equinox-OSGify the bundles coming from Qt but this task is more complex then it looks on the first sight because using the simple converter provided by PDE is not providing us a solution because QtJambi-Code expects to load the libraries in very special way which means we need to patch their Java-Code to make it aware of Equinox-OSGi.

The really cool thing is that patching and maintaining the patch is easier than one might think because they provide their sources through a git-repo one could simply clone and maintain the patched sources. So maintaining the patch is easier than it is for example to maintain a patch for the eclipse-platform because of git.

The tough thing is to get the environment setup in a way than one can produce .jars from the sources because one

  • Has to compile the Qt-Sources

  • To generate the Java-Binding-Classes to the Qt-Sources (extracted from the C++-Header-Files)


which is a bit time consuming and not documented very well at the moment. Though this is doable for a medium skilled Java-Dev I think one should be able to checkout the complete project with native and generated Java-Code and doesn't have to compile all the stuff.

After having managed to setup a build environment I patched the libary loading classes and recreated the .jar-packages. QtJambi is split in 2 .jars:

  • qtjambi.jar: Hold platform independent Java-Classes

  • qtjambi-${os}.jar: Holding native libraries for the platform and the JNI-Glue


So the setup is similar to SWT but in SWT also the Java-Code is part of the native fragment because it differs from platform to platform and the host bundle is simply an empty bundle. In contrast to that in Qt the Host-Bundle is holding all Java-Classes and in the native fragments one has the native-libs and JNI-Glue.

So what this all means for you? Not too much because I did 2 things as part of UFaceKit-Target-Setup:

  • Packaged my changes to the Java-Code and provide it for download

  • Added ant-tasks who fetch the native libs from Qt-Software and repackage them



One could also use these ant-tasks when not using UFaceKit (I'm using it for my RCP-Development-Setup).

The Equinox-OSGi-Support is not fully finished and I'll maybe rework it a bit in future when understanding the code better but for now it sufficient to go on and file a CQ to make use of Qt in UFaceKit. Let's see what's coming out from this now that Qt is LGPL.

Simple Qt-Jambi and Equinox-OSGi-Application


Let's create an Equinox-Application which uses Qt as UI-Toolkit now. The easiest thing is to use the PDE-Wizard to create a "Headless Hello RCP" and add a MainWindow.java.
package at.bestsolution.qt;

import java.io.BufferedReader;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;

import com.trolltech.qt.gui.QApplication;
import com.trolltech.qt.gui.QGridLayout;
import com.trolltech.qt.gui.QLabel;
import com.trolltech.qt.gui.QLineEdit;
import com.trolltech.qt.gui.QMainWindow;
import com.trolltech.qt.gui.QPixmap;
import com.trolltech.qt.gui.QPushButton;
import com.trolltech.qt.gui.QWidget;

public class MainWindow extends QMainWindow {

public MainWindow() {
QWidget widget = new QWidget();
widget.setObjectName("main_window");

QGridLayout layout = new QGridLayout();
layout.setMargin(0);
widget.setLayout(layout);

addHeader(layout,"Tom Schindl","at/bestsolution/qt/bookmarks.png");

QWidget content = new QWidget();
QGridLayout contentLayout = new QGridLayout();
content.setLayout(contentLayout);

addLine(0, contentLayout, "Firstname");
addLine(1, contentLayout, "Lastname");
addLine(2, contentLayout, "Age");

QPushButton button = new QPushButton();
button.setObjectName("submit");
button.setText("Submit");
contentLayout.addWidget(button,3,1);

layout.addWidget(content);

setCentralWidget(widget);
}

private void addHeader(QGridLayout layout, String labelText, String icon) {
QLabel header = new QLabel();
layout.addWidget(header);
header.setObjectName("header");
QGridLayout headerLayout = new QGridLayout();
headerLayout.setMargin(0);
header.setLayout(headerLayout);

QLabel headerIcon = new QLabel();
headerIcon.setObjectName("header_icon");
headerIcon.setPixmap(loadImage(icon));

headerLayout.addWidget(headerIcon);

QLabel headerText = new QLabel();
headerLayout.addWidget(headerText,0,1);
headerLayout.setColumnStretch(1, 100);
headerText.setObjectName("header_text");
headerText.setText(labelText);
}

private void addLine(int line, QGridLayout contentLayout, String labelText) {
QLabel label = new QLabel();
label.setText(labelText);
label.setObjectName("label");
contentLayout.addWidget(label);

QLineEdit text = new QLineEdit();
text.setObjectName("text");
contentLayout.addWidget(text,line,1);
}


private QPixmap loadImage(String path) {
try {
InputStream in = getClass().getClassLoader().getResourceAsStream(path);
ByteArrayOutputStream out = new ByteArrayOutputStream();

int l;
byte[] buffer = new byte[1024];

while ((l = in.read(buffer)) != -1) {
out.write(buffer, 0, l);
}

QPixmap pic = new QPixmap();
pic.loadFromData(out.toByteArray());
return pic;
} catch (Exception e) {
e.printStackTrace();
}

return null;
}
}

and modify the generated application class like this:
package at.bestsolution.qt;

import org.eclipse.equinox.app.IApplication;
import org.eclipse.equinox.app.IApplicationContext;

import com.trolltech.qt.gui.QApplication;

public class Application implements IApplication {
public Object start(IApplicationContext context) throws Exception {
QApplication.initialize(new String[0]);

MainWindow window = new MainWindow();
window.show();

QApplication.exec();

return IApplication.EXIT_OK;
}

public void stop() {}
}

Well as you see I'm not a good designer and the application looks well not really nice though it looks native on my OS-X though this is only faked by Qt because they are drawing everything on the screen as far as I understood it.

One could think that this fact is a draw back of Qt but IMHO it's the other way round because with this strategy they can support things SWT can't support easily - Completely restyle your application using a declarative language and well they use CSS like e.g. E4 does too.

The first thing to do is to add a method to load a stylesheet to Application.java:
private String loadStyles(String cssPath) {
InputStream in = getClass().getClassLoader().getResourceAsStream(cssPath);
BufferedReader r = new BufferedReader(new InputStreamReader(in));
StringBuilder s = new StringBuilder();
String line;

try {
while( (line = r.readLine()) != null ) {
s.append(line);
}
} catch (IOException e) {
e.printStackTrace();
}

return s.toString();
}

and set the style sheet on the main window:
public Object start(IApplicationContext context) throws Exception {
QApplication.initialize(new String[0]);

MainWindow window = new MainWindow();
window.setStyleSheet(loadStyles("at/bestsolution/qt/style.css"));
window.show();

QApplication.exec();

return IApplication.EXIT_OK;
}
and we need to define some styles:

resulting in this application:


which we all agree looks better than:



As you see this is also not my design but then one you get when using the Eclipse-Forms-API with the difference that in Eclipse one has to learn a new API to deal with besides SWT whereas in Qt the UI-Code is still Qt and styled by a declarative syntax and if you ask me the Forms-API is going to replace in space of Eclipse in E4 through SWT + CSS but this is only my personal opinion.

So should we all now move to Qt-Jambi to write UI-Applications in Java like we did years ago when we abandoned Swing and started using SWT?

Let's look at some potentially problematic areas:

  • Qt and QtJambi misses an application framework like eclipse RCP provides one for SWT-Application developers

  • Qt and QtJambi misses Databinding support like Eclipse-Databinding provides one for SWT, JavaBeans and EMF

  • Nokia removed all resources from QtJambi development and wants to build a community to work on it


For at least 2 of the above there are solutions already today:

  • E4's core application platform is UI-Toolkit agonstic so though E4 is not released until 1.5 years it would give people the possibility to use Qt as their UI-Toolkit of choice which supports many many things starting from animations, multimedia integration, ...

  • UFaceKit provides JFace-Viewer like and Eclipse-Databinding support for QtJambi if the CQ I'm going to file is approved


Still the killer problem is the lacking support from Nokia on QtJambi and it's unclear if a community could be build around it who not even maintains but also adds new features.

I think this is a bitty because with getting a real application framework with E4, it's themeing, multimedia and animation support I think QtJambi could get a real possibility to write cross-platform RCP-Applications in Java without the sometimes really hurting lowest common denominator problem we have in SWT.

So what should one do? Though QtJambi looks like a real solution for writing nice looking RCP-Applications the uncertainness caused by Nokia by cutting resources makes it unusable for most companies.

For form developers I could point you once more to UFaceKit which supports both SWT and Qt and your form application code is not affected by changing the underlying technology but one can still rely on native stuff where needed (e.g. using Qt animation/multimedia support).

For me as one of E4 committers and UFaceKit-Project lead it means:

  • I'd try to keep the application runtime widget agonstic if possible (well we are on a good track here)

  • I'll file a CQ to let UFaceKit make use of QtJambi and provide first class JFace-Viewer and Eclipse-Databinding support for QtJambi


  • 1. updated my wrong capitalization of Qt
    2. please note that I'm using Equinox specific stuff to make this work so it is maybe not runnable on other OSGi implementations but I'm happy to incooperate feedback and suggestions into my git-clone to support other OSGi implementations

March 02, 2009

Give your E4-Application a modern Look&Feel

EclipseCon is coming in about 3 weeks and I started preparing the stuff for my talks about E4 and UFaceKit.

In E4 we are trying to address some of the main pain points RCP-Application developers faced - Their application looks like Eclipse and the theming/presentation API is not flexible enough to modify all aspects of the UI (e.g. Toolbar/MenuBar, ...)!

The first step to make your application look different was that we introduced the concept of declarative styleing (CSS).

Let's take the demo E4-Photo-Demo-application as example.
This is the application without CSS:

This is the application with CSS:

But like in other aspects E4 goes further and allows you to exchange complete widgets like the application-shell, the menu and toolbar, the Stack-Folders (the standard theme uses CTabFolder) resulting in an E4-Demo-Application like this:

You want to know more about how this works and how the internals of the workbench make such things possible? Then I'd suggest to you attend the EcliseCon-talk about the modeled workbench Boris and I are delivering at EclipseCon09

But E4 goes even further! It allows you to plugin every widget-technology you want to! The internals don't care whether your application gets renderered by QT, Swing, UFaceKit you name it. So I've done that and here's my UFaceKit-Demo-Application built on top of E4:
Makeing UFaceKit a possible renderer of E4 opens the doors to all technologies supported by UFaceKit (Swing, QT, GWT, ...) and its advanced DeclartiveStyling-Support

February 27, 2009

News on UFaceKit

IP-Review passed

This is a great day in the short life of UFaceKit. We passed the initial IP-Review for our code base and I thank all the IP-Team for the great assistance and help to make our code base IP-clean.

Abstraction of Application-Bootstrapping

Until today the start up process of an application has been Toolkit specific (e.g. spinning the event-loop) this is now abstracted in a new interface called UIDesktop which can be compared to the mixture of SWT-Display and the Eclipse-Workbench.

This abstraction means that switching from SWT to QT means switching exactly one factory and that's it. This new UIDesktop concept is also a result of discussing a potential OpenGL-Implementation of the UFaceKit-API with one of our employees.

public void startup(UIFactory factory) {
UIDesktop desktop = factory.newDesktop();

desktop.runWithDefaultRealm(new UIRunnable() {

@Override
protected IStatus run(UIDesktop element) {
createUI(element,uiMethod);
return Status.OK_STATUS;
}
});

desktop.run();
}

// Creating application with SWT
startup(new JFaceFactory());

// Creating application with QT
startup(new QTFactory());

A first real world application

One of our employees is rewritting our one of our applications using UFaceKit and is making good progress. Writing a real world applications helps us to fill the last missing gaps in API. Maybe I can already show an intial version of the application on EclipseCon 09 then people can see a real world application using UFaceKit + EMF + CDO in my talks:By the way I'm nominated for 2 Eclipse-Awards

January 17, 2009

Getting started with UFaceKit and QT

QT and UFaceKit

So the big news this week in opensource space was the announcement of Nokia to release their C++ cross-platform widget toolkit under LGPL. This is great and people now once more start to request a SWT-Port for QT. I don't know if any company is going to invest the development resources into such a port at least I haven't heard anything.

From UFaceKit point of view the announcement is great because we've been working since some time on an UFaceKit-Implementation for QT. Today I invested some time to implement features to render the AddressBook-Application i showed you in my last blog entry

Below is the application rendered using the CleanlooksStyle on MacOSX:



The only change to the code I showed you last week is how the application is launched.
For SWT the launcher looks like this:
public class Launcher {
public static void main(String[] args) {
final Display display = new Display();

Realm.runWithDefault(SWTObservables.getRealm(display), new Runnable() {
public void run() {
JFaceFactory factory = new JFaceFactory();
Workbench workbench = new Workbench(factory);
workbench.open();

while( ! workbench.isDisposed() ) {
if( ! display.readAndDispatch() ) {
display.sleep();
}
}
}
});
}
}

And for QT:
public class Launcher {
public static void main(String[] args) {
QApplication.initialize(new String[0]);
QApplication.setStyle(new QCleanlooksStyle());

Realm.runWithDefault(QTObservables.getRealm(), new Runnable() {
public void run() {
QTFactory factory = new QTFactory();
Workbench workbench = new Workbench(factory);
workbench.open();
QApplication.exec();
}
});
}
}


And now with styles applied the whole application looks like this:



I'm still in the process to make myself familiar with the QT-API and how I'm supposed to use and implement certain functions. Even if you don't want to use our UFaceKit-API the work we are doing here is interesting to you probably because we provide for example QTObservables for use with Eclipse-Databinding and a Combo/List/Table/Tree-Viewer implementation for QT-Controls.

UFaceKit Dokuware

I was asked to provide instructions how to get the applications I show in my blog running the locally and play with them. I've opened a new section in the Eclipse-Wiki holding all informations about our project - outlining our goals, instructions how to get the current code base running, and hopefully much more information soon.

January 14, 2009

Pimp your application L&F with UFaceKit

Does your application look like this or hopefully a bit better than this really ugly example?

Making applications look nice and still not cluttering your code with these theming informations is something not provided out of the box by Eclipse. Still the situation is changing since the E4-Team is working on "native" SWT-CSS integration (Kevin McGuire and Kai Tödter) - if I'm not mistaken the code should in theory also work in 3.x.

But besides E4 there's another project called UFaceKit which provides a high-level widget-toolkit API (the application above is written with UFaceKit in about ~250 Lines of code) and part of this high-level abstraction is direct support for Declarative-Styleing.

Let's at first take a look at the above application. I've split it into 3 Classes:

When coding with UFaceKit and you choose to use the SWT-Implementation (we also provide Swing and QT though SWT is the most stable and feature rich) you get the native platform L&F (as you see above) but the application is not really visually appealing.

If you don't have support for declarative styling you'd now have to clutter your code with themeing informations (e.g. setting background-colors, ...) and your code is soon getting unmaintainable. The Web-Guys already found this out for a while and invented CascadingStyleSheets (CSS). So why not learning from them and bring CSS (I more like the term Declarative-Styleing) to the world of Java-Desktops.

As mentionned before the E4-Team is working on CSS support and so does UFaceKit but this is not the only thing. UFaceKit abstracts styling support and you can plug-in your own declarative syntax. Out of the box we support:

  • CSS: Like you know it from Web-Development. We currently don't support all features from CSS2 but only the most important ones

  • USML: UFaceKitStylingMarkupLanguage is a very simply XML-Definition for css-like styles which has the adavantage that it doesn't add any dependencies like CSS-Support does


As state we don't suppport all features CSS2 defines but a subset of the most important things:

  • ID-Definitions like #myelement { }

  • Class-Definitions like .mylabel { }

  • Element-Definitions like UILabel { }

  • Support for pseudo-Attributes like :hover, :focus

  • Support for attribute-selectors like .mylabel[@value >= 10]


Let's see what we can achieve by adding this styling support our application.


Amazing isn't it? No single line of application code has changed between those screenshots! As you might noticed I've used Kai Tödters E4-Example application as master and the data is backed up in XMI useing the EMF-Toolchain.

What can you expect in future from UFaceKit:

  • Working on better support for Swing (many Styling things are missing)

  • Working on better support for QT (some styling and control things are missing)

  • Finishing implementation of current API functions

  • Adding JUnit-Test, ...

  • Declarative Syntax to describe and visual design your UI using EMF

  • ...


As you see there's much work that needs to be done and if you are interested in helping out you are more than welcome.

January 08, 2009

Where do you go (JFace)Viewers

The presence


Today I thought about a problem of JFace-Viewers when it comes to clever memory management like it is provided for example by CDO. CDO has a very clever memory management concept where objects are swapped out of the memory if they are not referenced in application code.

When using CDO in conjunction with JFace-Viewers this concept doesn't work because JFace-Viewers restore the model element into the TableItem/TreeItem-data-slot and so CDOs clever memory management is not working and the whole model resides in memory.

Inspired by Ed's efforts to minimize the memory footprint of EObject (see bug 252501), I started to think how we could improve on the other side of the fence. I've started today implementing a set of specialized viewer classes which makes it possible for you to take advantage of the clever memory management supplied for example by CDO.

The idea is simple. Instead of restoring the real object in the viewer the object gets translated into a key value (in case of CDO it could the a CDOID) and so CDO can free memory ASAP. The code is available from the UFaceKit-Repository because the scope of UFaceKit is also to provide higherlevel utilities for current Eclipse-Technologies beside inventing it's own high-level API.

The future


The Viewer-Concept provided by JFace for StructuredControls (Combo, List, Table, Tree, TreeTable) is one of the most used concept in Eclipse-Applications and although they are very powerful and we fixed many deficiencies we could provide much better useablility and user experience in E4.

Some of them coming to my mind are:

  • No Toolkit-Independence we can only target SWT like controls

  • Usage of Java5 generics

  • Multiple different APIs to achieve solve a problem

  • Problem with memory intensive models

  • (Fill in your favorite problem)



If you are a regular reader of my blog you know that in my UFaceKit-Project I've already written a JFace-Viewer like implementation for other widget toolkits (QT, Swing). I've today restarted think whether this would be a good thing for E4 in general and so I filed bug 260451.

I'd like to see Eclipse-Viewer getting a project like Eclipse-Databinding which is split into a general and toolkit specific part and integrate itself seamless into the concepts provided by Eclipse-Databinding. I'd invite all of you to take part in a renewed implementation of the viewer concept by adding yourself to bug 260451 and take part in the design discussion hopefully takeing place there.

The intial list of points I'd mentionned in the bug are:

  • Cross-Toolkit like Eclipse-Databinding I'd like to see Viewers getting split
    a Toolkit-Neutral and Toolkit-Specific API so that implementation for e.g.
    Swing, QT, ... can be created.

  • Better support for big model graphs (e.g. better support for CDO) (see bug
    260422
    )

  • Revised inline editing

  • Direct-Databinding support

  • Builtin support Async-Programming (see bug 253777)

  • Support for Java5-Generics

  • Builtin databinding support (e.g. a Viewer could direclty implement the
    IObservableValue interface)

November 21, 2008

Back from ESE

I'm back in reality and just recap what happened the last 4 days.

My talks

Let me first recap my talks. I think all in all they went quite well though there are always things to improve (it was my first time doing a talk my own)

E4 - Modeling the workbench

I think I never talked to so many people ever before because I did my presentation in the biggest room available.I think I got the message around what the E4 project is about and in particular what the subtask-team I'm in is doing. The first reviews tell me that I didn't fail but I look forward for more comments.After my talk many people showed up personally. From what I can tell they agree with us about heading in the right direction. I think I even got the message about the joy, passion and openess the current E4-team is working together around that good that people think about joining us and bring in their own vision about the future of the Eclipse Platform. Hope to see you soon showing up at the E4-Mailing list.

Datacentric RCP with EMF and Databinding

I did the presentation in the 2nd biggest room and there even haven't been enough chairs for all people who wanted to attend my talk so they had to stand in the back. Woohoo.

I felt more comfortable speaking without a microphone and I think I showed people when mixing the right Eclipse technologies it's possible to write Enterprise ready Database frontends.

I admit my presentation was a bit focused about UI (Key-Binding, UI-Contexts, Commands) and not so how to access data. The only review I found until now is a short sentence in Ed Merks blog where people told him that the talk was "really good". So looking forward for more comments. I think the small application I presented there is what many people requested on the "E4-symposia" when they asked about a best practice example.

I even thought about restarting on an accompanying book about all the stuff one can find in the example and technologies but dismissed this thought immediately because I simply don't have the time and financial grounding to spend my time on it. The time (=money) my small company is investing in Eclipse is big enough already.

Conclusion

I would appreciate to get more comments about my presentation and ask myself why the same we had one EclipseCon was done where people got small pieces of paper to give back comments.

I think the intention was that people use gPublication to do so but it looks like people don't know about this. So if you want to give feedback and get access to the slides please do so at:

  • E4-Modeling the workbench: here

  • Datacentric RCP: here

but I'm afraid not all people attending my talks are really following my blog or the Planet so the feedback is going to be less than it was on EclipseCon.

If you and your company need help to get started with Eclipse RCP and other Eclipse technologies like OSGi, the modeling stack like (EMF, Teneo, CDO) my company is offering consultancy and development resources to anyone interested.

The E4 symposia

The symposia once more was I think a well received offer of Eclipse Summit Europe to the community and we talked about a lot different things in the E4 space. Boris Bokowski summarized the symposia in here.

For me as someone taking part in E4 project it is important to get feedback from the community to integrate their wishes (if my time permits) in the code base.

Socializing

I got to know my new people and we had a lot of interesting chats about new ideas (e.g. declarative ui) so it's hard to get back to reality and working on all those boring stuff.

November 04, 2008

Rotating Image in a PaintListener

For those who have a better understanding of matrices and 2-D graphics this may sound strange but today I struggeled about 2 hours rotating an image in a PaintListener.

Let me first of explain the exercise I had to solve, then show you my solution and then maybe someone can point out a better one.

Exercise

Draw an Image at Point(50,50) in a Canvas which is rotated a variable angle.

The solution

Solveing this problem one can use a SWT-Transform to adjust the Graphics-Context looks straight forward but it took me like said 2 hours to wrap my head around the problem. The following function is the solution I came up with.

public void paintControl(PaintEvent e) {
GC gc = e.gc;
gc.setAdvanced(true);

Bounds b = image.getBounds();

Transform transform = new Transform(display);
// The rotation point is the center of the image
transform.translate(50 + b.width/2, 50 + b.height/2);
// Rotate
transform.rotate(45);
// Back to the orginal coordinate system
transform.translate(-50 - b.width/2, -50 - b.height/2);
gc.setTransform(transform);
gc.drawImage(image, 50, 50);
transform.dispose();
}

Is the solution right? Is there a better solution?

My skills are very very bad when it comes to matrices and 2-D graphics so the above solution to the problem might be completely wrong and only works by chance.

October 27, 2008

News about UFacekit

There are some important news I'd like to share with all of you:

1. UFacekit Proposal


The proposal is out and we hope some of you are interested in the targets and ideas we follow with UFacekit. If you are please leave a note on the newly created newsgroup. Share your wishes, critism with us so that we can make UFacekit a success.

2. QT-Port


Just a few minutes ago I checked in a first running version of a QT-Port of the UFacekit-API. Besides providing this API we naturally provide bundles you can consume standalone (e.g. to only use a JFace-Viewer-API in QT-Jambi-Projects, ...).

So we now have:

  • Support for SWT/JFace

  • Support for Swing

  • Support for QT (Cleanlooks Style)


Platforms I'd like to see a port in future:

  • GWT - is going to be revived soon by one of the team-members

    • GXT

    • Other UI-Toolkits based upon GWT



  • Eclipse-Forms - Should be fairly easy to do

  • Android - The first test suggest it is possible though we need to see if all widget types are available. Maybe we can only provide some viewer and UI-Observables but not a full fledged UFace-API


Platforms I dream of a port in future:

  • Draw2d

  • OpenGL

October 24, 2008

There's no place where Eclipse-Databinding doesn't work

Tonight I thought I'll give Android a spin, I download the sources and worked through some samples. After an hour this got boring and because I already managed to get Eclipse-Databinding working in other Environments (GWT, Swing, QT) I thought now it is time to see if I can manage to get a minimal example working on Android.
Here's the application:



The model code looks like this (I'm using UBeans here because they are completely self contained and have no dependencies)

private static class Person extends UBean {
public static final int NAME = 1;

public String getName() {
return (String) get(NAME);
}

public void setName(String name) {
set(NAME, name);
}

@Override
public Object getValueType(int featureId) {
return String.class;
}

};

The UI-Code looks like this (fairly straight forward UI-Code):

TextView view = new TextView(this);
view.setText("Name: ");
TableLayout layout = new TableLayout(this);
layout.addView(view);

EditText text = new EditText(this);
layout.addView(text);

Button button = new Button(this);
button.setText("Say Hello");
button.setOnClickListener(new OnClickListener() {

public void onClick(View v) {
Dialog dialog = new Dialog(Test.this);
dialog.setTitle("Hello " + p.getName() + "!");
dialog.show();
}

});
layout.addView(button);

And now the important thing how do we connect UI and Model-Attributes? Right we use Eclipse-Databinding (well not the one you get from Eclipse directly because it doesn't compile out of the box but patching it took about 30 minutes :-).

IObservableValue mObs = UBeansObservables.observeValue(realm, p, Person.NAME);
IObservableValue uiObs = AndroidObservables.observeText(realm, text);
DataBindingContext ctx = new DataBindingContext(realm);
ctx.bindValue(uiObs, mObs, null, null);

Cool isn't it? Would a Eclipse-Databinding port for Android help you? Then take a look at the newly proposed Eclipse-Project UFacekit. We already provide Viewer and UI-Observable implementations for different Platforms (SWT,Swing,QT) and plan to provide one for other platforms (GWT, Eclipse-Forms, ... you name it). Why should we not provide them for Android-Widgets too?

October 20, 2008

Update on UFacekit

UFacekit has a new source structure


We have restructured the repository to clearly separate our modules into:

  • proper:

    This holds stable and actively maintained modules - currently Swing and SWT implementations. Checking them out and compiling works always else it's a bug and someone is to blame.

  • incubation:

    This holds newly and not yet stable modules - currently our new brand new QT support is in there. Checking them out and compiling works most of the times it's not a bug!

  • dormant:

    This holds old modules currently not actively maintained and don't even compile. Sad enough our GWT ports are currently located there. Hopefully we are good to push them forwards once more in the next months. You are a GWT guru and want to help making the GWT port as stable as possible? Come and join us.


The layout is taken from the Apache-Jakrata project.

UFacekit has an QT-Port


I started 2 or 3 weeks ago a port which uses QT-Jambi to bind against QT-Widgets. There's no ufacekit API available but Viewer implementation and observables for some widgets are already available. I hope I can finish this work as soon as possible. Might be interesting what happens when we are moving the sources to Eclipse.

UFacekit has a build story


Having a stable build story is one of the most important things for OpenSource-Projects. Kenneth did amazing work on making UFacekit managed and build with maven. The repository now doesn't hold any IDE-specific settings any more everything is done by maven.
We are not using PDE-build or any Eclipse-specific things because this would interfere with an important UFacekit-target:
"improve adoption of Eclipse Core technologies (like Eclipse-Databinding) outside RCP and SWT (e.g. Swing, GWT, QT)". Having a build story relying on Eclipse would be a bad thing.

The process e.g. for the proper-modules is like this:

svn co http://uface.googlecode.com/svn/trunk/proper/
cd proper
cd org.ufacekit
mvn clean install
mvn eclipse:eclipse

Afterwards fire up eclipse and import the modules. Done. Kenneth you are my king.

October 08, 2008

Disable parts SWT-Table/Tree with SWT.CHECK

This is a hack, a hack, a hack posting.

I have read many many entries on the newsgroups asking a question like this:

How can I disable certain check boxes in an SWT-Tree/Table. Is this possible?

The standard answer to this was: "Sorry no this is not possible". Today I faced the same problem (mine had to do with ViewerObservables#observeCheckElements()) where the user is not allowed to check the Top-Level-Nodes.

The tree looks like this:

+ Application 1
+ Privilege A
+ Privileg A1
+ Privilege B
+ Privileg B2
+ Application 1
+ Privileg C


The values bound are the ones in Privileg* so I have to lock the Application-checkboxes

The setup is something like this:

Databinding ctx = ....
IObservableSet mObs = ....

Tree tree = new Tree(parent,SWT.BORDER|SWT.V_SCROLL|SWT.H_SCROLL);
CheckBoxTreeViewer v = new CheckBoxTreeViewer(tree);
IObservableSet uiOs = ViewerObservables.observeCheckedElements(v,IPrivileges.class);
ctx.bindSet(uiObs,mObs,null,null);


I nearly gave up but then I had the following idea.


final Tree tree = new Tree(parent,SWT.BORDER|SWT.V_SCROLL|SWT.H_SCROLL);
// Attach a listener directly after the creation
tree.addListener(SWT.Selection,new Listener() {
public void handleEvent(Event event) {
if( event.detail == SWT.CHECK ) {
if( !(event.item.getData() instanceof IPrivileg) ) {
event.detail = SWT.NONE;
event.type = SWT.None;
event.doIt = false;
try {
tree.setRedraw(false);
TreeItem item = (TreeItem)tree.item;
item.setChecked(! item.getChecked() );
} finally {
tree.setRedraw(true);
}
}
}
}
});

CheckBoxTreeViewer v = new CheckBoxTreeViewer(tree);
// ....


This is a hack, I only tested it on Win32 (XP) and don't know how cross platform it is so don't kill me for posting this hack of hacks.

September 22, 2008

JFace-Viewers for Swing, is this possible?

You might think "Now he's gone completely crazy" but hold on and read through the next few paragrpahs to hopefully find out that I'm not.

0. The background


Do you sometimes have to code against Swing and have also been disappointed that you could not remember how to deal with Tables, Trees and TreeTables (I find myself always opening this tedious Swing-Tutorial to find how to do it)?

In last few days I worked on UFacekit's Swing implementation for Tree and TreeTable. JFace-Databinding has added support for Trees and TreeTables in 3.4 and naturally they build upon the JFace-Viewer implementation but naturally JFace-Viewers are bound to SWT and so it is impossible to use this support (or a slighlty one modified) Swing, right?

Well the above is not completely right the main JFace-Viewer-API is fairly free from SWT (besides some Widget, Item stuff) the internals are naturally not. After having noticed this I:

1. Extracted an Widget-Toolkit-Neutral API from JFace


... moved it to a new plugin (org.ufacekit.ui.viewers). I didn't only move the classes and interfaces to a new home I also added support for generics so all this casting is gone and done by the compiler for us.

A content provider now looks like this:

IContentProvider<Person,Collection<Person>> cp =
new IContentProvider<Person,Collection<Person>> {
// ...
}

and a collection can get iterated with a foreach-loop

for( Person p: v.getSelection() ) {
// ...
}

I rearranged some other classes and made interfaces from most of them, ... . So now I have a widget-toolkit-clean Viewer-API.

2. Copied some SWT-Classes (Widget, Table, TableItem, Tree, ...)


... replaced the internals through Swing-counter parts (some of the code is highly ineffecient because e.g. for a Tree we now have 3 Objects (UserObject, TreeItem, DefaultMutableTreeNode) )

3. Commented some JFace-code not needed to provide the minimum JFace-API


... providing a selection, and firing events when the selection changed but I currently e.g. don't need inline Editing so I simply commented all parts of the viewers that deal with this, including Mouse-Handling, ... . The problems from 2. & 3. are hidden from the user because all these are internal classes so I can replace them step by step.

4. Blog how nicely now I can setup a TreeTableViewer for Swing


(in fact SwingX because Swing doesn't has a TreeTable implementation by default - don't ask me why a Toolkit being around for such a long time doesn't has such a standard-control)

So now I don't have to remember how I have to create a TableTree in Swing which loads subnodes lazily because I can simple use the API I already know from JFace for SWT.

@Override
protected Component createUI(JFrame frame, List<Person> model) {
JXTreeTable tree = new JXTreeTable();

TableColumnExt c1 = new TableColumnExt(1);
c1.setHeaderValue("Givenname");
c1.setWidth(200);
tree.getColumnModel().addColumn(c1);

TableColumnExt c2 = new TableColumnExt(1);
c2.setHeaderValue("Surname");
c2.setWidth(200);
tree.getColumnModel().addColumn(c2);

JScrollPane scroll = new JScrollPane(tree);

TreeTableViewer<Person, Collection<Person>> viewer =
new TreeTableViewer<Person, Collection<Person>>(tree);
viewer.addSelectionChangedListener(
new ISelectionChangedListener<Person>() {
public void selectionChanged(SelectionChangedEvent<Person> event) {
for( Person p: event.getSelection() ) {
System.out.println(p);
}
}
});

TreeViewerColumn<Person> c = new TreeViewerColumn<Person>(viewer,c1);
c.setLabelProvider(new LabelConverter<Person>() {
@Override
public String getText(Person element) {
return element.getGivenname();
}
});
c = new TreeViewerColumn<Person>(viewer,c2);
c.setLabelProvider(new LabelConverter<Person>() {
@Override
public String getText(Person element) {
return element.getSurname();
}
});

viewer.setContentProvider(
new ITreeContentProvider<Person,Collection<Person>>() {
public Collection<Person> getChildren(Person parentElement) {
return parentElement.getChildren();
}

public Person getParent(Person element) {
return element.getParent();
}

public boolean hasChildren(Person element) {
return ((Person)element).getChildren().size() > 0;
}

public Collection<Person> getElements(Collection<Person> inputElement) {
return inputElement;
}

public void dispose() {
// TODO Auto-generated method stub
}

public void inputChanged(IViewer<Person, Collection<Person>> viewer,
Collection<Person> oldInput,
Collection<Person> newInput) {
// TODO Auto-generated method stub
}
});
viewer.setInput(model);
return scroll;
}

5. Summary


The internals are quite ugly there is a huge amount of bugs (I'm sure that not all is working smoothly already), missing functionality (e.g. Icon, Color and Font support) but I now have the foundation to add Tree and TreeTable support to the UFacekit-Library. Cleaning up and bugfixing can happen later. Like all other parts of the UFacekit-Project you can consume this swing-jface-bundle standalone because it has no dependency at all (besides the one on org.ufacekit.ui.viewers).

6. So am I now?


  • Completely Crazy

  • Fairly Crazy

  • A bit Crazy

  • Fairly normal if you know me and all the crazy ideas I already had

September 09, 2008

UFacekit - Proposed as a Component under Platform/Incubator

So the news is out [Mailinglist, Newsgroups]. UFacekit is proposed as a Component under Platform/Incubator project (proposal). I think this is the right move for UFacekit to gather momentum towards our first release. If you want to support this move:
  1. Comment on the following newsgroup post from Boris

  2. Add yourself/company as an interested party on the proposal page
I'm currently working on the JavaDoc and for SWT/JFace a build should be available right after we moved the sources to foundations repositories, swiched namespaces, ... .

September 04, 2008

Exploring new technologies part of Ganymede-Release Train

I took myself some time the last days exploring new technologies available with Ganymede 3.4:

  • Eclipse-Databinding and its new features

  • EMF-Databinding (Provisional but working very smoothly)

  • Teneo: Persist your model via hibernate in a SQL-Database

  • CDO: Share your model between different clients and persist it into an SQL-Database (with Revision support)

  • New Extension Points to enhance the Expression Framework

  • Spring & OSGi

  • P2 to install the Products using the P2-Agent

I did this to understand those technologies better because we at my company have to decide which technologies our next generation of products is built on (The current ones are based on selfwritten libs because at that time there was no Eclipse-Databinding, Teneo and CDO or we didn't knew about it).

As always when learning new technologies I created an example application but before I started I defined some goals I think are curcial to all Enterprise Datacentric Desktop Applications:

  • Nice L&F (as good as I can make an UI Look without a designer)

  • Plugable storage technology

  • Undo/Redo Support

Then I started hacking, creating an Ecore-Model, some plugins, extension points, browsing documentation and noticed that there are no examples around for most of the things I wanted use:

  • How to create an EditingDomain myself when not using the generated editor-classes from EMF?

  • How to use the new org.eclipse.ui.services-Extension point to enhance the expression framework?

  • Best strategy to use Extension Points when bundles are installed/uninstalled/updated while the application is running


All those things are not hard if you know how to do it but if you don't it's quite tricky to solve these problems. It even gets harder if the technologies you plan to use are quite new and/or are not used together and because of this bugs arise.

So the immediate output of my work was that 2 bugs [239015, 245183] in Eclipse-Databinding got fixed in 3.4.1.

The longterm output for me is:

  • I now have a good picture how our next technology stack looks like

  • I have an example application (I will add other things in the next weeks) to teach my co-workers the technologies

  • I had a lot of fun (besides struggeling with P2)

The longterm output for you is:

  • You have a small application showing you a lot of different concepts around RCP+EMF+Databinding applications

    • EMF-Ecore

    • Usage/Creation of your own Extension Points

    • Using EditingDomain outside the scope of EMF-Generated artefacts

    • Using Teneo

    • Using CDO

  • I started summerizing all the ideas, technologies and concepts combined in this example in a document, I'm working on from time to time. So maybe some time you'll get a "book" explaining you everything

  • Some nice reusable classes e.g. one to use EMF/Databinding-LabelProviders with cool features, a new drop down widget showing a Tree in the popup, ...


This is the application:


If you want to run it locally get a copy of the P2-Agent and point the metadata repository and artifacts repository to this location.

To use the CDO-Version you also need a server component which can be installed when pointing the agent to this location. After having installed the CDO-Server you also have to create a CDO-Configuration (cdo-server.xml) in the installations "configuration" directory which you can fetch from here.

The repository name in the above config "CDO-1" has to be the id of the CDO-Configuration you create in your application.

Finally if you are interested only in the sources then install a subversion plugin in your eclipse and use one of te Team-ProjectSet files from here to check out the necessary projects.

If you want to learn more about these cool technologies. I've proposed beside a talk about E4 - The new platform-ui concepts a talk about this example application on ESE.

August 25, 2008

Writing a CTreeCombo-Widget

I was working on my example RCP/EMF/Databinding application


I'm going to use to present various parts of those technologies to my co-workers and getting familiar with new technologies like CDO, Teneo, Spring and others when I hit the problem that standard CCombo didn't suited my needs.

What I wanted to have was a CCombo which presents a Tree like structure like this


for my Login-Screen and as you all know there's no such widget available currently. As you might guess from the above Screenshot I somehow managed to get such a widget.

Before we dive into it another requirement I had was that the implementation plugs itself into the existing viewer and databinding concepts of Eclipse.

So what did I do and how did it work? Well 95% of the work I had to do is C&P. I copied the CCombo-Code replaced List against Tree and solved compilation errors. To make a CTreeCombo widget I would have been done almost if this would have been the only requirement.

The real problem is that widgets are reparentable and that this can happen across Shells which makes it necessary to recreate the Tree and its popup shell from time to time so directly attaching a TreeViewer on the underlying Tree-Widget is not possible. So the only possibility was to create Proxy objects around TreeItem/TreeColumn who proxy the real implemementation so that they could be recreated whenever needed.

So if one wants to use the widget he/she has to write code like this:

int style = SWT.BORDER|SWT.READ_ONLY|SWT.FULL_SELECTION;
CTreeCombo combo = new CTreeCombo(shell,style);

CTreeComboItem item = new CTreeComboItem(combo,SWT.NONE);
item.setText("Parent 1");

CTreeComboItem childItem = new CTreeComboItem(item,SWT.NONE);
childItem.setText("Child 1.1");

childItem = new CTreeComboItem(item,SWT.NONE);
childItem.setText("Child 1.2");

item = new CTreeComboItem(combo,SWT.NONE);
item.setText("Parent 2");

childItem = new CTreeComboItem(item,SWT.NONE);
childItem.setText("Child 2.1");

childItem = new CTreeComboItem(item,SWT.NONE);
childItem.setText("Child 2.2");

CTreeCombo now works like an ordinary SWT-Tree providing the same API as SWT-Tree (at least currently the one which is necessary to write a JFace-Viewer) so that I could subclass AbstractTreeViewer and providing an implementation for it. So if one uses JFace-Viewers in his/her code they simply need to write:

int style = SWT.READ_ONLY|SWT.BORDER|SWT.FULL_SELECTION
CTreeCombo combo = new CTreeCombo(parent,style);

CTreeComboViewer viewer = new CTreeComboViewer(combo);
viewer.setLabelProvider(new LabelProviderImpl());
viewer.setContentProvider(new ContentProviderImpl());
viewer.setInput(input);

In the end it took me longer than I first thought but after 4 hours I had a working CTreeComboViewer (although it is not thoroughly tested yet) which behaves appropiately (at least in the way I currently use it).

If you are interested in the code of the widget or in the application to learn about:

  • Writing a modular RCP-Application

  • Using SWT, JFace and Databinding

  • Using EMF and EMF-Databinding

  • Using and creating your own Extension Points

  • Using and extending the Commands, Handlers and the Expression Framework


You can fetch the code from my companies svn-repository but the application is still in flux. If you are only interested in the widget and viewer code you can find it here for the widget and here for the viewer.

June 13, 2008

Ganymede - What's in JFace and Databinding

The History


JFace-Viewers/ToolTips


In 3.3 the whole Viewer-Infrastructur has been reworked to make it easier to add new features in upcoming releases. Some new features where part of 3.3 (e.g. LabelProvider/Column, CellNavigation, Customizable-Editor). Additionally JFace opened up its viewers for subclassers by wrapping Widget-Specific API (ViewerRow/ViewerCell).

Databinding


3.3 saw the first public release of the Eclipse-Databinding-Framework which removes the need for myiards of listeners to keep your model and UI in sync. Anbody who ever had write a Master-Detail-UI knows how hard it is to get it right.

Today


JFace-Viewers


We saw great adoption of our new API and new features added ontop of it. The most significat one is a LabelProvider which understands StyledText-Instructions named StyledCellLabelProvider. You'll see this LabelProvider in action if you open the Java-ProjectExplorer.

On the other hand we also saw great adoption of our API-Opening-Up effort which allows widget vendors to provide a JFace-Viewer-API for their structured widgets. There are 2 Nebula-Components (Nebula-Gallery and Nebula-Grid) who already adopted the concept and provide a viewer.

Thanks for the great feedback and bug reports from the community we fixed some [92] problems and feature request some of them dating back to 2003!

In comparison to Europa-Release we didn't introduced much new API. From my point of the main focus was to evolve the new API we provided in 3.3 and fix problems which have been introduced. If you saw how much code has been rewritten in 3.3 I think this was thr right thing (although we fairly broke no backward code anyways in 3.3).

Databinding


Thanks to the community and Ed Merks and his team there's now a 2nd possibility to back up your UI with a model beside JavaBeans.

Naturally they provide integration for their EMF-Objects with 2 brand new plugins named org.eclipse.emf.databinding and org.eclipse.emf.databinding.edit. Those plugins are marked as provisional but I'm using them since day 1 in my projects and for the standard cases they just work fine and whenever a bug occurs it's fixed immediately. Give it a try and see how fast you can develop powerful SWT-UIs.

At the very moment you bring EMF into your project it opens up the door for fairly everything you and your customers ever dreamed of (take a look at the teneo to presist your model in a SQL-Database using hibernate, working with distributed objects using CDO, validating your model using OCL and much more).

On UI-Side of Databinding also many new features have been added. You have support for Inline-Editing in Table/TreeViewers (every control inheriting from it e.g. GridViewer), there's new support for Observable-TreeViewers and naturally many many bugfixes [75].

The future


JFace-Viewers/ToolTips


Naturally we are going to fix bugs and problems. I have already some bugs in my queue I can address after the Ganymede-Release is out of the doors. Looking at this back log of viewer bugs [228] I'm going to try to bring this bug count down a bit (say 200 is a good number).

Databinding


I see a bright future for databinding and I'll restart my work on bringing all this (databinding+emf) to the web using it in my GWT-Enabled applications inside my UFace-project if time permits.

Summary


I think all people worked on the projects above have done an amazing job. We fixed many bugs added many great new features, many with the help from the community whether they filed sensetational bug reports or even provided patches. A big thank goes out to you, the community.

One more note in the end. In time of 3.4 we saw the creation of a new project called E4. It was discussed controversial in the blog space and on mailling list as you all known.

After EclipseCon I decided as a community member to take part in this effort for the next generation of an UI-Framework provided by the Eclipse Organisation and had a lot of fun until then. If you are interested in learning new things and exploring new areas in space of ui, resource-managment, model-driven development I can only advice you to take part and learn how to organize, design and implement one of the tools that will have infulence on the next generation of thousands of commercial and none-commercial products.

June 05, 2008

E4 is more about bringing it to the web

Since the E4-Presentation at EclipseCon and the SWT-Talk most people think that E4 is only about bringing Eclipse to the web. THAT'S NOT TRUE.

E4 is much more and that SWT gets a web-port is only a small part. Here's my top list of things for E4:

  • Modeldriven:
    One extensible model backing up the whole workbench

  • DOM: At the moment the Workbench is backed up by ONE model you automatically have a DOM and you can do with this DOM the same you do in Web-Applications (See my prototype)

  • New Resource Framework:
    Making handling resources much more Flexible

  • New Listener Concept:
    The current listener concept in eclipse sucks and makes eclipse slower than it could be

  • NO SINGLETONS AND STATIC FIELDS

  • Plugins in NONE-Java: Make it possible to write an Eclipse-Plugin in other languages (JavaScript, ...)

  • Declarative UI, Easier Styling .... and much more

May 20, 2008

A radical approach to explore new paths for e4

After EclipseCon 2008 and the E4 noise I started to rewrite the prototype shown there to use an EMF-Model (I'm going to refer to this prototype in the rest of this posting as PROTOTYPE_1).

It was quite cool to get insights into the platform code and with the code already created for EclipseCon it was not really an achievement to get something running within a fairly short time but finally I wasn't really happy because of multiple things:

  • I had to work around problems from the beginning to get a workbench up and running

  • It was hard to add new features because I was limited to things I could find a work-around for or going to learn the complete platform code which would have driven me mad

  • There was lack of feedback on the real code and we talked more about EMF pros and cons than concentrating on how we want to solve things (I'm still an EMF believer :-)


I asked myself how to solve the following problems:

  • How can I get up an Workbench-Window without any of the legacy code

  • How can I easily add features

  • How can I encourage people to work on E4 without having a deep understanding what's going on inside the current platform. In fact how can I get people outside the Platform-UI-Team to look at the code and understand in an affordable amount of time the concepts behind the workbench and bring up interesting ideas or outline how they think a feature can be implemented
Approximately 1 month ago I sat down and started to define a project which had the following targets:

  • A workbench with dependency on org.eclipse.jface, org.eclipse.equinox.common, org.eclipse.osgi, org.eclipse.emf

  • Built around an extensible EMF-Model

  • NO plugin.xml and NO .exsd (you'll see later how I extend the platform - it's a radical approach I know and looking back it got even more radical then I first thought it's going to be)

  • Similar but slightly improved EMF-Model compared the original one used to straight port the EclipseCon-Example

  • Allow multiple instances of the workbench inside one OSGi-Env - no singletons, no static variables!

  • As few API-Methods as possible (=suppress all the EMF-Methods and adding API-Methods e.g. to attach listeners or traverse the DOM generically) but still strongly typed

  • provide support for Scripting

Step 1: Redesign The Model From PROTOTYPE_1


I started to redesign the original model and removed some things I didn't like or found they are not needed yet. For example styles/styleclasses now work like they do in a Browser:
.myActiveView {
color: #FF0000;
background-color: #0000FF;
}

<span class="myActiveView" >Green on Blue</span>
where the style-properties and the class-properties are merged. I also moved all UI-Data (Font,Color,Gradient,...) from the UI-Element to the "css"-style definition whether an UI-Element reacts on a style property is the choice of the UI-Element and its implementor.

Step 2: Implementing the Workbench-UI-Core From Scratch

With the .ecore-Definition from Step 1 I created a static workbench.xmi file which defines a model of a static workbench.(Yes I started from a static model you'll see how dynamic such a model gets later). The final source code is ~ 88KB and the resulting .jar 36KB (the model, emf-dependencies are not part of this figures of course). But I think the target is reached I think there's no class having more than 500 Lines of Code (including the comments).
Creating .xmi-Files is a fairly trivial task because EMF comes with a generic editor and I guess people who know GMF could have written a graphical one with in a minute (any GMF-volunteers around?). When this step was finished my XMI-File looked like this

Step 3: Making the model dynamic


When starting Step 3 I first headed of and created .exsd-Files (you can see them here) to contribute the information to my model (views/perspectives). But while doing this I recognized that I'm redefining my .ecore-Model-Elements using .exsd so why the hell do I not provide plugin.xmi-artefacts instead of those plugin.xml files and at runtime create a complete workbench.xmi from all those artefacts. The hard part was to reimplement the loading of xmi-File (or rather to identify the source-code where the plugin.xml is processed to copy the logic). This left me with 3 files
  • workbench.xmi in org.eclipse.e4.workbench.ui

  • plugin.xmi in org.eclipse.e4.workbench.ui.ide contributing to workbench.xmi

  • plugin.xmi in org.eclipse.e4.workbench.ui.rhino contributing to plugin.xmi from org.eclipse.e4.workbench.ui.ide

Step 4: Implementing a Scritable-DOM


So now I had a workbench-model constructed at runtime using XMI-Artefacts. Doing some cool UI-Stuff was the next on my list. Wraping up an EObject as an Object-Scritable for Rhino was something I had already written for PROTOTYPE_1 so I "stole" the code from myself. The top feature on my list was to move a View (in 3.3 a ViewPart) in the model and automatically update the UI. So I wrote a view which presented the current workbench model inside a TreeViewer and allowed me to drag a view from stack to stack. It wasn't really is to distinguish a move from a remove but with help from Ed I managed to get it working. See the screen cast at the end of this posting.

Step 5: Persisting the current workbench state


So I was able to drag around the views but everytime I shut down the workbench and restarted model was recreated from the artifacts and started in the initial state. So adding persistance was next the next "big" issue. Well there's nothing more to say than these lines of code:

if (!restore) {
uri = URI.createPlatformPluginURI(
"/org.eclipse.e4.workbench.ui/META-INF/EWorkbench.xmi",true);
} else {
uri = URI.createFileURI(restoreFile);
}

// Save
try {
((EObject)workbench).eResource().save(null);
} catch (IOException e) {
e.printStackTrace();
}

Step 6: Extending the extension


Haven't you ever dreamed of extending an extension. I decided that my WorkbenchStructureViewPart should restore the current selection when coming up from a restored state but my generic model-element I contribute didn't had a slot to restore the information. So I digged into and searched how EMF allows me to extend an existing element (in fact once more Ed pointed me in the right direction). Now the plugin.xmi contributed by org.eclipse.e4.workbench.ui.rhino looks like this.

Step 7: Multiple Instances of the workbench


Not using org.eclipse.ui, no singletons and static variables automatically allows to have multiple workbench instances running. So in theory making this workbench run on top of the RAP framework should be possible without patching any code parts.

Acknowledgement / A Screencast / How to get it run


Before I forget about it two other guys (Boris and Ed) provided ideas, code and input to those freaking lines of code available from Eclipse-CVS using this ProjectSet.

Finally I created a Screencast for you to look at (it's a bit big (15MB) because I have no idea how to do Screencasting with OSS-Software on OS-X).



You'll see that I radically stripped down everything and made some strange decisions (e.g. no plugin.xml), backwards compatibility is not addressed at all, ... . Whether you like the idea of contributing XMI-Artefacts instead of .exsd & plugin.xml is not the question. The interesting thing IMHO is that it takes so few lines of code to show a nice workbench backed up by a model and reacting on (structural-)changes inside of it.

April 02, 2008

Learning BIRT, part 2

(This is the second half of my review for Practical Data Analysis and Reporting with BIRT).


Chapters six through ten cover various ways that reports can be enhanced. Each of these chapters is relatively self-contained, making it easy to refer back for details later when writing reports. Chapter six describes how reports can be parameterized, obviously a necessary capability to promote reuse. In particular the distinction between data set and report parameters in BIRT needs to be understood, and chapter six does a good job in explaining this difference. Also explained are more advanced parameter concepts, such as dynamic, cascading and group parameters. While a number of these parameter concepts are covered quickly, if you are a Java developer as the book assumes, the explanation should be a sufficient overview, and the BIRT documentation can serve to fill in the details.

Report project and libraries are described in chapter seven. By using the Eclipse projects configured for BIRT and report libraries, further reuse is enabled. For example, images that need to be shared across a team of developers creating reports can be stored in libraries, and these libraries are then referenced by each consuming report. As with the previous chapter, Java developers should have no problem understanding these concepts, and the use of specific project types will be very familiar to experienced Eclipse developers as well. Chapter seven also contains a tutorial about reusing resources, and this is useful for checking understanding.


An important aspect of report development is being able to customize rendering. Obviously we’d like to separate rendering instructions from main report data (if possible), so changes in rendering can be made independently. In chapter eight there are examples of several style options BIRT supports: BIRT built-in styles, custom styles, CSS, and style templates. For simple formatting requirements either the built-in style support or slight customizations of it will suffice. Style templates are more useful to apply over a range of reports, probably across groups or departments. Finally, the capability to use CSS allows BIRT users leverage vast resources from that style language. The examples in chapter eight are brief, but detailed enough to suggest the possibilities in each option.


Charts are a common requirement for reports. Luckily, BIRT’s Charting Engine supplies a number of thirteen popular charting options, including scatter, pie, bar and line charts. Further, drill-down (the ability to see more detailed information for a specific chart element) is supported by the Chart Engine. Chapter nine uses the pie, gauge and bar charts in simple, illustrative examples. While table reports are common and useful, you really get to see the power of BIRT as a reporting tool through these chart examples. Well designed charts can convey a lot of information in an attractive form, and drill-down allow you to present additional details without cluttering the initial chart presentation. Perhaps because of the visual appeal of charts, I found the examples in chapter nine more interesting than those in other chapters, and this made me wonder if incorporation of charts throughout the book might have been a good strategy.


BIRT includes scripting support using Java and JavaScript. Chapter ten discusses these capabilities, interestingly starting with a comment that knowledge of Java is useful for understanding the scripting examples. Yet the assumptions stated at the beginning of the book include being a Java developer and, as I’ve mentioned several times, those without Java experience will have to work hard to grasp much of the book’s content. Perhaps in an attempt to limit chapter size or to keep it accessible to those without Java experience, the script examples in this chapter only scratch the surface. A minor criticism: much of the code has pedestrian comments (about things that method names, etc. should suggest) and subsequent paragraphs have explanations similar to the comments. It would have been better to omit these comments, hence making the code more compact. Event handling, an integral part of BIRT scripting, is also covered briefly in a few examples. My feeling is that this chapter should assume a fair amount of experience with Java and the ability to pick up JavaScript while showing more detailed examples. Granted this would increase the length of the chapter and still would only show a fraction of the possibilities, but a more comprehensive example would be more instructive to the (stated) target readership.


The final two chapters deal with report deployment and a case study. The deployment material is good to get started with, and ideally your deployment requirements will fit within the basic cases. But, as is often the case with real world deployment scenarios, likely there will be complications requiring studying further BIRT documentation for alternatives. The working example chapter is only suggestive – to follow the example exactly requires a lot of set up and I doubt few readers will attempt it. As a summary of many of the concepts covered earlier, however, the case study is a nice summary and useful for pulling all of the previous threads together.


In conclusion, I believe John Ward’s book does a fine job of providing a quick start to BIRT. If you are a Java developing using Eclipse and want to take advantage of BIRT, starting with the BIRT “all in one” download and working through Practical Data Analysis and Reporting with BIRT will quickly get you up and running.

April 01, 2008

Reclipse

Hello everybody out there using Eclipse -
I'm doing a (free)Ruby version of Eclipse (“Reclipse” Just a hobby, won't be big and
professional like regular Eclipse) for Ruby and scripting language clones. This has
been brewing since last april 1st, and is starting to get ready. I'd like any feedback
on things people like/dislike in Eclipse, as my Reclipse resembles it somewhat (same
physical layout of the widgets (due to practical reasons) among other things).

I've currently ported JDT(3.4M3) and PDE(3.4M5), and things seem to work.
This implies that I'll get something practical within a few months, and I'd like to
know what features most people would want. Any suggestions are welcome, but I won't
promise I'll implement them :-)

March 20, 2008

Eclipse E4 and UFacekit

E4 and my impression

Haveing attended the E4 Talk, A Future of SWT and the E4 BOF. I'm looking forward for a lot of innovation and discussion about new architectures at various levels of the Eclipse-Platform.

The most important thing to notice is that E4 is much more than simply bringing RCP to the webspace. Still I'm going to concentrate on the UI-Aspect of E4 in the rest of the post.

There's never been a better time to start getting involved because I myself (or you yourself) can to some extend define how the future looks like.

From the discussion I had with all the guys from the Platform/SWT/...-team I feel fairly comfortable infact I'm glad the Platform/SWT-Team recognized that RAP is not the only solution to get RCP-Applications run inside the browsers. The current SWT-prototype code uses established technologies like GWT, Dojo. In fact with the current prototype design SWT is going to be for DOJO what GWT-Ext/MyGWT are for Ext-Js nowadays.

UFacekit and E4

Do we still have to put effort into UFacekit?

When I first saw what's been done by the E4-Prototypers my first reaction was: Do we still need to work UFacekit? My answer is definately YES because UFacekite is more than providing a possibility to run your Desktop-UI inside a Browser. UFacekit has more to offer than a uniform Widget-API. UFacekit provides other values:

  • Eclipse-Core-Databinding compatible to GWT

  • Eclipse-EMF-Ecore compatible to GWT

  • Highlevel-Abstraction for Eclipse-Databinding

  • Easy support for Decoration, ...

  • ... and much more

If SWT for Browser is getting reality (and it will trust me) people will want to use all this stuff in their application and then UFace provides them with all they need.

How can UFacekit profit


Well we get a first class Browser-Widget implementation for free or even better we can take part to make this happen (I'm willing get part of this effort) and use it in UFacekit.

UFacekit News

  • I added an Example how to use EMF + UFacekit inside GWT.
    You can take a look at the code here.

  • Angelo started to add CSS-Support for SWT-Widget in his own project and offered to donate it to UFacekit but I didn't had time to take look how to use it in UFacekit until now

  • Work on GWT-Ext port continues but getting the layout stuff right is a real pain

March 06, 2008

UFace - Update

I recognized today that I haven't blogged about one of my favorite OSS-project (UFace/UFacekit) lately.

For those of you who have never heard of this project let me introduce it in a few sentences.

UFace or UFacekit has the following targets:

  • Add a highlevel API above Eclipse-Databinding

  • Helping Eclipse-Databinding to gain momentum outside Eclipse/SWT/JFace world by providing Observable-Implementation for various UI-Toolkits like Swing, GWT, ...

  • Helping OSGi to be used in UI-Applications outside Eclipse-RCP e.g. in Swing Applications

  • Providing a uniform UI-API for all those widget-systems including builders for common form layouts (e.g. 2 column label/field list)


We have been fairly busy lately and added the following things into UFace:

  • Validation and Decoration Support (contributed by Kenneth Westelinck) for Swing and SWT

  • Worked heavily on the MyGWT integration

  • Maven-Build-System


Validation and Decoration


Adding decorations to a UIForms (our abstraction above the databindingContext providing a uniform API for different Databinding-Implementations JavaBean/EMF/UBean/...) is not more than adding these 2 lines to your sources:

StatusDecoratingInterceptor interceptor = 
new StatusDecoratingInterceptor(detailComposite);
detailForm_1.setAfterBindInterceptor(interceptor);


Darn cool, isn't it?

The resulting UI with validation error looks like this:

SWT on Win32:



Swing on Win32:


UFacekit implementation for MyGWT



Beside providing a higherlevel API above Eclipse-Databinding the other idea of UFace is to provide a uniform API to deploy your applications in different ways (Desktop, Web, Mobile-Devices, ...). In Web-Space we decided to go the GWT way which means your application is running completely in the browser and only business data is fetched from the server.

This concept is different from the one of RAP who, as far as I have understood the framework, does most of the work on the server-side and uses the browser "only" for rendering purposes (RAP devs please correct if I'm wrong here).

The hardest thing to bring to browsers are SWT-Layouts and that's where I'm currently progressing slowly but steadily at the moment. This is how the the same form looks like in the browser rendered with MyGWT:



It's not 100% right and Combo and List aren't working either but it was quite an achievement to get that far.

Current status / Release plans


My first draft plan was to have an M1-Milestone for JFace, Swing and MyGWT implementation ready for EclipseCon but I had to delay this because my current work load hasn't give me enough time to work on UFacekit too many hours. Today JFace and Swing are complete (as complete a first Milestone can be) and only MyGWT is missing so I hope we could have a first Milestone by April.

What's in the queue


We already have a queue for features we'd like to integrate (an incomplete list is this):

  • Support for more Widgets Tree/TreeTable, TabFolders, ...

  • Implementation ontop of Eclipse-Forms

  • Better looking decorations on Swing

  • Support for CSS to style your widgets

  • Extensible converts

January 23, 2008

EMF + Databinding - I'm adicted to this stuff

Ed blogged somedays ago about the progress he made makeing EMF available to RAP and J2ME and there are more and more people requesting a simple example project where some EMF-Databinding-Features are shown.

I've already send some code to the EMF-newsgroup and today I've added some more bits showing how to bind a Detail-List.



I'm going to add some more interesting stuff (e.g. field-dependencies, validation, ...) when I have time and will restart working on my article on EMF+Databinding+RCP+iBatis.

If you want to take a look at source code you can grab it from here.

There are some issues you need to be aware of when it comes to
e.g. Master-Detail + Field-Dependencies.

This is where UFace comes into play which handles this kind of thing for you (and even more).

Because I'm talking about UFace. We are making progress since the last blog entry the following things have happend:

  • refactored Factory-API to get extensible and not cluttered with overloaded methods

  • started to think how UForm can be used by native implementators (UForm is an abstraction level above Databinding and your Model-Implementation-Technology)

  • we added a new committer just today (Angelo Zerr) who develops some cool XML-UI things (See Akrogen) and is enhancing our Swing-Binding and SWT-Bindings. Welcome Angelo.

  • Set up a Committer and Contributor policy. I hate this legal stuff and we want to keep it at minimum but this has to be the foundation of every project

  • Received a code donation (SWT GridLayout for Swing) from Daniel Spiewak (See Daniels Code contribution)

January 10, 2008

One month of UFacekit-Development

A month ago James Strachan and I started hacking on a project we named UFacekit.

We both faced the need to write datacentric applications for different deployment environments (Desktop (Swing/SWT), GWT (MyGWT/GWT-Ext), ...) and we thought there must be an easy and fast way to come up with something that makes our day job easier. At this very moment UFacekit was born.

There are different things we are targeting with the project.

  1. Provide a uniform Facade above widget implementations (SWT,Swing,GWT,...)

  2. Promote the use of Eclipse-Databinding (and other related technologies e.g. EMF) outside Eclipse-World (Swing,GWT, ...) and provide a highlevel API above the low-level databinding API

  3. Provide reuseable Bundles which can be used independently
    • you are only interested in Swing-Databinding but still want to use the native Swing-API? - UFacekit provides an indepented Swing-Observable bundle for you
    • you want to use an alternative Bean-like implementation not relying on reflection and EMF is too heavy for you? - UFacekit provides an independent implementation for you named UBean



Instead of writing an SWT-Port for GWT/Swing (I know for Swing there's already an SWT port) we decided to go the Facade/Factory way and started hacking and the progress we made in this very short period of time (we are only working on it in the evening) is more than amazing.

Take a look at the following Screenshots they show what's already possible with the current sources.





They look fairly identical (the only reason they not look completely the same is that I haven't ported the GridLayout from SWT to Swing but relying on Mig-Layout).

They are full of features you need many lines code without a framework doing the nifity bits for you (e.g. MasterDetail + Field-Dependencies):

  • Master-Detail support

  • Model-UI-Binding

  • Field-Dependencies (Country/Federalstate)



Setting up this UI needs:

  • ~ 80 Lines of Widget-Toolkit-Independent code

  • ~ 20 Lines of Widget-Dependent code (= the start of the application which is currently not abstracted)



The amazing thing is that both UIs are made up by the same source code:


public void createFormUI(UIComposite root) {
UIFactory ui = root.getFactory();

UBeanForm listForm = new UBeanForm();
final UBeanForm detailForm_1 = new UBeanForm();

UIComposite containerComposite = ui.newComposite(root, null, ui.newGridLayout(2));

TableColumn[] columns = {
new TableColumn("People", new NameLabelProvider())
};

UITable table = ui.newTable(listForm, containerComposite, new GridLayoutData(200, GridLayoutData.DEFAULT, GridLayoutData.ALIGN_BEGINNING, GridLayoutData.ALIGN_FILL, false, true), listForm.detailList(AddressBook.PEOPLE, Collection.class), columns);

// ---------------------

UIComposite detailComposite = ui.newComposite(containerComposite, new GridLayoutData(GridLayoutData.ALIGN_FILL, GridLayoutData.ALIGN_FILL, true, true), ui.newGridLayout(2));
ui.newLabel(detailComposite, new GridLayoutData(GridLayoutData.ALIGN_END, GridLayoutData.ALIGN_CENTER), "ID");
ui.newTextField(detailForm_1, detailComposite, new GridLayoutData(GridLayoutData.ALIGN_FILL, GridLayoutData.ALIGN_FILL, true, false), detailForm_1.detailValue(Person.ID, int.class));

ui.newLabel(detailComposite, new GridLayoutData(GridLayoutData.ALIGN_END, GridLayoutData.ALIGN_CENTER), "Name");
ui.newTextField(detailForm_1, detailComposite, new GridLayoutData(GridLayoutData.ALIGN_FILL, GridLayoutData.ALIGN_FILL, true, false), detailForm_1.detailValue(Person.NAME, String.class));

ui.newLabel(detailComposite, new GridLayoutData(GridLayoutData.ALIGN_END, GridLayoutData.ALIGN_CENTER), "Location");
ui.newTextArea(detailForm_1, detailComposite, new GridLayoutData(GridLayoutData.ALIGN_FILL, GridLayoutData.ALIGN_FILL, true, false), detailForm_1.detailValue(Person.LOCATION, String.class));

ui.newLabel(detailComposite, new GridLayoutData(GridLayoutData.ALIGN_END, GridLayoutData.ALIGN_CENTER), "Country");
UICombo combo = ui.newCombo(detailForm_1, detailComposite, new GridLayoutData(GridLayoutData.ALIGN_FILL, GridLayoutData.ALIGN_FILL, true, false), detailForm_1.detailValue(Person.COUNTRY, Country.class), ModelHelper.createWritableList(getModel().getCountries(), Country.class), new CountryLabelProvider());

ui.newLabel(detailComposite, new GridLayoutData(GridLayoutData.ALIGN_END, GridLayoutData.ALIGN_BEGINNING), "Federalstate");
ui.newDependentListBox(detailForm_1, detailComposite, new GridLayoutData(GridLayoutData.DEFAULT,120,GridLayoutData.ALIGN_FILL, GridLayoutData.ALIGN_FILL, true, false), detailForm_1.detailValue(Person.FEDERAL_STATE, FederalState.class), (IObservableList) detailForm_1.detailList(Country.FEDERAL_STATES, Collection.class).createObservable(combo.getSelectionObservable()), new FederalStateLabelProvider());

WritableValue value = ModelHelper.createWritableValue(getModel());
listForm.bind(value);

IObservableValue detailObservable = table.getSelectionObservable();
detailForm_1.bind(detailObservable);

UBeanForm detailForm_2 = new UBeanForm();

columns = new TableColumn[] {
new TableColumn("ID", new IDLabelProvider()),
new TableColumn("Name", new NameLabelProvider()),
new TableColumn("Location", new LocationLabelProvider())
};

ui.newLabel(detailComposite, new GridLayoutData(GridLayoutData.ALIGN_END, GridLayoutData.ALIGN_CENTER), "");
ui.newTable(detailForm_2, detailComposite, new GridLayoutData(GridLayoutData.ALIGN_FILL,GridLayoutData.ALIGN_FILL,true,true), detailForm_2.detailList(Person.FRIENDS, Collection.class), columns);
detailForm_2.bind(detailObservable);
}


  public void run(final String uiMethod) {
Display display = new Display();

Realm.runWithDefault(SWTObservables.getRealm(display), new Runnable() {
public void run() {
Shell shell = createUI(uiMethod);
shell.setSize(650, 500);
shell.setText("UFacekit - JFace-Demo ");
Display display = Display.getCurrent();
while (!shell.isDisposed()) {
if (!display.readAndDispatch()) {
display.sleep();
}
}
}
});
}

private Shell createUI(String uiMethod) {
final Shell shell = new Shell();
SWTComposite composite = new SWTComposite(shell,new JFaceFactory().newFillLayout());
// generic code as shown above


You can even more reduce the size and complexity of the source by using FormBuilder-classes we are going to provide to make creating standard-forms like this as simple as possible.

Before we are publishing a first cut we need to finish the GWT-implementation (GWT/MyGWT/GWT-Ext) but we (in this case James) are on a good way and we should have a release fairly soon. Naturally there are some gaps (e.g. missing widgets, API inconsistencies) but hey the project just got 1 month so I hope you don't mind.

Did this spot your interest? Come and join our google group and share your ideas with us.

January 05, 2008

EclipseCon: I'll be there

News 1:

Just booked my flight and my room at the Hyatt. I'm excited to meet you all.

There are so many interesting talks like Steve's talk about the future of SWT which I'm very interested in because recently the Web-2.0 movement hit me hard and I've started to make Eclipse-Core-Technologies available in Web-Env.

News 2:

The other news I'd like to share with we you is that together with James Strachan I started a fairly interesting "experiment" called UFaceKit.

In short the project aims to provide a facade above widget implementations to use a uniform API above various Java-Widget implementations to create Datacentric-Applications.

Beside providing this generic API the project is split into many individual plugins/bundles which can be used out of the uface-scope:

  • A light weight JavaBean like implementation useable without any reflection-API the implementation is called UBean

  • Observables for UBean like Eclipse provides an implementation for JavaBeans

  • UI-Observables for GWT/MyGWT/GWT-EXT

  • UI-Observables for Swing



As you see one of the "waste products" of this project is that Eclipse-Databinding is can be used by Swing/GWT/... developers.

If you are interested in the project take a look at our project page and join the google-group. We are in pre-alpha stage and code changes a lot but we appreciate your help e.g. to provide an implementation for other Java-UI toolkits (QT-Jambi, Android, ...), help us with the Swing, GWT implementations of course all code is released under EPL.

Primary targets currently are:

  • SWT/JFace

  • GWT-implementations