Login | Register
My pages Projects Community openCollabNet

Discussions > dev > [gef-dev] Scaling problems

gef
Discussion topic

Hide all messages in topic

All messages in topic

Re: [gef-dev] UI/Model split (was Scaling problems)

Reply

Author anoncvs
Full name anonymous CVS access
Date 2004-01-30 12:22:52 PST
Message > One of the things I'd like to investigate at some stage is a client server
> version of GEF. This is why I want to firmly split the model from the UI.

You can do that now. You can definately have an application where the
model classes know absolutely nothing about the UI. E.g., you could
build a GEF editor to visualize classes in a library produced by someone
else. This is done in ArgoUML: the meta-model classes (should) know
nothing about any Figs. Your application objects do not need to
subclass FigNode or even implement any GEF interfaces.

To do that, you just need to implement some mediator classes like
Renderers and GraphModels. These classes know about the connection
between the UI and the model.

I just think that these classes are an extra level of abstraction that
is not at first clear to new developers and might not be useful to
developers that don't need it. E.g., many students who might be
learning GEF might expect it to be more concrete and specific.

jason!



--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at gef dot tigris dot org
For additional commands, e-mail: dev-help at gef dot tigris dot org

Re: RE: [gef-dev] Scaling problems

Reply

Author Bob Tarling <bob dot tarling at ntlworld dot com>
Full name Bob Tarling <bob dot tarling at ntlworld dot com>
Date 2004-01-30 12:09:41 PST
Message Haha - that worked fine

I think I did retranslateMouseEvent instead. Unsuprisingly everything got
worse.

I still think we need a better way of passing around a scaled and unscaled
mouse position rather than recalculating and possibly not knowing what state
the mouse event is in.

This is great for now though - I'm still finding my way around and don't
quite have the confidence yet for drastic refactoring.

I hope to get release 0.10.1 out in the next few days.

Thanks

Bob.

----- Original Message -----
From: "Bob Tarling" <bob.tarling@ntlw​orld.com>
To: <dev at gef dot tigris dot org>
Sent: Friday, January 30, 2004 7:47 PM
Subject: Re: RE: [gef-dev] Scaling problems


> Hmm, I thought I tried that. I'll give it another go.
>
> ----- Original Message -----
> From: "Christensen, Blake" <Blake.Christense​n@dsionline.com>
> To: <dev at gef dot tigris dot org>
> Sent: Friday, January 30, 2004 7:46 PM
> Subject: RE: RE: [gef-dev] Scaling problems
>
>
> >> The zoom scaling problems is one of the problems I worked
> >>around implementing an editor using gef. I just had each
> >>mode do the scaling it needed
> >I'd be grateful for any patch to fix ModeSelect.
>
> I just added:
>
> editor.translateMouseEvent(me);
>
> as the first line of mouseDragged and mouseReleased.
> I am still using version 1.2 so I don't know if there are any problems
with
> doing this.
>
> Blake
>
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe at gef dot tigris dot org
> For additional commands, e-mail: dev-help at gef dot tigris dot org
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe at gef dot tigris dot org
> For additional commands, e-mail: dev-help at gef dot tigris dot org
>


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at gef dot tigris dot org
For additional commands, e-mail: dev-help at gef dot tigris dot org

Re: RE: [gef-dev] Scaling problems

Reply

Author Bob Tarling <bob dot tarling at ntlworld dot com>
Full name Bob Tarling <bob dot tarling at ntlworld dot com>
Date 2004-01-30 11:47:42 PST
Message Hmm, I thought I tried that. I'll give it another go.

----- Original Message -----
From: "Christensen, Blake" <Blake.Christense​n@dsionline.com>
To: <dev at gef dot tigris dot org>
Sent: Friday, January 30, 2004 7:46 PM
Subject: RE: RE: [gef-dev] Scaling problems


>> The zoom scaling problems is one of the problems I worked
>>around implementing an editor using gef. I just had each
>>mode do the scaling it needed
>I'd be grateful for any patch to fix ModeSelect.

I just added:

 editor.translateMouseEvent(me);

as the first line of mouseDragged and mouseReleased.
I am still using version 1.2 so I don't know if there are any problems with
doing this.

Blake



--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at gef dot tigris dot org
For additional commands, e-mail: dev-help at gef dot tigris dot org


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at gef dot tigris dot org
For additional commands, e-mail: dev-help at gef dot tigris dot org

RE: RE: [gef-dev] Scaling problems

Reply

Author "Christensen, Blake" <Blake dot Christensen at dsionline dot com>
Full name "Christensen, Blake" <Blake dot Christensen at dsionline dot com>
Date 2004-01-30 11:46:28 PST
Message >> The zoom scaling problems is one of the problems I worked
>>around implementing an editor using gef. I just had each
>>mode do the scaling it needed
>I'd be grateful for any patch to fix ModeSelect.

