Being
developer of the WYSIWYG editor using GEF I want to say
that GEF needs to be more tweakable:
- Rulers as they are now are designed
to be used in the class diagram. They must be more customizable. I’ve
had to fork the ruler implementation to make it start not from the
top-left corner. Zero mark is not necessarily at the ruler start. I also
needed another figure (i.e. composite, like in MS Word).
- I guess it would be worthy to
provide some “mapping modes” like in windows – for metric,
English, so on. Rulers must be able to work in different units.
Eugene
-----Original
Message-----
From: gef-dev-admin@xxxxxxxxxxx
[mailto:gef-dev-admin@xxxxxxxxxxx] On Behalf
Of Randy Hudson
Sent: Monday,
June 28, 2004
8:17
PM
To: gef-dev@xxxxxxxxxxx
Subject: Re: [gef-dev] GEF feature
requests
Someone recently contacted me with a similar idea. The
idea was to create Content Providers like JFace has for trees/tables, but
instead for a specific graphical type of content such as a class diagram. Maybe
this person is on the mailing list and will detail his group's intentions.
This
is probably a good idea and a natural area for GEF to extend into. But,
as far as fixed content types/UIs, we've had some experience with this in the
Palette. The palette is a graphical viewer with a predefined structure
and appearance. But currently you can not really extend the palette using
public API. So maybe the palette can eventually serve as a proof of
concept for this idea.
I
think what we need are more detailed proposals. For example, the actual
API of ClassDiagramContentProvider and its dependencies, and how the client
would customize things like which figure is used to render the class, how
commands are created, etc. In some ways, having a single provider object
goes agains the way GEF is set up. You'll end up with one big class which
needs to know everything about the application. Instead, a more
appropriate approach might be to keep the editparts more invovled. Perhaps
create some new EditPart implementations which are more tightly coupled with a
specific UI element like "class" or "activity".
Thanks
for the suggestion and details design documents are definitely welcome,
Randy
Hudson
|
|
"Cameron Bateman"
<cbateman@xxxxxxx>
Sent
by: gef-dev-admin@xxxxxxxxxxx
06/28/2004 12:19 PM
Please
respond to gef-dev
|
To: <gef-dev@xxxxxxxxxxx>
cc:
Subject: [gef-dev] GEF
feature requests
|
Feature
request:
How about some default implementations of various
regularly used classes and application patterns? When I started using GEF
I found it took *way too much* time to develop a simple application that did
anything useful. I understand that keeping everything highly de-coupled
is an important design goal for GEF, but at the same time it makes it very hard
to design new apps.
In terms of default classes I'm thinking
particularly of the way Swing JTable's are designed. When you first
create a JTable you can specify a DefaultTableModel to get you up and running
until you understand how they work. Once you have that figured out, you
can go and re-factor, replacing DefaultTableModel with AbstractTableModel (its
parent class so most typesafety is also preserved) and implement your model
properly.
Regards,
Cameron
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/gef-dev
