[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [gef-dev] Fw: Who wants to fix something?
like to move the auto-scroll possibility into the AbstractTool class. This
would bring us a unified auto-scroll. I'm not sure whether there is a better
solution and what side effects we will have.
Basically our users wants the following
immediately during marquee selection and moving
2. auto-scroll if the mouse pointer is moved
outside the editor window
Missing auto-scoll implementation in the marquee tools
can be corrected by implementing auto-scroll (auto-expose) into AbstractTool.
The first requirement can be
achieved by performing the auto-expose in handleDragInProgress and not in
handleHover. The second requirement can be implemented by changing the
I'm not sure
about how to hanlde native drag and drop into the graphical viewer and drag
and drop from the palette. I think most problematic would be the drag from the
palette into the viewer. Which tool is created for these drags and where is
like to find a unique solution that I want to contribute to GEF to get the bug
fixed. Any ideas are appreciated.
I have some questions regaring other tools. Their are a lot of tools (marquee
selection, connection reconnection and creation) that do not use the
auto expose feature. Should this feature be added to an existing or new
abstract base class for all tools? IMHO it is a base usability requirement
because in a graphical viewer we are not draging objects. We move them and
move tools typically autoscroll.
also noticed, that we don't need two speeds if we allow auto exposing wo
continue when the mouse pointer is moved outside the viewer. In the
current implementation auto exposing stops.
For 1), each time step() is called, compare System.getCurrentMillis()
to the previous time it was called. Then, mulitply the
difference*currentRate to get the real number of pixels to scroll. Make sure
the number is at least 1, and at most some maximum value.
Sent by: gef-dev-admin@xxxxxxxxxxx
11/18/2003 01:18 AM
Please respond to gef-dev
Subject: [gef-dev] Fw: Who wants to
"Randy Hudson" <none@xxxxxxxxxx> schrieb
> Here's an
isolated bugzilla for someone looking to contribute to GEF:
Well, I did a few
evaluations and I noticed that the Marquee... classes
don't use the auto
expose feature. I added it to my implementation and I
also change the
auto exposing to be done in #handleDragInProgress and not
#handleHover. Thus, it scrolls immediately without a
> It involves the class
> Basically, we want:
I increased the
range and added a 2nd range for a faster scroll speed.
> 1) The
amount of scrolled pixels to be constant per unit of
> the speed of the computer and complexity of the
drawing affect the
> autoscroll speed.
I noticed that but I
currently can't see how to achieve this.
> 2) The speed
(pixels/second) to be progressive. This could
> with, I'm not convinced this will feel right.
Maybe just 2 speeds, slow
> fast, are needed.
speeds are really better but I don't think we need more. Even with the
speeds it is hard to get a right feeling if you don't have a very
diagram. Maybe we can change the class so that custom scroll ranges
speeds are easy to implement?