1.4 thoughts

[jfrazierjr]

Ok, so I had an idea and ran it by Trevor yesterday via email. Anywhoooo... the thoughts were to utilize the built in platform that Eclipse is based on. Though Trevor did not say much specific, it seems clear that he does not like Swing and that he had looked at SWT at some point in the past, but ran into some issues with

....how buggy the canvas component was (for example, it wouldn't correctly rotate and translate a drawable, a MAJOR issue for MT dev)

I emailed him back(waiting to get a response) to try to get additional information as I don't know if he played with SWT last week or two years ago and the issue in question may have been resolved or will be soon.

Anyway, some of the things that Eclipse is good at:

• Plugins are built into the core and it's expected that you build your product that way, so extending will be at least somewhat easy if the base code is built properly.
• Update manager. This seems like a good way to let users quickly know about updates and download if they wish
• configurable layout manager(ie, dockable tabs) for child windows
• built in browser control. Not quite sure exactly how well this works standards-wise, but since it it build on the Mozilla rendering engine, I expect it would be at least more up to date than the base Swing stuff.
• perhaps having Javascript IDE directly linked so source could be modified "on the fly".. (note I said perhaps!!!)
• works on major platforms.
• ongoing development
• others I can't think of right now

I am sure there are some negatives also, so this is really more of a throw an idea out there thing.

Anyway, I hope to get more clarification from Trevor in the next few days on his issues with SWT to see if there might be some workarounds(or better yet, the issues are fixed!)

[prestidigitator]

From what I recall SWT used to be a lot faster than Swing, too, but I don't know what the comparison is like now.

[Notsonoble]

Everything i've read still points to SWT not doing well in graphics heavy situations, and that most of swings problems that caused IBM to start SWT are ironed out already...

http://leepoint.net/JavaBasics/gui/gui- ... wtxul.html <-- the short of what I've read several places.

[Azhrei]

I'm sounding like a broken record now (remember those, kiddies? round pieces of vinyl that spun on something called a "turn table"?)...

I still think JavaFX could be a great way for users/GMs to build interfaces for MT. The resulting code is compiled Java, so it can be inserted into the application and immediately used and it will run as fast as the rest of the MT code. JFX uses Swing as its underlying GUI layer and has no option for anything else.

It's declarative style means users would program in it by saying what they want their window to look, and then defining the actions that should occur when fields are changed or buttons clicked. Much more object-oriented for the user and easier to build and maintain libraries of reusable code.

Unfortunately, it's not quite done baking yet. There are Swing components that don't have a JFX interface yet and some things in JFX are klunky to do. That will be ironed out in time. There is a JFX plugin for Eclipse that I have installed but I haven't played with it much yet. Too bad, as I was thinking it would make a cool proof-of-concept to be able to have users build their own MT UI.

[Craig]

Ok, so I had an idea and ran it by Trevor yesterday via email. Anywhoooo... the thoughts were to utilize the built in platform that Eclipse is based on. Though Trevor did not say much specific, it seems clear that he does not like Swing and that he had looked at SWT at some point in the past, but ran into some issues with

....how buggy the canvas component was (for example, it wouldn't correctly rotate and translate a drawable, a MAJOR issue for MT dev)

I emailed him back(waiting to get a response) to try to get additional information as I don't know if he played with SWT last week or two years ago and the issue in question may have been resolved or will be soon.

SWT was created to address some issues with swing -- well more correctly it was created for political reasons as there was no reason that swing couldn't of been fixed, but I digress. This was quite some time ago and those problems really don't exist in swing anymore. Unfortunately SWT is no where as consistent across OS's as swing is -- funny about that really . Sure SWT proponents tell you SWT works the same on all systems but just search for SWT and Mac OS X and you will see this is far from the case -- and whats worse there doesn't seem much of a desire to fix some of these issues. Another down side is the HTML support, you can't have it in as many places as swing (such as buttons/tooltips etc), not only that the HTML display pane (think chat panel) uses your native browser for rendering, so on Windows thats IE 6, 7 , 8 depending on what is installed, Mozilla for Linux, WebKit for Safari. And you think people complaining about the HTML in macros being awkward now!

Anyway, some of the things that Eclipse is good at:

Plugins are built into the core and it's expected that you build your product that way, so extending will be at least somewhat easy if the base code is built properly.

Azhrei and I have already talked a bit about using OSGi for MapTool -- this is what eclipse uses -- its quite small (1 megish) compared to a full eclipse install.

[*] built in browser control. Not quite sure exactly how well this works standards-wise, but since it it build on the Mozilla rendering engine, I expect it would be at least more up to date than the base Swing stuff.

Its only Mozilla on some platforms

I am sure there are some negatives also, so this is really more of a throw an idea out there thing.

The size is another big draw back, just a barebones Eclipse RCP with the updates adds quite a bit to the jar. Also it means either different jar files per platform or putting SWT for all platforms in the jar.

Also from my understanding -- and I could be wrong -- you are pretty limited when it comes to changing the look and feel -- skinning -- SWT apps.

[jfrazierjr]

Everything i've read still points to SWT not doing well in graphics heavy situations, and that most of swings problems that caused IBM to start SWT are ironed out already...

http://leepoint.net/JavaBasics/gui/gui- ... wtxul.html <-- the short of what I've read several places.

Yea.. I have no idea of the details of SWT's deficiencies, so it just may NOT work. However, the little research I have done seems to indicate that many of the older graphics issues are no longer a problem(of course, it only takes one critical one to be a show stopper).

[jfrazierjr]

I am sure there are some negatives also, so this is really more of a throw an idea out there thing.

The size is another big draw back, just a barebones Eclipse RCP with the updates adds quite a bit to the jar. Also it means either different jar files per platform or putting SWT for all platforms in the jar.

Also from my understanding -- and I could be wrong -- you are pretty limited when it comes to changing the look and feel -- skinning -- SWT apps.

Don't get me wrong. I am not married to this approach. Perhaps this was just an attempt at false laziness by building upon RCP to handle the things that where already built into it and not have to start from ground zero with the UI. One example I was thinking of was when a client logged into a server, the code could unload certain bundles (such as the FOW drawing tools buttons/code) and repainting. This approach is of course also possible just adding one of the OSGi containers to the Maptool code and recoding certain parts of the UI, but with Eclipse, some of the work would already be done for you and you have a default platform from which to start.

One bonus IF we were to use the RCP would be the Update Manager, so instead of downloading an entire zip file (which is fairly small anyway), only the bundles that needed updating could be downloaded. On the flip side, the Webstart would be a hugh PITA due to the size, so I can see your point.

[Craig]

I'm sounding like a broken record now (remember those, kiddies? round pieces of vinyl that spun on something called a "turn table"?)...

You can fix that jumping record thing by getting some tape and taping a few coins to the top of the arm holding the needle

I still think JavaFX could be a great way for users/GMs to build interfaces for MT. The resulting code is compiled Java, so it can be inserted into the application and immediately used and it will run as fast as the rest of the MT code. JFX uses Swing as its underlying GUI layer and has no option for anything else.

Depending on what the next update of JFX is like (and when) it looks very promising, even more so if the manage to finally sneak JWebPane into it (basically a swing web pane that is rendered by WebKit, ooh aahh!!)

There are still several controls missing but there are also several libraries like JFXtras that fill this gap, JFXtras is one of the reasons that not all controls have been done because it does quiet a good job of implementing them.

There is a JFX plugin for Eclipse that I have installed but I haven't played with it much yet. Too bad, as I was thinking it would make a cool proof-of-concept to be able to have users build their own MT UI.

Even if it never gets used for MapTool its still a great tool for quickly prototyping GUIs, especially if you have Adobe Illustrator or Adobe Photoshop you can use the tools to make it easier to create gui assets.

[Craig]

Don't get me wrong. I am not married to this approach. Perhaps this was just an attempt at false laziness by building upon RCP to handle the things that where already built into it and not have to start from ground zero with the UI. One example I was thinking of was when a client logged into a server, the code could unload certain bundles (such as the FOW drawing tools buttons/code) and repainting. This approach is of course also possible just adding one of the OSGi containers to the Maptool code and recoding certain parts of the UI, but with Eclipse, some of the work would already be done for you and you have a default platform from which to start.

One bonus IF we were to use the RCP would be the Update Manager, so instead of downloading an entire zip file (which is fairly small anyway), only the bundles that needed updating could be downloaded. On the flip side, the Webstart would be a hugh PITA due to the size, so I can see your point.

I like your ideas, but really the only thing that Eclipse RCP would offer over OSGi container is the GUI interface for fetching modules -- which I don't think the Eclipse GUI is suitable for MapTool Plugins, there are probably better ways of having a central plugin registry as well as possible private repositories -- and the application window frame work. All loading/unloading of plugins is handled by Eclipses OSGi container (Equinox which is available separately from Eclipse).

[jfrazierjr]

Another down side is the HTML support, you can't have it in as many places as swing (such as buttons/tooltips etc), not only that the HTML display pane (think chat panel) uses your native browser for rendering, so on Windows thats IE 6, 7 , 8 depending on what is installed, Mozilla for Linux, WebKit for Safari. And you think people complaining about the HTML in macros being awkward now!

I was not aware of the per widget support for html(or the lack there-of).

As for the browser thing, even IE 6 is better at handling html+css than Swing IMO...

[RPTroll]

I like the concept of an Eclipse plug-in more than I like the realization. It seems something is always faster and/or more functional. I also like the thought of JavaFX and would troll nudge things in that direction if there aren't any tech barriers to such an implementation. I'll also toss my hat into the ring development-wise if things head that direction.

[Azhrei]

I was not aware of the per widget support for html(or the lack there-of).

Well, the issue is that if the underlying GUI is rendering the components, then either the components don't have HTML support and a veneer layer needs to be added that interfaces to the components' true API, or they do have HTML support which is inherently platform-dependent.

As for the browser thing, even IE 6 is better at handling html+css than Swing IMO...

The problem is not whether a single HTML renderer is better than Swing, but whether it's consistent from one platform to the next. Imagine all of the rendering questions we get now, multiplied by all of the different HTML renderers that are out there. It makes me nauseous just to contemplate it.

On the issue of updates, I don't think going to the Eclipse RCP just for updates is terribly productive. Its always nice to reuse someone's code, but honestly, replacing a given module with another is not a difficult thing to do. The Web Start feature already does this: when you execute b71 from Web Start you only download those JARs that are different from the ones used in b70. In this case, that means maptool-1.3b71.jar and rplib-1.0b120.jar. The MT jar is 4MB and the rplib is < 1MB. Not bad at all.

The OSGi stuff allows the classpath to be set from inside the application meaning that a network location can be specified first, followed by the local directories. And OSGi provides a nice interface for all that so if something changes in the future, the API stays (relatively) solid while the implement bits change underneath.