Re: [fltk.bugs] [MOD] STR #2935: Fl_File_Browser::load() improvements for Unix
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2935 Version: 1.3-current Fix Version: 1.3-current (r9884) STR 2935 applied in svn. Thanks to Michael Baeuerle for the patch. Link: http://www.fltk.org/str.php?L2935 Version: 1.3-current Fix Version: 1.3-current (r9884) ___ 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
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2931 Version: 1.3-current Fix Version: 1.3-current (r9833) Applied the simplified version of Michael Baeuerle's scandir_posix patch. Note that this patch does not have all the const correct goodness from the earlier patches, but does mean that the fltk-1.3 API is not altered. Longer term, we'd be better off with the const correct versions (say 1.4 / fltk-3 or...) but this should do us fine for now! Link: http://www.fltk.org/str.php?L2931 Version: 1.3-current Fix Version: 1.3-current (r9833) ___ 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
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 ALbrecht queried whether there are any ABI issues: Micha reports that it looks like there are. In particular, the change of the prototypes of the sorting functions to be more const-correct breaks C++ linkage. Options are perhaps to revert the functions to their previous non-const forms? Greg suggests that we could keep the new forms if we put the ABI guards around them, with the old forms being the default... The new forms are preferred though because they are a better match to the Posix spec. In other, happier, news, Micha reports that the code runs fine on: -- POSIX.1-2008 compliant native 'scandir()': - HP-UX 11.11 (32Bit, big endian) Special AIX native 'scandir()': - AIX 5.1 (32Bit, big endian) -- And Manolo has verified that the special detection of MacOS =10.8 still works. 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
[fltk.bugs] [MOD] STR #2931: Re-implement fl_scandir for *nix systems that do not provide a native version
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 Upload Michael Baeuerle's patches to implement a scandir() function that we can use on *nix systems that is free of any potential license restrictions. The prior fl_scandir method was removed by #2687 due to license concerns, but this broke compilation on some systems (e.g. SunOS 5.7) that do not provide a suitable scandir() function natively. Attached files implement a substitute that we can use, that is reported to work, and should not break any exisitng platforms. Link: http://www.fltk.org/str.php?L2931 Version: 1.3-current scandir_patches_for_fltk-1.3.x-r9824.tar.gz Description: Binary data ___ 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
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 Currently tested on the following systems: -- Windows: - WinXP with mingw32 (assume other WinXX versions OK, since code change is trivial here) OSX: - 10.6.8 (OSX post 10.8 has a different scandir() implementation so needs to be verified separately) Systems with no usable native 'scandir()': - SunOS 5.7 (64Bit, big endian) Systems with a native POSIX.1-2008 compliant 'scandir()': - F17, 32-bit - Ubuntu 12.10, 32-bit (this codepath is effectively unchanged from before) OSF/DU/Tru64/IRIX: - None yet AIX: - None yet Systems with native 'scandir()', but not a POSIX.1-2008 compliant one (plus it matches to none of the explicitly handled cases above): - GNU/Linux with glibc 2.8 (32Bit, little endian) - NetBSD 5.1 (32Bit, little endian) 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 #2730: valgrind, out of bounds access, Fl_Text_Display wrapping
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2730 Version: 1.3-current Corvid indicates this arose after fixing #2691... Matt, I think that was applied by you; do you know what is going on with this one? The text editor code is practically opaque to me; I have no idea what is going on! Link: http://www.fltk.org/str.php?L2730 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 #2845: image test program blank on cygwin/GDI
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 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 #2873: Fl_JPEG_Image: when file not found, d() returns 3 instead of 0
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2873 Version: 1.3-current Link: http://www.fltk.org/str.php?L2873 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2861: Enabling Extract gettext on fluid menus + possibility of static initialization of strings
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2861 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2861 Version: 1.3-feature ___ 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
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2857 Version: 1.3-current Link: http://www.fltk.org/str.php?L2857 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2798: X11 coordinate clipping - label
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2798 Version: 1.3-current Link: http://www.fltk.org/str.php?L2798 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2802: poor modality interaction with local window manager
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2802 Version: 1.3-current Link: http://www.fltk.org/str.php?L2802 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2822: Fl_Input UTF-8 handling
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2822 Version: 1.3-current Link: http://www.fltk.org/str.php?L2822 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2823: Fl_Preferences unecessary setting of dirty attribute
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2823 Version: 1.3-current Link: http://www.fltk.org/str.php?L2823 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2833: fltk-3 tries to compile local PNG lib even if system lib is selected
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2833
Version: 3.0
Fltk-3 attempts to build the local PNG files even if configure selects the
system PNG libs instead.
However, this usually fails, since the local PNG lib is newer than most
distros (including OSX) are currently shipping, and since the system
header files are found before the local PNG header files, version
mis-match occurs.
I have seen this fail on OSX and Linux (and maybe mingw too, not certain)
and appears to be a feature of the restructured build hierarchy,
perhaps.
Anyway, here's a snapshot from OSX (though other hosts are similar...)
First, see that we configure with the SYSTEM image libs:
Configuration Summary
-
Directories: prefix=/usr/local
bindir=${exec_prefix}/bin
datadir=${datarootdir}
datarootdir=${prefix}/share
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib
mandir=${datarootdir}/man
Graphics: Quartz
Image Libraries: JPEG=System
PNG=System
ZLIB=System
Large Files: YES
OpenGL: YES
Threads: YES
configure: creating ./config.status
config.status: creating makeinclude
config.status: creating fltk.list
config.status: creating fltk3-config
config.status: creating fltk.spec
config.status: creating include/fltk3/Makefile
config.status: creating include/config.h
Now note that during the build, we attempt to build libpng anyway, but it
fails since the system headers do not match the local png source files...
Compiling fltk3images/PNMImage.cxx...
/usr/bin/ar cr ../lib/libfltk3images.a ...
Compiling fltk3png/png.c...
fltk3png/png.c:14:21: error: pngpriv.h: No such file or directory
fltk3png/png.c:17: error: expected â=â, â,â, â;â, âasmâ or
â__attribute__â before âYour_png_h_is_not_version_1_5_10â
fltk3png/png.c:559: error: expected â=â, â,â, â;â, âasmâ
or â__attribute__â before âPNGAPIâ
fltk3png/png.c:649: error: expected â=â, â,â, â;â, âasmâ
or â__attribute__â before âPNGAPIâ
fltk3png/png.c:680: error: expected â=â, â,â, â;â, âasmâ
or â__attribute__â before âPNGAPIâ
fltk3png/png.c:687: error: expected â=â, â,â, â;â, âasmâ
or â__attribute__â before âPNGAPIâ
fltk3png/png.c:695: error: expected â=â, â,â, â;â, âasmâ
or â__attribute__â before âPNGAPIâ
fltk3png/png.c:762: error: expected â=â, â,â, â;â, âasmâ
or â__attribute__â before âPNGAPIâ
make[1]: *** [fltk3png/png.o] Error 1
make: *** [all] Error 1
immpcx:fltk-3-syslibs ian$
Link: http://www.fltk.org/str.php?L2833
Version: 3.0
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2833: fltk-3 tries to compile local PNG lib even if system lib is selected
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2833 Version: 3.0 As a rider to this, I find that with judicious tweaking of the include paths in makeinclude I can get this to build OK, so that might be a feasible workaround. Though I do wonder why it is building the local libs at all if the system ones are selected (note that it also builds the local zlib and jpeg, though they seem less fragile than the PNG build is.) Link: http://www.fltk.org/str.php?L2833 Version: 3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2819: MinGW: #include dirent.h breaks fltk compilation
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 Using older mingw - i.e. gcc-3.4.2 and Msys-1.0, and testing fltk-1.3 r9329 I find: - The stock build proceeds correctly. - config.h has #define HAVE_DIRENT_H 1 set tested on 9th April 2012 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 dirent.h breaks fltk compilation
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 OK - took r9329 and applied the proposed patch by hand. make clean ; make proceeds normally and a brief run of a few test examples works well. It would appear the proposed change has no negative impact on an older mingw install, at least as far as I can ascertain. 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] [LOW] STR #2814: Status of fltk-1.3 compatability (as at r9297)
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 Yup, probably... If we use the wrong fluid (i.e. the fltk3 fluid) then, with the current build (r9315) we get 58 out of 70 exe's built. Almost all the failures (11 out of 12 I think, counting by hand) are fluid-related, so if we use a working fluid we will be almost home and dry... at least so far as building the code goes. Though, that said, there are actually a few funnies at runtime, where things are not quite right - but we can fix that once the builds are working. Switching to a good fluid would be a big help in that case. 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)
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 Switching to using a knwn good fluid (the one from my fltk-1.3 build in this case) I now build 68 out of 70 exe's. The hold-out (i.e. still broken) are: - table.cxx Compiling table.cxx... In file included from ../include/FL/Fl_Table.H:46, from ../include/FL/Fl_Table_Row.H:36, from table.cxx:18: ../include/FL/Fl_Scroll.H: In member function `Fl_Scrollbar* Fl_Scroll::vertical_scrollbar()': ../include/FL/Fl_Scroll.H:101: error: expected primary-expression before '*' token ../include/FL/Fl_Scroll.H:104: error: expected primary-expression before '*' token ../include/FL/Fl_Scroll.H:104: error: base operand of `-' is not a pointer ../include/FL/Fl_Scroll.H:106: error: non-lvalue in assignment ../include/FL/Fl_Scroll.H:107: error: base operand of `-' is not a pointer ../include/FL/Fl_Scroll.H:108: error: base operand of `-' is not a pointer ../include/FL/Fl_Scroll.H:110: error: invalid conversion from `int' to `Fl_Scrollbar*' ../include/FL/Fl_Scroll.H: In member function `Fl_Scrollbar* Fl_Scroll::horizontal_scrollbar()': ../include/FL/Fl_Scroll.H:114: error: expected primary-expression before '*' token ../include/FL/Fl_Scroll.H:117: error: expected primary-expression before '*' token ../include/FL/Fl_Scroll.H:117: error: base operand of `-' is not a pointer ../include/FL/Fl_Scroll.H:119: error: non-lvalue in assignment ../include/FL/Fl_Scroll.H:120: error: base operand of `-' is not a pointer ../include/FL/Fl_Scroll.H:121: error: base operand of `-' is not a pointer ../include/FL/Fl_Scroll.H:123: error: invalid conversion from `int' to `Fl_Scrollbar*' make: *** [table.o] Error 1 And - shapedwindow (which is never going to work under fltk1 so is missing from the test1 folder anyway.) So, if we can sort out what's wrong with table.cxx we are nearly there. 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)
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 Helps a bit - at least on WInXP i'm now building 54 targets. We're getting there! Log of the current errors attached, in case anyone has time to take a peak! Cheers... 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)
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 Attached file build-log... Link: http://www.fltk.org/str.php?L2814 Version: 3.0 build-log Description: Binary data ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2781: dirent.h compilation error
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2781 Version: 1.3.0 For the record, one of my test machines in ubuntu 11.10 and I am not seeing any problems, either with the svn repo or with the weeklies, so I don't think there is a general issue here. Maybe something is weird in the OP's setup? Link: http://www.fltk.org/str.php?L2781 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 #2773: window always show on the wrong screen
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2773 Version: 1.3-current Any update on this? I know Manolo did a pile of good work in sorting out how the screen and work areas are computed, but I wonder if the effect you are seeing might be a side-effect of that in some way? Don't know what rev Manolo's changes went in at, be interesting to see if the overlap the range you se the feature appearing in... Link: http://www.fltk.org/str.php?L2773 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current Just some additional notes culled from the ref'd thread: It appears, based on testing by the OP (David) and by me, that the crux may be in the Fl_Double_Window flush() method. If XDBE is inhibited, then at line 338 of r9209, we have an fl_offscreen created for the double buffer, which is then assigned to other_xid: myi-other_xid = fl_create_offscreen(w(), h()); Now, it is clear that the offscreen is created without first checking that the dimensions are non-zero, and that appears to be what triggers the subsequent crash... David's workaround was to do: myi-other_xid = ( w() h() ? fl_create_offscreen(w(),h()) : 0 ); instead, i.e. only create the offscreen surface for the double buffering of the window if the window has non-zero size. Otherwise, other_xid is set to NULL. It looks like *most* other places where other_xid is used, it is checked for being NULL first, so this ought to be safe. David reports good results with this workaround in his tests, though I was initially sceptical. I'm now of the opinion that this workaround is probably good, though we need to check there are no places where other_xid is actually used without first being checked for NULL, just to be sure! Link: http://www.fltk.org/str.php?L2797 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 #2687: src/scandir.c should probably be removed or rewritten
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 OK - this is odd. I never got any update emails form this STR, but I now see that Matt said, on the 20th Sept., that we should try removing the code and see what falls out... Then Greg bumped that yesterday (20th Dec) which I never got either... (Hmm, I wonder how many other STR posts I've missed?) The proper way to do this would be to restructure the files a bit and tidy up the Makefile accordingly (the WIN32 implementation is #included via the file I'd like to remove, for example...) and I don't have the tools to build all the assorted targets. So, until we ascertain that actually nobody still uses this code, I'll leave in the stub, but take away the suspect/offending code, and see how that flies! Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2687: src/scandir.c should probably be removed or rewritten
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 OK - r9210 should do it... Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2687: src/scandir.c should probably be removed or rewritten
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 Fix Version: 1.3-current (r9210) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 Fix Version: 1.3-current (r9210) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2709: fl_round_box may corrupt line style settings in Win32 systems - was: Windows7/x64 drawing problems in buttons.exe demo
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 I can't remember - did this ever get fixed? Link: http://www.fltk.org/str.php?L2709 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 #2735: fl_utf_toupper() and Eszett
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2735 Version: 1.3-current Responding to Torsten's question, I don't think other languages are likely to be affected? The sharp-s thing is more of a Germanic languages thing, and I don't think it occurs at all in (for example) the Romance languages? It doesn't even occur in English, which is (in large part) like a Germanic language... I do find it odd that native German speakers who responded seem to think that the Unicode recommendations are out of sync with real world usage, though! (Or maybe I am not so surprised...) Link: http://www.fltk.org/str.php?L2735 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 #2676: fl_alert dialogs etc crashes in XftTextExtents32 on Solaris
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2676 Version: 1.3-current OK. So... are we going to close this one as not a fltk bug and move on, or... Link: http://www.fltk.org/str.php?L2676 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current Yup, that sounds like the best deal... Also, why am I not getting any of these posts in my mail??? Other fltk mail seems to be arriving OK... Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current Side note: This STR may also have relevance to STR 2791, where the discussion is about what happens to Fl_Tile if you resize the window to 0x0... Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2723: Bug reports never seem to become less.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2723 Version: 1.3.0 Maybe if we use tachyonic neutrinos we can fix STR's from the future... Link: http://www.fltk.org/str.php?L2723 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 #2738: fltk-3 align anomaly
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2738 Version: 1.4-feature Link: http://www.fltk.org/str.php?L2738 Version: 1.4-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2682: Vertical scrollbar of Fl_Text_Editor have a strange behavior. Or is bug?
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2682 Version: 1.3-current Sorry - but I still can't figure out how to reproduce this bug, based on your description. Can you post a step-by-step description (maybe even in fltk.general) that is simple enough for me to follow and see if we can reproduce this for investigations... Link: http://www.fltk.org/str.php?L2682 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
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 Sounds good - but I don't have ready access to any multi-head kit; all my good gear is still in storage while we work on the house (yes, and that is well over a year now...) 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 #2705: FL_EXPORT that should not exist: See STR #2632 for FL_Button subclasses
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2705 Version: 1.3-current Albrecht - you figured out the last one, any ideas on this? Link: http://www.fltk.org/str.php?L2705 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
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) NOTE: There is work in #2697 to create the necessary work_area methods (thanks Manolo) that we should be able to use to get a better overall solution to this one, I think... Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) ___ 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
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 NOTE: when this is in place, it will be very useful for fixing #2695 I think... 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] [MOD] STR #2709: Windows7/x64 drawing problems in buttons.exe demo
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 Gents, We should change the title of this report... It is not x64 or WIN7 specific, it's more like a general bug in fltk-1.3 on WinXX hosts... Anyway, what I find is that, at r8630 someone (looks like Albrecht) checked in a mod to fl_round_box.cxx that added a call to: fl_line_style(0,1); at line 46 then: fl_line_style(0); at line 73. With those lines commented out, the buttons demo then seems to work fine, without the rendering bug. So, I speculate that forcing the line style back to the default at line 73 may be the issue? e.g. if it was not already the default value in the main button drawing code when the round_box got drawn... (Fl_Round_Button derives from Fl_Light_Button so the code is maybe doing something with line styles before the round down box for the button gets drawn? I can't tell...!) How do we read the current demanded line_style so that we can reset it to that, rather than just back to default? Albrecht, can you recall what r8630 was about? Also, slightly related, the doxygen header in Fl_Round_Button.H says that the deafult selection_color for a Fl_Round_Button is FL_RED but in fact the code sets it to FL_FOREGROUND_COLOR ... Link: http://www.fltk.org/str.php?L2709 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 #2709: fl_round_box may corrupt line style settings in Win32 systems - was: Windows7/x64 drawing problems in buttons.exe demo
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 Ok, checked the logs. r8630 says: r8630 | AlbrechtS | 2011-05-01 13:45:29 +0100 (Sun, 01 May 2011) | 11 lines Fixed drawing artifacts when scrolling round boxes (FL_ROUND_UP_BOX and FL_ROUND_DOWN_BOX) on Linux (STR #2615). This was done by (a) setting the line width in the box drawing function (was undefined, maybe 0) (b) taking care of zero and negative line width in X11 clipping functions. Both solutions would have solved the particular problem individually. Additionally made local helper function fl_arc_i() in src/fl_round_box.cxx static to avoid name clashes. So... maybe we can back out the line_style changes in fl_round_box? I guess that's option (a) in Albrecht's comment? Would that still be OK on linux, and not break Win32? Do we know...? Link: http://www.fltk.org/str.php?L2709 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 #2695: huge menus do not scroll at screen edges any more - regression
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) Manolo, Yes, that works OK, *for the single-monitor* case - but as you will no doubt have noted from my analysis of the problem above, I am not certain that this will work in a multi-head case, where there may be multiple displays of differing sizes. In that case, IIRC, x(), y(), w() and h() return a bounding rectangle over all the screens (that certainly used to be the behaviour when I was testing multi-head systems way back when, it may no longer be the case...) whereas the menu code clearly needs to understand the bounds for the *current* screen only. I do not have access to a multi-head system at present to test this on, but my suspiscion is that the fix as implemented will NOT work at all well on a multi-head system. Indeed, I think we changed to using screen_xywh() specifically to cope with the multi-head case. (Though back then screen_xywh() returned work-area rather than screen-area, so that was OK!) Does anyone have a multi-head system we can verify this on? Also - I still like the suggestion that we try and add little there is more arrows to the large menus in this case (other UX factors of using large menus notwithstanding...!) Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) ___ 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
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) I don't have enough (or indeed any!) different multi-head systems to test, but is Manolo right that the behaviour of the Fl::x(),y(),w()h() methods on a multi-head system is different depending on what host system you are on? If so, we *need* to fix that - these methods *have* to be consistent across hosts as they are used all over the place... And yes, this is off-topic for this STR. I'll raise a new one. Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #2697: Fl::x() y() w() h() behaviour not consistent across platforms in multi-head systems
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 Manolo reports that the Fl::x(), y(), w() and h() functions return different responses across platforms, in multi-head systems: - on Mac OS, the workarea size of the focus-containing screen - on MSWIN, the workarea size of the main screen - on X11, the workarea size of fl_screen Clearly, that means that code that uses these methods may behave unexpectedly on multi-head systems, if we move from one host to another. This seems like it could be a Very Bad Thing. 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
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 do not know - except that we must be consistent (for whatever that means...) The OSX method, that returns x,y,w,h, for the focussed display, seems like one credible option. However, we also need methods that will tell us the full extended display area, and I honestly think that x,y,w,h used to do this (I ran a system with several heads years ago, and I *think* that's how it worked back then... I am probably misremembering...) So that was why I suggested that we have both screen_xywh() and work_xywh(), so that there would be clear and unambiguous separation, per display. But what we do with the current x,y,w,h... well...? 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] [MOD] STR #2695: huge menus do not scroll at screen edges any more - regression
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current The idea of adding an optional flag to the the screen_xywh calls for WORK_AREA vs SCREEN_AREA is attractive - but there are (currently) 4 different forms of screen_xywh() so it might be tricky to add the extra flag and still have the compiler distinguish which versions we mean? That was why I suggested adding work_xywh() calls too (maybe all 4 cases?) - though I don't know how that would affect compatability... Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2690: fix a debug printf
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2690 Version: 1.3-current This looks to be correct - I might go ahead and apply it, if no one objects? Link: http://www.fltk.org/str.php?L2690 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2690: fix a debug printf
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2690 Version: 1.3-current Fix Version: 1.3-current (r8911) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2690 Version: 1.3-current Fix Version: 1.3-current (r8911) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2676: fl_alert dialogs etc crashes in XftTextExtents32 on Solaris
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2676 Version: 1.3-current Is there any update on this? Are we in a position where we can say whether this is a bug, or just a feature of the OP's setup, or...? Link: http://www.fltk.org/str.php?L2676 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 #2678: internationalization
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2678 Version: 1.3.0 Is there any update on this error report? Link: http://www.fltk.org/str.php?L2678 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 #2688: fl_width(' ') with --disable-xft
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2688 Version: 1.3-current Hmm - that might be right... I'll try and find time to dig into this one... Anyone else know what's going on here? Link: http://www.fltk.org/str.php?L2688 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 #2689: Handling of @ symbols in fl_draw() and symbol expansion
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2689 Version: 1.3-current Link: http://www.fltk.org/str.php?L2689 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 #2687: src/scandir.c should probably be removed or rewritten
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 I've added a #warning message to the suspect code, in the hope that this will let us see when/where/if it is ever actually used. Though this will only work if the host compiler is gcc, so may not actually help identify the problem at all... Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2687: src/scandir.c should probably be removed or rewritten
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 Adding to Greg's note above: - This code is *not* used under the win32 targets, there is a separate implementation in scander_win32.c for them; however, that function is only pulled into the fltk build as a consequence of being wrapped in an #ifdef within the suspect file. - It's far from obvious which platforms (if any) actually pull in the suspect code these days. The suspect code ought to be elided from the build on any host that has a working implementation of scandir(), which I guess is most platforms these days? - The suspect code, if it is used at all, is only called from within filename_list.cxx. (Side note: There may be some scope for flattening filename_list.cxx, scandir.c and scandir_win32.c into a single file, as there seems to be considerable overlap...) Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2490: Callbacks from menu don't work properly, especially when displaying dialogs
[STR Closed w/o Resolution] Link: http://www.fltk.org/str.php?L2490 Version: 1.1.10 Fix Version: Will Not Fix OK - it's been a while now, and no new reports or updates to this STR have been received. On the advice of the OP, I am closing this bug. The advice we have is that this feature is specific to a WM, and is probably a bug in the WM rather than in fltk-1.1.10 in this case. NOTE: This bug is tied to #1986 which has similar symptoms, but appears to be a different bug in practice. It is *not* proposed that we close #1986 at this stage. Link: http://www.fltk.org/str.php?L2490 Version: 1.1.10 Fix Version: Will Not Fix ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #1986: X-server freezes when a window is opened while the menu is open
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L1986 Version: 1.4-feature Fix Version: 1.1.10 NOTE: This bug was tied to an apparently similar bug (#2490) on fltk-1.1.10. That other bug has recently been closed as no fault found, it appears that in that case the bug was specific to a WM, rather than a bug in fltk. So, this bug (#1986) is probably unrelated to #2490 after all, as it turns out... Link: http://www.fltk.org/str.php?L1986 Version: 1.4-feature Fix Version: 1.1.10 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2686: fl_draw() not drawing wrapped line starting with @ when draw_symbols is false
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2686 Version: 1.3-current Please bring this discussion over to fltk-general, and bring a minimal worked example, so we can investigate what's going on. Also post the example code here for reference, perhaps? Link: http://www.fltk.org/str.php?L2686 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2673: test/editor beeps at Search-Find... and Search-Find Again
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2673 Version: 1.3.0 Or do we just stop fl_input() from beeping? Why does it beep, anyway? Link: http://www.fltk.org/str.php?L2673 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 #2678: internationalization
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2678 Version: 1.3.0 Do you have any botes of which versions do work / which version do not work, to help us pin down the regression? Also, perhaps you could post a small example fluid file that can be used to elict the fault, to ease investigation? Link: http://www.fltk.org/str.php?L2678 Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2682: Vertical scrollbar of Fl_Text_Editor have a strange behavior. Or is bug?
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2682 Version: 1.3-current can you bring this discussion onto fltk.geneal for now? To try and clarify the issue you are seeing. I can't see the fualt trying to reproduce the description given here... Link: http://www.fltk.org/str.php?L2682 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 #2632: FL_EXPORT that should not exists
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2632 Version: 1.3-current You will need to provide more information: What host platform? What compiler toolchain? What build process? I can't see what the problem is - maybe I am missing something obvious? As far as I can tell, the FL_EXPORT macro seems to be getting defined (or made empty) as approporiate to the build target, and all is good. What are you doing that is triggering this problem? Link: http://www.fltk.org/str.php?L2632 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 #2634: fl_help_view bug fixes and new features
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2634 Version: 1.4-feature @markcw: I'm temporarily bumping this to 1.4 for now, so we can push ahead with the 1.3.0 release cycle. Don't take that the wrong way though - we'll come back to this. In particular, can you post in fltk.general your questions (e.g. about getcwd() on OSX and building on win32 hosts) and we can give you a few tips and pointers to keep you going! Thanks for the input. Link: http://www.fltk.org/str.php?L2634 Version: 1.4-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2632: FL_EXPORT that should not exists
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2632 Version: 1.3-current If you refer to the header file Fl_Export.H, you will see that FL_EXPORT is defined to 3 possible values: # if defined(FL_DLL) #ifdef FL_LIBRARY # define FL_EXPORT __declspec(dllexport) #else # define FL_EXPORT __declspec(dllimport) #endif /* FL_LIBRARY */ # else #define FL_EXPORT # endif /* FL_DLL */ The intent, then, is that if the BUILD defines FL_DLL and FL_LIBRARY, then FL_EXPORT will be set for building the DLL. If you set only FL_DLL then FL_EXPORT will be set for *using* the DLL, but FL_LIBRARY must *not* be defined in that case. Or you can set neither FL_DLL or FL_LIBRARY and in that case FL_EXPORT will have no value, and that is the normal mode for all general building - and may work for using the DLL too, of course. Is that not what you want? What values does your build set for FL_DLL and FL_LIBRARY ? It sounds to me like your build may be setting them inappropriately, as no one else is reporting issues with this. Well, not so far, anyway! Link: http://www.fltk.org/str.php?L2632 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 #2626: iconized window will never show
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2626 Version: 1.3-current @Kurt - do you have a test sample we can run to see the effect? A simple, compileable example would be useful. Manolo can't reproduce it, so an example that shows it would help a lot. Is it possible that this is some feature of your Window Manager, rather than a specific fltk bug? Link: http://www.fltk.org/str.php?L2626 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 #2490: Callbacks from menu don't work properly, especially when displaying dialogs
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2490 Version: 1.1.10 Is this STR still active, or has the problem Gone Away? It seems that this problem may have been WM or hardware specific? Is that so? Do we know if this STR should also apply to fltk-1.3? Updates welcome! Link: http://www.fltk.org/str.php?L2490 Version: 1.1.10 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2629: Command shortcuts make Mac OS beep
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2629 Version: 1.3-current Yup - I had not noticed that, but I just did back to back tests of my app with fltk-1.1 and fltk-1.3, and the 1.3 build beeps every time I hit a CMD+key whereas the 1.1 build is silent. So something has changed in there. I have no idea what - probably one for Manolo as he's good at pinning down OSX weirdness. Link: http://www.fltk.org/str.php?L2629 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 #2622: cannot compile on cygwin
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2622 Version: 1.3-current Albrecht asked: OT here in fltk.general To Ian: it's your code, and it compiles well with the /broken/ MinGW wingdi.h, but not with Visual C++ (STR #2623) and the corrected mingw64 header files. If you have a better idea than an autoconf feature test, please give a comment on STR #2622. Thanks. /OT I can't reproduce the fault - I don't have the necessary bits, but how about this: As far as I understand it, the variant compilers have different ideas as to what the lpClass member of the GCP_RESULTSW struct is. Now, we do not need the lpClass data at all for what we are doing, so if we make that NULL, the problem maybe goes away? OK: I just tested this change in fl_font_win32.cxx @ line 345: gcp_res.lpClass = NULL;//c_buff; gcp_res.lpGlyphs = (LPWSTR)w_buff; gcp_res.nGlyphs = wc_len; gcp_res.lStructSize = sizeof(gcp_res); And for me, on win32 with mingw, that compiles OK and runs my suplementary plane glyph test OK too. Does that work elsewhere? If so, we can use that (which ought to keep the compilers happy) and can also remove all references to c_buff as we are no longer using it. Any good? Link: http://www.fltk.org/str.php?L2622 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 #2622: cannot compile on cygwin
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2622 Version: 1.3-current Right - I pushed a change at r8643 that I believe fixes this. Please test on as many variants as possible and let me know. Link: http://www.fltk.org/str.php?L2622 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 #2622: cannot compile on cygwin
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2622 Version: 1.3-current OK - sounds like this might be a working solution then. Note that I have also pushed a somewhat related fix to a bug that Albrecht discovered whilst testing this, so 8644 might be considered the fix point. I guess we need some feedback from Greg as to whether this also resolves the issues he was seeing with the VS tools, in his related bug... Link: http://www.fltk.org/str.php?L2622 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 #2623: Build errors with VS2005
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2623 Version: 1.3-current Possibly fixed by r8644, which does appear to resolve the related STR #2622. Link: http://www.fltk.org/str.php?L2623 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #1899: aglUseFont on QUARTZ does not use correct face
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1899 Version: 1.4-feature Since this was last updated, Manolo has done a lot of work in this area (text rendering, GL, OSX, Quartz...) so do we know if this STR is still extant, or has this problem been fixed? Link: http://www.fltk.org/str.php?L1899 Version: 1.4-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2622: cannot compile on cygwin
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2622 Version: 1.3-current Is there any update on this? I don't have any problem with the win32 builds, but I only ever use MinGW now, and do not have ready access to either cygwin or the VC toolchain. Link: http://www.fltk.org/str.php?L2622 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2591: Keyboard navigation appears to be backwards in mutli-button message boxes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2591 Version: 1.3-current Whilst playing with the popups demo from the test folder, I notice that, on popups that have multiple buttons, navigation using the keyboard cursor keys or tab keys appears to iterate through the buttons in the opposite direction to what one might expect from the button being pressed (i.e. pressing the right-arrow on the keypad moves the focus to the button on the left...) Probably not a new bug - it transpires that fltk-1.1 also does this, and fltk-2, though it is annoying now I hve noticed it! Link: http://www.fltk.org/str.php?L2591 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 #2587: Compose not properly reset with compose_reset() on X11
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2587 Version: 1.3-current Though most of those added functions are only used if XFT is enabled in the build (admittedly the default in 1.3) but the build can still be done in a non-XFT way for platforms that do not support the newer fuctions, or for users who do not wnat XFT. So whatever we come up with, has to work in either X11 variant, both with XFT and with only old-style Xlib support. Link: http://www.fltk.org/str.php?L2587 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 #2550: Xlib fl_text_extents
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current Fix Version: 1.3-current (r8404) Believed fixed in 1.3 subversion repository at r8404. Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current Fix Version: 1.3-current (r8404) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current Do we consider this STR resolved now? If so, I guess we can close this one too... Link: http://www.fltk.org/str.php?L2550 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 #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current Link: http://www.fltk.org/str.php?L2550 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 #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current @manolo: OK, thanks for that, that seems to have nailed it. (Though more testing is welcome of course!) @corvid: The really *safe* way to do that is to make the measurements in your draw() method, at which point you can be sure the gc is valid and the font should be set. That's true on all platforms actually, although (as has been observed) some (e.g. XFT) will *probably* work, if called at random times - though if you have multiple fonts in different widgets, there is a high likelihood that the measurement will be based on the font that the last widget that was drawn used, which may not be the font you wanted! An alternative might be to show your window then later (e.g. in a timeout as you suggested) use make_current() to set a valid context based on that window, and call the measurement functions then. That should also work, but feels like a hack to me. If you can contrive to make the measuremnts within your draw() method, all should be well, and that is the most graceful solution... If you look at the unittest_text.cxx example, you will see that is what is done there, and is the recommended method. Link: http://www.fltk.org/str.php?L2550 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 #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current Note that many of the Xlib font handling calls will choke like this if there's no valid drawing context, not just the changes I have made to fl_text_extents under Xlib. Indeed, the basic text drawing will also fail, in much the same way - and I deliberately derived the new fl_text_extents from the draw code in the hope of computing the correct metrics... Link: http://www.fltk.org/str.php?L2550 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 #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current Well, sort of - that's a kind of new thing, and I don't know how widely supported it is. I quote; The function Xutf8TextExtents is an extension introduced by The XFree86 Project, Inc. in their 4.0.2 release. Its presence is indicated by the macro X_HAVE_UTF8_STRING. To be honest, I didn't know they had added that, as previous googling for it or something similar had not shown much in the way of hits... I imagine that we could extend the code that is there at present to test explicitly for X_HAVE_UTF8_STRING (at build time) and use this function if found, or use the current fallback behaviour otherwise. This seems feasible, I think. Anyone got any views on this? Link: http://www.fltk.org/str.php?L2550 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 #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current Looking at this again, albeit briefly, I think we'd be better off leveraging the logic that's in out utf8Wrap.c (in src/xutf8 in the fltk tarball) and making something similar to our existing XUtf8DrawString() function. That should work anywhere and will have th merit of returing the same measurement as XUtf8DrawString() actually draws. If we use Xutf8TextExtents() then (if it works at all on unknown platform Xyz) there is a fair chance it will measure the string differently from how we render it, and so the results may be slightly off... But still not easy. Link: http://www.fltk.org/str.php?L2550 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 #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current I have committed a fix for this at r8399. Please test as much as possible as I am not convinced I have this right. Any feedback or improvements welcomed... Link: http://www.fltk.org/str.php?L2550 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 #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current Link: http://www.fltk.org/str.php?L2550 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 #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current Yes - that was me; I did what I could to implement fl_text_extents, but when it came to the Xlib code I choked, I just did not know what to do. I mainly use XFT... It still returns a bounding box that you can use, it just is not fitted tightly around the text (it just re-uses fl_measure, as I'm sure you have noticed!) XFT is nice though! Link: http://www.fltk.org/str.php?L2550 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 #2552: Fl_Tabs and focus
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2552 Version: 1.3-current Yup - I see that too. Note that this behaviour is consistent in that fltk-1.1 and fltk-1.3 both seem to do the same thing. But I suspect that what they do may be wrong or at least unexpected at any rate. Link: http://www.fltk.org/str.php?L2552 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 #2553: Font Problems in fluid Code Editor.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2553 Version: 1.3.0 Brian, On an extensive sample of 1 XP box, I could not reproduce this fault. Will try a few others, time permitting. I do think it would be nice to make that font user-settable though, which may alleviate this problem anyway? Link: http://www.fltk.org/str.php?L2553 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 #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current Might be - you tell me! Here's a list of what I know about measuring text extents in Xlib: : : : And that's it. If you reckon that's the way to get the actual inked extent of text in Xlib then that would be ideal, I'm sure a working patch would be most welcome. Link: http://www.fltk.org/str.php?L2550 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 #2553: Font Problems in fluid Code Editor.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2553 Version: 1.3.0 Just tried this on this Vista box, and I'm still NFF. Though I see Greg's screenshot - that does look nasty. I wonder if it is maybe doing something odd with the text handling (e.g. harking back to Edzard's question about UTF8) or if it is just some fonts weirdness... Link: http://www.fltk.org/str.php?L2553 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 #2553: Font Problems in fluid Code Editor.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2553 Version: 1.3.0 Oops! Now this is interesting: If I open the sample file in fluid, then use the widget tree to open the Target MenuItem (i.e. expand the entry for submenu wf_options then click on the Target entry, all is well and the fonts look correct. And are correct in all views thereafter. This is always the method I use to edit my widgets. However, if the first widget I open is reached by instead clicking on the widget itself in the layout, then I get the bad font after all (and in any edit view thereafter.) So it would appear that where the edit view is invoked from makes a difference to how it renders its text. This seems very odd... Suggestions welcome! Link: http://www.fltk.org/str.php?L2553 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 #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current So it's not at all a matter of using XTextExtents(), then? Well, I had a brief look then lost heart again. Short answer, no, XTextExtents() will not do. We'd need to extend .../src/xutf8/utf8Wrap.c to add our own XUtf8TextExtents function, modeled after XUtf8TextWidth(), and then use that - I imagine it would probably depend on XTextExtents16() though, rather than the plain XTextExtents(). That might then work - though I'm not sure if XTextExtents() returns the inked bounding box, or the typographical bounding box. If the latter, then the result will be very much like the existing code anyway, so may not be worth the effort. The distinction between fl_text_extents() and fl_measure() is that the former bounds just the inked area, the latter the typographical area... Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2511: Generated docs have outdated description of building on WINxx
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2511 Version: 1.3-current Brian just pointed out to me that the section in the generated docs about building for winXX hosts (chapter 3.6 et seq) is substantially out of date as comapred with the information that is in the README.MSWindows.txt file. Presumably we should look at merging the more recent descriptions from the various Readme's back into the generated docs at some point? Link: http://www.fltk.org/str.php?L2511 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2510: 'fluid -help' doesn't show anything on windows
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2510 Version: 1.3-current Not adding much - just wanted to note (in response to Albrecht's comment above) that the Msys shell does behave sensibly when running fluid (i.e. fluid is not backgrounded) and the stdio does go the shell as you'd expect. Link: http://www.fltk.org/str.php?L2510 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2505: Xft backend doesn't filter bad UTF-8 characters
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current Note that some of the other text handling functions do malloc the local string the first time they are called then hang onto the allocation and track its size, and realloc it later if a bigger string needs to be processed. I don't know if this is better or worse than having a large fixed string. Obvioulsy a fixed string might be subject to a buffer overflow, and allocation from the heap may be better than a static string or allocation from the stack... I don't know which I dislike least, actually... I don't *like* either option much! Link: http://www.fltk.org/str.php?L2505 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 #2508: Update jpeg, png, and zlib to their current version
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2508 Version: 1.3.0 Oh! That would be awkward - I thought the jpeg8x stuff was a superset of the jpeg6b that we currently use, is that not the case? Link: http://www.fltk.org/str.php?L2508 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 #2507: UTF-8 file name encoding handling in file chooser
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2507 Version: 1.3-current Not so much policy as an observation that implementation of dynamic arrays is somewhat inconsistent between compilers, so we need to shoot for the lowest common denominator. Link: http://www.fltk.org/str.php?L2507 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] FLUID crashes in MinGW 64 bit
Dan,
Please repost your query in fltk.general
This list (fltk.bugs) is meant for monitoring auto-generated messages from the
bug tracking system, not for user posts, so it is unlikely that you will get
the feedback you need here!
Also, please post plain-text as far as possible; html encoded messages may
cause odd formatting behaviours...
This is a multi-part message in MIME format.
--_=_NextPart_001_01CBACAE.26131AD8
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
I'm unable to build the test cases in 1.3.x (both rc2 and the lastest
snapshot) because of a trapped signal in fluid when trying to build code
from fast_slow.fl. Using gcc 4.4.5 and the sezero toolchain of mingw64.=20
=20
I can start up fluid, however it crashes when attempting to load .fl
files (e.g. test/CubeViewUI.fl). Other FLTK test apps do run (checkers,
Sudoku, et. al.).=20
=20
I read that 1.1.x would not support 64 bit, and that I should be using
1.3.x. I configured with and without --enable-threads. Are there special
options to build 64 correctly under MinGW?
=20
Thanks,
Dan
--_=_NextPart_001_01CBACAE.26131AD8
Content-Type: text/html;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
html xmlns:v=3Durn:schemas-microsoft-com:vml =
xmlns:o=3Durn:schemas-microsoft-com:office:office =
xmlns:w=3Durn:schemas-microsoft-com:office:word =
xmlns:m=3Dhttp://schemas.microsoft.com/office/2004/12/omml; =
xmlns=3Dhttp://www.w3.org/TR/REC-html40;headmeta =
http-equiv=3DContent-Type content=3Dtext/html; =
charset=3Dus-asciimeta name=3DGenerator content=3DMicrosoft Word 12 =
(filtered medium)style!--
/* Font Definitions */
@font-face
{font-family:Cambria Math;
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:Calibri,sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:Calibri,sans-serif;
color:windowtext;}
..MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--/style!--[if gte mso 9]xml
o:shapedefaults v:ext=3Dedit spidmax=3D1026 /
/xml![endif]--!--[if gte mso 9]xml
o:shapelayout v:ext=3Dedit
o:idmap v:ext=3Dedit data=3D1 /
/o:shapelayout/xml![endif]--/headbody lang=3DEN-US link=3Dblue =
vlink=3Dpurplediv class=3DWordSection1p class=3DMsoNormalI#8217;m =
unable to build the test cases in 1.3.x (both rc2 and the lastest =
snapshot) because of a trapped signal in fluid when trying to build code =
from fast_slow.fl. Using gcc 4.4.5 and the sezero toolchain of mingw64. =
o:p/o:p/pp class=3DMsoNormalo:pnbsp;/o:p/pp =
class=3DMsoNormalI can start up fluid, however it crashes when =
attempting to load .fl files (e.g. test/CubeViewUI.fl). Other FLTK test =
apps do run (checkers, Sudoku, et. al.). o:p/o:p/pp =
class=3DMsoNormalo:pnbsp;/o:p/pp class=3DMsoNormalI read that =
1.1.x would not support 64 bit, and that I should be using 1.3.x. I =
configured with and without --enable-threads. Are there special options =
to build 64 correctly under MinGW?o:p/o:p/pp =
class=3DMsoNormalo:pnbsp;/o:p/pp =
class=3DMsoNormalThanks,o:p/o:p/pp =
class=3DMsoNormalDano:p/o:p/p/div/body/html
--_=_NextPart_001_01CBACAE.26131AD8--
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2504: HAVE_CAIRO macro in installed header
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2504 Version: 1.3-current I agree that this seems like a sensible move, i.e. putting the HAVE_CAIRO macro inside a fltk namespace by changing its name to be fltk specific, e.g. FLTK_HAVE_CAIRO. Note that there is also a USE_CAIRO macro that ought to be similarly changed to FLTK_USE_CAIRO (or whatever we agree is the appropriate FL specific naming...) A very quick (and probably wrong!) scan with grep suggests that at least the following files would need to be checked for these macros: ./cairo/Fl_Cairo.cxx ./CMakeLists.txt ./config.h ./configh.cmake.in ./configh.in ./configure ./configure.in ./documentation/Doxybook ./documentation/Doxyfile ./FL/Fl.H ./FL/Fl_Cairo.H ./FL/Fl_Cairo_Window.H ./fluid/CMakeLists.txt ./ide/VisualC2008/*.vcproj ./ide/VisualC2008/config.h ./ide/VisualC2010/*.vcxproj ./ide/VisualC2010/config.h ./README.Cairo.txt ./test/cairo_test.cxx ./test/CMakeLists.txt Though I may have missed a few. We'd need to regenerate the PDF as well, since it also references these macros too. Link: http://www.fltk.org/str.php?L2504 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 #2504: HAVE_CAIRO macro in installed header
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2504 Version: 1.3-current Yup, looks like I did miss a few USE_CAIRO cases: ./src/Fl.cxx ./src/Fl_cocoa.mm ./src/Fl_Double_Window.cxx ./src/Fl_mac.cxx ./src/Fl_Menu_Window.cxx ./src/Fl_Overlay_Window.cxx ./src/Fl_Window.cxx ./src/Fl_x.cxx Oh well - there are probably more, of course! Link: http://www.fltk.org/str.php?L2504 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2397: [1.3.x] scrolling an image leaves digital garbage behind
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2397 Version: 1.3-current Greg, Testing this on may old ubuntu laptop (I'm on the road again...) running 8.04, this is no fault found - seems to be working fine for me. Though - the first line of you test program has a typo; how do you spell stdio again? One thing - the dependency tracking in the fltk-1.3 build seems to be hosed a bit at present; I think some of the recent refactoring and changing of source file names has not been fully reflected in the Makefile dependencies or something. I found this when a known good application crashed weirdly following a svn up of the fltk libs. A make clean of the fltk tree fixed it - hence my suspicion that the dependency tracking is hosed. Does a make clean and rebuild change anything for you? -- Ian Link: http://www.fltk.org/str.php?L2397 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
