[bug #27930] Offsetting a subview breaks when the parent view is resized

[Evgenii Philippov]

URL:
  <http://savannah.gnu.org/bugs/?27930>

                 Summary: Offsetting a subview breaks when the parent view is
resized
                 Project: GNUstep
            Submitted by: dfawcus
            Submitted on: Wed 04 Nov 2009 01:02:40 GMT
                Category: Gui/AppKit
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

I am trying to set up two NSViews,  one a subview of the other.
The subview is to track the width of the parent,  but is to be constantly
shorter than the height,  and offset vertically,
such that there is a portion of the parent always visible under then child.

The attached program exhibits a failure with gui/back 0.16 (and base 1.18) as
packaged on Mandriva 2009.1,  however it operates correctly on OSX 10.4.11;
the offset is initially seen to be correct,  but upon resize occuring it is
doubled.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Wed 04 Nov 2009 01:02:40 GMT  Name: offset.tar.gz  Size: 5kB   By:
dfawcus

<http://savannah.gnu.org/bugs/download.php?file_id=18985>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27930>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Evgenii Philippov]

Follow-up Comment #1, bug #27930 (project gnustep):

and I've found a workaround...

My code replaces the window content view with the new main view,
if instead the main view is itself set as a subview of the pre-existing
content view,  things work as expected.

i.e. in the sample code,  in do_window(),  replace
        [window setContentView: mainView];
with
        [[window contentView] addSubview:mainView];

Which may give a hint as to what is happening.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27930>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Evgenii Philippov]

Update of bug #27930 (project gnustep):

                  Status:                    None => Invalid                
             Assigned to:                    None => FredKiefer            
             Open/Closed:                    Open => Declined              

    _______________________________________________________

Follow-up Comment #2:

It took me some time to pin down the problem in your code. In the end it
turned out to be quite simple. In your _adjustFrameHeightForNewFrame: method
you set the origin of the subview relative to the origin of the super view:

        ourFrame.origin.y = newFrame.origin.y + _offset;

This is always wrong, as these two frames are in different coordinate
systems. The correct code looks like this:

        ourFrame.origin.y = _offset;

Why did it work on Apple but fail on GNUstep? Apple seems to have the origin
of the content view always at (0, 0). This is not true for GNUstep.

But then there isn't any reason for all your special code. Just set the
offset of your view once when you create it and make the height resizable as
well, that way the system should keep track of all this computation.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27930>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Evgenii Philippov]

Follow-up Comment #3, bug #27930 (project gnustep):

I remember to have encountered a similar issue based on the fact the origin
of the content view is zero on Mac OS X but not on GNUstep, as you said it
isn't easy to track down.
When you think about it it's logical to have a zero origin because the window
have no bottom border at all on Mac OS X by default. However iirc the weird
thing I have observed is that if you set a custom bottom border with
-setContentBorderThickness:forEdge:, the content view still reports (0, 0) as
its origin which looks like a Cocoa bug to me.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27930>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Derek Fawcus]

On Thu, Nov 05, 2009 at 07:55:39AM +0000, Fred Kiefer wrote:
>
> It took me some time to pin down the problem in your code.

 [ fix snipped]

Thanks.

> Why did it work on Apple but fail on GNUstep? Apple seems to have the origin
> of the content view always at (0, 0). This is not true for GNUstep.

Another trivial bug in my code.  Drat.

I'll have to forward a couple more things to the dev list which I think
are real bugs in order to compensate.

However it does suggest an additional testing methodology that should be pursued
before assuming an GNUstep bug,  namely to test under a window manager that
decorates in a similar fashion to quartz-wm.  I wonder if there is such a
beast already out there?

> But then there isn't any reason for all your special code. Just set the
> offset of your view once when you create it and make the height resizable as
> well, that way the system should keep track of all this computation.

Not in that simple example,  but the target program will (I believe) need it.

It will have (often) an additional subview below this one,  when its absent
this subview should be full size,  when present it will vary dynamically and
the offset+size of this view.  (Or at least that's the idea, I'm not sure how
it'll feel to use yet).

/phx


_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Derek Fawcus]

On Thu, Nov 05, 2009 at 08:17:49AM +0000, Quentin Mathé wrote:
>
> However iirc the weird
> thing I have observed is that if you set a custom bottom border with
> -setContentBorderThickness:forEdge:, the content view still reports (0, 0) as
> its origin which looks like a Cocoa bug to me.

Hmm - does anyone have access to an older implementation?  i.e. Rhapsody,
YellowBox (on windows) or OpenSTEP?  If so it'd be worth seeing how they
react to the above.


_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep