I may be wrong, but I vaguely remember an older version of interface builder complaining about overlapping views. I tried to replicate that in Xcode 4.6.3 today, but couldn't -- I got no warning when I put a button over another button.
Regards, Ivan Vučica via phone > On 03 Oct 2013, at 02:51, "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. > > I also bumped into a similar problem on iOS. After calculating new values for > frames and not rounding them off properly fonts in UILabel subviews can > become a bit blurry. > > Regarding the draw order. Of course the draw order should be in the order the > subviews are ordered in subviews array. > Why else is there a method for inserting subviews at different depths? > > Even if it's not documented it's the natural way to do it. It seems that > this is also the case so no point arguing about it :) > > Maybe Cocoa is a bit different but in Cocoa Touch you have subviews > overlapping each other all the time I can't imaging how it would be if draw > order is undefined. > > > -- > Johannes Lundberg > Project leader and lead developer of Mirama OS (previously Viking OS) > BRILLIANTSERVICE CO., LTD. > > My blog > Mirama homepage blog > Company homepage > > >> On Wed, Oct 2, 2013 at 11:28 PM, Matt Rice <[email protected]> wrote: >> On Wed, Oct 2, 2013 at 6:47 AM, Fred Kiefer <[email protected]> wrote: >> > I think this is an unrelated issue. >> >> probably, just wanted to throw it out there as one possible avenue, as >> I recall this one being not so fun to figure out. >> >> > First off, I always thought the drawing order of sibling views is >> > undefined. Could you please point me to a document that states otherwise? >> >> I know of no such document, it is undefined. >> >> >> > Still if Apple followes the order in wich views wher added, we should do >> > so two. But as far as I remember this is already the case. >> > And overlapping sibling views are a no-go in GNUstep, they might work for >> > drawing, but event handling will be screwed up. >> >> Correct, on OPENSTEP/the osx's i've tested this was the case, >> drawing was done in the order added (so back-most in the sibling views >> array was on top) IIRC >> >> event handling was done in the opposite order (so the back-most >> top-displayed view had first shot at the event) >> >> when using views that overlap it required care from the developer that >> all sibling NSViews which overlap the rectangle needing display >> -setNeedsDisplay at the same time, if you setNeedsDisplay a view which >> is not top-most (while not setNeedsDisplay on the top-most), >> display will become out of sync with event handling, thus it was >> something which worked with the correct parameters, was technically >> undefined, because its possible to get bad results. >> >> similarly, if the top-most view doesn't respond to events, and the a >> view it overlaps does respond to events you are likely screwed as >> well. >> >> its not something they want to define/advertise because honestly there >> are more ways to screw it up than do it correctly. but it has worked >> given a careful implementation. >> >> >> >> > Could you please provide an example that demonstrates the issue? After the >> > weekend I am Wiiling to look into this. >> >> I don't really have a test case for it or a gnustep install around, >> afaik until now DBModeler was the only thing using this feature and I >> haven't compiled it in years, and it is undoubtedly broken. >> >> hopefully Johannes can come up with something that exhibits the problem. > > _______________________________________________ > 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
