Thank you Eric for this great explanation. I had to go through all this
myself in detail to really understand what you wrote and you are
completely correct. It is the image that uses the wrong dpi value and
the code in -restrictWindow:toImage: just uses the pixel size instead of
the real image size. The problematic code is in getStandardBitmap() in
XGServerWindow.m and it even has a comment on how to correct this.
I added a call to -setBackgroundColor: in the -init method of
GSDragView. We will need to sort out what to do with the window size and
the -restrictWindow:toImage: method. For the moment we cannot do without
that method in most cases, as many users wont have compositing window
manager, although they are becoming very popular.
Fred
On 24.06.2011 01:22, Eric Wasylishen wrote:
Hey,
I think I tracked down the bug..
Plug.tiff had it's dpi set to 15 or so, so the point size was about 230x230.
The drag icon window was then set to that size (in pixels).
The problem seems to be the following call, in -[GSDragView
_setupWindowFor:mousePosition:imagePosition:]:
// Only display the image
[GSServerForWindow(_window) restrictWindow: [_window windowNumber]
toImage: [dragCell image]];
which doesn't seem to work properly with images with a DPI != 72.
As a quick fix you can set plug.tiff to 72dpi (using imagemagick: mogrify
-density 72x72 plug.tiff).
a couple other notes:
- If I do a [[self window] setBackgroundColor: [NSColor clearColor]] in
GSDragView, the drag icon shows up with proper alpha transparency for me -
since I'm using cairo and a compositing window manager.
- _setupWindowFor:mousePosition:imagePosition: uses [image size] to set the
window frame - this isn't safe with resolution independence; it should set the
window content size instead.
- I'm not sure what we should do to the -restrictWindow:toImage: method;
haven't looked at how it's implemented.
Cheers,
Eric
On 2011-06-23, at 5:04 PM, Bluna Ratimonkey wrote:
Thanks Eric, and especially for letting me see it somewhere else for
the first time :)
BTW, do you guys think we could use something like virtual window that
didn't actually get mapped but blend the image with XcursorImage so
image doesn't have a chance to jump on load and only map the window on
slide back?
On Fri, Jun 24, 2011 at 5:17 AM, Eric Wasylishen<[email protected]> wrote:
I just did a little debugging on this.. I got down to -[GSDragView
_setupWindowFor:mousePosition:imagePosition:] and the coordinates passed in to
here are correct. The frame that is set on _window in that method is correct,
but the place where the window actually shows up is at about double the
y-coordinate of where it should.
I attached a screenshot. I started the drag at around (184, 180) in screen
coordinates, which is what iPoint is. You can see that _window reports it has a
frame origin at that point, but it actually appear on screen around (184, 360).
-Eric
On 2011-06-23, at 3:53 PM, Bluna Ratimonkey wrote:
Oh sorry,
the mouse down was
NSPoint mouseDownPoint = [self convertPointFromBase:[anEvent locationInWindow]];
I tried this instead without success though. Was wondering if I should do this.
[self dragImage:[NSImage imageNamed:@"Plug.tiff"]
at:[self convertPointFromBase:[anEvent
locationInWindow]]
offset:NSZeroSize
event:anEvent
pasteboard:pb
source:mouseDownPort
slideBack:YES];
The case is in TMNodeView.m line 842
Thanks,
Bluna
--
/* Join Bluna Ratimonkey (漫画家) and build the real future for GNUstep ! */
[@"http://mus3.sourceforge.net"; setNeedsYourHelps:YES!!];
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
