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
like:
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 <[EMAIL PROTECTED]>
To: Adam Fedor <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
--Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD
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
>=20
> I can't really confirm it's a bug, because I haven't seen it. It =
would
> be helpful if you could make a small test app that shows the problem. =
In
> any case, the best place for this besides gnats is =
[EMAIL PROTECTED]
>=20
Hi,
I've hacked together a small app with portions of my production code, =
which
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
=
key.
THE BUG
To see the bug in action, comment out line 2 of TestView.m. This causes
=
the
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 =
into
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 =
highlighted
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 =
scrolled.
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
=
SndKit
framework for displaying sounds, where there are issues to do with all =
kinds of
magnification, and exact pixel/sample relationships that must be =
absolutely
accurate.
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
[EMAIL PROTECTED]
LinuxTest.tar.gz
