Re: [fltk.bugs] [HIGH] STR #2944: Mac OS X Fl_Gl_Window bugs - allFLTK versions

2013-04-06 Thread Lynn Quam
Yes, I agree that find_offset would be a useful method.

Regarding bug #1, the swap_buffers problem with glRasterPos being modified by 
gl_draw on Mac OS X:  Looking at the non-APPLE implementation(s) of gl_draw, 
they appear to leave that state of glRasterPos alone, which is probably why 
this bug has not been previously reported.  However, it is probably desirable 
that swap_buffers not depend on the state of glRasterPos, or the OpenGL 
transform matrices.


 --PART-BOUNDARY
 Content-Type: text/plain

 DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

 [STR Active]

 Link: http://www.fltk.org/str.php?L2944
 Version: 1.3.2


 To fix #2, I'm thinking the attached patch, rasterpos_bugfix.patch,
 might be a good way to implement the fix with code reuse in mind.

 This adds a find_offset() method to Fl_Widget.. essentially the same code
 you provided from Fl_mac.cxx, but made into a method so that
 both Fl_mac.cxx + Fl_Gl_Window.cxx can use it.

 Funny thing though, I *think* Fl_mac.cxx is completely unused code,
 a left over from the de-carbonization of FLTK. (verifying this with
 the other devs) In which case the code reuse issue might be moot.

 Still, it's probably useful to have this as a method; awaiting info
 from the other devs.

 Anyway, leaving this alternate patch suggestion to fix just #2 here,
 in case I get pulled off on other stuff and forget where I left off.


 Link: http://www.fltk.org/str.php?L2944
 Version: 1.3.2
 --PART-BOUNDARY
 Content-Type: text/plain
 Content-Disposition: attachment; filename=rasterpos_bugfix.patch

 Index: src/Fl_Gl_Window.cxx
 ===
 --- src/Fl_Gl_Window.cxx  (revision 9861)
 +++ src/Fl_Gl_Window.cxx  (working copy)
 @@ -183,8 +183,10 @@
GLint xywh[4];

if (window()) {
 -xywh[0] = x();
 -xywh[1] = window()-h() - y() - h();
 +int xoff,yoff;
 +const Fl_Window *win = find_offset(xoff, yoff);  // STR #2944
 +xywh[0] = xoff;
 +xywh[1] = win-h() - yoff - h();
} else {
  xywh[0] = 0;
  xywh[1] = 0;
 Index: src/Fl_Window.cxx
 ===
 --- src/Fl_Window.cxx (revision 9861)
 +++ src/Fl_Window.cxx (working copy)
 @@ -278,6 +278,21 @@
icon_ = ic;
  }

 +/**
 +  Finds the x/y offset of the current window relative to the top-level 
 window.
 +  \param[out] xoff,yoff Returns the x/y offset
 +  \returns the top-level window
 +*/
 +Fl_Window* Fl_Window::find_offset(int xoff, int yoff) const {
 +  xoff = yoff = 0;
 +  const Fl_Window *win = (const Fl_Window*)this;
 +  while (win  win-window()) {
 +xoff += win-x();// accumulate offsets
 +yoff += win-y();
 +win = win-window(); // walk up window hierarchy
 +  }
 +  return (Fl_Window*)win;
 +}

  //
  // End of $Id$.
 Index: FL/Fl_Window.H
 ===
 --- FL/Fl_Window.H(revision 9861)
 +++ FL/Fl_Window.H(working copy)
 @@ -120,6 +120,7 @@
  \see force_position(int)
*/
int force_position() const { return ((flags()  FORCE_POSITION)?1:0); }
 +  Fl_Window* find_offset(int xoff, int yoff) const;

  public:


 --PART-BOUNDARY--


___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs


Re: [fltk.bugs] [HIGH] STR #2944: Mac OS X Fl_Gl_Window bugs - all FLTK versions

2013-04-05 Thread Lynn Quam
DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Link: http://www.fltk.org/str.php?L2944
Version: 1.3.2


