In 3.5M3, we introduced two new API methods, showEditor(IEditorReference) and hideEditor(IEditorReference), in IWorkbenchPage. This is an interim solution that was proposed as an attempt to resolve bug 11001. Paul has provided a great description about what those two methods do and what we’re trying to achieve here in his comment so I suggest you read that and familiarize yourself with the details.

Essentially, these two methods provide plug-in developers with the ability to (unsurprisingly) show and hide editors at will. This seems to be a somewhat common use case in the RCP world as there appears to be a tendency to define rigid perspectives that are only intended to perform certain actions and those actions alone. Clicking something brings an editor up but when they switch to another perspective this “irrelevant” editor is still there and people get upset and so on and so forth.

The notion of restricting editors to a perspective is not unheard of in the IDE space either as I hear people ask for this feature every once in a while on IRC. These users don’t seem to like having their Java editors show up in the ‘C/C++’ perspective. This sounds like a fair requirement I suppose (I wouldn’t know since I only do Java development). Some users also want this filtering functionality extended onto views by filtering out projects based on current perspective. Now this all sounds like something Mylyn (and/or Tasktop?) can help the user with although I’m not positive as to whether Mylyn can be made perspective-aware or not in this regard…but what do I know, I don’t even use Mylyn.

In any case, even if a plug-in was perspective-aware and was achieving the functionality offered by these two methods, I’d imagine that the developers are probably using internal classes and methods and/or are having a tough time getting the behaviour to work right. If you haven’t been having any problems, we would love to know how and you can let us know how by leaving a comment on the bug. For the rest of you, if the idea of showing and hiding editors, perspective-related or otherwise, are relevant to your project or plug-in, please, download 3.5M3, give the API a spin and try integrating it into your code and let us know how it’s working out for you. The response we have had thus far since Paul committed the code has been underwhelming to say the least and I am shocked to say that this request actually has 18 votes! Of course, that number was only applicable at the time of this posting because this post may or may not cause that number to fluctuate. ;)

“Taking it to the next level” is a phrase we often used amongst the Extreme Blue teams and staff at the IBM Ottawa Software Lab in 2007 and I think it is quite fitting for this post. Whenever we didn’t know what to do next, we’d just ask ourselves, “how do we take [our project] to the next level?”. Thanks, Marcellus!

Back in 2006, Philippe and I had a dream of using BitTorrent to distribute plug-ins and updates for Eclipse and I participated in the Google Summer of Code program in 2006 in an attempt to realize that. The keyword here is “attempt”, because, needless to say, since this post isn’t entitled “Taking the Update Manager’s mirroring and file distribution capabilities to the next level…”, I didn’t get that far. But last night, I rolled up my sleeves and began to hard code values all over the place in an attempt to write my own implementations of the IArtifactRepository and IMetadataRepository interfaces and concrete subclasses of ArtifactRepositoryFactory and MetadataRepositoryFactory.

That did not go well. Quite simply, there were just too many methods to implement and I just gave up after it decided to call my metadata repository’s query method.

What I ended up doing was I subclassed p2’s implementations of these interfaces and abstract classes for handling update sites. By doing this, p2’s user interface would render things properly in its tree and actually allow me to click ‘Install’ (instead of throwing thousands of RuntimeExceptions when I was trying it the other way). Then I simply just overrode getArtifacts to retrieve the artifacts via BitTorrent.

What you see above is my Azureus instance seeding and sharing some plug-in jars of Subclipse and my BitTorrent protocol implementation at work downloading away in the ‘Progress’ view. Of course, the files didn’t actually even go to the right place (I had to hard code that too), but hey, I really just wanted to familiarize myself with p2’s (non-existent) APIs and I think that hacking something like this up together in a couple of hours has certainly helped me out on that front. :)

And before you ask, while the implementation of the BitTorrent protocol is in ECF’s CVS repository, this hack is not publicly accessible and will likely remain that way for a while. More to come later if this hack ever stops being just a hack.

The release date has been announced on the official website! Sadly, I don’t own a 360 (yet) so this is certainly very problematic. My original plan was to get a 360 when I returned to Hong Kong after the W09 term but it looks like that’ll be a little “late” now. The original claim was that it’d be released in the spring of 2009 so I had hopes that the stars would align properly but I guess that isn’t going to be the case.

絶望した!!!