Archive for the ‘RText’ Category

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.

Perl Language Support Enhancement

Friday, October 22nd, 2010

Newly added to the Perl Language Support in RSTALanguageSupport is the ability to modify the value of the PERL5LIB environment variable used when syntax-checking source code.  This feature has already been integrated into the RText Subversion trunk:

Missing a Perl library

Missing a Perl library

Adding it via PERL5LIB

Adding it via PERL5LIB

Problem solved!

Problem solved!

As the source code in the screenshots say, you can also solve this (a more proper solution in many cases, as well) with “use lib”, but I’m trying to give as much freedom with the language support library as possible.

Syntax Highlighting in ‘Find in Files’ Dialog

Saturday, September 18th, 2010

The latest change pushed to RText’s SVN is: syntax highlighting in the “Find in Files” dialog’s search results:

Syntax Highlighted Search Results

Syntax Highlighted Search Results

This is something I’ve wanted to do forever, but just never got around to it.  While it might not help you write better code, I believe it’s the little “extra” features like this that make an application fun to work with.

RText 1.2.0 Released!

Friday, September 10th, 2010

I’m happy to announce that RText 1.2.0 was just released yesterday!

RText 1.2.0

RText 1.2.0

It’s been a long time coming, almost 6 months since the last release.  There are plenty of new goodies this time around that make it worth updating:

  1. Language support added for C, Java, Perl, PHP, HTML and shell scripting (code completion for all, varying degrees of syntax checking for others).  While no Eclipse by any means, even the simplest of code completion support takes RText to another level of usability.  This is one area that will definitely be expanded moving forward.  Note that the focus is not on code project management, but simply on being able to provide code completion to speed up editing code.
  2. A huge number of usability improvements to the editor component.
  3. Format HTML and XML code with new JTidy integration.  Formatting options are configurable in the Options dialog.
  4. Added ActionScript syntax highlighting.
  5. Added a new option to ignore the extensions “.bak”, “.old” and “.orig” when opening files and determining their type.  This comes in very handy when you’re constantly making backups for some reason, like I do.
  6. “Experimental” translucent search window (Find, Replace) support if you’re running Java 6u10 or newer.  Note that in my testing, the translucency support in the JVM only seems to be reliable starting around 6u16 or so.  This is just a visual gag to make RText seem cooler, but it’s fun nonetheless, and it does have a practical use – make the dialogs translucent when overlapping the main editor window, so you can see any code they overlap.  When and just-how translucent they are is configurable in the Options dialog.
  7. Greatly improved “File System Tree” plugin, allowing you drill down into directories, create new files and folders, etc.  This should have happened a long time ago.  In the next release you should be able to copy, rename and delete files from the tree as well.
  8. Improved performance of file chooser when browsing NFS paths on Windows.
  9. Tons of minor usability improvements.

Upgrade today and see what you think!

Very large push to RText SVN

Saturday, July 31st, 2010

For some reason I’ve been batching up changes to RText, and haven’t pushed anything into SVN in 4 months.  Well, I came to my senses, and it’s all finally there!

There will be 3 main areas focused on in the 1.2 RText release:

  1. Integrating the language support I’ve been blogging about (Java, HTML, Perl, etc.)
  2. Usability improvements
  3. Bug fixes

The first item is already practically done.  I’ve integrated RSTALanguageSupport via a plugin.  I’ve still got a couple more ideas for the latter two items before 1.2 is good to go.

Integrating Language Support into RText

Saturday, May 22nd, 2010

I’ve spent the last week or so doing tedious, but important, stuff – making sure the RSTALangaugeSupport API is robust enough to be used in other applications.  The hard work is starting to pay off: Perl support is almost completely integrated already!

Perl options in RText

Perl options in RText

Here’s RText’s Options dialog, showing all the features related to Perl support that you can currently toggle.  As you can see, you can currently fiddle with both the code completion as well as the on-the-fly syntax checking I recently blogged about.  For the latter, you have to have a Perl install somewhere on your machine.  RText will scan your PATH for a Perl install, and default to using that, but you can change it to another installation if you want.  Still pending is the ability to add modules to the @INC path.

Language support will be fully integrated into all aspects of RText.  For example, compile errors and warnings will show up in the Error Strip component:

Compiler errors in Error Strip

Compiler errors in Error Strip

Also, function descriptions are displayed simply by hovering the mouse over them.  For example, below, my mouse is over the “print” function (sorry screen captures in Windows don’t capture the mouse pointer):

Function descriptions on mouse hover

Function descriptions on mouse hover

Perl is one of the harder languages to integrate, simply because its language support has so many features (runtime compilation, etc.) that others don’t have.  Hopefully other language supports will be integrated into RText shortly.  Stay tuned!

RText 1.1.0 Released!

Tuesday, March 16th, 2010

Hot on the heels of the latest release of RSTA comes a new release of RText.  This time around we have both new features as well as bug fixes and “platform” enhancements (too bad nobody uses the platform except RText!).