Attached file GlWindow-rasterpos-bug.c++...


Link: http://www.fltk.org/str.php?L2944
Version: 1.3.2// LHQuam modification to gl_overlay.cxx to demonstrate Mac OS X Gl_Window 
glRasterPos bug 
// when drawing text using gl_draw to Gl_Window AND using draw_overlay.

// On Mac OS X

// g++ -g  -Wno-deprecated-declarations -Wall -Wunused -Wno-format-y2k  -fPIC 
-fno-exceptions -fno-strict-aliasing  
-I/homedir/quam/Q/downloads/fltk/fltk-1.3.2-mac/ -o GlWindow-rasterpos-bug 
GlWindow-rasterpos-bug.c++ -L/opt/local/lib -lfltk_gl -lfltk -framework AGL 
-framework OpenGL -framework ApplicationServices  -framework Cocoa

// On Mac OS X:  To redirect to alternate library location:
// export DYLD_LIBRARY_PATH=/homedir/quam/Q/downloads/fltk/fltk-1.3.2-mac/src

// On Linux

//g++ -g  -Wno-deprecated-declarations -Wall -Wunused -Wno-format-y2k  -fPIC 
-fno-exceptions -fno-strict-aliasing  
-I/homedir/quam/Q/downloads/fltk/fltk-1.3.2/ -o GlWindow-rasterpos-bug 
GlWindow-rasterpos-bug.c++ -L/homedir/quam/downloads/fltk/fltk-1.3.2/src/  
-lfltk.1.3 -lfltk_gl.1.3 -lGL

// On Linux:  To redirect to alternate library location:
// set environment 
LD_LIBRARY_PATH=/homedir/quam/downloads/fltk/fltk-1.3-SVN-20130404/src

//
// $Id: gl_overlay.cxx 8864 2011-07-19 04:49:30Z greg.ercolano $
//
// OpenGL overlay test program for the Fast Light Tool Kit (FLTK).
//
// Copyright 1998-2010 by Bill Spitzak and others.
//
// This library is free software. Distribution and use rights are outlined in
// the file COPYING which should have been included with this file.  If this
// file is missing or damaged, see the license at:
//
// http://www.fltk.org/COPYING.php
//
// Please report all bugs and problems on the following page:
//
// http://www.fltk.org/str.php
//

#include config.h
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Hor_Slider.H
#include FL/Fl_Toggle_Button.H
#include FL/math.h

#if !HAVE_GL
#include FL/Fl_Box.H
class shape_window : public Fl_Box {
public: 
  int sides;
  shape_window(int x,int y,int w,int h,const char *l=0)
:Fl_Box(FL_DOWN_BOX,x,y,w,h,l){
  label(This demo does\nnot work without GL);
  }
};
#else
#include FL/gl.h
#include FL/Fl_Gl_Window.H

class shape_window : public Fl_Gl_Window {
  void draw();
  void draw_overlay();
public:
  int sides;
  int overlay_sides;
  shape_window(int x,int y,int w,int h,const char *l=0);
};

shape_window::shape_window(int x,int y,int w,int h,const char *l) :
Fl_Gl_Window(x,y,w,h,l) {
  sides = overlay_sides = 3;
}

void shape_window::draw() {
// the valid() property may be used to avoid reinitializing your
// GL transformation for each redraw:
  if (!valid()) {
valid(1);
glLoadIdentity();
glViewport(0,0,w(),h());
  }
// draw an amazing but slow graphic:
  glClear(GL_COLOR_BUFFER_BIT);
  //  for (int j=1; j=1000; j++) {
glBegin(GL_POLYGON);
for (int j=0; jsides; j++) {
  double ang = j*2*M_PI/sides;
  glColor3f(float(j)/sides,float(j)/sides,float(j)/sides);
  glVertex3f(cos(ang),sin(ang),0);
}
glEnd();
gl_draw(call to gl_draw, 0.0f,0.0f);  // comment this line out to 
suppress the bug
  
  // }
}

