Changes to x, y, w, h meaning in sub windows?

[Ken Brooks]

I am reviving an old program written in 2004, which used FLTK 1.1.7 for Mac. To get it to compile now, I upgraded to FLTK 1.3.4.

I'm having problems with the positioning of subwindows. The meanings of x, y, w, h, especially w and h, seem to have changed in some mysterious way that I'm having a very hard time quantifying.  But subwindows no longer appear where they used to, and where they do appear, their contents don't display with proper centering.

Could someone tell me what might have changed? Has there been a move from parent-relative coordinates to absolute coordinates, or vice versa?

Thanks,

Joymaker

[Ian MacArthur]

The meaning of x,y,w,h, in 1.1.7 should be the same as it is in 1.3.x or 1.4.x now. (The fltk-2 experiments did change this, but that didn’t stick...)

So... It should not be different.

However; the way that nested windows are handled on OSX has changed along the way, as Apple have evolved their window manager and graphics layer (Carbon, Cocoa, Quartz, etc...) so it is entirely possible it is something in there that is causing the change.


Does your code build on a non-OSX platform, and does it work? The handling of nested subwindow on X11 and WIN32 has not changed, so it might be informative to see what they do in comparison.

Indeed, the way that nested subwindow were created by fltk on OSX back in the 1.1.7 era was something of a workaround, so it is not inconceivable that your code was “wrong” before but worked due to some weirdness, and now that things are “fixed” the code no longer works... Or something...

I think a test on a non-OSX platform is worth a try, see how that behaviour compares; there’s a reasonable chance that both 1.1.7 and 1.3.4 could be run on a (maybe 32-bit) X11 or WIN32 machine side by side for comparison, whereas running 1.1.7 on a recent Mac is not really practical...

[Greg Ercolano]

On 05/03/17 14:49, Ken Brooks wrote:
> I'm having problems with the positioning of subwindows. The meanings
> of x, y, w, h, especially w and h, seem to have changed in some
> mysterious way that I'm having a very hard time quantifying.
> But subwindows no longer appear where they used to,
> and where they do appear, their contents don't display with proper centering.

Do you have some sample code you can provide us
that doesn't work as you expect?

For instance, some xywh coordinates for your main window vs. subwindow
and how you're achieving "centering" (of text? child widgets?)

> Could someone tell me what might have changed? Has there been a
> move from parent-relative coordinates to absolute coordinates, or vice versa?

IIRC, subwindow support wasn't well defined in some very old
versions, and was stabilized later.

Basically, objects within a window (main window or subwindow)
will have xy coordinate positions relative to the upper/left
corner of that window.

So objects within a subwindow will have xy's relative to the upper/left
of the subwindow (not the main window).

AFAIK, w/h values are not affected.

[Greg Ercolano]

On 05/03/17 15:11, Greg Ercolano wrote:
> So objects within a subwindow will have xy's relative to the upper/left
> of the subwindow (not the main window).

Some example code.

Note xywh values for the two child Fl_Box's are the same, but because
their parent subwindows are positioned separately, so are the child
boxes, as their xy coord space is within the subwindow's.

What you should see is (view with a fixed font):

-------------------------------------------------------------------
| Main Window |
| |
| --------------------------- ----------------------------- |
| | | | | |
| | -------- | | -------- | |
| | | | | | | | | |
| | | L Box | | | | R Box | | |
| | | | | | | | | |
| | -------- | | -------- | |
| | | | | |
| | | | | |
| | | | | |
| --------------------------- ----------------------------- |
| |
-------------------------------------------------------------------

..when you build and run the following:

