Re: [gef-dev] GEF feature requests

["Ian Bull" <ian@xxxxxxxxxxx>]

Thanks for pointing out this e-mail Randy.

 

As part of my PhD I have been looking at creating some standard Widgets built using GEF conforming to JFace conventions.  This way, if you want a "quick-and-dirty" widget to display box and arrow diagrams, class diagrams, etc.. you can instantiated one of these widgets and provide a few content providers.  The content provider will describe the data, and possibly some simple display information (such as which icons to use for a box, etc...).

 

We currently have a small team working on some simple examples, and then we were planning on releasing these to the community with three main goals in mind:

 1) To promote our work and gain more requirements for new widgets

 2) To see if anyone wants to contribute new widgets or extensions to our widgets

 3) To give people some GEF code the can use, learn from and extend.

 

Some of these widgets are being built using GEF and other ones just Draw2D.  I have actually been away from school for the past month but I am heading home on Wednesday.  When I get back I will update our website and hopefully get some prototypes online. 

I think Randy is correct though, we definitely need more detailed proposals.  I hope that by releasing a few simple widgets, and then opening up a discussion forum, we will be able to generate some solid requirements.

 

I will post more information here (or to the newsgroup) when I get home.  If you have any thoughts on this project please feel free to drop me a line.

 

Cheers,

Ian

----- Original Message -----

From: Randy Hudson

To: gef-dev@xxxxxxxxxxx

Sent: Monday, June 28, 2004 10:17 AM

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