Twitter github

Posts Tagged with “pde”

Why paint the workbench?

I had a colleague of mine ping me this morning and ask me why I was making the Eclipse workbench look like a pride parade march? Let’s analyze this picture (thanks Simon) for issues:

  1. labels for padding? Is that really the best solution here
  2. there’s some pixel waste here
  3. some extra whitespace lying around
  4. not sure what that is exactly
  5. 21 pixels for spacing is excessive, how about 5?

See, colors can help. Also, I didn’t meant to pick on the JDT team here, this is just one example of many you can find in the workbench. Furthermore, each UI can have its own style, so the choices of the developers aren’t necessarily wrong.

Painting the Workbench

If you’re a UI developer in Eclipse, you probably come across one of these issues:

  • fighting layouts
  • fidgeting with margins
  • pushing pixels
  • etc…

You probably also came up with some hack to add borders to composites to help with these issues. Well, at least I did.

Why am I bringing this up? Well a few days ago, Simon Archer and I were discussing how new GridLayout() can be bad since it sets default margins and how it can be difficult for people to realize this amongst other layout issues. To ease some of these issues and stop the madness of duplicating debugging utilities, Simon and I decided to start a new work area in PDE called Picasso. The purpose of the Picasso work area is to provide a utility to help UI debugging. Picasso does this by painting the workbench in funny ways to aid debugging 🙂

The screenshot above shows Picasso painting the preferences page’s composites. Picasso also allows you to hover over widgets and provide some raw debug information.

How do I use Picasso? Simply grab the code from the PDE Incubator and launch some runtime workbenches. Or you can build yourself a version of the Picasso plug-in and drop it in your application to see what’s going on.

Note, Simon and I are just providing Picasso as a utility for people to use, we don’t have crazy plans on maintaining it unless the community steps forward with patches and ideas. It’s just a work area that maybe useful to some.


An Eclipse-based Facebook Application (Part 2)

Since we have a plug-in available to exercise the Facebook API (see Part 1), the next step is to create a ‘org.eclipse.facebook.ui’ plug-in that will exercise that API. What I generally do when testing some new code in Eclipse is to create a simple view. In this case, I’ll create a stub view with a hyperlink to launch some Facebook login wizard (along with some other test hyperlinks):

Now that I have the basic code infrastructure in place, let’s get our Web 2.0 on by using that Facebook API! In Eclipse land, to take advantage of another plug-ins’ classes, you need to express a dependency on it. So in order for me to use the Facebook API plug-in I created in Part 1, we need to depend on it. We can do this in the plug-in manifest editor by going to the dependencies page and adding a dependency for the ‘com.facebook.api’ plug-in:

After reading the Facebook API in detail… it seems the API for logging in is straightforward albeit a bit tricky for a deskop-based application. In essence, you have to point to a special URL given to you by Facebook to login… once a user logs in, you need to capture a token that you use to create a REST client for Facebook API access. Ok, translating this into Eclipse terms, I figure all I need is a popup dialog and an SWT Browser widget with a clever listener. So here it is:

All this code does is create an embedded browser within a popup dialog and fishes for a particular authentication token from Facebook. If it finds the particular token, it will create a session with Facebook, if not, it will keep the dialog open until the user properly authenticates.

I was initially having trouble logging in to the service because I was stupid in how I was parsing the authentication token. I didn’t solve the problem until I enabled some tracing information. One interesting way to allow tracing for your Eclipse-based applications is to use the Platform debug facilities.

The basic gist is to create a .options file in the root of your plug-in. Here is how the ‘org.eclipse.osgi’ plug-in .options file looks like:

Pretty simple right…? Now, when you go to launch Eclipse applications, there is a tracing tab that allows you to tweak this options on and off to see what type of tracing information you would like:

I basically enabled this tracing ability within the facebook plug-in:

I then peaked at the console after I logged into see some tracing output:

So there, now I have a simple little framework to enable configurable tracing within my Eclipse-based applications.

That’s it for Part 2. In Part 3, we will cover things like separating core code from user interface code, Eclipse Forms and amongst whatever else pops up in my head.

Lessons Learned

  • Start simple and iterate as you make progress
  • A simple view provides a good way to test code
  • Trace early, trace often
  • Platform debug tracing provides a simple way to enable configurable development time debugging

Thanks for listening.

Plug-in Development Tip

Ever wanted to browse for a Java class but not import the whole universe in your workspace? Well here is a tip for you… I’ll do it in pictures.

I start with an empty workspace… and I want to find the EObject class from EMF. I Ctrl+Shift+T my way to sadness:


However, there is a Plug-ins view in Eclipse from PDE that allows me to add plug-ins to ‘Java Search.’

Now I try searching for my EObject class:

Now I’m happy 🙂

An Eclipse-based Facebook Application (Part 1)

So, the first thing I do when I write an Eclipse-based application, or any application for that matter is set a quick baseline of what I want done. For my first milestone, I decided I simply wanted to be able to log into Facebook. I figured, this would be a good start… it would require me to use the Facebook API in some fashion. This would force me to create a plug-in for the Facebook API which I would reuse when I started to do things like update my status from Eclipse. So my first stop was to look at the Facebook Java APIs since that would make life easier for me.

I found a cool project hosted at Google Code that contained some Java APIs. The only problem was that it seemed you needed a million jars to use these APIs. As an Eclipse plug-in afficiandio, I knew how to handle this… I’ll create a new plug-in! I downloaded all the jars and then launched the ‘New Plug-in Project from Exisiting Jars’ wizard which allows me to quickly create a plug-in by pointing to those existing jars.

To give my newly created plug-in some polish, I’ve decided to do a couple things. First, I’ll only export the packages that my consumers will need to work with the Facebook API:

In the Eclipse and OSGi world, Java packages are the unit of modularity. My consumers shouldn’t care about the other packages and I don’t feel like supporting those packages downstream so I won’t expose them. Since I don’t expose them, my consumers won’t be able to use any classes from those non-exported packages. This provides a nice way to keep your API really “internal.” For my next magic trick, I will make sure to set the Bundle-RequiredExecutionEnvironment (BREE) for my plug-in to J2SE-1.5:

BREEs are a way of telling Eclipse and OSGi that your plug-in at a minimum, requires Java 5.0 to run. This is cool because the Eclipse runtime won’t activate your plug-in if it’s running on Java 1.4… only Java 5.0 and above. The runtime will also give a message out stating that the plug-in can’t activate because the mininum BREE hasn’t been yet… also cool!

So with my new Facebook API plug-in setup and polished to my liking, we can go and start exercising that API in interesting ways. The first way will be finding a way to log-in to Facebook and that will be discussed in Part 2.

  • Lessons Learned
    • Start simple and iterate as you make progress
    • Use the ‘New Plug-in Project From Existing Jars’ wizard to package your dependencies
    • Don’t forget to set BREEs, they can save your consumers some heartache!
    • Export packages from plug-ins that consumers are only interested in

If you like this type of material, let me know. If there’s a good response, that’s usually motivation for me to do things faster.

New Target Platform Preference

To give plug-in developers out there a heads up… I want to say that there will be a new preference available to you when working with target platforms in 3.4M7:

What does this preference do?

Well, first, let me tell you about how PDE goes to build your target platform. By build, I mean what PDE does when you point it to a location and you get a target platform out of it. There has always been a little magic inside that operation. The magic involves PDE analyzing your target platform location and looking to see if it can find a configuration of plug-ins installed. How did PDE do this? In the the era of before p2, there was a platform.xml file that was kept by Update that listed the set of recognized plug-ins. In the era after p2, there is a file called which serves a similar purpose. These files were there so the runtime can make smart decisions on what to actually run when started. For example, you could have 10 versions of plug-in A on disk, but only one version listed in one of those configuration files so when Eclipse is ran, the runtime only knows about what is listed in the configuration file (see a sample below).

So if PDE found one of these “configuration files” it would construct your target platform to reflect what would actually be running in your target. If it didn’t find one of these configuration files, it will then just manually scan the file system and build a target platform with what plug-ins PDE found on disk. In the 10 versions of plug-in A case, it would populate the target platform with all 10 versions if it couldn’t find a target “configuration file.”

When p2 was introduced in the SDK (3.4M6), the file was always around and caused confusion for people when they grabbed the SDK, unzipped something like WTP and all their dependencies, and pointed their target platform to the location to only see the SDK set of bundles. PDE was almost being too smart here… it’s analysis of the target platform was correct, ie., only the SDK set of bundles have been discovered by p2 and since the target hasn’t been launched, the unzipped set of bundles (WTP) haven’t been discovered yet.

To not break people’s existing workflows, PDE added this preference to the target platform preference page with some smart initialization. If you’re target == host, we will attempt to build the target platform using the target’s configuration. If your target != host, PDE will revert to manually scanning for plug-ins on the file system to build your target platform. It seems 99.9% of the Eclipse plug-in development community has been spoiled by that workflow so PDE needs to adapt. However, if you wish to change this behavior, the preference will allow you to do that based on your needs.