#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Box.H>
int main(int argc, char **argv) {
Fl_Window *mainwin = new Fl_Window(800,180);
{
// Positions of these two subwindows are relative to the mainwin's upper/left
Fl_Window *leftwin = new Fl_Window(20,20,370,140);
leftwin->align(FL_ALIGN_CENTER);
leftwin->color(FL_RED);
{
// Child box coords within subwindow
Fl_Box *box = new Fl_Box(20,20,80,80,"L Box");
box->color(0xdd000000);
box->box(FL_FLAT_BOX);
}
leftwin->end();

Fl_Window *rightwin = new Fl_Window(410,20,370,140);
leftwin->align(FL_ALIGN_CENTER);
rightwin->color(FL_GREEN);
{
// Child box coords within subwindow
Fl_Box *box = new Fl_Box(20,20,80,80,"R Box");
box->color(0x00dd0000);
box->box(FL_FLAT_BOX);
}
rightwin->end();
}
mainwin->end();
mainwin->resizable(mainwin);
mainwin->show(argc, argv);
return Fl::run();
}

[Ken Brooks]

Thanks, Greg, your code executed as promised. I wish I could post my code, but it is big and convoluted and involves a couple of levels of subclassing of the window class. But I'll use pieces from your code to plug into mine to see if I can get some basic functionality back.

[Greg Ercolano]

On 05/03/17 15:56, Ken Brooks wrote:
> Thanks, Greg, your code executed as promised. I wish I could post my code, but it is big and convoluted and involves a couple of levels of subclassing of the window class. But I'll use pieces from your code to plug into mine to see if I can get some basic functionality back.

I'd suggest focusing on one subwindow; set its bg color so you can see
its borders.

You can use a tool like flruler:
http://seriss.com/people/erco/fltk/flruler/
..to measure the pixel distances to compare the old build to the
new to see where things "should" be.

I suppose also beware of the influences of things like fl_clip()
and fl_translate(), assuming you use either of those.
fl_clip(): http://www.fltk.org/doc-1.3/group__fl__drawings.html#ga0061bafa4252431de247713975e4c3ef
fl_translate(): http://www.fltk.org/doc-1.3/group__fl__drawings.html#ga319d6ba89d8a5a0b375dfbef4f265cd0

[Ken Brooks]

The plot thickens. I traced the problem to Fl_Gl_Window, which is subclassed in my project. Those are the things that are not displaying properly. So I went off and wrote a very trivial subclass that just draws a background, and modified your code, resulting in the attached program TryWin.zip. I created a brand-new clean Xcode project for it, imported the necessary libraries, and it looks good. But if I run this code in the context of my original project, but still using your main() function as my main function so not a lot of my code is getting called, we have some sizing and alignment problems. See the second screenshot below:

"Pure" project:  

Embedded in my project:

 Among other things, the red box is being positioned globally, not relative to its parent window.  What sort of initialization could be screwing things up for other windows in a global way?  fl_clip and fl_translate are not found in the entire project. 

