[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
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
-----Original Message-----
From: Gunnar Wagenknecht [mailto:G.Wagenknecht@xxxxxxxxxxxx]
Sent: Friday, November 28, 2003 1:46 PM
To: 'gef-dev@xxxxxxxxxxx'
Subject: 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
-----Original Message-----
From: Randy Hudson [mailto:hudsonr@xxxxxxxxxx]
Sent: Tuesday, November 18, 2003 4:56 PM
To: gef-dev@xxxxxxxxxxx
Subject: Re: [gef-dev] Fw: Who wants to fix something?

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.


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>
        Subject:        [gef-dev] Fw: Who wants to fix something?

Hi Randy,

"Randy Hudson" <none@xxxxxxxxxx> schrieb im Newsbeitrag
> 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.
> 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
> with, I'm not convinced this will feel right.  Maybe just 2 speeds, slow
> 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