[fltk.bugs] [MOD] STR #2907: deactivated box appearance
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2907 Version: 1.3-current I wrote to fltk.general about five days ago and got no response. I'll paste it in here so that it can't slip between the cracks permanently: I was playing around with the Fl_Light_Button colors as brought up the other day, and I noticed how the round button or something didn't grey out when deactivated in the gtk+ scheme. Hmmm I went off to test/boxtype and tried Index: boxtype.cxx === --- boxtype.cxx (revision 9746) +++ boxtype.cxx (working copy) @@ -37,6 +37,8 @@ y = y*H+10; Fl_Box *b = new Fl_Box(type,x,y,square ? H-20 : W-20,H-20,name); b-labelsize(11); + b-color(FL_RED); + b-deactivate(); if (square) b-align(FL_ALIGN_RIGHT); } ...and the ones that stayed bright red seemed like an arbitrary assortment. Is this in some way proper behaviour for these boxtypes? If not, I can try to make a patch modeled on how fl_gtk.cxx deals with it. Link: http://www.fltk.org/str.php?L2907 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2901: Fl_Browser format codes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2901 Version: 1.3-current Let's see...that formatting stuff was in...Fl_Browser::item_draw(). Link: http://www.fltk.org/str.php?L2901 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2901: Fl_Browser format codes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2901 Version: 1.3-current Ah, yes. So the literal '@' was to get out if you found your way in there for whatever reason and...wanted to get out and print the string starting with the '@'... I guess. The documentation under format_char() doesn't make that situation very clear. In any case, I'm not using that feature. It was something that caught my eye while writing about @N. Link: http://www.fltk.org/str.php?L2901 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2901: Fl_Browser format codes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2901 Version: 1.3-current In the source, I saw an N to set to FL_INACTIVE_COLOR, but I don't see that listed in the documentation. Hmm, I'm surprised that there's a case for format_char() followed by '@' specifically instead of format_char() followed by another format_char()... Link: http://www.fltk.org/str.php?L2901 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2892: Fl_Text_Display::position_to_line(): Consistency check ptvl failed
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2892
Version: 1.3-current
As erco wrote on fltk.general:
        Getting these errors on the terminal for every character
I type:
Fl_Text_Display::position_to_line(): Consistency check ptvl failed
Fl_Text_Display::position_to_line(): Consistency check ptvl failed
Fl_Text_Display::position_to_line(): Consistency check ptvl failed
Fl_Text_Display::position_to_line(): Consistency check ptvl failed
        Also, even though the screen appears to be large enough,
it
        doesn't show the line being typed, but seems scrolled
down
        to an empty line beyond the end of the buffer.