My only good theory is that my main game window (which isn't even displayed when this example is running) uses a wrapper class around Fl_Gl_Window called fltkbasicgl. A  wrapper class which I didn't write. I'm attaching the source and header file for it, I wonder if you can see anything in there that is "broken but used to be tolerated".

[Greg Ercolano]

On 05/08/17 13:56, Ken Brooks wrote:

"Pure" project:  

Embedded in my project:

 Among other things, the red box is being positioned globally, not relative to its parent window.  What sort of initialization could be screwing things up for other windows in a global way?

    To answer that question, loosing the subwindow context that creates the
    correct parent/child relationship would do it.

    i.e. creating the red box outside of begin()/end() for the blue subwindow.

    I haven't looked at your code, but make sure there's no end() between
    the blue subwindow's begin() and the creation of the red box. Or any FLTK
    calls that might affect the current() group. (e.g. Fl_Group::current(widget)).

    That would surely cause the red box to be parented to the wrong window,
    i.e. the main window instead of the subwindow.

   

[Greg Ercolano]

OK, here you're deriving a class from Fl_GL_Window (called TryWin),
and then attempting to parent an Fl_Box to that, which AFAIK is not allowed.

Quoting the relevant docs for Fl_GL_Window:
http://www.fltk.org/doc-1.3/classFl__Gl__Window.html#details
"""
Please note that the FLTK drawing and clipping functions will not work
inside an Fl_Gl_Window. All drawing should be done using OpenGL calls exclusively.
*Even though Fl_Gl_Window is derived from Fl_Group, it is not useful to add*
*other FLTK Widgets as children, unless those widgets are modified to draw*
*using OpenGL calls.*
"""

In other words, behavior of regular FLTK widgets (unless modified as described)
would be undefined.

[Ken Brooks]

There is more going on here than that. Getting rid of the red box gets rid of the red box, but does not change the size and position problems of the Fl_Gl_Window.

Here's the screenshot, once the red Fl_Box has been commented out:

[Greg Ercolano]

Hmm, I don't get the smaller blue box on OS X box, but that may have to do with other undefined behavior; looking closely at the openGL code in "TryWin", unless I'm missing something, the draw() method is missing the normal initialization of the OpenGL viewport/ortho.

Since I can't replicate your screenshot, I can't know if this is the issue, but does it help to redo your draw() code this way:

void TryWin::draw(){

    // Viewport not valid? Init viewport, ortho, etc.

    if (!valid()) {

        glLoadIdentity();

        glViewport(0,0,w(),h());

        glOrtho(-w(),w(),-h(),h(),-1,1);

    }

    glClearColor(0.5, 0.5, 0.8, 1.0);

    glClear(GL_COLOR_BUFFER_BIT + GL_DEPTH_BUFFER_BIT);

}

(Hmm, I'm replying here using google's interface to the group, something I rarely do -- copy/pasting code from my OS X terminal seems to include the terminal's font and bg color for some reason.. rather than rewrite that with a courier font, I'm leaving it be as I'm curious how it'll look in NNTP/email)

Besides adding the necessary "if (!valid())" check, I also left out the !visible check (I don't think fltk would call your draw() routine if the widget was invisible, but it's better to do something than nothing when draw() is called), and I don't think the glFlush() call is needed, as FLTK should be handling that kind of thing within draw().

[Greg Ercolano]

On 05/11/17 03:37, Greg Ercolano wrote:
> Since I can't replicate your screenshot, I can't know if this is the issue,
> but does it help to redo your draw() code this way:
>

> [..ugly google groups posted code..]

>
> (Hmm, I'm replying here using google's interface to the group, something I
> rarely do -- copy/pasting code from my OS X terminal seems to include the
> terminal's font and bg color for some reason.. rather than rewrite that
> with a courier font, I'm leaving it be as I'm curious how it'll look in NNTP/email)

Oh wow, ok, that google groups code paste experiment went oddly..
looked nice in google's editor, but immediately it looked bad
once posted. I'll keep that in mind :/

Replying here the way I normally do via email; here's the rewritten
draw() code again, for readability sake:

--- snip

void TryWin::draw(){
// Viewport not valid? Init viewport, ortho, etc.
if (!valid()) {
glLoadIdentity();
glViewport(0,0,w(),h());
glOrtho(-w(),w(),-h(),h(),-1,1);
}
glClearColor(0.5, 0.5, 0.8, 1.0);
glClear(GL_COLOR_BUFFER_BIT + GL_DEPTH_BUFFER_BIT);
}

--- snip

I'm guessing that added code might help, because without it
I don't think OpenGL is getting a proper viewport initialization.

> Besides adding the necessary "if (!valid())" check, I also left out the !visible check
> (I don't think fltk would call your draw() routine if the widget was invisible, but it's
> better to do something than nothing when draw() is called), and I don't think the
> glFlush() call is needed, as FLTK should be handling that kind of thing within draw().

PS. the 1.3.4 docs for Fl_GL_Window::valid() advise using this:

--- snip
void mywindow::draw() {
if (!valid()) {
glViewport(0,0,pixel_w(),pixel_h());
glFrustum(...);
...other initialization...
}
if (!context_valid()) {
...load textures, etc. ...
}
... draw your geometry here ...
}
--- snip

Just an aside: I've never had to use pixel_w(),pixel_h() myself..
Those new methods seem to have been added somewhere in 1.3.x,
something to do with supporting Apple retina displays when the
special Fl::use_high_res_GL(bool) mode is enabled.

So if by chance you need that hires mode, then replace
the w()/h() calls I'm using in draw() with pixel_w()/pixel_h().
[Outside of that, I think w()/h() are equivalent to pixel_w()/pixel_h()]

Attaching a single .cxx version of your TryWin example below
that I used for my tests, just so I could easily build it with
fltk-config --compile foo.cxx --use-gl.

My comments in the extreme right column.
It's odd I can't replicate your smaller blue window, but that may just
be a difference between our OSX hardware.

BTW, small nit: I also changed the variable names x1/y1/x2/y2
in the TryWin constructor to x/y/w/h -- those last two values
are *not* x/y coords, they are width/heights.
___________________________________________________________________________

#include <openGL/GLU.h> /* OSX SPECIFIC? */
#include <FL/GLUT.h>
#include <FL/Fl.H>
#include <FL/Fl_Gl_Window.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Box.H>

class TryWin : public Fl_Gl_Window {
public:
TryWin(int x1, int y1, int x2, int y2, int index0);
void draw();
//void initGL(); // UNUSED?
};

TryWin::TryWin(int X, int Y, int W, int H, int index0) // REWRITTEN: x1/y1/x2/y2 -> x/y/w/h
: Fl_Gl_Window(X, Y, W, H, "TryWin")
{
}

//void TryWin::initGL() { // UNUSED?
// glClear(GL_COLOR_BUFFER_BIT + GL_DEPTH_BUFFER_BIT); // UNUSED?
//} // UNUSED?

void TryWin::draw(){
// Viewport not valid? Init viewport, ortho, etc.

if (!valid()) { // ADDED
glLoadIdentity(); // ADDED
glViewport(0,0,w(),h()); // ADDED
glOrtho(-w(),w(),-h(),h(),-1,1); // ADDED
} // ADDED
// if (!visible_r()) return; // don't draw invisible widget // REMOVED -- fltk shouldn't be calling draw() if invisible -- is this a bug workaround?

glClearColor(0.5, 0.5, 0.8, 1.0);
glClear(GL_COLOR_BUFFER_BIT + GL_DEPTH_BUFFER_BIT);

// glFlush(); // REMOVED

}

int main(int argc, char **argv) {
Fl_Window *mainwin = new Fl_Window(800,180);
{
// Positions of these two subwindows are relative to the mainwin's upper/left

Fl_Window *leftwin = new TryWin(20,20,370,140, 1);
leftwin->align(FL_ALIGN_CENTER);
leftwin->color(FL_RED);
leftwin->end();
mainwin->begin();

// REMOVED FOLLOWING:
// Fl_Gl_Window SHOULDN'T PARENT REGULAR FLTK WIDGETS
//
// { // REMOVED
// // Child box coords within subwindow // REMOVED
// Fl_Box *box = new Fl_Box(20,20,80,80,"L Box"); // REMOVED
// box->color(0xdd000000); // REMOVED
// box->box(FL_FLAT_BOX); // REMOVED
// } // REMOVED

Fl_Window *rightwin = new Fl_Window(410,20,370,140);
leftwin->align(FL_ALIGN_CENTER);
rightwin->color(FL_GREEN);
{
// Child box coords within subwindow
Fl_Box *box = new Fl_Box(20,20,80,80,"R Box");
box->color(0x00dd0000);
box->box(FL_FLAT_BOX);
}
rightwin->end();
}
mainwin->end();
mainwin->resizable(mainwin);
mainwin->show(argc, argv);
return Fl::run();
}

___________________________________________________________________________

[Greg Ercolano]

BTW, the only other thing I can think of that might cause "trouble"
is the use of GL_DEPTH_BUFFER_BIT here:

> glClear(GL_COLOR_BUFFER_BIT + GL_DEPTH_BUFFER_BIT);

..without first enabling the depth buffer stuff:

glEnable(GL_DEPTH_TEST);
glDepthFunc(GL_LESS); // probably unneeded; GL_LESS is the default IIRC

You can include those calls within the !valid() check.

I do opengl flag settings after the viewport initialization.
not sure if the order matters; I defer to whatever the openGL
docs say about this.

[Ken Brooks]

Greg – I'm sorry it's been a month, I've had to come this from several angles to pin it down. But I believe I have a tight, minimal demonstration of the bug I'm dealing with.

Below is a modification of the example code you sent me.  TryWin Is a very trivial subclass of Fl_Gl_Window the just colors the window blue. Included in the attached archive. Questions:

1. leftwin and rightwin nominally have a height of 140 pixels. Why don't they come out with the same height?? Rather, midwin at 150 matches.

2. leftwin and midwin both have a width of 200 pixels. Why is midwin truncated? This is key to the bug I'm dealing with.

3. If I change the height of leftwin to 170, things get much worse. Picture below. Why is leftwin lowered at the top?

4. And what on earth is it made of, that it can reach outside the bounds of its containing window??

5. Can you reproduce any of this? My vital statistics:

Mac OS X 10.9.5

Xcode 6.2

FLTK header:   "$Id: Fl_Gl_Window.H 11787 2016-06-22 05:44:14Z manolo $"

#include <FL/Fl.H>

#include <FL/Fl_Window.H>

#include <FL/Fl_Box.H>

#include "TryWin.h"

int main(int argc, char **argv) {

    Fl_Window *mainwin = new Fl_Window(800,180);

    {

        // Positions of these subwindows are relative to the mainwin's upper/left

        Fl_Window *leftwin = new TryWin(20,20, 200, 140, 1);

        leftwin->align(FL_ALIGN_CENTER);

        leftwin->end();

        

        Fl_Window *midwin = new TryWin(120, 20, 200, 150, 2);

        midwin->align(FL_ALIGN_CENTER);

        midwin->end();

        

        Fl_Window *rightwin = new Fl_Window(410, 20, 200, 140);

        rightwin->align(FL_ALIGN_CENTER);

[Greg Ercolano]

On 06/14/17 11:35, Ken Brooks wrote:
> Greg – I'm sorry it's been a month, I've had to come this from several angles to pin it down. But I believe I have a tight, minimal demonstration of the bug I'm dealing with.
>
> Below is a modification of the example code you sent me.

OK, so to be able to tell what's what, I made some small changes
to your code so I could see each box/window as a separate color.
(attached changes here)

In the case of the Fl_Gl_Window, I told it to draw the area using
the RGB values from Fl_Widget::color() so I could set the RGB color()
on creation of each widget.

Other changes:

o I removed reference to the non-fltk file: #include "fltkbasicgl.h"
o I removed the #ifdef WIN32 stuff around the Fl_Gl_Window to simplify
o I combined the three files into one, so it's easier to compile/read/post here
o I added a if (!valid()) check because the docs say you should, e.g.

void TryWin::draw(){
// Viewport not valid? Init viewport, ortho, etc.
if (!valid()) {
glLoadIdentity();
glViewport(0,0,w(),h());
glOrtho(-w(),w(),-h(),h(),-1,1);
}

..

So if you would, please let's work with this code instead of the separate
files.. it's just easier for everyone to understand and participate.
I left markers in the code to show the beginning/ending of each of your files.

The resulting image is clearer to see what widget is generating which rectangle
on screen (screenshot attached).

> 1. leftwin and rightwin nominally have a height of 140 pixels. Why don't they come out with the same height?? Rather,

OK, in the attached screenshot, 'leftwin' is the dark red window,
and 'rightwin' is the dark green window.

These are the same size. It's hard to tell because 'midwin' (bright red window)
is drawing over it.

> 2. leftwin and midwin both have a width of 200 pixels. Why is midwin truncated? This is key to the bug I'm dealing with.

Because each opengl widget must be separate and not overlap.

When you define an opengl window, consider it's entire area not available
for other widgets (in the same 'top level' window) to overlap it or be
parented to it.

The only way that I'm aware of that allows fltk widgets to overlap is if
they're in /separate/ top level windows (e.g. 'window manager' windows,
which would include popup menus, dialog windows, and separate top level windows)

I like to think of opengl windows as an area managed by dedicated hardware
and is off limits to normal x windows/fltk drawing. Everything inside the
opengl rectangular area should be drawn and managed by opengl calls only.

leftwin and midwin's XYWH values overlap, so quite simply: don't do that.

> 3. If I change the height of leftwin to 170, things get much worse. Picture below. Why is leftwin lowered at the top?

Probably undefined behavior as the result of the two overlapping
opengl windows, leftwin and midwin, which AFAIK is not allowed.

If there exceptions to this rule, I choose not to depend on them,
and rather always design apps so that widgets are never inside the
opengl area (I think popup menus are an exception, as they are basically
separate windows)

> 4. And what on earth is it made of, that it can reach outside the bounds of its containing window??

Hmm, lost me here.

> 5. Can you reproduce any of this?

Yes, on both osx and linux I get similar behavior.

And it can likely be fixed (I didn't try) if you don't overlap the opengl
windows.

[Ken Brooks]

Thanks, Greg. I adopted your code and modified it to avoid overlaps. I'm still seeing strange behavior, and it doesn't look the same as yours.

First, I had to comment out the line        //glViewport(0, 0, pixel_w(), pixel_h());

  because it gave me a link error,

Undefined symbols for architecture x86_64:

  "Fl_Gl_Window::pixels_per_unit()", referenced from:

      Fl_Gl_Window::pixel_w() in foo.o

Wonder what that's all about. But having done that, I ran the code and got this:

 issues:

1. leftwin is defined with a height of 140, but comes out shorter than rightwin

2. midwin is defined with a height of 150, and comes out with the same height as rightwin at 140

3. midwin seems to be truncated from the left, although it is NOT overlapping with either neighbor.

 Here's the relevant modified code:

        Fl_Window *leftwin = new TryWin(20,20, 120, 140, 1);

        leftwin->align(FL_ALIGN_CENTER);

        leftwin->color(0x88000000);     // dark red

        leftwin->end();

        

        Fl_Window *midwin = new TryWin(160, 20, 200, 150, 2);

        midwin->align(FL_ALIGN_CENTER);

        midwin->color(0xdd000000);      // red

        midwin->end();

        

        Fl_Window *rightwin = new Fl_Window(440, 20, 200, 140);

        rightwin->align(FL_ALIGN_CENTER);

        rightwin->color(0x00880000);    // dark green

 do I have the wrong version of the library? If so, please tell me how I can figure out what version I've got and update it properly.

[Ken Brooks]

BTW, if  I change the starting x of midwin to 200, I don't see it at all. 

[Greg Ercolano]

On 06/19/17 09:36, Ken Brooks wrote:

 Here's the relevant modified code:

        Fl_Window *leftwin = new TryWin(20,20, 120, 140, 1);

        leftwin->align(FL_ALIGN_CENTER);

        leftwin->color(0x88000000);     // dark red

        leftwin->end();

        

        Fl_Window *midwin = new TryWin(160, 20, 200, 150, 2);

        midwin->align(FL_ALIGN_CENTER);

        midwin->color(0xdd000000);      // red

        midwin->end();

        

        Fl_Window *rightwin = new Fl_Window(440, 20, 200, 140);

        rightwin->align(FL_ALIGN_CENTER);

        rightwin->color(0x00880000);    // dark green

    When I make that change to my code, I get this result with fltk.1.3.4 on OSX:

    Do you get something different?

 do I have the wrong version of the library? If so, please tell me how I can figure out what version I've got and update it properly.

    Maybe..

    You can find the version of FLTK you have by looking in FL/Enumerations.H
    and looking at the FL*VERSION macros, e.g.

#define FL_MAJOR_VERSION        1
#define FL_MINOR_VERSION        3
#define FL_PATCH_VERSION        4

    ..which is 1.3.4, the current release of FLTK.

[Greg Ercolano]

On 06/19/17 09:38, Ken Brooks wrote:

BTW, if  I change the starting x of midwin to 200, I don't see it at all. 

    When I make that change I get:



    If you're not getting these results, try downloading fltk 1.3.4 source and rebuild, e.g.

    1) Download: http://www.fltk.org/software.php?VERSION=1.3.4&FILE=fltk/1.3.4/fltk-1.3.4-1-source.tar.gz
    2) Extract to e.g. /usr/local/src/fltk-1.3.4
    3) Build it: ( cd /usr/local/src/fltk-1.3.4; make )
    4) Build and run the test program we've been discussing (i'm assuming its in /var/tmp/foo.cxx)
            cd /var/tmp
            /usr/local/src/fltk-1.3.4/fltk-config --compile foo.cxx --use-gl
            ./foo

    Try those exact steps, or whatever's similar for you, and see if you can replicate my results.
    Copy of the code attached to give the above image result.

