Synopsis at the top for your convenience. 1. Designing custom multi-page widgets is eaier if you use a TabGroup to design it and a WizardGroup to run it.
2. Since static libs don't currently allow meaningful
method overrides, there are a few functions that should
be turned into hooks that can be taken and restored
or added to in the manner of add_timeout() or add_handler()
BUT that can be completely controled by an external app
such as a theme engine for drawing and animating graphics
in timeout() calls.
3. The overlays check button field is too long in fluid and
draws over the Live Mode button when toggled.
-----------
re. 1.
Tip: To take over paging of a multi-page widget, design
it as a TabGroup to allow editing one page at a time but
change the class to WizardGroup and let your navigation
buttons select the page to view.
This is a Window that is paged using check buttons.
The application doesn't do anything at this point, but
the UI works and this does at least work in a static
linked lib.
Note: The bash/kate utility I currently use is so
convenient that I have been putting off making this
a gui driven app forever. It is ten times easier
than even fltk-config and outputs makefiles that
are easy to understand and easy to edit but the
templates currently are VERY ugly and this WILL
end up as a new C/C++ driven app someday. Possibly
soon.
-------------
re. 2.
Hey! Could we make Widget::draw() (or whatever) into a
static and have it call a jump vector that we can pass
to a dll/dso so that themes could take and restore that
vector to do the drawing -- thus bypassing the bad
behavior of static libs? This would be very similar to
the way we handle add_timeout() and add_handler() which
DOES work with static libs.
Also, the same thing could be done to the drawFocusRect()
thing in (currently living UpBox.cxx).
Here's the note about that.
// Maybe this should be a public fltk method?
void drawFocusRect(const fltk::Rectangle& r1) {
Not only public, but it should be a hook.
And since we 'apparently' can't overwrite C++ methods
in static libs (at this point),
Symbol::draw_symbol_overlay()
should also jump through a hook that can be repointed to
another drawing routine.
----------------
re. 3.
Since some users will use a larger font, the Overlays
check button needs to be a bit oversized, but not so that
it overlaps the Live Mode button.
Make backups. Then...
In widget_panel.fl change the width of the Overlays
field to 90 (same as Live Mode) and move Live Mode
right so that the two just barely touch.
This is most easily done with a text editor.
Around line 930 in widget_panel.fl around this...
{fltk::CheckButton} overlaybutton {
label {&Overlays}
callback overlay_cb
tooltip {Turns the overlays (red outlines) off so you can see
the edges better.}
xywh {20 0 120 24} resizable
change this
xywh {20 0 120 24} resizable
to this.
xywh {20 0 90 24} resizable
Around line 951 near this...
{fltk::LightButton} wLiveMode {
label {LiveMode!}
callback live_mode_cb
xywh {95 2 90 22}
Change this...
xywh {95 2 90 22}
to this.
xywh {110 2 90 22}
Type fluid2 -c widget_panel.fl to generate the sources,
and recompile and reinstall (at least fluid2) from scratch.
For outlanders that would be...
make clean
make
make install
;-)
Happy outlanding! Do keep backups of the original files.
More often than not I've found that the original code was
far better than my great ideas.
-----------
Attached:
widget_panel.fl after modification (needs fluid2 -c <filename> to
generate sources)
tabgroup to wizard example, NOT for use!! Just a rough example for consideration. This will eventually become a real app but there are many tweeks left to do, even in
the gui.
widget_panel.fl.tar.gz
Description: GNU Zip compressed data
tabgroup-to-wizardgroup.tar.gz
Description: GNU Zip compressed data
_______________________________________________ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
