Need something in SWT?

2. January, 2011

When the guys at SWT can’t be bothered, there is now an alternative: A little project to create drop in replacements for stuff that you want in SWT. Check it out here.

In the same place, you can find a slightly modified version of StyledText. When I say “slightly modified”, then I mean “at the API level”. I’m currently heavily refactoring the code inside to make it maintainable and more easily extendable.

Some achievements from the latest hacking session:

  • It’s now possible to write tests that verify the rendering of StyledText
  • Bullets are managed and rendered in their own special classes. Same goes for StyleRanges. That reduced the size from 1’700 lines to just about 1’100 lines – not that much but a good start. This also means I can write tests that just check the management of StyleRanges – without bothering with a main loop, resource management, etc.
  • There are a bunch of helper methods to debug the model behind your text. They can dump the text in readable form.

What’s next? I’m really starting to think about turning StyleRange and TextStyle into independent classes. Right now, the former inherits from the latter which means there is some really ugly code when it comes to reusing styles, merging styles, font handling, etc. One effect is that the current implementation violates the contract of equals() and hashCode(): equals() takes the range into account while hashCode() doesn’t. While that may not have an effect (StyleRanges with the same style just pile up in a hash map), it’s still a sign of a skewed API.

The API would be much more clean if there was a style manager (which you could dispose to free all fonts, colors, etc, at once) and when StyleRanges were just tiny classes that contain a range and a pointer to a style. That would allow to get rid of the ranges int array, we could use Set and List to manage style ranges, etc.

Something that I’ve been testing is hierarchical styles (i.e. styles that inherit from other styles). Works like in word processors where you define a basic style and then derive from that. I’m not happy with the performance right now but I’ve got some ideas.

How to use my version? Simple: Clone the StyledText project and install it. Check the POM to see which dependencies you need in your project. Now replace

import org.eclipse.swt.custom.*;

with

import de.pdark.styledtext.*;

That’s it.


Uploaded first snapshot of ePen 0.9

15. May, 2010

I’ve just uploaded the first snapshot of the 0.9 prerelease on Sourceforge. Changes since 0.8:

  • Make text links in translations work
  • HTML: Use outline title in changelog
  • HTML layout. Index section in scene files needs some distance from the window border
  • Remember the editing position and open the same file with the cursor at the same place when the project is opened again
  • Editor for feedback page
  • HTML: Scroll mini-toc to the current scene
  • Going back and forward in the editing history will now scroll the text and place the cursor where it has been.

You can find it in the download area of the project.


ePen 0.8.0 released

6. May, 2010

I’ve just uploaded the ePen 0.8.0 release on SourceForge.net. You can find it in the download area of the project.

To install, follow the instructions in the README.txt (either in the archive or in the download area).

To get an idea what the software can do, see my story “Haul” (auch in Deutsch verfügbar).


ePen 0.8 status update

8. February, 2010

Followup to my last ePen post: All but the first point are resolved. You can open an existing project by specifying the path on the command line but that’s too tedious for something which is supposed to be simple. Since I want to give a good first impression, I want this fixed before I release 0.8.

For spell checking, I’ve switched to jazzy which is more simple to use than JaSpell. You can find the repository with my fork here: http://epen.hg.sourceforge.net/hgweb/epen/jazzy/. Unfortunately, just invoking the spell checker for every key press is too slow, so I had to disable the code for the time being. I’ll resolve this with ePen 0.9 where I hope to fix some other issues with the editor as well.

[EDIT] The project home page is at http://sourceforge.net/projects/epen/


ePen 0.7 Status Update

9. January, 2010

I’ve pushed the code for ePen into a new set of Mercurial repositories: signal (a signal/event handling library, new BSD license), JaSpell (fork of the project jaspell.sourceforge.net; mainly a port to Java 5 and Maven 2, BSD-License) and ePen (the main editor, Eclipse Public License 1.0 since I had to copy code from the Eclipse code base).

The editor is pretty usable and I hope to wrap up 0.8 next week which should fix the following issues:

  1. Create new projects and open existing ones. The main problem here is that an ePen project is a directory and SWT doesn’t offer very good dialogs to select directories. Right now, the editor will create a demo project when you start it the first time.
  2. The translation mode is too slow
  3. Editing is sluggish.
  4. HTML export should support filtering by state (to allow to export only “final” scenes).
  5. Setting up the development environment is too complex. Especially the part where you need to copy the Eclipse plugins into the Maven repository. 0.8 will come as one huge JAR which you can start with a double click.

After that, I plan to resume work on my story “Haul” and post the first scenes in my old, desolate Philmann Dark site.


ePen 0.7

31. December, 2009

I’ve started to work on ePen again. This time, I’m using Java and SWT/JFace. Python Traits was nice but too slow for my purpose, especially the editor.

This is the main window. As you can see, there is an outline with all characters, places, items, wiki pages and books (with chapters and scenes). The whole thing is meant to save all the information in one place so you can easily find and use them.

Do you see all those nice links? The editor will create them for you from names of characters and other things. If you click on them, you’ll jump right to the meat. I’m thinking of a hover mode where you get a summary but there is a bug somewhere.

The other feature is: No save button. The editor will save your work as you type. If it crashes or your whole computer crashes or there is a power failure? No sweat. Worked for an hour and forgot to save? Won’t happen again. I’m still working on automated backups plus a client/server mode so you can have automatic off-site backups, too.

Right now, I’m shaving off a few rough edges. Then, I’ll drop it on sourceforge.

[EDIT] The project home page is at http://sourceforge.net/projects/epen/


ePen

19. June, 2008

After a long time, I’m starting a new OSS project called “ePen“. From the description:

ePen – A cross platform tool for creative writers and book authors. ePen is able to manage all information around a book project: The actual text, descriptions of the characters and scenes, the storyline.

ePen should become for authors what a pen was for centuries: A simple tool to convert ideas into amazing, breathtaking stories.

Right now, ePen is in the planning stage even though I’ll commit a prototype this weekend. The first thing on the agenda is to decide how to implement the tool. The prototype was done in Python and PyQt and while it was a nice experience, the text editor leaves a lot to be desired (read: it sucks). I’ve collected my thoughts in this wiki.

I’ve also create a Google Group for discussions.


%d bloggers like this: