Pros/cons for writing tools as Eclipse plugins?

Engines, Libraries and Tools Tools Discussion
#1

I have a few tools I’ve created over time which run as separate LWJGL apps - the biggest two the level editor for Quix, and a 2d skeleton creator/animator. These are written to be as WYSIWYG as possible, which is why they use a LWJGL display and tend to share lots of the actual low-level classes and rendering with the games they were made for. Due to using a LWJGL diplay I chose to use Cas’ Spaghetti gui system (the one from 'flux), which has since then been extended and tweeked in various ways. A nice side effect of this is that I can actually display sprites/textures in the GUI without any problems as they’re using the same texture loader classes/backend. Images here and here to give you some idea of what the UI looks like.

Now spaghetti has served it’s purpose admirably, but it’s not exactly designed for this kind of work, and has numerous quirks when used in this way which make it less than ideal. Basically I’d like to switch over to a ‘proper’ GUI system. Which basically gives me the choice of Swing or SWT, and if I choose SWT the additional choice of whether to do a standalone tool or an Eclipse plugin.

Snags:

  • I need a LWJGL display. I have no idea if Swing or SWT would be prefered for this.
  • I’d like to share as much code as possible so that in-game doesn’t end up rewriting the outgame stuff. Ideally they’d all become game-agnostic, which should be doable with some refactoring. If I have to package up my classes into an eclipse plugin that’s going to make it harder to keep the two in sync.
  • I’m still not sure of the advantages of having an eclipse plugin vs. a standalone app. I know Kev did a nice map editor as a plugin (which I’m going to try in just a bit) but it still seems like an odd idea to me.
  • Swing gets a plus because I already know enough of it to get going without too much pain. On the other hand I’m not keen on working with Swing code (tree views, dnd and layout managers in particular I find rather frustrating) and it’d be good to try something else.

Anyone any suggestions/advice for what things to look into? Or any big advantages or disadvantages I’ve missed?

Cheers.

#2

Worth noting OpenGL is there as part of Eclipse 3.2:

http://archive.eclipse.org/eclipse/downloads/drops/S-3.2M3-200511021600/eclipse-news-M3.html

Also worth noting that SWT is signifcantly different to Swing in structure. Took me a little while to get my head round it. Its not a trvial swap over.

Kev

PS. The last time I tried the map editor it worked for me but I couldn’t reproduce a bug someone was having.

EDIT: Forgot to say - having editors integrated into Eclipse is absolutely lovely tho :slight_smile: Saves lots of times, feels very natural in work flow.

#3

Aye, I’d just noticed that SWT support, and an eclipse plugin does sound very tempting.

Other than the conceptual switch, did you find SWT to be as fast to develop with as Swing?

#4

I’ve worked with AWT/Swing everyday as long as I’ve worked - moving to SWT took a big of getting used to (its a bit like the Win32 MFC if that helps at all) but now its pretty close on par with Swing. Working as an Eclipse plug-in is whole other ball game though - I still find everyday something new in plug-in framework that screws me over (last time was caching of plugins outside of the plug-in mechanism). Of course once you’ve got your basic framework working in Eclipse its ok.

Its a bit step to take - but overall I think the reward is worth it.

Kev

#5

In general, I think that plugins are more difficult to write than stand-alone tools and limit distribution. I wouldn’t bother unless you think the Eclipse community (and no-one else) needs your tool.

#6

Sorry, I thought we were talking about the bespoke tools of an Eclipse user here?

Kev

#7

Probably. Er, almost certainly. In theory it’d be nice for users to use the level editor (and other developers to use the skeleton tool). But realistically no-one is likely to want to use it other than me.

#8

I think writing tools as plugins has some advantages for developers: you can tidy your workflow using the environment you are used to. That’s the reason why I write NetBeans plugins. And since there are rich client platforms available for both NetBeans and Eclipse, you can always create a standalone app on customer demand.

And getting used to the plugin framework of the IDE you use everyday can’t be bad…

#9

I’ve been thinking about this myself a lot but haven’t got the time to do it. All that XML that SPGL uses and the sprite packer etc etc. … wouldn’t it be nice if you could just drop pngs into a project and they got auto-packed and such?

Cas :slight_smile:

#10

SpritePacker + friends can be a tad annoying, but I’m not sure how they would be changed to be easier/better. I mostly tend to stick it into an ant script and forget about it, but it does place awkward restrictions for doing runtime loading etc.

#11

If you want to use SWT or Java with a current release of Eclipse then grab the Visual Editor plugin (VE) I am using the latest with Eclipse 3.2m5 I think. It is relatively nice way to mess with layouts etc. The main advantage of a plugin is the ease of development…I write them for a living and my life is so much easier now.

If you are not aware of it you can export a Plugin (plugin set) as an executable RCP (Ricj Client) Product. This provides a consise set of your/eclipse jars with startup code etc. that can be executed independently of eclipse.

#12

I do not know much about Eclipse and how it handles plug-ins. However, I always get a bit worried when someone is suggesting restricting the design/flow of an application because it needs to fit into a specific framework. I have often been in a situation where I had to be very ‘creative’ to actually solve a problem because of the restrictions that was defined by the underlying framework I was using. I presume that Eclipse has similar issues…

I only have experience using some of the plug-ins for e.g. uml modeling and I have never been fully satisfied with these modules. Cannot remember precise which one I tried but none of them actually provided a fully integrated solution I was happy with. I decided not to try using any UML plug-ins for my development for a long time. I believe this is a major issue for the Eclipse concept that it seems impossible to create a development tool that fully satisfies the need for a good UML modeling tool. This plug-in concept seems a bit too modular, which makes it impossible to fully integrate functionality provided by different modules. Please proof me wrong because having a framework like Eclipse would be very beneficial and save a lot of time. It just seems to me that if you want to make a solution where the usability is good and the functionality of the application is clear and easy to use you will have to make it from ‘scratch’.

#13

I would recommend writing your tools as OSGi bundles instead of Eclipse plugins. Eclipse provides support for this. The advantage would be that you’re not tied to Eclipse (and by extension SWT), although bundles automatically qualify as Eclipse plugins as well. Several implementations of the OSGi framework. Equinox (the foundation for Eclipse) is one, Apache Felix is another, Knopflerfish is a third. OSGi is an open standard maintained by the OSGi consortium. OSGi is an implementation of a Service Oriented Architecture within an application.

Of course if you’re set on using the Eclipse RCP and/or SWT, going the plugin route would probably make more sense.

#14

As I understand it there’s no mandate to actually use SWT for plugins anyway. I’m pretty sure you can use Swing too and it integrates somehow.

Cas :slight_smile: