[fltk.bugs] [LOW] STR #2943: Incorrect drawing of rounded box
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2943 Version: 1.3-current If size of widget is quite small then FLTK draws incorrect rounded box, all four corners are different (upper fig. on the attached picture). I investigated the issue and found out a few things: to fix it first we need to do mathematically correct rounding of coordinates. In other words, instead fl_vertex(x,y) must be fl_vertex(x+0.5,y+0.5) (second fig.). In fact, I suppose the rounding of coordinates is wider problem in FLTK. Second, rbox will draw tidy corners only if size of their radius is even number (third fig.). And the latest, I rarely used rounded box because of ugly appearance (IMHO). On the contrary, often I needed straight box but without sharp corners. Setting the RS (max radius) to small value (2..6) gives me what I want.(fourth fig.) Maybe, something like RS should be part of widget properties or at least it would be mentioned in docs as customising point? Link: http://www.fltk.org/str.php?L2943 Version: 1.3-current rounded_box.tar.gz Description: Binary data ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2726: Debug assertion failed window inFluid.
Reopened on request of OP. It seems clear to me that the attempted fix in r 9363 doesn't solve the OP's problem, since it would preserve *negative* char (int) values. Using both casts looks appropriate to make sure char codes 127 are positive int's. Nikita, could you please confirm that svn r9635 solves the problem? Leaving the STR open for confirmation... Hi, Albrecht. At the moment fluid works very well. But I don't understand why you had not removed the (int). isspace((unsigned char)*n)) is enough! Compilers (I tested VC++, mingw-gcc, ubuntu-gcc) cast to type int in any case and they print no warning because it's absolutely safe. We only say to compiler: Don't extend the sign bit when you will convert our character to int. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2726: Debug assertion failed window inFluid.
Used int instead of unsigned char as specified in isspace documentation.
Fabien, your changes again cause the appearing of debug assertion window on
VC2010 (Debug) while opening some FL file that uses non latin symbols.
Please, fix it in such way, for example:
if (n) { // see if blank, strip leading trailing blanks
-if (!nostrip) while (isspace((int) *n)) n++;
+if (!nostrip) while (isspace((int) *n 255)) n++;
const char *e = n + strlen(n);
-if (!nostrip) while (e n isspace((int)*(e-1))) e--;
+if (!nostrip) while (e n isspace((int)*(e-1) 255)) e--;
length = e-n;
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2726: Debug assertion failed window in Fluid.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2726 Version: 1.3-current But the real bug is, that we invested so much time into porting FLTK to UTF-8, but forgot to port Fluid. ;-) Not quite. This problem had appeared in one of 1.1.x versions. One note though: not all compilers like UTF-8 in their source code, even in text fields between quotes! The SGI C compiler even crashes. But gcc is just fine. Yes, and MS VC ignores the UTF8 sequences. You can see the strings in IDE correctly, but compiler translates them into the CP125x (or into UTF16 if set L). And you'll see an abracadabra in FLTK's widgets :( Link: http://www.fltk.org/str.php?L2726 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2726: Debug assertion failed window in Fluid.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2726
Version: 1.3-current
I have recollected about an annoying debug window that appears in debug
version of Fluid when you use UTF8 string for tooltip (WIN32 VC2008,
VC2010). Assertion window arises after calling isspace() e.g. in the line
fluid\Fl_Type.cxx:597.
--
_ASSERTE((unsigned)(c + 1) = 256);
That's line from MS' istype.c which doesn't let passing of any bytes 127
or 0.
The problem can be fixed via explicit cast to unsigned char or via
option
/J (Default char Type Is unsigned) for the Fluid project.
@@ -594,9 +594,9 @@
undo_checkpoint();
int length = 0;
if (n) { // see if blank, strip leading trailing blanks
-if (!nostrip) while (isspace(*n)) n++;
+if (!nostrip) while (isspace((unsigned char)*n)) n++;
const char *e = n + strlen(n);
-if (!nostrip) while (e n isspace(*(e-1))) e--;
+if (!nostrip) while (e n isspace((unsigned char)*(e-1))) e--;
length = e-n;
if (!length) n = 0;
}
Link: http://www.fltk.org/str.php?L2726
Version: 1.3-current
about.fl
Description: Binary data
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2722: Fluid shows labels in an incorrect way
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2722
Version: 1.3-current
When a widget has a label Fluid truncates it (as byte string) and prints
the UTF8 string incorrectly in half cases, approximately.
I would use fl_utf8decode() to avoid of splitting the UTF8 symbols.
For example:
@@ -323,9 +314,13 @@ void Widget_Browser::item_draw(void *v,
} else if ((c=l-label())) {
char buf[50]; char* p = buf;
*p++ = '';
- for (int i = 20; i--;) {
+ int b,l=strlen(c);
+ for (int i = 20; i0;) {
if (! (*c -32)) break;
-*p++ = *c++;
+fl_utf8decode(c, c+l, b);
+if (b==-1 || i-b0) break;
+l-=b;i-=b;
+while (b--)*p++ = *c++;
}
if (*c) {strcpy(p,...); p+=3;}
*p++ = '';
Link: http://www.fltk.org/str.php?L2722
Version: 1.3-currentattachment: fluid_utf8.jpg___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2597: FLUID generates wrong source code to initialize menu labels.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2597
Version: 1.4-feature
Hi, Manolo. I'm sorry for the late answer.
1) This is simple test FL file
# data file for the Fltk User Interface Designer (fluid)
version 1.0300
i18n_type 1
i18n_include libintl.h
i18n_function gettext
header_name {.h}
code_name {.cxx}
Function {make_window()} {open
} {
Fl_Window {} {open
xywh {288 362 412 286} type Double visible
} {
Fl_Menu_Bar {} {open selected
xywh {0 0 565 20}
} {
Submenu {} {
label 1 open
xywh {0 0 61 19}
} {
MenuItem {} {
label A
xywh {0 0 29 19}
}
MenuItem {} {
label B
xywh {0 0 29 19}
}
Submenu {} {
label 2 open
xywh {0 0 61 19}
} {
MenuItem {} {
label C
xywh {0 0 29 19}
}
}
}
Submenu {} {
label 3 open
xywh {0 0 61 19}
} {
MenuItem {} {
label D
xywh {0 0 29 19}
}
MenuItem {} {
label E
xywh {0 0 29 19}
}
}
Submenu {} {
label 4 open
xywh {0 0 61 19}
} {
MenuItem {} {
label F
xywh {0 0 30 20}
}
}
}
}
}
Old version of FLUID prints such text:
#include libintl.h
#include test_menu.h
unsigned char menu__i18n_done = 0;
Fl_Menu_Item menu_[] = {
{1, 0, 0, 0, 64, FL_NORMAL_LABEL, 0, 14, 0},
{A, 0, 0, 0, 0, FL_NORMAL_LABEL, 0, 14, 0},
{B, 0, 0, 0, 0, FL_NORMAL_LABEL, 0, 14, 0},
{2, 0, 0, 0, 64, FL_NORMAL_LABEL, 0, 14, 0},
{C, 0, 0, 0, 0, FL_NORMAL_LABEL, 0, 14, 0},
{0,0,0,0,0,0,0,0,0},
{0,0,0,0,0,0,0,0,0},
{3, 0, 0, 0, 64, FL_NORMAL_LABEL, 0, 14, 0},
{D, 0, 0, 0, 0, FL_NORMAL_LABEL, 0, 14, 0},
{E, 0, 0, 0, 0, FL_NORMAL_LABEL, 0, 14, 0},
{0,0,0,0,0,0,0,0,0},
{4, 0, 0, 0, 64, FL_NORMAL_LABEL, 0, 14, 0},
{F, 0, 0, 0, 0, FL_NORMAL_LABEL, 0, 14, 0},
{0,0,0,0,0,0,0,0,0},
{0,0,0,0,0,0,0,0,0}
};
Fl_Double_Window* make_window() {
Fl_Double_Window* w;
{ Fl_Double_Window* o = new Fl_Double_Window(412, 286);
w = o;
{ Fl_Menu_Bar* o = new Fl_Menu_Bar(0, 0, 565, 20);
if (!menu__i18n_done) {
int i=0;
for ( ; i10; i++) /* 10 is wrong limit of iterations! */
if (menu_[i].label())
menu_[i].label(gettext(menu_[i].label()));
menu__i18n_done = 1;
}
o-menu(menu_);
} // Fl_Menu_Bar* o
o-end();
} // Fl_Double_Window* o
return w;
}
My patch calculates the correct number of items - 13
2) That patch has one more bug :( Some cases will be handled incorrectly.
New version of the patch is:
--- a\Fl_Menu_Type.cxx 2011-05-09 00:00:00.0 +0400
+++ b\Fl_Menu_Type.cxx 2011-05-09 00:00:00.0 +0400
@@ -466,7 +466,10 @@ void Fl_Menu_Type::write_code2() {
const char *mName = mi-menu_name(i);
for (Fl_Type* q = next; q q-is_menu_item(); q = q-next) {
if (((Fl_Menu_Item_Type*)q)-label()) nLabel++;
-nItem++;
+int thislevel = q-level; if (q-is_parent()) thislevel++;
+int nextlevel =
+(q-next q-next-is_menu_item()) ? q-next-level :
next-level+1;
+nItem += 1 + ((thislevel nextlevel) ? (thislevel-nextlevel) :
0);
}
if (nLabel) {
write_c(%sif (!%s_i18n_done) {\n, indent(), mName);
Link: http://www.fltk.org/str.php?L2597
Version: 1.4-feature
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #2597: FLUID generates wrong source code to initialize menu labels.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2597
Version: 1.3-current
Since gettext() was moved from static structure into special function,
there is a bug in counting of quantity of array lines
(fluid/Fl_Menu_Type.cxx:467, variable nItem).
Author forgot about dummy strings like as {0,0,0...} which separate
submenus within the menu array. Thus, runtime cycle of initializing menu
will be completed before all labels will be assigned via gettext(). To fix
this bug I propose small patch:
--- a\Fl_Menu_Type.cxx 2011-03-28 23:36:09.196969400 +0400
+++ b\Fl_Menu_Type.cxx 2011-03-28 23:37:04.062107500 +0400
@@ -466,7 +466,10 @@ void Fl_Menu_Type::write_code2() {
const char *mName = mi-menu_name(i);
for (Fl_Type* q = next; q q-is_menu_item(); q = q-next) {
if (((Fl_Menu_Item_Type*)q)-label()) nLabel++;
-nItem++;
+int thislevel = q-level; if (q-is_parent()) thislevel++;
+int nextlevel =
+(q-next q-next-is_menu_item()) ? q-next-level :
next-level+1;
+nItem += 1+(thislevel-nextlevel);
}
if (nLabel) {
write_c(%sif (!%s_i18n_done) {\n, indent(), mName);
I have taken that method of counting from here:
fluid/Fl_Menu_Type.cxx:242.
There is one more problem, at the moment the text strings inside the menu
array have no mark like _() or gettext(). Do you understand?
Automatization tools like as xgettext or poEdit can't extract these
strings from the source code. Any ideas?
Link: http://www.fltk.org/str.php?L2597
Version: 1.3-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] Crash within Fl_Glut_Window::handle() after arising the mouse wheel event.
There is no test for a correctness of the mouse pointer in branch
FL_MOUSEWHEEL as opposed to other branches.
glut_compatability.cxx:104(1.1.10);106(1.3.x)
..
case FL_MOUSEWHEEL:
button = Fl::event_dy();
while (button 0) {mouse(3,GLUT_DOWN,ex,ey); ++button;}
while (button 0) {mouse(4,GLUT_DOWN,ex,ey); --button;}
return 1;
...
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #2381: Crash within Fl_Glut_Window::handle() after arising the mouse wheel event.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2381
Version: 1.1.10
Reposting by right way...
---
There is no test for a correctness of the mouse pointer in branch
FL_MOUSEWHEEL as opposed to other branches.
glut_compatability.cxx :104(1.1.10);106(1.3.x)
...
case FL_MOUSEWHEEL:
button = Fl::event_dy();
while (button 0) {mouse(3,GLUT_DOWN,ex,ey); ++button;}
while (button 0) {mouse(4,GLUT_DOWN,ex,ey); --button;}
return 1;
Link: http://www.fltk.org/str.php?L2381
Version: 1.1.10
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
