Everything you never wanted to know about fltk 2.x
Why you never wanted to know about it is because there's so much to say
about it. :-) It's almost all good so far.
This is my very first impressions, which will change over time. Let me
preface this by saying it's DEFINITELY the kind of quality that would
keep a prospective user interested past the critical first 5 minutes or
so, when they decide they "know it all", as we all do... but to varying
degrees of infinitessimal.
Roll up for the mystery tour... blow by blow as it happened...
fltk-2.0.x-r6970, first contact.
make -- very nice!
I'll be monkeying with it to configure as a 32-bitter on my 64-bit
machine, but the build is (as has traditionally been the case) EXCELLENT.
Got some new test routines. Nice. The arc demo is much better... I'll
go see if you're using the integer or the floating point version later.
Integer seems a bit more solid.
In the test folders: Ask (the source exists) didn't compile. There may
be a good reason for that... no biggie.
BITMAP! Wonderful! Now that's a bitmap.
Possible suggestion... Add text FL_ALIGN_SUPERIMPOSE_TEXT. This would
allow the image to be the button and the text label could explain what
it does.
In boxtype, if the "fltk::" was left off of the button names, they'd fit
in the button examples better.
Browser. Another outstanding improvement... at least in the test. Not
sure if the scroll bars disappear when the window is expanded in the
Text Browser/Output/Display yet (cuz I'm still just crawling along
here), but here's the keys to doing it. Thanks!
Broswercrop didn't compile. At least not out of the box on my Linux.
Problem with paths? I'll check it out.
Button doesn't show right. This is also probably a paths issue. ...
yup. Need to cd to the current directory where the executable is first.
Something like this in main() should do it.
*int main(int argc, char** argv) {
cd_dirname(argv[0])
*
* // trims filename off the end of a path and changes to the resulting
// directory. Probably needs '#include <unistd.h>' or something.
void cd_dirname(char* argv0)
{
char* buf = alloca(1024);
strcpy(buf, argv0); // fixme this should look up path from pid
char* p = strrchr(buf, '/'); // or '\\' for the SPYWARE operating
system.
if (p)
{
*p = 0;
chdir(buf);
}
}
*
again... browser is outstanding. Heh... :-) Rollover sensitivity, nice
little folders and a TREEVIEW!
cairo doesn't work... nice message telling me what I need to do to fix
it. 'Configure with --cairo-enabled'.
A++ so far, guys.
Callback demo. Good.
Clock! You've done it again. A transparent-ish window. I'll be
studying that one for sure.
Color_chooser. /*Ok, finally a problem.*/ This window needs to pop up
somewhere where the entire colormap will be visible or the colormap
itself needs to sense its dimensions and the screen limits. The limits
can be gotten from a call to XGetWindowAttributes, I think.
Cube. Nice sliders (and they all are) but let's face it the light
button sucks. :-) Need a nice LED button with all those nifty
highlights and translucent looking stuff. They can be loaded as (what
used to be called) Fl_PNG_Image, or better yet, would be to have some
other format for raw embedded data which will uncompress on the
fly--since everyone has zlib by now. I'll upload a utility to zlib
compress data and expand it into image format in a bit. The headers
consist of an ID string, W,H,D, mostly but I've also included n_frames,
and timeout for 1) pixies (pieces of box graphics) and animation (full
multiply size by n_frames to get the image()->array size.
Cubeview. Ok, /*the highlight on the wheel is a nice idea but it
doesn't look right.*/ Too much contrast (and again, this is straight
out of the box, no themes, schemes or anything else). BTW, this is why
we need alpha/subpixel or whatever, so that if we DO highlight a widget
it doesn't look so ghostly. I'd recommend removing the highlight from
an already beautiful spin-wheel (or whatever it's called) widget.
Cursor doesn't work if you click on it. Again, the paths are to blame,
no doubt, and again the fix would be to ch_dirname(...); See note
above. One more thing, there are about 150 built-in cursors in my X.
About half are duplicates, but there's a lot more than we have showing
in the demo. Might not be a biggie, but it's worth noting.
Curve. It's about the best we can do without subpixels at the moment.
It's ok.
Finally... a couple of clicks on the 'demo' program and then I'll give
you guys a rest.
I've always liked this window (the demo menu itself). And I still do.
I hit a few of the buttons and ended up on a demo called 'buttons' that
used the plastic scheme. And the plastic buttons look very nice, pretty
shade of blue, except all of the highlights are a bit "high" and
especially the toggle button (highlight is way too high) and that stupid
light button which is incomprehensively high. With the rollover
highlight alone, and the light can't be seen to turn on until you roll
back off of it. This is an artistic issue, more than a programming
issue, but the two do overlap.
That light button has more than one problem.
I'll keep messing with this, but my first impression is that this is by
and large A++ work. There are few issues, most of them left-overs from
other softwares this branched off from.
Thank you!!
...again.
Gotta get my cairo plugged in... I want to see what's up with that demo
too. :-)
_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs
