Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Refactoring GEF Figs for better extensibility

gef
Discussion topic

Back to topic list

Refactoring GEF Figs for better extensibility

Reply

Author "Smith, Brian" <SmithBL at mail dot medicine dot uiowa dot edu>
Full name "Smith, Brian" <SmithBL at mail dot medicine dot uiowa dot edu>
Date 2000-05-29 21:09:07 PDT
Message [sorry for the bad quoting format and the lack of threading: I had to
copy/paste the message from the archives page]

"Curt Hagenlocher" <curt at hagenlocher.org> wrote:

> 6. Setting the fill and stroke on
> a FigGroup recursively sets them for
> all objects contained in that group.
> Clearly, step 6 is wrong. This is
> especially ironic in light of the
> fact that the group itself *has* no
> graphical representation.

I don't think this is completely wrong. Take a UML class figure as an
example: When you change the stroke width, you want the whole figure to have
that stroke width, so each line and rectangle inside the figure must be
adjusted. The same goes for the fill (although it might be better to have a
"transparent" fill on the grouped elements).

In SVG, a <g> ("group") element's style properties are inherited by the
contained elements by default. The difference is that each element can
override the default. This type of mechanism doesn't exist in GEF currently,
but it could be added. However, TEE definitely seems like it would create
problems in this scenerio, since it can't describe an action like "apply
these properties by default".

> Issue: Inconsistent group handling
>
> Ungroup the FigSampleNode in the
> BasicApplication. Then, regroup.
> Visually, the graph looks the same,
> but the data model is subtly altered.
> Instead of FigSampleNode, the grouping
> object is now a FigGroup. Save
> as PGML and reload. The graph will be empty.
>
> Note that the seven components of the group
> were never created. Both of these problems
> can be characterised as discrepancies between
> how we expect an object to behave when
> loading from a file vs. creating a new
> instance.

Actually, this seems to be a problem with the group command, not with the
PGML persistence mechanism. I doubt that it should be possible to "ungroup"
a Node in the first place; this is definitely going to result in loss of
lots of information, independent of saving and restoring. This means that
FigNode isn't a FigGroup; rather it has a FigGroup. Thus, FigNode probably
shouldn't derive from FigGroup, but rather should contain one.

> I think that both problems could be
> solved by requiring that all objects
> derived from FigGroup have a
> constructor which accepts an owner, a Vector
> of Figs and the standard properties
> (x, y, width, etc., including fill).
> This would let the object know that it was
> being created from serialized data, and
> that it should (potentially) behave differently as a result.

I think the following method for dealing with groups would work out better:

1. Upon encountering a <group>, create a FigGroup for it.
2. Set the FigGroup's visual properties according to the <group> element's
attributes.
3. For each element nested inside the <group>:
   a) Create the appropriate Fig for that element.
   b) Set the nested Fig's visual properties
      to match the <group>'s
   c) Set the nested Fig's visual properties
      to match its attributes, if any.
   d) Add the Fig to the FigGroup.

TEE should be able to handle everything except perhaps for step 3.b

> Objects derived from FigEdge would
> probably still be a special case.

Special cases are no fun. I'll post another message about what I think
should happen with FigNode and FigEdge.

- Brian

« Previous message in topic | 1 of 1 | Next message in topic »

Messages

Show all messages in topic

Refactoring GEF Figs for better extensibility "Smith, Brian" <SmithBL at mail dot medicine dot uiowa dot edu> "Smith, Brian" <SmithBL at mail dot medicine dot uiowa dot edu> 2000-05-29 21:09:07 PDT
Messages per page: