Re: [fltk.bugs] [HIGH] STR #2946: PNG not loaded
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2946 Version: 1.3.2 So your app is compiled and linked with different png libraries. The FLTK libpng is 1.5.10, so I assume that your installed library is 1.6.1. There are two choices: (1) Let FLTK find the installed lib by configuring w/o --enable-localpng, but this might not work, because the internal code may not be compatible with the newer installed library. If it works, however, I'd recommend this one. (2) Use the FLTK PNG *header* files when *compiling* your app. You may have to tweak some include statements, however, and I can't tell you how, since this may be something in your app. Or something like this. BTW: this is not a FLTK bug, but more a user question about linking with the correct libs. Please ask further questions in fltk.general. This STR will be closed soon... Link: http://www.fltk.org/str.php?L2946 Version: 1.3.2 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2946: PNG not loaded
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2946 Version: 1.3.2 No problem, sometimes you don't know, but generally it's better to ask in fltk.general first. Closing this now. Link: http://www.fltk.org/str.php?L2946 Version: 1.3.2 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2946: PNG not loaded
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2946 Version: 1.3.2 Fix Version: 1.3.2 Link: http://www.fltk.org/str.php?L2946 Version: 1.3.2 Fix Version: 1.3.2 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] svn access / fltk.org changeover?
On 10.04.2013 18:51, Greg Ercolano wrote: On 04/10/13 00:01, Duncan Gibson wrote: and I no longer remember my subversion access password] FWIW, I believe there's a process for resetting your password at the right hand side of the login page: http://fltk.org/login.php Thanks for the pointer, Greg That's how I revitalized access from this, my work, address. However, I don't remember my subversion access password [from home] being the same as my mailing list / login account, but I could be wrong. Ah, could be. AFAIK, I don't think regular devs can manage svn user access, or if there is a way I don't know it. Mike (and probably only Mike) can set developer status, and if you have dev. status, you also have write access to svn - if not automatically, then at least because Mike does it so. AFAIK. I do know back in Dec 2011 Mike announced the fltk.org site was being planned to move off easysw.com, and I think it was supposed to move to a site Torsten Giebl found called filemedia. Not sure that transfer happened, as IIRC filemedia required their logo be on our website's main page, e.g. http://www.syntheticsw.com/~wizard/tmp/fltkorg_top_banner.png ..and I don't see that mod currently. Unless I missed it, I don't think there was an announcement as to the changeover. I don't think that anything happened so far... I'm actually not sure now if Mike is still managing fltk.org on a new site pointed at by Torsten, or if Torsten is now managing things. Kinda curious who the main contact and emergency contact (hit by a bus scenario) is for fltk.org.. anyone know? Most of the data could probably be recovered with the nightly backups that the dev's can access and save somewhere - as long as the site still works, at least. But I don't know either, whether anyone else has direct access to the server. whois fltk.org now claims that Mike is the tech and admin person, and Carl Thompson is the registrant. I just checked: this was the same as of Dec. 2011. Expiration date is now Feb. 2014. Albrecht ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2934: probably user-error, but .c files in src/fltk3png cannot find pngpriv.h
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2934 Version: 3.0-feature Thanks for the report, your testing, and for your confirmation. As said before, FLTK 3 is still under development, and the developers usually don't install the compiled version. The problem with png seems to be caused by not finding the correct libs/paths during configure. The default for the png library should be to use the system libs if available, but use the built-in version, if the system libs are not available. However, you'd need to install appropriate dev packages, if you want to use the system libs. But something appears not to work as intended. We'll take a look at this later, hence I'm leaving this STR open as a reminder, but won't fix anything now. Link: http://www.fltk.org/str.php?L2934 Version: 3.0-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2933: fltk-1.3.x-r9831 and Cygwin
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2933
Version: 1.3-current
Fix Version: 1.3.2
Okay, then your problem is solved ?
I still believe that it was only a problem of relics of previous builds in
the same source tree. You should really clean your sources and run
autoconf/configure from scratch, if you want to change the configuration.
Here is what I did with your configure commands as posted in Cygwin.tbz:
$ make distclean
=== cleaning jpeg ===
=== cleaning png ===
=== cleaning src ===
=== cleaning fluid ===
=== cleaning test ===
=== cleaning documentation ===
$ autoconf -f
$ cat str/Cygwin/error/Configure.fltk13
#! /bin/bash
# do_configure:
./configure \
--enable-cygwin \
--prefix=/usr/local/fltk13 \
--enable-shared \
--disable-x11 \
--enable-threads \
--enable-largefile \
--disable-localjpeg \
--disable-localpng \
--disable-localzlib
$ str/Cygwin/error/Configure.fltk13
checking for gcc... gcc
...
Configuration Summary
-
Directories: prefix=/usr/local/fltk13
bindir=${exec_prefix}/bin
datadir=${datarootdir}
datarootdir=${prefix}/share
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib
mandir=${datarootdir}/man
Graphics: GDI
Image Libraries: JPEG=Builtin
PNG=Builtin
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 fltk-config
config.status: creating fltk.spec
config.status: creating FL/Makefile
config.status: creating config.h
$ make
=== making jpeg ===
...
Note that JPEG and PNG fell back to using the builtin versions, since I
don't have the JPEG and PNG libs and/or headers installed.
This ran to completion w/o warnings or errors. You can view the full log
in the attached file:
http://www.fltk.org/strfiles/2933/str-2933_cygwin_log.txt
I'd appreciate if you could confirm that it works for you as well with the
given commands.
I consider this STR resolved now, but waiting for feedback...
Link: http://www.fltk.org/str.php?L2933
Version: 1.3-current
Fix Version: 1.3.2
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2933: fltk-1.3.x-r9831 and Cygwin
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2933 Version: 1.3-current This could be an autoconf/configure problem, or maybe your Cygwin version is not up-to-date. There has been an update for binutils lately, for instance. Basically, I have the same Cygwin version, and I made sure that mine is up-to-date: uname -a CYGWIN_NT-6.1-WOW64 as-w7 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin I tried different ./configure command lines, and all variants worked for me (after running commands like the following). Please try this: make distclean rm -rf autom4te.cache/ autoconf -f ./configure --enable-cygwin --enable-shared --disable-x11 The last line (./configure...) seems to be what you did, but I can only guess. If this doesn't work for you, please post your configure line and results, and show your error messages with a little more context (at least the last few successful compile commands before the error). BTW: your output looks strange, since you seem to compile for cygwin, but you also seem to have disabled X11 (because I see cygfltknox-1.3.dll in your error message) - however, this ought to work as well, and the command line given above works for me. Link: http://www.fltk.org/str.php?L2933 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 #2932: 1.3.2 tarball not packaged properly
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2932 Version: 1.3.2 Fix Version: 1.3.2 (r9829) Fixed in Subversion repository. Thanks for the heads-up, this is now fixed in the svn repo (r 9829). We'll need to take care of this for the next release. Unfortunately there are several places with version numbers that need to be adjusted manually for each release. :-( Some of them had already been fixed before, the remaining fixes were in src/Makefile for some library version numbers. We can't fix the released tarball, but this fix will be in the next weekly snapshot, which is due in about 9-10 hours from now, probably at 8 am UTC (1 am somewhere in the US). This is not exactly the released 1.3.2 version, but you can download it to get the correct version numbers. Link: http://www.fltk.org/str.php?L2932 Version: 1.3.2 Fix Version: 1.3.2 (r9829) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2932: 1.3.2 tarball not packaged properly
On 01.03.2013 01:04, Greg Ercolano wrote: On 02/28/13 15:24, Albrecht Schlosser wrote: We'll need to take care of this for the next release. Unfortunately there are several places with version numbers that need to be adjusted manually for each release. :-( We probably should have a checklist as part of the CMP, or similar document to describe the release process, so that we don't miss anything obvious. Greg, I started working on this. Please see for my posting in fltk.development, coming up soon... Albrecht ___ 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 Regarding ABI issues WRT (C++) fl_filename_list(), Michael wrote: I have tried to statically link code that use the new 'filename.H' against an older library and this fails because the parameter types of the C++ function do not exactly match. This is not the really the ABI problem we're talking about. If you compile with a new library (i.e. its header files), then this is NOT supposed to link and work correctly with an older library. The important part is the other way around: if you have an old program, linked dynamically against an older library (Windows DLL, U*X shared object), THEN it must still work with a newer shared library. This means that all previously existing functions/methods must still exist in the new library and be compatible. Michael continued: ... is it possible to overload the function declaration without breaking other things? I know that we have such overloaded functions/methods with different const-ness in some parameters. So, in theory, it should work if we kept the old non-const (C++) function name(s) and add another const-correct version, maybe as a pure C function (wasn't this another change you, Michael, did?). This could probably work, but I'm not absolutely sure. In this case the old function can simply call the new function, if this is possible (maybe by casting the arguments). Hint: a *test* could be to compile and _link_ a program dynamically with an old shared library and _run_ it (maybe on another system) with the new shared library. That's what typically happens if you have built your program on a Linux system with fltk 1.3.0, then you upgrade the system, and this installs fltk 1.3.3 (the next version, maybe with this patch). 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] [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
Added a patch file to replace the full source files in the uploaded tar
file. The patch is against current svn (r 9827). Although bigger than the
compressed tar file, I prefer the patch format.
The patch contains a few small changes WRT the tar file:
- copyright year adjusted (e.g. 1998-2010, 2013 - 1998-2013
- fixed one typo
Still testing, but patch looks good AFAICT. I'll post my test results with
Cygwin and other available systems later, but this can take some days due
to restricted test time. :-(
Link: http://www.fltk.org/str.php?L2931
Version: 1.3-currentIndex: FL/filename.H
===
--- FL/filename.H (revision 9827)
+++ FL/filename.H (working copy)
@@ -3,7 +3,7 @@
*
* Filename header file for the Fast Light Tool Kit (FLTK).
*
- * Copyright 1998-2010 by Bill Spitzak and others.
+ * Copyright 1998-2013 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
@@ -107,13 +107,15 @@
# endif /* __cplusplus */
# if !defined(FL_DOXYGEN)
-FL_EXPORT int fl_alphasort(struct dirent **, struct dirent **);
-FL_EXPORT int fl_casealphasort(struct dirent **, struct dirent **);
-FL_EXPORT int fl_casenumericsort(struct dirent **, struct dirent **);
-FL_EXPORT int fl_numericsort(struct dirent **, struct dirent **);
+/* Parameters changed to 'const struct dirent**' */
+FL_EXPORT int fl_alphasort(const struct dirent **, const struct dirent **);
+FL_EXPORT int fl_casealphasort(const struct dirent **, const struct dirent **);
+FL_EXPORT int fl_casenumericsort(const struct dirent **, const struct dirent
**);
+FL_EXPORT int fl_numericsort(const struct dirent **, const struct dirent **);
# endif
- typedef int (Fl_File_Sort_F)(struct dirent **, struct dirent **); /** File
sorting function. \see fl_filename_list() */
+ /* Changed to match POSIX.1-2008 compliant sort function like 'alphasort()'
*/
+ typedef int (Fl_File_Sort_F)(const struct dirent **, const struct dirent
**); /** File sorting function. \see fl_filename_list() */
# if defined(__cplusplus)
}
Index: src/filename_list.cxx
===
--- src/filename_list.cxx (revision 9827)
+++ src/filename_list.cxx (working copy)
@@ -3,7 +3,7 @@
//
// Filename list routines for the Fast Light Tool Kit (FLTK).
//
-// Copyright 1998-2010 by Bill Spitzak and others.
+// Copyright 1998-2013 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
@@ -28,17 +28,18 @@
extern C {
#ifndef HAVE_SCANDIR
- int fl_scandir (const char *dir, dirent ***namelist,
- int (*select)(dirent *),
- int (*compar)(dirent **, dirent **));
+ /* POSIX.1-2008 compliant prototype for own implementation of 'scandir()' */
+ int fl_scandir(const char *dir, struct dirent ***namelist,
+ int (*select)(const struct dirent *),
+ int (*compar)(const struct dirent **, const struct dirent
**));
#endif
}
-int fl_alphasort(struct dirent **a, struct dirent **b) {
+int fl_alphasort(const struct dirent **a, const struct dirent **b) {
return strcmp((*a)-d_name, (*b)-d_name);
}
-int fl_casealphasort(struct dirent **a, struct dirent **b) {
+int fl_casealphasort(const struct dirent **a, const struct dirent **b) {
return strcasecmp((*a)-d_name, (*b)-d_name);
}
@@ -72,8 +73,7 @@
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) {
+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
@@ -94,32 +94,29 @@
fl_utf8to_mb(d, dirlen, dirloc, dirlen + 1);
#endif
+ // We should not write 'dirent' here if we mean 'struct dirent' because the
+ // implicit 'struct' is only allowed with C++ and 'scandir()' is a C function
#ifndef HAVE_SCANDIR
- // This version is when we define our own scandir
+ // The system don't provide a usable implementation
+ // This is e.g. the case on SunOS 5.9 and older versions
int n = fl_scandir(dirloc, list, 0, sort);
-#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
Re: [fltk.bugs] [HIGH] STR #2928: Shortcuts not precessed correctly on MacOS
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 That's difficult to say... This is another kind of interference of making FLTK fully cross-platform and adhering to platform-specific standards. In my world ALT-letter doesn't produce text, and I can assume that our users are long accustomed to using these key combinations as shortcuts, as well as others may have used them (e.g. the OP). Currently we're not using MacOS, but this is planned for the future. So, I'd *like* to have ALT-letter as shortcuts on all platforms, but ... Just my 2 ct. 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] [MOD] STR #2911: Library can't be compiled under clang 3.1
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2911 Version: 1.3.2 Fix Version: 1.3.3 (r9750) Thanks for confirmation. I'm leaving this STR open as a reference so others can find it. At least for now... Link: http://www.fltk.org/str.php?L2911 Version: 1.3.2 Fix Version: 1.3.3 (r9750) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2911: Library can't be compiled under clang 3.1
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2911 Version: 1.3.2 Fix Version: 1.3.2 Thanks for the report, but this is already fixed in the Subversion repository. Could you please try a subversion download, or the patch posted in STR #2903 [1], or a newer snapshot [2]? [1] http://www.fltk.org/str.php?L2903 http://www.fltk.org/strfiles/2903/str_2903.patch [2] http://www.fltk.org/articles.php?L1270 or later ... Link: http://www.fltk.org/str.php?L2911 Version: 1.3.2 Fix Version: 1.3.2 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2911: Library can't be compiled under clang 3.1
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2911 Version: 1.3.2 Fix Version: 1.3.3 (r9750) Correction: Fix Version will be 1.3.3 (was 1.3.2). Link: http://www.fltk.org/str.php?L2911 Version: 1.3.2 Fix Version: 1.3.3 (r9750) ___ 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
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2705 Version: 1.3-current Fix Version: 1.3.2 This STR has not been updated by the submitter for two or more weeks and has been closed as required by the FLTK Configuration Management Plan. If the issue still requires resolution, please re-submit a new STR. Link: http://www.fltk.org/str.php?L2705 Version: 1.3-current Fix Version: 1.3.2 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #1679: Borderless windows on WIN32 do not appear on the taskbar
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1679 Version: 1.4-feature FWIW, meanwhile (in FLTK 1.3 and later) we have: int Fl_Window::menu_window() that can be used to test whether a window is a menu (window). This would simplify the proposed patch and get rid of having to set a specific window class for menus - although that could be useful as well, maybe... Link: http://www.fltk.org/str.php?L1679 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 #2903: Fl_X accesses protected member of Fl_Widget
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2903 Version: 1.3.2 Fix Version: 1.3.3 (r9750) Fixed in 3.0 as well (svn r 9751). Link: http://www.fltk.org/str.php?L2903 Version: 1.3.2 Fix Version: 1.3.3 (r9750) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2903: Fl_X accesses protected member of Fl_Widget
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2903
Version: 1.3.2
Hmm, you marked Scope 2 (Specific to an operating system), but didn't tell
us which one...
Anyway, according to the line numbers, this must be U*X, Linux, OS X ?
Thanks for the patch, but that's probably not what we want. The proper way
should be to use fullscreen_active() instead of using the flag directly.
Could you please try the attached patch instead ? (And please don't forget
to revert your changes). Does this work with clang?
Link: http://www.fltk.org/str.php?L2903
Version: 1.3.2Index: src/Fl_x.cxx
===
--- src/Fl_x.cxx(revision 9749)
+++ src/Fl_x.cxx(working copy)
@@ -1873,7 +1873,7 @@
// since we do not want save_under, do not want to turn off the
// border, and cannot grab without an existing window. Besides,
// there is no clear_override().
- if (win-flags() Fl_Widget::FULLSCREEN !Fl_X::ewmh_supported()) {
+ if (win-fullscreen_active() !Fl_X::ewmh_supported()) {
attr.override_redirect = 1;
mask |= CWOverrideRedirect;
Fl::screen_xywh(X, Y, W, H, X, Y, W, H);
@@ -1940,7 +1940,7 @@
}
// If asked for, create fullscreen
-if (win-flags() Fl_Widget::FULLSCREEN Fl_X::ewmh_supported()) {
+if (win-fullscreen_active() Fl_X::ewmh_supported()) {
XChangeProperty (fl_display, xp-xid, fl_NET_WM_STATE, XA_ATOM, 32,
PropModeAppend, (unsigned char*)
fl_NET_WM_STATE_FULLSCREEN, 1);
}
@@ -1984,7 +1984,7 @@
}
// non-EWMH fullscreen case, need grab
- if (win-flags() Fl_Widget::FULLSCREEN !Fl_X::ewmh_supported()) {
+ if (win-fullscreen_active() !Fl_X::ewmh_supported()) {
XGrabKeyboard(fl_display, xp-xid, 1, GrabModeAsync, GrabModeAsync,
fl_event_time);
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2903: Fl_X accesses protected member of Fl_Widget
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2903 Version: 1.3.2 Fix Version: 1.3.3 (r9750) Fixed in Subversion repository. Thanks for quick confirmation, this is now in svn r 9750. Link: http://www.fltk.org/str.php?L2903 Version: 1.3.2 Fix Version: 1.3.3 (r9750) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2900: ScrollGroup bug in fltk-3.0
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2900 Version: 3.0 See also original posting in fltk.bugs: http://www.fltk.org/newsgroups.php?gfltk.bugs+v:11981 with test code and diff and maybe follow-up's here: http://www.fltk.org/newsgroups.php?gfltk.bugs+Q%22ScrollGroup+bug+in+fltk-3.0%22 Link: http://www.fltk.org/str.php?L2900 Version: 3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2901: Fl_Browser format codes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2901 Version: 1.3-current @1: 'N' format code undocumented: should be added to docs. @2: literal '@': Hmm, I don't know what it's exactly intended to do, but the while loop started some lines above has *str != format_char(), so this is in fact format_char() != '@' followed by '@' ? Just wanted to add my *observation*, w/o further analysis. What is it intended to do there, and is that documented correctly? Or am I missing something? Link: http://www.fltk.org/str.php?L2901 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 #2901: Fl_Browser format codes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2901 Version: 1.3-current The documentation is ... ambiguous at best: http://www.fltk.org/doc-1.3/classFl__Browser.html#a6b4d3525d8d9fccfc748d824b39f250b '@@' Print rest of line starting with '@' Obviously the first '@' is meant to represent the current format_char(), but the second '@'? Literal '@' or also format_char()? I tend to read it as the latter, but ... (a) then the code posted above in the while loop doesn't make sense (b) how to represent a single @ sign and continue parsing format_char()? Is this not possible? At least I can't find it unambiguously in the docs. Or does Print rest of line mean Print with parsing '@' signs (format_char()'s) ??? Still confused ... It's not clear to me whether the code is correct at all, whatever is documented or not. Does anybody know what is really meant in the docs? Link: http://www.fltk.org/str.php?L2901 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] ScrollGroup bug in fltk-3.0
On 05.12.2012 19:23, w. szukalski wrote: I have by-passed that bug: sub_win = new fltk3::Window(x, y, w, h); subwin-begin(); scroll = new fltk3::ScrollGroup(0, 0, w, h); High costs. winfried Winfried, many, many thanks for this update. Otherwise your bug report might have been lost... Looking back to your original post of Oct 24, I can see that you did a good analysis of what happened and when. This would be very valuable as a source for a potential fix. Your workaround is good for now (although, as you mentioned, with some costs - adding a subwindow), but this bug *should* be fixed eventually. Unfortunately 3.0 is work in progress, and the person who knows best what's going on is Matthias (Matt) who did the change in svn r 9560, as you found out. It looks as if this was an effort to make coordinates in fltk 3 zero- based, as they should be (outside the 1.x compatibility layer), but something went wrong with it... Could you please file a bug report (STR) for FLTK 3.0 with the information you found out, so that we (in this case probably Matthias) can take care of it later. And please attach your demo program together with an appropriate image. This would be very helpful. http://www.fltk.org/str.php Thanks for your efforts. Albrecht Following the advice of Greg Ercolano I have created the directories fltk-3.0.x-r9366 and fltk-3.0.x-r9367. Then I have copied the contents of fltk-3.0.x-r9701 into these directories and called 'make distclean'. Then in fltk-3.0.x-r9366 I have called 'svn update -r9366'; and in fltk-3.0.x-r9367 I have called 'svn update -r9367'. Then I have first compiled and installed fltk-3.0.x-r9366, then fltk-3.0.x-r9367. Between fltk-3.0.x-r9366 and fltk-3.0.x-r9367 a bug has been inserted into ScrollGroup. The bug does allow only an origin of (0,0) for a ScrollGroup. The attached file 'group.cxx' shows that with fltk-3.0.x-r9366 a BMP file can be scrolled; but with fltk-3.0.x-r9367 scrolling the BMP file shows a broken image. My BMP file has a size of 720x486 to allow scrolling. winfried ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2891: Fl_Gl_Window does not draw when using FL_DLL
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2891 Version: 1.3-current Yes, please attach a simple, but complete sample program, so that we can compile and test it. Also, please add more info about your build system. Are you using the Windows IDE files, MinGW, CMake, or what type of build - both when building the FLTK DLL version and your application (the sample program)? And, BTW, you're right that a real bug report is better, so that we can track it. Posting directly to fltk.bug is discouraged. Link: http://www.fltk.org/str.php?L2891 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 This one ought to be fixed since July 24, 2012 (svn r9637 in fltk 1.3, svn r 9638 in fltk 3.0). Mathieu, can you confirm 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 #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 Pending] Link: http://www.fltk.org/str.php?L2873 Version: 1.3-current I assume the last sentence has some typos: all of x/y/d are = 0 should read any of w/h/d is/are = 0 ? .. or similar. And to the question: yes, I think they should all behave the same, since they can all be loaded by Fl_Shared_Image transparently (i.e. independent of the particular image type). 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] [MOD] 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 Changed priority to 3: Moderate. 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] [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 Hmm, I believe this is not a bug. As you cited from the docs, If the image has loaded correctly, w(), h(), and d() should return values greater zero, this doesn't mean that ALL values must be zero if it failed. The correct negation of this condition is: If the image has NOT loaded correctly, AT LEAST ONE OF w(), h(), and d() should return a value (less than or) equal (to) zero. Maybe it would be better to document the latter case, or even only that the image has not loaded correctly, if either w() or h() are zero, which means in fact a zero size image - d() wouldn't be relevant, anyway. Close STR, update docs accordingly? Greg, or anybody else? 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 #2726: Debug assertion failed window in Fluid.
[STR Closed w/o Resolution] Link: http://www.fltk.org/str.php?L2726 Version: 1.3-current Fix Version: 1.3-current (r9635) Fixed in Subversion repository. Confirmed by OP in fltk.bugs, so closing this STR now (again). Link: http://www.fltk.org/str.php?L2726 Version: 1.3-current Fix Version: 1.3-current (r9635) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2726: Debug assertion failed window in Fluid.
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2726 Version: 1.3-current Fix Version: 1.3-current (r9635) Sorry, wrong status. Now corrected: Closed w/Resolution. Link: http://www.fltk.org/str.php?L2726 Version: 1.3-current Fix Version: 1.3-current (r9635) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2726: Debug assertion failed window inFluid.
On 14.07.2012 23:05, Nikita Egorov wrote: Reopened on request of OP. It seems clear to me that the attempted fix in r 9363 doesn't solve the OP's problem, since it would preserve *negative* char (int) values. Using both casts looks appropriate to make sure char codes 127 are positive int's. Nikita, could you please confirm that svn r9635 solves the problem? Leaving the STR open for confirmation... Hi, Albrecht. At the moment fluid works very well. Thanks for confirmation. But I don't understand why you had not removed the (int). isspace((unsigned char)*n)) is enough! (1) to be absolutely sure that NO compiler would issue a warning. (2) because I don't know why EXACTLY Fabien changed the existing (unsigned char) cast to (int). (3) to document that we REALLY want both casts in sequence. Compilers (I tested VC++, mingw-gcc, ubuntu-gcc) cast to type int in any case and they print no warning because it's absolutely safe. We only say to compiler: Don't extend the sign bit when you will convert our character to int. Yes, I also think that it would have been enough, but see above. BTW, since this is only a compiler information, this additional cast doesn't add any runtime (performance) penalty, so I think that it is okay anyway. I'm going to close the STR now... -- Albrecht ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2726: Debug assertion failed window in Fluid.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2726 Version: 1.3-current Fix Version: 1.3-current (r9635) Reopened on request of OP. It seems clear to me that the attempted fix in r 9363 doesn't solve the OP's problem, since it would preserve *negative* char (int) values. Using both casts looks appropriate to make sure char codes 127 are positive int's. Nikita, could you please confirm that svn r9635 solves the problem? Leaving the STR open for confirmation... Link: http://www.fltk.org/str.php?L2726 Version: 1.3-current Fix Version: 1.3-current (r9635) ___ 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
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 I vote +1 for hiding platform differences, i.e. applying the patch and providing correct UTF-8 strings for file://... URI's in DND operations. BTW.: This STR looks more like a RFE now than a STR with priority 3, I suggest to re-classify, but I leave this to you, Manolo. The question that should be considered is if this should also be extended to http[s]:, ftp:, and maybe more URL schemes. After a little thinking about it, I wouldn't do it, because these URL types are usually given to a browser or other software that can handle URL-encoded names. 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
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
I can confirm the same behavior with Ubuntu, but that's a Debian
derivative, anyway.
To the patch (I didn't test it, just reading...):
+ char *last = q + bytesread;
+ while (q = last) {
Doesn't last point behind the last character of the string here (probably
the terminating NUL byte, if any? So the 2nd line should probably read:
+ while (q last) {
And, since there must be at least 2 more characters after the '%'
character, this could maybe be (to optimize a little):
+ while (q last-2) {
Then:
+ memmove(q+1, q+3, last - (q+2));
Does this also move the trailing NUL byte? I can't tell right now...
Other than that, I don't know about other window managers or OS's. Maybe I
could test with a Fedora system later, but I'd guess the main difference
could be the WM...
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 #2836: Fl_Window::copy_label() misbehaviour in special case
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2836 Version: 1.3-current Fix Version: 1.3.1 (r9452) Fixed in Subversion repository. Yes, this call is not only redundant, but also does a lot of unnecessary work, so I removed it. Thanks for pointing this out. And yes, my intention was also to clean up the code. FTR: Fixed in FLTK 1.3 (r9452) and FLTK 3.0 (r9453). Link: http://www.fltk.org/str.php?L2836 Version: 1.3-current Fix Version: 1.3.1 (r9452) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2836: Fl_Window::copy_label() misbehaviour in special case
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2836 Version: 1.3-current Yes, this is definitely a bug, thanks for the report. I'll probably fix it different than your patch though, since your patch wouldn't fix the unnecessary strdup() that the old code had anyway. Fl_Widget::label() seems to do it _right_ since it doesn't assign the same label again if it had been copied with copy_label() before. Link: http://www.fltk.org/str.php?L2836 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 #2836: Fl_Window::copy_label() misbehaviour in special case
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2836 Version: 1.3-current Fix Version: 1.3.1 (r9443) I could reproduce the bug on Windows and Linux, using the posted demo program. Valgrind (Linux) showed Invalid read errors. The fix doesn't call strdup() if the old and new labels are the same (i.e. copy_label() is called with the old label() value, if and only if it is already a copied label). This modification has been done, so that it is compatible with Fl_Widget::label() and to avoid unnecessary strdup()'s. I also did some code cleanup to avoid duplicate code. Tested with valgrind before and after the change, there are no Invalid read errors anymore, and there are no (new) memory leaks. Link: http://www.fltk.org/str.php?L2836 Version: 1.3-current Fix Version: 1.3.1 (r9443) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2836: Fl_Window::copy_label() misbehaviour in special case
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2836
Version: 1.3-current
Fix Version: 1.3.1 (r9443)
Fixed in Subversion repository.
Please test new subversion release (r 9443) or use attached patch file
str_2836_copy_label.patch to verify and report, if this solves the issue.
Other developers and testers are welcome to test and report if there are
any side effects.
Link: http://www.fltk.org/str.php?L2836
Version: 1.3-current
Fix Version: 1.3.1 (r9443)Index: src/Fl_Window.cxx
===
--- src/Fl_Window.cxx (revision 9442)
+++ src/Fl_Window.cxx (working copy)
@@ -139,22 +139,16 @@
}
void Fl_Window::label(const char *name) {
- label(name, iconlabel());
+ label(name, iconlabel());// platform dependent
}
void Fl_Window::copy_label(const char *a) {
- if (flags() COPIED_LABEL) {
-free((void *)label());
-clear_flag(COPIED_LABEL);
- }
- if (a) a = strdup(a);
- label(a, iconlabel());
- set_flag(COPIED_LABEL);
+ Fl_Widget::copy_label(a);
+ label(label(), iconlabel()); // platform dependent
}
-
void Fl_Window::iconlabel(const char *iname) {
- label(label(), iname);
+ label(label(), iname); // platform dependent
}
// the Fl::atclose pointer is provided for back compatibility. You
Index: src/Fl_Widget.cxx
===
--- src/Fl_Widget.cxx (revision 9442)
+++ src/Fl_Widget.cxx (working copy)
@@ -303,13 +303,14 @@
void
Fl_Widget::copy_label(const char *a) {
- if (flags() COPIED_LABEL) free((void *)(label_.value));
+ // reassigning a copied label remains the same copied label
+ if ((flags() COPIED_LABEL) (label_.value == a))
+return;
if (a) {
+label(strdup(a));
set_flag(COPIED_LABEL);
-label_.value=strdup(a);
} else {
-clear_flag(COPIED_LABEL);
-label_.value=(char *)0;
+label(0);
}
redraw_label();
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2837: Window doesn't show the correct title (label)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2837 Version: 3.0 FLTK 3 Windows don't show the correct window title (the Window's label()). Tests with the demo program of STR #2836 [1] show different Window titles on Windows and Linux, but none of them shows the correct title. All tests done with svn r9445. Expected result (showing test program output that should also be visible in the window title), done with FLTK 1.3 on Win/Linux: title: 'this is the title label' (23) title: 'this is the title label' (23) Result on Windows with FLTK 3: title: 'FLTK' (4) title: 'FLTK' (4) Result on Linux with FLTK 3: title: 'de_DE.utf8' (10) title: 'de_DE.utf8' (10) Note that this is a FLTK 1 program in compatibility mode, and it compiles flawlessly. Test programs in FLTK 3's test directory show FLTK on both Windows and Linux. [1] http://www.fltk.org/strfiles/2836/copy_same_label_bug_v2.cxx Link: http://www.fltk.org/str.php?L2837 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
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2819 Version: 1.3-current Fix Version: 1.3.1 (r9382) Fixed in FLTK 3 as well (svn rev. 9446). Closing this STR now. Link: http://www.fltk.org/str.php?L2819 Version: 1.3-current Fix Version: 1.3.1 (r9382) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] libfltk_images to not link (png_set_longjmp_fn not found)
On 23.04.2012 16:04, Joerg wrote: I have the same issue as in this already closed STR: #2805: png_set_longjmp_fn not found inmac lion (xcode 4) The difference is, I am using NetBSD and the current 1.3.x r9382. So, the issue is not fixed by switching to the current libpng 1.5.10 and the error is not platform dependent. It compiles and links if I comment out the call to setjmp() in FlPNG_Image::load_png_() in Fl_PNG_Image.cxx. Are you building with the bundled libpng, or are you maybe using the system libpng? If the latter, which version is this one? Albrecht ___ 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
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 Fix Version: 1.3.1 (r9211) Yup, closing. Thanks for testing. Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 Fix Version: 1.3.1 (r9211) ___ 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)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2805 Version: 1.3.0 I can only guess - maybe you're using another version of libpng than what our FLTK build expects. Please help us by answering these questions: - what compiler and version are you using? Is it MinGW gcc (it looks so from your posted error message, but I don't know for sure). - do you use a supplied (installed) libpng? If yes, which version? - how did you configure your FLTK build? Now one suggestion: try to configure FLTK with: ./configure --enable-localpng --enable-localjpeg --enable-localzlib or at least with --enable-localpng. Does this help? 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 #2820: [MICROSOFT] error while building under VS 2005 Express
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2820 Version: 1.3-current Greg, which svn release was this? This should already be fixed... ... see commit log of rev 9325 and a few mods later, the latest relevant commit being 9331 or so. Link: http://www.fltk.org/str.php?L2820 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
Manolo and Ian, thanks for testing and your confirmation. AFAICT there is
no single MinGW version, since it consists of many packages, and MSYS is
still at version 1.0, so...
Just for completeness, may I ask both of you to compile the attached
program mingw.c and run the following commands?
$ uname -a gcc --version gcc -o mingw mingw.c ./mingw
This one line is all to compile and run the program and get more info.
My output is:
$ uname -a gcc --version gcc -o mingw mingw.c ./mingw
MINGW32_NT-6.1 MY-PC 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 Msys
gcc.exe (GCC) 4.6.2
Copyright (C) 2011 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.17
__MINGW32_VERSION = 3.20
I ran this on Windows 7, and I think that 1.0.16... is the MSYS DLL
version (maybe).
After your tests I'm confident that the patch is okay to apply, but I'd
like to have the used versions documented with this STR. Thanks.
Link: http://www.fltk.org/str.php?L2819
Version: 1.3-current#include w32api.h
#include stdio.h
int main(int argc, char **argv) {
printf (__W32API_VERSION = %5.2f\n,__W32API_VERSION);
printf (__MINGW32_VERSION = %5.2f\n,__MINGW32_VERSION);
return 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 Thanks, this looks like a really ancient version. Note that I've been lazy when formatting the output of mingw.c, so your version numbers appear to be 3.6 and 3.9, as opposed to my versions 3.17 and 3.20, resp.. Your and Ian's compiler versions are the same, so I expect a similar old w32api and mingw version number from Ian. This seems to indicate that we're on the safe side with the patch... 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
[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
The following simple test program can't be compiled with a current MinGW
installation:
#include dirent.h
#include FL/Fl_File_Chooser.H
int main(int argc, char **argv) {
return 0;
}
Error message:
$ fltk-config --compile dirent.cxx
g++ -I/fltk-1.3 -I/fltk-1.3/png -I/fltk-1.3/zlib -I/fltk-1.3/jpeg
-mwindows -DWIN32 -DUSE_OPENGL32 -DFL_ABI_OVERRIDE=10302
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -o 'dirent' 'dirent.cxx'
-mwindows /fltk-1.3/lib/libfltk.a -lole32 -luuid -lcomctl32
In file included from J:/fltk-1.3/FL/Fl_File_Browser.H:31:0,
from dirent.cxx:2:
J:/fltk-1.3/FL/filename.H:75:8: error: redefinition of 'struct dirent'
c:\mingw\bin\../lib/gcc/mingw32/4.6.1/../../../../include/dirent.h:22:8:
error: previous definition of 'struct dirent'
The problem is that FLTK believes that MinGW doesn't have dirent.h and
adds an own definition of struct dirent.
The suggested patch would be to #include dirent.h instead if the
compilation is for MinGW (see attached file dirent.patch).
Could someone with an older MinGW version (Ian, maybe?) please verify:
(1) HAVE_DIRENT_H is definede as 1 in config.h
(2) the test program shown above compiles with the applied patch
(and shows errors w/o the patch).
If this could be confirmed, I'd commit the patch...
Link: http://www.fltk.org/str.php?L2819
Version: 1.3-currentIndex: FL/filename.H
===
--- FL/filename.H (revision 9329)
+++ FL/filename.H (working copy)
@@ -70,7 +70,7 @@
# endif /* __cplusplus */
-# if defined(WIN32) !defined(__CYGWIN__) !defined(__WATCOMC__)
+# if defined(WIN32) !defined(__MINGW32__) !defined(__CYGWIN__)
!defined(__WATCOMC__)
struct dirent {char d_name[1];};
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] Undefined symbols for architecture x86_64: error on Xcode
On 21.03.2012 15:51, Bubba wrote: Hi, I am using Xcode 4 and trying to set up FLTK 1.3.0 to run Bjarne Stroustrup's Chapter 12 FLTK Demo at the end of the chapter. I keep getting the following error when compiling, and have no idea where to go. I have an idea it might have to do with the linker flags, but I don't know what flag to add and where... Here's the error: Undefined symbols for architecture x86_64: Fl_JPEG_Image::Fl_JPEG_Image(char const*), referenced from: Graph_lib::Image::Image(Point, String, Graph_lib::Suffix::Encoding) in Graph.o Fl_GIF_Image::Fl_GIF_Image(char const*), referenced from: Graph_lib::Image::Image(Point, String, Graph_lib::Suffix::Encoding) in Graph.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Please don't post directly to fltk.bugs, this is reserved for FLTK's bug tracking system (www.fltk.org/str.php). Your post is more like a general user question, so you should use fltk.general for this. Anyway, trying to answer your question: Either you didn't include -lfltk_images (the image libraries), or (ISTR) you could try to switch the compiler settings from clang to gcc/g++. If this doesn't help, please ask again in fltk.general. Albrecht ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2777: Fltk3 doesn't apply font to IME.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2777 Version: 3.0 FLTK 3 is a development (pre-beta) version, and you should not yet use it for real work. Thanks for the patch anyway, it will be considered... Please see also this reply in fltk.development: http://www.fltk.org/newsgroups.php?gfltk.development+v:13142 Link: http://www.fltk.org/str.php?L2777 Version: 3.0 ___ 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
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2781 Version: 1.3.0 Fix Version: None This STR has not been updated by the submitter for two or more weeks and has been closed as required by the FLTK Configuration Management Plan. If the issue still requires resolution, please re-submit a new STR. Yes, this must be specific to the OP's setup. Closing this now, since the OP didn'r reply for more than 3 weeks. Link: http://www.fltk.org/str.php?L2781 Version: 1.3.0 Fix Version: None ___ 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 Pending] Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 Fix Version: 1.3.1 (r9211) Fixed in Subversion repository. Now it is. Sorry for the long delay, I've been too busy... I removed the two statements setting and resetting the line style, since this was not necessary to fix STR #2615. I tested this with the old test case on Linux, and I couldn't see any regressions. I also tested the new version on Windows with the mentioned test case (test/buttons.cxx and resizing the window), and everything looks well again on Windows. Please test, if you can see any other effects, I'll leave the STR open for now to await feedback. Thanks. Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 Fix Version: 1.3.1 (r9211) ___ 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 Pending] Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 Fix Version: 1.3.1 (r9211) Note: fixed in fltk 3 as well (svn -r 9212). Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 Fix Version: 1.3.1 (r9211) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2747: Fl_Input_::maximum_size(int m) doesn't work as expected with foreign chars
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2747 Version: 1.3-current Fix Version: 1.3.1 (r9196) Fixed in Subversion repository. Thanks for the report. This was a hangover from FLTK 1.1 (not yet fully ported to UTF-8 characters). Please confirm, whether svn r 9196 fixes the problem for you. I tested it successfully with different character strings, including 'â¬' (3 bytes in UTF-8) and your Swedish examples (2 bytes each), and also with invalid UTF-8 characters (sequences), e.g. \x80 = ⬠(Windows CP 1252). Link: http://www.fltk.org/str.php?L2747 Version: 1.3-current Fix Version: 1.3.1 (r9196) ___ 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
Meanwhile I installed Ubuntu 11.10, and I can reproduce the error message,
but only if I add a *bad* preprocessor macro, as can be seen in the
attached test file str_2781.cxx (see uncomment...).
Thus, it looks as if an incompatible header file or something in your own
code is introducing the error, but not FLTK's header files or code.
This is from my dirent.h header file:
$ cat -n /usr/include/dirent.h | grep -4 ^ 100
96 #ifdef __USE_BSD
97 /* File types for `d_type'. */
98 enum
99{
100 DT_UNKNOWN = 0,
101 # define DT_UNKNOWN DT_UNKNOWN
102 DT_FIFO = 1,
103 # define DT_FIFODT_FIFO
104 DT_CHR = 2,
See line #100 for the referenced error line.
One possibility to get the shown error message is to define DT_UNKNOWN as
a numeric constant, probably 0. Does anything in your code do this?
In fact, if I uncomment #define DT_UNKNOWN 0 in the attached test file,
I get this:
$ /path/to/fltk-1.3/fltk-config --compile str_2781.cxx
# g++ command line removed
In file included from /path/to/fltk-1.3/FL/filename.H:98:0,
from /path/to/fltk-1.3/FL/Fl_File_Browser.H:31,
from /path/to/fltk-1.3/FL/Fl_File_Chooser.H:34,
from str_2781.cxx:10:
/usr/include/dirent.h:100:5: error: expected identifier before numeric
constant
/usr/include/dirent.h:100:5: error: expected â}â before numeric
constant
/usr/include/dirent.h:100:5: error: expected unqualified-id before numeric
constant
In file included from /path/to/fltk-1.3/FL/filename.H:98:0,
from /path/to/fltk-1.3/FL/Fl_File_Browser.H:31,
from /path/to/fltk-1.3/FL/Fl_File_Chooser.H:34,
from str_2781.cxx:10:
/usr/include/dirent.h:362:1: error: expected declaration before â}â
token
--- snip ---
... which is the same as your error messages (with slightly different line
numbers, due to a newer FLTK version).
Please check your code and report, if this is not the problem, and if it
isn't please post a minimal code example (like mine) that shows the error.
Otherwise this STR will be closed in a few days.
Please report also, if this information solves your problems, so that we
can close the STR.
Link: http://www.fltk.org/str.php?L2781
Version: 1.3.0//
// Test for STR #2781
//
// uncomment the following statement to get the reported error messages:
// #define DT_UNKNOWN 0
#include FL/Fl_File_Chooser.H
int main(int argc, char ** argv) {
return 0;
}
___
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 New] Link: http://www.fltk.org/str.php?L2781 Version: 1.3.0 I currently don't have Ubuntu 11.10 installed, and so I can't help much with the system header files. It would maybe help, if you could post the relevant part(s) of your /usr/include/dirent.h (at, before, around line 100, as pointed out by the error message). It is also possible, that you included some other files or defined some macros in your main file or your file OPENGL_viewer.h that lead to conflicts with other macros. Please try to reduce your problem to one complete and compileable source file that includes only fltk-specific header files to see if the problem persists. If it does, please post this source file to this STR so that we can see it and test. I'd also be willing to install Ubuntu 11.10 to reproduce the problem, but this will take some time - and you should confirm that your problem persists with a short demo program before. Unfortunately problems with dirent.h etc. are common, due to changes and incompatibilities in the system libraries / header files. Maybe this is another instance of incompatible changes... 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] [MOD] STR #2778: fldiff can't do svn diffs with svn 1.7.x in subdirectories
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2778 Version: -current Link: http://www.fltk.org/str.php?L2778 Version: -current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] Bugs in some of the test sample programs
On 11.11.2011 05:37, Long To wrote: It seems that the following programs in the test directory: cube.cxx, fractals.cxx, and fullscreen.cxx have a timing bug. The executables created from visual studio 2010 professional on a windows 7 64 bit crashed on exit when either the button 'quit' or 'exit' is pressed. (Although programs exit properly when windows close box is pressed.) Thanks for the report, but ... I just ran a fresh build using VisualC 2010 Express (I don't have the professional version), and everything runs fine. I don't see a crash. Note that my build was in Release mode, on Win7 64-bit. Can you please provide more information about your build (Release or Debug mode?), and if this happens always or only sometimes? Do you have to do anything special while the program runs, or do you only start it and click the exit/quit button immediately? Can you provide some debug info (call stack etc. ?). This could help, if it is not something that is only in your system setup. What language is your system language? Albrecht ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] termination of the main window w/o termination of the application
On 09.11.2011 14:29, Steinhoff wrote: I have to do some temporarily GUI operations in a real-time application. That means I create a FLTK window for the GUI related operation and want to close it completely if all GUI work has been done ... without terminating the RT app. I'm using FLTK 1.1.10 after terminating the main window by termination the run() routine the main window doesn't disappear. How do you terminate the run() routine ? It's only removed from the screen if also the RT app terminates. Usually the Fl::run() loop is only terminated if/when all windows are closed. Do you say that you try to close the window, but it stays on the screen? If yes, how do you close it? With the user interface, by using the window's close button, or by calling hide() from the program? How can I fix that bug ? Which OS do you use? Sounds maybe like an X problem we discussed recently. If it is U*IX and you use an X server, then try to add two or three calls to Fl::wait(0.5) after the Fl::run() loop. Does this remove the window from the screen? Note that this is only a test. There's probably a better way if you can give us more context of what you're doing exactly. Albrecht ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] termination of the main window w/o termination of the application
On 09.11.2011 15:14, Albrecht Schlosser wrote: If it is U*IX and you use an X server, then try to add two or three calls to Fl::wait(0.5) after the Fl::run() loop. Does this remove the window from the screen? Okay, I just tested it on Linux, and what I found out was that a single call to Fl::check() is enough to remove the window in my tests on a local X server and on a remote X server as well. Hence, your code could probably be like: // init GUI, show window, ... Fl::run(); Fl::check(); // do other things... Albrecht P.S.: please post your replies and further questions to fltk.general, since fltk.bugs is reserved for our automatic bug tracking system. Thanks. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2748: fixed radio button hot key from turning it off if already on.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2748 Version: 1.3.0 Fix Version: 1.3.1 (r9149) @Matt: This fix (svn r 9149) should definitely be in FLTK 1.3.1, since the bug could lead to all radio buttons of a group being turned off. Test case in test/radio.cxx, navigate to any radio button and press space bar twice. Fixed in FLTK3 as well (r 9150). I left the STR open intentionally, so that it won't get lost - otherwise I consider this as solved, and the STR could be closed... Link: http://www.fltk.org/str.php?L2748 Version: 1.3.0 Fix Version: 1.3.1 (r9149) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2372: No visual indication when pressing Fl_Button with keyboard
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2372 Version: 1.3-current Fix Version: 1.3.1 (r9149) Note that the fix in r7826 (released in FLTK 1.3.0) introduced a regression, so that a radio button could be turned off by using the keyboard (space or shortcut), see STR #2748. http://www.fltk.org/str.php?L2748 The fix of this regression is in r9149 and ought to be released with FLTK 1.3.1. The fix has also been applied to FLTK 3 (r9150). Changed Fix Version from 1.3.0 to 1.3.1. Changed SVN: r from 7826 to 9149. Link: http://www.fltk.org/str.php?L2372 Version: 1.3-current Fix Version: 1.3.1 (r9149) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] msys make error for 1.3
On 23.10.2011 02:06, Gregory Dodd wrote: assuming operator error... maybe... ;-) After multiple tries (including total re-installs of mingw-msys) make gives me the following error (paths shortened): In file included from ../../include/objbase.h:12:0, from ../include/ole2.h:9, from ../../include/windows.h:114, from ../../include/winsock2.h:22, from Fl.cxx:54: ./../include/stdlib.h:521:36: error: 'long long int strtol' redeclared as different kind of symbol ./../include/stdlib.h:329:38: error: previous declaration of 'long int strtol(const char*, char**, int)' ./../include/stdlib.h:521:36: error: expected primary-expression before 'const' ./../include/stdlib.h:521:36: error: expected ')' before 'const' make[1]: *** [Fl.o] Error 1 make: *** [all] Error 1 We had this already, and it was not a FLTK problem, so let me guess: you're using a subversion checkout, and you used a Windows svn client, maybe tortoise svn ? Then this ought to help: $ d2u configh.in (du2 = dos2unix changes line endings from DOS/CR-LF to UNIX/LF). You can also use your favourite editor if it supports to change the file's line endings (e.g. notepad++). After converting the file, please run autoconf and configure again. See also: http://www.fltk.org/str.php?L2651 --- BTW: Please do not post directly to fltk.bugs, since it is for our bug tracking system (fltk.org/str.php). If you are not sure whether you found a bug or you need some help, please ask in fltk.general, else post bug reports at http://fltk.org/str.php. Thanks. Albrecht ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2739: fltk-3 install anomaly
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2739 Version: 3.0 Changed priority to Low and Software Version to 3.0. Link: http://www.fltk.org/str.php?L2739 Version: 3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2739: fltk-3 install anomaly
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2739 Version: 3.0 Also note that there may be more header directories that need to be installed in FLTK 3 (compatibility headers). BTW: I do fully agree with what Ian wrote. But thanks for the heads-up and the patch. Link: http://www.fltk.org/str.php?L2739 Version: 3.0 ___ 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 Great solution - please close the STR! :-) 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] 1.3.0 freezes in Fl_Menu_Item
On 20.10.2011 05:10, Jim Jozwiak wrote: Albrecht, Thank you so much for your patch and suggestions. You're welcome, I'm glad I could help you. And I can report the current 1.3.1 beta works perfectly. Thanks. (You probably mean the current snapshot, right?) Did you also correct your code, or did you try with the old code? The FLTK site and documentation are not clear about how to submit a bug report. Yes, it says do not submit an STR if the bug is not confirmed, but then it says to submit the potential bug report in the Forums without specifying which list to use. Well, yes, this could be improved... NUT is a very complicated gui and I could only get it to work with the more-or-less simple building blocks that fltk provides. I found the project to be impossible in Qt and GTK+ because their widgets have too many parms that often cause conflicted behavior when used in combination. Thanks for this comment, this is good news for FLTK. Albrecht ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] fltk-3.0.x-r9132: install problem
On 16.10.2011 12:55, w. szukalski wrote: In order to install FLTK3, I had to make the changes below. winfried --- fltk-3.0.x-r9132/Makefile.orig 2011-10-01 15:46:37.0 +0200 +++ fltk-3.0.x-r9132/Makefile 2011-10-01 15:48:23.0 +0200 @@ -27,7 +27,7 @@ include makeinclude -DIRS = $(IMAGEDIRS) src $(CAIRODIR) fluid test documentation +DIRS = $(IMAGEDIRS) src $(CAIRODIR) fluid test documentation include/fltk3 all: makeinclude fltk3-config for dir in $(DIRS); do\ @@ -39,7 +39,7 @@ -mkdir -p $(DESTDIR)$(bindir) $(RM) $(DESTDIR)$(bindir)/fltk3-config $(INSTALL_SCRIPT) fltk3-config $(DESTDIR)$(bindir) - for dir in FL $(DIRS); do\ + for dir in $(DIRS); do\ echo === installing $$dir ===;\ (cd $$dir; $(MAKE) $(MFLAGS) install) || exit 1;\ done --- fltk-3.0.x-r9132/include/fltk3/Makefile.in.orig 2011-10-01 15:50:35.0 +0200 +++ fltk-3.0.x-r9132/include/fltk3/Makefile.in 2011-10-01 15:50:49.0 +0200 @@ -25,7 +25,7 @@ # http://www.fltk.org/str.php # -include ../makeinclude +include ../../makeinclude all: Thanks for the patch, IMHO it looks good. However, there are probably more header directories to install than given in the patch, so I'd like to wait for Matt to take a look at it. Please file an STR (fltk.org/str.php) so that the patch doesn't get lost. Thanks. Albrecht ___ 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 Well, as a German, I can say that Eszett (German sharp s = 'Ã') is usually capitalized as 'SS', but that's not always done (often it is left as-is, since there is no upper-case 'Ã'). That said, is there a standard (ISO, POSIX, or anything else) that documents that this is the *correct* behavior? Notes: (a) at least this doesn't seem to change the number or bytes of the (UTF-8) string, but (b) it it not invertible. 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 #2729: Fl_Spinner bug
On 11.10.2011 01:14, Richard Sanders wrote: On Mon, Oct 10, 2011 at 1:19 AM, Albrecht Schlosser wrote: (citation trimmed...) Okay, I tested with and w/o the patch with the new attached spinner2.cxx that has another button (label NOP) just to receive input focus when pressing the TAB key, or to click on it to move the input focus from the spinner input field to another widget. (1) TAB works as expected and triggers the callback w/o the patch, as well as clicking on the button (FL_WHEN_RELEASE works as expected). (2) *With* the patch, each key press in the input field triggers the callback (as expected with FL_WHEN_CHANGED), but this is /not/ the *intended* behavior of this widget. Thus, this STR should be closed w/o resolution. To Richard: if you /really/ need the behavior as changed by your patch, then you should write your own widget, since we can't change it as suggested in your patch. But maybe this was only a misunderstanding? Note that my test was on Windows, maybe you see different behavior on another platform? Please comment on this, otherwise this STR will be closed w/o resolution in a few days. Link: http://www.fltk.org/str.php?L2729 Version: 1.3-current As Fl_Spinner stands our of the box. The callback gets executed every time that the value is changed via the up down buttons. To \not\ have the callback done when the value is changed via the keyboard is inconsistent behavior. Consistent behavior would be 1) Never call the callback on a value change. 2) Always call the callback on value change. Hmm, I really don't understand what you are saying here. As it is currently, the callback *is* called when the user changes the input field, but only after saying that he is ready by pressing the Enter or Tab key or clicking on another widget (losing focus). This is exactly what I would expect from such a widget. Imagine the contents of the input field is 31, and the user wants to change it to 32. The first keypress would probably delete the 2, and now the value is 3. With your patch, the callback would be called now, although the user is not ready with editing the value. Then the user would hit the 2 on his keyboard, giving the value 32. Now the callback would be called again (okay this time). But now imagine that the user would have hit the 5 instead of 2 ... More and more callbacks for each key press. Although this might be interesting for some low-level stuff, I'm sure that this is not what /most/ developers would expect of such a widget. Really consistent would be to have the callback for Fl_Spinner executed in accordance with the when() of Fl_Spinner and not the when() of the internal Fl_Input. This is something different, and it's worth a consideration. If you like to have this, then you should probably add an STR (with RFE status) for 1.3-feature to request such a finer control over the widget. This might be feasible... And that is the real problem, my suggestion is a kludge that makes it appear uniform to the user. For a programmer to have to instruct the user to only change values of Fl_Spinner via the up/down buttons makes the programmer look like an idiot, the programmer following the trail looks at the library provider and says... That's not the case! Please see above. I presume the intended behavior of Fl_Spinner is to allow the programmer to specify the callback but have no control of the when(), as is the case currently.I do not want to appear nasty or ungrateful but Fl_Spinner seems to be more of a proof of concept rather than a finished item. That may be correct, IIRC it was added somewhere during the 1.1.x life time, but maybe as a quick hack (all code is in the header file). It looks as if it was added (in svn r4149) for printing support in fluid (r4150). Anyway, IMHO it works as designed (as far as keyboard input is concerned). I'd like to read other opinions, though. Devs, please? Fl_Spinner has the same behavior in Windows and Linux. Thanks. Albrecht ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2729: Fl_Spinner bug
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2729
Version: 1.3-current
In my tests, the FL_WHEN_ENTER_KEY part *does* work as expected, i.e. the
callback is called when I press ENTER. However, I can see that pressing
TAB to leave the input field doesn't call the callback. See attached
simple test case spinner.cxx.
I'm not convinced that adding FL_WHEN_CHANGED is the correct solution, but
I'm not sure about it. However, I believe that pressing TAB (or clicking on
another widget *should* trigger the callback, if FL_WHEN_RELEASE is set
(unfortunately my simple test case doesn't contain other widgets...).
Link: http://www.fltk.org/str.php?L2729
Version: 1.3-current// file: spinner.cxx
// use: fltk-config --compile spinner.cxx to compile
#include FL/Fl_Window.H
#include FL/Fl_Spinner.H
#include FL/Fl_Box.H
#include FL/Fl.H
#include stdio.h
void spinner_cb(Fl_Widget *w, void *v) {
Fl_Spinner *s = (Fl_Spinner *)w;
Fl_Box *message = (Fl_Box *)v;
int val = (int)s-value();
static char buf[100];
sprintf(buf,received callback: value = %d,val);
message-label(buf);
message-redraw();
printf(%s\n,buf); fflush(stdout);
}
int main (int argc, char **argv) {
Fl_Window *win1 = new Fl_Window(250,150);
Fl_Spinner *spinner = new Fl_Spinner(50,10,100,80);
Fl_Box *message = new Fl_Box(10,110,230,30);
message-label(callbacks will show up here ...);
win1-end();
spinner-callback(spinner_cb,message);
win1-show(argc,argv);
return Fl::run();
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2729: Fl_Spinner bug
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2729
Version: 1.3-current
Okay, I tested with and w/o the patch with the new attached spinner2.cxx
that has another button (label NOP) just to receive input focus when
pressing the TAB key, or to click on it to move the input focus from the
spinner input field to another widget.
(1) TAB works as expected and triggers the callback w/o the patch, as well
as clicking on the button (FL_WHEN_RELEASE works as expected).
(2) *With* the patch, each key press in the input field triggers the
callback (as expected with FL_WHEN_CHANGED), but this is /not/ the
*intended* behavior of this widget.
Thus, this STR should be closed w/o resolution.
To Richard: if you /really/ need the behavior as changed by your patch,
then you should write your own widget, since we can't change it as
suggested in your patch. But maybe this was only a misunderstanding?
Note that my test was on Windows, maybe you see different behavior on
another platform? Please comment on this, otherwise this STR will be
closed w/o resolution in a few days.
Link: http://www.fltk.org/str.php?L2729
Version: 1.3-current// file: spinner.cxx
// use: fltk-config --compile spinner.cxx to compile
#include FL/Fl_Window.H
#include FL/Fl_Spinner.H
#include FL/Fl_Button.H
#include FL/Fl_Box.H
#include FL/Fl.H
#include stdio.h
void spinner_cb(Fl_Widget *w, void *v) {
Fl_Spinner *s = (Fl_Spinner *)w;
Fl_Box *message = (Fl_Box *)v;
int val = (int)s-value();
static char buf[100];
sprintf(buf,received callback: value = %d,val);
message-label(buf);
message-redraw();
printf(%s\n,buf); fflush(stdout);
}
int main (int argc, char **argv) {
Fl_Window *win1 = new Fl_Window(250,150);
Fl_Spinner *spinner = new Fl_Spinner(50,10,100,80);
Fl_Box *message = new Fl_Box(10,110,230,30);
Fl_Button *b = new Fl_Button(180,10,40,40,NOP);
message-label(callbacks will show up here ...);
win1-end();
spinner-callback(spinner_cb,message);
win1-show(argc,argv);
return Fl::run();
}
___
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 Yes, I remember the case well, and I can take a look at it over the next weekend, if nobody else beats me to it... 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] [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 In Corvid's example the last (only?) line of text doesn't have a terminating \n. This is probably what's causing the slider's misbehavior, because the line count is not consistent with the display. I remember that there was a comment (maybe in FLTK 2) that this was an unresolved problem. Maybe it's something similar here... HTH. 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] [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 Ian, thanks for investigating this. I'll take care of it ASAP. AFAICT, setting the line width in src/fl_round_box.cxx was not necessary after fixing the (32-bit - 16-bit) X11 clipping issue in STR #2615 in a more general way. I left it in the code, because it *seemed* to do the right thing anyway, but now it looks as if there were bad side effects. I'll check it again and report back here. 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: 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 Same findings here, also on Win7 (but Ian wrote that he could also replicate it on WinXP). It doesn't seem to depend on a particular Windows version. Here's my modified test case: use this patch --- test/buttons.cxx(revision 8981) +++ test/buttons.cxx(working copy) @@ -38,6 +38,7 @@ new Fl_Round_Button(150,50,160,30,Fl_Round_Button); new Fl_Check_Button(150,90,160,30,Fl_Check_Button); window-end(); + window-resizable(window); window-show(argc,argv); return Fl::run(); } Then run test/buttons.exe with something like this command to enhance the contrast: $ test/buttons -bg 77bbff This gives a light blue background. Then, besides clicking and releasing buttons, you can also resize the window to see lots of drawing artefacts. There's also one visible at the arrow of the Rl_Return_Button, where the white dots seem to be offset upwards by one or two pixels. See attached screenshot buttons_blue.png. Note that this is also present in fltk3, but you need to run it in the classic scheme: $ fltk-3.0/test/buttons -bg 77bbff -s classic My *guess* is that something happens to the transformation matrix in the draw() method of Fl_Radio_Button, but that this is not reset properly, since the effect doesn't go away with a full redraw after resize. But that's only a wild guess, I didn't look at the code. Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0attachment: buttons_blue.png___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2703: fl_pie not drawing correctly with X11
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2703 Version: 1.3-current Fix Version: 1.3.1 Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2703 Version: 1.3-current 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 #2703: fl_pie not drawing correctly with X11
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2703 Version: 1.3-current Lowered priority to 3 - Moderate. Richard, thanks for the investigation and the hint to fix the issue. I uploaded 3 images of Windows and Linux unittests (before and after the patch) for others to compare. Please see attached file fl_pie_linux.patch for a proposed fix. AFAICT Richard's suggested fix is worth implementing. In fact, we had some red dots in the previous Linux unittests that disappeared with the patch. Linux and Windows now look more similar than before. Are there any serious objections? There may be a small drawing overhead involved, but I don't think that this is something we should care about, since this is one step forward to more platform compatibility. Link: http://www.fltk.org/str.php?L2703 Version: 1.3-currentIndex: src/fl_arci.cxx === --- src/fl_arci.cxx (revision 9006) +++ src/fl_arci.cxx (working copy) @@ -77,6 +77,7 @@ if (w = 0 || h = 0) return; #if defined(USE_X11) + XDrawArc(fl_display, fl_window, fl_gc, x,y,w-1,h-1, int(a1*64),int((a2-a1)*64)); XFillArc(fl_display, fl_window, fl_gc, x,y,w-1,h-1, int(a1*64),int((a2-a1)*64)); #elif defined(WIN32) if (a1 == a2) return; ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] Yet another way fluid generated code can crash the application
[Cross-Posting to fltk.development, because this is something that ought to be discussed there. fltk.bugs is for automatic posting from the STR system only.] On 19.08.2011 02:18, Csaba Biegl wrote: Consider a fluid class containing an Fl_Input_Choice widget. If this widget has Fl_Menu_Item-s that have their own callbacks then these will crash the program. Reason is that Fl_Input_Choice itself is a group containing an FL_Input and a Fl_Menu_Button. It is the latter component that executes its menu item callbacks on their behalf. Fluid generated callbacks find their class instance using repeated -parent() calls. Because Fl_Input_Choice adds an other group to the hierarchy, the fluid generated callback will access the wrong object. Good catch - that sounds plausible (although I'm not very familiar with fluid code). I can post a patch to fix this, but we need to decide where to fix it. Thanks for the offer! Option 1: Fix it in fluid so that for Fl_Input_Choice menu item callbacks it adds one more -parent(). Advantage: This fix would be local to fluid. Drawback: special handling in fluid. Option 2: Fix it in Fl_Input_Choice so that its own subclassed version of Fl_Menu_Button passes up menu item callbacks to its parent. This is what I'd prefer on a first thought. But then there is the possibility that this would break user code that handled this correctly (code *not* generated by fluid). Just my 2 ct; I'll leave the final decision to others... Albrecht ___ 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 First of all we don't need Fl::x(),,,Fl::w() any more if we have the method to get each screen's working area as suggested by Ian. We could deprecate it then. If we did this, then the only question is that of compatibility with software that is using it. I'd say that these methods /should/ return the work area dimensions of the first/main monitor to be mostly consistent. On Windows this would be fully compatible with all previous versions. I think that X w/o Xinerama gives us only one display area, even with a multi-headed display, as Ian wrote. Maybe only in this case we would return this working area's bounds, and this would be a platform-dependent exception that could be documented. X with Xinerama would then return the first screen's working area. I don't know much about OS X though, but if it doesn't break things, I'd prefer consistency, so that it should always return the work area of the primary (not the focus-containing) screen. For all other cases, users should use the new methods that let them get the correct values of on specific monitor. 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 Pending] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) Monolo, unfortunately this is an even major regression on Windows, since it does not only use the wrong height, but also positions *all* menus on the primary monitor (even if the main window is on the secondary display). Please revert this change, we can't do it this way. But thanks for your efforts. The previous behavior was only a minor glitch that could probably be corrected as suggested by Ian, but this one is really bad. Sorry. :-( 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) BTW: I don't think that this would be okay on X11 with Xinerama, but I can't test this right now. 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) @Manolo: yes, the menu is now positioned correctly, but this still doesn't resolve the whole problem, since the menu doesn't scroll on *my* special display setup: monitor 1: 1680x1050 (with taskbar), monitor 2: 1440x900 (w/o taskbar). Both monitors have their zero y coordinates in line, and hence the lower part (higher y coordinates) is missing on monitor 2. As Ian noted, Fl::x()/y()/w()/h() *should* be platform-independent, and adding another #ifdef __APPLE__ in Fl_Menu.cxx (r 8935) should IMHO be avoided, if we can. However, rev. 8935 solves the issue maybe on most platforms or standard display setups and is at least a step forward... 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 #2696: Misplaced #endif in FL/x.H breaks use on WIN32 and __APPLE__
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2696 Version: 1.3-current No, that is all intentional, AFAICS. The relevant code for Windows is all in FL/win32.H, and there you can also find fl_xid() and class Fl_X. However, in FLTK 1.3 you must define the macro FL_INTERNALS to get these definitions, since they are excluded by default (they were included in FLTK 1.1 though). So the correct solution ought to be the definition of FL_INTERNALS before all (FLTK related) #include statements. Please confirm if this solves your problem, so that we can close this STR. Thanks. Link: http://www.fltk.org/str.php?L2696 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
[STR Closed w/o Resolution] Link: http://www.fltk.org/str.php?L2490 Version: 1.1.10 Fix Version: Will Not Fix Note: I tried[1] to remove the Duplicate of: STR #1986 flag, since this appears to be a totally different bug. IIRC this flag was set at a time we didn't know what caused the issue, and at that time it was more a suspicion than facts. Now I believe that they are unrelated. Thanks for the heads-up. [1] When resetting the Duplicate Of: field I got the error message Unable to save STR!. Leaving it as-is for now. 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] [MOD] STR #2680: Fl_Menu regression: potential endlessloop with unusual menu flags
On 18.07.2011 08:42, Manolo Gouy wrote:
Manolo, since you did that particular change, I assume that you are more
familiar with this code, and I'd like to see your comment (or a better
solution).
Here's a simple test case: use this patch to add an invisible menu item to
the menu button in test/menubar.cxx, compile and run it, then click on the
menu button. The application goes into an endless loop...
--- test/menubar.cxx(revision 8862)
+++ test/menubar.cxx(working copy)
@@ -176,6 +176,7 @@
{Charm, FL_ALT+'c'},
{Truth,FL_ALT+'t'},
{Beauty, FL_ALT+'b'},
+ {0,0, 0, 0, FL_MENU_INVISIBLE},
{0}
};
I don't think it's correct to define an Fl_Menu_Item with 0 in first
field (name) and non-zero somewhere else, because 0-named items
are used everywhere in the code as markers of submenu end.
See, e.g., Fl_Menu.cxx lines 46, 316, 334.
Accepting that would require much rewriting, for a dubious benefit.
Thanks for your comment.
I agree with you that this is unusual or may even look wrong, but there
are three reasons why I believe that it would be worth fixing:
(1) it works in FLTK 1.1 and worked in 1.3 up to and including RC3
(2) it fails in a bad way (GUI freeze, endless CPU loop)
(3) I believe that a zero item name (text == NULL) should always
terminate a (sub)menu, regardless of the contents of any other field
in the Fl_Menu_Item structure. It worked that way before svn r8639,
and that's why the user found this.
Documentation of const char* Fl_Menu_Item::label() const states:
A NULL here indicates the end of the menu (or of a submenu).
See
http://www.fltk.org/doc-1.3/structFl__Menu__Item.html#ab7a334e6bf9d8ead1c8f1f20a70b0296
There is no mention of restrictions of other menu fields, and thus
it *should* terminate the (sub)menu definitely.
Unfortunately the change in r8639 made this fail, so if you can
fix it (maybe in a better way than I did?), then please do it.
Thanks.
Albrecht
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2680: Fl_Menu regression: potential endless loop with unusual menu flags
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2680 Version: 1.3-current Yes, thanks, will do - but later... Link: http://www.fltk.org/str.php?L2680 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] 1.3.0 freezes in Fl_Menu_Item
Hi Jim, On 13.07.2011 03:01, Jim Jozwiak wrote: The application is nut-16.13 from nut.sourceforge.net. To recreate the problem, go to the View Foods tab and find a food, such as baked russet. The food will come up, but at this point the application freezes. gdb usually tells me fltk is sitting on line 331 of ../FL/Fl_Menu_Item.H, but I can't see what is wrong. My code worked at least until 1.3.0rc3, and works on 1.1.10. Since the earlier versions of 1.3.0 have disappeared from your site, I had to rerelease nut with explicit instructions to only use 1.1.10, but I didn't change my code. Usually we don't look at full applications to replicate a problem with FLTK, because it is much easier to find a potential bug in a short test program. In your case I was curious, and so I tried nut. There are good news for you: See the small one-line patch at the end of this message for your application that should fix the issue for you. At least it worked for me. Note that this might access one more menu entry, and that I didn't see any range checks in your code. Please take care of that yourself. I also didn't look at the initialization of the label() of additional menu entries. IMHO it would be best to initialize menu entry n+1 with label(0) and no flags to have a correct terminating entry, or maybe something like memset(pulldown[n],0,sizeof(pulldown[n]) ). Side note: after tweaking the Makefile(s) a little, I was able to compile and run your code on Windows 7. I didn't bother to test on Linux, although I could have done that too... The problem with your code (together with the handling in FLTK 1.3) was that you set the terminating menu entry to invisible() implicitly in line #68 in fltk/ServingMenuButton.cc. FLTK was changed in svn r8639 to handle invisible menu entries differently, and thus FLTK ran into an endless loop. :-( This is something I'd call undefined behavior caused by an undefined combination of menu flags. FLTK 1.1 handled this differently, and so did FLTK 1.3.0-rc3. Nevertheless this ought to be fixed in FLTK 1.3 itself, and I found a way to fix it, but I recommend the code change as shown below anyway. Thanks for your report and the test case ;-) Note: fltk.bugs is not the right place to post problems with FLTK. If you are not sure whether it is a bug or not, please post your questions to fltk.general. If you believe it's a bug, please file a STR at http://www.fltk.org/str.php. Thank you. If you care to pursue this by looking at Nut, perhaps you could also try Nut -scheme plastic, which has never worked right. The plastic scheme only appears on top-level things but does not penetrate into the hierarchy of widgets within widgets. I tried the plastic scheme, but didn't see exactly what was correct and what seemed to be wrong, but I agree that it doesn't appear to be the plastic scheme for all widgets. I won't investigate this further now, but if you want to get this fixed too, please file an STR as said above, add a simple test case that shows what you think is wrong, and explain what you would expect to be different. This way it won't be lost in the bit bucket... Albrecht Patch (inline, may wrap): --- nut-16.13-ori/fltk/ServingMenuButton.cc 2011-02-16 20:33:31 +0100 +++ nut-16.13/fltk/ServingMenuButton.cc 2011-07-17 17:14:08 +0200 @@ -74,6 +74,7 @@ pulldown[resultcount / 3 + 1].label(Save the current serving as the default but I will enter a new serving unit); pulldown[resultcount / 3 + 1].labelsize(FontSize); pulldown[resultcount / 3 + 1].callback(menu_cb, (void *)-1); +pulldown[resultcount / 3 + 2].flags = 0; Fl::check(); } ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2680: Fl_Menu regression: potential endless loop with unusual menu flags
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2680
Version: 1.3-current
According to this thread in fltk.bugs:
http://www.fltk.org/newsgroups.php?gfltk.bugs+Q%221.3.0+freezes+in+Fl_Menu_Item%22
there is a potential bug in src/Fl_Menu.cxx that can cause an application
to freeze in a CPU-bound endless loop.
This regression (caused by unusual or illegal Fl_Menu_Item flags) has
been introduced in svn r8639 to fix an issue with menu shortcuts for
invisible menu items (STR #2613).
I found a potential fix (see attached file Fl_Menu.patch), but I'm not
sure whether this is correct or there may be a better solution. Anyway,
although this is a somewhat undefined case, I suggest that we fix this in
FLTK.
Manolo, since you did that particular change, I assume that you are more
familiar with this code, and I'd like to see your comment (or a better
solution).
Here's a simple test case: use this patch to add an invisible menu item to
the menu button in test/menubar.cxx, compile and run it, then click on the
menu button. The application goes into an endless loop...
--- test/menubar.cxx(revision 8862)
+++ test/menubar.cxx(working copy)
@@ -176,6 +176,7 @@
{Charm, FL_ALT+'c'},
{Truth,FL_ALT+'t'},
{Beauty, FL_ALT+'b'},
+ {0,0, 0, 0, FL_MENU_INVISIBLE},
{0}
};
Link: http://www.fltk.org/str.php?L2680
Version: 1.3-currentIndex: src/Fl_Menu.cxx
===
--- src/Fl_Menu.cxx (revision 8862)
+++ src/Fl_Menu.cxx (working copy)
@@ -81,7 +81,7 @@
if (!m-visible()) n++;
while (n) {
m = next_visible_or_not(m);
-if (m-visible()) n--;
+if (m-visible() || !m-text) n--;
}
return m;
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2680: Fl_Menu regression: potential endless loop with unusual menu flags
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2680
Version: 1.3-current
FWIW, here is my *complete* patch, including the test case and lots of
printf() statements I used to find this particular problem with the user's
code (see attached file Fl_Menu_test.patch. Look for the output text \n***
GOT YOU! ***\n\n to see where (and when) the hangup would happen
otherwise.
Link: http://www.fltk.org/str.php?L2680
Version: 1.3-currentIndex: src/Fl_Menu.cxx
===
--- src/Fl_Menu.cxx (revision 8863)
+++ src/Fl_Menu.cxx (working copy)
@@ -56,10 +56,12 @@
// Advance a pointer to next visible or invisible item of a menu array,
// skipping the contents of submenus.
static const Fl_Menu_Item* next_visible_or_not(const Fl_Menu_Item* m) {
+ printf(%s:%d m=%p,
text=%s\n,__FUNCTION__,__LINE__,m,m-text?m-text:); fflush(stdout);
int nest = 0;
do {
if (!m-text) {
- if (!nest) return m;
+ if (!nest) { printf(%s:%d m=%p,
text=%s\n,__FUNCTION__,__LINE__,m,m-text?m-text:); fflush(stdout);
+ return m; }
nest--;
} else if (m-flagsFL_SUBMENU) {
nest++;
@@ -67,6 +69,7 @@
m++;
}
while (nest);
+ printf(%s:%d m=%p,
text=%s\n,__FUNCTION__,__LINE__,m,m-text?m-text:); fflush(stdout);
return m;
}
@@ -76,13 +79,23 @@
that you can advance through const and non-const data.
*/
const Fl_Menu_Item* Fl_Menu_Item::next(int n) const {
+ printf(%s:%d, n=%d\n,__FUNCTION__,__LINE__,n); fflush(stdout);
if (n 0) return 0; // this is so selected==-1 returns NULL
const Fl_Menu_Item* m = this;
if (!m-visible()) n++;
+ printf(%s:%d, n=%d\n,__FUNCTION__,__LINE__,n); fflush(stdout);
while (n) {
+printf(%s:%d, while(n) n=%d\n,__FUNCTION__,__LINE__,n); fflush(stdout);
m = next_visible_or_not(m);
-if (m-visible()) n--;
+printf(%s:%d, while(n) n=%d, visible=%d,
text=%p\n,__FUNCTION__,__LINE__,n,m-visible(),m-text); fflush(stdout);
+// if (m-visible() || !m-text) n--; // added: || !m-text
+if (m-visible() || !m-text ) { // added: || !m-text
+ n--;
+ if (!m-visible()) { printf(\n*** GOT YOU! ***\n\n); fflush(stdout); }
+}
+printf(%s:%d, while(n) n=%d\n,__FUNCTION__,__LINE__,n); fflush(stdout);
}
+ printf(%s:%d\n,__FUNCTION__,__LINE__); fflush(stdout);
return m;
}
Index: test/menubar.cxx
===
--- test/menubar.cxx(revision 8863)
+++ test/menubar.cxx(working copy)
@@ -176,6 +176,7 @@
{Charm, FL_ALT+'c'},
{Truth,FL_ALT+'t'},
{Beauty, FL_ALT+'b'},
+ {0,0, 0, 0, FL_MENU_INVISIBLE},
{0}
};
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2420: Tab-Navigation focuses non-active_r() widgets
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2420 Version: 1.4-feature @Jörg (OP): Please provide the your case. Otherwise this bug report will be closed after another 14 days or so... Link: http://www.fltk.org/str.php?L2420 Version: 1.4-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2420: Tab-Navigation focuses non-active_r() widgets
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2420 Version: 1.4-feature Should read: Please provide your test case... Link: http://www.fltk.org/str.php?L2420 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 #2670: while use FLTK as a shared library, fl_xid doesn't work.
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2670 Version: 1.3.0 Fix Version: 1.3.1 (r8821) Thanks for confirmation. Closed. Link: http://www.fltk.org/str.php?L2670 Version: 1.3.0 Fix Version: 1.3.1 (r8821) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2670: while use FLTK as a shared library, fl_xid doesn't work.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2670
Version: 1.3.0
Fix Version: 1.3.1 (r8821)
Fixed in Subversion repository.
@Manolo: obviously that's not enough (sigh). We need FL_EXPORT in the
function definition in src/Fl_win32.cxx as well. I found this out by
testing, and it worked for me with Visual C++ 2010 Express.
@jzhang: please confirm that svn r8821 fixes the issue. If you don't have
subversion access, please change line #1962 in file src/Fl_win32.cxx
from:
Window fl_xid_(const Fl_Window *w) {
to:
FL_EXPORT Window fl_xid_(const Fl_Window *w) {
(add FL_EXPORT).
Thanks for the report, and TIA for confirmation.
Link: http://www.fltk.org/str.php?L2670
Version: 1.3.0
Fix Version: 1.3.1 (r8821)
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2670: while use FLTK as a shared library, fl_xid doesn't work.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2670 Version: 1.3.0 Does it work if you define the preprocessor macro #define FL_INTERNALS at the top of your source file or in the compiler command line (like -DFL_INTERNALS) ? Link: http://www.fltk.org/str.php?L2670 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 #2663: OpenGL overlay bug on Windows 7 + Intel graphics
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2663 Version: 1.3-current If this is a driver bug, can you work around it by changing graphics setup options? I had success by reducing hardware acceleration in the extended graphics setup (I can't tell the exact options, but I'll try to translate from my German Windows XP): - right click on the desktop, select Properties - select Setup, select Extended - select Problem Handling - move the slider called Hardware Acceleration to a lower value - (maybe) reboot... Link: http://www.fltk.org/str.php?L2663 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 #2661: Fluid may crash when printing
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2661 Version: 1.3.0 Which OS? FTR: This is probably not a new (FLTK 1.3) problem, I just tried it on Windows with both FLTK 1.1 and 1.3, and both showed black rectangles instead of the GUI images, but didn't crash. (We didn't change fluid yet to use the new printing features, AFAICT...) Link: http://www.fltk.org/str.php?L2661 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 #2651: Building errors under latest MingW/MSYS
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2651 Version: 1.3-current Fix Version: 1.3.0 WRT line endings: Unix uses LF, and Mac OS used to use CR, AFAICT. Is Mac OS X now using LF? As for the solution, tagging configh.in as binary would be bad, since we would lose the possibility to make diffs. svn ps svn:eol-style LF configh.in ought to do the trick (and hopefully not break anything else). Link: http://www.fltk.org/str.php?L2651 Version: 1.3-current Fix 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 #2651: Building errors under latest MingW/MSYS
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2651 Version: 1.3-current Fix Version: 1.3.0 @Matt: Roman wrote that the bundled configure script in 1.3.0-rc6 worked, whereas the configure script created by himself (with MinGW's autoconf) doesn't - see also the different sizes and autoconf versions mentioned previously. Link: http://www.fltk.org/str.php?L2651 Version: 1.3-current Fix 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 #2651: Building errors under latest MingW/MSYS
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2651 Version: 1.3-current Fix Version: 1.3.0 @Roman: okay, one last try from my side: I'd like to know why it doesn't work in your configuration. Could you please take a look at the file config.log after running the (MinGW-created) configure? I manipulated my configure.in to look for strtoxx instead of strtoll, and I see: configure:5886: checking for strtoxx configure:5886: gcc -o conftest.execonftest.c 5 C:\...\Temp\ccQA1oZB.o:conftest.c:(.text+0xc): undefined reference to `strtoxx' collect2: ld returned 1 exit status configure:5886: $? = 1 configure: failed program was: | /* confdefs.h */ ... So what I get is a linker error (undefined reference). What is your error message? Link: http://www.fltk.org/str.php?L2651 Version: 1.3-current Fix Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
