I agree that my present solution is a workaround. The code I added
checks whether the window is actually in a different place than the
frame that is recorded in the NSWindow object, and adjusts the mouse
location accordingly. But obviously the real problem is that the
NSWindow doesn't know where the window really is.
Are you saying that the backend notifies the gui of the window
movement through posting an asynchronous notification? I would have
thought it would make a direct call for something like that, but then
I don't know anything about the backend and how it's structured. I
assumed that the notification was just broken somehow (or not
implemented) but I don't have the knowledge needed to fix the problem,
hence the workaround.
I don't know what the right solution is, but it doesn't seem like
developers who use GNUstep (such as myself) should have to worry about
running an event loop periodically in order to guarantee the internal
consistency of the system. But maybe that wasn't quite what you meant.
--
Doug Simons
Principal Developer
TestPlant Inc T +1 720-890-0211 ext 13
4730 Walnut Street F +1 720-890-0209
Boulder, CO 80301 doug.sim...@testplant.com
USA
http://www.testplant.com
This email and any attachments may contain privileged / confidential
information. If you have received this email in error
or believe that you are not the intended recipient, please delete all
content and attached files and contact TestPlant via
the switchboard on +1 720-890-0211 or via return e-mail. You should
not copy, forward or use any part of the
contents in any way. Any such unauthorised use or disclosure may be
unlawful.
On Nov 18, 2009, at 2:11 AM, Fred Kiefer wrote:
Doug Simons schrieb:
Author: dpsimons
Date: Mon Nov 16 23:51:14 2009
New Revision: 29026
URL: http://svn.gna.org/viewcvs/gnustep?rev=29026&view=rev
Log:
fix problem with mouse tracking being off in submenus that are
shifted to stay on screen
Modified:
libs/gui/branches/testplant_1/Source/NSMenuView.m
I think that this is an important patch we should discuss on this
mailing list. The patch clearly is wrong, as it is only trying to
address the result of a problem, but not the problem itself. What
happens is that after opening a submenu the interaction of the mouse
has
an offset, when the window manager repositions the submenu. I think
that
this is caused by the code not accepting any repositioning events for
the submenu. I would expect that the backend tries to tell gui where
the
submenu window did get positioned, but as we are in a tracking loop we
ignore these events.
An easy solution would be to run the normal event loop for a short
time
after we attach a new submenu, but this looks like just another hack.
Any better idea, how to resolve the issue?
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
