from:"Manolo Gouy"

Re: [fltk.bugs] [LOW] STR #2947: Drawing Things in FLTK / minor fixes

2013-04-09 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2947
Version: 1.3.2
Fix Version: 1.3-current (r9868)


Fixed in Subversion repository.

Thanks for spotting that.


Link: http://www.fltk.org/str.php?L2947
Version: 1.3.2
Fix Version: 1.3-current (r9868)

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

Re: [fltk.bugs] [MOD] STR #2931: Re-implement fl_scandir for *nix systems that do not provide a native version

2013-02-20 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current


The patch is also OK with Mac OS X 10.8


Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current

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

Re: [fltk.bugs] [HIGH] STR #2928: Shortcuts not processed correctly on MacOS

2013-01-29 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2928
Version: 1.3-current
Fix Version: 1.3-current (r9811)


Fixed in Subversion repository.


Link: http://www.fltk.org/str.php?L2928
Version: 1.3-current
Fix Version: 1.3-current (r9811)

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

Re: [fltk.bugs] [HIGH] STR #2928: Shortcuts not processed correctly on MacOS

2013-01-28 Thread Manolo Gouy


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

[STR Pending]

Link: http://www.fltk.org/str.php?L2928
Version: 1.3-current
Fix Version: 1.3-current (r9811)


OK. alt+letter shortcuts are necessary.

I believe the problem is fixed in the SVN repository with r.9811.

@Christophe: can you, please, confirm?


Link: http://www.fltk.org/str.php?L2928
Version: 1.3-current
Fix Version: 1.3-current (r9811)

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

Re: [fltk.bugs] [HIGH] STR #2928: Shortcuts not precessed correctly on MacOS

2013-01-28 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2928
Version: 1.3-current


The result of typing twice alt-e in a regular Mac OS text application
(say, TextEdit) with the US keyboard is
Â´Â´
where the 2nd acute is underlined. With the current CVS code, we obtain 
the same thing with FLTK text widgets (e.g., the editor demo).
With FLTK 1.3.2, the second acute does not appear. I am tempted to 
conclude that the new behaviour is the correct one.

My reading of this STR report is that it is not appropriate for the
Mac OS platform to use alt+letter as a shortcut, because these 
key combinations are meant to produce either non-ascii characters
(for example, Â©) or dead keys, meant to be combined with another
key to produce an accented character. This 2nd case occurs
with the alt+e combination that, on US keyboards, but not on
many others, is a dead key preparing for the construction of a letter
with the acute accent. 

I believe that shortcuts should be assigned to key combinations
that don't produce text, and that text-producing key combinations 
should be used to insert this text in a text widget.
There are many combinations that don't produce text: cmd-letter, 
ctrl-letter, cmd-alt-letter, etc... 

Opinions?


Link: http://www.fltk.org/str.php?L2928
Version: 1.3-current

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

Re: [fltk.bugs] [HIGH] STR #2921: r9798 breaks native file chooser on MacOSX 10.8.2

2013-01-21 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2921
Version: 1.3-current
Fix Version: 1.3-current (r9806)


Fixed in Subversion repository.


Link: http://www.fltk.org/str.php?L2921
Version: 1.3-current
Fix Version: 1.3-current (r9806)

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

Re: [fltk.bugs] [MOD] STR #2917: FLTK 1.3.2/trunk does not compile on OS X 10.4 and older

2013-01-17 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2917
Version: 1.3-current
Fix Version: 1.3-current (r9799)


Fixed in Subversion repository.


Link: http://www.fltk.org/str.php?L2917
Version: 1.3-current
Fix Version: 1.3-current (r9799)

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

Re: [fltk.bugs] [MOD] STR #2915: Mac OS: subwindow is not shown correctly after hide() and then show()

2013-01-13 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2915
Version: 1.3.2
Fix Version: 1.3-current (r9788)


Closed after confirmation from the OP.


Link: http://www.fltk.org/str.php?L2915
Version: 1.3.2
Fix Version: 1.3-current (r9788)

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

Re: [fltk.bugs] [MOD] STR #2915: Mac OS: subwindow is not shown correctly after hide() and then show()

2013-01-08 Thread Manolo Gouy


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

[STR Pending]

Link: http://www.fltk.org/str.php?L2915
Version: 1.3.2
Fix Version: 1.3-current (r9788)


Fixed in Subversion repository.


Link: http://www.fltk.org/str.php?L2915
Version: 1.3.2
Fix Version: 1.3-current (r9788)

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

[fltk.bugs] [MOD] STR #2915: Mac OS: subwindow is not shown correctly after hide() and then show()

2013-01-08 Thread Manolo Gouy


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

[STR New]

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


On Mac OS, when a subwindow is created, shown, hidden, and shown again,
it doesn't get drawn until the window is resized or is minimized
and unminimized.


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

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

Re: [fltk.bugs] Mac OS: bug in make_current

2012-12-19 Thread Manolo Gouy

It is unexpected that you call Fl_Window::make_current(), that runs
before writing to a window, when you are destroying this window.
Is it possible that you destroy this window in a callback of an
element of the window? In that case, you should use
Fl::delete_widget(Fl_Widget*)
to delete your window.


> Hello,
>
> I have been using FLTK for quite a while now (about a year), and with some 
> success. I use the 1.3.2 version, which I have integrated in projects on 
> Windows, Mac OS and Linux.
>
> However, I have a real problem on Mac OS, a crash which happens in certain 
> cases when I mix a (non FLTK) modal window and an FLTK window. When I destroy 
> the FLTK window, I have a crash...
>
> I traced the error back to Fl::make_current in Fl_cocoa.mm, with a lockFocus, 
> which is where the bug is perpetrated...
>
> For the moment, the only way for me to bypass this problem is to add a 
> @try/@catch around the lockFocus and I destroy the window...
>
> void Fl_Window::make_current() {
> ...
> NSView *current_focus = [NSView focusView];
> // sometimes current_focus is set to a non-FLTK view: don't touch that
> @try {
> if ( [current_focus isKindOfClass:[FLView class]] )
> [current_focus unlockFocus];
> [[i->xid contentView]  lockFocus]; <-- CRASH HERE
> }
> @catch(NSException* e) {
> delete this;  <-- VERY HORRIBLE, but it does not seem to matter
> return;
> }
>
>
> It works, but I do not feel very comfortable to modify the code of a library 
> which I use on many platform.
>
> Do you have any idea how I could bypass this error in a more acceptable way?
>
> Thank you in advance...
>
>
>

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

Re: [fltk.bugs] Mac OS: bug in make_current

2012-12-19 Thread Manolo Gouy

Could you, please, prepare a minimal program that triggers the problem
and post it here?

> Hello,
>
> I have been using FLTK for quite a while now (about a year), and with some 
> success. I use the 1.3.2 version, which I have integrated in projects on 
> Windows, Mac OS and Linux.
>
> However, I have a real problem on Mac OS, a crash which happens in certain 
> cases when I mix a (non FLTK) modal window and an FLTK window. When I destroy 
> the FLTK window, I have a crash...
>
> I traced the error back to Fl::make_current in Fl_cocoa.mm, with a lockFocus, 
> which is where the bug is perpetrated...
>
> For the moment, the only way for me to bypass this problem is to add a 
> @try/@catch around the lockFocus and I destroy the window...
>
> void Fl_Window::make_current() {
> ...
> NSView *current_focus = [NSView focusView];
> // sometimes current_focus is set to a non-FLTK view: don't touch that
> @try {
> if ( [current_focus isKindOfClass:[FLView class]] )
> [current_focus unlockFocus];
> [[i->xid contentView]  lockFocus]; <-- CRASH HERE
> }
> @catch(NSException* e) {
> delete this;  <-- VERY HORRIBLE, but it does not seem to matter
> return;
> }
>
>
> It works, but I do not feel very comfortable to modify the code of a library 
> which I use on many platform.
>
> Do you have any idea how I could bypass this error in a more acceptable way?
>
> Thank you in advance...
>
>
>

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

Re: [fltk.bugs] [HIGH] STR #2886: Fl_Tile and scrollbars

2012-12-05 Thread Manolo Gouy


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

[STR Pending]

Link: http://www.fltk.org/str.php?L2886
Version: 1.3-current
Fix Version: 1.3-current (r9720)


Yes, seems this bug is now repaired.


Link: http://www.fltk.org/str.php?L2886
Version: 1.3-current
Fix Version: 1.3-current (r9720)

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

Re: [fltk.bugs] [HIGH] STR #2886: Fl_Tile and scrollbars

2012-12-05 Thread Manolo Gouy


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

[STR Active]

Link: http://www.fltk.org/str.php?L2886
Version: 1.3-current
Fix Version: 1.3-current (r9720)


Reopened because the fix in r.9720 creates a bug apparent with fluid.

To reproduce on X11 or WIN32 (no bug with MacOS):
- goto the fluid/ directory in a terminal
- run ./fluid about_panel.fl &
- if the main window doesn't show a horizontal scrollbar, shrink
the window until the scrollbar appears; close fluid; start it again

==> The menubar isn't drawn at all.

Reverting file src/Fl_Browser_.cxx to its previous version
clears the bug.

@Greg: can you investigate?


Link: http://www.fltk.org/str.php?L2886
Version: 1.3-current
Fix Version: 1.3-current (r9720)

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

Re: [fltk.bugs] [MOD] STR #2888: CMake build on OSX 10.7 fails

2012-11-22 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2888
Version: 1.3.1
Fix Version: 1.3.1


Closing this because a workaround has been found.

I now realize that you initially reported that build was errorless
with configure/make. This implies your compilers (CMake uses the same)
can find scandir() and friends when asked by configure. Could you
have somewhere a CMake configuration file (may be a $HOME/.cmake file)
that imposes a strict ANSI compilation that would outlaw the scandir()
function?

Please, note that CMake, as configured now, produces unbundled 
executables, which is not perfect for a Mac OS X application.
The configure/make procedure produces mostly unbundled execs also
except for blocks, checkers and sudoku which are built into
true application bundles. Both FLTK Xcode projects produce only 
application bundles.


Link: http://www.fltk.org/str.php?L2888
Version: 1.3.1
Fix Version: 1.3.1

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

Re: [fltk.bugs] [MOD] STR #2888: CMake build on OSX 10.7 fails

2012-11-21 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2888
Version: 1.3-current


You may add
#define HAVE_SCANDIR 1
to your config.h file and then run make.
This should unblock the compilation of the scandir.c file.

I would tend to believe it's your installation of the C/C++ compilers
that is slightly broken somehow, because the scandir() function
should be detected, and same for snprintf(), strlcat(), strlcpy()
and vsnprintf().


Link: http://www.fltk.org/str.php?L2888
Version: 1.3-current

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

Re: [fltk.bugs] [MOD] STR #2890: MacOS 10.8: unbundled applications don't appear in dock nor menu bar

2012-11-21 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2890
Version: 1.3.1
Fix Version: 1.3-current (r9729)


Fixed in Subversion repository.


Link: http://www.fltk.org/str.php?L2890
Version: 1.3.1
Fix Version: 1.3-current (r9729)

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

[fltk.bugs] [MOD] STR #2890: MacOS 10.8: unbundled applications don't appear in dock nor menu bar

2012-11-21 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2890
Version: 1.3.1


With MacOS X 10.8, unbundled applications don't appear in dock 
nor have a menu bar.


Link: http://www.fltk.org/str.php?L2890
Version: 1.3.1

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

Re: [fltk.bugs] [MOD] STR #2888: CMake build on OSX 10.7 fails

2012-11-20 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2888
Version: 1.3-current


Then, the error is that cmake doesn't find scandir which does make
part of Mac OS X.
Could you consider using the cmake available from www.cmake.org ?


Link: http://www.fltk.org/str.php?L2888
Version: 1.3-current

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

Re: [fltk.bugs] [MOD] STR #2888: CMake build on OSX 10.7 fails

2012-11-20 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2888
Version: 1.3-current


This is unexpected because CMake builds without error
here under Mac OSX 10.8 and used to do so a few months ago
when I used 10.7.

CMake should output
Looking for scandir
Looking for scandir - found
and put
#define HAVE_SCANDIR 1
in the config.h file it creates.
Then, when file scandir.c is compiled, the statement
#  if !HAVE_SCANDIR 
should avoid the error you report.

Could you, please, double check that you do a clean install of 
FLTK 1.3.1, and report whether the resulting config.h file 
defines HAVE_SCANDIR


Link: http://www.fltk.org/str.php?L2888
Version: 1.3-current

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

Re: [fltk.bugs] [MOD] STR #2887: Weird behavior of Fl_Scroll on retina display (MacOS X 10.8)

2012-11-15 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2887
Version: 1.3.1
Fix Version: 1.3-current (r9721)


Fixed in Subversion repository.

Great you found the magic epsilon value!


Link: http://www.fltk.org/str.php?L2887
Version: 1.3.1
Fix Version: 1.3-current (r9721)

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

Re: [fltk.bugs] [MOD] STR #2887: Weird behavior of Fl_Scroll on retina display (MacOS X 10.8)

2012-11-14 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2887
Version: 1.3-current


A very similar bug appeared with Mac OS 10.6 and was solved by adding
the epsilon quantity in function rect_to_NSBitmapImageRep().
Unfortunately I can't reproduce the bug for lack of mac with
retina display. The solution might well be in playing with
those three statements:

  CGFloat epsilon = 0;
  if (fl_mac_os_version >= 100600) epsilon = 0.001;
  NSRect rect = NSMakeRect(x - epsilon, y - epsilon, w, h);


Link: http://www.fltk.org/str.php?L2887
Version: 1.3-current

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

Re: [fltk.bugs] [MOD] STR #2887: Weird behavior of Fl_Scroll on retina display (MacOS X 10.8)

2012-11-14 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2887
Version: 1.3-current


Thanks. Unfortunately this is a false solution, because it redraws
everything instead of scrolling the window.

Could you just try to start again from the stock Fl_cocoa.mm
and change its line #3329 replacing 0.001 by 0.1  ?


Link: http://www.fltk.org/str.php?L2887
Version: 1.3-current

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

Re: [fltk.bugs] [MOD] STR #2887: Weird behavior of Fl_Scroll on retina display (MacOS X 10.8)

2012-11-14 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2887
Version: 1.3-current


Hi Christophe,

Could you, please, change in file Fl_cocoa.mm the current function
rect_to_NSBitmapImageRep() by this one

static NSBitmapImageRep* rect_to_NSBitmapImageRep(Fl_Window *win, int x,
int y, int w, int h)
{
  while (win->window()) {
x += win->x();
y += win->y();
win = win->window();
  }
  NSRect rect = NSMakeRect(x, y, w, h);
  NSView *view = [Fl_X::i(win)->xid contentView];
  NSBitmapImageRep* imagerep = [view
bitmapImageRepForCachingDisplayInRect:rect];
  [view cacheDisplayInRect:rect toBitmapImageRep:imagerep];
  [imagerep retain];
  return imagerep;
}

and report whether it solves the bug?


Link: http://www.fltk.org/str.php?L2887
Version: 1.3-current

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

Re: [fltk.bugs] [HIGH] STR #2884: Fl_PNG_Image made from static memory will forget filename

2012-11-10 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2884
Version: 1.3.1
Fix Version: 1.3-current (r9712)


Fixed in Subversion repository.

The fix is a little different because a NULL name is acceptable
and means "don't add the image to the list of shared images".


Link: http://www.fltk.org/str.php?L2884
Version: 1.3.1
Fix Version: 1.3-current (r9712)

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

Re: [fltk.bugs] [CRIT] STR #2881: Check image bounds before allocation

2012-11-09 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2881
Version: 1.3-current
Fix Version: 1.3-current (r9709)


Fixed in Subversion repository.

The new static function Fl_RGB_Image::max_size(size) allows to 
control the maximum memory size allowed when creating a new 
Fl_RGB_Image object (one of its derived classes, really).
The default maximum size if infinite.
Calling this function beforehand will avoid the program crash
described here.


Link: http://www.fltk.org/str.php?L2881
Version: 1.3-current
Fix Version: 1.3-current (r9709)

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

Re: [fltk.bugs] [CRIT] STR #2881: Check image bounds before allocation

2012-11-05 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2881
Version: 1.3-current
Fix Version: 1.4-feature


The attached file 2881.patch corrects this issue (also with JPEG
images), but requires to use 
  #include 
  array = new(std::nothrow) char[xxx]
which is forbidden by the Configuration Management Plan.


Link: http://www.fltk.org/str.php?L2881
Version: 1.3-current
Fix Version: 1.4-feature

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

Re: [fltk.bugs] [CRIT] STR #2881: Check image bounds before allocation

2012-11-05 Thread Manolo Gouy

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

[STR New]

Link: http://www.fltk.org/str.php?L2881
Version: 1.3-current
Fix Version: 1.4-feature


Attached file "2881.patch"...


Link: http://www.fltk.org/str.php?L2881
Version: 1.3-current
Fix Version: 1.4-featureIndex: src/Fl_PNG_Image.cxx
===
--- src/Fl_PNG_Image.cxx(revision 9572)
+++ src/Fl_PNG_Image.cxx(working copy)
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if defined(HAVE_LIBPNG) && defined(HAVE_LIBZ)
 extern "C"
@@ -130,7 +131,7 @@
   {
 png_destroy_read_struct(&pp, &info, NULL);
 if (!from_memory) fclose(fp);
-Fl::warning("PNG file or data \"%s\" contains errors!\n", name_png);
+Fl::warning("PNG file or data \"%s\" is too large or contains errors!\n", 
name_png);
 return;
   }
 
@@ -178,7 +179,8 @@
 png_set_tRNS_to_alpha(pp);
 #  endif // HAVE_PNG_GET_VALID && HAVE_PNG_SET_TRNS_TO_ALPHA
 
-  array = new uchar[w() * h() * d()];
+  array = new(std::nothrow) uchar[w() * h() * d()];
+  if (!array) longjmp(png_jmpbuf(pp), 1);
   alloc_array = 1;
 
   // Allocate pointers...
Index: src/Fl_JPEG_Image.cxx
===
--- src/Fl_JPEG_Image.cxx   (revision 9572)
+++ src/Fl_JPEG_Image.cxx   (working copy)
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 
 // Some releases of the Cygwin JPEG libraries don't have a correctly
@@ -166,7 +167,8 @@
   h(dinfo.output_height);
   d(dinfo.output_components);
   
-  array = new uchar[w() * h() * d()];
+  array = new(std::nothrow) uchar[w() * h() * d()];
+  if (!array) longjmp(jerr.errhand_, 1);
   alloc_array = 1;
   
   jpeg_start_decompress(&dinfo);
@@ -342,7 +344,8 @@
   h(dinfo.output_height);
   d(dinfo.output_components);
   
-  array = new uchar[w() * h() * d()];
+  array = new(std::nothrow) uchar[w() * h() * d()];
+  if (!array) longjmp(jerr.errhand_, 1);
   alloc_array = 1;
   
   jpeg_start_decompress(&dinfo);
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs

Re: [fltk.bugs] [MOD] STR #2845: image test program blank on cygwin/GDI

2012-10-21 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2845
Version: 1.3-current


The image demo does work on Windows 7 and also through VirtualBox.
The bug, if any, is not of high priority.


Link: http://www.fltk.org/str.php?L2845
Version: 1.3-current

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

Re: [fltk.bugs] [MOD] STR #2849: X11 drag-n-drop of non-ascii pathname to FLTK widget fails

2012-10-18 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2849
Version: 1.3-current
Fix Version: 1.3-current (r9584)


Closed with the fl_decode_uri() support function and new documentation.


Link: http://www.fltk.org/str.php?L2849
Version: 1.3-current
Fix Version: 1.3-current (r9584)

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

Re: [fltk.bugs] [MOD] STR #2857: screen_xywh mouse pointer functions initially returns wrong data

2012-10-18 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2857
Version: 1.3-current
Fix Version: 1.3-current (r9701)


Fixed in Subversion repository.

Thanks for the patch.


Link: http://www.fltk.org/str.php?L2857
Version: 1.3-current
Fix Version: 1.3-current (r9701)

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

Re: [fltk.bugs] [LOW] STR #2878: Many warnings during MSWindows 7 64-bit compilation.

2012-10-18 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2878
Version: 1.3-current





Link: http://www.fltk.org/str.php?L2878
Version: 1.3-current

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

Re: [fltk.bugs] [HIGH] STR #2859: wait_for_expose sometimes gets incorrectly wedged

2012-10-16 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2859
Version: 1.3-current
Fix Version: 1.3-current (r9699)


Fixed in Subversion repository.

Thanks for the fix.


Link: http://www.fltk.org/str.php?L2859
Version: 1.3-current
Fix Version: 1.3-current (r9699)

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

[fltk.bugs] [LOW] STR #2878: Many warnings during MSWindows 7 64-bit compilation.

2012-10-08 Thread Manolo Gouy

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

[STR New]

Link: http://www.fltk.org/str.php?L2878
Version: 1.3-current


I compiled FLTK for MSWindows 7 64-bit using the MinGW 64 bit compiler
(gcc 4.7.0) and found that there are 3 warnings for each source
file plus a few more for those that include FL/Fl_Menu_Item.H.
They come from cast operations between the long and void* types
that differ in length on the 64-bit Windows7 platform.

I believe the correct solution for that is to replace
 void* user_data_;
by
 union {
   void* user_data_;
   long long_value_;
 };
in the declaration of the Fl_Widget class, and to use long_value_
instead of user_data_ wherever a long quantity is handled.

The attached file contains a patch with this change, protected
by #if FLTK_ABI_VERSION >= 10302, although I think the change
does not modify the class layout on real platforms.

Could another developer test this change with Microsoft's
64-bit compiler, and report what happens?


Link: http://www.fltk.org/str.php?L2878
Version: 1.3-currentIndex: Fl_Menu_Item.H
===
--- Fl_Menu_Item.H  (revision 9572)
+++ Fl_Menu_Item.H  (working copy)
@@ -110,7 +110,14 @@
   const char *text;///< menu item text, returned by label()
   int shortcut_;   ///< menu item shortcut
   Fl_Callback *callback_;   ///< menu item callback
+#if FLTK_ABI_VERSION >= 10302
+  union {
+void *user_data_;  ///< menu item user_data for the menu's callback
+long long_value_;  ///< same menu item field seen as a long quantity
+  };
+#else
   void *user_data_;///< menu item user_data for the menu's callback
+#endif
   int flags;   ///< menu item flags like FL_MENU_TOGGLE, 
FL_MENU_RADIO
   uchar labeltype_;///< how the menu item text looks like
   Fl_Font labelfont_;  ///< which font for this menu item text
@@ -240,7 +247,14 @@
 for the menu item's callback function.
 \see Fl_Callback_p Fl_MenuItem::callback() const
*/
-  void callback(Fl_Callback1*c, long p=0) {callback_=(Fl_Callback*)c; 
user_data_=(void*)p;}
+  void callback(Fl_Callback1*c, long p=0) {
+callback_=(Fl_Callback*)c; 
+#if FLTK_ABI_VERSION >= 10302
+long_value_ = p;
+#else
+user_data_=(void*)p;
+#endif
+  }
 
   /**
 Gets the user_data() argument that is sent to the callback function.
@@ -256,7 +270,13 @@
 argument.  This method casts the stored userdata() argument to long
 and returns it as a \e long value.
   */
-  long argument() const {return (long)(fl_intptr_t)user_data_;}
+  long argument() const {
+#if FLTK_ABI_VERSION >= 10302
+return long_value_;
+#else
+return (long)(fl_intptr_t)user_data_;
+#endif
+  }
   /**
 Sets the user_data() argument that is sent to the callback function.
 For convenience you can also define the callback as taking a long
@@ -264,7 +284,13 @@
 and stores it in the menu item's userdata() member.
 This may not be portable to some machines.
   */
-  void argument(long v) {user_data_ = (void*)v;}
+  void argument(long v) {
+#if FLTK_ABI_VERSION >= 10302
+long_value_ = v;
+#else
+user_data_ = (void*)v;
+#endif
+  }
 
   /** Gets what key combination shortcut will trigger the menu item. */
   int shortcut() const {return shortcut_;}
@@ -388,7 +414,13 @@
 the callback.
 You must first check that callback() is non-zero before calling this.
   */
-  void do_callback(Fl_Widget* o,long arg) const {callback_(o, (void*)arg);}
+  void do_callback(Fl_Widget* o,long arg) const {
+#if FLTK_ABI_VERSION >= 10302
+((Fl_Callback1*)callback_)(o, arg);
+#else
+callback_(o, (void*)arg);
+#endif
+  }
 
   // back-compatibility, do not use:
 
Index: Fl_Widget.H
===
--- Fl_Widget.H (revision 9572)
+++ Fl_Widget.H (working copy)
@@ -102,7 +102,14 @@
 
   Fl_Group* parent_;
   Fl_Callback* callback_;
+#if FLTK_ABI_VERSION >= 10302
+  union {
+void* user_data_;
+long long_value_;
+  };
+#else
   void* user_data_;
+#endif
   int x_,y_,w_,h_;
   Fl_Label label_;
   unsigned int flags_;
@@ -572,7 +579,14 @@
   \param[in] cb new callback
   \param[in] p user data
*/
-  void callback(Fl_Callback1*cb, long p=0) {callback_=(Fl_Callback*)cb; 
user_data_=(void*)p;}
+  void callback(Fl_Callback1*cb, long p=0) {
+callback_=(Fl_Callback*)cb; 
+#if FLTK_ABI_VERSION >= 10302
+long_value_=p;
+#else
+user_data_ = (void*)p;
+#endif
+  }
 
   /** Gets the user data for this widget.
   Gets the current user data (void *) argument that is passed to the 
callback function.
@@ -588,13 +602,25 @@
 
   /** Gets the current user data (long) argument that is passed to the 
callback function.
*/
-  long argument() const {return (long)(fl_intptr_t)user_data_;}
+  long argument() const {
+#if FLTK_ABI_VERSION >= 10302
+return long_value_;
+#else
+return (long)(fl_intp

Re: [fltk.bugs] [LOW] STR #2877: FLTK does dlopen on "libXrandr.so", should be "libXrandr.so.2"

2012-10-04 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2877
Version: 1.3-current
Fix Version: 1.3-current (r9695)


Fixed in Subversion repository.

Thanks for the good suggestion.


Link: http://www.fltk.org/str.php?L2877
Version: 1.3-current
Fix Version: 1.3-current (r9695)

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

Re: [fltk.bugs] FLTK 1.3 fails to build on OSX 10.8.2

2012-09-25 Thread Manolo Gouy

> I got an error compiling filename_list on my new OSX 10.8.2 computer:
>
> Compiling filename_list.cxx...
> filename_list.cxx: In function âint fl_filename_list(const char*, 
> dirent***, int (*)(dirent**, dirent**))â:
> filename_list.cxx:122: error: invalid conversion from âint (*)(const void*, 
> const void*)â to âint (*)(const dirent**, const dirent**)â
> filename_list.cxx:122: error:   initializing argument 4 of âint 
> scandir(const char*, dirent***, int (*)(const dirent*), int (*)(const 
> dirent**, const dirent**))â
> make[1]: *** [filename_list.o] Error 1
> make: *** [all] Error 1
>
> This is my gcc/os config:
>
> Adrians-MacBook-Pro:fltk-1.3.0 aboeing$ uname -a
> Darwin Adrians-MacBook-Pro.local 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 
> 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
>
> Adrians-MacBook-Pro:fltk-1.3.0 aboeing$ gcc -v
> Using built-in specs.
> Target: i686-apple-darwin11
> Configured with: 
> /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/src/configure 
> --disable-checking --enable-werror 
> --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 
> --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ 
> --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ 
> --with-slibdir=/usr/lib --build=i686-apple-darwin11 
> --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/dst-llvmCore/Developer/usr/local
>  --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 
> --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
> Thread model: posix
> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
>
>
> Anyway, to make FLTK compile I just replaced the definition with:
> int n = scandir(dirloc, list, 0, (int(*)(const dirent **, const dirent 
> **))sort);
>

This issue has been already reported and is fixed in the svn repository.
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs

Re: [fltk.bugs] [MOD] STR #2871: int Fl_Native_File_Chooser::showfile() uses MAX_PATH defined 260 - this is too short for some applications

2012-09-13 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2871
Version: 1.3.0
Fix Version: 1.3-current (r9174)


Fixed in Subversion repository.

This is the same as STR#2733 which has been fixed in Nov 2011.
Please use the version from the current svn repository.


Link: http://www.fltk.org/str.php?L2871
Version: 1.3.0
Fix Version: 1.3-current (r9174)

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

Re: [fltk.bugs] [MOD] STR #2868: Xcode 4 Project file builds cmap.cxx into the fltk.framework

2012-08-30 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2868
Version: 1.3.0
Fix Version: 1.3-current (r9678)


Fixed in Subversion repository.


Link: http://www.fltk.org/str.php?L2868
Version: 1.3.0
Fix Version: 1.3-current (r9678)

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

Re: [fltk.bugs] [MOD] STR #2864: FLTK 1.3.0 does not compile under Mac OSX Mountain Lion

2012-08-08 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2864
Version: 1.3.0
Fix Version: 1.3-current (r9649)


Fixed in Subversion repository.


Link: http://www.fltk.org/str.php?L2864
Version: 1.3.0
Fix Version: 1.3-current (r9649)

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

Re: [fltk.bugs] [MOD] STR #2864: FLTK 1.3.0 does not compile under Mac OSX Mountain Lion

2012-08-05 Thread Manolo Gouy


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

[STR Pending]

Link: http://www.fltk.org/str.php?L2864
Version: 1.3.0
Fix Version: 1.3-current (r9649)


@Matt: this solution doesn't work because MAC_OS_X_VERSION_10_8
isn't defined until ... 10.8
I'll take care of that.


Link: http://www.fltk.org/str.php?L2864
Version: 1.3.0
Fix Version: 1.3-current (r9649)

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

Re: [fltk.bugs] [MOD] STR #2864: FLTK 1.3.0 does not compile under Mac OSX Mountain Lion

2012-08-01 Thread Manolo Gouy


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

[STR Pending]

Link: http://www.fltk.org/str.php?L2864
Version: 1.3.0
Fix Version: 1.3-current (r9649)


If you replace your files src/filename_list.cxx and FL/mac.H by 
those attached here, you can test the fix.


Link: http://www.fltk.org/str.php?L2864
Version: 1.3.0
Fix Version: 1.3-current (r9649)

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

Re: [fltk.bugs] [MOD] STR #2864: FLTK 1.3.0 does not compile under Mac OSX Mountain Lion

2012-08-01 Thread Manolo Gouy

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

[STR Pending]

Link: http://www.fltk.org/str.php?L2864
Version: 1.3.0
Fix Version: 1.3-current (r9649)


Attached file "mac.H"...


Link: http://www.fltk.org/str.php?L2864
Version: 1.3.0
Fix Version: 1.3-current (r9649)//
// "$Id: mac.H 9649 2012-08-01 08:43:20Z manolo $"
//
// Mac header file for the Fast Light Tool Kit (FLTK).
//
// Copyright 1998-2011 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
//

// Do not directly include this file, instead use .  It will
// include this file if "__APPLE__" is defined.  This is to encourage
// portability of even the system-specific code...
#ifndef FL_DOXYGEN

#if !defined(Fl_X_H)
#  error "Never use  directly; include  instead."
#endif // !Fl_X_H

#ifdef __OBJC__
@class FLWindow; // a subclass of the NSWindow Cocoa class
typedef FLWindow *Window;
#else
typedef class FLWindow_opaque *Window; // pointer to the FLWindow objective-c 
class
#endif // __OBJC__

#if !(defined(FL_LIBRARY) || defined(FL_INTERNALS)) // this part is used when 
compiling an application program
#  include 

typedef struct flCocoaRegion* Fl_Region;
typedef struct CGContext* CGContextRef;
typedef struct OpaquePMPrintSettings*   PMPrintSettings;
typedef struct OpaquePMPageFormat*  PMPageFormat;
typedef struct OpaquePMPrintSession*PMPrintSession;
typedef struct CGImage* CGImageRef;
typedef CGContextRef Fl_Offscreen;

#else // this part must be compiled when building the FLTK libraries

// Standard MacOS C/C++ includes...
#include 
#undef check // because of Fl::check()

typedef CGContextRef Fl_Offscreen;

typedef struct flCocoaRegion {
  int count;
  CGRect *rects;
} *Fl_Region;  // a region is the union of a series of rectangles

#  include "Fl_Window.H"

// Some random X equivalents
struct XPoint { int x, y; };
struct XRectangle {int x, y, width, height;};
#ifndef CGFLOAT_DEFINED //appears with 10.5 in CGBase.h
#if defined(__LP64__) && __LP64__
typedef double CGFloat;
#else
typedef float CGFloat;
#endif
#endif // CGFLOAT_DEFINED

extern CGRect fl_cgrectmake_cocoa(int x, int y, int w, int h);
inline Fl_Region XRectangleRegion(int x, int y, int w, int h) {
  Fl_Region R = (Fl_Region)malloc(sizeof(*R));
  R->count = 1;
  R->rects = (CGRect *)malloc(sizeof(CGRect));
  *(R->rects) = fl_cgrectmake_cocoa(x, y, w, h);
  return R;
}
inline void XDestroyRegion(Fl_Region r) {
  if(r) {
free(r->rects);
free(r);
  }
}
extern void *fl_system_menu;
extern void *fl_default_cursor;

// This object contains all mac-specific stuff about a window:
// WARNING: this object is highly subject to change!
class Fl_X {
  
public:
  Window xid;  // pointer to the Cocoa window object (FLWindow*)
  Fl_Offscreen other_xid;  // pointer for offscreen bitmaps (overlay window)
  Fl_Window *w;// FLTK window for 
  Fl_Region region;
  Fl_Region subRegion; // region for this specific subwindow
  Fl_X *next;  // linked tree to support subwindows
  Fl_X *xidChildren, *xidNext; // more subwindow tree
  int wait_for_expose;
  void *cursor;// is really NSCursor*
  static Fl_X* first;
  static Fl_X* i(const Fl_Window* w) {return w->i;}
  static int fake_X_wm(const Fl_Window*,int&,int&,int&,int&,int&);
  static void make(Fl_Window*);
  void flush();
  // Quartz additions:
  CGContextRef gc; // graphics context (NULL when using QD)
  static void q_fill_context();// fill a Quartz context with current FLTK 
state
  static void q_clear_clipping();  // remove all clipping from a Quartz context
  static void q_release_context(Fl_X *x=0); // free all resources associated 
with fl_gc
  static void q_begin_image(CGRect&, int x, int y, int w, int h);
  static void q_end_image();
  // Cocoa additions
  void destroy(void);
  void map(void);
  void unmap(void);
  int unlink(Fl_X* start = NULL);
  void collapse(void);
  WindowRef window_ref(void);
  void set_key_window(void);
  void set_cursor(Fl_Cursor);
  static CGImageRef CGImage_from_window_rect(Fl_Window *win, int x, int y, int 
w, int h);
  static unsigned char *bitmap_from_window_rect(Fl_Window *win, int x, int y, 
int w, int h, int *bytesPerPixel);
  static Fl_Region intersect_region_and_rect(Fl_Region current, int x,int y,int 
w, int h);
  static CGContextRef watch_cursor_image(void);
  static CGContextRef help_cursor_image(void);
  static CGContextRef nesw_cursor_image(void);
  static CGContextRef nwse_cursor_image(void);
  static CGContextRef none_cursor_image(void);
  static void *get_carbon_function(const char *name);
  static void screen_work_area(int &X, int &Y, int &W, int &H, int n); // 
com

Re: [fltk.bugs] [MOD] STR #2864: FLTK 1.3.0 does not compile under Mac OSX Mountain Lion

2012-08-01 Thread Manolo Gouy

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

[STR Pending]

Link: http://www.fltk.org/str.php?L2864
Version: 1.3.0
Fix Version: 1.3-current (r9649)


Attached file "filename_list.cxx"...


Link: http://www.fltk.org/str.php?L2864
Version: 1.3.0
Fix Version: 1.3-current (r9649)//
// "$Id: filename_list.cxx 9649 2012-08-01 08:43:20Z manolo $"
//
// Filename list routines 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
//

// Wrapper for scandir with const-correct function prototypes.

#include 
#include 
#include "flstring.h"
#include 
#ifdef __APPLE__
#include 
#endif

extern "C" {
#ifndef HAVE_SCANDIR
  int fl_scandir (const char *dir, dirent ***namelist,
  int (*select)(dirent *),
  int (*compar)(dirent **, dirent **));
#endif
}

int fl_alphasort(struct dirent **a, struct dirent **b) {
  return strcmp((*a)->d_name, (*b)->d_name);
}

int fl_casealphasort(struct dirent **a, struct dirent **b) {
  return strcasecmp((*a)->d_name, (*b)->d_name);
}


/**
   Portable and const-correct wrapper for the scandir() function. 
   For each file in that directory a "dirent" structure is created. 
   The only portable thing about a dirent is that dirent.d_name is the 
nul-terminated file name. 
   An pointers array to these dirent's is created and a pointer to the array is 
returned in *list.
   The number of entries is given as a return value. 
   If there is an error reading the directory a number less than zero is 
returned, 
   and errno has the reason; errno does not work under WIN32. 

   \b Include:
   \code
   #include 
   \endcode

   \param[in] d the name of the directory to list.  It does not matter if it 
has a trailing slash.
   \param[out] list table containing the resulting directory listing
   \param[in] sort sorting functor:
- fl_alphasort: The files are sorted in ascending alphabetical order; 
upper and lowercase letters are compared according to their ASCII 
ordering  uppercase before lowercase.
- fl_casealphasort: The files are sorted in ascending alphabetical order; 
upper and lowercase letters are compared equally case is not 
significant.
- fl_casenumericsort: The files are sorted in ascending "alphanumeric" 
order, where an attempt is made 
to put unpadded numbers in consecutive order; upper and lowercase 
letters 
are compared equally case is not significant.
- fl_numericsort: The files are sorted in ascending "alphanumeric" order, 
where an attempt is made 
to put unpadded numbers in consecutive order; upper and lowercase 
letters are compared 
according to their ASCII ordering - uppercase before lowercase. 
   \return the number of entries if no error, a negative value otherwise.
*/
int fl_filename_list(const char *d, dirent ***list,
 Fl_File_Sort_F *sort) {
#if defined(WIN32) && !defined(__CYGWIN__) && !defined(HAVE_SCANDIR)
  // For Windows we have a special scandir implementation that uses
  // the Win32 "wide" functions for lookup, avoiding the code page mess
  // entirely. It also fixes up the trailing '/'.
  return fl_scandir(d, list, 0, sort);

#else // WIN32

  int dirlen;
  char *dirloc;

  // Assume that locale encoding is no less dense than UTF-8
  dirlen = strlen(d);
#ifdef __APPLE__
  dirloc = (char *)d;
#else
  dirloc = (char *)malloc(dirlen + 1);
  fl_utf8to_mb(d, dirlen, dirloc, dirlen + 1);
#endif

#ifndef HAVE_SCANDIR
  // This version is when we define our own scandir
  int n = fl_scandir(dirloc, list, 0, sort);
#elif defined(HAVE_SCANDIR_POSIX)
  // POSIX (2008) defines the comparison function like this:
  int n = scandir(dirloc, list, 0, (int(*)(const dirent **, const dirent 
**))sort);
#elif defined(__osf__)
  // OSF, DU 4.0x
  int n = scandir(dirloc, list, 0, (int(*)(dirent **, dirent **))sort);
#elif defined(_AIX)
  // AIX is almost standard...
  int n = scandir(dirloc, list, 0, (int(*)(void*, void*))sort);
#elif defined(__sgi)
  int n = scandir(dirloc, list, 0, sort);
#else
  // The vast majority of UNIX systems want the sort function to have this
  // prototype, most likely so that it can be passed to qsort without any
  // changes:
  int n = scandir(dirloc, list, 0, (int(*)(const void*,const void*))sort);
#endif

#ifndef __APPLE__
  free(dirloc);
#endif

  // convert every filename to utf-8, and append a '/' to all
  // filenames that are directories
  int i;
  char *fullname = (char*)malloc(dirlen+FL_PATH_MAX+3); // Add enough extra for 
two /'s and a nul
  // Use memcpy for speed since we already know the length of the string...

Re: [fltk.bugs] fltk-1.3.0 not building under MacOS 10.8 "Mountain Lion"

2012-08-01 Thread Manolo Gouy

Can someone, please, confirm that r.9649 compiles well
with MacOS 10.8 ?

> Because of a change in the dirent.h header file in 10.8, the source
> file filename_list.cxx no longer compiles correctly.
>
> A patch to repair this is:
>
> diff --git a/src/filename_list.cxx b/src/filename_list.cxx
> index 6434d67..6bc126b 100644
> --- a/src/filename_list.cxx
> +++ b/src/filename_list.cxx
> @@ -104,7 +104,7 @@ int fl_filename_list(const char *d, dirent ***list,
>  #ifndef HAVE_SCANDIR
>// This version is when we define our own scandir
>int n = fl_scandir(dirloc, list, 0, sort);
> -#elif defined(HAVE_SCANDIR_POSIX) && !defined(__APPLE__)
> +#elif defined(HAVE_SCANDIR_POSIX) || defined(__APPLE__)
>// POSIX (2008) defines the comparison function like this:
>int n = scandir(dirloc, list, 0, (int(*)(const dirent **, const dirent 
> **))sort);
>  #elif defined(__osf__)
>

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

Re: [fltk.bugs] [MOD] STR #2864: FLTK 1.3.0 does not compile under Mac OSX Mountain Lion

2012-08-01 Thread Manolo Gouy


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

[STR Pending]

Link: http://www.fltk.org/str.php?L2864
Version: 1.3.0
Fix Version: 1.3-current (r9649)


Should be fixed with r.9649.
Need confirmation from someone with 10.8 "mountain lion".


Link: http://www.fltk.org/str.php?L2864
Version: 1.3.0
Fix Version: 1.3-current (r9649)

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

Re: [fltk.bugs] [MOD] STR #2858: Need a fix to build 1.3 on cygwin with no x11

2012-06-27 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2858
Version: 1.3-current


This patch seems to make much sense, but what happens on cygwin + X11?
Could the OP, please, report whether the patch is correct 
in this case?


Link: http://www.fltk.org/str.php?L2858
Version: 1.3-current

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

Re: [fltk.bugs] [MOD] STR #2848: DataReadyThread leak OSX (bug in our Cocoa threading code)

2012-06-27 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2848
Version: 1.3-current
Fix Version: 1.3-current (r9588)


Closed now.


Link: http://www.fltk.org/str.php?L2848
Version: 1.3-current
Fix Version: 1.3-current (r9588)

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

Re: [fltk.bugs] [LOW] STR #2855: Fl::w() and other workarea functions not correctly updated upon changes

2012-06-14 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2855
Version: 1.3-current
Fix Version: 1.3-current (r9600)


Fixed in Subversion repository.

Many thanks for the excellent patch.


Link: http://www.fltk.org/str.php?L2855
Version: 1.3-current
Fix Version: 1.3-current (r9600)

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

Re: [fltk.bugs] [MOD] STR #2848: DataReadyThread leak OSX (bug in our Cocoa threading code)

2012-06-12 Thread Manolo Gouy


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

[STR Pending]

Link: http://www.fltk.org/str.php?L2848
Version: 1.3-current
Fix Version: 1.3-current (r9588)


The proposed patch has been committed in r.9588
Waiting a few more days for a reply from the OP.


Link: http://www.fltk.org/str.php?L2848
Version: 1.3-current
Fix Version: 1.3-current (r9588)

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

Re: [fltk.bugs] [MOD] STR #2850: Fl_RGB_Image::color_average loops indefinetley

2012-06-10 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2850
Version: 3.0


I believe r.9586 fixes this recursion error.


Link: http://www.fltk.org/str.php?L2850
Version: 3.0

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

Re: [fltk.bugs] [MOD] STR #2849: X11 drag-n-drop of non-ascii pathname to FLTK widget fails

2012-06-10 Thread Manolo Gouy


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

[STR Pending]

Link: http://www.fltk.org/str.php?L2849
Version: 1.3-current
Fix Version: 1.3-current (r9584)


I propose to close this STR as of r.9584 with more documentation
about filename dropping under X11 and the new support function 
fl_decode_uri(char *uri).


Link: http://www.fltk.org/str.php?L2849
Version: 1.3-current
Fix Version: 1.3-current (r9584)

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

Re: [fltk.bugs] [MOD] STR #2849: X11 drag-n-drop of non-ascii pathname to FLTK widget fails

2012-06-10 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2849
Version: 1.3-current


After Albrecht and Greg's input, I believe it would be inadequate
to just decode strings beginning with "file://" both because
other prefixes can occur (e.g., "computer://) and because
strings beginnings with "file://" could conceivably occur
when dragging text. The true solution would require the FLTK code
to "know" when dropped data is text or is a filename.
I propose to close this STR by adding a support function that FLTK
users can employ in the handle() function of drag-n-drop receiving
widgets to decode URI's when the dropped data is a filename.
That's function
   void fl_decode_uri(char *uri);
declared in FL/filename.H and to explain this issue in the 
Doxygen doc about drag-n-drop.


Link: http://www.fltk.org/str.php?L2849
Version: 1.3-current

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

Re: [fltk.bugs] [MOD] STR #2849: X11 drag-n-drop of non-ascii pathname to FLTK widget fails

2012-06-06 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2849
Version: 1.3-current


After some more reading, I see now that the Xdnd protocol 
wants dragged filenames to be expressed with the text/uri-list [1]
data type. This in turn makes filenames URL-encoded, that is,
all bytes not allowed in URLs are replaced by %XY in base 16.

Since this encoding is imposed by the Xdnd protocol, I conclude
that FLTK can expect to get it on all X11 platforms.

The question thus becomes:

should FLTK follow the Xdnd rule on the X11 platform
   or
should FLTK hide platform differences and deliver a UTF-8
   string on all platforms ?

I would much prefer to hide platform differences,
although differences would still exist (e.g., 
presence of the "file://" prefix only under X11).

Opinions ?

@Albrecht: I agree with your improvement suggestions,
and, yes, this moves the last NULL byte.


[1] http://www.newplanetsoftware.com/xdnd/dragging_files.html


Link: http://www.fltk.org/str.php?L2849
Version: 1.3-current

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

[fltk.bugs] [MOD] STR #2849: X11 drag-n-drop of non-ascii pathname to FLTK widget fails

2012-06-05 Thread Manolo Gouy

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

[STR New]

Link: http://www.fltk.org/str.php?L2849
Version: 1.3-current


Under Linux Debian, drag and drop of a filename to an FLTK widget 
fails if the pathname contains non-ascii characters
because the filename does not arrive as a correct UTF-8 string.

Notice that drag and drop of non-ascii text, as opposed to pathnames,
works well under Linux Debian.

To reproduce:
- create on your desktop an empty file named "tÃ©lÃ©phone"
- run the editor demo program
- drag the "tÃ©lÃ©phone" file from your desktop to the editor window
you see
   file:///home//Desktop/t%C3%A9l%C3%A9phone
in the editor window
instead of the expected
   file:///home//Desktop/tÃ©lÃ©phone

It happens that the pathname arrives UTF-8 encoded, but with 
non-ascii bytes replaced by the 3 ascii bytes %XY where XY are the 
hex byte value.

The attached dnd.diff patch fixes this for Linux/Debian by 
replacing, only when the dnd data begins with "file://", all %XX
instances by the corresponding single byte value.

Is this fix acceptable, or do other Linux/Unix systems, or X servers,
or file managers behave differently with dropping non-ascii pathnames?
If have no access to other X11 systems for tests.


Link: http://www.fltk.org/str.php?L2849
Version: 1.3-currentIndex: src/Fl_x.cxx
===
--- src/Fl_x.cxx(revision 9572)
+++ src/Fl_x.cxx(working copy)
@@ -1045,6 +1045,21 @@
 }
 Fl::e_text = buffer ? (char*)buffer : (char *)"";
 Fl::e_length = bytesread;
+if (strncmp(Fl::e_text, "file://", 7) == 0) {
+  char *q = Fl::e_text;
+  char *last = q + bytesread;
+  while (q <= last) {
+   if (*q == '%') {
+ int h;
+ // non-ascii chars (and '%') are encoded by %## using their 
hexadecimal value
+ sscanf(q+1, "%2X", &h);
+ *q = h;
+ memmove(q+1, q+3, last - (q+2));
+ last -= 2; Fl::e_length -= 2;
+   }
+   q++;
+  }
+}
 int old_event = Fl::e_number;
 fl_selection_requestor->handle(Fl::e_number = FL_PASTE);
 Fl::e_number = old_event;
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs

Re: [fltk.bugs] [MOD] STR #2848: DataReadyThread leak OSX (bug in our Cocoa threading code)

2012-06-02 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2848
Version: 1.3-current


Many thanks, Greg, for this detailed investigation.

Could the OP apply the attached cocoa.diff patch file
and write here whether it closes the leak. I would believe it does.


Link: http://www.fltk.org/str.php?L2848
Version: 1.3-current

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

Re: [fltk.bugs] [MOD] STR #2848: DataReadyThread leak OSX (bug in our Cocoa threading code)

2012-06-02 Thread Manolo Gouy

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

[STR New]

Link: http://www.fltk.org/str.php?L2848
Version: 1.3-current


Attached file "cocoa.diff"...


Link: http://www.fltk.org/str.php?L2848
Version: 1.3-currentIndex: src/Fl_cocoa.mm
===
--- src/Fl_cocoa.mm (revision 9420)
+++ src/Fl_cocoa.mm (working copy)
@@ -326,8 +326,6 @@
 void* DataReady::DataReadyThread(void *o)
 {
   DataReady *self = (DataReady*)o;
-  NSAutoreleasePool *localPool;
-  localPool = [[NSAutoreleasePool alloc] init]; 
   while ( 1 ) {// loop until thread 
cancel or error
 // Thread safe local copies of data before each select()
 self->DataLock();
@@ -358,12 +356,15 @@
  { return(NULL); } // just 
exit
 DEBUGMSG("CHILD THREAD: DATA IS READY\n");
 NSPoint pt={0,0};
+   NSAutoreleasePool *localPool;
+   localPool = [[NSAutoreleasePool alloc] init]; 
 NSEvent *event = [NSEvent otherEventWithType:NSApplicationDefined 
location:pt 
   modifierFlags:0
timestamp:0
 windowNumber:0 context:NULL 
 subtype:FLTKDataReadyEvent data1:0 
data2:0];
 [NSApp postEvent:event atStart:NO];
+   [localPool release];
 return(NULL);  // done with thread
   }
 }
@@ -1280,6 +1281,8 @@
 
selector:@selector(anyWindowWillClose:) 
 
name:NSWindowWillCloseNotification 
   object:nil];
+[NSThread detachNewThreadSelector:nil toTarget:nil withObject:nil];
+//NSLog(@"end of fl_open_display isMultiThreaded=%d",[NSThread 
isMultiThreaded]);
   }
 }
 
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs

Re: [fltk.bugs] [MOD] STR #2846: svn fltk will not compile under cmake - release tarball ok

2012-05-29 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2846
Version: 1.3-current
Fix Version: 1.3-current (r9556)


Fixed in Subversion repository.


Link: http://www.fltk.org/str.php?L2846
Version: 1.3-current
Fix Version: 1.3-current (r9556)

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

Re: [fltk.bugs] [MOD] STR #2846: svn fltk will not compile under cmake - release tarball ok

2012-05-29 Thread Manolo Gouy


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

[STR Pending]

Link: http://www.fltk.org/str.php?L2846
Version: 1.3-current
Fix Version: 1.3-current (r9556)


Could you confirm, please, that with r9556 cmake compiles libpng OK?


Link: http://www.fltk.org/str.php?L2846
Version: 1.3-current
Fix Version: 1.3-current (r9556)

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

Re: [fltk.bugs] [MOD] STR #2831: redraw problem with Fl_Pixmap on X11

2012-05-01 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2831
Version: 1.3-current
Fix Version: 1.3-current (r9421)


Closing.


Link: http://www.fltk.org/str.php?L2831
Version: 1.3-current
Fix Version: 1.3-current (r9421)

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

Re: [fltk.bugs] [MOD] STR #2831: redraw problem with Fl_Pixmap on X11

2012-05-01 Thread Manolo Gouy


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

[STR Pending]

Link: http://www.fltk.org/str.php?L2831
Version: 1.3-current
Fix Version: 1.3-current (r9421)


Fixed in Subversion repository.

I believe this regression is now fixed in the repository.
Greg: do you agree?


Link: http://www.fltk.org/str.php?L2831
Version: 1.3-current
Fix Version: 1.3-current (r9421)

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

Re: [fltk.bugs] [HIGH] STR #2825: FLTK 1/3 compatibility for Fl_Graphics_Driver and Fl_Surface_Device

2012-04-16 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2825
Version: 3.0
Fix Version: 3.0 (r9353)


Fixed in Subversion repository.


Link: http://www.fltk.org/str.php?L2825
Version: 3.0
Fix Version: 3.0 (r9353)

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

Re: [fltk.bugs] [HIGH] STR #2825: FLTK 1/3 compatibility for Fl_Graphics_Driver and Fl_Surface_Device

2012-04-15 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2825
Version: 3.0


Attached file Fl_Device.H further corrects the patch for functions
such as fltk3::GraphicsDriver_I::draw(fltk3::RGBImage*,...).


Link: http://www.fltk.org/str.php?L2825
Version: 3.0

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

Re: [fltk.bugs] [HIGH] STR #2825: FLTK 1/3 compatibility for Fl_Graphics_Driver and Fl_Surface_Device

2012-04-15 Thread Manolo Gouy

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

[STR New]

Link: http://www.fltk.org/str.php?L2825
Version: 3.0


Attached file "Fl_Device.H"...


Link: http://www.fltk.org/str.php?L2825
Version: 3.0//
// "$Id: Fl_Device.H 9285 2012-03-14 16:14:53Z manolo $"
//
// Definition of classes Fl_Device, Fl_Graphics_Driver, Fl_Surface_Device, 
// Fl_Display_Device for the Fast Light Tool Kit (FLTK).
// FLTK 123 wrapper started
//
// Copyright 2010-2012 by Bill Spitzak and others.
//
// This library is free software; you can redistribute it and/or
// modify it under the terms of the GNU Library General Public
// License as published by the Free Software Foundation; either
// version 2 of the License, or (at your option) any later version.
//
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
// Library General Public License for more details.
//
// You should have received a copy of the GNU Library General Public
// License along with this library; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
// USA.
//
// Please report all bugs and problems on the following page:
//
// http://www.fltk.org/str.php
//

#ifndef Fl_Device_H
#define Fl_Device_H

#include 
#include 
#include 
#include 
#include 

typedef fltk3::Offscreen Fl_Offscreen;
typedef fltk3::DrawImageCb Fl_Draw_Image_Cb;
typedef fltk3::Region Fl_Region;

namespace fltk3 { 

class GraphicsDriverWrapper : public fltk3::Wrapper {
public:
  virtual ~GraphicsDriverWrapper() {}
  
  virtual int height() { 
return ((fltk3::GraphicsDriver*)_p)->height(); 
}

  virtual int descent() { 
return ((fltk3::GraphicsDriver*)_p)->descent(); 
  }
 
  virtual int clip_box(int x, int y, int w, int h, int &X, int &Y, int &W, int 
&H) { 
return ((fltk3::GraphicsDriver*)_p)->clip_box(x,y,w,h,X,Y,W,H); 
  }
  
  virtual int not_clipped(int x, int y, int w, int h) { 
return ((fltk3::GraphicsDriver*)_p)->not_clipped(x,y,w,h); 
  }
  
  virtual double width(const char* str, int l) { 
return ((fltk3::GraphicsDriver*)_p)->width(str, l); 
  }

  virtual double width(unsigned c) { 
return ((fltk3::GraphicsDriver*)_p)->width(c); 
  }
  
#define FLTK3_DRIVER_WRAPPER(proto, call) \
virtual void proto { \
  ((fltk3::GraphicsDriver*)_p)->call; \
  }
FLTK3_DRIVER_WRAPPER(font(Fl_Font f, Fl_Fontsize s), font(_1to3_font(f), 
_1to3_fontsize(s)))
FLTK3_DRIVER_WRAPPER(draw(const char* str, int l, int x, int y), draw(str, l, 
x, y))
FLTK3_DRIVER_WRAPPER(draw(const char* str, int l, float fx, float fy), 
draw(str, l, fx, fy))
FLTK3_DRIVER_WRAPPER(draw(int angle, const char* str, int l, int x, int y), 
draw(angle, str, l, x, y))
FLTK3_DRIVER_WRAPPER(line(int x, int y, int x1, int y1), line(x, y, x1, y1))
FLTK3_DRIVER_WRAPPER(rect(int x, int y, int w, int h), rect(x, y, w, h))
FLTK3_DRIVER_WRAPPER(rectf(int x, int y, int w, int h), rectf(x, y, w, h))
FLTK3_DRIVER_WRAPPER(color(uchar r, uchar g, uchar b), color(r, g, b))
FLTK3_DRIVER_WRAPPER(color(Fl_Color c), color(_1to3_color(c)))
FLTK3_DRIVER_WRAPPER(line_style(int style, int width, char *dashes), 
line_style(style, width, dashes))
FLTK3_DRIVER_WRAPPER(push_clip(int x, int y, int w, int h) , push_clip(x, y, w, 
h))
FLTK3_DRIVER_WRAPPER(pop_clip(), pop_clip())
FLTK3_DRIVER_WRAPPER(draw(Fl_Pixmap *pxm, int XP, int YP, int WP, int HP, int 
cx, int cy) ,
draw((fltk3::Pixmap*)pxm->_p, XP,YP,WP,HP,cx,cy) )
FLTK3_DRIVER_WRAPPER(draw_image(Fl_Draw_Image_Cb cb, void *data, int X, int Y, 
int W, int H, int D) ,
draw_image( (fltk3::DrawImageCb)cb, data, X,Y,W,H,D) )
FLTK3_DRIVER_WRAPPER(line(int x, int y, int x1, int y1, int x2, int y2), 
line(x, y, x1, y1, x2, y2))
FLTK3_DRIVER_WRAPPER(xyline(int x, int y, int x1), xyline(x, y, x1))
FLTK3_DRIVER_WRAPPER(xyline(int x, int y, int x1, int y2), xyline(x, y, x1, y2))
FLTK3_DRIVER_WRAPPER(xyline(int x, int y, int x1, int y2, int x3), xyline(x, y, 
x1, y2, x3))
FLTK3_DRIVER_WRAPPER(yxline(int x, int y, int y1), yxline(x, y, y1))
FLTK3_DRIVER_WRAPPER(yxline(int x, int y, int y1, int x2), yxline(x, y, y1, x2))
FLTK3_DRIVER_WRAPPER(yxline(int x, int y, int y1, int x2, int y3), yxline(x, y, 
y1, x2, y3))
FLTK3_DRIVER_WRAPPER(rtl_draw(const char* str, int l, int x, int y), 
rtl_draw(str, l, x, y))
FLTK3_DRIVER_WRAPPER(draw(Fl_RGB_Image* rgb,int XP, int YP, int WP, int HP, int 
cx, int cy) ,
 draw( (fltk3::RGBImage*)rgb->_p, XP, YP, WP, HP, cx, cy) )
FLTK3_DRIVER_WRAPPER( draw(Fl_Bitmap* bm, int XP, int YP, int WP, int HP, int 
cx, int cy) ,
 draw( (fltk3::Bitmap*)bm->_p, XP, YP, WP, HP, cx, cy) )
FLTK3_DRIVER_WRAPPER(draw_image(const uchar* cb, int X, int Y, int W, int H, 
int D, int L), draw_image(cb, X, Y, W, H, D, L))
FLTK3_DRIVER_WRAPPER(draw_image_mono(const uchar* cb, int X, int Y, int W, int 
H,

Re: [fltk.bugs] [HIGH] STR #2801: When a widget (buttons with or without a image in this case) is deactivated and then activated again, the widget does not draw the contents as active .

2012-04-14 Thread Manolo Gouy


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

[STR Pending]

Link: http://www.fltk.org/str.php?L2801
Version: 3.0
Fix Version: 3.0 (r9317)


Fixed in Subversion repository.

Can the OP, please, confirm this bug is now fixed?


Link: http://www.fltk.org/str.php?L2801
Version: 3.0
Fix Version: 3.0 (r9317)

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

Re: [fltk.bugs] [MOD] STR #2819: MinGW: #include breaks fltk compilation

2012-04-09 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2819
Version: 1.3-current


Albrecht:
Here is the output I obtained running WinXP in VirtualBox on Mac OS

$ uname -a && gcc --version && gcc -o mingw mingw.cxx && ./mingw
MINGW32_NT-5.1 XPVIRTUALBOX 1.0.11(0.46/3/2) 2004-04-30 18:55 i686 unknown
gcc.exe (GCC) 3.4.2 (mingw-special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

__W32API_VERSION  =  3.60
__MINGW32_VERSION =  3.90


Link: http://www.fltk.org/str.php?L2819
Version: 1.3-current

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

Re: [fltk.bugs] [MOD] STR #2819: MinGW: #include breaks fltk compilation

2012-04-09 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2819
Version: 1.3-current


Hi Albrecht,

I confirm that with MinGW 5.0.2, config.h defines HAVE_DIRENT_H to 1
and I get the same compilation error "previous definition of 
struct dirent" as you had. I also confirm that this error disappears
after applying the patch you mention.


Link: http://www.fltk.org/str.php?L2819
Version: 1.3-current

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

Re: [fltk.bugs] [MOD] STR #2818: OSX: tooltip appearance takes focus from input widgets

2012-04-04 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2818
Version: 1.3-current
Fix Version: 1.3-current (r9321)


Fixed in Subversion repository.

Yes, this was an unwanted side effect of r9294 to allow 
borderless windows to have focus.


Link: http://www.fltk.org/str.php?L2818
Version: 1.3-current
Fix Version: 1.3-current (r9321)

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

Re: [fltk.bugs] [LOW] STR #2814: Status of fltk-1.3 compatability (as at r9297)

2012-04-02 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2814
Version: 3.0


All fluid-associated errors disappear if the fluid
program from the fluid1 directory (that is, FLTK 1.3 fluid compiled
using 1.3 compatibility) is used to compile keyboard, mandelbrot,
CubeView. Shouldn't this fluid version be used to test 1.3 
compatibility? Does it make sense to use the 3.0 fluid for this purpose?


Link: http://www.fltk.org/str.php?L2814
Version: 3.0

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

Re: [fltk.bugs] [LOW] STR #2814: Status of fltk-1.3 compatability (as at r9297)

2012-04-01 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2814
Version: 3.0


I believe r.9314 should allow some more demos to compile & run.


Link: http://www.fltk.org/str.php?L2814
Version: 3.0

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

Re: [fltk.bugs] [LOW] STR #2814: Status of fltk-1.3 compatability (as at r9297)

2012-03-28 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2814
Version: 3.0


I believe r.9310 will fix the problems with class Fl_Bitmap.


Link: http://www.fltk.org/str.php?L2814
Version: 3.0

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

Re: [fltk.bugs] [MOD] STR #2811: Inifinite loop in Fl_Menu_Item::next - with fix

2012-03-22 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2811
Version: 1.3.0
Fix Version: 1.3-current (r8866)


Same as already fixed STR#2680


Link: http://www.fltk.org/str.php?L2811
Version: 1.3.0
Fix Version: 1.3-current (r8866)

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

Re: [fltk.bugs] [HIGH] STR #2812: Borderless window gets no keyboard focus on Mac OS X

2012-03-22 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2812
Version: 1.3.0
Fix Version: 1.3-current (r9294)


Fixed in Subversion repository.

Thanks for the patch.


Link: http://www.fltk.org/str.php?L2812
Version: 1.3.0
Fix Version: 1.3-current (r9294)

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

Re: [fltk.bugs] [MOD] STR #2811: Inifinite loop in Fl_Menu_Item::next - with fix

2012-03-18 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2811
Version: 1.3.0


Could you, please try with the latest svn FLTK 1.3.x version.
I believe this bug has already been found (STR#2680) and fixed (r.8866).


Link: http://www.fltk.org/str.php?L2811
Version: 1.3.0

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

Re: [fltk.bugs] [LOW] STR #2810: Remove all uses of Fl_Device::class_name()

2012-03-18 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2810
Version: 1.3.0
Fix Version: 1.3-current (r9293)


Fixed in Subversion repository.

Uses of the function Fl_Device::class_name() are removed by the creation
of a new function
void Fl_Graphics_Driver::copy_offscreen()
that is declared virtual only if FLTK_ABI_VERSION >= 10302.
For lower values of FLTK_ABI_VERSION, a few Fl_Device::class_name()
calls remain in function fl_copy_offscreen().


Link: http://www.fltk.org/str.php?L2810
Version: 1.3.0
Fix Version: 1.3-current (r9293)

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

[fltk.bugs] [LOW] STR #2810: Remove all uses of Fl_Device::class_name()

2012-03-16 Thread Manolo Gouy

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

[STR New]

Link: http://www.fltk.org/str.php?L2810
Version: 1.3.0


There was a comment in the development forum that uses of the
Fl_Device::class_name() functions express incomplete use of 
virtual functions. That's true. I would like to improve this and
remove all calls to function Fl_Device::class_name() in FLTK 1.3.
The attached svn diff file does that by using two new functions
static int Fl_Surface_Device::to_display() and
static int Fl_Surface_Device::uses_display_driver().

This requires change to several files. I believe that ABI compatibity
is maintained. It seems this source 
http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++
provides a comprehensive description of how to ensure ABI 
compatibility of a C++ library. I would prefer to have the opinion
of other developpers before committing this large change.


Link: http://www.fltk.org/str.php?L2810
Version: 1.3.0Index: src/Fl_Device.cxx
===
--- src/Fl_Device.cxx   (revision 9274)
+++ src/Fl_Device.cxx   (working copy)
@@ -40,8 +40,31 @@
 {
   fl_graphics_driver = _driver;
   _surface = this;
+  same_driver_as_display = 0;
 }
 
+/** returns whether the surface that currently receives graphics output is the 
platform display */
+int Fl_Surface_Device::to_display() {
+  return surface() == Fl_Display_Device::display_device();
+}
+
+/** returns whether the surface that currently receives graphics output uses 
+the same graphics driver as the platform display */
+int Fl_Surface_Device::uses_display_driver() {
+  return same_driver_as_display;
+}
+
+int Fl_Surface_Device::same_driver_as_display = 0;
+
+void Fl_Display_Device::set_current()
+{
+  this->Fl_Surface_Device::set_current();
+  Fl_Surface_Device::same_driver_as_display = 1;
+}
+
+FL_EXPORT Fl_Graphics_Driver *fl_graphics_driver; // the current target device 
of graphics operations
+Fl_Surface_Device* Fl_Surface_Device::_surface; // the current target surface 
of graphics operations
+
 const Fl_Graphics_Driver::matrix Fl_Graphics_Driver::m0 = {1, 0, 0, 1, 0, 0};
 
 Fl_Graphics_Driver::Fl_Graphics_Driver() {
@@ -88,6 +111,7 @@
 #endif
   fl_mac_os_version = versionMajor * 1 + versionMinor * 100 + 
versionBugFix;
 #endif
+this->set_current();
 };
 
 
Index: src/fl_draw_image_mac.cxx
===
--- src/fl_draw_image_mac.cxx   (revision 9132)
+++ src/fl_draw_image_mac.cxx   (working copy)
@@ -55,7 +55,7 @@
 
   const void *array = buf;
   uchar *tmpBuf = 0;
-  if (cb || Fl_Surface_Device::surface()->class_name() == 
Fl_Printer::class_id) {
+  if (cb || !Fl_Surface_Device::to_display()) {
 tmpBuf = new uchar[ H*W*delta ];
 if (cb) {
   for (int i=0; i>8)&3];
   // when printing kCGLineCapSquare seems better for solid lines
-  if ( Fl_Surface_Device::surface()->class_name() == Fl_Printer::class_id && 
style == FL_SOLID && dashes == NULL ) {
+  if ( !Fl_Surface_Device::to_display() && style == FL_SOLID && dashes == NULL 
) {
 fl_quartz_line_cap_ = kCGLineCapSquare;
 }
   fl_quartz_line_join_ = Join[(style>>12)&3];
Index: src/Fl_Bitmap.cxx
===
--- src/Fl_Bitmap.cxx   (revision 9284)
+++ src/Fl_Bitmap.cxx   (working copy)
@@ -295,7 +295,7 @@
   HDC tempdc;
   int save;
   BOOL use_print_algo = false;
-  if (Fl_Surface_Device::surface()->class_name() == Fl_Printer::class_id) {
+  if (!Fl_Surface_Device::to_display()) {
 static HMODULE hMod = NULL;
 if (!hMod) {
   hMod = LoadLibrary("MSIMG32.DLL");
Index: src/Fl_Printer.cxx
===
--- src/Fl_Printer.cxx  (revision 9132)
+++ src/Fl_Printer.cxx  (working copy)
@@ -84,6 +84,7 @@
   fl_gc = (HDC)gc;
 #endif
   this->Fl_Surface_Device::set_current();
+  Fl_Surface_Device::same_driver_as_display = 1;
 }
 
 void Fl_System_Printer::origin(int *x, int *y)
Index: src/Fl_Text_Display.cxx
===
--- src/Fl_Text_Display.cxx (revision 9140)
+++ src/Fl_Text_Display.cxx (working copy)
@@ -3369,7 +3369,7 @@
   // draw the non-text, non-scrollbar areas.
   if (damage() & FL_DAMAGE_ALL) {
 //printf("drawing all (box = %d)\n", box());
-if (Fl_Surface_Device::surface()->class_name() == Fl_Printer::class_id) {
+if (!Fl_Surface_Device::to_display()) {
   // if to printer, draw the background
   fl_rectf(text_area.x, text_area.y, text_area.w, text_area.h, color() );
 }
Index: src/Fl_Image.cxx
===
--- src/Fl_Image.cxx(revision 9283)
+++ src/Fl_Image.cxx(working copy)
@@ -532,7 +532,7 @@
   } else if (img->d()==2 || img->d()==4) {
 copy_offscreen_with_alpha(X, Y, W, H, (Fl_Offscreen)img->id_, cx, cy);
   } else {
-fl_copy_of

Re: [fltk.bugs] [MOD] STR #2260: OpenGL windows in Fl_Tabs don't hide when tabs are switched (OS X only)

2012-03-05 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2260
Version: 1.3-current
Fix Version: 1.3-current (r9264)


Fixed in Subversion repository.


Link: http://www.fltk.org/str.php?L2260
Version: 1.3-current
Fix Version: 1.3-current (r9264)

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

Re: [fltk.bugs] [MOD] STR #2260: OpenGL windows in Fl_Tabs don't hide when tabs are switched (OS X only)

2012-03-04 Thread Manolo Gouy


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

[STR Pending]

Link: http://www.fltk.org/str.php?L2260
Version: 1.3-current
Fix Version: 1.3.0 (r7831)


Rob,
Could you, please, apply the small patch attached here under the name
STR2260.fix, and confirm whether it solves the openGL-in-Fl_Tabs issue?
Thanks.


Link: http://www.fltk.org/str.php?L2260
Version: 1.3-current
Fix Version: 1.3.0 (r7831)

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

Re: [fltk.bugs] [MOD] STR #2260: OpenGL windows in Fl_Tabs don't hide when tabs are switched (OS X only)

2012-03-04 Thread Manolo Gouy

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

[STR Pending]

Link: http://www.fltk.org/str.php?L2260
Version: 1.3-current
Fix Version: 1.3.0 (r7831)


Attached file "STR2260.fix"...


Link: http://www.fltk.org/str.php?L2260
Version: 1.3-current
Fix Version: 1.3.0 (r7831)

STR2260.fix
Description: Binary data
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs

Re: [fltk.bugs] [MOD] STR #2805: png_set_longjmp_fn not found in mac lion (xcode 4)

2012-02-09 Thread Manolo Gouy


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

[STR Active]

Link: http://www.fltk.org/str.php?L2805
Version: 1.3.0


This error occurs only with Apple's new LLVM 3.0 compiler.

You can fix that by modifying the "Build settings"
of the "fltk-images" target of the Xcode project:
go to the "Compiler for C/C++/Objective-C" item, and
change it from "Default compiler (Apple LLVM compiler 3.0)"
to "LLVM GCC 4.2",
and the project will compile without error.

Post here, please, what happens in your hands.


Link: http://www.fltk.org/str.php?L2805
Version: 1.3.0

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

Re: [fltk.bugs] [MOD] STR #2770: menubar menus have problems near screen edges

2011-12-05 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2770
Version: 1.3-current
Fix Version: 1.3-current (r9183)


Closed.


Link: http://www.fltk.org/str.php?L2770
Version: 1.3-current
Fix Version: 1.3-current (r9183)

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

Re: [fltk.bugs] [MOD] STR #2782: No FL_EXPORT definition for Fl_Native_File_Chooser

2011-12-02 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2782
Version: 1.3.0
Fix Version: 1.3-current (r9193)


Fixed in Subversion repository.


Link: http://www.fltk.org/str.php?L2782
Version: 1.3.0
Fix Version: 1.3-current (r9193)

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

Re: [fltk.bugs] [MOD] STR #2779: use of protected member causes Error with clang

2011-11-29 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2779
Version: 1.3.0
Fix Version: 1.3-current (r9192)


Fixed in Subversion repository.

Thanks for the patch


Link: http://www.fltk.org/str.php?L2779
Version: 1.3.0
Fix Version: 1.3-current (r9192)

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

Re: [fltk.bugs] [MOD] STR #2770: menubar menus have problems near screen edges

2011-11-22 Thread Manolo Gouy


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

[STR Pending]

Link: http://www.fltk.org/str.php?L2770
Version: 1.3-current
Fix Version: 1.3-current (r9183)


I believe this issue is solved with r9183.
Greg, do you agree ?


Link: http://www.fltk.org/str.php?L2770
Version: 1.3-current
Fix Version: 1.3-current (r9183)

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

Re: [fltk.bugs] [MOD] STR #2775: OS X window resizing doesn't respect system restrictions

2011-11-22 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2775
Version: 1.3-current
Fix Version: 1.3-current (r9181)





Link: http://www.fltk.org/str.php?L2775
Version: 1.3-current
Fix Version: 1.3-current (r9181)

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

Re: [fltk.bugs] [MOD] STR #2775: OS X window resizing doesn't respect system restrictions

2011-11-22 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2775
Version: 1.3-current
Fix Version: 1.3-current (r9181)


Fixed in Subversion repository.

Thanks for the patch, that was not enough to handle move operations.


Link: http://www.fltk.org/str.php?L2775
Version: 1.3-current
Fix Version: 1.3-current (r9181)

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

Re: [fltk.bugs] [MOD] STR #2770: menubar menus have problems near screen edges

2011-11-14 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2770
Version: 1.3-current


I would think that opening the 'huge' menu with its top edge at the
window's top would be bad because it would hide the menu title (huge).
I would also think that showing only the end of the menu above the menu
bar would be bad.
Thus, I like the way the 'huge' menu behaves.


Link: http://www.fltk.org/str.php?L2770
Version: 1.3-current

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

Re: [fltk.bugs] [MOD] STR #2770: menubar menus have problems near screen edges

2011-11-14 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2770
Version: 1.3-current


For the "International" menu issue:
I believe the solution would be to change line 357 of src/Fl_Menu.cxx
from
if (X < scr_x) X = scr_x; if (X > scr_x+scr_w-W) X = right_edge-W; //X=
scr_x+scr_w-W;

to

if (X < scr_x) X = scr_x; if (X > scr_x+scr_w-W) X = scr_x+scr_w-W;

Thus amounts to undo a change done by Matt at r.6490
and for which the commit text gives no clue.

@Matt: any opinion about why this change was done in the first place?


Link: http://www.fltk.org/str.php?L2770
Version: 1.3-current

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

Re: [fltk.bugs] [MOD] STR #2770: menubar menus have problems near screen edges

2011-11-14 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2770
Version: 1.3-current


I believe the behavior of the "Huge" menu is correct: this menu is
so big that it can't be displayed entirely upwards, 
so it opens downwards, as a usual menu does.


Link: http://www.fltk.org/str.php?L2770
Version: 1.3-current

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

Re: [fltk.bugs] [MOD] STR #2769: Crash during creation of non-modal window on secondary screen

2011-11-14 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2769
Version: 1.3-current
Fix Version: 1.3-current (r9177)


Fixed in Subversion repository.


Link: http://www.fltk.org/str.php?L2769
Version: 1.3-current
Fix Version: 1.3-current (r9177)

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

[fltk.bugs] [MOD] STR #2769: Crash during creation of non-modal window on secondary screen

2011-11-14 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2769
Version: 1.3-current


Run on Mac OS with 2 screens the editor test program.
Move the window to the secondary screen.
Type cmd-R
crash!


Link: http://www.fltk.org/str.php?L2769
Version: 1.3-current

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

Re: [fltk.bugs] [MOD] STR #2759: Fl_Window::hotspot() fails on multi-screen displays

2011-10-31 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2759
Version: 1.3-current
Fix Version: 1.3-current (r9163)


Fixed in Subversion repository.


Link: http://www.fltk.org/str.php?L2759
Version: 1.3-current
Fix Version: 1.3-current (r9163)

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

[fltk.bugs] [MOD] STR #2759: Fl_Window::hotspot() fails on multi-screen displays

2011-10-31 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2759
Version: 1.3-current


Fl_Window::hotspot() does not work well on multi-screen displays:
the window appears on the main screen when it's expected on a
secondary screen.

The bug is readily seen with the color_chooser test program.
Move the window to a secondary screen, click the "fl_chooser_color"
button, the fl_color_chooser will pop up on the main screen
instead of the secondary screen.


Link: http://www.fltk.org/str.php?L2759
Version: 1.3-current

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

Re: [fltk.bugs] [MOD] STR #2711: FL_NORMAL_SIZE and menus

2011-10-17 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2711
Version: 1.3-current


Reopened.
r.9070 introduced a regression where labels of correct menu buttons
are drawn at left of button without any margin, which is very ugly.


Link: http://www.fltk.org/str.php?L2711
Version: 1.3-current

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

Re: [fltk.bugs] [MOD] STR #2727: screen_work_area() doesn't compile under X

2011-10-04 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2727
Version: 3.0
Fix Version: 3.0 (r9121)


Fixed in Subversion repository.


Link: http://www.fltk.org/str.php?L2727
Version: 3.0
Fix Version: 3.0 (r9121)

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

Re: [fltk.bugs] [MOD] STR #2724: Fl_x.cxx does't compile if HAVE_XRANDR=0

2011-10-01 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2724
Version: 1.3-current
Fix Version: 1.3-current


Fixed in Subversion repository.


Link: http://www.fltk.org/str.php?L2724
Version: 1.3-current
Fix Version: 1.3-current

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

Re: [fltk.bugs] [MOD] STR #2695: huge menus do not scroll at screen edges any more - regression

2011-09-29 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2695
Version: 1.3-current
Fix Version: 1.3-current (r9084)


Fixed in Subversion repository.

Fixed together with STR#2697.


Link: http://www.fltk.org/str.php?L2695
Version: 1.3-current
Fix Version: 1.3-current (r9084)

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

Re: [fltk.bugs] [HIGH] STR #2697: Fl::x() y() w() h() behaviour not consistent across platforms in multi-head systems

2011-09-29 Thread Manolo Gouy


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2697
Version: 1.3-current
Fix Version: 1.3-current (r9084)


Fixed in Subversion repository.

Fix STR#2695 & 2697: correct computation of work areas with multiple
screens.

This introduces 3 new functions
static void Fl::screen_work_area(X,Y,W,H)
static void Fl::screen_work_area(X,Y,W,H,mx,my)
static void Fl::screen_work_area(X,Y,W,H,screen_no)
that compute screen work areas and are used by FLTK to position menu
windows.

The Fl::x(),y(),w(),h() functions are made consistent across platforms:
they return
the origin/size of the work area of the main screen (as far as possible,
see below).

On the Mac OS platform, all screen functions reflect changes in screen
number and
positions without requiring the application to restart.

On the X11 platform, I did not find an API to compute the main screen work
area
in all conditions. What's used does compute the correct work area when
there's
a single screen, but not when there are several, because it returns an
area that
encompasses all screens. The implemented workaround is that
Fl::x(),y(),w(),h()
and Fl::screen_work_area(X,Y,W,H,0) return the exact work area when
there's
a single screen, and return the full screen area when there are several.


Link: http://www.fltk.org/str.php?L2697
Version: 1.3-current
Fix Version: 1.3-current (r9084)

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

Re: [fltk.bugs] [HIGH] STR #2697: Fl::x() y() w() h() behaviour not consistent across platforms in multi-head systems

2011-09-29 Thread Manolo Gouy


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

[STR Pending]

Link: http://www.fltk.org/str.php?L2697
Version: 1.3-current


Assigning ownership.


Link: http://www.fltk.org/str.php?L2697
Version: 1.3-current

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

Re: [fltk.bugs] [HIGH] STR #2697: Fl::x() y() w() h() behaviour not consistent across platforms in multi-head systems

2011-09-27 Thread Manolo Gouy


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

[STR New]

Link: http://www.fltk.org/str.php?L2697
Version: 1.3-current


I propose the attached screens.patch to fix this STR 
as well as STR#2695.

It introduces 3 new API functions
static void Fl::work_area_xywh(X,Y,W,H);
static void Fl::work_area_xywh(X,Y,W,H,mx,my);
static void Fl::work_area_xywh(X,Y,W,H,n);
that compute the bounding box of the work area of a screen
(with cursor, at given point, of given rank).

Functions Fl::x(),y(),w(),and h() now return values
for the work area of the main screen, and are not used anymore by
menus.

On Mac OS, a callback is called at application start and whenever 
screens are changed, thus FLTK applications can be aware of
screen changes without restarting (see STR#2600).

On X11, I did not find an API to get the work area of a single 
screen, thus Fl::work_area_xywh() gives the same as Fl::screen_xywh().
The Fl::x()... functions do return a work area, but for a global
object that encompasses all screens. For these functions to be
consistent across OSes, it would require to change them on X11
and have them return the same as Fl::screen_xywh() for screen 0. 
I didn't do that yet.

I believe to have tested all that well with multiheaded systems
on Mac OS X, MSWindows and Linux/X11.

Could any other developer try it also?


Link: http://www.fltk.org/str.php?L2697
Version: 1.3-current

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

Re: [fltk.bugs] [HIGH] STR #2697: Fl::x() y() w() h() behaviour not consistent across platforms in multi-head systems

2011-09-27 Thread Manolo Gouy

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

[STR New]

Link: http://www.fltk.org/str.php?L2697
Version: 1.3-current


Attached file "screens.patch"...


Link: http://www.fltk.org/str.php?L2697
Version: 1.3-currentIndex: FL/mac.H
===
--- FL/mac.H(revision 9057)
+++ FL/mac.H(working copy)
@@ -125,6 +125,8 @@
   static CGContextRef nwse_cursor_image(void);
   static CGContextRef none_cursor_image(void);
   static void *get_carbon_function(const char *name);
+  static void screen_work_area(int n, XRectangle *area); // compute work area 
of a given screen
+  static void mac_screen_init(void); // recompute screen number and dimensions
 private:
   static void relink(Fl_Window*, Fl_Window*);
   bool subwindow;
Index: FL/Fl.H
===
--- FL/Fl.H (revision 9039)
+++ FL/Fl.H (working copy)
@@ -757,13 +757,13 @@
fl global screen functions declared in 
  @{ */
   // screen size:
-  /** Returns the origin of the current screen work area, where 0 indicates 
the left side of the screen. */
+  /** Returns the origin of the main screen work area, where 0 indicates the 
left side of the screen. */
   static int x(); // platform dependent
-  /** Returns the origin of the current screen work area, where 0 indicates 
the top edge of the screen. */
+  /** Returns the origin of the main screen work area, where 0 indicates the 
top edge of the screen. */
   static int y(); // platform dependent
-  /** Returns the width of the screen work area in pixels. */
+  /** Returns the width of the main screen work area in pixels. */
   static int w(); // platform dependent
-  /** Returns the height of the screen work area in pixels. */
+  /** Returns the height of the main screen work area in pixels. */
   static int h(); // platform dependent
 
   // multi-head support:
@@ -780,6 +780,16 @@
   static void screen_xywh(int &X, int &Y, int &W, int &H, int n); 
   static void screen_xywh(int &X, int &Y, int &W, int &H, int mx, int my, int 
mw, int mh);
   static void screen_dpi(float &h, float &v, int n=0);
+  static void work_area_xywh(int &X, int &Y, int &W, int &H, int mx, int my);
+  static void work_area_xywh(int &X, int &Y, int &W, int &H, int n);
+  /** 
+   Gets the bounding box of the work area of the screen that contains the 
mouse pointer.
+   \param[out]  X,Y,W,H the work area bounding box
+   \see void work_area_xywh(int &x, int &y, int &w, int &h, int mx, int my) 
+   */
+  static void work_area_xywh(int &X, int &Y, int &W, int &H) {
+work_area_xywh(X, Y, W, H, e_x_root, e_y_root);
+  }
 
   /**   @} */
 
Index: src/screen_xywh.cxx
===
--- src/screen_xywh.cxx (revision 9039)
+++ src/screen_xywh.cxx (working copy)
@@ -47,6 +47,7 @@
 static fl_gmi_func fl_gmi = NULL; // used to get a proc pointer for 
GetMonitorInfoA
 
 static RECT screens[16];
+static RECT work_area[16];
 static float dpi[16][2];
 
 static BOOL CALLBACK screen_cb(HMONITOR mon, HDC, LPRECT r, LPARAM) {
@@ -60,8 +61,11 @@
   if (fl_gmi(mon, &mi)) {
 screens[num_screens] = mi.rcMonitor;
 // If we also want to record the work area, we would also store mi.rcWork at 
this point
-//  work_area[num_screens] = mi.rcWork;
-
+work_area[num_screens] = mi.rcWork;
+/*fl_alert("screen %d %d,%d,%d,%d work %d,%d,%d,%d",num_screens,
+
screens[num_screens].left,screens[num_screens].right,screens[num_screens].top,screens[num_screens].bottom,
+
work_area[num_screens].left,work_area[num_screens].right,work_area[num_screens].top,work_area[num_screens].bottom);
+*/
 // find the pixel size
 if (mi.cbSize == sizeof(mi)) {
   HDC screen = CreateDC(mi.szDevice, NULL, NULL, NULL);
@@ -107,9 +111,11 @@
   screens[0].left  = 0;
   screens[0].right  = GetSystemMetrics(SM_CXSCREEN);
   screens[0].bottom = GetSystemMetrics(SM_CYSCREEN);
+  work_area[0] = screens[0];
 }
 #elif defined(__APPLE__)
 static XRectangle screens[16];
+static XRectangle work_area[16];
 static float dpi_h[16];
 static float dpi_v[16];
 
@@ -124,12 +130,25 @@
 screens[i].y  = int(r.origin.y);
 screens[i].width  = int(r.size.width);
 screens[i].height = int(r.size.height);
-CGSize s = CGDisplayScreenSize(displays[i]);
-dpi_h[i] = screens[i].width / (s.width/25.4);
-dpi_v[i] = screens[i].height / (s.height/25.4);
+Fl_X::screen_work_area(i, work_area + i);
+//fprintf(stderr,"screen %d 
%dx%dx%dx%d\n",i,screens[i].x,screens[i].y,screens[i].width,screens[i].height);
+//fprintf(stderr,"workarea %d 
%dx%dx%dx%d\n",i,work_area[i].x,work_area[i].y,work_area[i].width,work_area[i].height);
+if (CGDisplayScreenSize != NULL) {
+  CGSize s = CGDisplayScreenSize(displays[i]); // from 10.3
+  dpi_h[i] = screens[i].width / (s.width/25.4);
+  dpi_v[i] = screens[i].height / (s.height/25.4);
+  }
+else

1 2 3 4 5 >

1 - 100 of 481 matches

Mail list logo