...which pretty much covers it.
It seems like the Fl_Text_Display needs to have room for two lines and use
WRAP_AT_BOUNDS wrap mode.
I'm amazed that I haven't tripped over this before with textareas in
dillo, but maybe two lines tall is uncommon enough...
Code to reproduce attached.
Link: http://www.fltk.org/str.php?L2892
Version: 1.3-current#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Text_Editor.H
int main() {
  Fl_Window* w = new Fl_Window(186, 38);
  w-begin();
    Fl_Text_Editor *e = new Fl_Text_Editor(0, 0, 186, 38);
    e-wrap_mode(Fl_Text_Editor::WRAP_AT_BOUNDS, 0);
    e-buffer(new Fl_Text_Buffer);
  w-end();
  w-show();
  return Fl::run();
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2892: Fl_Text_Display::position_to_line(): Consistency check ptvl failed
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2892 Version: 1.3-current Oh, also at one point I tried #define DEBUG 1 in Fl_Text_Display.cxx, and then I was getting *** display_insert/position_to_xy # GIVE UP !\n from line 985 without changing wrap mode from the default, so it may be that wrap mode is not strictly necessary for position_to_line() unhappiness. Link: http://www.fltk.org/str.php?L2892 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2883: submenu positioning
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2883 Version: 1.3-current If there isn't room to the right of the parent menu, the submenu is placed to its left -- but sometimes there's even less room for it on the left side. Link: http://www.fltk.org/str.php?L2883 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2880: menu popup() positioning
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2880 Version: 1.3-current If there isn't enough room at the bottom of the screen for the menu, - if there is no title, the menu is placed such that the cursor is at the top left of the last item. This never struck me as odd. - if there is a title, the menu is placed such that there is a one-item gap between the cursor and the last menu item. This does look odd. I'm guessing now that it is supposed to put the bottom left corner of the menu at the cursor in both cases. For an example, you can take test/checkers and add a title to the popup() on line 1112. Link: http://www.fltk.org/str.php?L2880 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2730: valgrind, out of bounds access, Fl_Text_Display wrapping
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2730 Version: 1.3-current Yes, we still get plenty of these errors, as you can see at http://starurchin.org/dillo/valgrind.html Link: http://www.fltk.org/str.php?L2730 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #2771: Turkic locales and str(n)casecmp, toupper, tolower
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2771 Version: 1.3-current Don't want to forget about the discussion last month on fltk.general... http://www.mail-archive.com/fltk@easysw.com/msg12416.html Link: http://www.fltk.org/str.php?L2771 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 #2735: fl_utf_toupper() and Eszett
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2735 Version: 1.3-current I've been looking into text-transform in CSS, and Firefox shows SS when using text-transform values of uppercase and capitalize. For the microsoft browser, it's mentioned, evidently as a bug (http://msdn.microsoft.com/en-us/library/ff405742(v=vs.85).aspx). Not being a German speaker, I've only been going by what I've read, which gives me the impression that it generally becomes SS. And an upper case character that is used occasionally on signs got a Unicode code point not too long ago. *digs that up* http://unicode.org/versions/Unicode5.1.0/#Tailored_Casing_Operations 'In particular, capital sharp s is intended for typographical representations of signage and uppercase titles, and other environments where users require the sharp s to be preserved in uppercase. Overall, such usage is rare. In contrast, standard German orthography uses the string SS as uppercase mapping for small sharp s. Thus, with the default Unicode casing operations, capital sharp s will lowercase to small sharp s, but not the reverse: small sharp s uppercases to SS. In those instances where the reverse casing operation is needed, a tailored operation would be required.' Link: http://www.fltk.org/str.php?L2735 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2735: fl_utf_toupper() and Eszett
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2735 Version: 1.3-current I discovered Unicode's page with the, well, special cases: http://www.unicode.org/Public/UNIDATA/SpecialCasing.txt Link: http://www.fltk.org/str.php?L2735 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2735: fl_utf_toupper() and Eszett
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2735
Version: 1.3-current
Here's a patch just gluing it in as a special case...
Link: http://www.fltk.org/str.php?L2735
Version: 1.3-currentIndex: fl_utf8.cxx
===
--- fl_utf8.cxx (revision 9132)
+++ fl_utf8.cxx (working copy)
@@ -315,7 +315,14 @@
// l1 = fl_utf2ucs((unsigned char*)str + i, len - i, u1);
u1 = fl_utf8decode((const char*)(str + i), end, l1);
-l2 = fl_utf8encode((unsigned int) Toupper(u1), buf + l);
+if (u1 == 0xDF) {
+ // Eszett
+ l2 = 2;
+ buf[l] = 'S';
+ buf[l+1] = 'S';
+} else {
+ l2 = fl_utf8encode((unsigned int) Toupper(u1), buf + l);
+}
if (l1 1) {
i += 1;
} else {
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #2730: valgrind, out of bounds access, Fl_Text_Display wrapping
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2730 Version: 1.3-current The fix for the access at offset -1 (STR #2691) causes an out of bounds access at the other end, e.g.: ==22171== Invalid read of size 1 ==22171==at 0x80DA58F: Fl_Text_Display::measure_proportional_character(char const*, int, int) const (Fl_Text_Display.cxx:3220) ==22171==by 0x80DA42B: Fl_Text_Display::wrapped_line_counter(Fl_Text_Buffer*, int, int, int, bool, int, int*, int*, int*, int*, bool) const (Fl_Text_Display.cxx:3164) ==22171==by 0x80D69DD: Fl_Text_Display::count_lines(int, int, bool) const (Fl_Text_Display.cxx:1162) ==22171==by 0x80D4C5B: Fl_Text_Display::resize(int, int, int, int) (Fl_Text_Display.cxx:320) ==22171==by 0x80D72BD: Fl_Text_Display::buffer_modified_cb(int, int, int, int, char const*, void*) (Fl_Text_Display.cxx:1485) ==22171==by 0x80D3483: Fl_Text_Buffer::call_modify_callbacks(int, int, int, int, char const*) const (Fl_Text_Buffer.cxx:1310) ==22171==by 0x80D1565: Fl_Text_Buffer::text(char const*) (Fl_Text_Buffer.cxx:188) ==22171== Address 0x4867457 is 0 bytes after a block of size 1,583 alloc'd ==22171==at 0x402562C: malloc (vg_replace_malloc.c:236) ==22171==by 0x80D14F1: Fl_Text_Buffer::text(char const*) (Fl_Text_Buffer.cxx:178) p is buf-length()-1, and so is b initially. if (blineStart) b = lineStart; increases it to buf-length(). const char *s = buf-address(b); gets a value just beyond the end of the buffer. Link: http://www.fltk.org/str.php?L2730 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2730: valgrind, out of bounds access, Fl_Text_Display wrapping
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2730 Version: 1.3-current BTW, the line numbers in the valgrind report are off by a few because I have a couple of printf()s in my Fl_Text_Display.cxx, but all of its complaints are when *s is used. Link: http://www.fltk.org/str.php?L2730 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2731: valgrind jump depends on uninitialised value
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2731
Version: 1.3-current
I was just playing with the editor test, which still has the modifications
that I mentioned recently in the STR about the scrollbar.
Valgrind said:
==22622== Conditional jump or move depends on uninitialised value(s)
==22622==at 0x8081FD8: clip_to_short(int, int, int, int)
(fl_rect.cxx:123)
==22622==by 0x8082191: Fl_Graphics_Driver::rectf(int, int, int, int)
(fl_rect.cxx:183)
==22622==by 0x805A32D: fl_rectf(int, int, int, int) (fl_draw.H:206)
==22622==by 0x806B36F: fl_rectf(int, int, int, int, unsigned int)
(fl_draw.H:208)
==22622==by 0x8069B46: Fl_Text_Display::draw()
(Fl_Text_Display.cxx:3421)
==22622==by 0x8053C66: Fl_Group::update_child(Fl_Widget) const
(Fl_Group.cxx:751)
==22622==by 0x8053B31: Fl_Group::draw_children() (Fl_Group.cxx:726)
==22622==by 0x806E751: Fl_Window::draw() (Fl_Window.cxx:104)
==22622==by 0x8051A96: Fl_Double_Window::flush(int)
(Fl_Double_Window.cxx:361)
==22622==by 0x80518D8: Fl_Double_Window::flush()
(Fl_Double_Window.cxx:316)
==22622==by 0x80509AC: Fl_X::flush() (x.H:160)
==22622==by 0x804E4F9: Fl::flush() (Fl.cxx:741)
A little printf()ing showed that y sometimes has a crazy value.
Back in Fl_Text_Display.cxx, y comes from mCursorOldY.
mCursorOldY is only used in a couple of places, fortunately.
in draw(), there is:
int X, Y;
if (position_to_xy(mCursorPos, X, Y)) draw_cursor(X, Y);
//else puts(position_to_xy() failed - unable to draw cursor!);
//printf(drew cursor at pos: %d (%d,%d)\n, mCursorPos, X, Y);
mCursorOldY = Y;
and Fl_Text_Display::position_to_xy() has code that goes
/* If position is not displayed, return false */
if (pos mFirstChar || (pos mLastChar !empty_vlines())) {
return 0;
}
instead of setting y.
Link: http://www.fltk.org/str.php?L2731
Version: 1.3-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2727: screen_work_area() doesn't compile under X
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2727 Version: 3.0 (Just realized there's a 3.0 option in the bug tracker, so here's how far compilation happens to get at present...) fltk3/screen_xywh.cxx: In function 'void fltk3::screen_work_area(int, int, int, int, int)': fltk3/screen_xywh.cxx:252:9: error: 'Fl' has not been declared fltk3/screen_xywh.cxx:253:9: error: 'Fl' has not been declared fltk3/screen_xywh.cxx:254:9: error: 'Fl' has not been declared fltk3/screen_xywh.cxx:255:9: error: 'Fl' has not been declared Link: http://www.fltk.org/str.php?L2727 Version: 3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2719: native file chooser documentation
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2719 Version: 1.3-current A chunk of the documentation at the top of Fl_Native_File_Chooser.H is duplicated. Link: http://www.fltk.org/str.php?L2719 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2682: Vertical scrollbar of Fl_Text_Editor have a strange behavior. Or is bug?
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2682 Version: 1.3-current We've seen this reasonably frequently in Dillo since setting WRAP_AT_BOUNDS. I suspect it helps to have words (e.g., URLs) wider than the Fl_Text_Editor. Dragging the slider thing (whatever it's called) of the scrollbar reaches the bottom of the text, but the slider doesn't touch the bottom. Using the arrow keys to move around in the text, the text will sometimes change how it wraps for no obvious reason. If I go to the bottom and keep pressing down, I've seen it bounce between two different states of how it thinks it should wrap, and the slider will bounce a little. I'll try to come up with a reproducible case for you guys... Link: http://www.fltk.org/str.php?L2682 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2682: Vertical scrollbar of Fl_Text_Editor have a strange behavior. Or is bug?
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2682 Version: 1.3-current Attached file scrollbar_editor.diff... Link: http://www.fltk.org/str.php?L2682 Version: 1.3-currentIndex: editor.cxx === --- editor.cxx (revision 9073) +++ editor.cxx (working copy) @@ -768,15 +768,15 @@ w-begin(); Fl_Menu_Bar* m = new Fl_Menu_Bar(0, 0, 660, 30); m-copy(menuitems, w); -w-editor = new Fl_Text_Editor(0, 30, 660, 370); +w-editor = new Fl_Text_Editor(0, 30, 186, 176); w-editor-textfont(FL_COURIER); w-editor-textsize(TS); - //w-editor-wrap_mode(Fl_Text_Editor::WRAP_AT_BOUNDS, 250); +w-editor-wrap_mode(Fl_Text_Editor::WRAP_AT_BOUNDS, 0); w-editor-buffer(textbuf); w-editor-highlight_data(stylebuf, styletable, sizeof(styletable) / sizeof(styletable[0]), 'A', style_unfinished_cb, 0); - textbuf-text(); + textbuf-text(sdfsdfjl klskdfj asfdlkjd sflkasjdf sdlkfjs dflskjfd sdflkjsadflkslkdjf sdfksaldfkjaslkdf sd dklfksdfjskdf asldkfksdlfj sdflksdjf sdf slkdfjslkdfjlsf lskfskdfj fslkdfjsdf sdfkskjdlfksfdj sdflksjfslkdfjs fdlskdjf sfdlks f flkdfs df); style_init(); w-end(); w-resizable(w-editor); ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2682: Vertical scrollbar of Fl_Text_Editor have a strange behavior. Or is bug?
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2682 Version: 1.3-current Here's one that suffices to make the scrollbar not drag all the way down. It doesn't show any words-jumping oddness because they're all short. Link: http://www.fltk.org/str.php?L2682 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2711: FL_NORMAL_SIZE and menus
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2711 Version: 1.3-current If I set FL_NORMAL_SIZE=20 in test/menubar.cxx, the menubutton label draws over its triangle and the widest items in the radio menu don't fit into their popup. Link: http://www.fltk.org/str.php?L2711 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2710: handling of unrecognised schemes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2710 Version: 1.3-current If I call Fl::scheme(const char *s) with an unrecognised scheme name, the results are a bit odd, mostly following the default scheme, but with a certain amount of if (Fl::scheme()) around as well. In a few minutes of running on it, the only obviously wrong behaviour that I tripped upon was that the dot for a radio menu item wasn't centered. Link: http://www.fltk.org/str.php?L2710 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #2691: valgrind, out of bounds access, Fl_Text_Display wrapping
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2691
Version: 1.3-current
Fl_Text_Display::wrapped_line_counter() has a loop that goes
for (b=p; b=lineStart; b=buf-prev_char(b)) {
...
}
and so b often ends up with the value -1 when it leaves the loop.
Then there's a
const char *s = buf-address(b);
and
width = measure_proportional_character(s, 0, p+styleBufOffset);
where it examines this byte at index -1.
Link: http://www.fltk.org/str.php?L2691
Version: 1.3-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2690: fix a debug printf
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2690 Version: 1.3-current Attached file text_display_debug_printf.diff... Link: http://www.fltk.org/str.php?L2690 Version: 1.3-currentIndex: src/Fl_Text_Display.cxx === --- src/Fl_Text_Display.cxx (revision 8867) +++ src/Fl_Text_Display.cxx (working copy) @@ -282,7 +282,7 @@ #endif // DEBUG const int oldWidth = w(); #ifdef DEBUG - printf(oldWidth=%d, mContinuousWrap=%d, mWrapMargin=%d\n, oldWidth, mContinuousWrap, mWrapMargin); + printf(oldWidth=%d, mContinuousWrap=%d, mWrapMarginPix=%d\n, oldWidth, mContinuousWrap, mWrapMarginPix); #endif // DEBUG Fl_Widget::resize(X,Y,W,H); if (!buffer()) return; ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2688: fl_width(' ') with --disable-xft
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2688
Version: 1.3-current
Interesting discovery: fl_width(' ') gives me 10, and fl_width( ) gives
me 3.
Link: http://www.fltk.org/str.php?L2688
Version: 1.3-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2686: fl_draw() not drawing wrapped line starting with @ when draw_symbols is false
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2686 Version: 1.3-current Shouldn't fl_draw.cxx:308 test for draw_symbols, or do I misunderstand what's going on? I have a string of the form first @second third that is wrapped inside a bounding box so that each word is on a separate line, and only the first line is drawn. Link: http://www.fltk.org/str.php?L2686 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2671: xft Fl::set_fonts(): valgrind complains about fnt_obj_set
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2671 Version: 1.3-current I tried adding in an FcObjectSetDestroy(fnt_obj_set); and all seems well afterward. Link: http://www.fltk.org/str.php?L2671 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2658: set_fonts() comments
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2658 Version: 1.3-current The comment block for set_fonts() in Fl.H talks a lot about iso8859-1 as default. fl_set_fonts_x.cxx uses fl_encoding (iso10646-1) by default. fl_set_fonts_xft.cxx says Also, for now I'm ignoring the pattern_name and just getting everything..., which may or may not amount to just getting iso10646-1 if I were to dig more deeply. fl_set_fonts_mac.cxx says #pragma unused ( xstarname ). fl_set_fonts_win32.cxx just passes xstarname != 0 to something, which might do something with it. So it sounds like we should not use the argument, and then always expect iso10646-1 fonts back. Link: http://www.fltk.org/str.php?L2658 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2649: escaped symbol misbehaviour following newline
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2649 Version: 1.3-current I noticed that something like widget-tooltip(word\n@@some text\nmore\nmore); doesn't work properly. I just see text . Link: http://www.fltk.org/str.php?L2649 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2630: out of bounds array access
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2630
Version: 1.3-current
I was giving dillo a bit of valgrinding and got:
==9686== Invalid read of size 4
==9686==at 0x80CDC87: Fl_Text_Display::resize(int, int, int, int)
(Fl_Text_Display.cxx:423)
...
==9686== Address 0x5b0b594 is 4 bytes before a block of size 4 alloc'd
...
where the code goes
while ( (mLineStarts[mNVisibleLines-2]==-1)
scroll_(mTopLineNum-1, mHorizOffset))
{ }
and
mNVisibleLines = 1
Link: http://www.fltk.org/str.php?L2630
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 #2630: out of bounds array access
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2630 Version: 1.3-current Just to note that there's also some mNVisibleLines-2 down in Fl_Text_Display::display_insert() -- although I didn't put any effort into figuring out whether you can get into a situation there with mNVisibleLines 2. Link: http://www.fltk.org/str.php?L2630 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 #2574: events for invisible widgets
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2574 Version: 1.3-current Sorry I've been busy with outside-world stuff of late. I got a little bit of time to try the solution of moving the group outside the bounds of the window last night, but wasn't having success. Another developer (jcid) has been working in that area of the code since I've touched it, too, so... I should be able to give the global shortcuts solution a try tonight. Link: http://www.fltk.org/str.php?L2574 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 #2577: fl_choice focus
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2577 Version: 1.3-current All right. I can understand that you often can't make improvements because you're constrained by compatibility. Link: http://www.fltk.org/str.php?L2577 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 #2577: fl_choice focus
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2577 Version: 1.3-current *checks* At least with our usage, FLTK2 likes to focus the ReturnButton, which is indeed nicely unsurprising for a user. I begin to think the FLTK3 dream will find its share of exciting differences to contend with. Link: http://www.fltk.org/str.php?L2577 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 #2574: events for invisible widgets
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2574 Version: 1.3-current It doesn't appear to work while hidden, presumably because setting INACTIVE means that takesevents() will return false. Link: http://www.fltk.org/str.php?L2574 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 #2574: events for invisible widgets
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2574 Version: 1.3-current Ah yes, that works! Link: http://www.fltk.org/str.php?L2574 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 #2574: events for invisible widgets
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2574 Version: 1.3-current First I tried the patch as written, and the search bar broke because we hide() it initially, and it wasn't reactivated when show()n. So I tried adding a clear_flag(INACTIVE) to show(). Search still didn't work while it was hidden, and I realized that the individual button gets the event, but the bar as a whole is made in/visible, so I removed the parent visibility requirement. It still didn't work, so I svn reverted Fl_Widget.cxx's flag changes away, and then it was working. Link: http://www.fltk.org/str.php?L2574 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2577: fl_choice focus
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2577 Version: 1.3-current As the ask demo will show for fl_choice (triggered by the window callback), button 1 is the return button, but button 0 has the focus box. Maybe it's just me, but the focus box fools me and makes me expect button 0 to be chosen upon enter press. Link: http://www.fltk.org/str.php?L2577 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #2574: events for invisible widgets
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2574
Version: 1.3-current
The widget flag enum says:
       INVISIBLE      = 11,  /// the widget is not
drawn but can receive events
...whereas the code works like:
  unsigned int takesevents() const {
    return !output() active_r() visible_r();
  }
(The fltk2 dillo used a search bar that worked by receiving shortcut
events even when invisible.)
Link: http://www.fltk.org/str.php?L2574
Version: 1.3-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current No objections here! Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current It occurs to me that I might be committing one of those sins of users where we don't explain what we want something for, and then don't get what's quite best for us. - An 'ex' is a unit in CSS, so that's our deepest reason for wanting to keep track of the height of the 'x' for fonts. - We happen to use x-height to determine bullet size, width of underlines, and maybe a couple of other things like that -- but a calculation for these based on ascent or something would probably be no worse. Given that x-height has some typographical importance, is there an existing mechanism to get at the various font properties like that? It's definitely not important enough to ask for any new interfaces for, but if there happens to be a way already... Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2550
Version: 1.3-current
The unittest demo looks good.
The case where it breaks is when Dillo is given an internal URL
(about:splash) from the cmdline and can rush right off to start handling
it earlier than usual.
So I just tried some code with basically nothing in it:
#include FL/Fl.H
#include FL/fl_draw.H
#include FL/Fl_Window.H
int main(int argc, char **argv) {
int xx, xy, xw, xh;
// Fl_Window *window = new Fl_Window(540,380);
// window-begin();
// window-end();
// window-show(argc, argv);
fl_text_extents(x, xx, xy, xw, xh);
return Fl::run();
}
...and it breaks. The window lines didn't make a difference; I just wanted
to see what would happen there.
Link: http://www.fltk.org/str.php?L2550
Version: 1.3-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current Okay, no crash now with the latest code. What does it take to be an open window? Does that mean that I need to wait until Fl::run()? I have window-show(), then fl_font(), then fl_text_extent(), all before Fl::run(), and that gives height 0. I'm guessing that I can throw this stuff behind some Fl::add_timeout()s if necessary and all will be well? Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current I'm getting a segfault: (gdb) bt #0 0xb7e608e8 in XSetFont () from /usr/lib/libX11.so.6 #1 0x080e9ede in XUtf8_measure_extents (display=0x81606a8, d=0, font_set=0x818a6c8, gc=0x0, xx=0xbfffef3c, yy=0xbfffef38, ww=0xbfffef34, hh=0xbfffef30, string=0x810cfa4 , num_bytes=0) at xutf8/utf8Wrap.c:697 #2 0x080d9746 in fl_text_extents (c=0x810cfa3 x, n=1, dx=@0xbfffefc4, dy=@0xbfffefc0, W=@0xbfffefbc, H=@0xbfffefb8) at fl_font_x.cxx:311 #3 0x080d99c5 in fl_text_extents (c=0x810cfa3 x, dx=@0xbfffefc4, dy=@0xbfffefc0, w=@0xbfffefbc, h=@0xbfffefb8) at fl_font.cxx:76 #4 0x0808fbd9 in FltkFont (this=0x8198f98, attrs=0xb1b4) at fltkplatform.cc:120 [...] (gdb) frame 1 #1 0x080e9ede in XUtf8_measure_extents (display=0x81606a8, d=0, font_set=0x818a6c8, gc=0x0, xx=0xbfffef3c, yy=0xbfffef38, ww=0xbfffef34, hh=0xbfffef30, string=0x810cfa4 , num_bytes=0) at xutf8/utf8Wrap.c:697 697 XSetFont(display, gc, fonts[fnum]-fid); (gdb) p display $15 = (Display *) 0x81606a8 (gdb) p gc $16 = (GC) 0x0 (gdb) p fonts[fnum]-fid $17 = 31457286 Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current So it's not at all a matter of using XTextExtents(), then? Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current I see that Xlib also has a Xutf8TextExtents(). Is that unsuitable? (I wouldn't even need three colons to describe the nothing at all that I know about Xlib) Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2550: Xlib fl_text_extents
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current Tried a non-XFT build, saw #warning fl_text_extents is only a test stub in Xlib build at present go by, and indeed a couple of things were a little bit off, as Dillo is using it to measure the height of an x. If this is fundamentally a hard problem, we can work around it without trouble. Link: http://www.fltk.org/str.php?L2550 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2547: error in Fl_Tree sample code
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2547 Version: 1.3-current Above Fl_Tree::first() in Fl_Tree.cxx, the sample code has tree-next() instead of tree-next(item). Link: http://www.fltk.org/str.php?L2547 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 #2543: Fl::lock() availability
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2543 Version: 1.3-current In this case, our user got his FLTK-1.3 from somewhere and didn't compile it himself. So we're presented with whatever we're presented with. As for how much of a true problem it is in our case to call lock() and not get any locking, I'm not sure yet. But having some way for an application to know whether asking FLTK for multithreading will get it anything seems good. Link: http://www.fltk.org/str.php?L2543 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2543: Fl::lock() availability
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2543 Version: 1.3-current It appears that Fl::lock() is always declared, but only defined for WIN32 and if FLTK was compiled to HAVE_PTHREAD. Is there a test that I should be making, other than pawing through fltk-config --ldflags? Link: http://www.fltk.org/str.php?L2543 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 #1987: TextEditor-text() can return garbage
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1987
Version: 2.0-current
This bug just came up on dillo-dev.
It looks to me like TextBuffer::text() should
start as follows:
if (!gapstart_ length_) {
buf_[length_+gapend_] = 0;
return buf_+gapend_;
}
Link: http://www.fltk.org/str.php?L1987
Version: 2.0-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
