Home » Eclipse Projects » GEF » RulerComposite
| RulerComposite [message #139868] |
Thu, 24 June 2004 12:59  |
Eclipse User |
|
|
|
i've been looking at the code for rulers. i'm wondering why the top level UI
object is a RulerComposite (inheriting from Composite), rather than a
RulerEditor (inheriting from EditPart).
i'm assuming this is because the rulers have to be added to an existing
editor. if, instead, i'm writing an editor that draws the rulers itself
(actually it's more like a graph axis than a ruler), would it make sense to
have the top level object be an EditPart (and simplifying some of the ruler
structure? i know i can probably figure this out by looking at the code, but
was hoping someone knew the answer off the top of their head.
also, any pointers on how to go about structuring an editor that had such
axes/rulers as part of it's model would be appreciated. starting from the
ruler code sample.
regards,
al
|
|
| |
| Re: RulerComposite [message #139940 is a reply to message #139928] |
Thu, 24 June 2004 18:45  |
| Eclipse User |
|
|
|
so you'd suggest using a similar structure even if the ruler/axes are an
integral part of the model? in my situation, the ruler/axis may have to be
drawn in the middle of the client area, not at an edge. so direct re-use of
the ruler code isn't actually possible.
"Randy Hudson" <none@us.ibm.com> wrote in message
news:cbfhnu$ij4$1@eclipse.org...
> It makes a lot of things easier to implement as a composite. For example,
> independant scrolling and also focus management and keyboard
accessibility.
> Maybe your graph axis doesn't need some of these functions.
>
> "Al Major" <almajor@boxspoon.com> wrote in message
> news:cbf1ca$l69$1@eclipse.org...
> > i've been looking at the code for rulers. i'm wondering why the top
level
> UI
> > object is a RulerComposite (inheriting from Composite), rather than a
> > RulerEditor (inheriting from EditPart).
> >
> > i'm assuming this is because the rulers have to be added to an existing
> > editor. if, instead, i'm writing an editor that draws the rulers itself
> > (actually it's more like a graph axis than a ruler), would it make sense
> to
> > have the top level object be an EditPart (and simplifying some of the
> ruler
> > structure? i know i can probably figure this out by looking at the code,
> but
> > was hoping someone knew the answer off the top of their head.
> >
> > also, any pointers on how to go about structuring an editor that had
such
> > axes/rulers as part of it's model would be appreciated. starting from
the
> > ruler code sample.
> >
> > regards,
> >
> > al
> >
> >
>
>
|
|
|
| Re: RulerComposite [message #139962 is a reply to message #139928] |
Thu, 24 June 2004 23:26 |
| Eclipse User |
|
|
|
hi randy,
i'm still having some trouble with this, so i'm going to try to summarize
the situation to see if i understand it correctly.
according to the documentation i've seen, the GraphicalViewer is an
EditPartViewer with it's own RootEditPart and EditPartFactory. i somehow
have the impression that GEF is designed to have a single EditPartViewer per
editor (workbench editpart). this is (apparently) a mistaken impression,
because......
in the RulerComposite, the top level composite contains (up to) 3
ScrollingGraphicalViewers, one of them being the "main" EditPartViewer, the
others being an EditPartViewer for each Ruler. so conceptually, there's 3
models (one for each viewer), apparently tied together with a RulerProvider
that exposes the ruler models to the "main" model.
the bulk of the ruler code is straightforward GEF/draw2d code as i expected.
just the glue code in the composite is being done SWT style instead of in
draw2d. this is what surprised me.
is this an accurate representation of the situation?
if so, and from what you're saying, certain features, such as independant
scrolling, focus management and keyboard accessibility are difficult to
implement purely with draw2d figures. as a newbie, i don't understand enough
about the architecture to see why this should be so. your word on it is
obviously good. however, i'd like to know if there are other situations
where one or the other (draw2d/SWT) is the obvious choice. has anything been
written up about this?
in my situation with the ruler/axis potentially in the middle of the client
area, the choice comes down to how the model is visualized. if the model can
be cleanly split so that each sub-model can be visualized in a
non-overlapping region of the screen, i can use the composite glue ala
ruler. however, if there are model elements that must visually appear on
both sides of the ruler/axis i have to use draw2d as the glue. in the second
case, can you say a little more about the functionality restrictions i'm
likely to run into, and point me at the right parts of the API / other
documentation.
thx/regards,
al
"Randy Hudson" <none@us.ibm.com> wrote in message
news:cbfhnu$ij4$1@eclipse.org...
> It makes a lot of things easier to implement as a composite. For example,
> independant scrolling and also focus management and keyboard
accessibility.
> Maybe your graph axis doesn't need some of these functions.
>
> "Al Major" <almajor@boxspoon.com> wrote in message
> news:cbf1ca$l69$1@eclipse.org...
> > i've been looking at the code for rulers. i'm wondering why the top
level
> UI
> > object is a RulerComposite (inheriting from Composite), rather than a
> > RulerEditor (inheriting from EditPart).
> >
> > i'm assuming this is because the rulers have to be added to an existing
> > editor. if, instead, i'm writing an editor that draws the rulers itself
> > (actually it's more like a graph axis than a ruler), would it make sense
> to
> > have the top level object be an EditPart (and simplifying some of the
> ruler
> > structure? i know i can probably figure this out by looking at the code,
> but
> > was hoping someone knew the answer off the top of their head.
> >
> > also, any pointers on how to go about structuring an editor that had
such
> > axes/rulers as part of it's model would be appreciated. starting from
the
> > ruler code sample.
> >
> > regards,
> >
> > al
> >
> >
>
>
|
|
|
| Re: RulerComposite [message #140075 is a reply to message #139962] |
Fri, 25 June 2004 10:17 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Since GEF is the foundation for business tools, it must be Section 508
accessible. So we needed a way to traverse to the ruler with the keyboard.
There are tons of ways to do this and you could do it within a single
GraphicalViewer, but we chose to use native focus traversal within a single
Composite.
The other thing that was necessary was a separate notion of selection. If a
Guide on the ruler is selected, a part in the diagram cannot also be in the
same selection. Again, there are ways to implement the illusion of two
distinct viewers within a single viewer, but it is harder. Context menus
need to be separate, etc.
It really depends on what you are doing as to how you solve it. Do you need
selection, context menus, etc., or are you just painting an axis?
"Al Major" <almajor@boxspoon.com> wrote in message
news:cbg64e$e4j$1@eclipse.org...
> hi randy,
>
> i'm still having some trouble with this, so i'm going to try to summarize
> the situation to see if i understand it correctly.
>
> according to the documentation i've seen, the GraphicalViewer is an
> EditPartViewer with it's own RootEditPart and EditPartFactory. i somehow
> have the impression that GEF is designed to have a single EditPartViewer
per
> editor (workbench editpart). this is (apparently) a mistaken impression,
> because......
>
> in the RulerComposite, the top level composite contains (up to) 3
> ScrollingGraphicalViewers, one of them being the "main" EditPartViewer,
the
> others being an EditPartViewer for each Ruler. so conceptually, there's 3
> models (one for each viewer), apparently tied together with a
RulerProvider
> that exposes the ruler models to the "main" model.
>
> the bulk of the ruler code is straightforward GEF/draw2d code as i
expected.
> just the glue code in the composite is being done SWT style instead of in
> draw2d. this is what surprised me.
>
> is this an accurate representation of the situation?
>
> if so, and from what you're saying, certain features, such as independant
> scrolling, focus management and keyboard accessibility are difficult to
> implement purely with draw2d figures. as a newbie, i don't understand
enough
> about the architecture to see why this should be so. your word on it is
> obviously good. however, i'd like to know if there are other situations
> where one or the other (draw2d/SWT) is the obvious choice. has anything
been
> written up about this?
>
> in my situation with the ruler/axis potentially in the middle of the
client
> area, the choice comes down to how the model is visualized. if the model
can
> be cleanly split so that each sub-model can be visualized in a
> non-overlapping region of the screen, i can use the composite glue ala
> ruler. however, if there are model elements that must visually appear on
> both sides of the ruler/axis i have to use draw2d as the glue. in the
second
> case, can you say a little more about the functionality restrictions i'm
> likely to run into, and point me at the right parts of the API / other
> documentation.
>
> thx/regards,
>
> al
>
>
>
>
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:cbfhnu$ij4$1@eclipse.org...
> > It makes a lot of things easier to implement as a composite. For
example,
> > independant scrolling and also focus management and keyboard
> accessibility.
> > Maybe your graph axis doesn't need some of these functions.
> >
> > "Al Major" <almajor@boxspoon.com> wrote in message
> > news:cbf1ca$l69$1@eclipse.org...
> > > i've been looking at the code for rulers. i'm wondering why the top
> level
> > UI
> > > object is a RulerComposite (inheriting from Composite), rather than a
> > > RulerEditor (inheriting from EditPart).
> > >
> > > i'm assuming this is because the rulers have to be added to an
existing
> > > editor. if, instead, i'm writing an editor that draws the rulers
itself
> > > (actually it's more like a graph axis than a ruler), would it make
sense
> > to
> > > have the top level object be an EditPart (and simplifying some of the
> > ruler
> > > structure? i know i can probably figure this out by looking at the
code,
> > but
> > > was hoping someone knew the answer off the top of their head.
> > >
> > > also, any pointers on how to go about structuring an editor that had
> such
> > > axes/rulers as part of it's model would be appreciated. starting from
> the
> > > ruler code sample.
> > >
> > > regards,
> > >
> > > al
> > >
> > >
> >
> >
>
>
|
|
|
| Re: RulerComposite [message #140272 is a reply to message #140075] |
Fri, 25 June 2004 16:10 |
| Eclipse User |
|
|
|
thanks. that was useful detail.
i'm not quite sure as yet whether i'll need selection/context menus etc.
maybe i'll start off mimicking your implementation and see if more/less is
needed later.
regards,
al
"Randy Hudson" <none@us.ibm.com> wrote in message
news:cbhc53$irk$1@eclipse.org...
> Since GEF is the foundation for business tools, it must be Section 508
> accessible. So we needed a way to traverse to the ruler with the
keyboard.
> There are tons of ways to do this and you could do it within a single
> GraphicalViewer, but we chose to use native focus traversal within a
single
> Composite.
>
> The other thing that was necessary was a separate notion of selection. If
a
> Guide on the ruler is selected, a part in the diagram cannot also be in
the
> same selection. Again, there are ways to implement the illusion of two
> distinct viewers within a single viewer, but it is harder. Context menus
> need to be separate, etc.
>
> It really depends on what you are doing as to how you solve it. Do you
need
> selection, context menus, etc., or are you just painting an axis?
>
>
>
> "Al Major" <almajor@boxspoon.com> wrote in message
> news:cbg64e$e4j$1@eclipse.org...
> > hi randy,
> >
> > i'm still having some trouble with this, so i'm going to try to
summarize
> > the situation to see if i understand it correctly.
> >
> > according to the documentation i've seen, the GraphicalViewer is an
> > EditPartViewer with it's own RootEditPart and EditPartFactory. i somehow
> > have the impression that GEF is designed to have a single EditPartViewer
> per
> > editor (workbench editpart). this is (apparently) a mistaken impression,
> > because......
> >
> > in the RulerComposite, the top level composite contains (up to) 3
> > ScrollingGraphicalViewers, one of them being the "main" EditPartViewer,
> the
> > others being an EditPartViewer for each Ruler. so conceptually, there's
3
> > models (one for each viewer), apparently tied together with a
> RulerProvider
> > that exposes the ruler models to the "main" model.
> >
> > the bulk of the ruler code is straightforward GEF/draw2d code as i
> expected.
> > just the glue code in the composite is being done SWT style instead of
in
> > draw2d. this is what surprised me.
> >
> > is this an accurate representation of the situation?
> >
> > if so, and from what you're saying, certain features, such as
independant
> > scrolling, focus management and keyboard accessibility are difficult to
> > implement purely with draw2d figures. as a newbie, i don't understand
> enough
> > about the architecture to see why this should be so. your word on it is
> > obviously good. however, i'd like to know if there are other situations
> > where one or the other (draw2d/SWT) is the obvious choice. has anything
> been
> > written up about this?
> >
> > in my situation with the ruler/axis potentially in the middle of the
> client
> > area, the choice comes down to how the model is visualized. if the model
> can
> > be cleanly split so that each sub-model can be visualized in a
> > non-overlapping region of the screen, i can use the composite glue ala
> > ruler. however, if there are model elements that must visually appear on
> > both sides of the ruler/axis i have to use draw2d as the glue. in the
> second
> > case, can you say a little more about the functionality restrictions i'm
> > likely to run into, and point me at the right parts of the API / other
> > documentation.
> >
> > thx/regards,
> >
> > al
> >
> >
> >
> >
> > "Randy Hudson" <none@us.ibm.com> wrote in message
> > news:cbfhnu$ij4$1@eclipse.org...
> > > It makes a lot of things easier to implement as a composite. For
> example,
> > > independant scrolling and also focus management and keyboard
> > accessibility.
> > > Maybe your graph axis doesn't need some of these functions.
> > >
> > > "Al Major" <almajor@boxspoon.com> wrote in message
> > > news:cbf1ca$l69$1@eclipse.org...
> > > > i've been looking at the code for rulers. i'm wondering why the top
> > level
> > > UI
> > > > object is a RulerComposite (inheriting from Composite), rather than
a
> > > > RulerEditor (inheriting from EditPart).
> > > >
> > > > i'm assuming this is because the rulers have to be added to an
> existing
> > > > editor. if, instead, i'm writing an editor that draws the rulers
> itself
> > > > (actually it's more like a graph axis than a ruler), would it make
> sense
> > > to
> > > > have the top level object be an EditPart (and simplifying some of
the
> > > ruler
> > > > structure? i know i can probably figure this out by looking at the
> code,
> > > but
> > > > was hoping someone knew the answer off the top of their head.
> > > >
> > > > also, any pointers on how to go about structuring an editor that had
> > such
> > > > axes/rulers as part of it's model would be appreciated. starting
from
> > the
> > > > ruler code sample.
> > > >
> > > > regards,
> > > >
> > > > al
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: RulerComposite [message #141172 is a reply to message #140272] |
Thu, 01 July 2004 18:12 |
| Eclipse User |
|
|
|
it appears that if i have multiple panes, each with it's own model, the top
level editor (corresponding to LogicEditor in the sample) will need to
contain a GraphicalEditor instance for each pane. so the current structure
of LogicEditor inheriting from a GraphicalEditor is not going to work as is.
or, am i missing something?
regards,
al
"Al Major" <almajor@boxspoon.com> wrote in message
news:cbi0u6$r63$1@eclipse.org...
> thanks. that was useful detail.
>
> i'm not quite sure as yet whether i'll need selection/context menus etc.
> maybe i'll start off mimicking your implementation and see if more/less is
> needed later.
>
> regards,
>
> al
>
>
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:cbhc53$irk$1@eclipse.org...
> > Since GEF is the foundation for business tools, it must be Section 508
> > accessible. So we needed a way to traverse to the ruler with the
> keyboard.
> > There are tons of ways to do this and you could do it within a single
> > GraphicalViewer, but we chose to use native focus traversal within a
> single
> > Composite.
> >
> > The other thing that was necessary was a separate notion of selection.
If
> a
> > Guide on the ruler is selected, a part in the diagram cannot also be in
> the
> > same selection. Again, there are ways to implement the illusion of two
> > distinct viewers within a single viewer, but it is harder. Context
menus
> > need to be separate, etc.
> >
> > It really depends on what you are doing as to how you solve it. Do you
> need
> > selection, context menus, etc., or are you just painting an axis?
> >
> >
> >
> > "Al Major" <almajor@boxspoon.com> wrote in message
> > news:cbg64e$e4j$1@eclipse.org...
> > > hi randy,
> > >
> > > i'm still having some trouble with this, so i'm going to try to
> summarize
> > > the situation to see if i understand it correctly.
> > >
> > > according to the documentation i've seen, the GraphicalViewer is an
> > > EditPartViewer with it's own RootEditPart and EditPartFactory. i
somehow
> > > have the impression that GEF is designed to have a single
EditPartViewer
> > per
> > > editor (workbench editpart). this is (apparently) a mistaken
impression,
> > > because......
> > >
> > > in the RulerComposite, the top level composite contains (up to) 3
> > > ScrollingGraphicalViewers, one of them being the "main"
EditPartViewer,
> > the
> > > others being an EditPartViewer for each Ruler. so conceptually,
there's
> 3
> > > models (one for each viewer), apparently tied together with a
> > RulerProvider
> > > that exposes the ruler models to the "main" model.
> > >
> > > the bulk of the ruler code is straightforward GEF/draw2d code as i
> > expected.
> > > just the glue code in the composite is being done SWT style instead of
> in
> > > draw2d. this is what surprised me.
> > >
> > > is this an accurate representation of the situation?
> > >
> > > if so, and from what you're saying, certain features, such as
> independant
> > > scrolling, focus management and keyboard accessibility are difficult
to
> > > implement purely with draw2d figures. as a newbie, i don't understand
> > enough
> > > about the architecture to see why this should be so. your word on it
is
> > > obviously good. however, i'd like to know if there are other
situations
> > > where one or the other (draw2d/SWT) is the obvious choice. has
anything
> > been
> > > written up about this?
> > >
> > > in my situation with the ruler/axis potentially in the middle of the
> > client
> > > area, the choice comes down to how the model is visualized. if the
model
> > can
> > > be cleanly split so that each sub-model can be visualized in a
> > > non-overlapping region of the screen, i can use the composite glue ala
> > > ruler. however, if there are model elements that must visually appear
on
> > > both sides of the ruler/axis i have to use draw2d as the glue. in the
> > second
> > > case, can you say a little more about the functionality restrictions
i'm
> > > likely to run into, and point me at the right parts of the API / other
> > > documentation.
> > >
> > > thx/regards,
> > >
> > > al
> > >
> > >
> > >
> > >
> > > "Randy Hudson" <none@us.ibm.com> wrote in message
> > > news:cbfhnu$ij4$1@eclipse.org...
> > > > It makes a lot of things easier to implement as a composite. For
> > example,
> > > > independant scrolling and also focus management and keyboard
> > > accessibility.
> > > > Maybe your graph axis doesn't need some of these functions.
> > > >
> > > > "Al Major" <almajor@boxspoon.com> wrote in message
> > > > news:cbf1ca$l69$1@eclipse.org...
> > > > > i've been looking at the code for rulers. i'm wondering why the
top
> > > level
> > > > UI
> > > > > object is a RulerComposite (inheriting from Composite), rather
than
> a
> > > > > RulerEditor (inheriting from EditPart).
> > > > >
> > > > > i'm assuming this is because the rulers have to be added to an
> > existing
> > > > > editor. if, instead, i'm writing an editor that draws the rulers
> > itself
> > > > > (actually it's more like a graph axis than a ruler), would it make
> > sense
> > > > to
> > > > > have the top level object be an EditPart (and simplifying some of
> the
> > > > ruler
> > > > > structure? i know i can probably figure this out by looking at the
> > code,
> > > > but
> > > > > was hoping someone knew the answer off the top of their head.
> > > > >
> > > > > also, any pointers on how to go about structuring an editor that
had
> > > such
> > > > > axes/rulers as part of it's model would be appreciated. starting
> from
> > > the
> > > > > ruler code sample.
> > > > >
> > > > > regards,
> > > > >
> > > > > al
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: RulerComposite [message #141250 is a reply to message #141172] |
Thu, 01 July 2004 20:01 |
| Eclipse User |
|
|
|
I am not sure what you mean. What do you mean by a pane? And what are
these panes showing?
"Al Major" <almajor@boxspoon.com> wrote in message
news:cc2270$is0$1@eclipse.org...
> it appears that if i have multiple panes, each with it's own model, the
top
> level editor (corresponding to LogicEditor in the sample) will need to
> contain a GraphicalEditor instance for each pane. so the current structure
> of LogicEditor inheriting from a GraphicalEditor is not going to work as
is.
> or, am i missing something?
>
> regards,
>
> al
>
> "Al Major" <almajor@boxspoon.com> wrote in message
> news:cbi0u6$r63$1@eclipse.org...
> > thanks. that was useful detail.
> >
> > i'm not quite sure as yet whether i'll need selection/context menus etc.
> > maybe i'll start off mimicking your implementation and see if more/less
is
> > needed later.
> >
> > regards,
> >
> > al
> >
> >
> > "Randy Hudson" <none@us.ibm.com> wrote in message
> > news:cbhc53$irk$1@eclipse.org...
> > > Since GEF is the foundation for business tools, it must be Section 508
> > > accessible. So we needed a way to traverse to the ruler with the
> > keyboard.
> > > There are tons of ways to do this and you could do it within a single
> > > GraphicalViewer, but we chose to use native focus traversal within a
> > single
> > > Composite.
> > >
> > > The other thing that was necessary was a separate notion of selection.
> If
> > a
> > > Guide on the ruler is selected, a part in the diagram cannot also be
in
> > the
> > > same selection. Again, there are ways to implement the illusion of
two
> > > distinct viewers within a single viewer, but it is harder. Context
> menus
> > > need to be separate, etc.
> > >
> > > It really depends on what you are doing as to how you solve it. Do
you
> > need
> > > selection, context menus, etc., or are you just painting an axis?
> > >
> > >
> > >
> > > "Al Major" <almajor@boxspoon.com> wrote in message
> > > news:cbg64e$e4j$1@eclipse.org...
> > > > hi randy,
> > > >
> > > > i'm still having some trouble with this, so i'm going to try to
> > summarize
> > > > the situation to see if i understand it correctly.
> > > >
> > > > according to the documentation i've seen, the GraphicalViewer is an
> > > > EditPartViewer with it's own RootEditPart and EditPartFactory. i
> somehow
> > > > have the impression that GEF is designed to have a single
> EditPartViewer
> > > per
> > > > editor (workbench editpart). this is (apparently) a mistaken
> impression,
> > > > because......
> > > >
> > > > in the RulerComposite, the top level composite contains (up to) 3
> > > > ScrollingGraphicalViewers, one of them being the "main"
> EditPartViewer,
> > > the
> > > > others being an EditPartViewer for each Ruler. so conceptually,
> there's
> > 3
> > > > models (one for each viewer), apparently tied together with a
> > > RulerProvider
> > > > that exposes the ruler models to the "main" model.
> > > >
> > > > the bulk of the ruler code is straightforward GEF/draw2d code as i
> > > expected.
> > > > just the glue code in the composite is being done SWT style instead
of
> > in
> > > > draw2d. this is what surprised me.
> > > >
> > > > is this an accurate representation of the situation?
> > > >
> > > > if so, and from what you're saying, certain features, such as
> > independant
> > > > scrolling, focus management and keyboard accessibility are difficult
> to
> > > > implement purely with draw2d figures. as a newbie, i don't
understand
> > > enough
> > > > about the architecture to see why this should be so. your word on it
> is
> > > > obviously good. however, i'd like to know if there are other
> situations
> > > > where one or the other (draw2d/SWT) is the obvious choice. has
> anything
> > > been
> > > > written up about this?
> > > >
> > > > in my situation with the ruler/axis potentially in the middle of the
> > > client
> > > > area, the choice comes down to how the model is visualized. if the
> model
> > > can
> > > > be cleanly split so that each sub-model can be visualized in a
> > > > non-overlapping region of the screen, i can use the composite glue
ala
> > > > ruler. however, if there are model elements that must visually
appear
> on
> > > > both sides of the ruler/axis i have to use draw2d as the glue. in
the
> > > second
> > > > case, can you say a little more about the functionality restrictions
> i'm
> > > > likely to run into, and point me at the right parts of the API /
other
> > > > documentation.
> > > >
> > > > thx/regards,
> > > >
> > > > al
> > > >
> > > >
> > > >
> > > >
> > > > "Randy Hudson" <none@us.ibm.com> wrote in message
> > > > news:cbfhnu$ij4$1@eclipse.org...
> > > > > It makes a lot of things easier to implement as a composite. For
> > > example,
> > > > > independant scrolling and also focus management and keyboard
> > > > accessibility.
> > > > > Maybe your graph axis doesn't need some of these functions.
> > > > >
> > > > > "Al Major" <almajor@boxspoon.com> wrote in message
> > > > > news:cbf1ca$l69$1@eclipse.org...
> > > > > > i've been looking at the code for rulers. i'm wondering why the
> top
> > > > level
> > > > > UI
> > > > > > object is a RulerComposite (inheriting from Composite), rather
> than
> > a
> > > > > > RulerEditor (inheriting from EditPart).
> > > > > >
> > > > > > i'm assuming this is because the rulers have to be added to an
> > > existing
> > > > > > editor. if, instead, i'm writing an editor that draws the rulers
> > > itself
> > > > > > (actually it's more like a graph axis than a ruler), would it
make
> > > sense
> > > > > to
> > > > > > have the top level object be an EditPart (and simplifying some
of
> > the
> > > > > ruler
> > > > > > structure? i know i can probably figure this out by looking at
the
> > > code,
> > > > > but
> > > > > > was hoping someone knew the answer off the top of their head.
> > > > > >
> > > > > > also, any pointers on how to go about structuring an editor that
> had
> > > > such
> > > > > > axes/rulers as part of it's model would be appreciated. starting
> > from
> > > > the
> > > > > > ruler code sample.
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > al
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
Goto Forum:
Current Time: Sat May 10 05:13:05 EDT 2025
Powered by FUDForum. Page generated in 0.03530 seconds |
Home