Re: [fltk.bugs] [MOD] STR #1625: menu items text color has changedyielding poor contrast
Matthias Melcher wrote: > On my WindowsXP Teletubbies-Background original settings.. LOL *falls out of chair* I'd always wondered why that default XP background was somehow "disturbing", but could never put my finger on it. That's it, by God! > This annoys the heck out of me when Fluid overrides my colors > for the graphical labels! Yes, I seem to remember having a conversation IRL with Bill at DD once commiserating on the hassle that ~/.Xdefaults can cause from a user support point of view. When writing apps at Metrolight in the early 90's, I'd ran into this because folks loved tweaking their .Xdefaults in those days. It was especially a problem when users would specify color changes in such a way that it would accidentally affect *all* apps, and how IIRC Bill wanted to avoid this kind of trouble when writing his own toolkit. I don't remember if he'd written FLTK yet. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #1639: Fl::event_button[1, 2, 3]() always returns 0
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Just some notes from the sidelines, as I thought this was interesting. I think the problem here is the functions in question [event_button123()] all work with the event_state(), which returns the buttons being held down at the time of the event. Since the button callback is called when buttons are /released/, the event_state() has already been cleared. The functions in question work OK in the context of handle() in response to an FL_PUSH, but return all 0's when FL_RELEASE occurs because the button is no longer down. Or so it seems, looking at how the event_button123() and event_buttons() [plural] methods work. The event_button() [singluar] and event_key() methods have a different implementation that doesn't look at the event_state(), but rather, the event e_keysym. Not sure if this is a bug in the code, or an undocumented or misdocumented feature.. as the docs for the 'Fl::event_*() methods' section say these methods are valid in handle() and callback() contexts.. just apparently not in the context of a button callback() though. Link: http://www.fltk.org/str.php?L1639 Version: 1.1.7 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #1641: "make clean" doesn't remove all executables
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] I just pulled the latest 1.1.x SVN, and I don't see the problem: Sat 03/31/07 15:17:14 /usr/local/src/fltk-1.1.x-svn/test [EMAIL PROTECTED] ## ROOT ## 212 # ls -la blocks -rwxr-xr-x 1 root root 217170 Mar 31 15:16 blocks Sat 03/31/07 15:17:22 /usr/local/src/fltk-1.1.x-svn/test [EMAIL PROTECTED] ## ROOT ## 213 # make clean Sat 03/31/07 15:17:28 /usr/local/src/fltk-1.1.x-svn/test [EMAIL PROTECTED] ## ROOT ## 214 # ls -la blocks ls: blocks: No such file or directory ..as far as I can tell, no binaries are left behind. Link: http://www.fltk.org/str.php?L1641 Version: 1.1-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #1641: "make clean" doesn't remove all executables
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] I see.. "Scope" says all OS's, but looks like this is OSX specific. (The OSX bundle executable is left behind). My test was on linux. Scope should probably be 'Specific to an operating system'.. Link: http://www.fltk.org/str.php?L1641 Version: 1.1-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #1641: "make clean" doesn't remove all executables
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Yeow, you're right. And it's a linux binary alright, too.. file(1) says so. (ie. its *not* a 'leftover' from a previous MacOS build) Apparently the build instructions for 'blocks' includes an 'install' command that puts the blocks executable in the .app dir regardless of platform; on fedora3: # pwd /usr/local/src/fltk-1.1.x-svn/test # make blocks echo Compiling blocks.cxx... Compiling blocks.cxx... g++ -I.. -Os -Wall -Wunused -Wno-format-y2k -fno-exceptions -fno-strict-aliasing -I/usr/X11R6/include -c blocks.cxx echo Linking blocks... Linking blocks... g++ -Os -Wall -Wunused -Wno-format-y2k -fno-exceptions -fno-strict-aliasing -L/usr/X11R6/lib blocks.o -o blocks -lasound ../lib/libfltk.a -ldl -lm -lXext -lX11 /usr/bin/install -c -m 755 blocks blocks.app/Contents/MacOS ^^^ : blocks ../FL/mac.r Looks like test/Makefile at fault here; shouldn't be copying stuff into the .app dirs unless it's an OSX build. Same problem for 'checkers' and 'sudoku' targets (on fedora3): # make sudoku [..] /usr/bin/install -c -m 755 sudoku sudoku.app/Contents/MacOS : sudoku ../FL/mac.r # make checkers [..] /usr/bin/install -c -m 755 checkers checkers.app/Contents/MacOS : checkers ../FL/mac.r Link: http://www.fltk.org/str.php?L1641 Version: 1.1-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #1644: Fl_Text_Buffer::*file() methods need docs for return value
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] These Fl_Text_Buffer methods need their return value documented: appendfile() insertfile() loadfile() Should probably at least say: "Returns 0 on success, 1 on error loading file (strerror() contains reason)." Link: http://www.fltk.org/str.php?L1644 Version: 1.1-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #1644: Fl_Text_Buffer::*file() methods need docs for return value
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Looks like there are multiple error codes: 1=open error, 2=ferror(). Maybe it should say instead: "Returns 0 on success, non-zero on error (strerror() contains reason). 1 indicates open for read failed (no data loaded). 2 indicates error occurred while reading data (data was *partially* loaded)." Also: outputfile() needs docs on its return value as well. Same as above, but for writing data. Link: http://www.fltk.org/str.php?L1644 Version: 1.1-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #1645: Fl_Text_Buffer::text(): docs need clarification text() returns COPY
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Currently the docs for text() and text(char *text) reads: -- const char* text(); void text(const char* text); Gets or sets the text in the buffer. When you are done with the text, free it using the free() function. -- IMHO it is not clear the part about free() is exclusively regarding the get method. Since this sentence is describing two methods that act very differently, I think the docs should be made very clear that text(void) returns a *copy* and not a pointer to the internal buffer, and that the free() comment has nothing at all to do with the text(const char*) method. Possibly better wording: -- const char* text(); void text(const char* text); Gets or sets the text in the buffer. The first form returns a *copy* of the text in the buffer which you must later free() when done using it. The second form sets the text in the buffer, making an internal copy of the string that is automatically managed. -- Link: http://www.fltk.org/str.php?L1645 Version: 1.1-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #1662: FLTK API docs: request for standard documenting of pointer return values
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Any funcs/methods that return a pointer should have a standard indication of memory implications: o Whether the data needs to be freed or not (new or delete) o Whether the data is static or not (affects threading) The latter underlining a distinction between static data and dynamically allocated data internally managed by the class; though both don't concern the caller for free()ing/delete()ing, there is still a distinction between the two, as static data is potentially dangerous to a threaded app. Currently some docs seem to not be clear on this, eg: http://fltk.org/doc-2.0/html/structFont.html#m2 It would be good if the 'return value' is documented in such a way that it's easy for an app programmer to find (eg. the last sentence in the docs for the function, or a separate 'Return Value' section, similar to unix manpages) and the language consistent regarding static vs non-static, and whether the data needs to be freed with free() or delete(). This applies to both FLTK 1.x and 2.x. This is probably a request to modify the CMP to include these specifics under the "Documenting Functions and Methods" section. Link: http://www.fltk.org/str.php?L1662 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #1665: No docs for FLTK2 MenuBar class
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] I didn't see docs for the MenuBar class on this page: http://fltk.org/doc-2.0/html/index.html ..an omission? Link: http://www.fltk.org/str.php?L1665 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #1667: bad link in docs for fl_ask()
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] On this page: http://fltk.org/documentation.php/doc-1.1/functions.html#fl_ask ..the link for fl_choice() incorrectly redirects to the Fl_Choice *class* docs. I believe the intention is to link to the fl_choice() function instead. Link: http://www.fltk.org/str.php?L1667 Version: 1.1-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #1676: Fl_Input_Choice allows selection of sub-menus
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] I think this simple patch might cover it. Link: http://www.fltk.org/str.php?L1676 Version: 1.1-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #1676: Fl_Input_Choice allows selection of sub-menus
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1676
Version: 1.1-current--- Fl_Input_Choice.H.old 2007-05-14 16:59:57.459721360 -0700
+++ Fl_Input_Choice.H 2007-05-14 17:00:28.058069704 -0700
@@ -59,6 +59,8 @@
static void menu_cb(Fl_Widget*, void *data) {
Fl_Input_Choice *o=(Fl_Input_Choice *)data;
+const Fl_Menu_Item *item = o->menubutton()->mvalue();
+if ( item && item->flags & (FL_SUBMENU|FL_SUBMENU_POINTER) ) return;
// ignore submenus
o->inp_->value(o->menu_->text());
o->do_callback();
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] build FLTK in vc .net 2003
Manoj wrote: >> Do you want to link FLTK statically or dynamically? > I want to build FLTK statically. Be sure to link against the correct .lib files (fltk.lib, etc) generated by VS. Ignore the .dll's (fltk.dll), as they're only for non-static builds. Show us your compile/link line from the VS logs, that may help. I've always had good luck by just doing a build on of the FLTK test apps most like my program from within the VS IDE, slurping up the compile/link lines from the build logs, and shoving those into a Makefile. Builds should work if done from either a VS DOS Console, or by opening a regular DOS window and running the VCVARS32 batch script to init all the compiler variables. Either way you'll get 'cl' and 'link' into your PATH for doing command line compiles using VS (which I prefer to the IDE). ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #1718: FLTK "Basics intro" docs should cover begin() and end()
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1718 Version: 1.1-current It's been brought up on the group that there's insufficient coverage of FLTK's begin() end() in the basic docs for new users. It seems the concept of begin() and end() is a confusing one for new users, so it really should be covered right up front in the intro docs, specifically here: http://fltk.org/documentation.php/doc-1.1/basics.html#3_1 Link: http://www.fltk.org/str.php?L1718 Version: 1.1-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #1726: Fl_Browser docs need to document select() and selected() methods
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1726
Version: 1.1-current
Fl_Browser::selected() and select() are omitted from the Fl_Browser docs:
http://fltk.org/documentation.php/doc-1.1/Fl_Browser.html
This excerpt from Fl_Browser.H shows them to be Fl_Browser class methods:
* * *
int Fl_Browser::select(int line, int v) {
if (line < 1 || line > lines) return 0;
return Fl_Browser_::select(find_line(line), v);
}
int Fl_Browser::selected(int line) const {
if (line < 1 || line > lines) return 0;
return find_line(line)->flags & SELECTED;
}
* * *
Link: http://www.fltk.org/str.php?L1726
Version: 1.1-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] Text and labels do not resize in V1.1
Larry Finger wrote:
> I have converted my FLTK application to allow resizing of the window.
You can make a window resizable without subclassing.
Just the resizable() call should be all that's needed, eg. this being
a complete program that should resize correctly:
#include
#include
#include
int main() {
Fl_Window win(400,400,"Window");
Fl_Box box(10,10,400-20,400-20,"Test");
box.box(FL_FLAT_BOX);
box.color(FL_RED);
box.labelsize(20);
win.end();
win.resizable(box); // <-- make window resizable
win.show();
return(Fl::run());
}
> A sample showing the effect is shown below. Is this a bug or a "feature"?
I ran your program under 1.1.x 5917 on linux; it printed the word
'Test' in the center of the window, and when I resized the window,
'Test' stayed in the middle. What goes wrong on your end? What's the
platform?
BTW, some comments about the code posted:
This definition isn't needed:
> void show(int argc, char **argv) {
> Fl_Window::show(argc, argv);
> }
..since your subclass is public (public Fl_Window) that is the
default behavior, so the method doesn't need to be wrapperized.
> void draw(void) {Fl_Window::draw();}
..same here; not needed. That is the default behavior.
> void Resizable_Window::resize(int x, int y, int w, int h) {
> Fl_Window::resize(x, y, w, h); }
..same here; not needed. That is the default behavior.
I believe those 3 method definitions can all be removed
without affecting the behavior of the program, unless I'm
missing something.
These are basically all wrappers for what are already public
methods, so they're redundant.
> int main(int argc, char **argv)
> {
> Resizable_Window *main_Window = new Resizable_Window(50, 50, 200, 200,
> "Test Window");
> Fl_Box *b = new Fl_Box(0, 0, 200, 200);
> main_Window->size_range(0, 0, Fl::w(), Fl::h());
> Fl_Text_Display *o = new Fl_Text_Display(0, 100, 200 , 0, "TEST");
> o->labelsize(20);
> main_Window->resizable(b);
..that last line could also be 'main_Window->resizable(o);', and you
could skip the Fl_Box definition, and it should still act the same.
Also, note that an Fl_Text_Display widget is not going to display
anything unless you associate an Fl_Text_Buffer with it, eg:
http://seriss.com/people/erco/fltk/#Fl_Text_Display
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #1796: Fl_Window::size_range() docs should indicate zero a special value for minh/minw
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1796 Version: 1.1-current It would appear that if minh or minw are set to zero, the value is ignored, falling back to the fltk/window manager defaults. maxw/maxh document zero as a special value, but not minw/minh. Current docs read: minw and minh are the smallest the window can be. Suggested modification: minw and minh are the smallest the window can be. A value of zero for either will cause that value to be ignored, retaining the default behavior for that dimension. Link: http://www.fltk.org/str.php?L1796 Version: 1.1-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #1799: fltk-config and fltk2-config has bugs
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1799 Version: 1.1-current Gonzalo has identified bugs in fltk2-config which both FLTK1 and FLTK2 seem to have, e.g. % fltk2-config --use-images --libs /usr/local/lib/libfltk2.a ..seems to be missing the image lib. Gonzalo wrote that all these appeared to be wrong.. comments are mine. % fltk2-config --use-images --libs /usr/local/lib/libfltk2.a .. missing images. % fltk2-config --ldflags -L/usr/local/lib -lfltk2 -lX11 -lXi -lXinerama -lXft -lpthread -lm -lXext -lsupc++ (..not sure what's wrong with this one.) % fltk2-config --use-images --ldflags -L/usr/local/lib -lfltk2_images -lpng -lfltk2_images -ljpeg -lz -lfltk2 -lX11 -lXi -lXinerama -lXft -lpthread -lm -lXext -lsupc++ ..-lfltk2_images appears twice. % fltk2-config --use-images --ldstaticflags -L/usr/local/lib /usr/local/lib/libfltk2_images.a /usr/local/lib/libfltk2.a -lX11 -lXi -lXinerama -lXft -lpthread -lm -lXext -lsupc++ -lpng -lfltk2_images -ljpeg -lz ..bad ordering of libs, images appears twice. % fltk2-config --ldflags -L/usr/local/lib -lfltk2 -lX11 -lXi -lXinerama -lXft -lpthread -lm -lXext -lsupc++ % fltk2-config --ldstaticflags -L/usr/local/lib /usr/local/lib/libfltk2.a -lX11 -lXi -lXinerama -lXft -lpthread -lm -lXext -lsupc++ ..should probably be -lfltk2.a instead of /usr/local/lib/libfltk2.a Link: http://www.fltk.org/str.php?L1799 Version: 1.1-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #1801: When compiling FLTK2 using MinGW/MSYSmake fails.
Kevin Van Sickle wrote: > In a forum "http://www.mail-archive.com/[EMAIL PROTECTED]/msg01679.html" > I found that Ian the funkloard had a work around [..] ..Ian the what now? ;) My subscription to the Zeitgeist seems to have expired. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #1808: FLTK2's fluid does respect namespaces correctly
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1808
Version: 2.0-current
Ya, I don't think fluid is aware of certain C++ coding styles.
As a workaround for the short term, you might try making
two #include files, the first with the 'using namespace xxx {'
and the other with the '}'.
Link: http://www.fltk.org/str.php?L1808
Version: 2.0-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #1815: FLTK Tutorial 'Writing Your First Program' should cover begin()/end()
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1815 Version: 1.1-current As described in this article: http://fltk.org/newsgroups.php?gfltk.general+v:23821 ..the description of begin()/end() has somehow fallen out of the docs for 'Writing Your First Program': http://fltk.org/documentation.php/doc-1.1/basics.html#3_1 The old docs covered this (highlighted in red): http://seriss.com/people/erco/fltk/fltk-old-docs-page-1.png Suggest restoring that paragraph into the 1.x docs. Link: http://www.fltk.org/str.php?L1815 Version: 1.1-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #1815: FLTK Tutorial 'Writing Your First Program' should cover begin()/end()
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1815 Version: 1.1-current Actually, I think this is a dup of STR #1718: http://fltk.org/str.php?L1718 Apparently it's been fixed in SVN by Matt, but hasn't made its way to the website docs for 1.x. Link: http://www.fltk.org/str.php?L1815 Version: 1.1-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] fltk2-config --compile is not working
varun mittal wrote: > [EMAIL PROTECTED]/fltk]$ fltk2-config --compile test.cpp > gcc -I/usr/local/include -I/usr/include/freetype2 -Wno-non-virtual-dtor > -o test test.cpp -L/usr/local/lib /usr/local/lib/libfltk2.a -lX11 -lXi > -lXinerama -lXft -lpthread -lm -lXext -lsupc++ > test.cpp:1:19: error: FL/Fl.H: No such file or directory > test.cpp:2:26: error: FL/Fl_Window.H: No such file or directory > test.cpp:3:23: error: FL/Fl_Box.H: No such file or directory Looks like test.cpp is an FLTK1 program (FL/Fl.H, etc), but it's being compiled with FLTK2 (fltk2-config). Either install FLTK1 and build with that (fltk-config) or convert test.cpp to FLTK2's coding style. #include is FLTK1 style #include is FLTK2 style ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #1817: Fl_Help_View memory leak
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1817 Version: 1.1.7 I'm not too familiar with Fl_Help_View, and haven't tried the patch, but it seems it might make sense to free the image when the page is changed (eg. clicking on a link to a new page, or hitting forward/back buttons) or when the widget is destroyed. This way when the page needs to casually be redrawn (eg. if the screen is resized or there's a change in the mouse selection), the image(s) don't need to be reloaded from disk each time. So in other words cache the image only for the current page, and clear it when the page is changed or the widget destroyed. Link: http://www.fltk.org/str.php?L1817 Version: 1.1.7 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #1844: fltk1.1.x: Add a clip() method toFl_Group
Michael Sweet wrote:
> Only a clip on/off method was implemented, as an X,Y,W,H method would not
> be binary-compatible.
Great, much thanks!
BTW, I think one of the main issues of the original thread
was that the clip should take into account the current box() type,
so that the children don't overdraw the widget's box(), if one is
supplied.
I think that might be absent here:
> --- src/Fl_Group.cxx (revision 5990)
> +++ src/Fl_Group.cxx (working copy)
> @@ -536,6 +536,9 @@
>
> void Fl_Group::draw_children() {
>Fl_Widget*const* a = array();
> +
> + if (clip_children()) fl_push_clip(x(), y(), w(), h());
> +
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #1867: docs on FL_MOVE should indicate return(1) from FL_ENTER needed
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1867 Version: 1.1-current I've seen folks ask quite a bit about apps not receiving FL_MOVE events, most recently: http://fltk.org/newsgroups.php?gfltk.general+v:24635 The question probably wouldn't come up if the docs for FL_MOVE (in the "Handling Events" section of the docs) indicated that to receive FL_MOVE, the app needs to return(1) in response to FL_ENTER. Currently only the docs for FL_ENTER mention this, but I don't think folks will know to look there, since that's not the event they'll be focused on. Link: http://www.fltk.org/str.php?L1867 Version: 1.1-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #1886: Fl_File_Chooser::value() docs: indicate index values are 1-based
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1886
Version: 1.1-current
Fl_File_Chooser::value() should indicate the index values are 1-based.
Also, would be handy to show an example for() loop showing how to walk the
filenames, eg:
// Get list of filenames user selected from a MULTI chooser
for ( int t=1; t<=chooser->count(); t++ ) {
const char *filename = chooser->value(t);
..
}
Link: http://www.fltk.org/str.php?L1886
Version: 1.1-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #1914: fltk-2.0.x-r6087 doesn't compile
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1914 Version: 2.0-current I think the cause of this error is fluid being called by the Makefile to convert the .fl into source code, and the user's shell doesn't have access to the Xwindow manager (it shouldn't have to). The FLTK core folks might need to look into this one to see if fluid invoked from the command line (as per the Makefile's use of it) is trying to access the window manager when it shouldn't. It might be something as simple as some FLTK commands in the main() of fluid that are happening before the argument line is checked. Link: http://www.fltk.org/str.php?L1914 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #1974: Stray html in Fl_Valuator docs
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1974 Version: 1.3-current The docs on this page change into "tiny type" in the docs for the 'range()' method: http://fltk.org/documentation.php/doc-1.1/Fl_Valuator.html#Fl_Valuator I think the problem is some stray "superscript" html near the "1/10" text in the method above, eg. an unclosed "SUP" html tag. Link: http://www.fltk.org/str.php?L1974 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2032: Fl_Group::resize() should update own xywh before updating children
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2032 Version: 1.1.9 A widget's resize() method will always see stale info if it looks up at its parent's xywh values. This is because Fl_Group::resize() doesn't update its own public xywh values until after the children's resize() methods have been called. Would like to suggest this is a bug, and that Fl_Group::resize() should update its own public xywh values first, before invoking the children's resize() methods. I think Albrecht has already recommended a patch that is going in the right direction, will try to attach that here. Thread on fltk.general (08/30/2008): Subject: During widget resize(), how to get the current window's width/height? ..and thread on fltk.development (08/31/2008): "Subject: RFE: Fl_Group::resize() additional methods for fltk 1.x" Link: http://www.fltk.org/str.php?L2032 Version: 1.1.9 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] Compiling fltk2.0 under VC++ 2008
brian wrote: > Hello, > > I'm not sure this is the right place to post this, but I'm trying to build > this version of fltk under windows has it is explained in the README.windows > file using VC++. > > In the file it explains how to use VC++ 6.0, but at the time I only have VC++ > 2008 installed and I'm not getting good results with it, first was cairo not > installed but that wasn't a real problem, but now it asks for "fltk2d.lib" > which does not exists. > > Is this just a VC++ version problem (because of the several conversions it > needs to make on the project to convert from VC++ 6.0 to 2008)? Right, you should actually post this to fltk.general instead of fltk.bugs. Post there, and someone will be able to help you, I'm sure. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2084: ScrollGroup fails to redraw when its contents shrink.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2084 Version: 2.0-current Tried the scroll program; could not confirm on fedora3 with latest svn. When I clicked the buttons, they deleted all the way to the last, without leaving phantoms behind. Might be platform specific.. what platform are you using? Also, you might try setting the box type for the scroll to be a flat box. IIRC, FLTK defaults to 'no box' for the bg, causing the bg for the scroller to not draw, which might explain the phantom images. Link: http://www.fltk.org/str.php?L2084 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2084: ScrollGroup fails to redraw when its contents shrink.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2084 Version: 2.0-current > Greg, did you comment out that "data->scroll->redraw();" at line 29? I compiled the code unmodified; just compiled and ran under latest fltk-2.0 (which was a complete re-checkout of 2.0-svn to an empty directory, compiled everything from scratch, then built OP's app in the test directory) Maybe it's window manager/graphics card specific? Link: http://www.fltk.org/str.php?L2084 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2085: Audit new utf8 files for LGPL compliance
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2085 Version: 1.3-feature As per discussion with Mike, need to contact Jean-Marc regarding new utf8 code to see if we can make it all LGPL compliant. Link: http://www.fltk.org/str.php?L2085 Version: 1.3-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2084: ScrollGroup fails to redraw when its contents shrink.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2084 Version: 2.0-current > > I compiled the code unmodified; > That's the point. The posted code _contains_ the workaround Ohh... sorry, I missed that. I thought the posted code /showed/ the problem, not fixed it..! ;) Yes, commenting out the redraw, I get the phantom buttons on fedora3. It seems like Group::remove() should tell the parent to redraw() automatically, and it would seem that it's not. I suppose if that's the case and intentional, Group::remove() should probably document this. Maybe the reason remove() doesn't tell the parent to redraw() is it might be ineffective to do so if the parent were 'see through' (NO_BOX), in which case to get desired results, FLTK would need to walk up the widget tree to find the correct widget to redraw(), which is maybe impractical or inexact. Or, maybe it's just an omission.. ;) Link: http://www.fltk.org/str.php?L2084 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2085: Audit new utf8 files for LGPL compliance
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2085 Version: 1.3-feature Yes, he da man. A major undertaking for one person. Be sure to grep around for his notice. Please note it's also in src/fl_utf8.cxx as well as src/xutf8/*. Link: http://www.fltk.org/str.php?L2085 Version: 1.3-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2085: Audit new utf8 files for LGPL compliance
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2085 Version: 1.3-feature Right, I think Mike is taking this on. Probably his confirmation should be kept somewhere safe. Link: http://www.fltk.org/str.php?L2085 Version: 1.3-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2086: Menu crashes with UTF-8 menu text entries
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2086 Version: 1.3-current Confirmed on Vista.. menu becomes as wide as the screen, and certainly taller than it needs to be. I've attached a screenshot here as "bigmenu-vista.jpg". Link: http://www.fltk.org/str.php?L2086 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 #2086: Menu crashes with UTF-8 menu text entries
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2086 Version: 1.3-current I think the issue here is the "List" submenu item string contains \n's. Not sure this is a bug, so much as an unexpected/unsupported use of menu items. I guess the question is, should menu items support multi-line strings? My guess is probably not.. Link: http://www.fltk.org/str.php?L2086 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 #2086: Menu crashes with UTF-8 menu text entries
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2086 Version: 1.3-current The memsets() are extraneous and should not be needed; the strcpy()s handle initializing the string. Link: http://www.fltk.org/str.php?L2086 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 #2086: Menu crashes with UTF-8 menu text entries
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2086 Version: 1.3-current I wasn't able to test this on my XP box because I didn't have the Chinese fonts installed. Just got around to adding them: 1. Control Panel->Regional And Language Options 2. Clicked the "Advanced" tab, and under "Code Page Conversion Tables", checkbox'ed the "10002 MAC - Traditional Chinese Big 5" font 3. Went into the "Languages" tab, and checkbox'ed "Install files for East Asian Languages" 4. (Used the Windows XP CD where needed) 5. Reboot Now when I run the app, it runs fine on XP in all respects: * Title bar looks like it should. * No matter what I do with the menus (tried about 15 times), I could not replicate the giant "List" menu. Tried opening the first "Submenu" in different ways (dragging, click-releasing), and optionally navigating its submenus, then sliding into the "List" menu.. always the List menu displayed correctly and correctly sized. I'm using the same executables I used for the Vista test. I've added "normal-winxp.jpg" screenshot here, which looks perfectly fine. One thing I noticed in Ian's zip version of the program was leading spaces in some of the font names. Removing the leading space, but that didn't seem to change the behavior in any way I could see. In fact, I found I could comment out *all* the Fl::set_font() stuff, and it still worked fine. Something I noticed about 1.3.x (and like!) is that no set_font() stuff was needed to get the Asian fonts to display. Of interest, Albrecht, my fonts look a little different than yours. Your menus seem to have serifs, whereas mine seem to look more like the usual Helvetica. With or without the set_font() I get this, and with or without the leading space in the font name. In my case I'm using the VS 7 .NET compiler, not sure if that matters. And when adding the font in the control panel, I /only/ checkbox'ed the "10002 MAC - Traditional Chinese Big5" font; I ignored the other fonts that said things like "Simplified Chinese". Link: http://www.fltk.org/str.php?L2086 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 #2086: Menu crashes with UTF-8 menu text entries
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2086 Version: 1.3-current Link: http://www.fltk.org/str.php?L2086 Version: 1.3-current<>___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #2094: Fl_Input: FL_WHEN_ENTER_KEY_ALWAYS triggering callbacks on focus changes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2094
Version: 1.3-current
If Fl_Input is created with when(FL_WHEN_ENTER_KEY_ALWAYS),
the callback is triggered even when there's simple focus changes.
To see the problem:
1) Run attached program;
2) Type into "Input A" and hit 'Tab' to move focus to "Input B"
3) The input callback is incorrectly triggered.
4) Click back and forth between "Input A" and "Input B"
5) Whenever you click on Input B, Input A's callback is
incorrectly triggered.
It would appear that FL_LEAVE events are triggering FL_ENTER callbacks.
Link: http://www.fltk.org/str.php?L2094
Version: 1.3-current// Demonstrate problem with when(FL_ENTER_KEY_ALWAYS)
#include
#include
#include
#include
void Input_CB(Fl_Widget *w, void *data) {
fprintf(stderr, "INPUT CALLBACK FOR '%s'\n", w->label());
}
int main() {
Fl_Window win(400, 100);
Fl_Input a(120,10,200,25,"Input A");
a.when(FL_WHEN_ENTER_KEY_ALWAYS);
a.callback(Input_CB);
Fl_Input b(120,40,200,25,"Input B");
b.when(FL_WHEN_ENTER_KEY);
b.callback(Input_CB);
win.show();
return(Fl::run());
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2094: Fl_Input: FL_WHEN_ENTER_KEY_ALWAYS triggering callbacks on focus changes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2094
Version: 1.3-current
Seems the problem is right after an FL_UNFOCUS comes to the widget.
I'm thinkin the problem might be an unintended fallthrough in the case
statement for FL_UNFOCUS in Fl_Input_::handletext() (see <-- marker):
snip
case FL_UNFOCUS:
if (active_r() && window()) window()->cursor(FL_CURSOR_DEFAULT);
if (mark_ == position_) {
if (!(damage()&FL_DAMAGE_EXPOSE)) {minimal_update(position_);
erase_cursor_only = 1;}
} else //if (Fl::selection_owner() != this)
minimal_update(mark_, position_);
// <-- UNINTENTIONAL FALLTHRU?
case FL_HIDE:
fl_reset_spot();
if (!readonly() &&
(when() & (FL_WHEN_RELEASE | FL_WHEN_NOT_CHANGED)))
maybe_do_callback();
return 1;
snip
I think FL_UNFOCUS is falling through, to FL_HIDE's maybe_do_callback().
Link: http://www.fltk.org/str.php?L2094
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 #2094: Fl_Input: FL_WHEN_ENTER_KEY_ALWAYS triggering callbacks on focus changes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2094
Version: 1.3-current
What worked for me was to add a 'return 1' just above FL_HIDE, eg:
--- snip
case FL_UNFOCUS:
if (active_r() && window()) window()->cursor(FL_CURSOR_DEFAULT);
if (mark_ == position_) {
if (!(damage()&FL_DAMAGE_EXPOSE)) {minimal_update(position_);
erase_cursor_only = 1;}
} else //if (Fl::selection_owner() != this)
minimal_update(mark_, position_);
return 1;// <-- ADD THIS
// <-- ADD BLANK LINE
case FL_HIDE:
fl_reset_spot();
--- snip
Looking at older versions, it looks like it's been an omission for a long
time, but wasn't noticeable until a recent logic change in FL_HIDE that
includes testing for FL_WHEN_NOT_CHANGED causes the fallthrough to invoke
the callback unexpectedly.
So I'm pretty sure that 'return 1;' needs to be in there to prevent the
fallthrough -- I don't think that fallthrough has ever been intentional.
Link: http://www.fltk.org/str.php?L2094
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 #2094: Fl_Input: FL_WHEN_ENTER_KEY_ALWAYS triggering callbacks on focus changes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2094
Version: 1.3-current
Yes, I think you're right.
> IMHO, the problem is that FL_WHEN_ENTER_KEY_ALWAYS
> implicitly sets the FL_WHEN_NOT_CHANGED bit, and this can fire the
> callback even if the value has _not_ changed.
Agreed.
Seems like the logic isn't clear -- FL_WHEN_ENTER_KEY_ALWAYS is supposed
to only call the callback when Enter is hit, regardless of a change in
data, according to its docs.
But FL_WHEN_ENTER_KEY_ALWAYS is currently a combo of FL_WHEN_ENTER_KEY and
FL_WHEN_NOT_CHANGED, which sounds right if you read the flag's names
literally: "do the callback when Enter is pressed, whether or not the
value was changed".
But the docs for FL_WHEN_NOT_CHANGED don't actually mean that; the docs
for that flag say to do the callback "whenever the user interacts with the
widget", which is really NOT something FL_WHEN_ENTER_KEY_ALWAYS is supposed
to do.
It sounds like FL_WHEN_ENTER_KEY_ALWAYS should be a special case unto
itself with a special bit to indicate the 'ALWAYS', eg. changing the enum
definition to include FL_WHEN_ENTER_KEY plus an unused bit:
FL_WHEN_ENTER_KEY_ALWAYS=(16+8),
..and changing Fl_Input_::maybe_do_callback()
OLD: if (changed() || (when()&FL_WHEN_NOT_CHANGED)) {
OLD:do_callback();
OLD: }
NEW: if (changed() ||
NEW: ((when()&FL_WHEN_NOT_CHANGED) ||
NEW: ((when()&FL_WHEN_ENTER_KEY_ALWAYS)==FL_WHEN_ENTER_KEY_ALWAYS)))
NEW:do_callback();
NEW: }
or something like that. Above not tested, but maybe that's the solution.
Not sure myself.
Link: http://www.fltk.org/str.php?L2094
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 #2094: Fl_Input: FL_WHEN_ENTER_KEY_ALWAYS triggering callbacks on focus changes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2094 Version: 1.3-current Meh, I think actually the enum can't be changed, because the 1.1.x docs for Fl_Input::when() say (FL_WHEN_ENTER_KEY|FL_WHEN_NOT_CHANGED) should give the same effect as FL_WHEN_ENTER_KEY_ALWAYS. So I guess the logic in the code must check for that combo of flags as a special case, which means tests for FL_WHEN_NOT_CHANGED must also check for the existence of the ENTER_KEY flag. Will try to offer a better patch suggestion over the next few days, if someone doesn't beat me to it. Link: http://www.fltk.org/str.php?L2094 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #2099: Can't post comments to article
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2099 Version: 2.0-feature Tried making a comment to an article, but gives an error about a field not being specified, but no field appears to be unspecified. Here's a screenshot after hitting 'Submit Comment' showing the problem: http://seriss.com/people/erco/fltk/tmp/cantpostcomment.jpg Am I missing something? Link: http://www.fltk.org/str.php?L2099 Version: 2.0-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2099: Can't post comments to article
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2099 Version: 2.0-feature BTW, I see might not be supported (seems unlikely), but changing that to doesn't change the error. Link: http://www.fltk.org/str.php?L2099 Version: 2.0-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #2100: Can't make comments on 'Links' page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2100
Version: 1.3-current
Tried to submit a comment to this link, indicating the link is stale:
http://fltk.org/links.php?V99+Q
Typing in a comment and hitting 'Submit Comment' gives a "404 Not Found".
Apparently the URL for the posting is slightly malformed:
http://fltk.org/links.php%5fV99#_USER_COMMENT_1541
..that %5f ("_") directly after the .php is probably the culprit.
BTW one other problem; yesterday I posted a similar bug for:
Application: FLTK Web Site
..but the bug report doesn't show up in the bug report search.
Is this a bug in the bug search form?
Link: http://www.fltk.org/str.php?L2100
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 #2100: Can't make comments on 'Links' page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2100 Version: 1.3-current Just checked the latter; seems indeed I can't find this STR when doing a search for eg: creator:greg.ercolano ..or even just doing a search for: comments ..comes up blank, which should match because it's the Subject: of this STR. Link: http://www.fltk.org/str.php?L2100 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 #2101: Fl_Window not found in fl_set_spot
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2101
Version: 1.3-current
Using Ian's example and adding a second window and some
output widgets in addition to input, I can get it to crash
right away.
There's probably more widgets here than necessary, but it's probably
useful for debugger tests to coerce the crash.
snip
#include
#include
#include
#include
#include
#include
Fl_Double_Window *win1 = 0;
Fl_Double_Window *win2 = 0;
Fl_Input *in1 = 0;
Fl_Input *in2 = 0;
Fl_Input *in3 = 0;
Fl_Input *in4 = 0;
Fl_Input *in5 = 0;
Fl_Input *in6 = 0;
Fl_Output *out1 = 0;
Fl_Output *out2 = 0;
Fl_Button *but1 = 0;
void update_text(void *) {
static char message[128];
static int count = 0;
count++;
sprintf(message, "String Number %d", count);
in1->value(message);
in4->value(message);
out1->value(message);
out2->value(message);
Fl::repeat_timeout(0.5, update_text);
}
void OpenDialog_CB(Fl_Widget*,void*) {
win2->show();
}
int main(int argc, char **argv) {
// MAIN WINDOW
{
win1 = new Fl_Double_Window(522, 210, "Window #1");
in1 = new Fl_Input(100, 10, 300, 25, "Changes");
in2 = new Fl_Input(100, 40, 300, 25, "Fixed #1");
in2->value("Fixed Text Here");
in3 = new Fl_Input(100, 70, 300, 25, "Fixed #2");
in3->value("More Fixed Text Here");
out1 = new Fl_Output(100, 100, 300, 25, "Output");
but1 = new Fl_Button(100,130,150,25,"Push For Dialog");
but1->callback(OpenDialog_CB);
win1->end();
}
// SECONDARY WINDOW WITH INPUT/OUTPUT
{
win2 = new Fl_Double_Window(522, 210, "Window #2");
win2->begin();
in4 = new Fl_Input(100, 10, 300, 25, "Changes");
in5 = new Fl_Input(100, 40, 300, 25, "Fixed #1");
in5->value("Fixed Text Here");
in6 = new Fl_Input(100, 70, 300, 25, "Fixed #2");
in6->value("More Fixed Text Here");
out2 = new Fl_Output(100, 100, 300, 25, "Output");
win2->end();
}
win1->show(argc, argv);
Fl::add_timeout(0.1, update_text);
return Fl::run();
}
snip
Link: http://www.fltk.org/str.php?L2101
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 #2085: Audit new utf8 files for LGPL compliance
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2085 Version: 1.3-feature Are the patches checked in? I just did a checkout of fltk-1.3.x-svn, and looks like these in the xutf8 directory still have the old headers: keysym2Ucs.c test.c test2.c ucs2fontmap.c utf8Input.c utf8Utils.c utf8Wrap.c Link: http://www.fltk.org/str.php?L2085 Version: 1.3-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2085: Audit new utf8 files for LGPL compliance
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2085 Version: 1.3-feature Afraid I don't have SVN write access or chocolates to offer ;) Because Jean-Mark Lienher == "oksid" == "O'ksi'D" == "oKsidiZer" -- they're all one and the same person -- the files containing pure O'ksi'D copyright notices should also be switched over to LGPL copyrights. Since this STR is a record of changing the headers, we should probably supply complete proof of this. First, his emails from the newsgroup show the association: v From: Jean-Marc Lienher <[EMAIL PROTECTED]> Date: Fri, 24 Sep 2004 10:09:25 + (UTC) ..and the new LGPL copyright notices you have already in place show this association as well: v // Author: Jean-Marc Lienher ( http://oksid.ch ) // Copyright 2000-2003 by O'ksi'D. ^^^ ..and finally, for completeness, it seems a good idea to attach a screenshot of his open source website mentioned in the above existing LGPL and older O'ksi'D copyright notices, http://www.oksid.ch/, which is currently forwarding over to: http://www.whoow.org/people/Jean-Marc.Lienher/index_en.html ..also shows this association; attached here as 'oksidizer-screenshot.png'. Link: http://www.fltk.org/str.php?L2085 Version: 1.3-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2085: Audit new utf8 files for LGPL compliance
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2085 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2085 Version: 1.3-feature<>___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2094: Fl_Input: FL_WHEN_ENTER_KEY_ALWAYS triggering callbacks on focus changes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2094 Version: 1.3-current I think I'm going with this hotfix for now (leaving the FL_UNFOCUS fallthrough): case FL_HIDE: fl_reset_spot(); if (!readonly() && -(when() & (FL_WHEN_RELEASE | FL_WHEN_NOT_CHANGED))) +(when() & (FL_WHEN_RELEASE | FL_WHEN_NOT_CHANGED)) && +!(when() & FL_WHEN_ENTER_KEY)) maybe_do_callback(); return 1; Probably wrong, but I need to do something. Link: http://www.fltk.org/str.php?L2094 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 #2094: Fl_Input: FL_WHEN_ENTER_KEY_ALWAYS triggering callbacks on focus changes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2094 Version: 1.3-current Not sure what to offer without making a new bitflag. I noticed some other bad behavior with the current release as well: the callback is triggered even if the window is just minimized (windows), and also when the app is closed (win/mac). In my app this is fatal, because the input can contain a command that is executed when the callback is called, which is destructive if run when the user doesn't expect it. Link: http://www.fltk.org/str.php?L2094 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] fltk 1.3.x [Windows] copy/paste (^C/^V) not working in Fl_Text_Editor
Is it just me, or are other people noticing ^C/^V not working in the editor demo on Windows with 1.3.x svn? Seems ok on Linux. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #2104: copy/paste not working under windows
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2104 Version: 1.3-current Can't copy/paste between fltk widgets under windows with 1.3.x-svn current. Works OK to copy text from other programs to FLTK and vice versa, but not within an FLTK app. Replication: 1) Run the editor and paste some text into it from DOS. Should work fine, either with Edit>Paste or ^V. 2) Now highlight some text within the editor, and try to paste it else where in the editor, either with ^C/^V, or with Edit>Copy/Paste. Nothing happens. Seems to be a problem with both input widgets and the editor. Link: http://www.fltk.org/str.php?L2104 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] fltk 1.3.x [Windows] copy/paste (^C/^V) not working in Fl_Text_Editor
Greg Ercolano wrote: > Is it just me, or are other people noticing ^C/^V not working in the editor > demo > on Windows with 1.3.x svn? More details under windows: Seems to be a general problem with copy/paste within an FLTK app. I can copy text from other programs (eg. DOS) to FLTK (eg. editor, Fl_Input..), and from FLTK into other programs. But I can't seem to highlight text within FLTK, and then paste the text elsewhere within FLTK, either to the same widget, or another widget. Doesn't seem to be a keyboard thing.. both ^C/^V /and/ the Edit>Copy and Edit>Paste menus are affected, so it seems to be the actual FLTK copy/paste mechanism with FLTK under windows. I've made STR 2104 for this: http://fltk.org/str.php?L2104 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2104: copy/paste not working under windows
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2104 Version: 1.3-current I poked at this a bit. Seems the crux of it is Fl::paste()'s call to GetClipboardData() is returning NULL. Should be a simple matter of looking at GetLastError() to see what the problem is, but unfortunately the error number is always f...@#ing zero. Anyone have the source code to GetClipboardData() so we can debug that problem? ;) Another issue, I poked around in the Fl::copy() function, I decided to check the return value of all the clipboard functions just to see what they were; seems SetClipboardData() is returning NULL, indicating a failure (and of course GetLastError() is returning zero, so no help there). But since pasting works into other windows, it must be working to some extent. I'm not sure how to trace further, as the Microsoft functions don't seem to be returning any useful error information. But the Microsoft clipboard functions /seem/ to be the issue here. Link: http://www.fltk.org/str.php?L2104 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 #2104: copy/paste not working under windows
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2104
Version: 1.3-current
I looked to the older FLTK code, and the one thing that seemed different is
that fl_i_own_selection[clipboard] was being set to 1, whether
OpenClipboard() worked or not.
In the new FLTK code, fl_i_own_selection[clipboard] is set to zero if
OpenClipboard() works (which it does in my case).
So I found I could 'fix' the problem by setting it to 1 in both cases, eg.
this one line change to Fl::copy() in Fl_win32.cxx:
if (clipboard) {
// set up for "delayed rendering":
if (OpenClipboard(fl_xid(Fl::first_window( {
// if the system clipboard works, use it
EmptyClipboard();
SetClipboardData(CF_TEXT, NULL);
CloseClipboard();
- fl_i_own_selection[clipboard] = 0;
+ fl_i_own_selection[clipboard] = 1;
} else {
// only if it fails, instruct paste() to use the internal buffers
fl_i_own_selection[clipboard] = 1;
}
This restores the old behavior, but seems wrong the way I read the
intention of the code.
But given the above described behavior of the Microsoft clipboard stuff
failing without error codes, it seems like something might be wrong in
fltk's handling of the MS clipboard functions for 'delayed rendering'.
HTH.
Link: http://www.fltk.org/str.php?L2104
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 #2104: copy/paste not working under windows
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2104 Version: 1.3-current (I should preface the following with the disclaimer I'm not at all familiar with the WIN32 clipboard functions, or how it's all supposed to work.) Regarding CF_TEXT vs. CF_UNICODETEXT, you might be right. I just did a few more tests putting printf()s at all the OpenClipboard(), SetClipboardData(), and GetClipboardData() calls, and noticed the chain of events during ^C and ^V are: ^C -- 1) calls OpenClipboard(fl_xid(..)) 2) calls SetClipboardData(CF_TEXT), function returns NULL(!) ^V -- 1) calls OpenClipboard(NULL) 2) calls GetClipboardData(CF_TEXT), which.. 2a) causes a WM_RENDERFORMAT event which.. 2b) calls SetClipboardData(CF_UNICODETEXT) which returns OK 2c) causes GetClipboardData() to return NULL, which causes fltk to fail to do its paste (and GetLastError() is zero..!) So if GetClipboardData() is returning NULL because the WM_RENDERFORMAT event it causes is first doing a SetClipboardData(CF_UNICODETEXT), that might explain the NULL return for the CF_TEXT get request.. incompatible data types? (would be nice if GetLastError() indicated this..!) I definitely recommend adding printf()s to the clipboard funcs, and esp. monitor the return values for errors. Link: http://www.fltk.org/str.php?L2104 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 #2107: WIN32: Fl::add_fd does not work well with anonymous pipes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2107 Version: 1.1.9 Is the data you're transmitting ASCII and delimited by CRLFs? If so, make sure the child is flushing its output regularly enough. If you're sending binary data, be sure both ends of the pipe agree on the blocking size. Try to include a *small* example program here showing the FLTK app and the child, and how the two are interacting. FWIW, I decided quickly Microsoft did not do a great job implementing the unixy functions for pipes (eg. select()/read()/etc. for pipes), however, I found their WIN32 API calls like CreatePipe() + CreateProcess() (and related calls) are fairly reliable. To use them effectively, I found it involved making a child thread to handle reading the pipe, so if it blocked, FLTK was unaffected. When data was fully ready, the child would dump it in a buffer common to the two threads, and set a flag. The FLTK parent thread would use an FLTK timer to keep an eye on the flag, and when set, would lock the data and read it, then clear the flag. This way there was no chance the FLTK thread would hang up waiting for data; the child thread would deal with it, and could hang as much as it liked. Link: http://www.fltk.org/str.php?L2107 Version: 1.1.9 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2107: WIN32: Fl::add_fd does not work well with anonymous pipes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2107 Version: 1.1.9 > I find that, under WIN32, Fl::add_fd works only superficially > when the monitored file descriptor is an anonymous pipe. I don't > know if you know that already perfectly, but the documentation > is silent on this subject. BTW, the docs on Fl::add_fd() seem to be fairly distinct about this: http://fltk.org/documentation.php/doc-1.1/Fl.html#Fl.add_fd Quoting the docs: "Under UNIX any file descriptor can be monitored (files, devices, pipes, sockets, etc.) **Due to limitations in Microsoft Windows, WIN32 applications can only monitor sockets.**" So I read that to mean what you're doing is specifically not supported. I think this limitation has to do with how Microsoft implemented select() for BSD network sockets only, and not an across the board solution for all the things the win32 select() function supports, such as pipes.. named or otherwise. I think you're right to follow your instincts to go with the WIN32 API calls under windows. My reply above about how to use a child thread to read the pipe into a buffer and an FLTK timer to lock/read the buffer is a reliable method. Link: http://www.fltk.org/str.php?L2107 Version: 1.1.9 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2108: fl_rect() should document mixing fl_line_style() may be unpredictable
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2108 Version: 1.3-current Docs for fl_rect() should indicate what negative side effects fl_line_style() may cause, and what behaviors are guaranteed (if any). Example: line thickness >0 can cause the rectangle to draw outside the xywh region (significant when drawing borders around widgets), and pixel centering may not be guaranteed (causing lopsided rectangles when clipped at the xywh boundary). On win32, there appears to be a problem with endcaps at the lower right corner. A thread in fltk.general entitled "draw results differ in linux and mac" (started 12/19/08) raises details of this STR. At very least, it should mention fl_line_style() may cause unexpected results, and should probably cover whether dotted lines are supported or not. (Apparently internally fl_rect() is /not/ implemented as 4 fl_line() calls, which folks might assume) Link: http://www.fltk.org/str.php?L2108 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 #2108: fl_rect() should document mixing fl_line_style() may be unpredictable
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2108 Version: 1.3-current It looks like the real intention of this call is for only drawing 1-pixel rectangles as efficiently as possible, and it should maybe be explicitly noted that fl_rect() is /not/ intended as a convenience function for drawing four fl_lines(). Maybe the docs should also recommend if >1 pixel thick rectangles are desired, four fl_line() calls should be used instead, since internally fl_rect() is not necessarily the equivalent of four fl_line() calls. Link: http://www.fltk.org/str.php?L2108 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 #2108: fl_rect() should document mixing fl_line_style() may be unpredictable
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2108 Version: 1.3-current Link: http://www.fltk.org/str.php?L2108 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 #2108: fl_rect() should document mixing fl_line_style() may be unpredictable
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2108 Version: 1.3-current If fl_rect() is intended to honor fl_line_style(), then I should point out on win32, fl_rect() + fl_line_style(5) makes weird corners. See attached fl_rect.png image to see the problem.. seems to be the line caps. There are similar problems with a line style of 2 as well, just not as pronounced. Link: http://www.fltk.org/str.php?L2108 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2112: OSX: changing a window's size() affects size_range() max
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2112 Version: 1.3-current I find if I set the size_range() to a minimum and no maximum, the window can be resized as one would expect. But if later the size() is set, it seems to have the effect of setting the maximum size_range() to the size() value. Attached foo.cxx is a small demo of the problem. With 1.3.x, the user CAN'T enlarge the window.. with 1.1.x (eg. 1.1.7), the user can. Can't replicate the problem on linux or win32, so it seems to be Mac specific. Link: http://www.fltk.org/str.php?L2112 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 #2112: OSX: changing a window's size() affects size_range() max
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2112
Version: 1.3-current
Link: http://www.fltk.org/str.php?L2112
Version: 1.3-current#include
#include
#include
int main() {
Fl_Window win(640, 480);
win.resizable(win);
win.show();
win.size_range(320, 240); // minimum, no max
win.size(600,300); // <-- PROBLEM HERE: PREVENTS USER FROM SIZING
LARGER THAN 600/300 IN 1.3.x
return(Fl::run());
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2114: Fl_Browser::clear() is not clearing 'last' to zero
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2114 Version: 1.3-current I'm fairly sure Fl_Browser::clear() is neglecting to set: last = 0; Link: http://www.fltk.org/str.php?L2114 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 #2115: Misplacement of text in Fl_Text_Editor and probably Fl_Text_Display
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2115 Version: 1.3-current Yes, I've noticed this too while using the source code editor in fluid (1.3.x-svn); just insert/deleting regular ascii text leaves "digital drit" along the upper most pixels of the line. I see this in both fltk 1.3.x-svn and fltk 1.1.x-svn, so it's not the UTF8 merge. Looks to me like font drawing is 1 pixel higher than expected; attached 4x closeup of the 1.1.x and 1.3.x fluid code editor screens shows the top line of text's top pixel is clipped off the screen. (red arrows in attached "code-editor.png" image) Also, possibly a different problem, the rows of text are touching each other; bottom-most pixel of each line is adjacent to the top-most pixel of the line below it (orange arrows). Normally there's a few scanlines between lines of text (see firefox text editor closeup at the right of the "code-editor.png" image) Link: http://www.fltk.org/str.php?L2115 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 #2115: Misplacement of text in Fl_Text_Editor and probably Fl_Text_Display
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2115 Version: 1.3-current Link: http://www.fltk.org/str.php?L2115 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 #2115: Misplacement of text in Fl_Text_Editor and probably Fl_Text_Display
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2115 Version: 1.3-current Here's something else, also possibly related. Regarding attached image "xft-vs-no-xft.png"; a comparison of the fluid text editor under linux with XFT enabled vs. disabled. Seems with XFT off: o The text doesn't clip off the top of the screen o There's some whitespace between the rows of text. o No 'digital drit' during insert/delete This is something I've always suspected; when testing my Fl_Gel_Tabs and Fl_Matte_Button widgets, I've noticed that text that should always be vertically centered is off by a vertical pixel or two, depending on whether XFT is enabled or not. Link: http://www.fltk.org/str.php?L2115 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 #2115: Misplacement of text in Fl_Text_Editor and probably Fl_Text_Display
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2115 Version: 1.3-current Link: http://www.fltk.org/str.php?L2115 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 #2115: Misplacement of text in Fl_Text_Editor and probably Fl_Text_Display
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2115 Version: 1.3-current A few other things I noticed while poking at this. button-centered-text.png This screenshot compares a button drawn with XFT off vs. on, showing the text vertical positioning being off a few pixels inside buttons, which means the problem might not just be the text editor. text-with-box.png text-with-box.cxx - This screenshot (and example program that generated it) shows a comparison of XFT on vs. off, black text drawn over a red box defined by fl_measure(), to see if the text falls within the box area. It's interesting to see the position offsets of the text using the various methods of text area computations, including Ian's new fl_text_extents() function, which seems to be the most accurate of all the methods. Link: http://www.fltk.org/str.php?L2115 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 #2115: Misplacement of text in Fl_Text_Editor and probably Fl_Text_Display
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2115 Version: 1.3-current Link: http://www.fltk.org/str.php?L2115 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 #2115: Misplacement of text in Fl_Text_Editor and probably Fl_Text_Display
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2115 Version: 1.3-current Link: http://www.fltk.org/str.php?L2115 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 #2115: Misplacement of text in Fl_Text_Editor and probably Fl_Text_Display
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2115
Version: 1.3-current
Link: http://www.fltk.org/str.php?L2115
Version: 1.3-current#include
#include
#include
#include
// TEST TEXT POSITIONING WITHIN BOX USING VARIOUS METHODS
class TestBox : public Fl_Box {
public:
TestBox(int X,int Y,int W,int H,const char*L=0) : Fl_Box(X,Y,W,H,L) {
box(FL_FLAT_BOX);
color(FL_WHITE);
}
void draw() {
// DRAW OUTER BOX IN WHITE
fl_color(FL_WHITE);
fl_rectf(x(),y(),w(),h());
// SET FONT/SIZE TO DETERMINE XYWH OF TEXT
fl_font(labelfont(), labelsize());
// A: DRAW USING draw(s,X,Y,W,H) + fl_measure()
{
int X=x()+20, Y=y()+5, W=0, H=0;
fl_measure(label(), W,H, 0);
// DRAW RED BOX AROUND FL_MEASURE'D AREA
fl_color(FL_RED);
fl_rect(X,Y,W,H);
// DRAW TEXT IN BLACK
fl_color(FL_BLACK);
fl_draw(label(), X,Y,W,H, align(),0,0);
fl_draw("A:",x(),Y+fl_height());
}
// B: DRAW USING draw(s,X,Y) + fl_measure()
{
int X=x()+20, Y=y()+35, W=0, H=0;
fl_measure(label(), W,H, 0);
// DRAW RED BOX AROUND FL_MEASURE'D AREA
fl_color(FL_RED);
fl_rect(X,Y,W,H);
// DRAW TEXT IN BLACK
fl_color(FL_BLACK);
fl_draw(label(), X,Y+H);
fl_draw("B:",x(),Y+fl_height());
}
// C: DRAW USING draw(s,X,Y) + fl_height()
{
int X=x()+20, Y=y()+65, W=0, H=0;
fl_measure(label(), W,H, 0);
// DRAW RED BOX AROUND FL_MEASURE'D AREA
fl_color(FL_RED);
fl_rect(X,Y,W,H);
// DRAW TEXT IN BLACK
fl_color(FL_BLACK);
fl_draw(label(),X,Y+fl_height());
fl_draw("C:",x(),Y+fl_height());
}
// D: DRAW USING draw(s,X,Y) + Ian's new fl_text_extents()
{
int X=x()+20, Y=y()+95, W=0, H=0;
int dx=0,dy=0,wo=0,ho=0;
fl_text_extents(label(), dx, dy, wo, ho);
// DRAW RED BOX AROUND TEXT EXTENTS AREA
fl_color(FL_RED);
fl_rect(X+dx,Y+dy+fl_height(),wo,ho);
// DRAW TEXT IN BLACK
fl_color(FL_BLACK);
fl_draw(label(),X,Y+fl_height());
fl_draw("D:",x(),Y+fl_height());
}
}
};
int main() {
Fl_Window win(300,300);
TestBox test(10,10,300-20,300-20,"ABCabc HHHllljjjgggkk()||ÃÃÃÃÃ");
test.align(FL_ALIGN_CENTER|FL_ALIGN_INSIDE);
win.end();
win.show();
return(Fl::run());
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2115: Misplacement of text in Fl_Text_Editor and probably Fl_Text_Display
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2115 Version: 1.3-current I think I see the problem. When XFT is enabled, the pixel size of eg. the FL_COURIER font may be quite different the actual font size requested by the user. eg. if textsize() is set to 11, the actual pixel size of the font may be much larger than 11. Internally, I think Fl_Text_Editor is sometimes using the raw font size value for pixel size, ie. not always using fl_height()/fl_measure(). To show the difference clearly; if I change the attached text-with-box.cxx program to use courier with a font size of 11, eg. adding to main(): test.labelfont(FL_COURIER); test.labelsize(11); ..and compile and run with XFT on vs. off, the result is attached "text-with-box-courier.png", which shows a large difference in the font's size, even though the requested size is 11 in both cases. With XFT on, the font's bounding box is 14 pixels, vs. 10 when XFT is off. Seems these docs for fl_height() may no longer be true: http://fltk.org/documentation.php/doc-1.3/drawing.html#fl_height ..specifically the bit about "You can also just use the value of size passed to fl_font()." With XFT fonts, the pixel size can apparently be much larger than the font's size() value. Fl_Text_Editor internally alternates between using fl_height() and the raw font value to calculate font heights, probably getting the heights wrong in the latter case. The fix is likely to change everything to use fl_height(), fl_measure(), and friends. Also, the docs for fl_height() might need to be rescinded, as I don't think that's true any longer. Link: http://www.fltk.org/str.php?L2115 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 #2115: Misplacement of text in Fl_Text_Editor and probably Fl_Text_Display
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2115 Version: 1.3-current Link: http://www.fltk.org/str.php?L2115 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 #2115: Misplacement of text in Fl_Text_Editor and probably Fl_Text_Display
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2115
Version: 1.3-current
The following convenience function code in fl_draw() is wrong, and seems to
be affecting Fl_Text_Editor/Fl_Text_Display negatively:
-
/**
Dummy passthru function called only in Fl_Text_Display that simply
returns
the font height as given by the \a size parameter in the same call!
\todo Is fl_height(int, int size) required for Fl_Text_Dispay?
Why not use \a size parameter directly?
*/
inline int fl_height(int, int size) {return size;}
-
When called with fl_height(FL_COURIER, 11), the result is 11 (which is
wrong).
The normal sequence most code is using is:
fl_font(FL_COURIER,11);
fl_height();
..which comes back with the correct value of 14.
Link: http://www.fltk.org/str.php?L2115
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 #2115: Misplacement of text in Fl_Text_Editor and probably Fl_Text_Display
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2115
Version: 1.3-current
Changing this:
inline int fl_height(int, int size) {return size;}
..to instead be implemented something like the following:
int fl_height(int font, int size) {
if ( font == fl_font() && size == fl_size() ) return(fl_height());
int tf = fl_font(), ts = fl_size(); // save
fl_font(font,size);
int height = fl_height();
fl_font(tf,ts); // restore
return(height);
}
..seems to solve the problem in Fl_Text_Display() and fluid for me.
However, I do think lines like this in Fl_Text_Display should
be double checked:
int lineHeight = mMaxsize ? mMaxsize : textsize_;
..as this appears to make direct use of "textsize_" as a pixel
size, which should likely be replaced with an appropriate
fl_height call.
Link: http://www.fltk.org/str.php?L2115
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 #2115: Misplacement of text in Fl_Text_Editor and probably Fl_Text_Display
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2115 Version: 1.3-current Right.. it's a strange problem. However, I'm pretty sure the code implementation discrepancy in fl_height(int,int) vs. fl_height(void) has got to be fixed. fl_height(void) returns the ascent+descent, whereas fl_height(int,int) just returns the second argument. Both should do the same thing, and surely fl_height(int,int) should do what fl_height(void) does internally so that their behavior is the same. Regarding the fontsize vs. actual pixel size, I'm not sure what to offer, and it's probably true a lot of widgets likely use the pixel size value instead of fl_height() and friends, my own widgets probably being among them. However, in light of the above, I feel the urge to modify all those widgets to switch to using fl_height() and fl_measure() to ensure my commercial apps look right. Link: http://www.fltk.org/str.php?L2115 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 #2115: Misplacement of text in Fl_Text_Editor and probably Fl_Text_Display
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2115 Version: 1.3-current Link: http://www.fltk.org/str.php?L2115 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 #2115: Misplacement of text in Fl_Text_Editor and probably Fl_Text_Display
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2115
Version: 1.3-current
Link: http://www.fltk.org/str.php?L2115
Version: 1.3-current#include
#include
#include
#include
// TEST TEXT POSITIONING WITHIN BOX USING VARIOUS METHODS
class TestBox : public Fl_Box {
public:
TestBox(int X,int Y,int W,int H,const char*L=0) : Fl_Box(X,Y,W,H,L) {
box(FL_FLAT_BOX);
color(FL_WHITE);
}
void draw() {
// DRAW OUTER BOX IN WHITE
fl_color(FL_WHITE);
fl_rectf(x(),y(),w(),h());
// SET FONT/SIZE TO DETERMINE XYWH OF TEXT
fl_font(labelfont(), labelsize());
// A: DRAW USING draw(s,X,Y,W,H) + fl_measure()
{
int X=x()+20, Y=y()+5, W=0, H=0;
fl_measure(label(), W,H, 0);
// DRAW RED BOX AROUND FL_MEASURE'D AREA
fl_color(FL_RED);
fl_rect(X,Y,W,H);
// DRAW TEXT IN BLACK
fl_color(FL_BLACK);
fl_draw(label(), X,Y,W,H, align(),0,0);
fl_draw("A:",x(),Y+fl_height()-fl_descent());
}
// B: DRAW USING draw(s,X,Y) + fl_measure() + fl_descent()
{
int X=x()+20, Y=y()+35, W=0, H=0;
fl_measure(label(), W,H, 0);
// DRAW RED BOX AROUND FL_MEASURE'D AREA
fl_color(FL_RED);
fl_rect(X,Y,W,H);
// DRAW TEXT IN BLACK
fl_color(FL_BLACK);
fl_draw(label(), X,Y+H-fl_descent());
fl_draw("B:",x(),Y+fl_height()-fl_descent());
}
// C: DRAW USING draw(s,X,Y) + fl_height() + fl_descent()
{
int X=x()+20, Y=y()+65, W=0, H=0;
fl_measure(label(), W,H, 0);
// DRAW RED BOX AROUND FL_MEASURE'D AREA
fl_color(FL_RED);
fl_rect(X,Y,W,H);
// DRAW TEXT IN BLACK
fl_color(FL_BLACK);
fl_draw(label(),X,Y+fl_height()-fl_descent());
fl_draw("C:",x(),Y+fl_height()-fl_descent());
}
// D: DRAW USING draw(s,X,Y) + Ian's new fl_text_extents()
{
int X=x()+20, Y=y()+95;
int dx=0,dy=0,wo=0,ho=0;
fl_text_extents(label(), dx, dy, wo, ho);
// DRAW RED BOX AROUND TEXT EXTENTS AREA
fl_color(FL_RED);
fl_rect(X+dx,Y+dy+fl_height()-fl_descent(),wo,ho);
// DRAW TEXT IN BLACK
fl_color(FL_BLACK);
fl_draw(label(),X,Y+fl_height()-fl_descent());
fl_draw("D:",x(),Y+fl_height()-fl_descent());
}
// E: DRAW USING draw(s,X,Y,W,H) + labelsize() for height, fl_width()
for width
{
int X=x()+20, Y=y()+125, W=0, H=0;
W = (int)fl_width(label());
H = labelsize();// probably bad
// DRAW RED BOX AROUND TEXT EXTENTS AREA
fl_color(FL_RED);
fl_rect(X,Y,W,H);
// DRAW TEXT IN BLACK
fl_color(FL_BLACK);
fl_draw(label(), X,Y,W,H, align(),0,0);
fl_draw("E:", x(),Y,(int)fl_width("E:"),H, align(),0,0);
}
}
};
int main() {
Fl_Window win(300,300);
TestBox test(10,10,300-20,300-20,"ABCabc HHHllljjjgggkk()||ÃÃÃÃÃ");
test.align(FL_ALIGN_CENTER|FL_ALIGN_INSIDE);
test.labelfont(FL_COURIER);
test.labelsize(11);
win.end();
win.show();
return(Fl::run());
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2115: Misplacement of text in Fl_Text_Editor and probably Fl_Text_Display
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2115 Version: 1.3-current BTW, added fl_descent() to the text-box example code to fix a bug that was hiding the problem a bit; with this fix, the text draws within all the boxes except when the font size is used for the pixel size. Also changed the font to FL_COURIER which shows the problem I'm seeing on linux pretty well. I also added an 'E:' line that uses the font size as the pixel size, to show how that technique is off from the others. "text-with-box-fix.cxx" -- has the above fixes "text-with-box-fix.png" -- screenshots of XFT on vs. off. (green arrows show text drawing outside box) Also, in the code it documents what the A/B/C/D/E lines are, but thought I'd include the description here as well: A: USES draw(s,X,Y,W,H) + fl_measure() B: USES draw(s,X,Y) + fl_measure() + fl_descent() C: USES draw(s,X,Y) + fl_height() + fl_descent() D: USES draw(s,X,Y) + Ian's new fl_text_extents() E: USES draw(s,X,Y,W,H) + labelsize() for height, fl_width() for width Note that only E draws outside the bounding box when XFT is on. Link: http://www.fltk.org/str.php?L2115 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2117: text not vertically centered in buttons, underlines drawing incorrectly
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2117 Version: 1.3-current Noticed a few font drawing problems under fedora3 + fltk1.3.x: o text not vertically centered within buttons consistently o underlined text not drawing consistently The attached "button.png" shows screenshot blowups of the 'button' test program; left is with XFT disabled, right is with XFT enabled. Left image shows the "Exit" button drawing correctly, the underline being below the font, and the font centered normally (even if descenders appeared in the text). Right image shows the "Exit" button text favoring the bottom of the bottom, and the underline being "high", touching the bottoms of all the letters. Link: http://www.fltk.org/str.php?L2117 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 #2117: text not vertically centered in buttons, underlines drawing incorrectly
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2117 Version: 1.3-current Link: http://www.fltk.org/str.php?L2117 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 #2117: text not vertically centered in buttons, underlines drawing incorrectly
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2117 Version: 1.3-current Link: http://www.fltk.org/str.php?L2117 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 #2117: text not vertically centered in buttons, underlines drawing incorrectly
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2117 Version: 1.3-current Forgot to blow up button.png; posted "button-zoom-4x.png" which makes it easier to see. Also: typo in above; "..favoring the bottom of the bottom" was supposed to read "..favoring the button of the *button*". Link: http://www.fltk.org/str.php?L2117 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 #2115: Misplacement of text in Fl_Text_Editor and probably Fl_Text_Display
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2115 Version: 1.3-current I'm fine with the interface we have, as long as it does what it's supposed to ;) I think between fl_height(), fl_measure(), and Ian's new fl_text_extents(), maybe everything is covered. I think all we really need to fix this STR is: o Fix fl_height(int,int) [which so far has never been documented] so that it does what fl_height() does (without affecting the current fl_font()/fl_size()) The fix to fl_height(int,int) will, I think, fix the OP's bug.. (it fixes mine) and maybe note a warning in the docs that in light of some of the new changes to support Anti Aliased fonts, fl_height() might provide more accurate font positioning info than fl_size(). Link: http://www.fltk.org/str.php?L2115 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 #2104: copy/paste not working under windows
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2104
Version: 1.3-current
Link: http://www.fltk.org/str.php?L2104
Version: 1.3-current--- Fl_win32.cxx.orig 2009-01-11 16:24:42.336344000 -0800
+++ Fl_win32.cxx2009-01-11 16:33:08.945327728 -0800
@@ -548,11 +548,18 @@
fl_selection_length[clipboard] = len;
if (clipboard) {
// set up for "delayed rendering":
-if (OpenClipboard(fl_xid(Fl::first_window( {
+if (OpenClipboard(NULL)) {
// if the system clipboard works, use it
+ int utf16_len = fl_utf8toUtf16(fl_selection_buffer[clipboard],
fl_selection_length[clipboard], 0, 0);
EmptyClipboard();
- SetClipboardData(CF_TEXT, NULL);
+ HGLOBAL hMem = GlobalAlloc(GMEM_MOVEABLE, utf16_len * 2 + 2);
+ LPVOID memLock = GlobalLock(hMem);
+ fl_utf8toUtf16(fl_selection_buffer[clipboard],
fl_selection_length[clipboard], (unsigned short*) memLock, utf16_len * 2);
+ *((unsigned short*) memLock + utf16_len) = 0;
+ GlobalUnlock(hMem);
+ SetClipboardData(CF_UNICODETEXT, hMem);
CloseClipboard();
+ GlobalFree(hMem);
fl_i_own_selection[clipboard] = 0;
} else {
// only if it fails, instruct paste() to use the internal buffers
@@ -587,19 +594,25 @@
Fl::e_text = 0;
} else {
if (!OpenClipboard(NULL)) return;
-HANDLE h = GetClipboardData(CF_TEXT);
+HANDLE h = GetClipboardData(CF_UNICODETEXT);
if (h) {
- Fl::e_text = (LPSTR)GlobalLock(h);
+ unsigned short *memLock = (unsigned short*) GlobalLock(h);
+ int utf16_len = wcslen(memLock);
+ Fl::e_text = (char*) malloc (utf16_len * 4 + 1);
+ int utf8_len = fl_utf8fromwc(Fl::e_text, utf16_len * 4, memLock,
utf16_len);
+ *(Fl::e_text + utf8_len) = 0;
LPSTR a,b;
a = b = Fl::e_text;
while (*a) { // strip the CRLF pairs ($...@^)
- if (*a == '\r' && a[1] == '\n') a++;
- else *b++ = *a++;
+if (*a == '\r' && a[1] == '\n') a++;
+else *b++ = *a++;
}
*b = 0;
Fl::e_length = b - Fl::e_text;
receiver.handle(FL_PASTE);
GlobalUnlock(h);
+ free(Fl::e_text);
+ Fl::e_text = 0;
}
CloseClipboard();
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2104: copy/paste not working under windows
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2104 Version: 1.3-current I've attached Sadysta's changes as a patch. (Sadysta.patch) I did not try it, I removed the commented out code, and fixed indenting. Link: http://www.fltk.org/str.php?L2104 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2122: On the mac, default FL_COURIER fonts showing up 'gray'?
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2122 Version: 1.3-current Seems that on my macs, the FL_COURIER font is coming up 'gray' instead of 'black'. Attached screenshot (fltk-1.3.x-mac-gray-courier.png) shows a comparison between the attached program (foo.cxx) compiled and run under 1.1.7 vs. 1.3.x-svn to show the difference. The 1.3.x text seems like its 50% gray instead of black, compared to the 1.1.7 text. Seems that regardless of the text color used; black becomes gray, red becomes pink. Possibly some new antialiasing algorithm not present before is preventing it from sufficiently stroking opaque? Or maybe a different system courier font is being used that is too "thin"? This is OSX 10.4.11 (on PPC). Fltk is 1.3.x-svn (current checkout, default configure) Link: http://www.fltk.org/str.php?L2122 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 #2122: On the mac, default FL_COURIER fonts showing up 'gray'?
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2122
Version: 1.3-current
Link: http://www.fltk.org/str.php?L2122
Version: 1.3-current#include
#include
#include
#include
#include
int main() {
char title[40];
sprintf(title, "fltk
%d.%d.%d",FL_MAJOR_VERSION,FL_MINOR_VERSION,FL_PATCH_VERSION);
Fl_Window win(600, 150, title);
Fl_Multiline_Output out(10,10,win.w()-20,win.h()-20);
out.textfont(FL_COURIER);
out.value("-rw-r--r-- 1 root 10003847 Dec 10 01:50
CMakeLists.txt\n"
"-rw-r--r-- 1 root 10001327 Dec 10 01:50
CubeMain.cxx\n"
"-rw-rw-rw- 1 root 10001344 Dec 28 08:45 CubeMain.o\n"
"-rwxrwxrwx 1 root 1000 313532 Dec 28 08:45 CubeView\n"
"-rw-r--r-- 1 root 10004394 Dec 10 01:50
CubeView.cxx\n"
"-rw-r--r-- 1 root 10003421 Dec 10 01:50
CubeView.h\n");
win.show();
return(Fl::run());
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2125: shared-lib-calls-exit /usr/lib/libfltk_forms.so.1.3
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2125 Version: 1.3-current FLTK's few uses of exit() and _exit() look OK to me: > Fl_abort.cxx: by definition the 'fatal()' dialogs exit by definition > fl_open_uri.cxx: calls _exit() in fork() contenxt > forms_compatability.cxx: by definition supports the old 'forms' library, which used exit(). Only very old (1980's) programs compile against this deprecated compatibility module. However, fatal() is called throughout the library (in about 20 places), which means exit is called after that dialog is posted, which might be bad.. Link: http://www.fltk.org/str.php?L2125 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 #2122: On the mac, default FL_COURIER fonts showing up 'gray'?
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2122 Version: 1.3-current Things seem to look better if I change default "Courier New" in fl_font_mac.cxx to just "Courier". The attached image "courier-vs-courier-new.png" compares the two. The change seems to look normal contrast-wise, though the vertical line spacing is a little off for some reason. With that change, things look much better in fluid's code editor as well, where you can really see the low-contrast problem with all the text coloring. Is there a reason not to use "Courier"? Link: http://www.fltk.org/str.php?L2122 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
