From: Guillaume L. <gla...@te...> - 2006-09-16 21:00:18
|
A long time ago we spent countless hours trying to get auto-scrolling right, and we did, as far as the move itself is concerned. However, how this move is propagated needs to be reworked. Looking into this bug https://sourceforge.net/tracker/?func=detail&atid=104932&aid=1052780&group_id=4932 I checked how autoscrolling is working in matrix and notation view, and I see a couple of issues : - autoscrolling while moving the insertion pointer happens way too fast (looks like a feedback loop) - that's clearly a bug, no questions here - autoscrolling while moving the playback pointer is propagated to the segment canvas. This is not by accident, but I'm not sure if it's such a good idea. - autoscrolling while defining a loop is broken (just doesn't happen) - like with the playback pointer, I think it should happen only in the current view and not be propagated to the segment canvas. Any comments on the last two issues ? Should autoscrolling happen both in the current view and in the segment canvas ? -- Guillaume. http://www.telegraph-road.org |
From: D. M. M. <ros...@gm...> - 2006-09-17 00:17:15
|
On Saturday 16 September 2006 5:00 pm, Guillaume Laurent wrote: > - autoscrolling while moving the playback pointer is propagated to the > segment canvas. This is not by accident, but I'm not sure if it's such a > good idea. > > - autoscrolling while defining a loop is broken (just doesn't happen) - > like with the playback pointer, I think it should happen only in the > current view and not be propagated to the segment canvas. > > Any comments on the last two issues ? Should autoscrolling happen both in > the current view and in the segment canvas ? Probably eats CPU for breakfast, doesn't it? I think it might be sufficient to just autoscroll the active view and let the others catch up when you let go. Just so they *do* catch up when you let go. Having everything move in sync would look cool, but we have too many complaints about excessive CPU loading as it is. Another thing I noticed earlier today, autoscrolling while drawing out a long selection in notation doesn't seem to happen. Requires wiggling the mouse back and forth to keep things moving. -- D. Michael McIntyre Linux fanatic, and certified Geek; registered Linux user #243621 Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/ |
From: Martin S. <mc...@as...> - 2006-09-17 00:37:03
|
On Sat, 16 Sep 2006, D. Michael McIntyre wrote: > On Saturday 16 September 2006 5:00 pm, Guillaume Laurent wrote: > Another thing I noticed earlier today, autoscrolling while drawing out a long > selection in notation doesn't seem to happen. Requires wiggling the mouse > back and forth to keep things moving. The same happens in matrix. I've been meaning to mention this for a while, but was waiting until I had had a chance to look at the code. I find that to get the sideways scroll to start in the matrix view, I have to be move the cursor very quickly from the start point of the selection to the edge of the window, or no scrolling occurs. With the touch-pad of my laptop this is really difficult, and the only way that I have found to get it to work reliably, is to first manually scroll the start point of the selection near to the edge of the window that I want to extent past, before starting the selection. Once I finally manage to get the scroll to start, it then quickly accelerates until it is too fast to control, and when I try to slow it down by moving the cursor back into the window, the scroll stops and won't restart. I thus have to cancel the selection and start again. I imagine that this might not be such a problem when using a mouse, but it is very difficult when using a touch-pad, as I do. In much older versions of rosegarden, sideways scrolling used to work much more predictably, although it used to go uncontrollably fast. Rather than having the scroll accelerate, what I would prefer would be if the scrolling velocity were proportional to the distance that the cursor lies past the end of the view. This would allow better control of the scrolling speed. By the way, thanks to Chris for fixing the "%s parameters" labelling problem. That gem was in the parameter-area code that I originally wrote. So I was planning to try to find time to fix it this weekend. Martin |
From: Guillaume L. <gla...@te...> - 2006-09-23 23:47:38
|
On Saturday 16 September 2006 23:00, Guillaume Laurent wrote: > A long time ago we spent countless hours trying to get auto-scrolling > right, and we did, as far as the move itself is concerned. However, how > this move is propagated needs to be reworked. Looking into this bug > > https://sourceforge.net/tracker/?func=detail&atid=104932&aid=1052780&group_ >id=4932 > > I checked how autoscrolling is working in matrix and notation view, and I > see a couple of issues : > > - autoscrolling while moving the insertion pointer happens way too fast > (looks like a feedback loop) - that's clearly a bug, no questions here > > - autoscrolling while moving the playback pointer is propagated to the > segment canvas. This is not by accident, but I'm not sure if it's such a > good idea. > > - autoscrolling while defining a loop is broken (just doesn't happen) - > like with the playback pointer, I think it should happen only in the > current view and not be propagated to the segment canvas. > > Any comments on the last two issues ? Should autoscrolling happen both in > the current view and in the segment canvas ? Fixes are in, except for the first issue (autoscrolling happens too quickly in some cases), which I haven't really looked into. -- Guillaume. http://www.telegraph-road.org |
From: D. M. M. <ros...@gm...> - 2006-09-24 02:28:33
|
On Saturday 23 September 2006 7:47 pm, Guillaume Laurent wrote: > Fixes are in, except for the first issue (autoscrolling happens too quickly > in some cases), which I haven't really looked into. Right in time for the release! :D I'll have to play with this, but the code looked good, and I'm optimistic that I'm about to be suitably impressed. -- D. Michael McIntyre Linux fanatic, and certified Geek; registered Linux user #243621 Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/ |
From: Martin S. <mc...@as...> - 2006-09-24 09:43:50
|
On Saturday 23 September 2006 7:47 pm, Guillaume Laurent wrote: > Fixes are in, except for the first issue (autoscrolling happens too quickly > in some cases), which I haven't really looked into. I just tried this (assuming that it is the version in svn), but it now doesn't seem to be possible to place the insertion cursor with the mouse, at all. Whenever I click on the bar above the matrix view, the insertion cursor initially appears in the right place, but as soon as I release the mouse button, the insertion cursor disappears, and turns out to have gone back to near the beginning of the composition. Also, although auto-scrolling forwards appears to work well (ignoring what happens after one releases the mouse button), auto-scrolling backwards zips back too fast to see. Martin |
From: Chris C. <ca...@al...> - 2006-09-24 13:09:23
|
On Sunday 24 Sep 2006 10:43, Martin Shepherd wrote: > I just tried this (assuming that it is the version in svn), but it > now doesn't seem to be possible to place the insertion cursor with > the mouse, at all. Whenever I click on the bar above the matrix view, > the insertion cursor initially appears in the right place, but as > soon as I release the mouse button, the insertion cursor disappears, > and turns out to have gone back to near the beginning of the > composition. It looks like the ruler is failing to take the current offset into account. If the view is scrolled hard left, then placing the pointer works correctly. If you scroll a bit to the right, then the pointer appears in the right place when you click, but on release it jumps back by the distance that you had scrolled right by. Scroll a lot to the right, and it jumps off the screen. This applies to all views, not just the matrix. Probably a one-liner, some signal call failing to add in the current offset. Scrolling while setting a loop works in the top and bottom rulers in the main view, and in the top ruler in the matrix, but it doesn't work at all for me in the bottom ruler in the matrix or any ruler in notation. I'm not sure whether that's new behaviour or not (it likely isn't). Autoscrolling when dragging the insertion cursor in the notation view is now absurdly fast. It was too fast before -- we never had the incremental scroll when doing that -- but it will happily skip through the whole composition in one or two jumps now. Autoscrolling when dragging the playback pointer in the notation view doesn't work -- it jumps back and forward repeatedly between the start and incremental positions. That one definitely isn't new behaviour, but it would be nice to see it fixed. Chris |
From: Guillaume L. <gla...@te...> - 2006-09-24 23:23:29
|
On Sunday 24 September 2006 15:12, Chris Cannam wrote: > Scrolling while setting a loop works in the top and bottom rulers in th= e > main view, and in the top ruler in the matrix, but it doesn't work at > all for me in the bottom ruler in the matrix or any ruler in notation. = =A0 > I'm not sure whether that's new behaviour or not (it likely isn't). Strange that it wouldn't work with the bottom ruler, the problem was the = same=20 in both cases : you really needed to move the mouse very quickly in one=20 direction to "jumpstart" the autoscroll. Strangely enough, turning the st= atic=20 vars used to compute the autoscroll into plain members seem to have fixed= it=20 (as noted in the svn commit note, my guess is that the static was being=20 accessed through different objects). In any case, as far as I can test, autoscrolling while defining a loop is= =20 working again. Can everyone confirm ? --=20 Guillaume. http://www.telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2006-09-24 15:22:24
|
On Sunday 24 September 2006 11:43, Martin Shepherd wrote: > On Saturday 23 September 2006 7:47 pm, Guillaume Laurent wrote: > > Fixes are in, except for the first issue (autoscrolling happens too > > quickly in some cases), which I haven't really looked into. > > I just tried this (assuming that it is the version in svn), but it now > doesn't seem to be possible to place the insertion cursor with the > mouse, at all. Whenever I click on the bar above the matrix view, the > insertion cursor initially appears in the right place, but as soon as > I release the mouse button, the insertion cursor disappears, and turns > out to have gone back to near the beginning of the composition. Woops, just committed a fix for that (thanks Chris for pointing out the cause). > Also, > although auto-scrolling forwards appears to work well (ignoring what > happens after one releases the mouse button), auto-scrolling backwards > zips back too fast to see. Yes, I haven't looked into that yet. I haven't fixed the autoscrolling when defining a loop either. (and I haven't received any of the replies to this thread, except those which were cc'd to me - sigh) -- Guillaume. http://www.telegraph-road.org |
From: Martin S. <mc...@as...> - 2006-09-24 23:50:08
|
On Sun, 24 Sep 2006, Guillaume Laurent wrote: > Woops, just committed a fix for that (thanks Chris for pointing out the > cause). Thanks. However note that the fix restores the lightning-fast autoscrolling behaviour. I have just taken a look through the code, and I can see what is causing the lightning fast scrolling. What happens is the following: If you click and hold down the mouse button in the top ruler above the matrix, (what do you call this ruler?), and drag it to the right, to move the insert cursor, then when the mouse has been moved to a position 90% of the way across the view, slotScrollHoriz(), in rosegardencanvasview.cpp, moves the view by 60% of the visible area to the right. The result is that now the user is holding down the mouse button 60% of the visible area to the right of the new scroll right position, and so slotScrollHoriz() again scrolls by another 60% of the visible area, and this keeps happening until the end of the segment is reached, or the user lets go of the mouse button. Although I haven't yet found out what handler controls the smooth scroll, it looks as though it kicks in just to the right of where the paging scroll is triggered, such that if you click past the 90% position, then the smooth scroll is triggered rather than the paging scroll. To verify that this was the case I tried disabling "page" scrolling by overriding the value of the scroll argument that slotSetInsertCursorPosition() receives. When I assigned it 0, then smooth scrolling of the insertion cursor appeared to work perfectly. So I believe the fix is to call slotSetInsertCursorPosition() with its optional scroll argument set to 0, when calling it from the mouse handler of the ruler. I haven't figured out how to do that yet. Martin |
From: Martin S. <mc...@as...> - 2006-09-25 00:15:24
|
On Sun, 24 Sep 2006, Martin Shepherd wrote: >... > So I believe the fix is to call slotSetInsertCursorPosition() with its > optional scroll argument set to 0, when calling it from the mouse handler > of the ruler. I haven't figured out how to do that yet. Okay, the following patch does this, and it appears to work. If this is accepted as a solution, then the same thing will need to be done for the notation view etc... Index: gui/matrixview.h =================================================================== --- gui/matrixview.h (revision 7549) +++ gui/matrixview.h (working copy) @@ -360,6 +360,10 @@ slotSetInsertCursorPosition(position, true); } + virtual void slotSetInsertCursorPositionUnscrolled(Rosegarden::timeT position) { + slotSetInsertCursorPosition(position, false); + } + /** * Catch the keyboard being pressed */ Index: gui/matrixview.cpp =================================================================== --- gui/matrixview.cpp (revision 7549) +++ gui/matrixview.cpp (working copy) @@ -415,12 +415,12 @@ QObject::connect (topBarButtons->getLoopRuler(), SIGNAL(setPointerPosition(Rosegarden::timeT)), - this, SLOT(slotSetInsertCursorPosition(Rosegarden::timeT))); + this, SLOT(slotSetInsertCursorPositionUnscrolled(Rosegarden::timeT))); QObject::connect (topBarButtons, SIGNAL(dragPointerToPosition(Rosegarden::timeT)), - this, SLOT(slotSetInsertCursorPosition(Rosegarden::timeT))); + this, SLOT(slotSetInsertCursorPositionUnscrolled(Rosegarden::timeT))); topBarButtons->getLoopRuler()->setBackgroundColor (Rosegarden::GUIPalette::getColour(Rosegarden::GUIPalette::InsertCursorRuler)); |
From: Martin S. <mc...@as...> - 2006-09-25 02:44:02
|
What my previous patch didn't address, was another problem that I previously noted, wherein if one didn't manage to drag the cursor quickly enough to the edge of the matrix view, smooth scrolling didn't start. The following patch, which includes the previous patch, fixes this as well. Basically, there was a clause in doAutoScroll() (in rosegardencanvasview.cpp), that turned off autoscrolling if no autoscrolling motions were performed within 20 move events. Since no autoscrolling occurs until the cursor nears the edges of the display area, autoscrolling thus got cancelled if one started with the cursor near the middle of the display area, and then dragged at a reasonable speed towards an edge. I suspect that the above clause was designed to stop the effect whereby after pausing a drag, when one has already reached a high speed, the scrolling restarts at that high speed, when the user starts moving the mouse again. A better way to deal with this, IMHO, is to simply knock the auto-scroll speed back down to its default start value, whenever the user pauses dragging, and this is what the patch below does. Note that this also fixes the same problem that occured with dragging out the selection, in the matrix view. While this patch appears to fix all of the auto-scrolling issues of the matrix view, I haven't worked out equivalent fixes for the notation view, since auto-scrolling/paged-scrolling seem to be triggered a bit differently there, and I haven't had time to figure out how this works. Index: gui/matrixview.h =================================================================== --- gui/matrixview.h (revision 7549) +++ gui/matrixview.h (working copy) @@ -360,6 +360,10 @@ slotSetInsertCursorPosition(position, true); } + virtual void slotSetInsertCursorPositionUnscrolled(Rosegarden::timeT position) { + slotSetInsertCursorPosition(position, false); + } + /** * Catch the keyboard being pressed */ Index: gui/rosegardencanvasview.cpp =================================================================== --- gui/rosegardencanvasview.cpp (revision 7549) +++ gui/rosegardencanvasview.cpp (working copy) @@ -138,8 +138,6 @@ QPoint dp = p - previousP; previousP = p; - static int quiet = 0; - m_autoScrollTimer.start( m_autoScrollTime ); ScrollDirection scrollDirection = None; @@ -190,15 +188,9 @@ // is presumably still pressed. m_minDeltaScroll = DefaultMinDeltaScroll; m_currentScrollDirection = None; + } else { + m_minDeltaScroll = DefaultMinDeltaScroll; } - - if (dx || dy) quiet = 0; - else ++quiet; - - if (quiet == 20) { - stopAutoScroll(); - quiet = 0; - } } Index: gui/matrixview.cpp =================================================================== --- gui/matrixview.cpp (revision 7549) +++ gui/matrixview.cpp (working copy) @@ -415,12 +415,12 @@ QObject::connect (topBarButtons->getLoopRuler(), SIGNAL(setPointerPosition(Rosegarden::timeT)), - this, SLOT(slotSetInsertCursorPosition(Rosegarden::timeT))); + this, SLOT(slotSetInsertCursorPositionUnscrolled(Rosegarden::timeT))); QObject::connect (topBarButtons, SIGNAL(dragPointerToPosition(Rosegarden::timeT)), - this, SLOT(slotSetInsertCursorPosition(Rosegarden::timeT))); + this, SLOT(slotSetInsertCursorPositionUnscrolled(Rosegarden::timeT))); topBarButtons->getLoopRuler()->setBackgroundColor (Rosegarden::GUIPalette::getColour(Rosegarden::GUIPalette::InsertCursorRuler)); |
From: Chris C. <ca...@al...> - 2006-09-25 09:19:12
|
On Monday 25 Sep 2006 02:39, Martin Shepherd wrote: > What my previous patch didn't address, was another problem that I > previously noted, wherein if one didn't manage to drag the cursor > quickly enough to the edge of the matrix view, smooth scrolling > didn't start. The following patch, which includes the previous patch, > fixes this as well. I think there's some conflict between that patch and Guillaume's last commit -- the patch doesn't apply over it, and it does look like a real conflict where the same code has been modified in two different ways. Any chance of one of you testing out both options and resolving that? Chris |
From: Martin S. <mc...@as...> - 2006-09-25 19:07:29
|
Hi Chris, On Mon, 25 Sep 2006, Chris Cannam wrote: > On Monday 25 Sep 2006 02:39, Martin Shepherd wrote: >> What my previous patch didn't address, was another problem that I >> previously noted, wherein if one didn't manage to drag the cursor >> quickly enough to the edge of the matrix view, smooth scrolling >> didn't start. The following patch, which includes the previous patch, >> fixes this as well. > > I think there's some conflict between that patch and Guillaume's last > commit -- the patch doesn't apply over it, and it does look like a real > conflict where the same code has been modified in two different ways. Curious. I modified the code after doing an svn update. Since this followed Guillarme's post about his patch, I assumed that I was modifying against his final patch. Was this not made to trunk? Martin |
From: Chris C. <ca...@al...> - 2006-09-25 19:09:37
|
On Monday 25 Sep 2006 20:07, Martin Shepherd wrote: > Curious. I modified the code after doing an svn update. Since this > followed Guillarme's post about his patch, I assumed that I was > modifying against his final patch. Was this not made to trunk? Yes, I think it was. I'm up-to-date on trunk now and svn diff reports no local changes, yet your patch doesn't apply. Chris |
From: Martin S. <mc...@as...> - 2006-09-25 19:35:27
|
On Mon, 25 Sep 2006, Chris Cannam wrote: > On Monday 25 Sep 2006 20:07, Martin Shepherd wrote: >> Curious. I modified the code after doing an svn update. Since this >> followed Guillarme's post about his patch, I assumed that I was >> modifying against his final patch. Was this not made to trunk? > > Yes, I think it was. I'm up-to-date on trunk now and svn diff reports > no local changes, yet your patch doesn't apply. I'm guessing that Guillarme made another patch after his announcement. I just now deleted my changes, and did another svn update. I can't immediately see what was done to fix the problem, but it does appear to be fixed in trunk. Thus my patch would appear to be redundant. Martin |
From: Chris C. <ca...@al...> - 2006-09-25 19:40:43
|
On Monday 25 Sep 2006 20:34, Martin Shepherd wrote: > I'm guessing that Guillarme made another patch after his > announcement. There's a mailing list (rg-bugs) that gets notifications of all the Subversion commits, if you want to check that kind of thing. > I can't immediately see what was done to fix the problem, but > it does appear to be fixed in trunk. Thus my patch would appear to > be redundant. Didn't your patch cover a couple of different problems? Chris |
From: Martin S. <mc...@as...> - 2006-09-25 20:13:52
|
On Mon, 25 Sep 2006, Chris Cannam wrote: > On Monday 25 Sep 2006 20:34, Martin Shepherd wrote: >> I'm guessing that Guillarme made another patch after his >> announcement. > > There's a mailing list (rg-bugs) that gets notifications of all the > Subversion commits, if you want to check that kind of thing. Ah. I wasn't aware of that. I have just submitted a request to join the list. >> I can't immediately see what was done to fix the problem, but >> it does appear to be fixed in trunk. Thus my patch would appear to >> be redundant. > > Didn't your patch cover a couple of different problems? Yes. However Guillarme's patches appear to have completely fixed one of them, and fixed the worst part of the other. In fact, the difference between the effect of the latter patch and mine, may simply reflect a difference of opinion in how things should behave. The diffence is in the way rosegarden behaves to pausing during autoscrolling, with the mouse button still held down, but in a part of the visible area that doesn't trigger scrolling. With Guillarme's patch, scrolling restarts with the same speed as before, when the mouse is again moved into the autoscrolling region, whereas with mine, it starts from the slow initial default speed. The following patch, which I just made, relative to the latest code in trunk, implements the latter behavior. Guillarme should probably vet this before it is officially applied to trunk. Index: gui/rosegardencanvasview.cpp =================================================================== --- gui/rosegardencanvasview.cpp (revision 7552) +++ gui/rosegardencanvasview.cpp (working copy) @@ -40,7 +40,6 @@ m_minDeltaScroll(DefaultMinDeltaScroll), m_autoScrollTime(InitialScrollTime), m_autoScrollAccel(InitialScrollAccel), - m_quiet(0), m_autoScrollXMargin(0), m_autoScrollYMargin(0), m_currentScrollDirection(None), @@ -92,7 +91,6 @@ const int RosegardenCanvasView::AutoscrollMargin = 16; const int RosegardenCanvasView::InitialScrollTime = 30; const int RosegardenCanvasView::InitialScrollAccel = 5; -const int RosegardenCanvasView::QuietScrollMaxCount = 20; const int RosegardenCanvasView::MaxScrollDelta = 100; // max a.scroll speed const double RosegardenCanvasView::ScrollAccelValue = 1.04;// acceleration rate @@ -139,8 +137,6 @@ QPoint dp = p - m_previousP; m_previousP = p; - m_quiet = 0; - m_autoScrollTimer.start( m_autoScrollTime ); ScrollDirection scrollDirection = None; @@ -189,20 +185,12 @@ m_minDeltaScroll = MaxScrollDelta; m_currentScrollDirection = scrollDirection; - } else if (dx || dy) { + } else { // Don't automatically stopAutoScroll() here, the mouse button // is presumably still pressed. m_minDeltaScroll = DefaultMinDeltaScroll; m_currentScrollDirection = None; } - - if (dx || dy) m_quiet = 0; - else ++m_quiet; - - if (m_quiet == QuietScrollMaxCount) { - stopAutoScroll(); - m_quiet = 0; - } } Index: gui/rosegardencanvasview.h =================================================================== --- gui/rosegardencanvasview.h (revision 7552) +++ gui/rosegardencanvasview.h (working copy) @@ -153,7 +153,6 @@ QTimer m_autoScrollTimer; int m_autoScrollTime; int m_autoScrollAccel; - int m_quiet; QPoint m_previousP; int m_autoScrollXMargin; int m_autoScrollYMargin; @@ -168,7 +167,6 @@ static const int InitialScrollTime; static const int InitialScrollAccel; static const int MaxScrollDelta; - static const int QuietScrollMaxCount; static const double ScrollAccelValue; }; Index: gui/rosegardenscrollview.h =================================================================== --- gui/rosegardenscrollview.h (revision 7552) +++ gui/rosegardenscrollview.h (working copy) @@ -148,7 +148,6 @@ QTimer m_autoScrollTimer; int m_autoScrollTime; int m_autoScrollAccel; - int m_quiet; QPoint m_previousP; int m_autoScrollXMargin; int m_autoScrollYMargin; @@ -163,7 +162,6 @@ static const int InitialScrollTime; static const int InitialScrollAccel; static const int MaxScrollDelta; - static const int QuietScrollMaxCount; static const double ScrollAccelValue; }; Index: gui/rosegardenscrollview.cpp =================================================================== --- gui/rosegardenscrollview.cpp (revision 7552) +++ gui/rosegardenscrollview.cpp (working copy) @@ -82,7 +82,6 @@ const int RosegardenScrollView::AutoscrollMargin = 16; const int RosegardenScrollView::InitialScrollTime = 30; const int RosegardenScrollView::InitialScrollAccel = 5; -const int RosegardenScrollView::QuietScrollMaxCount = 20; const int RosegardenScrollView::MaxScrollDelta = 100; // max a.scroll speed const double RosegardenScrollView::ScrollAccelValue = 1.04;// acceleration rate @@ -129,8 +128,6 @@ QPoint dp = p - m_previousP; m_previousP = p; - m_quiet = 0; - m_autoScrollTimer.start( m_autoScrollTime ); ScrollDirection scrollDirection = None; @@ -179,20 +176,12 @@ m_minDeltaScroll = MaxScrollDelta; m_currentScrollDirection = scrollDirection; - } else if (dx || dy) { + } else { // Don't automatically stopAutoScroll() here, the mouse button // is presumably still pressed. m_minDeltaScroll = DefaultMinDeltaScroll; m_currentScrollDirection = None; } - - if (dx || dy) m_quiet = 0; - else ++m_quiet; - - if (m_quiet == QuietScrollMaxCount) { - stopAutoScroll(); - m_quiet = 0; - } } |
From: Guillaume L. <gla...@te...> - 2006-09-25 22:18:34
|
On Monday 25 September 2006 22:13, Martin Shepherd wrote: > > the visible area that doesn't trigger scrolling. With Guillarme's > patch, scrolling restarts with the same speed as before, when the > mouse is again moved into the autoscrolling region, whereas with mine, > it starts from the slow initial default speed. The following patch, > which I just made, relative to the latest code in trunk, implements > the latter behavior. Guillarme should probably vet this before it is > officially applied to trunk. I just tried it and the behavior is much better (and it simplifies the code too, all the better :-) ). Since the autoscrolling is mostly Chris's work, perhaps he'll want to check, but as far as I'm concerned I'd apply it. (BTW, I've just received confirmation that the sforge mail loss is due to temporary problem in sforge which make it unable to properly reply to an antispam check that my ISP performs - so both parties are concerned here). -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2006-09-26 08:47:21
|
On Monday 25 Sep 2006 23:18, Guillaume Laurent wrote: > Since the autoscrolling is mostly Chris's work, perhaps he'll want to check It is? I don't recall having had anything to do with it. Maybe I just don't recall. Chris |
From: D. M. M. <ros...@gm...> - 2006-09-26 16:02:53
|
On Tuesday 26 September 2006 4:48 am, Chris Cannam wrote: > On Monday 25 Sep 2006 23:18, Guillaume Laurent wrote: > > Since the autoscrolling is mostly Chris's work, perhaps he'll want to > > check > > It is? I don't recall having had anything to do with it. > > Maybe I just don't recall. Wasn't it mostly William's work? Anyway, I'll go with Martin on this one, and we should just vet the patch already. -- D. Michael McIntyre Linux fanatic, and certified Geek; registered Linux user #243621 Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/ |
From: Guillaume L. <gla...@te...> - 2006-09-26 22:58:55
|
On Tuesday 26 September 2006 18:02, D. Michael McIntyre wrote: > On Tuesday 26 September 2006 4:48 am, Chris Cannam wrote: > > On Monday 25 Sep 2006 23:18, Guillaume Laurent wrote: > > > Since the autoscrolling is mostly Chris's work, perhaps he'll want to > > > check > > > > It is? I don't recall having had anything to do with it. > > > > Maybe I just don't recall. > > Wasn't it mostly William's work? I remember he played a large part in deciding of the behavior, and a quick svn blame shows that he contributed a patch on the matter, but I'm pretty sure Chris did most of the work. > Anyway, I'll go with Martin on this one, and we should just vet the patch > already. It's in. Thanks Martin :-). -- Guillaume. http://www.telegraph-road.org |