[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [gef-dev] Fw: Who wants to fix something?
|
unified auto-scroll
https://bugs.eclipse.org/bugs/show_bug.cgi?id=44288
I'd
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
behavior:
1. auto-scroll
immediately during marquee selection and moving
EditParts
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
ViewportAutoexposeHelper.
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
it created?
I'd
like to find a unique solution that I want to contribute to GEF to get the bug
fixed. Any ideas are appreciated.
Cu,
Gunnar
The
implementation works.
But
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.
I
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.
Cu,
Gunnar
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.
-randy
|
| Gunnar Wagenknecht
<G.Wagenknecht@xxxxxxxxxxxx>
Sent by: gef-dev-admin@xxxxxxxxxxx
11/18/2003 01:18 AM
Please respond to gef-dev
|
To: "'gef-dev@xxxxxxxxxxx'"
<gef-dev@xxxxxxxxxxx>
cc:
Subject: [gef-dev] Fw: Who wants to
fix something? |
Hi Randy,
"Randy Hudson" <none@xxxxxxxxxx> schrieb
im Newsbeitrag
news:<bp36po$fu7$1@xxxxxxxxxxx>...
> Here's an
isolated bugzilla for someone looking to contribute to GEF:
>
https://bugs.eclipse.org/bugs/show_bug.cgi?id=44288
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
in
#handleHover. Thus, it scrolls immediately without a
wait.
> It involves the class
ViewportAutoexposeHelper.
> 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
time.
Currently
> 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
be
experimented
> with, I'm not convinced this will feel right.
Maybe just 2 speeds, slow
and
> fast, are needed.
Two
speeds are really better but I don't think we need more. Even with the
2
speeds it is hard to get a right feeling if you don't have a very
large
diagram. Maybe we can change the class so that custom scroll ranges
and
speeds are easy to implement?
Cu,
Gunnar
_______________________________________________
gef-dev
mailing
list
gef-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/gef-dev