void shape_window::draw_overlay() {
// the valid() property may be used to avoid reinitializing your
// GL transformation for each redraw:
  if (!valid()) {
valid(1);
glLoadIdentity();
glViewport(0,0,w(),h());
  }
// draw an amazing graphic:
  gl_color(FL_RED);
  glBegin(GL_LINE_LOOP);
  for (int j=0; joverlay_sides; j++) {
double ang = j*2*M_PI/overlay_sides;
glVertex3f(cos(ang),sin(ang),0);
  }
  glEnd();
}
#endif

// when you change the data, as in this callback, you must call redraw():
void sides_cb(Fl_Widget *o, void *p) {
  shape_window *sw = (shape_window *)p;
  sw-sides = int(((Fl_Slider *)o)-value());
  sw-redraw();
}

#if HAVE_GL
void overlay_sides_cb(Fl_Widget *o, void *p) {
  shape_window *sw = (shape_window *)p;
  sw-overlay_sides = int(((Fl_Slider *)o)-value());
  sw-redraw_overlay();
}
#endif
#include stdio.h
int main(int argc, char **argv) {

  Fl_Window window(300, 370);

  shape_window sw(10, 75, window.w()-20, window.h()-90);
//sw.mode(FL_RGB);
  window.resizable(sw);

  Fl_Hor_Slider slider(60, 5, window.w()-70, 30, Sides:);
  slider.align(FL_ALIGN_LEFT);
  slider.callback(sides_cb,sw);
  slider.value(sw.sides);
  slider.step(1);
  slider.bounds(3,40);

  Fl_Hor_Slider oslider(60, 40, window.w()-70, 30, Overlay:);
  oslider.align(FL_ALIGN_LEFT);
#if HAVE_GL
  oslider.callback(overlay_sides_cb,sw);
  oslider.value(sw.overlay_sides);
#endif
  oslider.step(1);
  oslider.bounds(3,40);

  window.end();
  window.show(argc,argv);
#if HAVE_GL
  printf(Can do overlay = %d\n, sw.can_do_overlay());
  sw.show();
  sw.redraw_overlay();
#else
  sw.show();
#endif

  return Fl::run();
}

//
// End of $Id: gl_overlay.cxx 8864 2011-07-19 04:49:30Z 

Re: [fltk.bugs] [HIGH] STR #2944: Mac OS X Fl_Gl_Window bugs - all FLTK versions

2013-04-05 Thread Lynn Quam
DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Link: http://www.fltk.org/str.php?L2944
Version: 1.3.2


Attached file GlWindow-nested-window-bug.c++...


Link: http://www.fltk.org/str.php?L2944
Version: 1.3.2// LHQuam modification to shape.cxx to demonstrate Mac OS X Gl_Window bug when 
the Gl_Window 
// is inside nested Fl_Windows. 
//

// On Mac OS X

// g++ -g  -Wno-deprecated-declarations -Wall -Wunused -Wno-format-y2k  -fPIC 
-fno-exceptions -fno-strict-aliasing  
-I/homedir/quam/Q/downloads/fltk/fltk-1.3.2-mac/ -o GlWindow-nested-window-bug 
GlWindow-nested-window-bug.c++ -L/opt/local/lib -lfltk_gl -lfltk -framework AGL 
-framework OpenGL -framework ApplicationServices  -framework Cocoa

// On Mac OS X:  To redirect to alternate library location:
// export DYLD_LIBRARY_PATH=/homedir/quam/Q/downloads/fltk/fltk-1.3.2-mac/src

// On Linux

//g++ -g  -Wno-deprecated-declarations -Wall -Wunused -Wno-format-y2k  -fPIC 
-fno-exceptions -fno-strict-aliasing  
-I/homedir/quam/Q/downloads/fltk/fltk-1.3.2/ -o GlWindow-nested-window-bug 
GlWindow-nested-window-bug.c++ -L/homedir/quam/downloads/fltk/fltk-1.3.2/src/  
-lfltk.1.3 -lfltk_gl.1.3 -lGL

