This Christmas I bought an iPod Nano for Elyn and ran into a lot
of software ugliness.

First, her computer runs Windows 98, and, apparently, cannot be
upgraded to some more recent version of Windows. That sucks, but is
apparently unfixable. Naturally, iTunes doesn’t support 98. Some
sites on the web suggest that, perhaps, you can apply some hacks,
attach an iPod to the machine and use some software to copy music over
— but even then iTunes won’t work.

Of course there isn’t a Linux port of iTunes (too bad for us it
isn’t written in Java…).

I tried both Wine and CrossOver Office — the latter
can actually run iTunes, but unfortunately still does not support
connecting it to your iPod. It might be possible to do what I want
with some combination of iTunes, a program to remove the DRM from the
downloaded songs, and some Linux-based iPod program like gtkpod… but
this seems awful, even assuming it would work.

So, upgrading Elyn’s machine to Linux (if it is even possible)
wouldn’t help. The lack of TurboTax would also be a problem — they
have an online version but, from what I’ve read, it isn’t as
featureful. The Linux worlds needs to make inroads with ISVs in order
to get users like Elyn; I really couldn’t recommend Linux to her
today.

At this point it looks like buying a new machine is the only
answer. I hate computers.

There’s been a fair amount of activity in the open source video
editing space lately, and unfortunately not nearly enough on medi8 (in fact we haven’t even updated
our web site so there is nothing to see there, aside from the
source).

Instead of going through the other projects I thought I’d finally
post my reasons for writing medi8 as an Eclipse plugin. I think at
first blush this seems like a strange idea — certainly I’ve gotten
negative reactions from a few people I’ve talked to about it.
However, really, it makes a lot of sense, as I will try to show; and
not
everybody disagrees (I seem to be following Doug Schaefer around a
little lately. And likewise I sometimes feel that Per has been
everyplace interesting about 3 years ahead of me…).

Note that in particular we’re writing Eclipse IDE plugins, and not
an RCP application. For RCP the choice is mostly about technology:
what is the simplest way to get an application up and running? What
framework provides the platform support and ease of development that
you need? Etc. But, that’s not what we’re talking about here.

The basic observation is that editing a movie has a lot in common
with developing a program. It can be a large project, taking many
months and involving many people (back when I was seriously working on
my free software movie, on Vicki’s advice I planned to take 6 months
off work in order to edit). A “real” movie can involve a large number
of parts, some of which could be custom software (e.g., a custom
titling plugin to make cool credits); data management is a serious
issue; etc.

Once you draw this parallel the reasons for developing Eclipse
plugins become more clear. Using Eclipse as a framework gives us
many things for free.

We don’t have to worry about project structuring or management,
Eclipse has this. Likewise for file management, and Eclipse even
provides features that, were we to write a video editor from scratch,
we would not include — e.g., the option of integrated source control
(I saw a feature request for CVS support in Kino, and felt
vindicated). Eclipse also has infrastructure for help, for
manipulation of editors and views, for task management (to-do lists,
markers, and errors), and builders.

Really all we need to concentrate on is the mechanics of movie
editing, how our model works, and things like that. We don’t spend
any time writing the same application infrastructure that has been
written so many times before.

Of course this isn’t without drawbacks. Eclipse’s GUI tends
toward the cluttered and it could benefit greatly from a UI
designer (I’m not very concerned about this, though; cleanups are
inevitable). There’s also the possibility that Eclipse will somehow
be incompatible with what we want to deliver; but the evidence is that
this is merely a theoretical worry.

The overall vision for this tool is pretty straightforward: a
full-featured sound and video editor built as a set of Eclipse
plugins. Part of the big goal is using Eclipse as a framework to
unify all the parts of film editing; so for instance I picture being
able to build effects plugins of various kinds as Eclipse projects
themselves, and have the final film project depend on the effects
written for it.

My memories of the original Aeon Flux are, perhaps appropriately,
fragmentary. Back in the day I didn’t get MTV and in the end I think
I only saw two episodes all the way through. (Remember when MTV was
interesting?) In any case, I remember liking what I saw, so I was
looking forward to the film, although with some caution. After
hearing a bit about it, I entered the theater expecting only
disappointment.

The film itself is an unusual mix. It definitely has its bad
points, which I feel compelled to enumerate. Some of the dialog is
laughable. Stylistically it seems like it can’t decide between a
certain kind of Star Trekian futurism (people in subtly matching
outfits walking easily through crowded outdoor markets), smooth
concrete abstractionism (Flux’s apartment, seemingly located in a
scrubbed out sewer), something more baroque (the library, the
Relical), or something hyper-realistic (close-ups lit to show skin
texture, the unusual posters of the dictator).

Likewise it can’t decide what kind of an action film it wants to
be. The cutting is very choppy and the action scenes are consequently
difficult to follow. At times the settings seem to indicate a more
visually ambitious film is buried in the sub-liminal — the locations
chosen generally impressed me.

Despite its flaws this film did capture elements of the original.
The world is mysterious, post-Picardian Kafka (nicely captured in the
phrase “industrial virus”). The technology is alien and magical and
as viewers we often do not know whether some gadget is taken for
granted in this world where any object can have the function of any
other, where form and function are completely divorced. Perhaps we
are viewing ordinary things. Or perhaps Flux knows as little as we.

It brings to mind the Codex Seraphinianus, which in its own world
is most likely a perfectly ordinary book, no more exotic than an issue
of National Geographic.

The ending was a mild let-down, as were the moments when the film
devolved to mere action and the typical tropes of the genre.

I enjoyed this film quite a bit more than I expected to. In an
artistic sense I found it inspiring, similar to the way that reading a
story by Delany invariably makes me want to write.

I’ve been spending a lot of time thinking about C and C++
development lately. In particular I’ve been thinking along the lines
of, “how can we make C++ development as easy as Java development?”.
This turns out to touch a lot of different things, and I’m going to
blog more fully about it later. Today I just wanted to share some
thought about one particular problem: building gcjx.

I wrote about this earlier, noting
the incredible performance difference between g++ and jikes.
Today I went a little bit deeper and built gcjx with the
-ftime-report flag. Then I wrote a little perl script to
summarize the results (I’m only showing the top 4 here, the rest are
all 3% or less):

I think the underlying problem here is that each compilation of a
gcjx source file re-scans many of the gcjx headers and also a fair
chunk of libstdc++, which hugely inflates the amount of
work done. For instance, mangle.cc is a mere 386 lines
of code, but run it through cpp and out comes a whopping 51,997 lines.
Like most sane programs, gcjx doesn’t play odd cpp tricks like
including files multiple times; so much of this work is simply
redundant.

The fix here is to move away from purely textual preprocessing and
move to a more sophisticated model, one that eliminates redundant
work. This is actually not as hard as you might first believe. For
the most part it is an application of better data structures to the
problem, coupled with the observation that, since typically header
files do not interfere with each other via macro tricks, you can gain
efficiency by caching lookup contexts during preprocessing. Perhaps I
ought to write this up more fully; that is pretty sketchy.

I know of two attempts at this already. One is the gcc
compiler server branch. Unfortunately this project seems to have
been canceled by Apple, as there has not been progress on it in quite
some time. There was little documentation for this project and, I
think, nobody outside Apple really understood what it was about back
when it was active.

The other project in this area is Doug Schaefer’s PDOM work in
the Eclipse CDT. Unfortunately this is for indexing only — as far as
I know there is no code generation planned. (Remedying this is one of
my major prescriptions for improving C++ tools… but you have to wait
for the bigger entry on this topic.)

Last week I got gcjx to successfully parse and analyze the
Classpath generics branch. I only needed a couple of hacks to get
there :-). More recently I fixed some of the remaining problems with
1.5 code generation — I added code to generate bridge methods and
handle enum-typed switches. Now I’m going to switch back to the tree
back end, with an eye toward merging gcjx to the trunk.

I’m going to go out of order a bit here and describe two different
NetBeans talks together, though they happened on different days. Then
I’ll use this as a place to discuss some interesting NetBeans-related
conversations and explorations.

Charlie Hunt gave a talk titled, “NetBeans: Pushing Java
Productivity”. (There’s that word again.) This talk was a run
through of all the new NetBeans features and some future plans. Tim
Boudreau gave a talk about Matisse and other things — this talk was
largely demos of some of the new things. I freely intermix stuff the
two of them said here.

The new NetBeans release includes Matisse (a Swing GUI builder),
new editor features for productivity, newly rewritten CVS support (no
SVN yet, but planned for the near future). There is now support for
JSF, Struts, and JBoss in the IDE — Eclipse probably lags a bit here.

This revision of NetBeans looks a lot like Eclipse. Astoundingly
so in some cases, for instance the editor window has a small vertical
pane on the right which represents errors and warnings, exactly the
way Eclipse does. I wondered whether NetBeans was copying Eclipse, or
whether both of the are copying some standard-but-unknown-to-me IDE
approach.

Bad News

First the bad news for NetBeans. In some important ways Eclipse
remains superior. NetBeans does not have an integrated compiler.
Instead it invokes ant. It does parse and understand a Java source
file when you open it — but this means that, unless you do a full
compilation, you won’t have a global view of all the errors in your
project. When you go to run your project, NetBeans does a real
compilation. Contrast this with Eclipse, where it compiles in the
background, has global knowledge of your program (and can do things
like mark up the project view to show which files have errors in them
— before the file is opened), and where running a test case doesn’t
mean that you have to wait for a rebuild. This is core stuff,
directly impacting your workflow, and Eclipse is just better.

I’m told a future NetBeans will integrate with the compiler better
(there is some JSR for the compiler API. This stuff scares me given
what it would imply for gcjx…).

Eclipse’s CVS support also looked better offhand, but I didn’t
play with NetBeans’ myself.

Tim and I had a long talk about Classpath, NetBeans, Eclipse,
Swing, and SWT. While I’m not really a fan of SWT’s implementation,
the simple fact is that it is open source and readily runnable with
gcj. On the other hand Swing requires a major development effort,
which we’re still undertaking. And while we definitely plan to be
able to run NetBeans, we’re not there yet. And in short — feature
comparisons aside (features are in constant flux anyway) — this is
why I’m an Eclipse user and promoter.

I think it would be perfectly fine — cool, even — to set up
Classpath and friends to build with NetBeans the same way I set them
up to build with Eclipse. I gave a quick try to this at the airport,
using a NetBeans CD conveniently handed out at the conference, but ran
aground on a quirk (NetBeans doesn’t like your source to appear in
. — which is where Classpath puts it). Bummer! (I
found a number of other oddities too, like the lack of a “Save As”
action — maybe I’ll be spending some quality time with their bugzilla
soon.

Also it strikes me that in some ways Emacs is still the state of
the art. For instance people gush endlessly about the “new” Mozilla
search “non-dialog” — umm, that is Emacs isearch. So, now NetBeans
has abbrevs… yay, color me unenthused that the IDEs are catching up
on basic editing skills. Ahh, I’m being excessively snarky.

Matisse

The bad news is pretty bad. However, the good news is also pretty
damn good. In fact the good things in NetBeans are just amazingly
awesome.

By which I mean, Matisse gives a really awesome demo. Matisse is
a Swing GUI builder that plugs in to NetBeans. It purports to let you
build cross-platform applications correctly. It comes with a new
layout manager called GroupLayout (which, it is claimed,
is open source, but I have not verified this) which handles all the
details, for instance this is where information about
platform-specific spacing differences is kept. It also has some nice
tricks like aligning font baselines even across different widget
types.

Matisse tries hard to make it easy to build sensible GUIs, but
doesn’t actually force you to. For instance, in the demo, as Tim
dragged UI elements around, guidelines would appear showing suggested
drop points. This kind of thing is very handy, he was able to create
new composite widgets with proper spacing and proper resize behavior
in just a couple of minutes.

I still think that Swing kind of looks like crap on Linux. It
should be indistinguishable from any other application, and
unfortunately that is not the case yet. This is something that
Classpath can, and should, solve.

Fun quote: “you can’t spend an hour on Matisse”. Meaning, it is
too easy to use to take up that much time.

Sharing

On stage Tim demoed something that I thought was really cool and
revolutionary. NetBeans has a built-in IM client, and Tim was talking
to a co-developer in the Czech Republic. Tim chose “share this
project” and, over IM, the code was transferred to his colleague, who
then proceeded to edit it — and the changes showed up instantly in
Tim’s workspace.

This is so damn cool. I’ve been wanting something like this for
quite a while… not every change is worth sending to version control,
and sometimes you really want to use the pair-programming style.
(Also it would be super great to be able to share a debug session, but
I don’t know if NetBeans can do that yet.) Anyway I’ve thought about
having this in Eclipse, but NetBeans is actually already there.
Amazing.

Currently you need an account on share.java.net to get this
functionality. That seems smart for them, in a building-a-portal way
— and sourceforge or savannah should offer IM service like this. In
combination with the Eclipse Mylar plugin this would be quite cool;
for instance open a project and be available for talking with other
developers from that project. They plan to look at a jxta-based
implementation soon, meaning the sharing could really be P2P. I think
this would be friendlier for users.

Eclipse is working on similar functionality as part of the ECF project. This is now
definitely on my must-examine list, not only for shared hacking on
Classpath, but also for integration with Medi8. Shared movie editing
seems like a cool idea.

Other NetBeans stuff

My notes say that Charlie’s talk was full of unsubtle anti-Eclipse
jabs. Which it was. Come on guys, rise above.

NetBeans has an ant debugger (nice idea, didn’t see a demo). It
has a PDE-like thing for writing NetBeans plugins (the demo here was
about the same as Bob’s, making me suspect that they both chose the
only easy thing). You can make rich client applications using the
NetBeans base (does Gnome have this yet? I think these days I would
probably pick Eclipse RCP as the base for a traditional-style
application). NetBeans makes it really easy to download and install
the latest LookingGlass. It seems to me that we could do this for all
of Fedora, by providing a way to say “I want package X”, and then
fetch the SRPM and turn it into an Eclipse project. Well, except for
the fact that most SRPMs are probably not really suitable for hacking
inside today’s Eclipse 🙁

You can set background wallpaper in NetBeans. This is useless but
they did ask, “Can Eclipse do this?”. Seriously, come on guys.

By the way, LookingGlass gives a really nice demo. Things whirl
and slide around, and pulse organically. But does it help my
productivity? Or just make me reach for the motion sickness pills?

Tim hinted at scriptable refactoring coming in NetBeans. Hmm,
sounds like something I wanted.

There is a J2ME plugin for NetBeans that allows debugging on the
actual device you are using — they’ve found the device emulators to
be somewhat flaky and so debugging on a live device is more useful.
This sounds pretty hand for folks in the J2ME space. Maybe I
misunderstood this though, since Michael Koch tells me that not many
devices actually support this.