I just added:

 editor.translateMouseEvent(me);

as the first line of mouseDragged and mouseReleased.
I am still using version 1.2 so I don't know if there are any problems with doing this.

Blake



--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at gef dot tigris dot org
For additional commands, e-mail: dev-help at gef dot tigris dot org

[gef-dev] UI/Model split (was Scaling problems)

Reply

Author Bob Tarling <bob dot tarling at ntlworld dot com>
Full name Bob Tarling <bob dot tarling at ntlworld dot com>
Date 2004-01-30 11:31:17 PST
Message > IIRC, that was an attempt at making it optional for a developer using
> GEF to understand the concept of a Renderer.
One of the things I'd like to investigate at some stage is a client server
version of GEF. This is why I want to firmly split the model from the UI.

I'm thinking of this initially being a 'pass the baton' approach where only
one user, the 'baton' holder can make modifications. All users see these
changes in their view in real time. The baton holder can pass the baton by
clicking in user in a user list panel. Any user can request the baton by
clicking on the current baton holder.

Once this simple approach is working some work could begin to allow multiple
edits.

Please note - this is some way off, I have many other things on my list, but
I'd like to gradually start architecting for this by gradually removing the
models knowledge of the GUI. Possibly eventually splitting GEF into 2 jars,
one for model and one for GUI, I wouldn't like to see any cyclic
dependencies between these.

However I sometimes wonder if Figs are truly GUI objects. I'm starting to
view these as a 2nd layer model, it is more like data about where to
display, very little on how to display.

> I wish there was an easy way for developers to express pairs of
> corresponding classes without having to write a bunch of code to
> explicitly manage the correspondence

Personally I don't like relying on naming conventions. ALthough JUnit is
cool and I'd like to start a test suite.

I've been thinking about the possibilty of letting users define their own
Figs in XML. The same XML could map that Fig to a model class.
XML rules could also dictate which ports can be attached by which edges and
maybe some other simple rules such as degree.

I have quite a few ideas I'd like to try to implement. I'll maybe put a few
proposals together and add some links to the homepage. These can be
discussed further and refined on the dev list.

Others are

- LayoutManagers for better resizing of Figs. I've already started on a
FigFactory as a quick fix to help with this same problem. This is what I'm
working on in core GEF at the moment.

- Change the co-ordinate system of child figs to be based on the position in
parent rather than position in Canvas.

Bob.

----- Original Message -----
From: "Jason Robbins" <jrobbins at tigris dot org>
To: <dev at gef dot tigris dot org>
Sent: Friday, January 30, 2004 6:02 PM
Subject: Re: RE: [gef-dev] Scaling problems


> On Fri, 2004-01-30 at 09:23, bob dot tarling at ntlworld dot com wrote:
> > >>e.g. FigNode has a makePresentation() method
> >
> > Oops, I meant to point out that a NetNode has a makePresentation method.
I don't think the model should know how it's presented.
>
>
> IIRC, that was an attempt at making it optional for a developer using
> GEF to understand the concept of a Renderer.
>
> I think it is good to make some key concepts optional so that new
> developers can get started more easily and so that simple cases can be
> handled simply (e.g., an application object that is only rendered by one
> corresponding Fig object). However, when it is not documented well, it
> looks like bad design.
>
> I wish there was an easy way for developers to express pairs of
> corresponding classes without having to write a bunch of code to
> explicitly manage the correspondence, unless they have a special
> correspondence rule. E.g., if I had application objects Student,
> Instructor, and Course, I might want them rendered by FigStudent,
> FigInstructor, and FigCourse. But. maybe there is one special case,
> applicaton object Room should be rendered by FigBuilding.
>
> One thing has been added to the Java culture since I started GEF is the
> wide spread usage of JUnit. JUnit encourages the use of a simple naming
> convention for corresponding classes. E.g., Student and StudentTest.
> But, it also allows a developer to build their own TestSuite if desired.
>
> Maybe we could go with a naming convention as a way to make Renderers
> optional. E.g., when adding an instance of model class C, the default
> renderer would look for FigC. But, what package should it look in?
> Of course, developers could always add their own Renderer to handle
> special cases.
>
> jason!
>
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe at gef dot tigris dot org
> For additional commands, e-mail: dev-help at gef dot tigris dot org
>


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at gef dot tigris dot org
For additional commands, e-mail: dev-help at gef dot tigris dot org

Re: RE: [gef-dev] Scaling problems

Reply

Author anoncvs
Full name anonymous CVS access
Date 2004-01-30 10:02:11 PST
Message On Fri, 2004-01-30 at 09:23, bob dot tarling at ntlworld dot com wrote:
> >>e.g. FigNode has a makePresentation() method
>
> Oops, I meant to point out that a NetNode has a makePresentation method. I don't think the model should know how it's presented.


IIRC, that was an attempt at making it optional for a developer using
GEF to understand the concept of a Renderer.

I think it is good to make some key concepts optional so that new
developers can get started more easily and so that simple cases can be
handled simply (e.g., an application object that is only rendered by one
corresponding Fig object). However, when it is not documented well, it
looks like bad design.

I wish there was an easy way for developers to express pairs of
corresponding classes without having to write a bunch of code to
explicitly manage the correspondence, unless they have a special
correspondence rule. E.g., if I had application objects Student,
Instructor, and Course, I might want them rendered by FigStudent,
FigInstructor, and FigCourse. But. maybe there is one special case,
applicaton object Room should be rendered by FigBuilding.

One thing has been added to the Java culture since I started GEF is the
wide spread usage of JUnit. JUnit encourages the use of a simple naming
convention for corresponding classes. E.g., Student and StudentTest.
But, it also allows a developer to build their own TestSuite if desired.

Maybe we could go with a naming convention as a way to make Renderers
optional. E.g., when adding an instance of model class C, the default
renderer would look for FigC. But, what package should it look in?
Of course, developers could always add their own Renderer to handle
special cases.

jason!



--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at gef dot tigris dot org
For additional commands, e-mail: dev-help at gef dot tigris dot org

Re: RE: [gef-dev] Scaling problems

Reply

Author bob dot tarling at ntlworld dot com
Full name bob dot tarling at ntlworld dot com
Date 2004-01-30 09:23:18 PST
Message >>e.g. FigNode has a makePresentation() method

Oops, I meant to point out that a NetNode has a makePresentation method. I don't think the model should know how it's presented.

--------------------​--------------------​-
Email provided by http://www.ntlhome.com/
Attachments

Re: RE: [gef-dev] Scaling problems

Reply

Author bob dot tarling at ntlworld dot com
Full name bob dot tarling at ntlworld dot com
Date 2004-01-30 09:19:48 PST
Message > The zoom scaling problems is one of the problems I worked
>around implementing an editor using gef. I just had each
>mode do the scaling it needed
I'd be grateful for any patch to fix ModeSelect.

>I don't feel the model view controller seperation is
>complete in gef so I modified:
I agree with this. It is not clear where the seperation is.
I was curious to see that the model has knowledge of the GUI. e.g. FigNode has a makePresentation() method

I'm hoping to get GEF back to being released regularly with changes and deprecations in to impove this structure.

If you have any improvements you can apply then please create an issue and attach a patch.

Try to create seperate issues and a patch for each one rather than just apply one big patch. The bigger patches with multiple changes can take quite some time to check.

Regards

Bob.

--------------------​--------------------​-
Email provided by http://www.ntlhome.com/
Attachments

RE: [gef-dev] Scaling problems

Reply

Author "Christensen, Blake" <Blake dot Christensen at dsionline dot com>
Full name "Christensen, Blake" <Blake dot Christensen at dsionline dot com>
Date 2004-01-30 09:01:41 PST
Message The zoom scaling problems is one of the problems I worked around implementing an editor using gef. I just had each mode do the scaling it needed, which probably wasn't the best solution.
 
In case anyone is interested some other changes I have made:
 
I don't feel the model view controller seperation is complete in gef so I modified:
FigNode removing the delete, since the model should delete not the view/controller.
Extensions to NetNode and NetEdge intercept dispose and pass the information to the model.
LayerPerspective implements the graphChanged method which gets the nodes and edges from the model. Calls to this are added to the constructors and the setGraphModel method.
The implementation of MutableGraphSupport was there to send model changes to the view/controller (gef) and handle commands going to the model layer on top of a database.
 
FigLine was changed since the hit method was code for a square and not a line.
 
 
Blake
Attachments

[gef-dev] Scaling problems

Reply

Author Bob Tarling <bob dot tarling at ntlworld dot com>
Full name Bob Tarling <bob dot tarling at ntlworld dot com>
Date 2004-01-29 18:06:21 PST
Message I have to confess I'm getting beaten by issue 60 http://gef.tigris.or​g/issues/show_bug.cg​i?id=60

If anyone can spot anything I'm missing then let me know.

I think part of the problem lies with the methods on Editor of translateMouseEvent and retranslateMouseEvent. These are called by various modes, which means that no other mode can be sure if the mouse event it is passed has already been scaled or not.

I'd suggest these methods should return a new copy of a MouseEvent rather than amending its input, that's a nasty side effect.

Better still we could subclass MouseEvent to contain both scaled and unscaled co-ordinates and pass this specialist MouseEvent around instead.

In the meantime though I'd like to find a workaround for the current problem. This is around the mouseDragged method of ModeSelect, I've done some refactoring so I can see what's going on a bit more clearly but I've had no luck so far in solving this.

Those using ArgoUML can easily reproduce the bug with that, just zoom in or out and then draw a selection rectangle. I'll but a demo into BasicApplication also.

Bob.
Attachments
Messages per page: