Archive for the ‘RText’ Category

RText 2.0.3 Released

Saturday, May 5th, 2012

RText 2.0.3 was just released on SourceForge!  It’s based off of the recent 2.0.3 release of RSyntaxTextArea.  Here’s what’s new:

  • Added code folding for several languages, including C, C++, Java, Perl, XML, Groovy, C#, JavaScript, MXML, CSS and LaTeX.
  • Dockable window panels are now collapsible, allowing you to allot more screen real estate to the editors when necessary.
  • Added LaTeX syntax highlighting and code folding.
  • Added DTD syntax highlighting.
  • Added “Go to Member” shortcut (Ctrl+Shift+O) similar to Eclipse. Currently only for Java, JavaScript, and XML.
  • The Source Browser’s tree view of source code is now sortable.
  • License changed to modified BSD from GPL.  This allows folks to use pieces of RText without making their entire application GPL.

In short: code folding, more languages supported, and more liberal license.

Unfortunately, my MacBook is on the fritz, so I can’t create a Mac app bundle at the moment.  As soon as I can get this resolved, a Mac bundle will get uploaded to SourceForge.  Until then, folks on OS X can use the *nix bundle if necessary (it’s just a gzipped install).

RSyntaxTextArea & RText updated in Maven

Thursday, April 19th, 2012

Just a quick note that a user has kindly updated the RSyntaxTextArea and RText artifacts available in Maven:

http://search.maven.org/#search|ga|1|g%3A%22com.fifesoft%22%20OR%20g%3A%22com.fifesoft.rtext%22

As usual, please report any issues in the forums.

RText 2.0.0-beta2 Released

Sunday, January 15th, 2012

RText 2.0.0-beta2 was just released on SourceForge!  Why wasn’t there a “beta 1″?  Well, this release includes RSTA 2.0-beta2, and I wanted to keep their version numbers in sync, so there was no beta 1.  RText is an example of a full-featured application that takes advantage of everything RSyntaxTextArea has to offer.  Keep in mind though that this release is built on top of a beta release of RSTA, and there may be more bugs than usual (or maybe not!).

In any case, enjoy!

RText 1.5 Released on SourceForge!

Tuesday, September 13th, 2011

I’m happy to announce that RText 1.5 was released on SourceForge earlier this week.  This release brings the following changes:

  • Added scripted macro support.  You can now write macros in either JavaScript or Groovy and assign them shortcuts, essentially creating your own custom menu item actions.  This feature really allows you to extend RText in any way imaginable!
  • Added very basic JSP code completion.  Unfortunately, I have not been able to add tld support yet, but the framework is now in place.
  • Added a “stop” button to the Tool output window like the one in the Console output window.  Now you can kill runaway tools (finally!).
  • Updated to RSyntaxTextArea/AutoComplete 1.5.2.  This improves anti-aliasing in the editor, and adds options to auto-insert closing curly braces, clear whitespace-only lines on Enter presses, and painting indent/tab lines.  All of this is configurable in the Options dialog.
  • Added “Check for Updates” menu item to Help menu.
  • Made opening a file via Find in Files dialog center the matched line vertically in the editor.

Enjoy!

Scripted Macros in next RText

Tuesday, August 23rd, 2011

In the next RText release, the old macro functionality – which recorded keystrokes in the editor component for playback – is being replaced with something much more powerful.  If you’re using Java 6 or later, you’ll be able to write scripts in Rhino or Groovy (Groovy support requires the embeddable Groovy jar to be placed on RText’s classpath), assign them shortcuts, then use them like any other action in the RText menu bar!  These scripts will run in the main RText process, and will have programmatic access to the entire application.  This truly allows you to extend RText in any way you can think of.

To create a scripted macro, choose “New Macro…” from the Macros menu:

New Macro menu item

New Macro menu item

The name of your macro must be unique among all macros, and will be the menu item text.  The description field is optional, and will display in RText’s status bar when you mouse-over the menu item.  Give the macro a keyboard shortcut (if you want to), select the scripting language you want to use, and click OK to begin creating your macro.  (Note that if you choose to use Groovy, you’ll be reminded in the dialog that the embeddable Groovy jar needs to be placed in the RText install, and RText needs to be restarted to pick it up.  Rhino works out-of-the-box with Java 6 JVM’s since it comes standard).

A script template will open in RText:

A rather large comment at the top describes the macro functionality, as well as two pre-defined variables you can use to manipulate the running RText instance:

In this file, you simply write out your macro.  As an example, below is simple Rhino script for a (very crude, and in fact mostly incorrect) word counter macro.  It counts the number of “words” in the selected text in the current editor, and displays it in a popup dialog.  Note the focus here isn’t on the actual correctness of the algorithm, but rather the overall macro structure:

Word Count Macro

Word Count Macro

Important things to take away are:

  1. Macros are run on the EDT, so you are free to call any Swing-related methods you want without wrapping them in SwingUtilities.invokeLater().
  2. It’s a good idea to wrap your macros in calls to textArea.beginAtomicEdit() and textArea.endAtomicEdit() if you will be manipulating the text in textArea.  The latter method should also be in a “finally” block, in case any unexpected exceptions are thrown.  These methods cause any action done in your macro to be remembered as a “single operation” for undo/redo purposes.  Failure to do this simply means that, if you edit the text in the text component, you may have to press Ctrl+Z multiple times to get what the macro did un-done, depending on what exactly you’re doing.  In the example above, we didn’t actually edit the text area’s contents, so beginAtomicEdit()/endAtomicEdit() weren’t strictly necessary, but I left them there for instruction.

Pretty cool, huh?  If you assigned this macro a shortcut, you can run it by simply typing said shortcut (be sure to select some text first to watch it work!).

Editing or removing macros can be easily be done in the “Macros” panel of the Options dialog.  This panel is easily accessed via the “Macros” -> “Edit Macros…” menu item.

Macros in Options dialog

Macros in Options dialog

Here you can add new macros, remove old ones, or modify existing ones (modifying either their shortcut/description, or the actual code itself).

RText 1.4.0 Released

Monday, June 13th, 2011

RText 1.4.0 has just been released on SourceForge!  Here’s what’s new this release:

  • Added Flex (MXML) syntax highlighting and source browser support.
  • Added Clojure syntax highlighting.
  • Fixed bug: the default directory for new files wasn’t persisted when modified in the Options dialog.  Thanks pmsl in the forums!
  • Added a Console plugin.  This allows you to run system commands (like a shell), as well as interact directly with the RText UI using its API via JavaScript (Rhino).
  • Improved Java code completion.
  • Updated Dutch translation (thanks Rogier), Korean translation (Kwangsub), and Traditional Chinese translation (kp200906).

Moving forward, expect to see improvements to Javascript and MXML editing, even better keyboard navigation, and (yet again) improved Java code completion (read: use less memory)!

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.