Archive for November, 2010

RText 1.3.1 – Bugfix Release

Wednesday, November 24th, 2010

Wowza, just a few days after RText 1.3 was released, a major bug was discovered by a fellow on the RText forums.  This bug caused the Options dialog to not display if you didn’t have Perl installed on your machine.  You got no error message, just no Options dialog.  The cause was a nasty, unchecked NullPointerException, but as such was an easy fix.  So if you grabbed 1.3, and especially if you don’t have Perl installed, go and upgrade to 1.3.1 today!

RText 1.3.0 Released!

Saturday, November 20th, 2010

RText 1.3.0 was released on SourceForge this past Friday!  This released focused on two things:  aesthetic improvements to the UI and bug fixes.  As always, I encourage you to download it and check it out.  Here’s a rundown of what was changed:

  • Drop shadows were added to menus. This code was graciously borrowed from JGoodies, and when using WindowsLookAndFeel, really pushes us over the edge to looking like a truly native application.

    Drop shadows under menus

    Drop shadows under menus

  • Revamped external LookAndFeel support. Several Substance 6.1 skins are now selectable by default in RText.  Some tweaking may still be needed to get some custom components looking 100% with arbitrary (non-”standard”) LookAndFeels.

    RText with Graphite Glass skin

    RText with Graphite Glass skin

  • Text matches in the “Find in Files” dialog are now syntax highlighted, providing a little extra context when looking through a list of search results:

    Syntax Highlighted Search Results

    Syntax Highlighted Search Results

  • Translucent search windows now work on Java 7+, not just Java 6.  This feature is still optional and disabled by default, as translucent windows may not be a fast operation on some systems (or you may just find it annoying =)  ):

    (Optional) translucent search dialogs

    (Optional) translucent search dialogs

  • Added Copy, Paste, and Delete popup menu items on the File System Tree:

    New File System Tree options

    New File System Tree options

  • Added PERL5LIB modification support to the Perl parser – see the Perl options panel in the Options dialog.

    Overriding PERL5LIB

    Overriding PERL5LIB

  • Fixed a bug with “variables” not working for tool directories (i.e. ${file_dir}).
  • Fixed several bugs in Java code completion.
  • The relevant Throwable is now included in completion choices when inside of a catch block when editing Java:

    Java code completion in catch blocks

    Java code completion in catch blocks

  • Logging any uncaught EDT throwables to a log file in user’s home directory (AWTExceptionHandler).
  • Fixed NPE in FindInFilesTable when user switches from WinLAF to another one (workaround for JRE bug 6429812).
  • Added a “Libraries” tab to the About dialog listing all external libraries RText uses.

    About dialog lists used libraries

    About dialog lists used libraries

  • The order you put file chooser favorite directories in is now remembered.
  • Updated Spanish translation (thanks phrodo).

Big Source Browser improvements for Java

Sunday, November 14th, 2010

RText has almost always had a “Source Browser,” a panel docked on the left (by default) that gave an outline of the code in the currently active editor, similar to the “Outline” view in Eclipse.  This component is powered by ctags, either the standard one if you’re on *nix, or Exuberant Ctags on Windows (or again on *nix if configured that way).  Using the former buys you outlines for C source only, while using the latter gets you outlines for any programming language supported by both Exuberant Ctags and RText (really, what’s supported by RSyntaxTextArea).

But not too long ago, as part of my Language Support add-on library efforts, I also implemented an outline tree specifically for Java, almost perfectly mimicking Eclipse’s Outline view.  I’ve been wanting to use it in RText for awhile now, but figured since it was currently Java-specific (won’t display an outline for any other language), it couldn’t be used.  Well, I finally bit the bullet and made RText’s SourceBrowser “pluggable.”  Languages can register a specific tree view for themselves, but if they don’t, it falls back on the standard ctags-based tree.  This allows me to register and use the JavaOutlineTree class only when editing Java code.  Here’s a screenshot:

Java Outline Tree

Java Outline Tree

As you can see, the Source Browser now provides much more detailed, and much nicer looking, information for Java classes.

Substance LookAndFeel in RText

Wednesday, November 10th, 2010

One of the nice things about RText is how configurable it is.  Not only can you change the fonts and colors used in the editor, but you can also change the icon set and LookAndFeel of the application at runtime.  This results in a huge amount of flexibility in the appearance of RText, although most people just stick to the defaults (system LookAndFeel, Eclipse icons, Visual Studio-ish editor color scheme), simply because those default settings look nice enough.

Lately though, I’ve been hankering to offer more built-in flexibility on the LookAndFeel side of things.  For a long time, RText has shipped with the Office LookAndFeels, however those are only usable on Windows, and even then only look good on Windows XP and earlier (note to self: need to revisit these and tidy them up a little for Vista and 7!).  Personally, I’ve been wanting to try out a “dark” LookAndFeel, so I did some hunting…

Turns out one of the skins of the Substance LookAndFeel is dark (“Graphite Glass”) and overall looks quite nice.  So I decided to see what it would take to run RText with Substance.  I thought it would be straight-forward, due to RText’s ability to load 3rd-parth LAF’s dynamically; however, it was a lot more work than I thought it would be.

First, the latest, greatest Substance release requires 2 jars – the main “substance.jar” and an extra library, “trident.jar”, which seemingly handles the animations in the LAF.  RText’s LAF loading was hard-wired to assume a single jar per-LAF, so I had to modify the XML format to allow specifying multiple jars.  No biggie.

Next I ran into what appears to be a bug in Trident, though I could be wrong.  RText allows dynamic loading of 3rd-party LAFs by dropping them into a specific directory and adding an entry for them in an XML file.  The magic behind loading them is done via a custom ClassLoader, which is used when setting a new LookAndFeel at runtime.  Initially, I kept getting strange Exceptions about Trident-related stuff not being able to load resources that were in its own jar file.  I dug into the source, and it appears that org.pushingpixels.trident.TridentConfig is hard-coded to use Thread.currentThread().getContextClassLoader() to load resources.  I found that by changing this to use “getClass().getClassLoader()” instead, things worked beautifully.  I’m unsusure of the full repercussions of this change; it may be that it breaks other scenarios, but I’m thinking that the context ClassLoader doesn’t work in situations like mine, where a custom ClassLoader is being used.

The next stumbling block was that, since Substance installs its own RootPaneUI and is capable of providing custom-drawn window decorations, it doesn’t play nicely with runtime LookAndFeel switching.  Allowing it to draw window decorations is practically required to get the full effect of the LAF.  Unfortunately, this means it doesn’t lend itself well to runtime LAF switching.  In fact, as best as I can tell, if you’ve previously run your application with an LAF that doesn’t provide custom window decorations (such as Windows), then try to switch to a LAF that does (such as Substance), you’ll get runtime exceptions.  For this reason, when doing a runtime LAF change, RText looks at the current LAF and the proposed one; if neither is Substance, the switch is allowed.  If both are Substance (i.e. different skins), the switch is also allowed.  But if one is a Substance skin and the other isn’t, the user is informed that the new LookAndFeel will only be installed after a restart of RText.

Once RText would finally run with a Substance skin enabled, a fourth problem emerged – custom components looked terrible.  Specifically, RText’s main window has a title panel for its “docked windows,” and a custom tabbed pane UI for painting tabs, and these didn’t look too hot.  I dug into the Substance API and found some calls you could make into the currently active SubstanceSkin, that seemed to provide some good colors for custom components.  Things still aren’t perfect in this area, but it looks a lot better than it did previously.

So here’s a screenshot of how things currently look with the Substance “Graphite Glass” skin:

RText with Graphite Glass skin

RText with Graphite Glass skin

Overall I don’t think it’s so bad.  The editor colors could use some work, but otherwise I think things are okay.  And here’s how things look with the “Moderate” skin:

RText with Moderate skin

RText with Moderate skin

The tabs at the bottom are a little dark and bleh, so some work to do there too.

There are other issues as well.  Substance is really sort of an all-or-nothing LookAndFeel.  It’s tough to have an application (like RText) where you can runtime switch to and from Substance and another LookAndFeel like Windows or Nimbus; if you’re going to use Substance and no other LAF though, it should be fine.  One example being custom table/list renderers.  Substance has a fade in/out effect for armed elements in these components, however, if you use any custom renderers extending Default(List|Tree)CellRenderer, the effect is lost.  This is because this effect is only available if your custom renderers extend DefaultSubstance*CellRenderer, not plain ol’ Default*CellRenderer.  Unfortunately, this is simply not possible in applications like RText, where Substance isn’t on the build path.