Re: [fltk.bugs] [HIGH] STR #2859: wait_for_expose sometimes gets incorrectly wedged
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2859
Version: 1.3-current
Attached file "fltk-1.3.x-resize-expose.patch"...
Link: http://www.fltk.org/str.php?L2859
Version: 1.3-currentdiff -up fltk-1.3.0r9619/src/Fl_x.cxx.expose fltk-1.3.0r9619/src/Fl_x.cxx
--- fltk-1.3.0r9619/src/Fl_x.cxx.expose 2012-07-05 09:49:55.466925868 +0200
+++ fltk-1.3.0r9619/src/Fl_x.cxx2012-07-05 09:50:24.159428363 +0200
@@ -1838,14 +1838,13 @@ int fl_handle(const XEvent& thisevent)
void Fl_Window::resize(int X,int Y,int W,int H) {
int is_a_move = (X != x() || Y != y());
int is_a_resize = (W != w() || H != h());
- int is_a_enlarge = (W > w() || H > h());
int resize_from_program = (this != resize_bug_fix);
if (!resize_from_program) resize_bug_fix = 0;
if (is_a_move && resize_from_program) set_flag(FORCE_POSITION);
else if (!is_a_resize && !is_a_move) return;
if (is_a_resize) {
Fl_Group::resize(X,Y,W,H);
-if (shown()) {redraw(); if(is_a_enlarge) i->wait_for_expose = 1;}
+if (shown()) redraw();
} else {
x(X); y(Y);
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2859: wait_for_expose sometimes gets incorrectly wedged
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2859 Version: 1.3-current Link: http://www.fltk.org/str.php?L2859 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #2859: wait_for_expose sometimes gets incorrectly wedged
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2859 Version: 1.3-current You can get a window into the state where it will no longer render any updates, because wait_for_expose is incorrectly set to true. This happens in Fl_Window::resize() in Fl_x.cxx. The code there assumes that the current width/height is what X11 sees, and enlarging must therefore result in an eventual Expose event. This is incorrect. What happens is that the program requests a resize from e.g. 200x200 to 100x100. The window manager refuses, which it indicates by sending a resize back with the original 200x200 size. There will be no Expose events in this case, as the window never actually changed size. The easy fix is to remove the code that sets wait_for_expose in resize(). It is based on flawed assumptions, so it is currently wrong. Link: http://www.fltk.org/str.php?L2859 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2802: poor modality interaction with local window manager
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2802 Version: 1.3-current I'm afraid I've forgotten the details, but I believe it was necessary to get the correct window decoration. Without that code it would display multiple windows' title bars as "active". Link: http://www.fltk.org/str.php?L2802 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2802: poor modality interaction with local window manager
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2802
Version: 1.3-current
FLTK doesn't tell the local WM that a window is modal, which means that you
lack the visual clues normally associated with it. It is possible to do
better by interacting more with the local WM.
The attached patch does the following:
- Sets _NET_WM_STATE_MODAL on X11
- Redirects focus to the modal window on Win32
- Makes all other windows refuse to become key or main on OS X
This gives an improved behaviour on all platforms in that the window
decorations will always indicate that the modal window has focus. IOW,
FLTK and the local WM now agree on who has focus.
Issues remaining (and I don't intend to address those on this bug):
- X11: Windows are transient/modal for another window, not the entire
window group (this is almost impossible to solve as there are sooo many
bugs in the WMs in this area).
- Win32/OS X: The proper way of doing modal/non-modal windows involves
releasing control of the main loop, so it isn't easily done in FLTK. We
can only try to emulate the native behaviour.
- Win32: Proper behaviour is to blink or otherwise visually indicate that
focus is modal. Right now it simply just refuses to change focus.
- OS X: Layering is off if you have multiple levels of modal/non-modal
windows.
Link: http://www.fltk.org/str.php?L2802
Version: 1.3-currentdiff -up fltk-1.3.0/src/Fl_cocoa.mm.modal fltk-1.3.0/src/Fl_cocoa.mm
--- fltk-1.3.0/src/Fl_cocoa.mm.modal2012-01-25 08:22:49.910577692 +0100
+++ fltk-1.3.0/src/Fl_cocoa.mm 2012-01-25 08:48:20.403135026 +0100
@@ -651,6 +651,14 @@ static void do_timer(CFRunLoopTimerRef t
}
- (BOOL)canBecomeKeyWindow
{
+ if (Fl::modal_ && (Fl::modal_ != w))
+return NO;
+ return YES;
+}
+- (BOOL)canBecomeMainWindow
+{
+ if (Fl::modal_ && (Fl::modal_ != w))
+return NO;
return YES;
}
@end
@@ -2456,6 +2464,7 @@ void Fl_X::make(Fl_Window* w)
if ( w->border() || (!w->modal() && !w->tooltip_window()) ) {
Fl_Tooltip::enter(0);
}
+if (w->modal()) { Fl::modal_ = w; }
w->set_visible();
if ( w->border() || (!w->modal() && !w->tooltip_window()) )
Fl::handle(FL_FOCUS, w);
Fl::first_window(w);
@@ -2478,8 +2487,6 @@ void Fl_X::make(Fl_Window* w)
int old_event = Fl::e_number;
w->handle(Fl::e_number = FL_SHOW);
Fl::e_number = old_event;
-
-if (w->modal()) { Fl::modal_ = w; fl_fix_focus(); }
}
}
diff -up fltk-1.3.0/src/Fl_win32.cxx.modal fltk-1.3.0/src/Fl_win32.cxx
--- fltk-1.3.0/src/Fl_win32.cxx.modal 2012-01-24 21:49:46.778170605 +0100
+++ fltk-1.3.0/src/Fl_win32.cxx 2012-01-24 21:49:46.791170372 +0100
@@ -1075,6 +1075,10 @@ static LRESULT CALLBACK WndProc(HWND hWn
break;
case WM_SETFOCUS:
+if ((Fl::modal_) && (Fl::modal_ != window)) {
+ SetFocus(fl_xid(Fl::modal_));
+ return 0;
+}
Fl::handle(FL_FOCUS, window);
break;
@@ -1828,6 +1832,11 @@ Fl_X* Fl_X::make(Fl_Window* w) {
Fl::e_number = old_event;
w->redraw(); // force draw to happen
}
+
+ // Needs to be done before ShowWindow() to get the correct behaviour
+ // when we get WM_SETFOCUS.
+ if (w->modal()) {Fl::modal_ = w; fl_fix_focus();}
+
// If we've captured the mouse, we dont want to activate any
// other windows from the code, or we lose the capture.
ShowWindow(x->xid, !showit ? SW_SHOWMINNOACTIVE :
@@ -1845,7 +1854,6 @@ Fl_X* Fl_X::make(Fl_Window* w) {
}
}
- if (w->modal()) {Fl::modal_ = w; fl_fix_focus();}
return x;
}
diff -up fltk-1.3.0/src/Fl_x.cxx.modal fltk-1.3.0/src/Fl_x.cxx
--- fltk-1.3.0/src/Fl_x.cxx.modal 2012-01-24 21:49:46.784170498 +0100
+++ fltk-1.3.0/src/Fl_x.cxx 2012-01-24 21:49:46.792170354 +0100
@@ -2066,6 +2066,12 @@ void Fl_X::make_xid(Fl_Window* win, XVis
while (wp->parent()) wp = wp->window();
XSetTransientForHint(fl_display, xp->xid, fl_xid(wp));
if (!wp->visible()) showit = 0; // guess that wm will not show it
+ if (win->modal()) {
+Atom net_wm_state = XInternAtom (fl_display, "_NET_WM_STATE", 0);
+Atom net_wm_state_skip_taskbar = XInternAtom (fl_display,
"_NET_WM_STATE_MODAL", 0);
+XChangeProperty (fl_display, xp->xid, net_wm_state, XA_ATOM, 32,
+PropModeAppend, (unsigned char*) &net_wm_state_skip_taskbar, 1);
+ }
}
// Make sure that borderless windows do not show in the task bar
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2775: OS X window resizing doesn't respect system restrictions
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2775
Version: 1.3-current
The current OS X Fl_Window::resize() method assumes that the system will
respect the resize and move operations given to it. Unfortunately that
isn't always the case. One example is trying to resize the window to
something larger than the screen, which the system will then crop.
When this assumption fails, FLTK and the system get out of sync as to the
window's dimensions and things break in fun and interesting ways.
I've played around with it and determined that the system will send events
back to the application with the size and position it deemed suitable. So
the code should be changed to treat setFrame and setFrameOrigin as
requests, and then wait for the system to act on them. The attached patch
does just that.
Link: http://www.fltk.org/str.php?L2775
Version: 1.3-currentdiff -up fltk-1.3.0/src/Fl_cocoa.mm.orig fltk-1.3.0/src/Fl_cocoa.mm
--- fltk-1.3.0/src/Fl_cocoa.mm.orig 2011-11-21 14:01:46.654077147 +0100
+++ fltk-1.3.0/src/Fl_cocoa.mm 2011-11-21 14:01:48.025083631 +0100
@@ -2600,6 +2600,12 @@ void Fl_Window::resize(int X,int Y,int W
pt.y = [[(NSWindow*)i->xid screen] frame].size.height - (Y + h());
[(NSWindow*)i->xid setFrameOrigin:pt];
}
+// setFrame and setFrameOrigin are only requests to the system to
+// do a resize or move. We will get callbacks later if the system allowed
+// this, and possibly with adjusted values. We avoid processing until
+// that happens (which usually happens directly as setFrame[Origin] is
+// called).
+return;
}
resize_from_system = 0;
if (is_a_resize) {
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2676: fl_alert dialogs etc crashes in XftTextExtents32 on Solaris
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2676 Version: 1.3-current Ah, I see. I've done some more investigation though, and FLTK is off the hook (mostly). AFAICT, Solaris' libXft is completely borked when it comes to bitmap fonts. However, they've done some change in the system at some point that makes fontconfig avoid them. So our systems (which are a bit out of date), are picking Serif14.pcf.Z for "Serif", whilst more updated systems are picking "LucidaBrightRegular.ttf". You can fix the older systems by tweaking the fontconfig settings, at which point it will also choose the Lucida font. You can also see the bad behaviour on new systems by asking for "Gallant", which only exists in a bitmap form. I haven't been able to figure out exactly what they've managed to do to break their libXft, but I'm not sure it is of any importance. So this is to a large extent a Solaris bug and not a FLTK one. The thing that FLTK could improve though is to not crash when Xft cannot open a font. Either try to fall back to "Sans", or exit a bit more gracefully with an error message. Link: http://www.fltk.org/str.php?L2676 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2676: fl_alert dialogs etc crashes in XftTextExtents32 on Solaris
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2676
Version: 1.3-current
I've determined that this is not a header/library version mismatch at
least. I've run the following test software here:
#include
int main(int argc, char **argv)
{
printf("Headers: %d\n", XftVersion);
printf("Library: %d\n", XftGetVersion());
return 0;
}
And it outputs:
bash-3.00# ./xfttest
Headers: 20106
Library: 20106
Link: http://www.fltk.org/str.php?L2676
Version: 1.3-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2676: fl_alert dialogs etc crashes in XftTextExtents32 on Solaris
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2676 Version: 1.3-current I'm hoping I can investigate this further this week. Please hold off a bit before you close it. :) Link: http://www.fltk.org/str.php?L2676 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2665: Wrong application name shown in OS X menu
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2665 Version: 1.3-current The application name used by FLTK when generating the main menu on OS X is wrong as it always uses the process name instead of the bundle one. Attached is a patch that mimics the way the system figures out the application name. Link: http://www.fltk.org/str.php?L2665 Version: 1.3-currentdiff -up fltk-1.3.x-r8772/src/Fl_cocoa.mm.orig fltk-1.3.x-r8772/src/Fl_cocoa.mm --- fltk-1.3.x-r8772/src/Fl_cocoa.mm.orig 2011-06-16 12:32:39.262088892 +0200 +++ fltk-1.3.x-r8772/src/Fl_cocoa.mm2011-06-16 13:00:42.680073109 +0200 @@ -3127,7 +3140,9 @@ static void createAppleMenu(void) NSMenuItem *menuItem; NSString *title; - NSString *nsappname = [[NSProcessInfo processInfo] processName]; + NSString *nsappname = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleName"]; + if (nsappname == nil) +nsappname = [[NSProcessInfo processInfo] processName]; appleMenu = [[NSMenu alloc] initWithTitle:@""]; /* Add menu items */ title = [[NSString stringWithUTF8String:Fl_Mac_App_Menu::about] stringByAppendingString:nsappname]; ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2664: Fl::e_original_keysym isn't set for modifier keys on OS X
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2664
Version: 1.3-current
The flagsChanged code path on OS X set Fl::e_keysym but forgets
Fl::e_original_keysym, causing issues as that will then retain whatever
value the last key press had.
Trivial patch attached.
Link: http://www.fltk.org/str.php?L2664
Version: 1.3-currentdiff -up fltk-1.3.x-r8772/src/Fl_cocoa.mm.orig fltk-1.3.x-r8772/src/Fl_cocoa.mm
--- fltk-1.3.x-r8772/src/Fl_cocoa.mm.orig 2011-06-16 10:59:17.403122205
+0200
+++ fltk-1.3.x-r8772/src/Fl_cocoa.mm2011-06-16 10:59:27.259048663 +0200
@@ -1832,7 +1832,7 @@ static void q_set_window_title(NSWindow
if ( tMods )
{
unsigned short keycode = [theEvent keyCode];
-Fl::e_keysym = macKeyLookUp[keycode & 0x7f];
+Fl::e_keysym = Fl::e_original_keysym = macKeyLookUp[keycode & 0x7f];
if ( Fl::e_keysym )
sendEvent = ( prevMods___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2654: Parent-less popup menu has wrong position
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2654 Version: 1.3-current Yes, that seems to fix it in my test case at least. Link: http://www.fltk.org/str.php?L2654 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 #2647: crash in X11 clipboard code
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2647 Version: 1.3.0 Fix Version: 1.3.0 (r8764) Seems to work nicely with r8772. Thanks! Link: http://www.fltk.org/str.php?L2647 Version: 1.3.0 Fix Version: 1.3.0 (r8764) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2655: screen_xywh fallback cleanup
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2655
Version: 1.3-current
This is a follow-up to STR #2640 and r8738 which cleaned up the
screen_xywh() confusion between screens and workspaces. The patch improves
the fallbacks a bit and also confines the platform specific portions a bit
better.
Link: http://www.fltk.org/str.php?L2655
Version: 1.3-current--- fltk-1.3.x-r8744/src/screen_xywh.cxx.fullscreen 2011-05-26
15:48:00.0 +0200
+++ fltk-1.3.x-r8744/src/screen_xywh.cxx2011-06-01 14:00:08.256046579
+0200
@@ -202,81 +202,21 @@ int Fl::screen_count() {
\param[in] mx, my the absolute screen position
*/
void Fl::screen_xywh(int &X, int &Y, int &W, int &H, int mx, int my) {
- if (num_screens < 0) screen_init();
-
-#ifdef WIN32
- if (num_screens > 0) {
-int i;
-
-for (i = 0; i < num_screens; i ++) {
- if (mx >= screens[i].left && mx < screens[i].right &&
- my >= screens[i].top && my < screens[i].bottom) {
- X = screens[i].left;
- Y = screens[i].top;
- W = screens[i].right - screens[i].left;
- H = screens[i].bottom - screens[i].top;
- return;
- }
-}
- }
- // if all else fails:
- X = Fl::x();
- Y = Fl::y();
- W = Fl::w();
- H = Fl::h();
-#elif defined(__APPLE__)
- if (num_screens > 0) {
-int i;
+ int screen = 0;
+ int i;
-for (i = 0; i < num_screens; i ++) {
- if (mx >= screens[i].x &&
- mx < (screens[i].x + screens[i].width) &&
- my >= screens[i].y &&
- my < (screens[i].y + screens[i].height)) {
- X = screens[i].x;
- Y = screens[i].y;
- W = screens[i].width;
- H = screens[i].height;
- return;
- }
-}
- }
- // if all else fails:
- X = Fl::x();
- Y = Fl::y();
- W = Fl::w();
- H = Fl::h();
-#elif HAVE_XINERAMA
- if (num_screens > 0 && screens) { // screens == NULL if
!XineramaIsActive(fl_display)
-int i;
+ if (num_screens < 0) screen_init();
-for (i = 0; i < num_screens; i ++) {
- if (mx >= screens[i].x_org &&
- mx < (screens[i].x_org + screens[i].width) &&
- my >= screens[i].y_org &&
- my < (screens[i].y_org + screens[i].height)) {
- X = screens[i].x_org;
- Y = screens[i].y_org;
- W = screens[i].width;
- H = screens[i].height;
- return;
- }
+ for (i = 0; i < num_screens; i ++) {
+int sx, sy, sw, sh;
+Fl::screen_xywh(sx, sy, sw, sh, i);
+if ((mx >= sx) && (mx < (sx+sw)) && (my >= sy) && (my < (sy+sh))) {
+ screen = i;
+ break;
}
}
- // if all else fails:
- X = Fl::x();
- Y = Fl::y();
- W = Fl::w();
- H = Fl::h();
-#else
- (void)mx;
- (void)my;
- X = 0;
- Y = 0;
- W = DisplayWidth(fl_display, fl_screen);
- H = DisplayHeight(fl_display, fl_screen);
-#endif // WIN32
+ screen_xywh(X, Y, W, H, screen);
}
/**
@@ -288,47 +228,51 @@ void Fl::screen_xywh(int &X, int &Y, int
void Fl::screen_xywh(int &X, int &Y, int &W, int &H, int n) {
if (num_screens < 0) screen_init();
+ if ((n < 0) || (n >= num_screens))
+n = 0;
+
#ifdef WIN32
- if (num_screens > 0 && n >= 0 && n < num_screens) {
+ if (num_screens > 0) {
X = screens[n].left;
Y = screens[n].top;
W = screens[n].right - screens[n].left;
H = screens[n].bottom - screens[n].top;
} else {
-X = Fl::x();
-Y = Fl::y();
-W = Fl::w();
-H = Fl::h();
+/* Fallback if something is broken... */
+X = 0;
+Y = 0;
+W = GetSystemMetrics(SM_CXSCREEN);
+H = GetSystemMetrics(SM_CYSCREEN);
}
#elif defined(__APPLE__)
- if (num_screens > 0 && n >= 0 && n < num_screens) {
+ if (num_screens > 0) {
X = screens[n].x;
Y = screens[n].y;
W = screens[n].width;
H = screens[n].height;
} else {
+/* Fallback if something is broken... */
X = Fl::x();
Y = Fl::y();
W = Fl::w();
H = Fl::h();
}
-#elif HAVE_XINERAMA
- if (num_screens > 0 && n >= 0 && n < num_screens && screens) {
+#else
+#if HAVE_XINERAMA
+ if (num_screens > 0) {
X = screens[n].x_org;
Y = screens[n].y_org;
W = screens[n].width;
H = screens[n].height;
- } else {
-X = Fl::x();
-Y = Fl::y();
-W = Fl::w();
-H = Fl::h();
+ } else
+#endif // HAVE_XINERAMA
+ {
+/* Fallback if something is broken (or no Xinerama)... */
+X = 0;
+Y = 0;
+W = DisplayWidth(fl_display, fl_screen);
+H = DisplayHeight(fl_display, fl_screen);
}
-#else
- X = 0;
- Y = 0;
- W = DisplayWidth(fl_display, fl_screen);
- H = DisplayHeight(fl_display, fl_screen);
#endif // WIN32
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2654: Parent-less popup menu has wrong position
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2654 Version: 1.3-current I'm using Fl_Menu_Button with box type FL_NO_BOX in order to get a free floating popup menu. In order for it not to confuse Fl_Scroll or create similar problems, I've created it without a parent. Unfortunately that results in it being position incorrectly as it uses Fl::event_x/y() at all times. As these are window relative coordinates, it should check if it has a window and use Fl::event_x/y_root() if not. Link: http://www.fltk.org/str.php?L2654 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 #2647: crash in X11 clipboard code
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2647 Version: 1.3-current You're right on both accounts I'd say. Thanks for spotting those issues. Link: http://www.fltk.org/str.php?L2647 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2647: crash in X11 clipboard code
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2647
Version: 1.3-current
I've been getting crashes sometimes in the X11 clipboard when getting stuff
out of primary from firefox. I didn't do any deep digging into exactly what
kind of junk it was sending as I figured the FLTK code needed to be robust
anyway. Included patch cleans up some old cruft and adds some sanity
checks. I'm no longer able to crash things here.
Link: http://www.fltk.org/str.php?L2647
Version: 1.3-currentdiff -up fltk-1.3.x-r8732/src/Fl_x.cxx.orig fltk-1.3.x-r8732/src/Fl_x.cxx
--- fltk-1.3.x-r8732/src/Fl_x.cxx.orig 2011-05-26 17:11:08.158068729 +0200
+++ fltk-1.3.x-r8732/src/Fl_x.cxx 2011-05-26 17:15:35.860244660 +0200
@@ -1162,18 +1162,15 @@ int fl_handle(const XEvent& thisevent)
fl_event_time);
return true;
}
- XTextProperty text_prop;
- text_prop.value=portion;
- text_prop.format=format;
- text_prop.encoding=actual;
- text_prop.nitems=count;
- char **text_list;
- text_list = (char**)&portion;
- int bytesnew = strlen(*text_list)+1;
- buffer = (unsigned char*)realloc(buffer, bytesread+bytesnew+remaining);
- memcpy(buffer+bytesread, *text_list, bytesnew);
+ // Make sure we got something sane...
+ if ((portion == NULL) || (format != 8) || (count == 0))
+return true;
+ buffer = (unsigned char*)realloc(buffer, bytesread+count+remaining+1);
+ memcpy(buffer+bytesread, portion, count);
XFree(portion);
- bytesread += bytesnew - 1;
+ bytesread += count;
+ // Cannot trust data to be null terminated
+ buffer[bytesread] = '\0';
if (!remaining) break;
}
if (buffer) {
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #2619: wrong menu item returned from popup()
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2619 Version: 1.3-current I have a context menu that's initiated by pressing F8 and is then shown through Fl_Menu_Button::popup(). Unfortunately there is some bug with which item is returned as the result. It seems like I always get back the item the mouse is hovering over. This is not the correct item in at least two cases: 1) When I use the arrow keys and enter to select something else. 2) When I press a menu item shortcut key. The mouse is completely stationary during this so it is not a case of accidentally moving the mouse and changing the selected entry. If the mouse is completely outside the menu, then things seem to work correctly. Link: http://www.fltk.org/str.php?L2619 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 #2613: Invisible menu entries don't work
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2613 Version: 1.3-current The patch seems to solve the issue, yes. Thank you. :) Link: http://www.fltk.org/str.php?L2613 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #2613: Invisible menu entries don't work
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2613 Version: 1.3-current This is what the docs say about invisible menu entries: FL_MENU_INVISIBLE= 0x10, // Item will not show up (shortcut will work) Unfortunately, that's not true. The shortcut is ignored for invisible entries. I've found that this is caused by two bugs: 1. Fl_Menu_Item::find_shortcut() checks activevisible(), when it probably should be checking active(). 2. Fl_Menu_Item::find_shortcut() uses next() to iterate, but that function is defined as skipping invisible items. The first is easy to fix, but the latter not so much. One easy fix is to do the iteration manually in find_shortcut(). Suggestions? Link: http://www.fltk.org/str.php?L2613 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 #2599: expose dead keys to applications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2599 Version: 1.3-feature Neither do I, unfortunately. Do you have some contacts in your end that you could ask to help out? It would be a shame to have the process stall now that we've gotten this far. Link: http://www.fltk.org/str.php?L2599 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 #2599: expose dead keys to applications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2599 Version: 1.3-feature Updated X11 patch that just makes sure that e_text is empty when we're in the middle of a composition. Link: http://www.fltk.org/str.php?L2599 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 #2599: expose dead keys to applications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2599
Version: 1.3-feature
Attached file "fltk-1_v5.3.x-dead-chars-x11.patch"...
Link: http://www.fltk.org/str.php?L2599
Version: 1.3-featurediff -up fltk-1.3.x-r8617/FL/Enumerations.H.dead-x11
fltk-1.3.x-r8617/FL/Enumerations.H
--- fltk-1.3.x-r8617/FL/Enumerations.H.dead-x11 2011-04-14 15:11:34.0
+0200
+++ fltk-1.3.x-r8617/FL/Enumerations.H 2011-04-28 14:09:22.704753444 +0200
@@ -425,6 +425,25 @@ enum Fl_When { // Fl_Widget::when():
/*@}*/ // group: Event States
+/** \name Compose States
+
+ These constants define the state of character composition for the
+ current keyboard event.
+
+ \sa Fl::event_compose_state(), Fl::event_compose_symbol()
+*/
+
+/*@{*/
+
+enum Fl_Compose {
+ FL_COMPOSE_UNKNOWN = 0, ///< current compose status cannot be determined
+ FL_COMPOSE_NONE, ///< no composition active for this event
+ FL_COMPOSE_INTERMEDIATE, ///< the current event is part of a composition
but does not end it
+ FL_COMPOSE_FINAL,///< a composed character has successfully been
construced
+};
+
+/*@}*/ // group: Compose States
+
/** \name Box Types
\brief FLTK standard box types
diff -up fltk-1.3.x-r8617/FL/Fl.H.dead-x11 fltk-1.3.x-r8617/FL/Fl.H
--- fltk-1.3.x-r8617/FL/Fl.H.dead-x11 2011-03-30 14:07:52.0 +0200
+++ fltk-1.3.x-r8617/FL/Fl.H2011-04-28 14:09:22.705753438 +0200
@@ -133,6 +133,8 @@ public: // should be private!
static int e_keysym;
static char* e_text;
static int e_length;
+ static int e_compose_state;
+ static const char* e_compose_symbol;
static Fl_Event_Dispatch e_dispatch;
static Fl_Widget* belowmouse_;
static Fl_Widget* pushed_;
@@ -685,6 +687,9 @@ public:
*/
static int event_length() {return e_length;}
+ static int event_compose_state();
+ static const char* event_compose_symbol();
+
static int compose(int &del);
static void compose_reset();
static int event_inside(int,int,int,int);
diff -up fltk-1.3.x-r8617/src/Fl_compose.cxx.dead-x11
fltk-1.3.x-r8617/src/Fl_compose.cxx
--- fltk-1.3.x-r8617/src/Fl_compose.cxx.dead-x112011-04-01
11:00:07.0 +0200
+++ fltk-1.3.x-r8617/src/Fl_compose.cxx 2011-04-28 14:09:22.721753347 +0200
@@ -31,6 +31,8 @@
#ifndef FL_DOXYGEN
// at present, this is effectively used by Mac OS X only
int Fl::compose_state = 0;
+int Fl::e_compose_state = FL_COMPOSE_UNKNOWN;
+const char* Fl::e_compose_symbol = "";
#endif
#if !defined(WIN32) && !defined(__APPLE__)
@@ -94,6 +94,31 @@ void Fl::compose_reset()
#endif
}
+/**
+ Returns what role the current key press plays in constructing a composed
+ character.
+ \see Fl_Compose
+ */
+int Fl::event_compose_state()
+{
+ return e_compose_state;
+}
+
+/**
+ Returns the raw symbol associated with the current event. This will be
+ the same as what Fl::event_text() returns except when the compose state
+ is FL_COMPOSE_INTERMEDIATE or FL_COMPOSE_FINAL.
+ \see Fl_Compose
+ */
+const char* Fl::event_compose_symbol()
+{
+ if ((e_compose_state == FL_COMPOSE_INTERMEDIATE) ||
+ (e_compose_state == FL_COMPOSE_FINAL))
+return e_compose_symbol;
+
+ return Fl::event_text();
+}
+
//
// End of "$Id: Fl_compose.cxx 8552 2011-04-01 09:00:07Z manolo $"
//
diff -up fltk-1.3.x-r8617/src/Fl_x.cxx.dead-x11 fltk-1.3.x-r8617/src/Fl_x.cxx
--- fltk-1.3.x-r8617/src/Fl_x.cxx.dead-x11 2011-04-18 13:45:46.0
+0200
+++ fltk-1.3.x-r8617/src/Fl_x.cxx 2011-04-28 14:35:11.116861001 +0200
@@ -51,6 +53,7 @@
# include
# include
# include
+# include
static Fl_Xlib_Graphics_Driver fl_xlib_driver;
static Fl_Display_Device fl_xlib_display(&fl_xlib_driver);
@@ -921,9 +924,6 @@ int fl_handle(const XEvent& thisevent)
#endif
}
- if ( XFilterEvent((XEvent *)&xevent, 0) )
- return(1);
-
switch (xevent.type) {
case KeymapNotify:
@@ -1218,9 +1218,11 @@ int fl_handle(const XEvent& thisevent)
case KeyRelease: {
KEYPRESS:
int keycode = xevent.xkey.keycode;
+static int real_keycode;
fl_key_vector[keycode/8] |= (1 << (keycode%8));
static char *buffer = NULL;
static int buffer_len = 0;
+static char *compose_buffer = NULL;
int len;
KeySym keysym;
if (buffer_len == 0) {
@@ -1231,6 +1233,12 @@ int fl_handle(const XEvent& thisevent)
event = FL_KEYDOWN;
int len = 0;
+ // keycode 0 is a fake key, so looking that up is pointless,
+ // instead we rely on the fact that the preceding event was the
+ // real key
+ if (keycode != 0)
+real_keycode = keycode;
+
if (fl_xim_ic) {
Status status;
len = XUtf8LookupString(fl_xim_ic, (XKeyPressedEvent *)&xevent.xkey,
@@ -1242,7 +1250,115 @@ int fl_handle(const XEvent& thisevent)
len = XUtf8LookupString(fl_xim_ic, (XKeyPressedEvent *)&xevent.xkey,
Re: [fltk.bugs] [MOD] STR #2599: expose dead keys to applications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2599 Version: 1.3-feature For X11: I'm not sure I can follow your changes. It seems like the variable you set makes it hide the next character, not the current one. And what's the deal with the Shift keys? The bug in my patch is that it assumed that Xutf8LookupString() would always return nothing for intermediate stages. This is wrong, and the obvious fix is to clear out the buffer whenever XFilterEvent() returns true. Link: http://www.fltk.org/str.php?L2599 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 #2599: expose dead keys to applications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2599 Version: 1.3-feature First off, thanks for helping out so thoroughly in this rather pesky area. :) We'll start of with the mac portions: > With the patch, the result is unpredictable, that is, not reproducible. > This is because there is a memory allocation problem in these statements: The object lifetime handling on Mac takes some getting used to and I can't say I was entirely sure things were correct. From what I understood, most things are put in a "autorelease pool", which generally meant they lived long enough for the event to be processed but no longer. I assumed that e_text and friends were only valid from an FLTK event handler, and hence the lifetime of these objects were sufficient. This was also before I had considered the more advanced input methods. A more robust allocation scheme like the one you have proposed is very much welcome. > Also, I don't understand why you build Fl::e_text in setMarkedText as > the concatenation of the previous Fl::e_text and the received string. This was added to deal with how OS X deals with bad compose sequence. E.g. press dead tilde twice, which will result in: Press 1: setMarkedText (tilde) Press 2: insertText (tilde, overwritting the earlier tilde) setMarkedText (tilde) Hence the need to concatenate the data from insertText with the one from setMarkedText. > I would also suggest that you put the cocoaDead2FLTK function in your > application code rather than in FLTK itself. I added this method for two reasons: 1. We need a set of platform independent symbols, as we cannot rely on all three platforms having the exact same representation of dead keys (they don't). 2. I did not want to use the "non-dead" versions of the symbols as that could possibly create ambiguities. Say on X11 where you could generate ò using either " " or " ". So for applications that want to see the specific symbols, differentiating between "dead" and "non-dead" seemed important. And since Unicode has an equivalent concept in combining characters, that seemed like a good symbol set to use. (The Win32 code has a similar translation routine) Link: http://www.fltk.org/str.php?L2599 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 #2605: Windows key code varies on X11
On Mon, 18 Apr 2011 04:47:11 -0700 (PDT) Manolo Gouy wrote: > > [STR Closed w/Resolution] > > Link: http://www.fltk.org/str.php?L2605 > Version: 1.3.0 > Fix Version: 1.3.0 (r8603) > > > Fixed in Subversion repository. > > Thanks for the patch. > I'm afraid parts of the patch were left out. You need the XK_MISCELLANY portion on Solaris. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2599: expose dead keys to applications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2599 Version: 1.3-feature Updated patches for todays snapshot. Link: http://www.fltk.org/str.php?L2599 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 #2599: expose dead keys to applications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2599
Version: 1.3-feature
Attached file "fltk-1_v3.3.x-dead-chars-mac.patch"...
Link: http://www.fltk.org/str.php?L2599
Version: 1.3-featurediff -up fltk-1.3.x-r8592/src/Fl_cocoa.mm.dead-mac
fltk-1.3.x-r8592/src/Fl_cocoa.mm
--- fltk-1.3.x-r8592/src/Fl_cocoa.mm.dead-mac 2011-04-13 22:50:41.0
+0200
+++ fltk-1.3.x-r8592/src/Fl_cocoa.mm2011-04-15 11:04:18.863876401 +0200
@@ -848,34 +848,26 @@ static void cocoaMouseHandler(NSEvent *t
return;
}
-
-static void calc_e_text(CFStringRef s, char *buffer, size_t len, unsigned sym)
+static const char* cocoaDead2FLTK(const char *in)
{
- int i, no_text_key = false;
- static unsigned notext[] = { // keys that don't emit text
-FL_BackSpace, FL_Print, FL_Scroll_Lock, FL_Pause,
-FL_Insert, FL_Home, FL_Page_Up, FL_Delete, FL_End, FL_Page_Down,
-FL_Left, FL_Up, FL_Right, FL_Down,
-FL_Menu, FL_Num_Lock, FL_Help
- };
- int count = sizeof(notext)/sizeof(int);
-
- if (sym > FL_F && sym <= FL_F_Last) no_text_key = true;
- else for (i=0; i < count; i++) {
-if (notext[i] == sym) {
- no_text_key = true;
- break;
- }
- }
-
- if (no_text_key) {
-buffer[0] = 0;
- } else {
-CFStringGetCString(s, buffer, len, kCFStringEncodingUTF8);
- }
+ if (strcmp(in, "\140") == 0) // GRAVE ACCENT
+return "\314\200"; // COMBINING GRAVE ACCENT
+ if (strcmp(in, "\302\264") == 0) // ACUTE ACCENT
+return "\314\201"; // COMBINING ACUTE ACCENT
+ if (strcmp(in, "\136") == 0) // CIRCUMFLEX ACCENT
+return "\314\202"; // COMBINING CIRCUMFLEX ACCENT
+ if (strcmp(in, "\176") == 0) // TILDE
+return "\314\203"; // COMBINING TILDE
+ if (strcmp(in, "\302\250") == 0) // DIAERESIS
+return "\314\210"; // COMBINING DIAERESIS
+ // FIXME: OS X dead key behaviour isn't documented and I don't have
+ //any more keyboards to test with...
+
+ // hope that OS X gave us something proper to begin with
+ return in;
}
-static int cocoaKeyboardHandler(NSEvent *theEvent);
+static void cocoaKeyboardHandler(NSEvent *theEvent);
@interface FLTextView : NSTextView
// this subclass is needed under OS X <= 10.4 but not under >= 10.5 where the
base class is enough
@@ -885,11 +877,13 @@ static int cocoaKeyboardHandler(NSEvent
@implementation FLTextView
- (void)insertText:(id)aString
{
- cocoaKeyboardHandler([NSApp currentEvent]);
+ //NSLog(@"FLTextView:insertText:");
+ [[[NSApp keyWindow] contentView] insertText:aString];
}
- (void)doCommandBySelector:(SEL)aSelector
{
- cocoaKeyboardHandler([NSApp currentEvent]);
+ //NSLog(@"FLTextView:doCommandBySelector:");
+ [[[NSApp keyWindow] contentView] doCommandBySelector:aSelector];
}
@end
@@ -902,15 +896,10 @@ Events during a character composition se
replace the temporary character by this one
- keyup -> [theEvent characters] contains the standard character
*/
-static int cocoaKeyboardHandler(NSEvent *theEvent)
+static void cocoaKeyboardHandler(NSEvent *theEvent)
{
- static char buffer[32];
- int sendEvent = 0, retval = 0;
- Fl_Window *window = (Fl_Window*)[(FLWindow*)[theEvent window] getFl_Window];
- Fl::first_window(window);
NSUInteger mods;
- fl_lock_function();
// get the modifiers
mods = [theEvent modifierFlags];
// get the key code
@@ -926,40 +915,32 @@ static int cocoaKeyboardHandler(NSEvent
// In this mode, there seem to be no key-down codes
// printf("%08x %08x %08x\n", keyCode, mods, key);
maskedKeyCode = keyCode & 0x7f;
- switch([theEvent type]) {
-case NSKeyDown:
- sendEvent = FL_KEYBOARD;
- // fall through
-case NSKeyUp:
- if ( !sendEvent ) {
-sendEvent = FL_KEYUP;
-Fl::e_state &= 0xbfff; // clear the deadkey flag
- }
- mods_to_e_state( mods ); // process modifier keys
- sym = macKeyLookUp[maskedKeyCode];
- if (sym < 0xff00) { // a "simple" key
- // find the result of this key without modifier
- NSString *sim = [theEvent charactersIgnoringModifiers];
- UniChar one;
- CFStringGetCharacters((CFStringRef)sim, CFRangeMake(0, 1), &one);
- // charactersIgnoringModifiers doesn't ignore shift, remove it when
it's on
- if(one >= 'A' && one <= 'Z') one += 32;
- if (one > 0 && one <= 0x7f && (sym<'0' || sym>'9') ) sym = one;
- }
- Fl::e_keysym = Fl::e_original_keysym = sym;
- // Handle FL_KP_Enter on regular keyboards and on Powerbooks
- if ( maskedKeyCode==0x4c || maskedKeyCode==0x34) s = @"\r";
- calc_e_text((CFStringRef)s, buffer, sizeof(buffer), sym);
- Fl::e_length = strlen(buffer);
- Fl::e_text = buffer;
-default: // prevent 'not handled in switch' warnings
- break;
+
+ if ([theEvent type] == NSKeyUp) {
+Fl::e_state &= 0xbfff
Re: [fltk.bugs] [MOD] STR #2599: expose dead keys to applications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2599
Version: 1.3-feature
Attached file "fltk-1_v3.3.x-dead-chars-x11.patch"...
Link: http://www.fltk.org/str.php?L2599
Version: 1.3-featurediff -up fltk-1.3.x-r8592/FL/Enumerations.H.dead-x11
fltk-1.3.x-r8592/FL/Enumerations.H
--- fltk-1.3.x-r8592/FL/Enumerations.H.dead-x11 2011-04-14 15:11:34.0
+0200
+++ fltk-1.3.x-r8592/FL/Enumerations.H 2011-04-15 10:52:19.457097928 +0200
@@ -425,6 +425,25 @@ enum Fl_When { // Fl_Widget::when():
/*@}*/ // group: Event States
+/** \name Compose States
+
+ These constants define the state of character composition for the
+ current keyboard event.
+
+ \sa Fl::event_compose_state(), Fl::event_compose_symbol()
+*/
+
+/*@{*/
+
+enum Fl_Compose {
+ FL_COMPOSE_UNKNOWN = 0, ///< current compose status cannot be determined
+ FL_COMPOSE_NONE, ///< no composition active for this event
+ FL_COMPOSE_INTERMEDIATE, ///< the current event is part of a composition
but does not end it
+ FL_COMPOSE_FINAL,///< a composed character has successfully been
construced
+};
+
+/*@}*/ // group: Compose States
+
/** \name Box Types
\brief FLTK standard box types
diff -up fltk-1.3.x-r8592/FL/Fl.H.dead-x11 fltk-1.3.x-r8592/FL/Fl.H
--- fltk-1.3.x-r8592/FL/Fl.H.dead-x11 2011-03-30 14:07:52.0 +0200
+++ fltk-1.3.x-r8592/FL/Fl.H2011-04-15 10:52:19.458097922 +0200
@@ -133,6 +133,8 @@ public: // should be private!
static int e_keysym;
static char* e_text;
static int e_length;
+ static int e_compose_state;
+ static const char* e_compose_symbol;
static Fl_Event_Dispatch e_dispatch;
static Fl_Widget* belowmouse_;
static Fl_Widget* pushed_;
@@ -685,6 +687,9 @@ public:
*/
static int event_length() {return e_length;}
+ static int event_compose_state();
+ static const char* event_compose_symbol();
+
static int compose(int &del);
static void compose_reset();
static int event_inside(int,int,int,int);
diff -up fltk-1.3.x-r8592/src/Fl_compose.cxx.dead-x11
fltk-1.3.x-r8592/src/Fl_compose.cxx
--- fltk-1.3.x-r8592/src/Fl_compose.cxx.dead-x112011-04-01
11:00:07.0 +0200
+++ fltk-1.3.x-r8592/src/Fl_compose.cxx 2011-04-15 10:54:12.503442977 +0200
@@ -31,6 +31,8 @@
#ifndef FL_DOXYGEN
// at present, this is effectively used by Mac OS X only
int Fl::compose_state = 0;
+int Fl::e_compose_state = FL_COMPOSE_UNKNOWN;
+const char* Fl::e_compose_symbol = "";
#endif
#if !defined(WIN32) && !defined(__APPLE__)
@@ -94,6 +96,31 @@ void Fl::compose_reset()
#endif
}
+/**
+ Returns what role the current key press plays in constructing a composed
+ character.
+ \see Fl_Compose
+ */
+int Fl::event_compose_state()
+{
+ return e_compose_state;
+}
+
+/**
+ Returns the raw symbol associated with the current event. This will be
+ the same as what Fl::event_text() returns except when the compose state
+ is FL_COMPOSE_INTERMEDIATE or FL_COMPOSE_FINAL.
+ \see Fl_Compose
+ */
+const char* Fl::event_compose_symbol()
+{
+ if ((e_compose_state == FL_COMPOSE_INTERMEDIATE) ||
+ (e_compose_state == FL_COMPOSE_FINAL))
+return e_compose_symbol;
+
+ return Fl::event_text();
+}
+
//
// End of "$Id: Fl_compose.cxx 8552 2011-04-01 09:00:07Z manolo $"
//
diff -up fltk-1.3.x-r8592/src/Fl_x.cxx.dead-x11 fltk-1.3.x-r8592/src/Fl_x.cxx
--- fltk-1.3.x-r8592/src/Fl_x.cxx.dead-x11 2011-02-26 15:14:50.0
+0100
+++ fltk-1.3.x-r8592/src/Fl_x.cxx 2011-04-15 10:52:19.460097911 +0200
@@ -35,6 +35,8 @@
/ Define this if your keyboard lacks a backspace key... /
/* #define BACKSPACE_HACK 1 */
+# define XK_XKB_KEYS
+
# include
# include
# include
@@ -50,6 +52,7 @@
# include
# include
# include
+# include
static Fl_Xlib_Graphics_Driver fl_xlib_driver;
static Fl_Display_Device fl_xlib_display(&fl_xlib_driver);
@@ -920,9 +923,6 @@ int fl_handle(const XEvent& thisevent)
#endif
}
- if ( XFilterEvent((XEvent *)&xevent, 0) )
- return(1);
-
switch (xevent.type) {
case KeymapNotify:
@@ -1217,9 +1217,11 @@ int fl_handle(const XEvent& thisevent)
case KeyRelease: {
KEYPRESS:
int keycode = xevent.xkey.keycode;
+static int real_keycode;
fl_key_vector[keycode/8] |= (1 << (keycode%8));
static char *buffer = NULL;
static int buffer_len = 0;
+static char *compose_buffer = NULL;
int len;
KeySym keysym;
if (buffer_len == 0) {
@@ -1230,6 +1232,12 @@ int fl_handle(const XEvent& thisevent)
event = FL_KEYDOWN;
int len = 0;
+ // keycode 0 is a fake key, so looking that up is pointless,
+ // instead we rely on the fact that the preceding event was the
+ // real key
+ if (keycode != 0)
+real_keycode = keycode;
+
if (fl_xim_ic) {
Status status;
len = XUtf8LookupString(fl_xim_ic, (XKeyPre
Re: [fltk.bugs] [HIGH] STR #2583: inconcistent alpha behaviour for fl_draw_image()
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2583 Version: 1.3-current The initial bug is now properly fixed in todays snapshot. Many thanks. :) Link: http://www.fltk.org/str.php?L2583 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2607: Bad include of FL/gl.h in Fl_Gl_Window.cxx
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2607 Version: 1.3-current r8536 introduced this: Index: src/Fl_Gl_Window.cxx === --- src/Fl_Gl_Window.cxx(revision 8535) +++ src/Fl_Gl_Window.cxx(revision 8536) @@ -34,6 +34,9 @@ #include #include +#ifdef __APPLE__ +#include +#endif #include "Fl_Gl_Choice.H" #include #include Problem is, the file is called "gl.h", not "gl.H". Makes the compilation fail on case sensitive file systems. Link: http://www.fltk.org/str.php?L2607 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2605: Windows key code varies on X11
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2605
Version: 1.3-current
For the first few years after the Windows key appeared, people couldn't
agree on which X11 keysym to use for it. So different systems will use one
of XK_Meta_x, XK_Hyper_x and XK_Super_x. These days it's generally Super
that's used, but FLTK expects Meta.
The attached patch makes FLTK report the same FLTK key code for all three
variants.
Link: http://www.fltk.org/str.php?L2605
Version: 1.3-currentdiff -up fltk-1.3.x-r8530/src/Fl_x.cxx.super fltk-1.3.x-r8530/src/Fl_x.cxx
--- fltk-1.3.x-r8530/src/Fl_x.cxx.super 2011-04-14 16:24:10.774674182 +0200
+++ fltk-1.3.x-r8530/src/Fl_x.cxx 2011-04-14 16:24:55.460432541 +0200
@@ -36,6 +36,7 @@
/* #define BACKSPACE_HACK 1 */
# define XK_XKB_KEYS
+# define XK_MISCELLANY
# include
# include
@@ -1432,6 +1433,21 @@ int fl_handle(const XEvent& thisevent)
else if (keysym == FL_BackSpace) got_backspace = 1;
}
# endif
+// For the first few years, there wasn't a good concensus on what the
+// Windows keys should be mapped to for X11. So we need to help out a
+// bit and map all variants to the same FLTK key...
+switch (keysym) {
+case XK_Meta_L:
+case XK_Hyper_L:
+case XK_Super_L:
+ keysym = FL_Meta_L;
+ break;
+case XK_Meta_R:
+case XK_Hyper_R:
+case XK_Super_R:
+ keysym = FL_Meta_R;
+ break;
+}
// We have to get rid of the XK_KP_function keys, because they are
// not produced on Windoze and thus case statements tend not to check
// for them. There are 15 of these in the range 0xff91 ... 0xff9f
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2583: inconcistent alpha behaviour for fl_draw_image()
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2583 Version: 1.3-current Any updates to this issue? It would be nice to get committed as things won't work for me on Mac without this. Link: http://www.fltk.org/str.php?L2583 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 #2599: expose dead keys to applications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2599 Version: 1.3-feature Updated patches for X11 and Mac. The X11 patch fixes a header issue for Solaris. The Mac patch starts doing FL_PASTE for insertText calls that aren't part of a keyboard event. As for CJK, I have to admit that I have no experience how that works. As the current code states that CJK is a future project, my assumption was that I didn't need to fix that now. It's not really something I have the means to deal with now anyway. Link: http://www.fltk.org/str.php?L2599 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 #2599: expose dead keys to applications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2599
Version: 1.3-feature
Attached file "fltk-1_v2.3.x-dead-chars-mac.patch"...
Link: http://www.fltk.org/str.php?L2599
Version: 1.3-featurediff -up fltk-1.3.x-r8530/src/Fl_cocoa.mm.dead-mac
fltk-1.3.x-r8530/src/Fl_cocoa.mm
--- fltk-1.3.x-r8530/src/Fl_cocoa.mm.dead-mac 2011-03-24 13:58:32.0
+0100
+++ fltk-1.3.x-r8530/src/Fl_cocoa.mm2011-04-06 13:50:41.761364334 +0200
@@ -837,34 +837,26 @@ static void cocoaMouseHandler(NSEvent *t
return;
}
-
-static void calc_e_text(CFStringRef s, char *buffer, size_t len, unsigned sym)
+static const char* cocoaDead2FLTK(const char *in)
{
- int i, no_text_key = false;
- static unsigned notext[] = { // keys that don't emit text
-FL_BackSpace, FL_Print, FL_Scroll_Lock, FL_Pause,
-FL_Insert, FL_Home, FL_Page_Up, FL_Delete, FL_End, FL_Page_Down,
-FL_Left, FL_Up, FL_Right, FL_Down,
-FL_Menu, FL_Num_Lock, FL_Help
- };
- int count = sizeof(notext)/sizeof(int);
-
- if (sym > FL_F && sym <= FL_F_Last) no_text_key = true;
- else for (i=0; i < count; i++) {
-if (notext[i] == sym) {
- no_text_key = true;
- break;
- }
- }
-
- if (no_text_key) {
-buffer[0] = 0;
- } else {
-CFStringGetCString(s, buffer, len, kCFStringEncodingUTF8);
- }
+ if (strcmp(in, "\140") == 0) // GRAVE ACCENT
+return "\314\200"; // COMBINING GRAVE ACCENT
+ if (strcmp(in, "\302\264") == 0) // ACUTE ACCENT
+return "\314\201"; // COMBINING ACUTE ACCENT
+ if (strcmp(in, "\136") == 0) // CIRCUMFLEX ACCENT
+return "\314\202"; // COMBINING CIRCUMFLEX ACCENT
+ if (strcmp(in, "\176") == 0) // TILDE
+return "\314\203"; // COMBINING TILDE
+ if (strcmp(in, "\302\250") == 0) // DIAERESIS
+return "\314\210"; // COMBINING DIAERESIS
+ // FIXME: OS X dead key behaviour isn't documented and I don't have
+ //any more keyboards to test with...
+
+ // hope that OS X gave us something proper to begin with
+ return in;
}
-static int cocoaKeyboardHandler(NSEvent *theEvent);
+static void cocoaKeyboardHandler(NSEvent *theEvent);
@interface FLTextView : NSTextView
// this subclass is needed under OS X <= 10.4 but not under >= 10.5 where the
base class is enough
@@ -874,11 +866,13 @@ static int cocoaKeyboardHandler(NSEvent
@implementation FLTextView
- (void)insertText:(id)aString
{
- cocoaKeyboardHandler([NSApp currentEvent]);
+ //NSLog(@"FLTextView:insertText:");
+ [[[NSApp keyWindow] contentView] insertText:aString];
}
- (void)doCommandBySelector:(SEL)aSelector
{
- cocoaKeyboardHandler([NSApp currentEvent]);
+ //NSLog(@"FLTextView:doCommandBySelector:");
+ [[[NSApp keyWindow] contentView] doCommandBySelector:aSelector];
}
@end
@@ -891,15 +885,10 @@ Events during a character composition se
replace the temporary character by this one
- keyup -> [theEvent characters] contains the standard character
*/
-static int cocoaKeyboardHandler(NSEvent *theEvent)
+static void cocoaKeyboardHandler(NSEvent *theEvent)
{
- static char buffer[32];
- int sendEvent = 0, retval = 0;
- Fl_Window *window = (Fl_Window*)[(FLWindow*)[theEvent window] getFl_Window];
- Fl::first_window(window);
NSUInteger mods;
- fl_lock_function();
// get the modifiers
mods = [theEvent modifierFlags];
// get the key code
@@ -915,40 +904,32 @@ static int cocoaKeyboardHandler(NSEvent
// In this mode, there seem to be no key-down codes
// printf("%08x %08x %08x\n", keyCode, mods, key);
maskedKeyCode = keyCode & 0x7f;
- switch([theEvent type]) {
-case NSKeyDown:
- sendEvent = FL_KEYBOARD;
- // fall through
-case NSKeyUp:
- if ( !sendEvent ) {
-sendEvent = FL_KEYUP;
-Fl::e_state &= 0xbfff; // clear the deadkey flag
- }
- mods_to_e_state( mods ); // process modifier keys
- sym = macKeyLookUp[maskedKeyCode];
- if (sym < 0xff00) { // a "simple" key
- // find the result of this key without modifier
- NSString *sim = [theEvent charactersIgnoringModifiers];
- UniChar one;
- CFStringGetCharacters((CFStringRef)sim, CFRangeMake(0, 1), &one);
- // charactersIgnoringModifiers doesn't ignore shift, remove it when
it's on
- if(one >= 'A' && one <= 'Z') one += 32;
- if (one > 0 && one <= 0x7f && (sym<'0' || sym>'9') ) sym = one;
- }
- Fl::e_keysym = Fl::e_original_keysym = sym;
- // Handle FL_KP_Enter on regular keyboards and on Powerbooks
- if ( maskedKeyCode==0x4c || maskedKeyCode==0x34) s = @"\r";
- calc_e_text((CFStringRef)s, buffer, sizeof(buffer), sym);
- Fl::e_length = strlen(buffer);
- Fl::e_text = buffer;
-default: // prevent 'not handled in switch' warnings
- break;
+
+ if ([theEvent type] == NSKeyUp) {
+Fl::e_state &= 0xbfff
Re: [fltk.bugs] [MOD] STR #2599: expose dead keys to applications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2599 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2599 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 #2599: expose dead keys to applications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2599
Version: 1.3-feature
Attached file "fltk-1_v2.3.x-dead-chars-x11.patch"...
Link: http://www.fltk.org/str.php?L2599
Version: 1.3-featurediff -up fltk-1.3.x-r8530/FL/Enumerations.H.dead-x11
fltk-1.3.x-r8530/FL/Enumerations.H
--- fltk-1.3.x-r8530/FL/Enumerations.H.dead-x11 2011-03-06 23:40:26.0
+0100
+++ fltk-1.3.x-r8530/FL/Enumerations.H 2011-03-31 13:43:53.937068283 +0200
@@ -425,6 +425,25 @@ enum Fl_When { // Fl_Widget::when():
/*@}*/ // group: Event States
+/** \name Compose States
+
+ These constants define the state of character composition for the
+ current keyboard event.
+
+ \sa Fl::event_compose_state(), Fl::event_compose_symbol()
+*/
+
+/*@{*/
+
+enum Fl_Compose {
+ FL_COMPOSE_UNKNOWN = 0, ///< current compose status cannot be determined
+ FL_COMPOSE_NONE, ///< no composition active for this event
+ FL_COMPOSE_INTERMEDIATE, ///< the current event is part of a composition
but does not end it
+ FL_COMPOSE_FINAL,///< a composed character has successfully been
construced
+};
+
+/*@}*/ // group: Compose States
+
/** \name Box Types
\brief FLTK standard box types
diff -up fltk-1.3.x-r8530/FL/Fl.H.dead-x11 fltk-1.3.x-r8530/FL/Fl.H
--- fltk-1.3.x-r8530/FL/Fl.H.dead-x11 2011-03-21 17:32:37.0 +0100
+++ fltk-1.3.x-r8530/FL/Fl.H2011-03-31 13:43:53.937068283 +0200
@@ -132,6 +132,8 @@ public: // should be private!
static int e_keysym;
static char* e_text;
static int e_length;
+ static int e_compose_state;
+ static const char* e_compose_symbol;
static Fl_Event_Dispatch e_dispatch;
static Fl_Widget* belowmouse_;
static Fl_Widget* pushed_;
@@ -677,6 +679,9 @@ public:
*/
static int event_length() {return e_length;}
+ static int event_compose_state();
+ static const char* event_compose_symbol();
+
static int compose(int &del);
static void compose_reset();
static int event_inside(int,int,int,int);
diff -up fltk-1.3.x-r8530/src/Fl_compose.cxx.dead-x11
fltk-1.3.x-r8530/src/Fl_compose.cxx
--- fltk-1.3.x-r8530/src/Fl_compose.cxx.dead-x112011-03-21
17:32:37.0 +0100
+++ fltk-1.3.x-r8530/src/Fl_compose.cxx 2011-03-31 13:43:53.946068949 +0200
@@ -31,6 +31,8 @@
#ifndef FL_DOXYGEN
// at present, this is effectively used by Mac OS X only
int Fl::compose_state = 0;
+int Fl::e_compose_state = FL_COMPOSE_UNKNOWN;
+const char* Fl::e_compose_symbol = "";
#endif
#if !defined(WIN32) && !defined(__APPLE__)
@@ -94,6 +94,31 @@ void Fl::compose_reset()
#endif
}
+/**
+ Returns what role the current key press plays in constructing a composed
+ character.
+ \see Fl_Compose
+ */
+int Fl::event_compose_state()
+{
+ return e_compose_state;
+}
+
+/**
+ Returns the raw symbol associated with the current event. This will be
+ the same as what Fl::event_text() returns except when the compose state
+ is FL_COMPOSE_INTERMEDIATE or FL_COMPOSE_FINAL.
+ \see Fl_Compose
+ */
+const char* Fl::event_compose_symbol()
+{
+ if ((e_compose_state == FL_COMPOSE_INTERMEDIATE) ||
+ (e_compose_state == FL_COMPOSE_FINAL))
+return e_compose_symbol;
+
+ return Fl::event_text();
+}
+
//
// End of "$Id: Fl_compose.cxx 8522 2011-03-21 16:32:37Z manolo $"
//
diff -up fltk-1.3.x-r8530/src/Fl_x.cxx.dead-x11 fltk-1.3.x-r8530/src/Fl_x.cxx
--- fltk-1.3.x-r8530/src/Fl_x.cxx.dead-x11 2011-02-26 15:14:50.0
+0100
+++ fltk-1.3.x-r8530/src/Fl_x.cxx 2011-03-31 14:26:02.481170514 +0200
@@ -35,6 +35,8 @@
/ Define this if your keyboard lacks a backspace key... /
/* #define BACKSPACE_HACK 1 */
+# define XK_XKB_KEYS
+
# include
# include
# include
@@ -50,6 +52,7 @@
# include
# include
# include
+# include
static Fl_Xlib_Graphics_Driver fl_xlib_driver;
static Fl_Display_Device fl_xlib_display(&fl_xlib_driver);
@@ -920,9 +923,6 @@ int fl_handle(const XEvent& thisevent)
#endif
}
- if ( XFilterEvent((XEvent *)&xevent, 0) )
- return(1);
-
switch (xevent.type) {
case KeymapNotify:
@@ -1217,9 +1217,11 @@ int fl_handle(const XEvent& thisevent)
case KeyRelease: {
KEYPRESS:
int keycode = xevent.xkey.keycode;
+static int real_keycode;
fl_key_vector[keycode/8] |= (1 << (keycode%8));
static char *buffer = NULL;
static int buffer_len = 0;
+static char *compose_buffer = NULL;
int len;
KeySym keysym;
if (buffer_len == 0) {
@@ -1230,6 +1232,12 @@ int fl_handle(const XEvent& thisevent)
event = FL_KEYDOWN;
int len = 0;
+ // keycode 0 is a fake key, so looking that up is pointless,
+ // instead we rely on the fact that the preceding event was the
+ // real key
+ if (keycode != 0)
+real_keycode = keycode;
+
if (fl_xim_ic) {
Status status;
len = XUtf8LookupString(fl_xim_ic, (XKeyPre
Re: [fltk.bugs] [MOD] STR #2599: expose dead keys to applications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2599 Version: 1.3-feature Ah. Mac is still new to me, so please continue to examine those portions extra carefully. For this specific case, it seems that you can get input directly through insertText. Since this isn't a key press, I'm reluctant to present it to the application as such. I see three possible solutions here: 1) Fake a keydown (and possibly key up) using a special key code meaning "this isn't really an actual key". 2) Send the text as a FL_PASTE event. 3) Create a new event type, something like FL_TEXT. Opinions? For the next question, the X11 patch also includes the basic groundwork for this change. The second modification to Fl_compose.cxx is because the Mac code was structured a bit oddly compared to other platforms: - The input widgets rely on Fl::compose() returning false for keys that need special care. - All platforms except Mac has a test in Fl::compose() for control characters, fixing this. - For Mac, the check was instead done in the platform code and achieved the correct result by clearing out e_text. I changed the code so that Mac behaves like the other platforms by looking for control characters. To be honest, Fl::compose() probably needs a rewrite to make it cleaner. Link: http://www.fltk.org/str.php?L2599 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 #2599: expose dead keys to applications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2599
Version: 1.3-feature
Attached file "fltk-1.3.x-dead-chars-mac.patch"...
Link: http://www.fltk.org/str.php?L2599
Version: 1.3-featurediff -up fltk-1.3.x-r8501/src/Fl_cocoa.mm.dead-mac
fltk-1.3.x-r8501/src/Fl_cocoa.mm
--- fltk-1.3.x-r8501/src/Fl_cocoa.mm.dead-mac 2011-03-01 13:37:34.0
+0100
+++ fltk-1.3.x-r8501/src/Fl_cocoa.mm2011-03-31 12:57:53.439955142 +0200
@@ -837,34 +837,26 @@ static void cocoaMouseHandler(NSEvent *t
return;
}
-
-static void calc_e_text(CFStringRef s, char *buffer, size_t len, unsigned sym)
+static const char* cocoaDead2FLTK(const char *in)
{
- int i, no_text_key = false;
- static unsigned notext[] = { // keys that don't emit text
-FL_BackSpace, FL_Print, FL_Scroll_Lock, FL_Pause,
-FL_Insert, FL_Home, FL_Page_Up, FL_Delete, FL_End, FL_Page_Down,
-FL_Left, FL_Up, FL_Right, FL_Down,
-FL_Menu, FL_Num_Lock, FL_Help
- };
- int count = sizeof(notext)/sizeof(int);
-
- if (sym > FL_F && sym <= FL_F_Last) no_text_key = true;
- else for (i=0; i < count; i++) {
-if (notext[i] == sym) {
- no_text_key = true;
- break;
- }
- }
-
- if (no_text_key) {
-buffer[0] = 0;
- } else {
-CFStringGetCString(s, buffer, len, kCFStringEncodingUTF8);
- }
+ if (strcmp(in, "\140") == 0) // GRAVE ACCENT
+return "\314\200"; // COMBINING GRAVE ACCENT
+ if (strcmp(in, "\302\264") == 0) // ACUTE ACCENT
+return "\314\201"; // COMBINING ACUTE ACCENT
+ if (strcmp(in, "\136") == 0) // CIRCUMFLEX ACCENT
+return "\314\202"; // COMBINING CIRCUMFLEX ACCENT
+ if (strcmp(in, "\176") == 0) // TILDE
+return "\314\203"; // COMBINING TILDE
+ if (strcmp(in, "\302\250") == 0) // DIAERESIS
+return "\314\210"; // COMBINING DIAERESIS
+ // FIXME: OS X dead key behaviour isn't documented and I don't have
+ //any more keyboards to test with...
+
+ // hope that OS X gave us something proper to begin with
+ return in;
}
-static int cocoaKeyboardHandler(NSEvent *theEvent);
+static void cocoaKeyboardHandler(NSEvent *theEvent);
@interface FLTextView : NSTextView
// this subclass is needed under OS X <= 10.4 but not under >= 10.5 where the
base class is enough
@@ -874,11 +866,13 @@ static int cocoaKeyboardHandler(NSEvent
@implementation FLTextView
- (void)insertText:(id)aString
{
- cocoaKeyboardHandler([NSApp currentEvent]);
+ //NSLog(@"FLTextView:insertText:");
+ [[[NSApp keyWindow] contentView] insertText:aString];
}
- (void)doCommandBySelector:(SEL)aSelector
{
- cocoaKeyboardHandler([NSApp currentEvent]);
+ //NSLog(@"FLTextView:doCommandBySelector:");
+ [[[NSApp keyWindow] contentView] doCommandBySelector:aSelector];
}
@end
@@ -891,15 +885,10 @@ Events during a character composition se
replace the temporary character by this one
- keyup -> [theEvent characters] contains the standard character
*/
-static int cocoaKeyboardHandler(NSEvent *theEvent)
+static void cocoaKeyboardHandler(NSEvent *theEvent)
{
- static char buffer[32];
- int sendEvent = 0, retval = 0;
- Fl_Window *window = (Fl_Window*)[(FLWindow*)[theEvent window] getFl_Window];
- Fl::first_window(window);
NSUInteger mods;
- fl_lock_function();
// get the modifiers
mods = [theEvent modifierFlags];
// get the key code
@@ -915,40 +904,32 @@ static int cocoaKeyboardHandler(NSEvent
// In this mode, there seem to be no key-down codes
// printf("%08x %08x %08x\n", keyCode, mods, key);
maskedKeyCode = keyCode & 0x7f;
- switch([theEvent type]) {
-case NSKeyDown:
- sendEvent = FL_KEYBOARD;
- // fall through
-case NSKeyUp:
- if ( !sendEvent ) {
-sendEvent = FL_KEYUP;
-Fl::e_state &= 0xbfff; // clear the deadkey flag
- }
- mods_to_e_state( mods ); // process modifier keys
- sym = macKeyLookUp[maskedKeyCode];
- if (sym < 0xff00) { // a "simple" key
- // find the result of this key without modifier
- NSString *sim = [theEvent charactersIgnoringModifiers];
- UniChar one;
- CFStringGetCharacters((CFStringRef)sim, CFRangeMake(0, 1), &one);
- // charactersIgnoringModifiers doesn't ignore shift, remove it when
it's on
- if(one >= 'A' && one <= 'Z') one += 32;
- if (one > 0 && one <= 0x7f && (sym<'0' || sym>'9') ) sym = one;
- }
- Fl::e_keysym = Fl::e_original_keysym = sym;
- // Handle FL_KP_Enter on regular keyboards and on Powerbooks
- if ( maskedKeyCode==0x4c || maskedKeyCode==0x34) s = @"\r";
- calc_e_text((CFStringRef)s, buffer, sizeof(buffer), sym);
- Fl::e_length = strlen(buffer);
- Fl::e_text = buffer;
-default: // prevent 'not handled in switch' warnings
- break;
+
+ if ([theEvent type] == NSKeyUp) {
+Fl::e_state &= 0xbfff; /
Re: [fltk.bugs] [MOD] STR #2599: expose dead keys to applications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2599 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2599 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 #2599: expose dead keys to applications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2599
Version: 1.3-feature
Attached file "fltk-1.3.x-dead-chars-win32.patch"...
Link: http://www.fltk.org/str.php?L2599
Version: 1.3-featurediff -up fltk-1.3.x-r8501/src/Fl_win32.cxx.dead-win32
fltk-1.3.x-r8501/src/Fl_win32.cxx
--- fltk-1.3.x-r8501/src/Fl_win32.cxx.dead-win322011-03-11
13:42:59.298646109 +0100
+++ fltk-1.3.x-r8501/src/Fl_win32.cxx 2011-03-11 16:02:49.452346270 +0100
@@ -777,6 +777,27 @@ static int ms2fltk(int vk, int extended)
return extended ? extendedlut[vk] : vklut[vk];
}
+static xchar msdead2fltk(xchar in)
+{
+ switch (in) {
+ case 0x0060: // GRAVE ACCENT
+return 0x0300; // COMBINING GRAVE ACCENT
+ case 0x00b4: // ACUTE ACCENT
+return 0x0301; // COMBINING ACUTE ACCENT
+ case 0x005e: // CIRCUMFLEX ACCENT
+return 0x0302; // COMBINING CIRCUMFLEX ACCENT
+ case 0x007e: // TILDE
+return 0x0303; // COMBINING TILDE
+ case 0x00a8: // DIAERESIS
+return 0x0308; // COMBINING DIAERESIS
+ // FIXME: Windows dead key behaviour isn't documented and I don't have
+ //any more keyboards to test with...
+ }
+
+ // hope that Windows gave us something proper to begin with
+ return in;
+}
+
#if USE_COLORMAP
extern HPALETTE fl_select_palette(void); // in fl_color_win32.cxx
#endif
@@ -838,6 +859,8 @@ static LRESULT CALLBACK WndProc(HWND hWn
//fl_msg.pt = ???
//fl_msg.lPrivate = ???
+ MSG fl_orig_msg = fl_msg;
+
Fl_Window *window = fl_find(hWnd);
if (window) switch (uMsg) {
@@ -1019,6 +1040,7 @@ static LRESULT CALLBACK WndProc(HWND hWn
if (GetKeyState(VK_SCROLL)) state |= FL_SCROLL_LOCK;
Fl::e_state = state;
static char buffer[1024];
+static char compose_buffer[1024];
if (uMsg == WM_CHAR || uMsg == WM_SYSCHAR) {
xchar u = (xchar) wParam;
@@ -1026,7 +1048,67 @@ static LRESULT CALLBACK WndProc(HWND hWn
Fl::e_length = fl_utf8fromwc(buffer, 1024, &u, 1);
buffer[Fl::e_length] = 0;
+ if (Fl::e_compose_state == FL_COMPOSE_INTERMEDIATE) {
+// if you enter an invalid compose sequence Windows will spit
+// out the entire thing in back-to-back messages
+while (PeekMessageW(&fl_msg, hWnd, WM_CHAR, WM_SYSDEADCHAR,
PM_REMOVE)) {
+ uMsg = fl_msg.message;
+ wParam = fl_msg.wParam;
+ lParam = fl_msg.lParam;
+
+ u = (xchar) wParam;
+ Fl::e_length += fl_utf8fromwc(&buffer[Fl::e_length],
1024-Fl::e_length, &u, 1);
+ buffer[Fl::e_length] = 0;
+
+ // update the compose symbol so that it will end up pointing at
+ // the last symbol in the sequence
+ u = msdead2fltk(u);
+ int length = fl_utf8fromwc(compose_buffer, 1024, &u, 1);
+ compose_buffer[length] = '\0';
+ Fl::e_compose_symbol = compose_buffer;
+ Fl::e_compose_state = FL_COMPOSE_FINAL;
+}
+
+if (Fl::e_compose_state != FL_COMPOSE_FINAL) {
+ MSG extra_msg;
+
+ // Windows doesn't expose the raw symbol (AFAIK), so we have to
+ // get a bit creative. Resend the last message to TranslateMessage()
+ // without all the inital dead characters, and we should get the
+ // raw symbol.
+ TranslateMessage(&fl_orig_msg);
+
+ if (PeekMessageW(&extra_msg, hWnd, WM_CHAR, WM_SYSDEADCHAR,
PM_REMOVE)) {
+u = (xchar) extra_msg.wParam;
+int length = fl_utf8fromwc(compose_buffer, 1024, &u, 1);
+compose_buffer[length] = '\0';
+
+Fl::e_compose_symbol = compose_buffer;
+Fl::e_compose_state = FL_COMPOSE_FINAL;
+ } else {
+// something went wrong, just provide the composed symbol
+Fl::e_compose_symbol = buffer;
+Fl::e_compose_state = FL_COMPOSE_FINAL;
+ }
+}
+ } else {
+Fl::e_compose_state = FL_COMPOSE_NONE;
+ }
+} else if (uMsg == WM_DEADCHAR || uMsg == WM_SYSDEADCHAR) {
+ xchar u = (xchar) wParam;
+ int length;
+
+ u = msdead2fltk(u);
+
+ length = fl_utf8fromwc(compose_buffer, 1024, &u, 1);
+ compose_buffer[length] = '\0';
+
+ Fl::e_compose_state = FL_COMPOSE_INTERMEDIATE;
+ Fl::e_compose_symbol = compose_buffer;
+
+ buffer[0] = '\0';
+ Fl::e_length = 0;
} else if (Fl::e_keysym >= FL_KP && Fl::e_keysym <= FL_KP_Last) {
if (state & FL_NUM_LOCK) {
// Convert to regular keypress...
@@ -1077,19 +1159,8 @@ static LRESULT CALLBACK WndProc(HWND hWn
}
}
} else if ((lParam & (1<<31))==0) {
-#ifdef FLTK_PREVIEW_DEAD_KEYS
- if ((lParam & (1<<24))==0) { // clear if dead key (always?)
-xchar u = (xchar) wParam;
-Fl::e_length = fl_utf8fromwc(buffer, 1024, &u, 1);
-buffer[Fl::e_length] = 0;
- } else { // set if "extended key" (never printable?)
-buff
Re: [fltk.bugs] [MOD] STR #2599: expose dead keys to applications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2599
Version: 1.3-feature
Attached file "fltk-1.3.x-dead-chars-x11.patch"...
Link: http://www.fltk.org/str.php?L2599
Version: 1.3-featurediff -up fltk-1.3.x-r8530/FL/Enumerations.H.dead-x11
fltk-1.3.x-r8530/FL/Enumerations.H
--- fltk-1.3.x-r8530/FL/Enumerations.H.dead-x11 2011-03-06 23:40:26.0
+0100
+++ fltk-1.3.x-r8530/FL/Enumerations.H 2011-03-31 13:19:29.485769283 +0200
@@ -425,6 +425,25 @@ enum Fl_When { // Fl_Widget::when():
/*@}*/ // group: Event States
+/** \name Compose States
+
+ These constants define the state of character composition for the
+ current keyboard event.
+
+ \sa Fl::event_compose_state(), Fl::event_compose_symbol()
+*/
+
+/*@{*/
+
+enum Fl_Compose {
+ FL_COMPOSE_UNKNOWN = 0, ///< current compose status cannot be determined
+ FL_COMPOSE_NONE, ///< no composition active for this event
+ FL_COMPOSE_INTERMEDIATE, ///< the current event is part of a composition
but does not end it
+ FL_COMPOSE_FINAL,///< a composed character has successfully been
construced
+};
+
+/*@}*/ // group: Compose States
+
/** \name Box Types
\brief FLTK standard box types
diff -up fltk-1.3.x-r8530/FL/Fl.H.dead-x11 fltk-1.3.x-r8530/FL/Fl.H
--- fltk-1.3.x-r8530/FL/Fl.H.dead-x11 2011-03-21 17:32:37.0 +0100
+++ fltk-1.3.x-r8530/FL/Fl.H2011-03-31 13:23:49.289973644 +0200
@@ -132,6 +132,8 @@ public: // should be private!
static int e_keysym;
static char* e_text;
static int e_length;
+ static int e_compose_state;
+ static const char* e_compose_symbol;
static Fl_Event_Dispatch e_dispatch;
static Fl_Widget* belowmouse_;
static Fl_Widget* pushed_;
@@ -677,6 +679,9 @@ public:
*/
static int event_length() {return e_length;}
+ static int event_compose_state();
+ static const char* event_compose_symbol();
+
static int compose(int &del);
static void compose_reset();
static int event_inside(int,int,int,int);
diff -up fltk-1.3.x-r8530/src/Fl_compose.cxx.dead-x11
fltk-1.3.x-r8530/src/Fl_compose.cxx
--- fltk-1.3.x-r8530/src/Fl_compose.cxx.dead-x112011-03-21
17:32:37.0 +0100
+++ fltk-1.3.x-r8530/src/Fl_compose.cxx 2011-03-31 13:25:08.733845974 +0200
@@ -31,6 +31,8 @@
#ifndef FL_DOXYGEN
// at present, this is effectively used by Mac OS X only
int Fl::compose_state = 0;
+int Fl::e_compose_state = FL_COMPOSE_UNKNOWN;
+const char* Fl::e_compose_symbol = "";
#endif
#if !defined(WIN32) && !defined(__APPLE__)
@@ -94,6 +96,31 @@ void Fl::compose_reset()
#endif
}
+/**
+ Returns what role the current key press plays in constructing a composed
+ character.
+ \see Fl_Compose
+ */
+int Fl::event_compose_state()
+{
+ return e_compose_state;
+}
+
+/**
+ Returns the raw symbol associated with the current event. This will be
+ the same as what Fl::event_text() returns except when the compose state
+ is FL_COMPOSE_INTERMEDIATE or FL_COMPOSE_FINAL.
+ \see Fl_Compose
+ */
+const char* Fl::event_compose_symbol()
+{
+ if ((e_compose_state == FL_COMPOSE_INTERMEDIATE) ||
+ (e_compose_state == FL_COMPOSE_FINAL))
+return e_compose_symbol;
+
+ return Fl::event_text();
+}
+
//
// End of "$Id: Fl_compose.cxx 8522 2011-03-21 16:32:37Z manolo $"
//
diff -up fltk-1.3.x-r8530/src/Fl_x.cxx.dead-x11 fltk-1.3.x-r8530/src/Fl_x.cxx
--- fltk-1.3.x-r8530/src/Fl_x.cxx.dead-x11 2011-02-26 15:14:50.0
+0100
+++ fltk-1.3.x-r8530/src/Fl_x.cxx 2011-03-31 13:19:29.487769431 +0200
@@ -920,9 +920,6 @@ int fl_handle(const XEvent& thisevent)
#endif
}
- if ( XFilterEvent((XEvent *)&xevent, 0) )
- return(1);
-
switch (xevent.type) {
case KeymapNotify:
@@ -1217,9 +1214,11 @@ int fl_handle(const XEvent& thisevent)
case KeyRelease: {
KEYPRESS:
int keycode = xevent.xkey.keycode;
+static int real_keycode;
fl_key_vector[keycode/8] |= (1 << (keycode%8));
static char *buffer = NULL;
static int buffer_len = 0;
+static char *compose_buffer = NULL;
int len;
KeySym keysym;
if (buffer_len == 0) {
@@ -1230,6 +1229,12 @@ int fl_handle(const XEvent& thisevent)
event = FL_KEYDOWN;
int len = 0;
+ // keycode 0 is a fake key, so looking that up is pointless,
+ // instead we rely on the fact that the preceding event was the
+ // real key
+ if (keycode != 0)
+real_keycode = keycode;
+
if (fl_xim_ic) {
Status status;
len = XUtf8LookupString(fl_xim_ic, (XKeyPressedEvent *)&xevent.xkey,
@@ -1241,7 +1246,111 @@ int fl_handle(const XEvent& thisevent)
len = XUtf8LookupString(fl_xim_ic, (XKeyPressedEvent *)&xevent.xkey,
buffer, buffer_len, &keysym, &status);
}
- keysym = XKeycodeToKeysym(fl_display, keycode, 0);
+
+// if this returns true, then Xlib has done some c
[fltk.bugs] [MOD] STR #2599: expose dead keys to applications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2599 Version: 1.3-feature Currently dead keys are pretty much hidden away from applications. For most, they don't care and this is just fine. Unfortunately I need to know when these keys are pressed for my application, and since FLTK controls the low level event handling, that means FLTK needs to be improved. I've composed a bunch of patches that fixes this for all three platforms. Existing applications should be unaffected, but applications that want information about dead keys get some new API functions that can examine the current state and what the current symbol is for each event. The patches also fixes some bugs in the same code. For X11 it returned a bogus key code for composed characters, and OS X generally had a bad connection between key presses and key events. These patches are fairly large given this somewhat obscure use case, but I still urge you to seriously consider them. The primary reason being that it's impossible for the application to do this without the help of FLTK, as FLTK controls the event loop. Link: http://www.fltk.org/str.php?L2599 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 #2587: Compose not properly reset with compose_reset() on X11
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2587 Version: 1.3-current That may be the case, but "most" is the key word here. If you look at the input handling in Fl_x.cxx you'll see that they are used even outside Xft specific code. So to reiterate, this code adds no new dependencies. Link: http://www.fltk.org/str.php?L2587 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2587: Compose not properly reset with compose_reset() on X11
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2587 Version: 1.3-current It most certainly is not behaving correctly. The documentation for compose_reset() only says "If the user moves the cursor, be sure to call Fl::compose_reset().". Unfortunately it doesn't say why, but I have to assume it is so that a compose started in one input box won't continue in another, or continue when you've clicked somewhere else in the same input field. This does not work! Pressing dead diaresis in one input field, moving to another and then pressing "o" will give you "ö". It should give you a plain "o". Compare FLTK with GTK and you'll see the difference. As for the whole extension thing, FLTK already assumes those extensions are in place as all the fancy X11 input handling uses the UTF-8 functions. Check the man page for Xutf8LookupString() and you'll see the same warning. Link: http://www.fltk.org/str.php?L2587 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2587: Compose not properly reset with compose_reset() on X11
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2587
Version: 1.3-current
The compose voodoo is done inside Xlib, so for compose_reset() to actually
do anything meaningful we need to tell Xlib to drop state. Fortunately
this is very simple. Attached patch does just that.
Note that this patch modifies the ABI and should therefore be applied
before final release.
Link: http://www.fltk.org/str.php?L2587
Version: 1.3-currentdiff -up fltk-1.3.x-r8501/FL/Fl.H.compose fltk-1.3.x-r8501/FL/Fl.H
--- fltk-1.3.x-r8501/FL/Fl.H.compose2011-03-10 16:43:36.908728039 +0100
+++ fltk-1.3.x-r8501/FL/Fl.H2011-03-10 16:45:48.357447792 +0100
@@ -678,13 +678,7 @@ public:
static int event_length() {return e_length;}
static int compose(int &del);
- /**
-If the user moves the cursor, be sure to call Fl::compose_reset().
-The next call to Fl::compose() will start out in an initial state. In
-particular it will not set "del" to non-zero. This call is very fast
-so it is ok to call it many times and in many places.
- */
- static void compose_reset() {compose_state = 0;}
+ static void compose_reset();
static int event_inside(int,int,int,int);
static int event_inside(const Fl_Widget*);
static int test_shortcut(Fl_Shortcut);
diff -up fltk-1.3.x-r8501/src/Fl_compose.cxx.compose
fltk-1.3.x-r8501/src/Fl_compose.cxx
--- fltk-1.3.x-r8501/src/Fl_compose.cxx.compose 2011-03-10 16:43:48.110556346
+0100
+++ fltk-1.3.x-r8501/src/Fl_compose.cxx 2011-03-10 16:55:22.401898007 +0100
@@ -33,6 +33,10 @@
int Fl::compose_state = 0;
#endif
+#if !defined(WIN32) && !defined(__APPLE__)
+extern XIC fl_xim_ic;
+#endif
+
/** Any text editing widget should call this for each FL_KEYBOARD event.
Use of this function is very simple.
@@ -76,6 +80,22 @@ int Fl::compose(int& del) {
return 1;
}
+/**
+ If the user moves the cursor, be sure to call Fl::compose_reset().
+ The next call to Fl::compose() will start out in an initial state. In
+ particular it will not set "del" to non-zero. This call is very fast
+ so it is ok to call it many times and in many places.
+ */
+void Fl::compose_reset()
+{
+ Fl::compose_state = 0;
+
+#if !defined(WIN32) && !defined(__APPLE__)
+ if (fl_xim_ic)
+Xutf8ResetIC(fl_xim_ic);
+#endif
+}
+
//
// End of "$Id: Fl_compose.cxx 8173 2011-01-03 16:50:34Z manolo $"
//
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2583: inconcistent alpha behaviour for fl_draw_image()
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2583 Version: 1.3-current I have one semi-related issue that you might want to consider whilst looking at this. If we get the option of different pixel formats, FLTK should be able to inform the application of the most efficient one. That way we can avoid having a pointless conversion stage when not needed. Right now for my application, it gets converted from BGRx to RGBx (what FLTK requires) and then back to BGRx (which the X server wants). One big massive waste of CPU cycles there. :) Link: http://www.fltk.org/str.php?L2583 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 #2583: inconcistent alpha behaviour for fl_draw_image()
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2583 Version: 1.3-current Do we have a consensus? Anyone implementing this? :) Link: http://www.fltk.org/str.php?L2583 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 #2583: inconcistent alpha behaviour for fl_draw_image()
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2583 Version: 1.3-current I agree with Manolo. FLTK is a platform abstraction layer. Therefore the most important thing should be consistent behaviour across platforms (to the extent possible). Removing the alpha support from Mac is a lot easier than adding it to the others, so it should be the preferred choice. There is also the fact that Fl_RGB_Image handles alpha, meaning that fl_draw_image() probably shouldn't so that you have the choice. If both mandate alpha then you have to add a lot of wasteful CPU cycles making sure your input data has 0xff in the fourth byte. I can verify that the patch solves the issue here. (Nitpick: kCGImageAlphaNone and kCGImageAlphaNoneSkipLast mean the same thing, so the test there could be removed. :)) Link: http://www.fltk.org/str.php?L2583 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 #2583: inconcistent alpha behaviour for fl_draw_image()
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2583 Version: 1.3-current It is random data, so I'd really like to have to option to disable alpha processing. It is evidently possible on all three platforms. Link: http://www.fltk.org/str.php?L2583 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #2583: inconcistent alpha behaviour for fl_draw_image()
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2583 Version: 1.3-current I've unfortunately hit the problem that fl_draw_image() on OS X behaves very different from X11 or Windows. On the latter two the data is assumed to be RGB (as documented) and the delta argument is just a memory layout issue. On OS X though, it is assumed that the data is RGBA if the delta is 4. This means that code that works fine on X11 and Windows breaks in fun and intersting ways on OS X. I suggest changing the OS X code so that it is always assumed that there is no alpha channel. This is how the other backends behave and is also how fl_draw_image() is documented. The only place that mentions alpha is Fl_RGB_Image, and that gives you consistent alpha behaviour for all backends. Link: http://www.fltk.org/str.php?L2583 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 #2581: crash on OS X with fl_draw() if no font set
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2581 Version: 1.3-current Crash does indeed not occur with current svn. Thanks. Link: http://www.fltk.org/str.php?L2581 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2581: crash on OS X with fl_draw() if no font set
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2581
Version: 1.3-current
If I call fl_draw() without setting a font, I get a crash because of a NULL
reference. It seems the code was meant to protect against this (given the
comments), but it is not working.
To be honest, I'm not sure how this ever worked. The routines set the
local pointer fl_fontsize. A macro is then called to see if this is NULL,
and call fl_font() if it is. But nowhere is fl_fontsize assigned a new
proper value after that call to fl_font().
I fixed this by redoing the macro at the top:
#define check_default_font() {if (!fl_fontsize) { fl_font(FL_HELVETICA,
FL_NORMAL_SIZE); fl_fontsize = fl_graphics_driver->font_descriptor(); } }
Link: http://www.fltk.org/str.php?L2581
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 #2580: OS X event loop breaks without any visible window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2580 Version: 1.3-current I agree that opening the display without any FLTK calls whatsoever might be dangerous. But that might be overkill. The issue here is that fd:s (and timers?) won't work without an open display. So the solution seems to me to be to open display when you call add_fd() or add_timeout(). This principle seems to hold for other things as fl_open_display() is called from stuff like Fl::get_mouse(). I tried doing this here and it solves the issue. Link: http://www.fltk.org/str.php?L2580 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 #2580: OS X event loop breaks without any visible window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2580 Version: 1.3-current I'll try to do something tomorrow (end of work day here now). I have discovered that the issue isn't visible windows, but that there has to be one created at one point. Putting the following at the start of the program fixes things: Fl_Window *wnd; wnd = new Fl_Window(100, 100); wnd->show(); wnd->hide(); Maybe a call to fl_open_display() is needed somewhere... Link: http://www.fltk.org/str.php?L2580 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #2580: OS X event loop breaks without any visible window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2580 Version: 1.3-current I'm having problems with the event loop on OS X. The same code works fine on Windows and Linux. The issue is that for a while the program has no open Windows, but instead waits for a file descriptor (registered using Fl::add_fd). On OS X it never signals that the fd is ready, but works fine on other platforms. After some digging, it seems that nextEventMatchingMask returns immediately when there are no windows visible. Hence it never gets a chance to see the event from the DataReady thread. I'm a complete noob when it comes to OS X programming, so I'm not sure what the problem here is. Apple's reference documentation doesn't mention anything about this method returning immediately. It does however mention that scenario for more high level run methods. In those cases it is because there are no "sources". I guess that might be the case here as the DataReady thing doesn't create any special objects; it only injects a special event when needed. I'm trying to understand things better here and try to create one of theses "sources", but any help you can provide is appreciated. Link: http://www.fltk.org/str.php?L2580 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2558: FL_NORMAL_SIZE isn't respected everywhere
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2558
Version: 1.3-current
Some time ago, FL_NORMAL_SIZE was changed from a normal constant into a
variable so that you could override the default font size (which you
_really_ want as the default is a bit large compared to other toolkits).
Unfortunately there were a few places that were overlooked. Prominently
the fl_ask stuff and the tooltips.
Attached patch fixes up those missing parts.
Because of the way Fl_Tooltip is implemented, this involves an ABI change.
So it would be nice if this could be fixed before 1.3.0 is released.
Link: http://www.fltk.org/str.php?L2558
Version: 1.3-currentdiff -up fltk-1.3.x-r8365/FL/Fl_Tooltip.H.orig fltk-1.3.x-r8365/FL/Fl_Tooltip.H
--- fltk-1.3.x-r8365/FL/Fl_Tooltip.H.orig 2011-02-08 17:17:36.569519069
+0100
+++ fltk-1.3.x-r8365/FL/Fl_Tooltip.H2011-02-08 17:17:40.790215898 +0100
@@ -72,7 +72,7 @@ public:
/**Sets the typeface for the tooltip text. */
static void font(Fl_Font i) { font_ = i; }
/**Gets the size of the tooltip text. */
- static Fl_Fontsize size() { return size_; }
+ static Fl_Fontsize size() { if (size_ == -1) return FL_NORMAL_SIZE; return
size_; }
/**Sets the size of the tooltip text. */
static void size(Fl_Fontsize s) { size_ = s; }
/** Gets the background color for tooltips. The default background color is
a pale yellow. */
diff -up fltk-1.3.x-r8365/src/fl_ask.cxx.orig fltk-1.3.x-r8365/src/fl_ask.cxx
--- fltk-1.3.x-r8365/src/fl_ask.cxx.orig2011-02-08 17:02:42.042811694
+0100
+++ fltk-1.3.x-r8365/src/fl_ask.cxx 2011-02-08 17:09:10.436946779 +0100
@@ -55,7 +55,7 @@ static Fl_Input *input;
static int ret_val;
static const char *iconlabel = "?";
Fl_Font fl_message_font_ = FL_HELVETICA;
-Fl_Fontsize fl_message_size_ = 14;
+Fl_Fontsize fl_message_size_ = -1;
#ifdef __APPLE__
extern "C" void NSBeep(void);
#endif
@@ -127,7 +127,7 @@ void resizeform() {
int x, w, h, max_w, max_h;
const int icon_size = 50;
- fl_font(fl_message_font_, fl_message_size_);
+ fl_font(message->labelfont(), message->labelsize());
message_w = message_h = 0;
fl_measure(message->label(), message_w, message_h);
@@ -211,7 +211,10 @@ static int innards(const char* fmt, va_l
}
message->labelfont(fl_message_font_);
- message->labelsize(fl_message_size_);
+ if (fl_message_size_ == -1)
+message->labelsize(FL_NORMAL_SIZE);
+ else
+message->labelsize(fl_message_size_);
if (b0) {button[0]->show(); button[0]->label(b0);
button[1]->position(210,70);}
else {button[0]->hide(); button[1]->position(310,70);}
if (b1) {button[1]->show(); button[1]->label(b1);}
diff -up fltk-1.3.x-r8365/src/Fl_File_Chooser2.cxx.orig
fltk-1.3.x-r8365/src/Fl_File_Chooser2.cxx
--- fltk-1.3.x-r8365/src/Fl_File_Chooser2.cxx.orig 2011-02-08
17:11:05.696980005 +0100
+++ fltk-1.3.x-r8365/src/Fl_File_Chooser2.cxx 2011-02-08 17:11:09.121545514
+0100
@@ -1410,7 +1410,7 @@ Fl_File_Chooser::update_preview()
// Show the first 1k of text...
int size = previewBox->h() / 20;
if (size < 6) size = 6;
- else if (size > 14) size = 14;
+ else if (size > FL_NORMAL_SIZE) size = FL_NORMAL_SIZE;
previewBox->label(preview_text_);
previewBox->align((Fl_Align)(FL_ALIGN_CLIP | FL_ALIGN_INSIDE |
diff -up fltk-1.3.x-r8365/src/fl_font_x.cxx.orig
fltk-1.3.x-r8365/src/fl_font_x.cxx
--- fltk-1.3.x-r8365/src/fl_font_x.cxx.orig 2011-02-08 17:13:13.214037502
+0100
+++ fltk-1.3.x-r8365/src/fl_font_x.cxx 2011-02-08 17:13:19.987155982 +0100
@@ -320,7 +320,7 @@ void fl_text_extents(const char *c, int
void Fl_Xlib_Graphics_Driver::draw(const char* c, int n, int x, int y) {
if (font_gc != fl_gc) {
-if (!current_font) fl_font(FL_HELVETICA, 14);
+if (!current_font) fl_font(FL_HELVETICA, FL_NORMAL_SIZE);
font_gc = fl_gc;
XSetFont(fl_display, fl_gc, current_font->fid);
}
diff -up fltk-1.3.x-r8365/src/fl_font_xft.cxx.orig
fltk-1.3.x-r8365/src/fl_font_xft.cxx
--- fltk-1.3.x-r8365/src/fl_font_xft.cxx.orig 2011-02-08 17:13:05.014683493
+0100
+++ fltk-1.3.x-r8365/src/fl_font_xft.cxx2011-02-08 17:13:06.734967573
+0100
@@ -588,7 +588,7 @@ void fl_destroy_xft_draw(Window id) {
void Fl_Xlib_Graphics_Driver::draw(const char *str, int n, int x, int y) {
if ( !current_font ) {
-fl_font(FL_HELVETICA, 14);
+fl_font(FL_HELVETICA, FL_NORMAL_SIZE);
}
#if USE_OVERLAY
XftDraw*& draw_ = fl_overlay ? draw_overlay : ::draw_;
diff -up fltk-1.3.x-r8365/src/Fl_Tooltip.cxx.orig
fltk-1.3.x-r8365/src/Fl_Tooltip.cxx
--- fltk-1.3.x-r8365/src/Fl_Tooltip.cxx.orig2011-02-08 17:18:03.193914697
+0100
+++ fltk-1.3.x-r8365/src/Fl_Tooltip.cxx 2011-02-08 17:18:24.696464727 +0100
@@ -39,7 +39,7 @@ Fl_Color Fl_Tooltip::color_ = fl_color_c
FL_NUM_BLUE - 2);
Fl_Color Fl_Tooltip:
[fltk.bugs] [MOD] STR #2557: gcc undefines min/max macros
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2557 Version: 1.3-current In fl_draw.cxx there is a macro for min(). Unfortunately this breaks with gcc on some platforms as it undefines min and max (since those macros will break C++ standard headers). The workaround is simply to move the macro definition until after you've included all of the headers. Observed with a Mac OS X 10.4 target with gcc 4.4.3. Link: http://www.fltk.org/str.php?L2557 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2556: bad include of ApplicationServices.h for Mac OS X
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2556 Version: 1.3-current In Fl_Gl_Choice.cxx: #include However, in at least the 10.4 SDK, it is called ApplicationServices.h (notice the lower case h). This causes problems when you are using a case sensitive file system (like here, where we cross compile from Linux). Link: http://www.fltk.org/str.php?L2556 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2555: configure looks for native ar, not target one (crosscompiling)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2555 Version: 1.3-current Since ar messes with symbols, you should use one that understands the target system. Hence configure.in should look for it using AC_PATH_TOOL, not AC_PATH_PROG. For libfltk.a we seem to run the proper ranlib right after, so it's probably not a practical issue right now. Still, it could be misused in the future so it's probably best to fix it at the source. Link: http://www.fltk.org/str.php?L2555 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 #2507: UTF-8 file name encoding handling in file chooser
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2507 Version: 1.3-current Updated patch as STR #2505 mentioned that there is a policy to avoid dynamic arrays. Link: http://www.fltk.org/str.php?L2507 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2507: UTF-8 file name encoding handling in file chooser
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2507
Version: 1.3-current
Attached file "fltk-1_v2.3.x-scandir-utf8.patch"...
Link: http://www.fltk.org/str.php?L2507
Version: 1.3-currentdiff -up ./src/filename_list.cxx.scandir ./src/filename_list.cxx
--- ./src/filename_list.cxx.scandir 2010-11-28 22:06:39.0 +0100
+++ ./src/filename_list.cxx 2011-01-05 09:54:14.500548587 +0100
@@ -28,6 +28,7 @@
// Wrapper for scandir with const-correct function prototypes.
#include
+#include
#include "flstring.h"
#include
@@ -37,7 +38,6 @@ extern "C" {
int fl_scandir (const char *dir, dirent ***namelist,
int (*select)(dirent *),
int (*compar)(dirent **, dirent **));
-# define scandir fl_scandir
#endif
}
@@ -81,54 +81,87 @@ int fl_casealphasort(struct dirent **a,
*/
int fl_filename_list(const char *d, dirent ***list,
Fl_File_Sort_F *sort) {
+#if defined(WIN32) && !defined(__CYGWIN__) && !defined(HAVE_SCANDIR)
+ // For Windows we have a special scandir implementation that uses
+ // the Win32 "wide" functions for lookup, avoiding the code page mess
+ // entirely. It also fixes up the trailing '/'.
+ return fl_scandir(d, list, 0, sort);
+
+#else // WIN32
+
+ int dirlen;
+ char *dirloc;
+
+ // Assume that locale encoding is no less dense than UTF-8
+ dirlen = strlen(d);
+ dirloc = (char *)malloc(dirlen + 1);
+
+ fl_utf8to_mb(d, dirlen, dirloc, dirlen + 1);
+
#ifndef HAVE_SCANDIR
- int n = scandir(d, list, 0, sort);
+ // This version is when we define our own scandir
+ int n = fl_scandir(dirloc, list, 0, sort);
#elif defined(HAVE_SCANDIR_POSIX) && !defined(__APPLE__)
// POSIX (2008) defines the comparison function like this:
- int n = scandir(d, list, 0, (int(*)(const dirent **, const dirent **))sort);
+ int n = scandir(dirloc, list, 0, (int(*)(const dirent **, const dirent
**))sort);
#elif defined(__osf__)
// OSF, DU 4.0x
- int n = scandir(d, list, 0, (int(*)(dirent **, dirent **))sort);
+ int n = scandir(dirloc, list, 0, (int(*)(dirent **, dirent **))sort);
#elif defined(_AIX)
// AIX is almost standard...
- int n = scandir(d, list, 0, (int(*)(void*, void*))sort);
-#elif !defined(__sgi)
+ int n = scandir(dirloc, list, 0, (int(*)(void*, void*))sort);
+#elif defined(__sgi)
+ int n = scandir(dirloc, list, 0, sort);
+#else
// The vast majority of UNIX systems want the sort function to have this
// prototype, most likely so that it can be passed to qsort without any
// changes:
- int n = scandir(d, list, 0, (int(*)(const void*,const void*))sort);
-#else
- // This version is when we define our own scandir (WIN32 and perhaps
- // some Unix systems) and apparently on IRIX:
- int n = scandir(d, list, 0, sort);
+ int n = scandir(dirloc, list, 0, (int(*)(const void*,const void*))sort);
#endif
-#if defined(WIN32) && !defined(__CYGWIN__)
- // we did this already during fl_scandir/win32
-#else
- // append a '/' to all filenames that are directories
- int i, dirlen = strlen(d);
+ free(dirloc);
+
+ // convert every filename to utf-8, and append a '/' to all
+ // filenames that are directories
+ int i;
char *fullname = (char*)malloc(dirlen+FL_PATH_MAX+3); // Add enough extra
for two /'s and a nul
// Use memcpy for speed since we already know the length of the string...
memcpy(fullname, d, dirlen+1);
+
char *name = fullname + dirlen;
- if (name!=fullname && name[-1]!='/') *name++ = '/';
+ if (name!=fullname && name[-1]!='/')
+*name++ = '/';
+
for (i=0; id_name);
-if (de->d_name[len-1]=='/' || len>FL_PATH_MAX) continue;
-// Use memcpy for speed since we already know the length of the string...
-memcpy(name, de->d_name, len+1);
-if (fl_filename_isdir(fullname)) {
- (*list)[i] = de = (dirent*)realloc(de, de->d_name - (char*)de + len + 2);
- char *dst = de->d_name + len;
- *dst++ = '/';
- *dst = 0;
+int newlen = fl_utf8from_mb(NULL, 0, de->d_name, len);
+dirent *newde = (dirent*)malloc(de->d_name - (char*)de + newlen + 2); //
Add space for a / and a nul
+
+// Conversion to UTF-8
+memcpy(newde, de, de->d_name - (char*)de);
+fl_utf8from_mb(newde->d_name, newlen + 1, de->d_name, len);
+
+// Check if dir (checks done on "old" name as we need to interact with
+// the underlying OS)
+if (de->d_name[len-1]!='/' && len<=FL_PATH_MAX) {
+ // Use memcpy for speed since we already know the length of the string...
+ memcpy(name, de->d_name, len+1);
+ if (fl_filename_isdir(fullname)) {
+char *dst = newde->d_name + newlen;
+*dst++ = '/';
+*dst = 0;
+ }
}
+
+free(de);
+(*list)[i] = newde;
}
free(fullname);
-#endif
+
return n;
+
+#endif // WIN32
}
//
diff -up ./src/fl_utf.c.scandir ./src/fl_utf.c
--- ./src/fl_utf.c.scandir 2010-11-28 22:06:39.0 +0100
+++ ./src/
Re: [fltk.bugs] [LOW] STR #2505: Xft backend doesn't filter bad UTF-8 characters
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current Updated patch that avoids dynamic arrays. I've used the same method as fl_utf8to_mb() that tries to use a statically allocated string first to avoid having to do two passes. Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2505: Xft backend doesn't filter bad UTF-8 characters
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2505
Version: 1.3-current
Attached file "fltk-1_v3.3.x-xft-check.patch"...
Link: http://www.fltk.org/str.php?L2505
Version: 1.3-currentdiff -up ./src/fl_font_xft.cxx.xft ./src/fl_font_xft.cxx
--- ./src/fl_font_xft.cxx.xft 2010-11-29 19:18:27.0 +0100
+++ ./src/fl_font_xft.cxx 2011-01-05 09:47:42.191472266 +0100
@@ -358,6 +358,33 @@ Fl_Font_Descriptor::~Fl_Font_Descriptor(
// XftFontClose(fl_display, font);
}
+static void utf8extents(const char *str, int n, XGlyphInfo *extents)
+{
+
+ wchar_t wstr_buf[1024];
+ wchar_t *wstr;
+ int count;
+
+ memset(extents, 0, sizeof(XGlyphInfo));
+
+ wstr = wstr_buf;
+ count = fl_utf8towc(str, n, wstr, 1024);
+ if (count >= 1024) {
+wstr = (wchar_t *)malloc((count + 1) * sizeof(wchar_t));
+count = fl_utf8towc(str, n, wstr, count + 1);
+ }
+
+ if (sizeof(wchar_t) == sizeof(FcChar32))
+XftTextExtents32(fl_display, current_font, (XftChar32 *)wstr, count,
extents);
+ else if (sizeof(wchar_t) == sizeof(FcChar16))
+XftTextExtents16(fl_display, current_font, (XftChar16 *)wstr, count,
extents);
+ else
+XftTextExtentsUtf8(fl_display, current_font, (XftChar8 *)str, n, extents);
+
+ if (wstr != wstr_buf)
+free(wstr);
+}
+
int fl_height() {
if (current_font) return current_font->ascent + current_font->descent;
else return -1;
@@ -371,7 +398,7 @@ int fl_descent() {
double fl_width(const char *str, int n) {
if (!current_font) return -1.0;
XGlyphInfo i;
- XftTextExtentsUtf8(fl_display, current_font, (XftChar8 *)str, n, &i);
+ utf8extents(str, n, &i);
return i.xOff;
}
@@ -397,7 +424,7 @@ void fl_text_extents(const char *c, int
return;
}
XGlyphInfo gi;
- XftTextExtentsUtf8(fl_display, current_font, (XftChar8 *)c, n, &gi);
+ utf8extents(c, n, &gi);
w = gi.width;
h = gi.height;
@@ -586,7 +613,26 @@ void Fl_Graphics_Driver::draw(const char
color.color.blue = ((int)b)*0x101;
color.color.alpha = 0x;
- XftDrawStringUtf8(draw_, &color, current_font, x, y, (XftChar8 *)str, n);
+ wchar_t wstr_buf[1024];
+ wchar_t *wstr;
+ int count;
+
+ wstr = wstr_buf;
+ count = fl_utf8towc(str, n, wstr, 1024);
+ if (count >= 1024) {
+wstr = (wchar_t *)malloc((count + 1) * sizeof(wchar_t));
+count = fl_utf8towc(str, n, wstr, count + 1);
+ }
+
+ if (sizeof(wchar_t) == sizeof(FcChar32))
+XftDrawString32(draw_, &color, current_font, x, y, (XftChar32 *)wstr,
count);
+ else if (sizeof(wchar_t) == sizeof(FcChar16))
+XftDrawString16(draw_, &color, current_font, x, y, (XftChar16 *)wstr,
count);
+ else
+XftDrawStringUtf8(draw_, &color, current_font, x, y, (XftChar8 *)str, n);
+
+ if (wstr != wstr_buf)
+free(wstr);
}
void Fl_Graphics_Driver::draw(int angle, const char *str, int n, int x, int y)
{
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2505: Xft backend doesn't filter bad UTF-8 characters
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current Quite right, the gist of it is that it converts the encoding to wchar_t to exploit the side effect of sanitizing the string. For the issues: 1. Dynamic arrays I'll have a look at this and post an updated patch. 2. sizeof() checks Yeah, I'm not particularly proud of this one. The basic problem is that wchar_t is not well defined when it comes to size, so there needed to be something. Preferably I'd have a preprocessor check, but I didn't have any defines to work with. Things can be improved by adding a check in configure for this. 3. Performance As you say, the performance hit is already there for Windows so as far as the project goes, it has been deemed acceptable. Improvements might be possible, but I suspect they're small. The conversion from UTF-8 to UCS-4 is a fairly simple one, and the extra cycles needed compared to only parsing and validating the UTF-8 string are probably negligable. The big performance hog will most likely be the malloc(). But let's not kid ourselves. This is C++, so there are stray malloc():s hidden all over the place when objects get flung around. So unless someone can show me numbers that this is causing any tangible slowdown, I'd consider this a case of premature optimization. :) Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2507: UTF-8 file name encoding handling in file chooser
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2507 Version: 1.3-current Mac OS X might be a UTF-8 platform? Most modern Unix systems probably are. I had to force my local Fedora here to be ISO 8859-1 to test this properly. Link: http://www.fltk.org/str.php?L2507 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2505: Xft backend doesn't filter bad UTF-8 characters
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current Updated patch that also handles text measurements properly. Rendering of stuff like selections got a bit funky otherwise. Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2505: Xft backend doesn't filter bad UTF-8 characters
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2505
Version: 1.3-current
Attached file "fltk-1_v2.3.x-xft-check.patch"...
Link: http://www.fltk.org/str.php?L2505
Version: 1.3-currentdiff -up ./src/fl_font_xft.cxx.xft ./src/fl_font_xft.cxx
--- ./src/fl_font_xft.cxx.xft 2010-11-29 19:18:27.0 +0100
+++ ./src/fl_font_xft.cxx 2011-01-04 15:04:01.847304494 +0100
@@ -358,6 +358,26 @@ Fl_Font_Descriptor::~Fl_Font_Descriptor(
// XftFontClose(fl_display, font);
}
+static void utf8extents(const char *str, int n, XGlyphInfo *extents)
+{
+
+ wchar_t wstr[n + 1];
+ int count;
+
+ memset(extents, 0, sizeof(XGlyphInfo));
+
+ count = fl_utf8towc(str, n, wstr, sizeof(wstr));
+ if (count > (int)sizeof(wstr))
+return;
+
+ if (sizeof(wchar_t) == sizeof(FcChar32))
+XftTextExtents32(fl_display, current_font, (XftChar32 *)wstr, count,
extents);
+ else if (sizeof(wchar_t) == sizeof(FcChar16))
+XftTextExtents16(fl_display, current_font, (XftChar16 *)wstr, count,
extents);
+ else
+XftTextExtentsUtf8(fl_display, current_font, (XftChar8 *)str, n, extents);
+}
+
int fl_height() {
if (current_font) return current_font->ascent + current_font->descent;
else return -1;
@@ -371,7 +391,7 @@ int fl_descent() {
double fl_width(const char *str, int n) {
if (!current_font) return -1.0;
XGlyphInfo i;
- XftTextExtentsUtf8(fl_display, current_font, (XftChar8 *)str, n, &i);
+ utf8extents(str, n, &i);
return i.xOff;
}
@@ -397,7 +417,7 @@ void fl_text_extents(const char *c, int
return;
}
XGlyphInfo gi;
- XftTextExtentsUtf8(fl_display, current_font, (XftChar8 *)c, n, &gi);
+ utf8extents(c, n, &gi);
w = gi.width;
h = gi.height;
@@ -586,7 +606,19 @@ void Fl_Graphics_Driver::draw(const char
color.color.blue = ((int)b)*0x101;
color.color.alpha = 0x;
- XftDrawStringUtf8(draw_, &color, current_font, x, y, (XftChar8 *)str, n);
+ wchar_t wstr[n + 1];
+ int count;
+
+ count = fl_utf8towc(str, n, wstr, sizeof(wstr));
+ if (count > (int)sizeof(wstr))
+return;
+
+ if (sizeof(wchar_t) == sizeof(FcChar32))
+XftDrawString32(draw_, &color, current_font, x, y, (XftChar32 *)wstr,
count);
+ else if (sizeof(wchar_t) == sizeof(FcChar16))
+XftDrawString16(draw_, &color, current_font, x, y, (XftChar16 *)wstr,
count);
+ else
+XftDrawStringUtf8(draw_, &color, current_font, x, y, (XftChar8 *)str, n);
}
void Fl_Graphics_Driver::draw(int angle, const char *str, int n, int x, int y)
{
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2507: UTF-8 file name encoding handling in file chooser
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2507
Version: 1.3-current
File name encodings are a bit of a pain as there is no clear right way.
What other toolkits do is to assume the file names are encoded according
to locale. FLTK assumes that they are always in UTF-8 though.
On Windows, this handling is already in place (although some of the heavy
lifting is done by Windows itself). The interface there is that FLTK
always expects UTF-8 encoded file names, and does all the necessary voodoo
to interface with Windows.
The attached patch fixes this issue for the other platforms as well. This
makes the FLTK interface consistent in that FLTK always expects UTF-8 file
names, not just on one of the platforms. It also means that the file
chooser shows files the same way that e.g. GTK+ does.
The patch basically fixes three things:
1. fl_utf8to_mb()/fl_utf8from_mb() has a stupid behaviour where it behaves
different on utf-8 systems and can segfault if the caller doesn't check
this first.
2. The non-win32 fl_scandir() had a useless call to fl_utf2mbcs() (which
does nothing on the platforms used here).
3. Shuffles around fl_filename_list() a bit and gives it a consistent
UTF-8 interface.
Link: http://www.fltk.org/str.php?L2507
Version: 1.3-currentdiff -up ./src/filename_list.cxx.scandir ./src/filename_list.cxx
--- ./src/filename_list.cxx.scandir 2010-11-28 22:06:39.0 +0100
+++ ./src/filename_list.cxx 2011-01-04 13:35:59.006471987 +0100
@@ -28,6 +28,7 @@
// Wrapper for scandir with const-correct function prototypes.
#include
+#include
#include "flstring.h"
#include
@@ -37,7 +38,6 @@ extern "C" {
int fl_scandir (const char *dir, dirent ***namelist,
int (*select)(dirent *),
int (*compar)(dirent **, dirent **));
-# define scandir fl_scandir
#endif
}
@@ -81,54 +81,82 @@ int fl_casealphasort(struct dirent **a,
*/
int fl_filename_list(const char *d, dirent ***list,
Fl_File_Sort_F *sort) {
+#if defined(WIN32) && !defined(__CYGWIN__) && !defined(HAVE_SCANDIR)
+ // For Windows we have a special scandir implementation that uses
+ // the Win32 "wide" functions for lookup, avoiding the code page mess
+ // entirely. It also fixes up the trailing '/'.
+ return fl_scandir(d, list, 0, sort);
+
+#else // WIN32
+
+ // Assume that locale encoding is no less dense than UTF-8
+ int dirlen = strlen(d);
+ char dirloc[dirlen + 1];
+
+ fl_utf8to_mb(d, dirlen, dirloc, sizeof(dirloc));
+
#ifndef HAVE_SCANDIR
- int n = scandir(d, list, 0, sort);
+ // This version is when we define our own scandir
+ int n = fl_scandir(dirloc, list, 0, sort);
#elif defined(HAVE_SCANDIR_POSIX) && !defined(__APPLE__)
// POSIX (2008) defines the comparison function like this:
- int n = scandir(d, list, 0, (int(*)(const dirent **, const dirent **))sort);
+ int n = scandir(dirloc, list, 0, (int(*)(const dirent **, const dirent
**))sort);
#elif defined(__osf__)
// OSF, DU 4.0x
- int n = scandir(d, list, 0, (int(*)(dirent **, dirent **))sort);
+ int n = scandir(dirloc, list, 0, (int(*)(dirent **, dirent **))sort);
#elif defined(_AIX)
// AIX is almost standard...
- int n = scandir(d, list, 0, (int(*)(void*, void*))sort);
-#elif !defined(__sgi)
+ int n = scandir(dirloc, list, 0, (int(*)(void*, void*))sort);
+#elif defined(__sgi)
+ int n = scandir(dirloc, list, 0, sort);
+#else
// The vast majority of UNIX systems want the sort function to have this
// prototype, most likely so that it can be passed to qsort without any
// changes:
- int n = scandir(d, list, 0, (int(*)(const void*,const void*))sort);
-#else
- // This version is when we define our own scandir (WIN32 and perhaps
- // some Unix systems) and apparently on IRIX:
- int n = scandir(d, list, 0, sort);
+ int n = scandir(dirloc, list, 0, (int(*)(const void*,const void*))sort);
#endif
-#if defined(WIN32) && !defined(__CYGWIN__)
- // we did this already during fl_scandir/win32
-#else
- // append a '/' to all filenames that are directories
- int i, dirlen = strlen(d);
+ // convert every filename to utf-8, and append a '/' to all
+ // filenames that are directories
+ int i;
char *fullname = (char*)malloc(dirlen+FL_PATH_MAX+3); // Add enough extra
for two /'s and a nul
// Use memcpy for speed since we already know the length of the string...
memcpy(fullname, d, dirlen+1);
+
char *name = fullname + dirlen;
- if (name!=fullname && name[-1]!='/') *name++ = '/';
+ if (name!=fullname && name[-1]!='/')
+*name++ = '/';
+
for (i=0; id_name);
-if (de->d_name[len-1]=='/' || len>FL_PATH_MAX) continue;
-// Use memcpy for speed since we already know the length of the string...
-memcpy(name, de->d_name, len+1);
-if (fl_filename_isdir(fullname)) {
- (*list)[i] = de = (dirent*)realloc(de, de->d_name - (char*)de + len + 2);
- char *dst = de->d_name
Re: [fltk.bugs] [LOW] STR #2505: Xft backend doesn't filter bad UTF-8 characters
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current To be honest, I haven't checked the [already existing] code that validates the UTF-8 string. I just noticed it seems to do a good job at catching junk. I would assume that incorrect lengths is the most likely way errors are spotted though. Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2505: Xft backend doesn't filter bad UTF-8 characters
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current Aside from the matter of plain ol' bugs, the text displayed in widgets might come from external sources like databases, network communication or read from files in one of the gazilion ways that doesn't have idiot proof encoding handling. There is also the problematic case of file names where there is always a fair amount of ambiguity when it comes to encoding. The simple fact is that UTF-8 has the possibility of being malformed. Allowing the toolkit to handle that and visibly present the presence of bad characters would be an improvement in my book. There is also the matter of consistent behaviour across FLTK platforms. Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2505: Xft backend doesn't filter bad UTF-8 characters
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2505
Version: 1.3-current
The Windows backend handles bad UTF-8 sequences by either replacing them
with the replacement character, or guesses that they are ISO
8859-1/CP1252. No such handling is done in the Xft backend though. It
would be nice if this is done for the features above, and for consistency
across platforms if nothing else.
The attached patch changes this by doing a UTF-8 to UCS-2/UCS-4
conversion, which has the side effect of filtering the string.
Link: http://www.fltk.org/str.php?L2505
Version: 1.3-currentdiff -up ./src/fl_font_xft.cxx.xft ./src/fl_font_xft.cxx
--- ./src/fl_font_xft.cxx.xft 2010-11-29 19:18:27.0 +0100
+++ ./src/fl_font_xft.cxx 2011-01-03 11:52:18.017946001 +0100
@@ -586,7 +586,19 @@ void Fl_Graphics_Driver::draw(const char
color.color.blue = ((int)b)*0x101;
color.color.alpha = 0x;
- XftDrawStringUtf8(draw_, &color, current_font, x, y, (XftChar8 *)str, n);
+ wchar_t wstr[n + 1];
+ int count;
+
+ count = fl_utf8towc(str, n, wstr, sizeof(wstr));
+ if (count > sizeof(wstr))
+return;
+
+ if (sizeof(wchar_t) == sizeof(FcChar32))
+XftDrawString32(draw_, &color, current_font, x, y, (XftChar32 *)wstr,
count);
+ else if (sizeof(wchar_t) == sizeof(FcChar16))
+XftDrawString16(draw_, &color, current_font, x, y, (XftChar16 *)wstr,
count);
+ else
+XftDrawStringUtf8(draw_, &color, current_font, x, y, (XftChar8 *)str, n);
}
void Fl_Graphics_Driver::draw(int angle, const char *str, int n, int x, int y)
{
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2470: Lack of Xutf8TextPropertyToTextList on non-XFree86 X implementations
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2470 Version: 1.3-current Similar to STR #438, the new FLTK 1.3 code relies on XFree86 specific extensions to Xlib. This causes problems compiling it on e.g. Solaris. Link: http://www.fltk.org/str.php?L2470 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