// On Linux:  To redirect to alternate library location:
// set environment 
LD_LIBRARY_PATH=/homedir/quam/downloads/fltk/fltk-1.3-SVN-20130404/src

// ##
// $Id: shape.cxx 8864 2011-07-19 04:49:30Z greg.ercolano $
//
// Tiny OpenGL demo program for the Fast Light Tool Kit (FLTK).
//
// Copyright 1998-2010 by Bill Spitzak and others.
//
// This library is free software. Distribution and use rights are outlined in
// the file COPYING which should have been included with this file.  If this
// file is missing or damaged, see the license at:
//
// http://www.fltk.org/COPYING.php
//
// Please report all bugs and problems on the following page:
//
// http://www.fltk.org/str.php
//

#include config.h
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Hor_Slider.H
#include FL/math.h

#if HAVE_GL

#include FL/gl.h
#include FL/Fl_Gl_Window.H

class shape_window : public Fl_Gl_Window {
  void draw();
public:
  int sides;
  shape_window(int x,int y,int w,int h,const char *l=0);
};

shape_window::shape_window(int x,int y,int w,int h,const char *l) :
Fl_Gl_Window(x,y,w,h,l) {
  sides = 3;
}

void shape_window::draw() {
// the valid() property may be used to avoid reinitializing your
// GL transformation for each redraw:
  if (!valid()) {
valid(1);
glLoadIdentity();
glViewport(0, 0, w(), h());
  }
// draw an amazing graphic:
  glClear(GL_COLOR_BUFFER_BIT);
  glColor3f(.5,.6,.7);
  glBegin(GL_POLYGON);
  for (int j=0; jsides; j++) {
double ang = j*2*M_PI/sides;
glVertex3f(cos(ang),sin(ang),0);
  }
  glEnd();
}

#else

#include FL/Fl_Box.H
class shape_window : public Fl_Box {
public: 
  int sides;
  shape_window(int x,int y,int w,int h,const char *l=0)
:Fl_Box(FL_DOWN_BOX,x,y,w,h,l){
  label(This demo does\nnot work without GL);
  }
};

#endif

// when you change the data, as in this callback, you must call redraw():
void sides_cb(Fl_Widget *o, void *p) {
  shape_window *sw = (shape_window *)p;
  sw-sides = int(((Fl_Slider *)o)-value());
  sw-redraw();
}

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

  Fl_Window window(300, 330);  // top-level Fl_Window
  Fl_Window win2(0,0,300,290); // Fl_Window nested inside top-level Fl_Window
  
  shape_window sw(10, 10, 280, 280);
// make it resize:
  win2.resizable(sw);
  win2.end();

  window.resizable(win2);
  //  window.size_range(300,330,0,0,1,1,1);
// add a knob to control it:
  Fl_Hor_Slider slider(50, 295, window.w()-60, 30, Sides:);
  slider.align(FL_ALIGN_LEFT);
  slider.callback(sides_cb,sw);
  slider.value(sw.sides);
  slider.step(1);
  slider.bounds(3,40);

  window.end();
  window.show(argc,argv);
  
  return Fl::run();
}

//
// End of $Id: shape.cxx 8864 2011-07-19 04:49:30Z greg.ercolano $.
//
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs


Re: [fltk.bugs] [HIGH] STR #2944: Mac OS X Fl_Gl_Window bugs - all FLTK versions

2013-04-05 Thread Lynn Quam

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Link: http://www.fltk.org/str.php?L2944
Version: 1.3.2


I have added files for two test programs that demonstrate the reported
Gl_Window bugs.


Link: http://www.fltk.org/str.php?L2944
Version: 1.3.2

___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs


[fltk.bugs] Mac OS X Fl_Gl_Window bugs

