Re: [fltk.bugs] [HIGH] STR #2944: Mac OS X Fl_Gl_Window bugs - all FLTK versions
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2944 Version: 1.3.2 OK; fixes applied to fltk 1.3.x svn current for these: Item #1: fixed in r9865 -- Apple specific overlay emulation issue with swapbuffer + gl rasterpos Item #2: fixed in r9866 -- Apple specific nested gl window issue Haven't gotten to investigating Item #3 yet. Link: http://www.fltk.org/str.php?L2944 Version: 1.3.2 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2939: Fl_Tabs not honoring when(FL_WHEN_NOT_CHANGED)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2939 Version: 1.3.2 Fix Version: 1.3-current (r9867) Fixed in Subversion repository. Leaving this open to allow for comments before closing. Link: http://www.fltk.org/str.php?L2939 Version: 1.3.2 Fix Version: 1.3-current (r9867) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.commit] [Library] r9865 - branches/branch-1.3/src
Author: greg.ercolano
Date: 2013-04-08 09:49:55 -0700 (Mon, 08 Apr 2013)
New Revision: 9865
Log:
Fix STR# 2944 [1]: When an app uses overlays and gl_draw(),
gl_draw() would mess up the raster position
affecting the Mac overlay emulation in swapbuffer code.
Modified:
branches/branch-1.3/src/Fl_Gl_Window.cxx
Modified: branches/branch-1.3/src/Fl_Gl_Window.cxx
===
--- branches/branch-1.3/src/Fl_Gl_Window.cxx2013-04-06 16:35:05 UTC (rev
9864)
+++ branches/branch-1.3/src/Fl_Gl_Window.cxx2013-04-08 16:49:55 UTC (rev
9865)
@@ -249,10 +249,34 @@
# endif
#elif defined(__APPLE_QUARTZ__)
if(overlay != NULL) {
-//aglSwapBuffers does not work well with overlays under cocoa
-glReadBuffer(GL_BACK);
-glDrawBuffer(GL_FRONT);
-glCopyPixels(0,0,w(),h(),GL_COLOR);
+// STR# 2944 [1]
+//Save matrixmode/proj/modelview/rasterpos before doing overlay.
+//
+int wo=w(), ho=h();
+GLint matrixmode;
+GLfloat pos[4];
+glGetIntegerv(GL_MATRIX_MODE, matrixmode);
+glGetFloatv(GL_CURRENT_RASTER_POSITION, pos); // save original
glRasterPos
+glMatrixMode(GL_PROJECTION); // save proj/model
matrices
+glPushMatrix();
+ glLoadIdentity();
+ glMatrixMode(GL_MODELVIEW);
+ glPushMatrix();
+glLoadIdentity();
+glScalef(2.0f/wo, 2.0f/ho, 1.0f);
+glTranslatef(-wo/2.0f, -ho/2.0f, 0.0f); // set transform so
0,0 is bottom/left of Gl_Window
+glRasterPos2i(0,0); // set glRasterPos to
bottom left corner
+{
+ // Emulate overlay by doing copypixels
+ glReadBuffer(GL_BACK);
+ glDrawBuffer(GL_FRONT);
+ glCopyPixels(0, 0, wo, ho, GL_COLOR); // copy GL_BACK to
GL_FRONT
+}
+glPopMatrix(); // GL_MODELVIEW // restore model/proj
matrices
+ glMatrixMode(GL_PROJECTION);
+ glPopMatrix();
+glMatrixMode(matrixmode);
+glRasterPos3f(pos[0], pos[1], pos[2]); // restore original
glRasterPos
}
else
aglSwapBuffers((AGLContext)context_);
___
fltk-commit mailing list
fltk-commit@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-commit
[fltk.commit] [Library] r9866 - in branches/branch-1.3: FL src
Author: greg.ercolano
Date: 2013-04-08 11:24:17 -0700 (Mon, 08 Apr 2013)
New Revision: 9866
Log:
Fix for STR #2944 [2]: Fix Apple-specifc nested window problem for
Fl_Gl_Window's.
Added new method Fl_Widget::window_offset(x,y)
to access the top-level window offset of the current
widget.
Open to alternative names for the new method.
Modified:
branches/branch-1.3/FL/Fl_Window.H
branches/branch-1.3/src/Fl_Gl_Window.cxx
branches/branch-1.3/src/Fl_Window.cxx
Modified: branches/branch-1.3/FL/Fl_Window.H
===
--- branches/branch-1.3/FL/Fl_Window.H 2013-04-08 16:49:55 UTC (rev 9865)
+++ branches/branch-1.3/FL/Fl_Window.H 2013-04-08 18:24:17 UTC (rev 9866)
@@ -120,6 +120,7 @@
\see force_position(int)
*/
int force_position() const { return ((flags() FORCE_POSITION)?1:0); }
+ Fl_Window* window_offset(int xoff, int yoff) const;
public:
Modified: branches/branch-1.3/src/Fl_Gl_Window.cxx
===
--- branches/branch-1.3/src/Fl_Gl_Window.cxx2013-04-08 16:49:55 UTC (rev
9865)
+++ branches/branch-1.3/src/Fl_Gl_Window.cxx2013-04-08 18:24:17 UTC (rev
9866)
@@ -183,8 +183,10 @@
GLint xywh[4];
if (window()) {
-xywh[0] = x();
-xywh[1] = window()-h() - y() - h();
+int xoff,yoff;
+const Fl_Window *win = window_offset(xoff, yoff); // STR #2944 [2]
+xywh[0] = xoff;
+xywh[1] = win-h() - yoff - h();
} else {
xywh[0] = 0;
xywh[1] = 0;
Modified: branches/branch-1.3/src/Fl_Window.cxx
===
--- branches/branch-1.3/src/Fl_Window.cxx 2013-04-08 16:49:55 UTC (rev
9865)
+++ branches/branch-1.3/src/Fl_Window.cxx 2013-04-08 18:24:17 UTC (rev
9866)
@@ -278,6 +278,21 @@
icon_ = ic;
}
+/**
+ Finds the x/y offset of the current window relative to the top-level window.
+ \param[out] xoff,yoff Returns the x/y offset
+ \returns the top-level window
+*/
+Fl_Window* Fl_Window::window_offset(int xoff, int yoff) const {
+ xoff = yoff = 0;
+ const Fl_Window *win = (const Fl_Window*)this;
+ while (win win-window()) {
+xoff += win-x(); // accumulate offsets
+yoff += win-y();
+win = win-window(); // walk up window hierarchy
+ }
+ return (Fl_Window*)win;
+}
//
// End of $Id$.
___
fltk-commit mailing list
fltk-commit@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-commit
[fltk.commit] [Library] r9867 - in branches/branch-1.3: FL src
Author: greg.ercolano
Date: 2013-04-08 13:18:40 -0700 (Mon, 08 Apr 2013)
New Revision: 9867
Log:
Solves STR #2939; adding when() support to Fl_Tabs.
Also added a general Fl_Tabs code example to the docs.
Modified:
branches/branch-1.3/FL/Fl_Tabs.H
branches/branch-1.3/src/Fl_Tabs.cxx
Modified: branches/branch-1.3/FL/Fl_Tabs.H
===
--- branches/branch-1.3/FL/Fl_Tabs.H2013-04-08 18:24:17 UTC (rev 9866)
+++ branches/branch-1.3/FL/Fl_Tabs.H2013-04-08 20:18:40 UTC (rev 9867)
@@ -49,6 +49,49 @@
gap is larger. It is easiest to lay this out in fluid, using the
fluid browser to select each child group and resize them until
the tabs look the way you want them to.
+
+ Typical use:
+ \code
+ Fl_Tabs *tabs = new Fl_Tabs(10,10,300,200);
+ {
+ Fl_Group *tab1 = new Fl_Group(20,30,280,170,Tab1);
+ {
+ ..widgets that go in tab#1..
+ }
+ tab1-end();
+ Fl_Group *tab2 = new Fl_Group(20,30,280,170,Tab2);
+ {
+ ..widgets that go in tab#2..
+ }
+ tab2-end();
+ }
+ tabs-end();
+ \endcode
+
+ In the above, tab1's tab can be made red by using
tab1-selection_color(FL_RED);
+ and tab1's text can be made bold by tab1-labelfont(FL_HELVETICA_BOLD),
+ and can be made 'engraved' by tab1-labeltype(FL_ENGRAVED_LABEL);
+
+ As of FLTK 1.3.3, Fl_Tabs() supports the following flags for when():
+
+- \ref FL_WHEN_NEVER -- callback never invoked (all flags off)
+- \ref FL_WHEN_CHANGED -- if flag set, invokes callback when a tab has
been changed (on click or keyboard navigation)
+- \ref FL_WHEN_NOT_CHANGED -- if flag set, invokes callback when the tabs
remain unchanged (on click or keyboard navigation)
+- \ref FL_WHEN_RELEASE -- if flag set, invokes callback on RELEASE of
mouse button or keyboard navigation
+
+ Notes:
+
+-# The above flags can be logically OR-ed (|) or added (+) to combine
behaviors.
+-# The default value for when() is \ref FL_WHEN_RELEASE (inherited from
Fl_Widget).
+-# If \ref FL_WHEN_RELEASE is the \em only flag specified,
+the behavior will be as if (\ref FL_WHEN_RELEASE|\ref FL_WHEN_CHANGED)
was specified.
+-# The value of changed() will be valid during the callback.
+-# If both \ref FL_WHEN_CHANGED and \ref FL_WHEN_NOT_CHANGED are
specified,
+the callback is invoked whether the tab has been changed or not.
+ The changed() method can be used to determine the cause.
+-# \ref FL_WHEN_NOT_CHANGED can happen if someone clicks on an already
selected tab,
+or if a keyboard navigation attempt results in no change to the tabs,
+ such as using the arrow keys while at the left or right end of the tabs.
*/
class FL_EXPORT Fl_Tabs : public Fl_Group {
Fl_Widget *value_;
Modified: branches/branch-1.3/src/Fl_Tabs.cxx
===
--- branches/branch-1.3/src/Fl_Tabs.cxx 2013-04-08 18:24:17 UTC (rev 9866)
+++ branches/branch-1.3/src/Fl_Tabs.cxx 2013-04-08 20:18:40 UTC (rev 9867)
@@ -170,25 +170,59 @@
}}
/* FALLTHROUGH */
case FL_DRAG:
- case FL_RELEASE:
-o = which(Fl::event_x(), Fl::event_y());
+ case FL_RELEASE: {
+// PUSH, DRAG, RELEASE..
+int do_cb=0;
+if ((o = which(Fl::event_x(), Fl::event_y( { // get tab group for
tab user is over
+ if (o != value()) set_changed(); // if over tab, handle change
+ else clear_changed();
+}
if (event == FL_RELEASE) {
- push(0);
- if (o Fl::visible_focus() Fl::focus()!=this) {
-Fl::focus(this);
-redraw_tabs();
+ push(0); // no longer 'pushed'
+ // Over a tab?
+ if (o) {
+ // Handle taking keyboard focus w/visible focus indication
+ if (Fl::visible_focus() Fl::focus()!=this) {
+ Fl::focus(this);
+ redraw_tabs();
+ }
+ if (value(o)) { // commit to value, see if it
changed..
+ set_changed();// it changed
+ do_cb =
+ ( (when() FL_WHEN_RELEASE) // wants cb on RELEASE
and..
+ (when() FL_WHEN_CHANGED)// when changed?
+ ) || ( // ..or..
+ (when() == FL_WHEN_RELEASE) // *only* WHEN_RELEASE
specified? (default behavior)
+ ) ? 1 : 0;
+ } else {
+ clear_changed(); // no change
+ do_cb = (when() FL_WHEN_RELEASE // wants cb when RELEASE and..
+ when() FL_WHEN_NOT_CHANGED)?1:0; // ..when no change
occurred?
+ }
}
- if (o value(o)) {
-Fl_Widget_Tracker wp(o);
-set_changed();
- do_callback();
- if (wp.deleted()) return 1;
- }
Re: [fltk.development] [RFE] STR #2942: Buttons keep the same color when clicked
[STR Closed w/o Resolution] Link: http://www.fltk.org/str.php?L2942 Version: 1.3-feature Fix Version: 1.3-current No, sorry. We won't set anything (e.g. selection_color) w/o the user explicitly requesting it. This would also break apps that have the colors set as-is. The usual default is to use the selection_color(), and this is taken from a system color. As I wrote before, the setting you proposed would also be sub-optimal for other FLTK schemes. I'm closing this STR now. Link: http://www.fltk.org/str.php?L2942 Version: 1.3-feature Fix Version: 1.3-current ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: method to find top level window?
On 06.04.2013 07:55, Greg Ercolano wrote:
Is there a method that returns the top-level window manager window
for the current widget?
window() is not it; this just returns the parent window
which won't be the top-level window when there are
windows within windows, eg:
Fl_Window *top = new Fl_Window(..);
top-begin();
Fl_Window *sub = new Fl_Window(..);
sub-begin();
:
It seems unlikely we don't have such a thing, but I think
supporting nested windows is something recent, and I see
places in our code that do inline loops instead of calling a method.
If there isn't such a method, would like to suggest we add one,
the code being something like:
---
Fl_Window *Fl_Widget::toplevel_window() const {
Fl_Window *top = window();
while (top top-window()) top = top-window();
return top;
}
---
Comments?
ISTR that we discussed adding such a method a while ago, and that
it probably wasn't done for some reasons. However, thinking about
it, I don't know what this might have been. Too simple ? What, if
the top-level window still has a (non-window) parent widget? Does
it matter ? I don't know.
Anyway, since it's not much code, could we probably add it to the
header file as an inline method ? I think so. If there were a vote
request, my vote would be +1, unless there are reasons not to do
it that I don't know of (yet). Other opinions, votes?
BTW: toplevel_window() doesn't look bad, but what about top_window().
Less typing ;-)
Albrecht
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: method to find top level window?
On 04/08/13 15:32, Albrecht Schlosser wrote: On 06.04.2013 07:55, Greg Ercolano wrote: BTW: toplevel_window() doesn't look bad, but what about top_window(). Less typing ;-) Yes, what I based 'toplevel_window()' on was that in our code, the term 'top-level' is used fairly consistently to refer to the real window in a widget hierarchy. This, as opposed to 'top' as perhaps meaning the window on top of all others in window depth (along the Z axis) I have no real preference otherwise. BTW, on a similar new method train of thought; had to add a method to Fl_Widget called window_offset() which returns the x/y offset of the current widget relative to the top-level window (top window? ;) to fix STR #2944 (r9866). Again, I'm indifferent on naming; perhaps there's a better name for what this method should be called. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] FLTK-1.3 group button menus in wrong place whe rearranged
marty moore remoor...@yahoo.com wrote: I've been playing around with this because I want to create a set of buttons that change to indicate where the user is in the program, instead of using a status bar. Maybe a little odd, but sounded interesting. I'd appreciate any ideas. You could always set up a series of different panes in Fl_Wizard where each pane has a status label and the set of buttons that are relevant in the current program context, and switch between panes as part of a button callback. D. This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK-1.3 group button menus in wrong place whe rearranged
On 08.04.2013 01:27, marty moore wrote:
What happens:
1. When the first button is clicked, and the delete option is selected, the
other buttons disappear, but the menu is where the clicked button used to be,
not where the button is actually located.
2. If the add option is selected from the popped up menu, the menu is
located on top of the new button.
3. Continue selecting add, and the all of the menus appear over the first
added button.
4. If escape is pressed, or the button is clicked again to cancel the menu,
the buttons and menus seem to act properly again.
So it appears that when a previous button in the group is removed, the
button's menu position doesn't get updated.
Is there any way to update the menu position, other than manually with
popup(x,y) or pulldown(x,y,w,h)
Your problem lies buried in Fl_Pack. This is not designed to be
updated dynamically the way you try to do it, or at least this
doesn't work as expected. The reason why this is so is because
Fl_Pack rearranges its children only when it is draw(), but this
doesn't happen when you might expect it to do.
In your code, this part is called in a callback:
else if ( op == DEL )
{
cout onMenu 2: deleting endl;
int i = G1-find(w);
clearTo(i);
WIN-redraw();
Here you ask the window to be drawn, but this doesn't happen
until the event loop is reached again, either by returning
from the callback or ... (see below).
cout onMenu 3: poping menu endl;
sb = (Sbut*)G1-child(0);
sb-popup();
Here the menu pops up, but Fl_Pack still knows of the old
button position(s), hence the unexpected position. But this
popup() call also includes running the event loop again, until
the menu will be closed. Now you will see the new button
position(s), but the menu stays at the old position.
There are two ways to overcome this:
(1) I recommend not to use Fl_Pack, but instead calculate the
new button positions yourself (use a class derived from Fl_Group),
and everything ought to work as expected if you calculate the
positions before calling popup(). Note that calling init_sizes()
has nothing to do with Fl_Pack's and/or Fl_Groups position
calculations, unless you resize() the group or window. Hence it
would be useful to call init_sizes() after re-positioning the
buttons in the group.
(2) I don't recommend this one, but it should give you a clue
whether I'm right with my assumption. ;-) Instead of calling
popup() in the callback, as you did above, start a timer with
a short time, say 0.3 seconds, and popup() the menu in this
timer callback. If you did this, then the window's draw() would
happen before the timer callback runs, and therefore Fl_Pack's
draw() method would have adjusted the positions already. Although
this might look as the easier part, I don't consider this good
style, and if you extend your program later, Fl_Pack will maybe
not be the widget/group you want to use because of its restricted
features.
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK-1.3 group button menus in wrong place whe rearranged
Oh! I was mid-reply, and I see Albrecht has already said most of what I was
going to say...
So it appears that when a previous button in the group is removed, the
button's menu position doesn't get updated.
As Albrecht said, the way Fl_Pack behaves in practice is probably not what you
want for your use case.
I have to confess I don't much care for Fl_Pack in general; every time I tried
to use it, I ended up in difficulties.
Albrecht suggests deriving your own container from Fl_Group - this is probably
the best bet; looks like more work initially but in practice it will be easier
as it gives you so much more control over the way your widgets are positioned,
sized and redrawn...
Albrecht also suggests a workaround based on timers. I think this might work
out pretty well, though I'd consider having my own derived Fl_Pack (or similar
container widget) that, in its derived draw() method, sets a flag to tell
whether the draw has actually been enacted (and hence the sizes properly
recalculated) and have that flag cleared down by the callback that triggers the
timer.
The timer can then poll until it sees that the widget has been drawn (the
flag is re-set) and thence that the sizes ought to be correct, for popping up
the menus now...
Well, something like that...
Also, some entirely spurious critique of the example code, for no other reason
than I was part way through rewriting it anyway...
static Fl_Font LFONT = FL_BOLD;
Would be better to say:
static Fl_Font LFONT = FL_HELVETICA | FL_BOLD;
Which is actually the same thing, but makes it explicit: It is (kinda) just
chance that FL_BOLD on its own works (since FL_HELV... == 0). Really it is
meant as a modifier, not a name in its own right!
class Sbut : public Fl_Menu_Button
{
public:
Sbut (int i);
~Sbut ();
static void onButton ( Fl_Widget* w, void* v);
int handle ( int event );
int i() { return _i; }
int _i;
/// char* _cstr; // not really needed
};
//cc
Sbut::Sbut (int id )
: Fl_Menu_Button( 0, 0, 100, 50)
{
//cout Sbut(s) 0: id endl;
_i = idx;
callback(onButton);
//_cstr = new char[sizeof(int)]; // not needed, and maybe too small
anyway?
char _cstr[16]; // use a stack automatic temp instead, cheaper than
calling new
sprintf(_cstr, %i, id);
// label(_cstr);
copy_label(_cstr); // use copy_label so the widget manages the label
string for you
//cc
Sbut::~Sbut ()
{
// delete _cstr;
}
//***
int main (int argc, char **argv)
{
WIN-end();
//WIN-resizable(G1);
// With a pack, it may be that...
WIN-resizable(WIN); // might work out better...
// Passing argc, argv to show() ensures that fltk picks up
// the system default settings... Useful on some host systems.
WIN-show(argc, argv);
return Fl::run();
}
Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England Wales. Company no. 02426132
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK-1.3 group button menus in wrong place whe rearranged
On 08.04.2013 11:58, Albrecht Schlosser wrote: There are two ways to overcome this: .. at least .. (1) I recommend not to use Fl_Pack, ... (2) I don't recommend this one, but it should give you a clue ... (3) You might also recalculate the button positions in your callbacks/functions to modify the group, i.e. clearto() and/or onMenu(), but you would have to do it in the same way as Fl_Pack would do it later in its draw() method. This way, you'd have the popup() work depending on the new positions, as you expect. The point why I don't recommend this either is because you'd have to *know* how Fl_Pack calculates the positions. However, this is not trivial, but could work with your simple buttons. But if you do this anyway, why not create an own group class? You could also overwrite the resize() method and rearrange your buttons while the window/group is being resized. Then you would be able to call resize() after you rearranged the group's buttons, and that's it. I like this more than recalculating positions in draw(), because (a) it's less overhead, and (b) you avoid the problems you see in your program. So I still recommend (1). Here's a small amendment to my previous posting. I wrote: Here the menu pops up, but Fl_Pack still knows of the old button position(s), hence the unexpected position. In fact, Fl_Pack is not involved here. It's the button widget that still knows its old position, because Fl_Pack didn't rearrange the children yet. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK-1.3 group button menus in wrong placewhe rearranged
Ian, I agree with you 100%, but want to add one comment. On 08.04.2013 12:28, MacArthur, Ian (Selex ES, UK) wrote: Albrecht also suggests a workaround based on timers. I think this might work out pretty well, though I'd consider having my own derived Fl_Pack (or similar container widget) that, in its derived draw() method, sets a flag to tell whether the draw has actually been enacted (and hence the sizes properly recalculated) and have that flag cleared down by the callback that triggers the timer. The timer can then poll until it sees that the widget has been drawn (the flag is re-set) and thence that the sizes ought to be correct, for popping up the menus now... Well, something like that... Yep, this was suggested as a workaround only, either to see how it can be done (just for learning), or if one really wants to use Fl_Pack. Deriving from Fl_Pack (as I assume you meant above) for another container widget and do the polling makes things even worse, but I assume that you only wrote it for the same reasons as I did. My personal opinion is that users should NOT try to resize widgets in their draw methods, since this will lead to problems earlier or later. The problems with Fl_Pack result just from the fact that it tries to allow its children to resize in their respective draw() methods, and hence it *must* recalculate positions after calling the children's draw() methods - thus the only way to do it is in its own draw() method. My suggestion in my other posting about resizing/rearranging children in resize() seems to be much better for user code, and I'm using it in my apps successfully. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK-1.3 group button menus in wrong placewherearranged
Yep, this was suggested as a workaround only, either to see how it
can be done (just for learning), or if one really wants to use
Fl_Pack. Deriving from Fl_Pack (as I assume you meant above) for
another container widget and do the polling makes things even worse,
but I assume that you only wrote it for the same reasons as I did.
Yes, indeed.
I think the better thing is to make your own container based on Fl_Group, since
that gives more control over how the packed widgets will finally be drawn
anyway...
Also, more or less as an aside, I think your (Albrecht's) analysis of how
Fl_Pack is causing this issue is correct - since I was already poking at
marty's code, I tweaked it to use a timer as you had suggested (only for the
purposes of experiment of course!) and the code now works as expecetd...
--
// marty - button add example
#include iostream
#include string
#include cstdio
#include cstdlib
#include FL/Fl.H
#include FL/Fl_Box.H
#include FL/Fl_Menu_Button.H
#include FL/Fl_Menu_Item.H
#include FL/Fl_Pack.H
#include FL/Fl_Window.H
using std::cout;
using std::endl;
using std::string;
static Fl_Pack* G1;
static Fl_Window* WIN;
static int idx = 0;
static Fl_Color LBG = FL_DARK_BLUE;
static Fl_Color LFG = FL_WHITE;
static Fl_Color LSC = FL_BLUE;;
static Fl_Color LTC = FL_WHITE;
static Fl_Font LFONT = (FL_HELVETICA | FL_BOLD);
static Fl_Fontsize FSIZE = 20;
static int LSPC = 5;
enum eop { DEL=-1, ADD=1 };
class Sbut : public Fl_Menu_Button
{
public:
Sbut (int i);
static void onButton ( Fl_Widget* w, void* v);
int handle ( int event );
int i() { return _i; }
int _i;
};
//
void clearTo ( int idx )
{
cout clearto idx : ;
Fl_Widget* w;
int last = G1-children()-1;
if ( last idx )
cout removing ;
{
// remove last to idx
for ( int i=last; i-1; i-- )
{
if ( i != idx )
{
cout i ;
w = G1-child(i);
G1-remove(w);
delete w;
}
}
}
WIN-redraw();
cout endl;
}
//
static void pop_on_timeout(void *v)
{
Sbut* sb = (Sbut*)v;
WIN-redraw();
cout pop_on_timeout: popping menu endl;
sb-popup();
}
//
void onMenu (Fl_Widget* w, void* v)
{
eop op = (eop)fl_intptr_t(v);
Sbut* sb;
if ( op == ADD )
{
cout onMenu: add endl;
sb = new Sbut(idx);
G1-add(sb);
idx++;
Fl::add_timeout(0.2, pop_on_timeout, (void*)sb);
}
else if ( op == DEL )
{
cout onMenu 2: deleting endl;
int i = G1-find(w);
clearTo(i);
sb = (Sbut*)G1-child(0);
Fl::add_timeout(0.2, pop_on_timeout, (void*)sb);
}
}
//m
Fl_Menu_Item xMenu[] = {
{add button to end, and popup menu, 0, onMenu, (void*)ADD},
{delete other buttons, and popup menu, 0, onMenu, (void*)DEL},
{0}
};
//cc
Sbut::Sbut (int id )
: Fl_Menu_Button( 0, 0, 100, 50)
{
//cout Sbut(s) 0: id endl;
_i = idx;
callback(onButton);
char _cstr[16];
sprintf(_cstr, %i, id);
copy_label(_cstr);
//cout label = label() endl;
color( LBG, LSC);
labelcolor(LFG);
labelfont(LFONT);
labelsize(FSIZE);
menu(xMenu);
if ( menu() )
{
Fl_Menu_Item* mi; // non-const pointer
mi = (Fl_Menu_Item*)menu();
int sz = mi-size();
for ( int j=0; jsz; j++ )
{
// cout set: j endl;
color(LBG, LSC);
mi-labelsize(FSIZE);
mi-labelfont(LFONT);
mi-labelcolor(LFG);
mi = mi-next();
}
}
}
//hH
int Sbut::handle ( int event )
{
if ( event == FL_PUSH )
{
cout Sbut handle 1: PUSH endl;
do_callback();
return 1;
}
return 0;
}
//hH
void Sbut::onButton ( Fl_Widget* w, void* v)
{
int i = G1-find(w);
cout Sbut onButton 0: i endl;
Sbut* sb = (Sbut*)w;
sb-popup();
}
//***
int main (int argc, char **argv)
{
Sbut* sb;
WIN = new Fl_Window(0, 0, 200, 300);
G1 = new Fl_Pack(0, 0, 150, 150);
G1-begin();
for ( int i=0; i5; i++ )
{
sb = new Sbut(i);
idx++;
}
G1-end();
WIN-end();
//WIN-resizable(G1);
WIN-resizable(WIN);
WIN-show(argc, argv);
return Fl::run();
}
/* end of file */
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK-1.3 group button menus in wrong placewherearranged
Hi,
Thank you very much for explaining the problem fully. I really appreciate that
you took the time to analyze it, make suggestions, and even play with my code.
You have really impressed me with the quality of help available on the fltk
forum.
Thanks again,
Marty
Yep, this was suggested as a workaround only, either to see how it
can be done (just for learning), or if one really wants to use
Fl_Pack. Deriving from Fl_Pack (as I assume you meant above) for
another container widget and do the polling makes things even worse,
but I assume that you only wrote it for the same reasons as I did.
Yes, indeed.
I think the better thing is to make your own container based on Fl_Group,
since that gives more control over how the packed widgets will finally be
drawn anyway...
Also, more or less as an aside, I think your (Albrecht's) analysis of how
Fl_Pack is causing this issue is correct - since I was already poking at
marty's code, I tweaked it to use a timer as you had suggested (only for the
purposes of experiment of course!) and the code now works as expecetd...
--
// marty - button add example
#include iostream
#include string
#include cstdio
#include cstdlib
#include FL/Fl.H
#include FL/Fl_Box.H
#include FL/Fl_Menu_Button.H
#include FL/Fl_Menu_Item.H
#include FL/Fl_Pack.H
#include FL/Fl_Window.H
using std::cout;
using std::endl;
using std::string;
static Fl_Pack* G1;
static Fl_Window* WIN;
static int idx = 0;
static Fl_Color LBG = FL_DARK_BLUE;
static Fl_Color LFG = FL_WHITE;
static Fl_Color LSC = FL_BLUE;;
static Fl_Color LTC = FL_WHITE;
static Fl_Font LFONT = (FL_HELVETICA | FL_BOLD);
static Fl_Fontsize FSIZE = 20;
static int LSPC = 5;
enum eop { DEL=-1, ADD=1 };
class Sbut : public Fl_Menu_Button
{
public:
Sbut (int i);
static void onButton ( Fl_Widget* w, void* v);
int handle ( int event );
int i() { return _i; }
int _i;
};
//
void clearTo ( int idx )
{
cout clearto idx : ;
Fl_Widget* w;
int last = G1-children()-1;
if ( last idx )
cout removing ;
{
// remove last to idx
for ( int i=last; i-1; i-- )
{
if ( i != idx )
{
cout i ;
w = G1-child(i);
G1-remove(w);
delete w;
}
}
}
WIN-redraw();
cout endl;
}
//
static void pop_on_timeout(void *v)
{
Sbut* sb = (Sbut*)v;
WIN-redraw();
cout pop_on_timeout: popping menu endl;
sb-popup();
}
//
void onMenu (Fl_Widget* w, void* v)
{
eop op = (eop)fl_intptr_t(v);
Sbut* sb;
if ( op == ADD )
{
cout onMenu: add endl;
sb = new Sbut(idx);
G1-add(sb);
idx++;
Fl::add_timeout(0.2, pop_on_timeout, (void*)sb);
}
else if ( op == DEL )
{
cout onMenu 2: deleting endl;
int i = G1-find(w);
clearTo(i);
sb = (Sbut*)G1-child(0);
Fl::add_timeout(0.2, pop_on_timeout, (void*)sb);
}
}
//m
Fl_Menu_Item xMenu[] = {
{add button to end, and popup menu, 0, onMenu, (void*)ADD},
{delete other buttons, and popup menu, 0, onMenu, (void*)DEL},
{0}
};
//cc
Sbut::Sbut (int id )
: Fl_Menu_Button( 0, 0, 100, 50)
{
//cout Sbut(s) 0: id endl;
_i = idx;
callback(onButton);
char _cstr[16];
sprintf(_cstr, %i, id);
copy_label(_cstr);
//cout label = label() endl;
color( LBG, LSC);
labelcolor(LFG);
labelfont(LFONT);
labelsize(FSIZE);
menu(xMenu);
if ( menu() )
{
Fl_Menu_Item* mi; // non-const pointer
mi = (Fl_Menu_Item*)menu();
int sz = mi-size();
for ( int j=0; jsz; j++ )
{
// cout set: j endl;
color(LBG, LSC);
mi-labelsize(FSIZE);
mi-labelfont(LFONT);
mi-labelcolor(LFG);
mi = mi-next();
}
}
}
//hH
int Sbut::handle ( int event )
{
if ( event == FL_PUSH )
{
cout Sbut handle 1: PUSH endl;
do_callback();
return 1;
}
return 0;
}
//hH
void Sbut::onButton ( Fl_Widget* w, void* v)
{
int i = G1-find(w);
cout Sbut onButton 0: i endl;
Sbut* sb = (Sbut*)w;
sb-popup();
}
//***
int main (int argc, char **argv)
{
Sbut* sb;
WIN = new Fl_Window(0, 0, 200, 300);
G1 = new Fl_Pack(0, 0, 150, 150);
G1-begin();
for ( int i=0; i5; i++ )
{
sb = new Sbut(i);
idx++;
}
G1-end();
WIN-end();
//WIN-resizable(G1);
WIN-resizable(WIN);
WIN-show(argc, argv);
return Fl::run();
}
/* end
Re: [fltk.general] FLTK-1.3 group button menus in wrong placewherearranged
//hH
int Sbut::handle ( int event )
{
if ( event == FL_PUSH )
{
cout Sbut handle 1: PUSH endl;
do_callback();
return 1;
}
return 0;
}
Also, unrelated, the above bit of code should be repaired.
As it is, the button's own handle() method is being completely eclipsed.
Fl_Button::handle(event); should really be called in there somewhere
to allow the button's mechanics to operate.
If the purpose of this handle() is just to print a message on PUSH,
then:
int Sbut::handle ( int event )
{
if ( event == FL_PUSH )
cout Sbut handle 1: PUSH endl;
return(Fl_Button::handle(event);
}
..and the button's own code will handle the do_callback() on PUSH.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Caps Lock detection
On Fri, 05 Apr 2013 23:39:28 -0700, Greg Ercolano wrote:
an fltk timer would probably be needed to get the correct
state info shown reliably.
Thanks for the replies.
No luck with an fltk timer, on Ubuntu Linux 10.04. Test program below.
In the console we can see that (Fl::event_state() FL_CAPS_LOCK)
correctly changes to nonzero as soon as you press Caps Lock.
But it doesn't change back to 0 when you press Caps Lock again
until e.g. you move the mouse over the window.
Howard Rubin
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Output.H
#include iostream
void TimerProc(void* p) {
Fl_Output* pOutput = static_castFl_Output*(p);
if (Fl::event_state() FL_CAPS_LOCK) {
pOutput-show();
std::cerr 1;
} else {
pOutput-hide();
std::cerr 0;
}
pOutput-damage(~0); pOutput-redraw(); Fl::check(); Fl::wait(.1);
Fl::repeat_timeout(0.25, TimerProc, p);
}
int main(int argc, char* argv[]) {
Fl_Window* win = new Fl_Window(300, 200, );
Fl_Output* pOutput = new Fl_Output(120, 50, 0, 15, Caps Lock);
win-end();
win-show();
Fl::add_timeout(0.25, TimerProc, pOutput);
return Fl::run();
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 04/08/13 10:35, Howard Rubin wrote:
On Fri, 05 Apr 2013 23:39:28 -0700, Greg Ercolano wrote:
an fltk timer would probably be needed to get the correct
state info shown reliably.
Thanks for the replies.
No luck with an fltk timer, on Ubuntu Linux 10.04. Test program below.
In the console we can see that (Fl::event_state() FL_CAPS_LOCK)
correctly changes to nonzero as soon as you press Caps Lock.
But it doesn't change back to 0 when you press Caps Lock again
until e.g. you move the mouse over the window.
I'm not sure if this is a bug in X11 or not.. kinda seems so.
X11's own KeyRelease events seem to behave similarly;
in my tests with the pure X11 code below, when X11 sends
a KeyRelease event for the capslock key, the event.xkey.state
shows accurate info when capslock is ENABLED, but INACCURATE INFO
when capslock is disabled.
You have to hit some other key to get the accurate state of
capslock after lock release.
So I think FLTK is simply passing this X11 behavior on to the app.
Not really sure if FLTK can fix this if X11 gives similar info.
My X11's a bit rusty, but there might be a way to acquire the realtime
capslock state by a different X library call -- if there is, you should
probably #ifdef that into your code.
#include stdio.h
#include stdlib.h
#include string.h
#include X11/Xlib.h
#include X11/Xutil.h
//
// Slightly modified X windows hello world
//
// ref: http://www.cuillin.demon.co.uk/nazz/trivia/hw/hw_c.html
// compile: g++ hello.c -o hello -lXtst -lX11 -lXext
//
int main(int argc, char *argv[])
{
Display*dpy;/* X server connection */
Window win;/* Window ID */
GC gc; /* GC to draw with */
XFontStruct *fontstruct;/* Font descriptor */
XGCValues gcv;/* Struct for creating GC */
XEvent event; /* Event received */
XSetWindowAttributes xswa; /* Temporary Set Window Attribute struct */
// OPEN DISPLAY
if ((dpy = XOpenDisplay(NULL)) == NULL) {
fprintf(stderr, %s: can't open %s\n, argv[0], XDisplayName(NULL));
exit(1);
}
// CREATE 500x500 WINDOW
win = XCreateSimpleWindow(dpy, DefaultRootWindow(dpy),
50,50,500,500,// x,y,w,h
0,// border width
0,0); // border color, bg color
XSelectInput(dpy, win, ExposureMask|KeyPressMask|KeyReleaseMask);
// MAP WINDOW
XMapWindow(dpy, win);
// EVENT LOOP
while (1) {
XNextEvent(dpy, event);
switch ( event.type ) {
case Expose:
fprintf(stderr, * Expose event\n);
if ( event.xexpose.count == 0) {
while (XCheckTypedEvent(dpy, Expose, event));
// GET CURRENT WINDOW SIZE (FOR TEXT CENTERING)
XWindowAttributes xwa;
if (XGetWindowAttributes(dpy, win, xwa) == 0)
break;
XClearWindow(dpy, win);
}
break;
case KeyPress:
case KeyRelease: {
const char *ename = (event.type==KeyPress) ? Press :
Release;
printf(%s keycode=0X%04x, state=0X%04x\n, ename,
event.xkey.keycode, event.xkey.state);
break;
}
default:
fprintf(stderr, * Ignored event '%d'\n, (int)event.type);
break;
}
}
return(1);
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