I hope this clarifies things for some people who have been experiencing growing pains with the 3.4M6 version of Eclipse. It pains me to expose this preference, but it seems it may be a good thing in the long run. The important thing to take away here is that an unzipped plug-in != installed plug-in.

Related bugs:
[bug 226037] – initialization policy for target platform should be different based on location
[bug 225148] – P2 PDE target doesn’t work, easily

Internal Extension Points

What do people think about internal extension points? Currently, there is no concept about “internal” extension points in Eclipse besides using the convention of having “internal” (ie., internalTweaklets) in the extension point name along with some terse documentation. I know there are also products that don’t ship extension point schemas (.exsd) to prevent their users from extending schemas they don’t want. This is kind of funny because Eclipse is still aware of the extension point it just can’t help the user extend it… since there’s no schema… in essence… the extension point is being hidden… yet it is still there:

I think we can do better than this and try to mimick the concept we have with internal packages and x-friends. For example, imagine an extension point you wanted to define to be used just but your plug-ins for now… it’s useful for you internally but not ready to open to the public yet. In PDE, we could allow you to define an extension point as internal and maybe give it some “friends” that wouldn’t be flagged as discouraged access to the extension point.

What does the community think? Is this something valuable for people?

Prosyst Equinox Contribution

Ian Skerrett must be doing a lot of marketeering today… I’ve been seeing a couple of press releases go through my inbox. Prosyst officially announced some of its recent graduated contributions to Equinox:

  • Initial Provisioning (CVS) (note: not related to p2)
  • IO Connector (CVS)
  • Wire Admin (CVS) (note: nothing to do with wiring packages)
  • Declarative Services (CVS)

This is good news because the old Declarative Services implementation in Equinox sucked due to concurrency issues and Equinox didn’t have any of the other mentioned implementations. It’s good to see more services out there for people to take advantage of… especially when they are in the OSGi specifications.

With that said, anyone want to contribute Declarative Services tooling to PDE? New contributors don’t be scared… I have room for you in the PDE Incubator 🙂

Pushing Pixels and I-Build Goodies

There’s been a lot of hustle and bustle for the latest Eclipse I-build. The p2 guys are pushing hard to get things in and the API Tools camp is making their debut. From the PDE UI camp, I was on an icon conquest today with improving icons in the schema editor:

It’s funny that I agonize over things like icons when probably only a few people in the Eclipse community really care about pushing pixels. In the end, I lost my battle with overlays so another redesign of the schema editor icons will happen in the future to make them more overlay friendly:

I also had fun trying to come up with icons representing OSGi services but I’m going to save that rant for tomorrow.

Another item coming from PDE is a filterable launch configuration:

This is incredibly useful if you want to filter for a set of plug-ins and either enable or disable them. For example, say you wanted no org.apache* plug-ins in your launch config, simply filter for them and click ‘Deselect All’ (it’s filter-sensitive now). No more going through and checking things individually! Everyone can thank Ian Bull for his persistence in getting this enhancement in.

The other thing I’m looking forward to in the upcoming I-build is improved colored label support. Look for PDE to adopt this in things like the ‘Open Plug-in Artifact’ dialog and other places that make sense. If you’re interested in test driving this functionality, look for a class called StyledCellLabelProvider in the 3.4M6 release.

Oh, and JDT Core released some crazy changes to support external class folders. I plan on looking at this support in depth after my vacation to see if we can close an old outstanding issue in PDE.

That’s all that comes across my mind for now 🙂

Articles, Articles, Articles

During my last webinar on Plug-in Development 101, I received feedback from an attendee that they would like to see more basic articles about Eclipse out there. Since I do anything for Eclipse, of course I obliged and produced a Plug-in Development 101 article series over at developerWorks (part 2 is coming early next month).

While this article may not apply to most readers of my blog, it’s nice to have basic information out there to foster community growth. It would be great to see a CDT 101 or Higgins 101 out there for the masses. I’m always willing to help any Eclipse projects out there if they need some article help, feel free to contact me.

For the more advanced Eclipse developer out there, Ian Bull and I are working on a Zest article for next month. On a personal note, once Ian and I are done, I’ll be celebrating my 25th Eclipse-related published article! Drinks on me!

Thanks everyone for reading, if you have any article suggestions, feel free to drop me a note.