Re: Fwd: NSView patch

2009-02-24 Thread Matt Rice
On Mon, Feb 23, 2009 at 8:50 AM, Fred Kiefer fredkie...@gmx.de wrote:
 Matt Rice wrote:
 On Mon, Feb 23, 2009 at 5:50 AM, Fred Kiefer fredkie...@gmx.de wrote:
 The other problem that we sometimes mark subviews as still needing
 display due to rounding errors should be addressed. Here it would be
 helpful to get the detailed values of the involved rectangles. These
 surely are in Matts gdb log, but as he is using a changed version of the
 NSView code it is hard for me to tell, which is which. What would help
 is to have the values of _visibleRect, _invalidRect and aRect at the
 beginning of the method displayRectIgnoringOpacity:inContext:

 the superview at the beginning of the method.

 Breakpoint 2, -[NSView displayRectIgnoringOpacity:inContext:]
 (self=0x276ff90, _cmd=0xdc4e70, aRect={origin = {x = 0, y = 0}, size =
 {width = 476, height = 381}}, context=0x299b740) at NSView.m:2368
 2368      BOOL flush = NO;
 $_invalidRect ={origin = {x = 0, y = 0}, size = {width = 1, height = 1}}
 $_visibleRect ={origin = {x = 0, y = 0}, size = {width = 476, height = 381}}
 $aRect ={origin = {x = 0, y = 0}, size = {width = 476, height = 381}}

 still in the super-view but right before we go to the subview...

 Breakpoint 3, -[NSView displayRectIgnoringOpacity:inContext:]
 (self=0x276ff90, _cmd=0xdc4e70, aRect={origin = {x = 0, y = 0}, size =
 {width = 476, height = 381}}, context=0x299b740) at NSView.m:2450
 2450                  if (NSIsEmptyRect(isect) == NO)
 $_invalidRect ={origin = {x = 0, y = 0}, size = {width = 0, height = 0}}
 $_visibleRect ={origin = {x = 0, y = 0}, size = {width = 476, height = 381}}
 $aRect ={origin = {x = 0, y = 0}, size = {width = 476, height = 381}}
 $isect ={origin = {x = 48.7490425, y = 192.641785}, size = {width =
 118, height = 54}}
 $subviewFrame ={origin = {x = 48.7490425, y = 192.641785}, size =
 {width = 118, height = 54}}

 right after we go
 isect = [subview convertRect: isect fromView: self];

 Breakpoint 4, -[NSView displayRectIgnoringOpacity:inContext:]
 (self=0x276ff90, _cmd=0xdc4e70, aRect={origin = {x = 0, y = 0}, size =
 {width = 476, height = 381}}, context=0x299b740) at NSView.m:2453
 2453                      [subview displayRectIgnoringOpacity: isect
 inContext: context];
 $new_isect ={origin = {x = 0, y = 0}, size = {width = 117.85, height = 
 54}}


 now here in the view where the error occurs

 Breakpoint 2, -[NSView displayRectIgnoringOpacity:inContext:]
 (self=0x284f7e0, _cmd=0xdc4e70, aRect={origin = {x = 0, y = 0}, size =
 {width = 117.85, height = 54}}, context=0x299b740) at
 NSView.m:2368
 2368      BOOL flush = NO;
 $_invalidRect ={origin = {x = 0, y = 0}, size = {width = 118, height = 54}}
 $_visibleRect ={origin = {x = 0, y = 0}, size = {width = 118, height = 54}}
 $aRect ={origin = {x = 0, y = 0}, size = {width = 117.85, height = 54}}

 Breakpoint 1, gsbp () at NSView.m:2362


 Thank you for checking all these values. It is really just a small
 rounding error in the conversion. What about cheating here? For this
 special case the simplest solution would be to use the bounds rectangle
 of the sub view as new isect, when the real isect before the conversion
 is equal to the frame rect of the sub view.
 I know this will not help us in all cases, but it would quite often save
 us the computation of the conversion and in this specific case it is
 also more correct.

 The code would look somewhat like this, plus plenty of comments
 explaining why we do this:

              isect = NSIntersectionRect(aRect, subviewFrame);
              if (NSIsEmptyRect(isect) == NO)
                {
                  if (NSEqualRects(isect, subviewFrame) == YES)
                    isect = [subview bounds];
                  else
                    isect = [subview convertRect: isect fromView: self];
                  [subview displayRectIgnoringOpacity: isect inContext:
 context];
                }

 The main problem here is that somebody will have to convince me that
 this is correct in all cases, even with scaling and rotation.


I don't think that will work because I'm also seeing rounding errors on
the isect = NSIntersectionRect(...) calls... though not in the stuff i
sent earlier for some reason... not sure why...
but that would also only work when displaying whole views,
and i take it you don't like the idea of just using
GSAlmostEqualRects() in NSView?

here's 2 test cases, bar.app is the minimal one and another one that
allows you to drag the purple view around by clicking on it, and
resize it by clicking the black square, rotate and scale and all that
other stuff... (note that scaling doesn't seem to work until its been
rotated)
the one thing it doesn't do is allow you to set the origin at
non-integer increments unless whatever input device your using gives
non-integer coordinates (i don't appear to have one)
if its not reproducable I could add something like a NSStepper to
increment the deal by the value of the value of the top slider or
something...


Re: [Gnustep-cvs] r27911 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m

2009-02-24 Thread Fred Kiefer
Gregory Casamento wrote:
 Author: gcasa
 Date: Wed Feb 18 08:38:02 2009
 New Revision: 27911
 
 URL: http://svn.gna.org/viewcvs/gnustep?rev=27911view=rev
 Log:
   * Source/GSNibLoading.m: Rollback of previous change.  Found a 
   minor problem.
 
 Modified:
 libs/gui/trunk/ChangeLog
 libs/gui/trunk/Source/GSNibLoading.m

Greg,

could you please explain why you had to undo this change? If there was a
problem I am willing to help fixing it. I did not remove this code
myself, as I wanted to give you enough time to check, whether my
replacement was working.
I really would like to the see this code here go away.

Fred


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: [Gnustep-cvs] r27911 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m

2009-02-24 Thread Gregory Casamento
Hey Fred,

When I removed my code, the menu started rendering as it had before (i.e.
messy with all but a few items in the top level).   As you can see, the date
was the 18th, so it was just before SCALE, I figured it would be better to
roll back the change until I could take a better look at it.

I will do that today and tomorrow as I would like to see this code go away
too.

GC

On Tue, Feb 24, 2009 at 5:35 PM, Fred Kiefer fredkie...@gmx.de wrote:

 Gregory Casamento wrote:
  Author: gcasa
  Date: Wed Feb 18 08:38:02 2009
  New Revision: 27911
 
  URL: http://svn.gna.org/viewcvs/gnustep?rev=27911view=rev
  Log:
* Source/GSNibLoading.m: Rollback of previous change.  Found a
minor problem.
 
  Modified:
  libs/gui/trunk/ChangeLog
  libs/gui/trunk/Source/GSNibLoading.m

 Greg,

 could you please explain why you had to undo this change? If there was a
 problem I am willing to help fixing it. I did not remove this code
 myself, as I wanted to give you enough time to check, whether my
 replacement was working.
 I really would like to the see this code here go away.

 Fred


 ___
 Gnustep-dev mailing list
 Gnustep-dev@gnu.org
 http://lists.gnu.org/mailman/listinfo/gnustep-dev




-- 
Gregory Casamento
Open Logic Corporation, Principal Consultant
## GNUstep Chief Maintainer
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell), (301)362-9640 (Home)
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev