Now I'm working on themes and plugins. Also getting a chance to give the
new fluid a bit of a workout. OUTSTANDING!! Love the tree view and key
handling. The edit fields in the tabbed editor (it's apparently not a
quote-
unquote panel???... still learning the ropes) are great. Again, the key
handling
is great.
The mod for the button clicks seems to have helped a lot, by the way.
See a previous note I sent on this subject...
It's in the X related stuff near the word "push". The lengths of the
two timeouts are reversed and the 200 millisecond timeout should start
out at 400 ms and perhaps be customizable. Or scan the message base
for the text "interpreting" in my messages. The exact code fix is in
that message if you want it.
I'm even starting to like the fact that these thing resize by default
until you toggle
[\,] Resizable
once, but this is apparently a side effect rather than a deliberate
design feature??
Also I understand the difficulty of stacking the windows correctly but
I intend to work on that myself a bit later.
One more note. Changing the window class on the fly in fluid...
wonderful. No more editing with a text editor? :-)
Now... back to the grind.
-----------
ask.h doesn't have a related cxx file.
It's implementation is in message.cxx. One or the other should be
changed. I'll probably change the cxx name so that the headers
still work. That is message.cxx will become an empty file with a
note in it about being renamed ask.cxx. I know this conflicts with
a test named ask but it's easy to change the the file to ask-test
or something (in order to end some of the filename confusion that
seems to be causing problems among developers or maintaners in the
distro I d/loaded.)
In conclusion: I will (and have done this)
1. empty src/message.cxx and add a note that it's now ask.cxx
2. create src/ask.cxx and
3. rename test/ask test/ask-test.
Note: I did the same thing to InvisibleWidget.cxx which has the header
named InvisibleBox.h. Mine is named InvisibleBox.cxx.
-----------
In test/shiny.cxx shiny_panel.cxx is missing
In fltk/gl.h gl_start and gl_finish have been renamed glstart and glfinish.
was..
* // This file also provides "missing" OpenGL functions, and
// /gl_start/() and /gl_finish/() to allow OpenGL to be used in any window
*
is (on my system)..
* // This file also provides "missing" OpenGL functions, and
// /glstart/() and /glfinish/() to allow OpenGL to be used in any window
*
------------
I have modified ask.cxx (was message.cxx) to correct the tab order.
Here's the stuff to set the tab order.
set up a Widget** or an array of Widget* if you know how many will be
re-ordered. In ask/message, we know how many there are
First here are the pieces I used to fix the tab order.
* static Widget* tab_order[3];
/// prepare tab reordering -rs
tab_order[i] = (Widget*)button;
// set the tab order (group, num_widgets, widget_1, ...)
set_tab_order(&window, 3, tab_order[1], tab_order[0], tab_order[2]);
*
And here's the implementation of set_tab_order()
* void set_tab_order(Group* g, int n_widgets, Widget* o, ...)
{
Widget** po = &o;
// remove them all from the group or window and
// add them back in in the correct (reversed) order.
for(int i = n_widgets-1; i >= 0; i--)
{
if(po[i] != 0)
{
g->remove(po[i]);
g->add(po[i]);
}
}
}
*
The array itself needs to be rotated to give the focus to the right widget.
And here's how I used it to correct the tab ordering in the innerds()
function.
after this...
* button->callback(set_button_number, i);
*
add this...
* /// prepare tab reordering. -rs
tab_order[i] = (Widget*)button;
*
after this...
* window.end();
*
add this...
* // set the tab order (group, num_widgets, widget_1, ...) rs->
set_tab_order(&window, 3, tab_order[1], tab_order[0], tab_order[2]);
*
It's no worse than argc, argv, is it? ;-) And it gets the job done.
I'll strip out unnecessary code in ask/message.cxx a bit later if this
can replaces some
of the dance that had to be done to get the right widget to receive the
focus.
Hey... And thanks for this software! It's a fantastic combination of
easy use and
adapability, of simplicity and power.
I'm definitely sold on 2.x.
Uh... as an afterthought, I should say that I haven't tried the
set_tab_order() thing
on a 64-bitter. It should be fine if the stack size is the same size as
a generic pointer--
and how could be be otherwise?--but someone else will have to check that
out.
_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs