Re: [fltk.bugs] [MOD] STR #2915: Mac OS: subwindow is not shown correctly after hide() and then show()
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2915 Version: 1.3.2 Fix Version: 1.3-current (r9788) Closed after confirmation from the OP. Link: http://www.fltk.org/str.php?L2915 Version: 1.3.2 Fix Version: 1.3-current (r9788) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.commit] [Library] r9792 - in branches/branch-1.3: FL src
Author: manolo
Date: 2013-01-13 07:25:37 -0800 (Sun, 13 Jan 2013)
New Revision: 9792
Log:
Mac OS: added support for the text input feature introduced in OS 10.7 Lion
where pressing and holding
some key opens a window with possible accented characters. This feature is used
by the Fl_Input_ and
Fl_Text_Editor widgets. User-defined text input widgets can optionally use this
feature, but the default
behavior is to not use it. Fl_Secret_Input turns it off, for example.
Modified:
branches/branch-1.3/FL/Fl.H
branches/branch-1.3/FL/Fl_Widget.H
branches/branch-1.3/FL/mac.H
branches/branch-1.3/src/Fl_Input.cxx
branches/branch-1.3/src/Fl_Input_.cxx
branches/branch-1.3/src/Fl_Text_Display.cxx
branches/branch-1.3/src/Fl_Text_Editor.cxx
branches/branch-1.3/src/Fl_cocoa.mm
branches/branch-1.3/src/Fl_compose.cxx
Modified: branches/branch-1.3/FL/Fl.H
===
--- branches/branch-1.3/FL/Fl.H 2013-01-10 09:17:58 UTC (rev 9791)
+++ branches/branch-1.3/FL/Fl.H 2013-01-13 15:25:37 UTC (rev 9792)
@@ -147,7 +147,7 @@
#ifdef __APPLE__
static int marked_text_length(void); // returns length of marked text
static void reset_marked_text(); // resets marked text
- static void insertion_point_location(int x, int y); // sets window
coordinates of insertion point
+ static void insertion_point_location(int x, int y, int height); // sets
window coordinates height of insertion point
#endif
#endif
/**
Modified: branches/branch-1.3/FL/Fl_Widget.H
===
--- branches/branch-1.3/FL/Fl_Widget.H 2013-01-10 09:17:58 UTC (rev 9791)
+++ branches/branch-1.3/FL/Fl_Widget.H 2013-01-13 15:25:37 UTC (rev 9792)
@@ -171,6 +171,7 @@
GROUP_RELATIVE = 116, /// position this widget relative to the
parent group, not to the window
COPIED_TOOLTIP = 117, /// the widget tooltip is internally
copied, its destruction is handled by the widget
FULLSCREEN = 118, /// a fullscreen window (Fl_Window)
+MAC_USE_ACCENTS_MENU = 119, /// On the Mac OS platform, pressing
and holding a key on the keyboard opens an accented-character menu window
(Fl_Input_, Fl_Text_Editor)
// (space for more flags)
USERFLAG3 = 129, /// reserved for 3rd party extensions
USERFLAG2 = 130, /// reserved for 3rd party extensions
@@ -976,6 +977,10 @@
*/
virtual class Fl_Gl_Window* as_gl_window() {return 0;}
+ /** Returns non zero if MAC_USE_ACCENTS_MENU flag is set, 0 otherwise.
+ */
+ int use_accents_menu() { return flags() MAC_USE_ACCENTS_MENU; }
+
/** For back compatibility only.
\deprecated Use selection_color() instead.
*/
Modified: branches/branch-1.3/FL/mac.H
===
--- branches/branch-1.3/FL/mac.H2013-01-10 09:17:58 UTC (rev 9791)
+++ branches/branch-1.3/FL/mac.H2013-01-13 15:25:37 UTC (rev 9792)
@@ -132,7 +132,7 @@
static void *get_carbon_function(const char *name);
static void screen_work_area(int X, int Y, int W, int H, int n); //
compute work area of a given screen
static int next_marked_length; // next length of marked text after current
marked text will have been replaced
- static int insertion_point_location(int *px, int *py); // computes window
coordinates of insertion point
+ static int insertion_point_location(int *px, int *py, int *pheight); //
computes window coordinates height of insertion point
private:
static void relink(Fl_Window*, Fl_Window*);
bool subwindow;
Modified: branches/branch-1.3/src/Fl_Input.cxx
===
--- branches/branch-1.3/src/Fl_Input.cxx2013-01-10 09:17:58 UTC (rev
9791)
+++ branches/branch-1.3/src/Fl_Input.cxx2013-01-13 15:25:37 UTC (rev
9792)
@@ -780,12 +780,14 @@
: Fl_Input(X,Y,W,H,l)
{
type(FL_FLOAT_INPUT);
+ clear_flag(MAC_USE_ACCENTS_MENU);
}
Fl_Int_Input::Fl_Int_Input(int X,int Y,int W,int H,const char *l)
: Fl_Input(X,Y,W,H,l) {
type(FL_INT_INPUT);
+ clear_flag(MAC_USE_ACCENTS_MENU);
}
@@ -810,6 +812,7 @@
Fl_Secret_Input::Fl_Secret_Input(int X,int Y,int W,int H,const char *l)
: Fl_Input(X,Y,W,H,l) {
type(FL_SECRET_INPUT);
+ clear_flag(MAC_USE_ACCENTS_MENU);
}
int Fl_Secret_Input::handle(int event) {
Modified: branches/branch-1.3/src/Fl_Input_.cxx
===
--- branches/branch-1.3/src/Fl_Input_.cxx 2013-01-10 09:17:58 UTC (rev
9791)
+++ branches/branch-1.3/src/Fl_Input_.cxx 2013-01-13 15:25:37 UTC (rev
9792)
@@ -388,6 +388,9 @@
} else {
fl_rectf((int)(xpos+curx+0.5), Y+ypos, 2, height);
}
+#ifdef __APPLE__
+ Fl::insertion_point_location(xpos+curx, Y+ypos+height, height);
+#endif
}
CONTINUE:
@@ -1119,6 +1122,7 @@
maximum_size_ = 32767;
shortcut_
Re: [fltk.general] Event-Handling
On 12 Jan 2013, at 17:10, Christian Hufnagel wrote: To be sure: If I want to react on special events, I can't do that with = the normal widgets, I must derive a own class? Yes, that's the normal way, just derive your own widget and add the = extra features you need. But it is cheap and easy to do - it is C++ after all... As I said before, it is worth taking a look at the samples in the test = folder, to see how it is done.=20 And, going off at a tangent: Note also that fluid can work with your = derived widgets - you create the widget in fluid by dripping in an = instance of the base class from which you derived, then in the C++ tab = of the widget properties you simply enter the name of your derived = widget, and all *should* be well! Also (though your English seems fine to me) if you really feel you are = struggling, it is probably OK to post in German any questions you are = having difficulty phrasing - since at least Matthias and Albrecht will = understand (even if I don't) ! It has been only a theoretical question which has been fully answered. The tip to see at the examples was good, thank you. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Manage focus with Suggestions popup/win/menu
On 12 Jan 2013, at 03:17, Denton Thomas wrote: Using Fl_Window (Fl_Double_Window) + set_non_modal() is definitely easier, and does not hog input. Thanks for mentioning that, Ian. New problem, though. Test code is below. Regardless of what group/win type I use, mouse input will pass through the popup to the window/widgets below. This acts like an insertion-order thing. So, widget is drawn z-top, but it is z-below for input. I can fix the input order by making sure the other widget additions occur before the suggestion box. In my project, though, I can't control/guarantee the insertion order of the widget into the parent group ... so I'm a bit stumped. Ideas? I'll keep reading docs/threads ... (Without studying the sample code in all that much detail..) my initial reaction is that the creation of the Fl_Window based SuggestionBox widget as a member of your SuggestionInput widget, is causing it to be created as a sub-window of the main window, rather than a window in its own right and this is messing with the behaviour of the other widgets. If you can put the SuggestionBox browser in a pop-up window, rather than putting the pop-up windows inside the SuggestionBox, things might be simpler and make it easier to control the ordering of windows / events / etc...? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] OpenGL + widgets
Is there a recommended approach to drawing FLTK widgets inside or on top of an OpenGL window? I see a few ways to approach this. The simplest way to get quick results seems to be to subclass widgets to provide OpenGL draw() methods and write an OpenGL window draw method that draws its children. A more general but also more complex approach would be write an OpenGL output driver (has anyone else written such a thing already?), or somehow draw widgets to an image which is then drawn in OpenGL (could an existing driver easily be modified to do this?). Are there other options, or anything in particular to watch out for when doing one of these? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OpenGL + widgets
On 13 Jan 2013, at 20:59, Christopher James Huff wrote: Is there a recommended approach to drawing FLTK widgets inside or on top of an OpenGL window? Not as such... I see a few ways to approach this. The simplest way to get quick results seems to be to subclass widgets to provide OpenGL draw() methods and write an OpenGL window draw method that draws its children. And indeed Matthias has a demo doing exactly that, erm... somewhere... I can't find the link right now. This was code he put up years ago, but AFAIK it ought to still work fine with fltk-1.3. A more general but also more complex approach would be write an OpenGL output driver (has anyone else written such a thing already?), Which would be the preferred way, at least with fltk-1.3, if anyone could ever get around to writing the code... With fltk-1.3, the driver layer was abstracted away, with the specific intent of making it easier to implement alternate low-level code; obviously the initial intent was to make it easier to have the X11/WinXX/Cocoa and printing layers work, but the idea was always to make a GL layer (and others, e.g. framebuffer, whatever,) possible. But so far no one has had the time... A volunteer, they say, is worth 10 pressed men... (that's a hint, by the way, just in case you have a little time to throw at this - we'd appreciate it!) or somehow draw widgets to an image which is then drawn in OpenGL (could an existing driver easily be modified to do this?). Are there other options, or anything in particular to watch out for when doing one of these? This is also feasible, you'd use the existing drawing mechanisms to render to an off-screen buffer, then pass that buffer to the GL context for display, I guess. Note that *some* platforms (I think OSX for sure and maybe, IIRC, X11 in fltk2) use essentially this technique to render font faces in GL contexts, by drawing the glyphs (or in the OSX case entire strings) into a buffer then passing that to GL for rendering into the scene. But I think an actual GL driver layer would work better... Though handling of fonts might always be problematic - drawing TT fonts in Windows GL is actually easier. MS did do some useful things after all! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
