Re: scrolling on dia, with mouse wheel, scroll tool and keyboard
Le dim, mai 20, 2001, à 12:51:48 -0600, Patrick Sung a écrit: The problems is in ddisplay_update_scrollbars() in display.c, an extra area (namely 'extra_border_x' and 'extra_border_y' is added to the entire scrollable (by scroll bar) area (all 4 side). However with key scrolling it won't work because it never take those extra area into account. Since this extra area break a lot of scrolling function of Dia, I would to suggest to take it off for now until we can better define the scrollable area, drawing area, and viewing area (since this could affect a lot of code on display.c and some other files; and may also affect objects in Dia). What is the impact of your change (what was the extra_border_[xy] variables supposed to do) ? Below is two patches to fix the scrolling problem, one is remove the extra area, the other one is to add support for mouse wheel to scroll up and down. I've applied the latter (mouse wheels), augmented with code to take into account a second wheel (some rare mouses have a second, horizontal wheel). I don't really understand what the first fix fixes. -- Cyrille -- Grumpf.
Re: scrolling on dia, with mouse wheel, scroll tool and keyboard
Cyrille Chepelov wrote: Le dim, mai 20, 2001, à 12:51:48 -0600, Patrick Sung a écrit: The problems is in ddisplay_update_scrollbars() in display.c, an extra area (namely 'extra_border_x' and 'extra_border_y' is added to the entire scrollable (by scroll bar) area (all 4 side). However with key scrolling it won't work because it never take those extra area into account. Since this extra area break a lot of scrolling function of Dia, I would to suggest to take it off for now until we can better define the scrollable area, drawing area, and viewing area (since this could affect a lot of code on display.c and some other files; and may also affect objects in Dia). What is the impact of your change (what was the extra_border_[xy] variables supposed to do) ? When you create a new diagram, the diagram is scrollable. This extra space is created by the extra_border_[xy] variables when the canvas received a GDK_CONFIGURE event (which is triggered once when new diagram is created). Let say if you have a preference setting of 200x200 pixels of initial visible area size, extra_border_[xy] will give an extra 200 pixels to all four sides of the canvas thus making available of 600x600 pixels area *to scroll*. This extra space is reachable only by using the scroll tool or the scroll (not mouse wheel and arrow keys) because the ddisplay_scroll_[direction] functions are called when the mouse wheel and key pressed event is triggered. The ddisplay_scroll_ functions check against the diagram's extent (which is initialized to be smaller 200x200 pixels). Therefore those functions won't scroll the canvas even when you see there are still 200 pixel on each side. None of the objects aware of this extra space created as they are create on the fly when the scrollbar position is being updated (ddisplay_update_scrollbars()). It would look so weird when you can still scroll up using the scroll bar but not using the wheel or arrow keys. ;) hope this clarify the changes. (ps. you can actually assign extra_border_[xy] to zero and see what will happen) Patrick
Re: scrolling on dia, with mouse wheel, scroll tool and keyboard
Cyrille Chepelov wrote: Le dim, mai 20, 2001, à 03:07:50 -0600, Patrick Sung a écrit: hope this clarify the changes. (ps. you can actually assign extra_border_[xy] to zero and see what will happen) Now I see what you mean. With your changes, we get the scrollbar really proportional to the size of the diagram, as would be expected. However, people with small screens will have a problem: now they really have to use the scroll tool to put an object outside of the visible area. I'm a bit tempted by your patch ; until now, I really didn't see the point of using the scroll tool. Having scrollbars consistent with the size of the diagram, and scrollbar behaviour consistent with arrow/wheel scrolling is a Good Thing(tm). OTOH, having the scrollbar scrollable area bigger than the diagram's size can prove itself handy on a small screen. This is why we need some new variables to define such a scrollbar scrollable area. Maybe we can utilize the page layout view like we used to have in a word processor (or Visio) to distinguish between the drawable (and printable) area. Now if a user want to draw outside, they can create a new page. So when you create a new diagram, only one page is displayed (and scrollable if the screen size isn't large enough). This won't destroy the use of the printable area grid line and also gives users a better control of placement of objects in a page. I've committed a one-liner to put extra_border_x = extra_border_y = 0; let's see the reactions. Perhaps it'll be better to let the user choose the behaviour (but I really don't see how to formulate such an option, in a way understandable by users). Thanks Patrick
