[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [gef-dev] Fw: Who wants to fix something?
|
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