The coolest new feature is “Tool support.”  You can now set up “external tools” (e.g. other programs on your system and run them from inside RText.  This allows you to more easily integrate with compilers, tools such as Ant, or any other program you use regularly while programming.  You can even assign keyboard shortcuts to tools, to allow for easy execution.

Adding a New Tool

Below are example screenshots showing a simple Java program being executed within RText:

Selecting a Tool to run

Running a compiled Java class

Task support has been enhanced as well.  In 1.0, any time “TODO” or “FIXME” was found in a code comment, it was assumed to be a task.  Now, users can define what tokens constitute a task themselves.  This allows you to tailor RText to handle your own personal little programming quirks.

Adding a new Task Identifier

All of the enhancements previously blogged about for RSTA also show up in RText 1.1.  This means nice little things such as improved keyboard navigation, and better font selection out-of-the-box on OS X.

Finally, as always, lots of little bugs were squashed and tiny usability enhancements made.  Again, most enhancements these days comes from suggestions from users, so speak up if there’s something you’d like to see in RText or RSyntaxTextArea!  A good place to be heard is over in the forums.

So give this release a shot and see what you think!  The next release will likely sport the currently-vaporware code completion I’ve been working on for a few languages, so stay tuned…

Yet more Improvements to RSyntaxTextArea

Sunday, January 10th, 2010

Happy New Year!  After a nice long break, it’s time to get the ball rolling on the Fifesoft projects again!

First, some low-lying fruit has been picked for RSTA.  You can now toggle whether end-of-line markers are rendered at the end of each line.  This can be useful for things such as seeing extra whitespace at the end of lines.  Here’s a preview of this feature being used in RText, where it is already integrated in SVN:

EOL Markers in RSyntaxTextArea

EOL Markers in RSyntaxTextArea

Also, and perhaps more importantly, there have been improvements in RSTA’s keyboard navigation.  Ctrl+left/right arrow have always skipped words, but until now, it’s used Java’s default “word skip” behavior (e.g. BreakIterator.getWordInstance()).  This isn’t really optimal for skipping “words” in source code, so this functionality has been revamped to behave like Eclipse does.  The only difference is that the caret does not stop at capital letters in camelCaseIdentifiers.  I despise this behavior, and I don’t know why the Eclipse devs think it’s a good idea.  Besides this, double-clicking on a word does a better “select word” for source code than before.  These are little things that make a big usability difference.

Finally, external tool support is being added into RText.  This will allow you to run things such as Ant, compilers, or whatever else from directly inside RText.  Nothing really to show at the moment though, just the framework has been put in.

RText 1.0.0 Released!

Saturday, December 5th, 2009

It’s been a very long time coming, but RText 1.0 has finally been released!  Since it’s been production quality for awhile now (I’ve used it at work, across multiple OS’s, for years now), I decided to give it the credit it deserves.

Cool stuff in the 1.0 release include:

  • Cleaned up the main window – removed some unnecessary borders around components (Swing is bad at that sort of thing), and modernized the appearance of “dockable windows” (the windows the plugins live in).
  • Updated to the latest RSyntaxTextArea release.  This brings highlighting support for Scala, Delphi and BBCode, auto-insertion of closing curly braces in C-style languages, auto-completion of closing tags in XML, and a default color scheme that’s easier on the eyes for markup languages.
  • A spell checker was added.  It uses Jazzy and supports American and British English out-of-the-box.  Spelling errors are squiggle-underlined, and a focusable tool tip allows the user to correct the spelling error, add the word to a user dictionary, or ignore the word (just like in Eclipse).  I’m particularly proud of this new feature.
  • An optional “Tasks” window displays all instances of “TODO” and “FIXME” in your code comments for all opened files, like in Eclipse.
  • The file chooser now lets you open files in the system default viewer or editor via RMB -> Open In… -> System Viewer/Editor.  This feature requires Java 6.
  • Improved the “Split Window” view.  While the default is the Tabbed View, “Split Window” is probably the second-most popular view in RText.  The file list is now a real “dockable window” so it integrates into the rest of the UI like it’s supposed to now.  It also now has a context menu for the files in it (save, close, file properties, etc.).
  • Big code reorganization that doesn’t really show in the application itself, but hopefully makes the source a little better organized.

There’s plenty to do for 1.1, not the least of which is to bring some of the localizations back up to date (they really fell behind with this release).  I also plan to add “External Tool” support – assign a keyboard shortcut to your favorite application!

Give it a try and see what you think!  Feedback, criticism, and everything else is welcome in the forums.

Breadcrumb Bar Nearly Done

Sunday, October 4th, 2009

The breadcrumb bar I blogged about earlier is nearly done.  I managed to mimic the behavior seen in Vista’s breadcrumb bars, clicking outside of the “button” area turns the breadcrumb bar into a text field for manually typing a file path.  Even better, it offers suggestions as you type!  Here’s how it’s looking in RText’s file chooser dialog:

Using the Breadcrumb Bar

Using the Breadcrumb Bar

Morphing into text field with autocomplete

Morphing into text field with autocomplete

This is much more powerful than the combo box with the directory hierarchy that was there previously.  Note that if too many folders are in a directory to be listed in a single menu, there are arrows at the top and bottom of the menu, allowing you to scroll through the entire list.  The menu also responds to the scroll wheel on the mouse.  I’ve seen this behavior on OS X, on a Macbook where screen space is limited (or you just don’t want a menu to get too long).

This component should honor RTL locales, as well as look good in all LookAndFeels (tested in all the standard ones, including Nimbus, which, as always, took a little work to get looking good).  As always, check it out from RText’s Subversion repository if you want to see how it is implemented.