2013-04-03 Thread Lynn Quam
I have found two major bugs in the Mac OS X implementation of Fl_Gl_Window.  I 
will report the bugs in two separate postings.

The first bug occurs with overlays on Fl_Gl_Windows.  If either the OpenGL view 
transform or model transform are other than identity, then the code in 
Fl_Gl_Window::swap_buffers calling glCopyPixels to copy the GL_BACK to GL_FRONT 
has the wrong glRasterPos.

I have code to fix this bug.

Since I have not previously reported FLTK bug fixes, I would like to know the 
procedure that I should use.


___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs


[fltk.bugs] Mac OS X Fl_Gl_Window bugs

2013-04-03 Thread Lynn Quam
The Mac OS X Fl_Gl_Window implementation has a serious bug in the code for 
Fl_Gl_Window::make_current when Fl_Windows are nested.  The computation for the 
x and y values of the xywh array passed to aglSetInteger(context_, 
AGL_BUFFER_RECT, xywh) does not take this nesting into account, causing the 
Gl_Window drawing area to be incorrectly placed inside the main window.

I have code to fix this bug.

Since I have not previously reported FLTK bug fixes, I would like to know the 
procedure that I should use.

___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs


Re: [fltk.bugs] Mac OS X Fl_Gl_Window bugs

2013-04-03 Thread Lynn Quam
 I have found two major bugs in the Mac OS X implementation of Fl_Gl_Window.  
 I will report the bugs in two separate postings.

 The first bug occurs with overlays on Fl_Gl_Windows.  If either the OpenGL 
 view transform or model transform are other than identity, then the code in 
 Fl_Gl_Window::swap_buffers calling glCopyPixels to copy the GL_BACK to 
 GL_FRONT has the wrong glRasterPos.

 I have code to fix this bug.

 Since I have not previously reported FLTK bug fixes, I would like to know the 
 procedure that I should use.




I forgot to mention that this problem is only triggered if some OpenGL code 
causes the glRasterPos to be changed from the bottom left corner of the 
Gl_Window.  In my case, the application code called gl_draw(const char* str, 
int n) to draw a string into the Gl_Window, which changes the glRasterPos.
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs


Re: [fltk.development] New FLTK3 user -- layout feature request

2011-12-01 Thread Lynn Quam

 Huh? I don't understand the question.
 You get the size of a button just by calling its w() and h() methods.
 What property of the widget are you trying to measure other than its
 width and height?


The w() and h() methods return the size that the user requested when the widget 
was created or resized.  What I want is the shrink-wrap size.
For labels and buttons it is the size of the label and/or image and the 
surrounding box.

For example:

void fl_Widget_shrinkwrap_size(Widget *o, int* sizes) {
  int w,h;
  o-measure(w,h);
  if (w  5  o-align()(fltk3::ALIGN_LEFT|fltk3::ALIGN_RIGHT)) {w += 6;}

  sizes[0]=w + fltk3::box_dw(o-box());
  sizes[1]=h + fltk3::box_dh(o-box());
}

___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev


[fltk.development] New FLTK3 user -- layout feature request

2011-11-30 Thread Lynn Quam
I am a new user of FLTK3 who is migrating from using Tcl/Tk for GUI 
development.  My software development is in Common Lisp (SBCL).  I have some 
tests successfully running using FLTK3 in combination with OpenGL.

I like everything I am seeing in FLTK3, EXCEPT for (semi-)automatic layout of 
widget arrangements.  Tk has simple, yet effective ways to control widget 
placement.  I am willing to write layout class methods for FLTK, but some basic 
infrastructure appears to be missing.

An outside_measure() method should be implemented for classes, such as Button 
and all of its subclasses, so that the outside dimensions of those widgets can 
be determined.  The existing measure() method returns the dimensions of the 
label string and/or image.   I have implemented such methods for Menubar and 
Widget, but the implementations are fragile, depending on FLTK internal details.

Is there anything in the ROADMAP directed toward more advanced layout 
infrastructure?


___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev