Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » GEF » scrolling graphical viewer
scrolling graphical viewer [message #46144] Fri, 29 November 2002 01:40 Go to next message
Eclipse UserFriend
Originally posted by: jayuen.alumni.uwaterloo.ca

Hi:

I was wondering how I can set up the ScrollingGraphicalViewer such that even
if there aren't any EditParts that are outside of the visible portion of the
viewer, I can still scroll? Currently, if I want to expand the drawing area
of my graphical editor, it seems like the only way I can do this is by
creating a new EditPart, dragging it outside of the viewing area, and then
releasing. Subsequently, the scrollbars appear and I am able to scroll to
the edit part.

I was hoping to be able to increase the size of the scrolling area without
necessarily having edit parts created. I noticed that one of the bug
reports (22873) refers to auto-scrolling the graphical viewer on a drag. I
guess the functionality I am seeking is similar except that the graphical
viewer is scrolled by simply clicking the scrollbar arrows.

Thanks for any help!
Jason
Re: scrolling graphical viewer [message #46176 is a reply to message #46144] Fri, 29 November 2002 02:25 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: hudsonr.us.eye-bee-em.com

How big is big enough? You could put a MarginBorder on the primary layer.
Actually, there already is one there with size of 5 pixels. This prevents
selection handles from causing scrollbar changes.

"Jason Yuen" <jayuen@alumni.uwaterloo.ca> wrote in message
news:as6gfj$msi$1@rogue.oti.com...
> Hi:
>
> I was wondering how I can set up the ScrollingGraphicalViewer such that
even
> if there aren't any EditParts that are outside of the visible portion of
the
> viewer, I can still scroll? Currently, if I want to expand the drawing
area
> of my graphical editor, it seems like the only way I can do this is by
> creating a new EditPart, dragging it outside of the viewing area, and then
> releasing. Subsequently, the scrollbars appear and I am able to scroll to
> the edit part.
>
> I was hoping to be able to increase the size of the scrolling area without
> necessarily having edit parts created. I noticed that one of the bug
> reports (22873) refers to auto-scrolling the graphical viewer on a drag.
I
> guess the functionality I am seeking is similar except that the graphical
> viewer is scrolled by simply clicking the scrollbar arrows.
>
> Thanks for any help!
> Jason
>
>
Re: scrolling graphical viewer [message #46206 is a reply to message #46176] Fri, 29 November 2002 04:40 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: jayuen.alumni.uwaterloo.ca

Hi Randy:

1. How big is big enough?

Well, I was hoping that the user could scroll infinitely in either
direction. In some drawing apps (like Visio), the user can keep scrolling
even though there aren't any glyphs in the area to which he is scrolling.
The more he clicks on the scroll arrow, the thinner the scroll bar gets.
Currently, it seems the scroll bar scrolls only once the user has placed a
glyph outside the boundaries of the viewer. Basically, I would like the
user to be able to "grow" the drawing area simply through scrolling.

I looked at some of the methods in the Viewport class and tried to invoke
setContentsTracksHeight(false) and setContentsTracksWidth(false) but to no
avail.. I also looked at the RangeModel interface but I suspect that I'm
barking up the wrong tree :).

2. Margin border

Forgive me for my ignorance but I'm not entirely sure how a MarginBorder
would allow for the behaviour that I'm looking for. I searched the GEF
code and the only margin borders that seem to be created are in the palette
edit parts and none with respect to the primary layer. If possible, could
you clarify this suggestion?

Thanks a lot for your help,

Jason

"Randy Hudson" <hudsonr@us.eye-bee-em.com> wrote in message
news:as6j64$nm5$1@rogue.oti.com...
> How big is big enough? You could put a MarginBorder on the primary layer.
> Actually, there already is one there with size of 5 pixels. This prevents
> selection handles from causing scrollbar changes.
>
> "Jason Yuen" <jayuen@alumni.uwaterloo.ca> wrote in message
> news:as6gfj$msi$1@rogue.oti.com...
> > Hi:
> >
> > I was wondering how I can set up the ScrollingGraphicalViewer such that
> even
> > if there aren't any EditParts that are outside of the visible portion of
> the
> > viewer, I can still scroll? Currently, if I want to expand the drawing
> area
> > of my graphical editor, it seems like the only way I can do this is by
> > creating a new EditPart, dragging it outside of the viewing area, and
then
> > releasing. Subsequently, the scrollbars appear and I am able to scroll
to
> > the edit part.
> >
> > I was hoping to be able to increase the size of the scrolling area
without
> > necessarily having edit parts created. I noticed that one of the bug
> > reports (22873) refers to auto-scrolling the graphical viewer on a drag.
> I
> > guess the functionality I am seeking is similar except that the
graphical
> > viewer is scrolled by simply clicking the scrollbar arrows.
> >
> > Thanks for any help!
> > Jason
> >
> >
>
>
Re: scrolling graphical viewer [message #46234 is a reply to message #46206] Fri, 29 November 2002 14:29 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: hudsonr.us.eye-bee-em.com

The canvas is represented with "freeform" figures. Freeform-figures are
"shrink-wrapped" containers around their children. So, if you take the
Rectangle that encompasses all children of the primary layer, the primary
layer is at least that big. I say at least, because after this rectangle is
found, it is expanded by the Border that is set on the FreeformLayer. So,
if the borders insets are 1000 pixels all around, the "shrink-wrapping" will
be 1000 pixels larger than the rectangle needed to encompass the children.
This will cause a certain of free scrolling.

I don't like Visio behavior. If you scroll way off the center of the
diagram, how do you get back? I guess if you have a ruler you might have a
clue as to where the origin is. Pretty soon you will be able to drag an item
infinitely (well, until 2^31) in the logic example. The feedback layer
causes the scrolling bounds to change, and we are about to implement
autoscroll, so as the diagram scrolls down, the feedback layer will continue
to push the bottom limit down further.

"Jason Yuen" <jayuen@alumni.uwaterloo.ca> wrote in message
news:as6r0l$pv3$1@rogue.oti.com...
> Hi Randy:
>
> 1. How big is big enough?
>
> Well, I was hoping that the user could scroll infinitely in either
> direction. In some drawing apps (like Visio), the user can keep scrolling
> even though there aren't any glyphs in the area to which he is scrolling.
> The more he clicks on the scroll arrow, the thinner the scroll bar gets.
> Currently, it seems the scroll bar scrolls only once the user has placed a
> glyph outside the boundaries of the viewer. Basically, I would like the
> user to be able to "grow" the drawing area simply through scrolling.
>
> I looked at some of the methods in the Viewport class and tried to invoke
> setContentsTracksHeight(false) and setContentsTracksWidth(false) but to no
> avail.. I also looked at the RangeModel interface but I suspect that I'm
> barking up the wrong tree :).
>
> 2. Margin border
>
> Forgive me for my ignorance but I'm not entirely sure how a MarginBorder
> would allow for the behaviour that I'm looking for. I searched the GEF
> code and the only margin borders that seem to be created are in the
palette
> edit parts and none with respect to the primary layer. If possible,
could
> you clarify this suggestion?
>
> Thanks a lot for your help,
>
> Jason
>
> "Randy Hudson" <hudsonr@us.eye-bee-em.com> wrote in message
> news:as6j64$nm5$1@rogue.oti.com...
> > How big is big enough? You could put a MarginBorder on the primary
layer.
> > Actually, there already is one there with size of 5 pixels. This
prevents
> > selection handles from causing scrollbar changes.
> >
> > "Jason Yuen" <jayuen@alumni.uwaterloo.ca> wrote in message
> > news:as6gfj$msi$1@rogue.oti.com...
> > > Hi:
> > >
> > > I was wondering how I can set up the ScrollingGraphicalViewer such
that
> > even
> > > if there aren't any EditParts that are outside of the visible portion
of
> > the
> > > viewer, I can still scroll? Currently, if I want to expand the
drawing
> > area
> > > of my graphical editor, it seems like the only way I can do this is by
> > > creating a new EditPart, dragging it outside of the viewing area, and
> then
> > > releasing. Subsequently, the scrollbars appear and I am able to
scroll
> to
> > > the edit part.
> > >
> > > I was hoping to be able to increase the size of the scrolling area
> without
> > > necessarily having edit parts created. I noticed that one of the bug
> > > reports (22873) refers to auto-scrolling the graphical viewer on a
drag.
> > I
> > > guess the functionality I am seeking is similar except that the
> graphical
> > > viewer is scrolled by simply clicking the scrollbar arrows.
> > >
> > > Thanks for any help!
> > > Jason
> > >
> > >
> >
> >
>
>
Re: scrolling graphical viewer [message #46264 is a reply to message #46234] Fri, 29 November 2002 16:32 Go to previous message
Eclipse UserFriend
Originally posted by: jayuen.alumni.uwaterloo.ca

I see what you mean now with the border. I experimented a little bit with
padding the primary layer but it's not the greatest. I think the upcoming
auto-scroll will be the best.

Yeah, I was envisioning a canvas with a ruler so that the user could
re-locate himself. I was also thinking that if I add zoom capabilities
later on, it wouldn't be that bad to navigate a (potentially) very large
canvas

Anyhow. thanks for your help,

Jason

"Randy Hudson" <hudsonr@us.eye-bee-em.com> wrote in message
news:as7tkg$am4$1@rogue.oti.com...
> The canvas is represented with "freeform" figures. Freeform-figures are
> "shrink-wrapped" containers around their children. So, if you take the
> Rectangle that encompasses all children of the primary layer, the primary
> layer is at least that big. I say at least, because after this rectangle
is
> found, it is expanded by the Border that is set on the FreeformLayer. So,
> if the borders insets are 1000 pixels all around, the "shrink-wrapping"
will
> be 1000 pixels larger than the rectangle needed to encompass the children.
> This will cause a certain of free scrolling.
>
> I don't like Visio behavior. If you scroll way off the center of the
> diagram, how do you get back? I guess if you have a ruler you might have a
> clue as to where the origin is. Pretty soon you will be able to drag an
item
> infinitely (well, until 2^31) in the logic example. The feedback layer
> causes the scrolling bounds to change, and we are about to implement
> autoscroll, so as the diagram scrolls down, the feedback layer will
continue
> to push the bottom limit down further.
>
> "Jason Yuen" <jayuen@alumni.uwaterloo.ca> wrote in message
> news:as6r0l$pv3$1@rogue.oti.com...
> > Hi Randy:
> >
> > 1. How big is big enough?
> >
> > Well, I was hoping that the user could scroll infinitely in either
> > direction. In some drawing apps (like Visio), the user can keep
scrolling
> > even though there aren't any glyphs in the area to which he is
scrolling.
> > The more he clicks on the scroll arrow, the thinner the scroll bar gets.
> > Currently, it seems the scroll bar scrolls only once the user has placed
a
> > glyph outside the boundaries of the viewer. Basically, I would like
the
> > user to be able to "grow" the drawing area simply through scrolling.
> >
> > I looked at some of the methods in the Viewport class and tried to
invoke
> > setContentsTracksHeight(false) and setContentsTracksWidth(false) but to
no
> > avail.. I also looked at the RangeModel interface but I suspect that I'm
> > barking up the wrong tree :).
> >
> > 2. Margin border
> >
> > Forgive me for my ignorance but I'm not entirely sure how a MarginBorder
> > would allow for the behaviour that I'm looking for. I searched the GEF
> > code and the only margin borders that seem to be created are in the
> palette
> > edit parts and none with respect to the primary layer. If possible,
> could
> > you clarify this suggestion?
> >
> > Thanks a lot for your help,
> >
> > Jason
> >
> > "Randy Hudson" <hudsonr@us.eye-bee-em.com> wrote in message
> > news:as6j64$nm5$1@rogue.oti.com...
> > > How big is big enough? You could put a MarginBorder on the primary
> layer.
> > > Actually, there already is one there with size of 5 pixels. This
> prevents
> > > selection handles from causing scrollbar changes.
> > >
> > > "Jason Yuen" <jayuen@alumni.uwaterloo.ca> wrote in message
> > > news:as6gfj$msi$1@rogue.oti.com...
> > > > Hi:
> > > >
> > > > I was wondering how I can set up the ScrollingGraphicalViewer such
> that
> > > even
> > > > if there aren't any EditParts that are outside of the visible
portion
> of
> > > the
> > > > viewer, I can still scroll? Currently, if I want to expand the
> drawing
> > > area
> > > > of my graphical editor, it seems like the only way I can do this is
by
> > > > creating a new EditPart, dragging it outside of the viewing area,
and
> > then
> > > > releasing. Subsequently, the scrollbars appear and I am able to
> scroll
> > to
> > > > the edit part.
> > > >
> > > > I was hoping to be able to increase the size of the scrolling area
> > without
> > > > necessarily having edit parts created. I noticed that one of the
bug
> > > > reports (22873) refers to auto-scrolling the graphical viewer on a
> drag.
> > > I
> > > > guess the functionality I am seeking is similar except that the
> > graphical
> > > > viewer is scrolled by simply clicking the scrollbar arrows.
> > > >
> > > > Thanks for any help!
> > > > Jason
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Previous Topic:Change the Container Size as the child size changed?
Next Topic:Single Model - Layered views
Goto Forum:
  


Current Time: Thu Dec 26 15:03:14 GMT 2024

Powered by FUDForum. Page generated in 0.04312 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top