Now that I’ve finally finished school, started a job, and received a paycheck, I have decided to help make Denis’s new year wish come true. Eclipse has long been a friend of mine, and now I’m a Friend of Eclipse!
Every once in a while something just doesn’t happen to be as intiutive as you would have liked it to be. Lately I was trying to contribute a simple command based toggle button to the workbench. Although it is simple to actually provide the menu contribution and to put the button in visual “toggle” mode, it was so straight forward to actually obtain the state of the button in the UI.
To make the menu contribution show up as a toggleable button you have to provide the style value “toggle” on your commands menu contribution:
<extension point="org.eclipse.ui.menus">
<menuContribution locationURI="...">
<command commandId="org.eclipse.example.command.toggle"
style="toggle" />
</menuContribution>
</extension>
Next we have too keep track of our actual toggle state. Since it is possible to have multiple menu contributions for the same command, we have to keep track of the state in a central place. Imagine a toggle button triggerable from the main menu and a views toolbar. The state of these buttons are keept in sync by storing the state directly in the command. The key to this is the org.eclipse.jface.commands.ToggleState. This implementation of org.eclipse.core.commands.State is a wrapper for a boolean. To attach such a State object to a command, it is provided during the command declaration:
<command id="org.eclipse.example.command.toggle"
name="Toggle Me">
<state class="org.eclipse.jface.commands.ToggleState"
id="org.eclipse.example.command.toggleState" />
</command>
The state element takes the ToggleState class as a state provider and attaches itself to the command. The id of the state has to be unique to identfy the state. With the state attached to our command, how can we access it? In the Handler, reacting to the invocation of the menu contribution, we have to access the current state keept in the ToggleState. The following code demonstrates just that:
ICommandService service =
(ICommandService) PlatformUI.getWorkbench().getService(ICommandService.class);
Command command = service.getCommand("org.eclipse.example.command.toggle");
State state = command.getState("org.eclipse.example.command.toggleState");
state.setValue(!(Boolean) state.getValue());
We obtain our command from the ICommandService and ask it for our toggleState stored within the command. Next we just flip the boolean as to create the new state. Now we can just do whatever we want to do in our Handler using the new state. Great, isn’t it? Of course the ToggleState is only one possible implementation of State. One could also imagine multiple states, radio states, text states etc. Also the State class has a specialization (PersistableState), which can be persisted to the preferences as to keep track of the (toggle) states of your buttons.
But there is thing left to do: what happens to this other button which is also a menu contribution for our command? We need to toggle the pressed state of it, as to reflect the state of the first button. To do so, a Handler has to implement IElementUpdater providing the method updateElements(…). It gets an UIElement as a parementer, which can be used to trigger the toggle state:
public void updateElement(UIElement element, Map paramters) {
element.setChecked(isSelected);
}
To broadcast the refresh event to all menu contributions we use the ICommandService in our Handlers:
commandService.refreshElements(executionEvent.getCommand().getId(), null);
I hope you find the information here valuable and i am looking forward to your comments.
I just recieved my EclipseCon 2009 Registration confirmation.
Here are my talks that were accepted:
I’m looking forward to meet you all there at the conference.
Don’t forget to vote for the committer shirt contest, book your Hotel and bring your power outlet adapters…
Over the past month or so I’ve been working with the DZone folks to put together a refcard on Equinox and OSGi. It was finally released yesterday. Phew.
The idea behind refcardz is to give people a quick overview of a technology, how to get started and a few of those key tips and hints for being effective. Putting one of these together is a bit of a challenge as the topics are broad and there are lots of different audiences — Equinox and OSGi are no different. No matter what you are going to leave out stuff. You can also check out the interview I did with James Sugrue on Equinox for the release of the refcard.
Finally, keep an eye out for a full book on Equinox and OSGi coming out in the summer. You can get some of the content now from Rough Cuts. Your feedback is extremely useful.
This semester my wife gives a lecture in theoretical computer science at the KIT (Karlsruhe Institute of Technology). The current topic is decidability and therefor the students learn about the halting problem. The whole topic is rather dry and good examples for illustration are always welcome.
One example I liked is the question whether a program is a virus or not. As a proof, you could reduce the halting problem to this problem, but it is far better illustrated by giving a self-referencing program (the formal proof then would be based on diagonalization):
Let P be the program that decides whether A is a virus. Then you could define your virus A as:
if P(A) then exit; else infect();
Great, isn’t it? The virus knows the virus-detector P and doesn’t behave as a virus if P can identify it as a virus. If not, it’s evil. q.e.d.
That’s the theory. Let’s have a practical look at it.
First of all, it seems that the virus author is a pretty bad program designer – we usually try to avoid circular dependencies. But, being pragmatic I’m willing to compromise where it is necessary and in this case I must (unless I want to reduce the halting problem).
What seems more awkward to me is that the virus depends on P to being a behavioral analysis. Antivirus programs actually do behavioural analysis to detect viruses. And although I can’t find a link of proof between all the antivirus ads in Google I remember at least one headline where a root kit detected antivirus software and clouded itself against it.
But Antivirus programs also do statical analysis. In statical analysis the code isn’t run but only looked at. And any P that does statical analysis would find infect() (hopefully, if the heuristics work) and thus mark the self-clouding virus as virus anyway.
Of course this does not invalidate the proof that I hinted to above. I really like it as example for decidability. It works if you define “virus” as a program with malicious behaviour.
It’s sad that in practice we can’t always restrict our environment as we need it – unless we just write a “Hello World”.
Have you ever come across an issue while developing an Eclipse-based application, go to export it and get an evil “Invalid character constant” message or something similar in your logs? This happens when you’re developing an application that requires Unicode characters but your system file encoding is something other than you expect (i.e., on Macs it’s usually MacRoman and on Windows it’s Cp1252). When you go to export, PDE Build will use the default file encoding (see the file.encoding system property) available to the VM. This can cause problems if you’re using Unicode characters in code and on export, PDE Build chooses a default encoding like Cp1252.
In Eclipse 3.5M5, PDE added some checks to make sure that your project encoding matches what would be exported:
This is accomplished via the javacDefaultEncoding.<library> property (in your build.properties file). This doesn’t help you much if you need to do file-specific encodings, but PDE Build supports that via the javacCustomEncodings property. For example:
javacCustomEncodings.. = src/org/foo[US-ASCII],\
src/org/foo/bar.java[ISO-8859-1]
Hope this helps!
I used what little free time I had over the holidays to catch up on the recent developments in source control management systems, which have been quite interesting to follow. Especially the arrival of Distributed Version Control Systems has caused quite a buzz in the software development industry.
Somehow Eclipse as a whole totally missed the SVN boat. Only in the last year has there been any uptake of Subversion within the Eclipse Foundation itself. And although there are two separate plugins (and by my count at least 3 different adapter libraries) it still doesn’t feel quite as solid as the CVS counterpart. But the writing is on the wall: CVS does not fulfill all the needs we expect from a contemporary source code management system. And while I have been a long-time fan of Subversion (atomic-commits and rename tracking, yay!) I still feel that maybe the time of centralized source control is over, especially in an open source environment. Doug Schaefer seems to agree. Distributed source control makes it much easier for potential contributors to get started. Experimental and “investigative” branches are easier to manage, and things like feature branches are more easily merged again. While it’s not all roses either (partial checkouts and IP-taints anyone?), but it does make the the development process quite a bit better. And isn’t that one of the main goals of the Eclipse Foundation?
So over the holiday I checked out (quite literally) the latest egit sources and played around with it a little. I must say that I came away quite impressed. Although there are still some features missing, the core looks very solid and usable.
The history of the egit project
Because the source for egit is openly available, it was very easy for me to “grok” the innards of the git system. My C is getting a little rusty these days, so a Java implementation made a much better reading experience for me. Debugging and Ctrl-clicking as well for that matter. With the core jgit library in hand, I even tried to implement a versioned POJO persistence store, but that’s a story for another time. What struck me most about git was the raw and brutal simplicity and the resulting elegance of its design. Believe it or not, but git only knows four different types of objects. Java’s “hello world” uses about that many! Another neat thing is the hash value that is calculated for virtually everything you do. When I first readabout this feature, I was quite skeptical to be honest: For starters, I don’t want to type 40 letter strings anytime I want to reference a revision and secondly, what about collisions? Well I worked out the math on that one, and what it comes down to is this: by the time I will create my first collision I will have been struck by lightning three times over and have survived the sun going supernova. And as for typing in those hashes, well you need it less than you would think and even then you usually only need the first few letters to make it unambiguous.
So kudos to the egit team for the great and continued work on this project. There even is an egit project proposal up. Although git support was postponed in the last board meeting, I still think this a step in the right direction and I’m looking forward to future developments.
(18) (4) (120) (57) (8) (58) (127) (35) (9) (15) (3) (17) (12) (13) (12) (16) (3) (20) (8)