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 <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 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
