Re: [stellation-res] VSF Editor

["Jonathan Gossage" <jonathan@xxxxxxxxxxxxxx>]

----- Original Message -----
From: "Jim Wright - IBM Research" <jwright@xxxxxxxxxxxxxx>
To: <stellation-res@xxxxxxxxxxxxxxx>
Cc: "Stellation" <stellation-res@xxxxxxxxxxxxxxx>
Sent: Thursday, December 05, 2002 10:13 AM
Subject: Re: [stellation-res] VSF Editor


> At 08:56 AM 12/5/2002, Jonathan Gossage wrote:
> >I was looking at the VSF editor last night and I was wondering whether it
> >might make sense to use the JDT Java editor as the starting point. There
> >seems to a lot of functionality in the Java Editor that we will need and
> >will have to implement for ourselves.
>
> Hi Jonathan,
>
> The JFace and JDT editors would probably be a great starting point -
> there's a lot of good design and functionality there.  If I'd understood
> the editor frameworks better when I started, the VSF editor concept demo
> would look a lot different internally (so a rewrite is needed, no
problem).
> The next VSF editor rev (hopefully a solid tool rather than just a demo)
> will use a _lot_ more of the Eclipse frameworks.

The reason I think you want access to most or all of the java editor
technology is that one of the things you are going to want to do is provide
the syntax checking, problem reporting and correction, incremental
compilation etc. that are provided by the standard environment in addition
to all the fragment related enhancements that Stellation will offer. This
means being able to deal with standard things like CompilationUnits and
dynamically building VSF's from standard JavaElements etc.

>
> Several probably-obvious points:
> * You should probably start by extending the JFace text editor.
>     The JDT Java editor is built on top of the JFact text editor
framework;
>     the Java editor is a _lot_ more complicated.  For the VSF editor,
>     I started with a basic JFace text editor, studied the JDT editor to
see
>     how the JFace edit framework actually worked, and then borrowed
>     selected bits from the Java editor.

Ideally I would have liked to simply extend the Java editor, but
unfortunately extension points are few and far between in the Java editor
itself. In particular, there is no clean way to be able extend th management
of ditor input and output. One of my objectives is to allw strings to show
on the screen and be editable by programmers and have the code that is saved
and compiled use code to access the correct string variant. This means
transforming the code on input and output and the current editor is not well
adpated to that purpose/
>
> * Do a small pilot first; given the current state of Eclipse docs, that's
the
>    best way to get a feel for how the various interfaces and components
>    fit together.
>
> * Be aware that the names given to various Eclipse classes / interfaces
>    are often misleading.  org.eclipse.jface.text.Position is a good
example:
>    I assumed it marked a point location within an editor buffer: it really
>    specifies a span/range/subsequence of contiguous characters
>    (since Positions have both offset and length).  A Position is very
similar
>    to an IMarker (which can also have a length); in fact, Positions are
pretty
>    much the transient editor-buffer equivalents of IMarkers: Positions are
> updated
>    dynamically with every edit buffer change, while IMarkers are only
updated
>    when a MarkerUpdater is run, e.g. when the buffer contents are saved to
the
>    underlying document.  But I digress....
>
> If you decide to go this route, I could write up more details on what I
> know about
> the editor frameworks, and would be interested in whatever you learn along
> the way.
> Time permitting, I'm hoping to do an article on the next rev of the VSF
> editor and
> how to leverage the text editor frameworks -- but I need to learn a fair
> bit more first!

What I have leared so far is that some areas of the editor are not well
fitted to supporting advanced development concepts. Ideally I would like to
work with an editor that used an AST as the primary representaion and
persistence mechanism and then allowed a variety of rendering methods for
screen presentation and export to other tools.
>
> -----------------
>
> On another topic -- re: the intenationalization work in general, I've been
> wondering if you
> can join forces with other Eclipse folks working in this area.  A number
of
> people outside
> Stellation are concerned about this area (e.g. Peter Manahan), and maybe
> you could
> get them involved somehow (or benefit from any work they may have done).
> (Admittedly, I haven't looked into this, and am pretty ignorant about the
> whole topic --
> I may be totally off base here).

It looks as if most of the work these folks are doing is dealing with the
internationalization of the help files which is a different problem from the
one I am trying to address.
>
> Here is one possibly-relevant thread:
> http://dev.eclipse.org/mhonarc/lists/platform-help-dev/msg00132.html
>
> Regards,
> Jim
>
>

Regards

Jonathan

Personal Email
jgossage@xxxxxxxx

Business Email
jonathan@xxxxxxxxxxxxxx