[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fwd: Re: Possible bug to do with scrolling and xgps]

From: Adam Fedor
Subject: [Fwd: Re: Possible bug to do with scrolling and xgps]
Date: Thu, 02 Nov 2000 09:17:00 -0700

I don't have time to look at this right now, but if someone else does,
be my guest. I might have time next week...

My thoughts, which may or may not be correct:
The bounding box coordinates are only updated during a lockFocus, so we
need to make sure it's updated when the view is already lock focused.

THe odd thing is that I think it is the NSClipView's coordinates that
are changed, but the _document_view needs to know about it, so  in the
NSClipView's method to set the bounding box, there needs to be something

 if (_document_view == [NSView focusedView])
   update coordinates (as in [NSView -lockFocus]).


-------- Original Message --------
Subject: Re: Possible bug to do with scrolling and xgps
Date: Tue, 31 Oct 2000 23:08:48 +1300
From: Stephen Brandon <VaryaAndSteve@brandons.free-online.co.uk>
To: Adam Fedor <fedor@doc.com>
References: <00103023241300.02528@tokyo.brandon.com>

Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 31 Oct 2000, you wrote:
> Stephen Brandon wrote:
> > If you can confirm that this is a bug (and I am sure it is), and if =
you can
> > tell me the sort of places where a fix needs to be done in GNUstep, =
I would be
> > happy to have a go at fixing it myself. Though it might be easier =
if you did
> > it, if you know all the frameworks really well.
> >=20
> I can't really confirm it's a bug, because I haven't seen it. It =
> be helpful if you could make a small test app that shows the problem. =
> any case, the best place for this besides gnats is =


I've hacked together a small app with portions of my production code, =
shows the problem quite nicely, though the code looks pretty awful!

If you compile the app as given, the bug has a workaround, so you can =
see what
is supposed to happen when there is no bug. The app has a simple view =
of a
diagonal line in a scroll view, and you can click and drag left and =
right to
highlight part of the line. You can extend the selection with the shift

To see the bug in action, comment out line 2 of TestView.m. This causes
removal of the 2 lines of code which are the workaround.

The workaround simply unlocks then locks focus JUST BEFORE the =
highlighting is
done. This causes the updated coordinates of the TestView to be taken =
account in the highlighting. Otherwise, if you drag off the right of =
the view,
then reverse direction and drag left again, the right edge of the =
rectangle lags behind the mouse position, by the amount that the view
originally scrolled to the left. In other words, the unhighlighting is =
drawn on
the screen in the position it would have done if the view had NOT =

So, it is evident from this test that the frame relationships between
containing views are only updated in the XGContext when the focus is =
changed. I
have had this exact code running on OpenStep for a long time, and the
workaround is NOT necessary on OpenStep. Therefore, GNUStep bug? :-)

I am sorry that the mouse dragging code is quite complex and =
unreadable. It's
worse than really necessary for this example, because it comes from the
framework for displaying sounds, where there are issues to do with all =
kinds of
magnification, and exact pixel/sample relationships that must be =

Something that shows up on my system (and probably will on yours) is =
that the
dragging performance is not all that good. OK, there's lots of =
debugging printf
nonsense in the code I sent you, but apart from this, when scrolling =
there are
frequently artifacts that take a few seconds to sort themselves out, =
and look
quite bad on screen. I trust that this will improve in future!

Anyway, I really hope all this helps.

Stephen Brandon

Attachment: LinuxTest.tar.gz
Description: GNU Zip compressed data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]