Yes, we should have to setNeedsDisplay to cause it to redraw. This is no different. However, is it ok to need to have code like this?
[view setNeedsDisplay:YES]; view.frame = newFrame; [view setNeedsDisplay:YES]; To compare with OS X or iOS you only need view.frame = newFrame; [view setNeedsDisplay:YES]; I will try to find some more info on how this is implemented in Cocoa. -- Johannes Lundberg Project leader and lead developer of Mirama OS (previously Viking OS) BRILLIANTSERVICE CO., LTD. My blog <http://brilliantobjc.blogspot.com> Mirama homepage <http://www.brilliantservice.co.jp/viking/> blog<http://hmdviking.blogspot.jp> Company homepage <http://www.brilliantservice.co.jp> On Fri, Oct 4, 2013 at 3:06 PM, Fred Kiefer <[email protected]> wrote: > Sorry, the problem here is that GNUstep follows the specification. There > it states: > > "This method, in setting the frame rectangle, repositions and resizes the > receiver within the coordinate system of its superview. It neither > redisplays the receiver nor marks it as needing display. You must do this > yourself with > display<https://developer.apple.com/library/mac/documentation/cocoa/reference/applicationkit/classes/NSView_Class/Reference/NSView.html#//apple_ref/occ/instm/NSView/display> > > orsetNeedsDisplay:<https://developer.apple.com/library/mac/documentation/cocoa/reference/applicationkit/classes/NSView_Class/Reference/NSView.html#//apple_ref/occ/instm/NSView/setNeedsDisplay:> > ." > Now we will need to assert that the actual implementation on Cocoa behaves > differently before we change our code. > > Fred > > On the road > > Am 04.10.2013 um 02:46 schrieb "Lundberg, Johannes" < > [email protected]>: > > Another things I noticed is that when moving or scaling a NSView by > changing the frame you have to call [view setNeedsDisplay:YES] before and > after changing the frame (this is not needed on OSX/iOS). If you only call > setNeedsDisplay after changing the frame the old frame is not redrawn and > causes a trail of remaining pixels where the view has been. This could be > fixed by adding functionality to setFrame, couldn't it? How if we keep the > old frame in a private variable and redraw both frames when call to redraw > is made? > > > > -- > Johannes Lundberg > Project leader and lead developer of Mirama OS (previously Viking OS) > BRILLIANTSERVICE CO., LTD. > > My blog <http://brilliantobjc.blogspot.com> > Mirama homepage <http://www.brilliantservice.co.jp/viking/> > blog<http://hmdviking.blogspot.jp> > Company homepage <http://www.brilliantservice.co.jp> > > > On Thu, Oct 3, 2013 at 8:20 PM, Matt Rice <[email protected]> wrote: > >> On Wed, Oct 2, 2013 at 5:51 PM, Lundberg, Johannes >> <[email protected]> wrote: >> > Thanks all for your replies. >> > >> > Matt is correct. A quick test with this code after subviews has gotten >> new >> > values (calculated with some analytic formula) >> > >> > for each subview >> > { >> > subview.frame = NSMakeRect((int)subview.frame.origin.x, >> > (int)subview.frame.origin.y, (int)subview.frame.size.width, >> > (int)subview.frame.size.height); >> > } >> > >> > fixes the problem. >> >> Unfortunate because this problem is likely unapparent for >> non-overlapping views, causing unnecessary redraws. >> > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > >
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