[Ken Brooks]

Directions are not quite right: yours led to...

> make

...

=== making jpeg ===

/bin/sh: /Applications/Xcode: No such file or directory

and even after ./configure, same results.  

This is MacOS X 10.12 and Xcode.app 8.3.3 .  /Applications/Xcode.app, of course, is really a directory full of MacOSish details.  There is no /Applications/Xcode; it seems that README.OSX.txt and ./configure are both rather out of date.  The advanced version

> ./configure CXXFLAGS="-mmacosx-version-min=10.4" LDFLAGS="-mmacosx-version-min=10.4"

had no effect on this problem.

Please advise.

[Greg Ercolano]

On 08/01/17 16:27, Ken Brooks wrote:
> Directions are not quite right: yours led to...
>
> > make
> ...
> === making jpeg ===
> /bin/sh: /Applications/Xcode: No such file or directory
> and even after ./configure, same results.

Hmm, sounds like you're unable to build FLTK at this point,
separate from building the examples.

Not sure I understand, as you've been able to compile your own
examples so far, what changed?

If you recently installed Xcode, be sure you included the command line
tools option as well.

Offhand, it's weird to me that the command line 'make' is trying
to do something with /Application/Xcode, as it should be running
clang or gcc/g++, not Xcode. Make sure you don't have any environment
variables that might be causing the problem (printenv | grep Xcode).

If you can't build FLTK, I'd suggest starting a separate thread
regarding that, as we're off the subject of this thread regarding
drawing issues with subwindows.

In the new thread, please include:

> the mac osx release (sw_vers)
> If anything other than default Apple Xcode/cli installed, describe details
> the version of fltk you're building with (tar? svn/rev#? 1.3.x or 1.4.x?)
> the complete output of running of FLTK's ./configure
> the config.log that ./configure generated (as an attachment)
> after running ./configure, comment out ".SILENT:" from './makeinclude'
before running 'make', and then include the entire output of 'make'
up to and including the error message.

An easy way to comment out the .SILENT: line in makeinclude:

sed -ie 's/^\.SILENT:/#.SILENT:/' makeinclude

[Ken Brooks]

In my earlier attempt I used the XCode / Framework approach, which seemingly ended in corrupt libraries.  So I tried taking your instructions literally, complete with a fresh download, to start from a very clean, well known starting point.  Oops.  Not so well known...  

Ken