[fltk.bugs] 1.3 re Fl_Positioner & fluid (needs a better "generic" widget for custom classes)
to greg, michael and ben.(c/o fltk-bugs) [Ben, if you pass me a better email address I won't have to pass these things the forums. Thanx.] re Fl_Positioner. Fl_Positioner should probably check if the box type fills the area and if it doesn't it should fill the area with the background color. That's should be in the draw(int, int, int, int) function. There's a note in the header that the default box type is FL_NO_BOX. Here's what NO_BOX does. [fl_positioner.png] re. fluid In addition, the "box" in fluid fills in too many defaults to be useful as a modeler or place holder for custom classes like an fl_positioner. We can change the class in fluid but we don't have a good generic widget for producing them in fluid, one that has better defaults. (I commented out almost all of the Box defaults in the ui.fl file.) For example, Box sets the fg (select color?) and bg both to the same color. My first shot at creating a Positioner didn't show the cross hairs at all due to this. Any custom widget that does graphics is likely to use the select color I think, because we don't have fields specifically for line and area colors. [01-positioner-test.tar.gz attached] Change the box to down_box and change the colors (selection color does the cross hairs, I think) using fluid and see what I mean. You may also have to move the #include up in the tab order. I think I forgot to 'save' the fl file with that changed.) 01-positioner-test.tar.gz Description: GNU Zip compressed data ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2365: FileChooser Berzerk When Typing Paths
When I first saw this I thought it got posted to me by accident. I was going to offer to look up the fix, which I think I did in version 1.16. Thanks for the note, Ben. Let me know if there's anything I can do to help. I have copies of several old versions of fltk, from v1, though a working 2.x with demos and themes (which need a complete rework in order to inherit predictably, but they do work such as they are). Ben Stott wrote: > [STR Closed w/Resolution] > > Link: http://www.fltk.org/str.php?L2365 > Version: None > Fix Version: None (r8385) > > > Fixed in Subversion repository. > > Thanks for the work, RS. I'll get around to reviewing all your fixes at > some point! > > > Link: http://www.fltk.org/str.php?L2365 > Version: None > Fix Version: None (r8385) > > > ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] Hacker's Delight (FLTK Version 2, personal installer shared, w/debug info)
To FLTK Dev. This is my midway point. The next step may take some time so here yuh go. (Makefiles can be diffed to see what was wrong with them and also see how to turn them into dynamic libs which will save TONS drive space, not to mention, you don't have to recompile the test files when you fix stuff in the base code, but you won't want to copy the Makefiles because they don't allow linking to the statics, which I think you wanted to do. The modified makefiles are in the 'mods' tarball. The other files were merged from my real system and the code should be identical to the current published rev.) To Anyone That's Interested. Special version of fltk2 for hackers. This creates a shared library for the BIG lib and static/shared for the smaller ones in order to reduce the size of the test files AND make debugging easier. Debug code is set up if you do as I did. But I'm getting ahead of myself here. The Knoppix test installation that I had planned didn't work because there aren't enough X libs available. I'd consider making a soft-linker for using the libs from your main system, but that would defeat the whole purpose of isolating it in Knoppix, not to mention the difficulty of accommodating all the variables. So this installs in a user's own $HOME folder. Create a new user you can play with. No SU, no security risks. Just a bit of hard drive space is all that is required. To uninstall just delete the entire $HOME/usr32 and it's gone. This WILL write into a .fltk/ directory in your $HOME folder as well, if you run certain apps, like fluid, but it doesn't look like there are any conflicts with existing fltk apps IF you dare install it in a user's home folder that also has version 1.x running. This is from the README in the tarball. -- Unpack files.tar.gz to files here and also mods, but don't copy the mods over your original files until you read a bit of this. This should compile the test files with no other modifications, but if you want to see where I am in the process of debugging, then copy all of the mods folder, over the original files, and sh go Then make and make install. With all the mods, this will (read "should") install into your $HOME/usr32 folder, no superuse privileges required but you'll have to add ~/usr32/bin to your PATH and ~/usr32/lib to your LD_LIBRARY_PATH in ~/.profile or ~/.bashrc so that the files can be used. See the 'go' script in the mods folder. Sorry about the name of the path but that's what I use on my 64-bit machine to allow me to compile this as a 32-bit app, which is what I personally need it to be though yours will compile as 32 or 64 bits (shared, with debug) if you use the files as I have them set up. A couple of the test files are still broken and currently HelpView and another app aren't laying out properly until second pass. Good luck. The entire test folder *with* debug info is only 4.6 megs. 2.3 megs stripped. (244 files total, about 100 of them are the executables.) Themes and plugins are not yet working. If you want the docs to work in fluid (there's a bug in helpview still, but it shows right on the second pass), see the error message in fluid2 and manually copy the 'documents' to where fluid is looking for them. It DOES work! To my tkf friends, this isn't the Forth system. This is mainly for fltk, but I'll pass it along here as well, in case you want to catch a preview-glimpse of what version 2 was supposed to be like. I'd list all the minor fixups tune-ups (double/triple click now work right) but that would take a small encyclopedia. Note: You WILL want the real version for stand-alone apps. For that just use the makefiles in the 'files' tarball. Those are the originals. But really this isn't for apps at all. It's for hackers and experimenters. Sorry. This version is for Linux only. If you want to beta-test Windows 7 and then PAY for what you just debugged, run the NSA_KEY spyware in a three-level backdoor behind your back (think "AT&T and FISA", my fellow freedom-haters and terrorist lovers), loaded with apparently designed-in security leaks, and encourage ravenous marketing strategy, and a registry everyone in the world can monkey with except you, you're on your own. Working from the end of the list to the front, those were my gripes with Windows as they went critical-mass, to the point where I now only use Windows for my modem. My linmodem never worked. FLTK (either version) is a wornderful toy to use to explore the X Windows system. Enjoy! (Try KDBG if you haven't every tried it before. It's quite nice.) http://rainbowsally.net/tkf/fltk-2/fltk-2.0.x-r7513-dev.tar.gz ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.c
[fltk.bugs] all work and no play? 2.0 xxxImage tip and a toy...
The SharedImage API is a mess. It should be made VERY clear that to
load a pngImage or a jpgImage, they can't be loaded directly as shared
images and this should be documented for every Image class we support
inherently with a note that by adding handlers we can use the same
interface for all.
For example...
* SharedImage* im = pngImage::get("gc_16x16_png", gc_16x16_png);
*
works.
* SharedImage* im = SharedImage::get("gc_16x16_png", gc_16x16_png);
*
does not work although using the name alone like this
* SharedImage* im = SharedImage::get("gc_16x16_png");
*
does work.
For those not adequately confused, when you add the datas after the name
these images load from memory. The memory is the format of the file and
can be generated by fluid if you play with it a bit or by any bin2text
kind of utility.
But all images loaded this way need a unique text name so they can be
hashed and found by a unique identifier (like an Atom but generated by
fltk).
Adding to the confusion, fluid2 inlines the data (good) but uses the
filename alone to load the image, giving one the false impression that
you a) can't load data from memory and b) SharedImage doesn't work right.
The filename is fine! It's a uinique identifier. But fluid also can
determine what file type it is (if it can show the picture, right?), so
fluid should use the proper loader and load the data from memory, thus
solving about three problems at once.
The third problem it solves is serving as a fltk programming tutorial. :-)
If you don't "get this" yet, pay close attention to the loader's name
and the number of parameters used. (Aha! See what I mean?)
*pngImage::get(); can take one or two parameters. Same with
xpmImage, jpgImage.
*
SharedImage::get(); only works with one parameter, the name.
This is as it should be, believe it or not, because sometimes we load
files by name not knowing the extension. And it works great for loading
KDE theme icons and probably will for other themes as well...
Got a sec and an itchy programming finger?
-> try this. Create an empty window in fluid (don't
generate a main, we have one)
*#include "Ui.h" // <- the name of your fluid header file.
// #include Ui.cxx too if you don't know how to "make" it
#include// roughly equiv. to "FL/Fl.H"
#include // roughly equiv. to "Murder/Mayhem.madness"
const unsigned char binary_data[306] = {
0x89,0x50,0x4E,0x47,0x0D,0x0A,0x1A,0x0A,0x00,0x00,0x00,0x0D,0x49,0x48,0x44,0x52,
0x00,0x00,0x00,0x27,0x00,0x00,0x00,0x0E,0x08,0x06,0x00,0x00,0x00,0xAC,0x00,0x05,
0xCB,0x00,0x00,0x00,0x04,0x73,0x42,0x49,0x54,0x08,0x08,0x08,0x08,0x7C,0x08,0x64,
0x88,0x00,0x00,0x00,0x19,0x74,0x45,0x58,0x74,0x53,0x6F,0x66,0x74,0x77,0x61,0x72,
0x65,0x00,0x77,0x77,0x77,0x2E,0x69,0x6E,0x6B,0x73,0x63,0x61,0x70,0x65,0x2E,0x6F,
0x72,0x67,0x9B,0xEE,0x3C,0x1A,0x00,0x00,0x00,0xC4,0x49,0x44,0x41,0x54,0x48,0x89,
0xED,0xD0,0xBD,0x6A,0x84,0x40,0x18,0x46,0xE1,0xF3,0x39,0x43,0x7E,0x30,0xC8,0x82,
0x29,0xAC,0x96,0xB9,0x6B,0x3B,0x3B,0x6F,0x44,0xB0,0xB3,0xB7,0x13,0x9B,0x54,0x2A,
0x81,0xB0,0x66,0x75,0x20,0xF3,0x6D,0xB3,0x75,0x0A,0x9B,0x69,0x3C,0xF0,0xF6,0x0F,
0xAF,0xA8,0x2A,0xC0,0x27,0x90,0x03,0x96,0xF8,0xED,0xC0,0x02,0x7C,0x5B,0x80,0x75,
0x5D,0xDF,0xD2,0x34,0xBD,0x00,0x2F,0x51,0x59,0xC0,0x3C,0xCF,0xF7,0xB6,0x6D,0x7D,
0x59,0x96,0x3F,0x76,0x1C,0x47,0x93,0x65,0xD9,0x75,0xDB,0xB6,0x39,0xCF,0xF3,0xAF,
0xD8,0xB8,0xA6,0x69,0xDE,0xBB,0xAE,0x4B,0x01,0xB1,0x00,0x21,0x84,0xDD,0x7B,0xFF,
0x0B,0xAC,0x71,0x69,0x50,0x55,0x55,0xB0,0xD6,0x1A,0x80,0x24,0x36,0xE6,0xBF,0x4E,
0xDC,0xD1,0x4E,0xDC,0xD1,0x4E,0xDC,0xD1,0x12,0x40,0x45,0xE4,0x6F,0x9A,0x26,0x44,
0xC4,0xC4,0xDE,0xB2,0x2C,0xC6,0x7B,0x9F,0x00,0x58,0xE7,0x5C,0x18,0x86,0xE1,0x56,
0xD7,0xF5,0x2B,0x70,0x89,0xFB,0x15,0xF4,0x7D,0x6F,0x9D,0x73,0xF7,0xA2,0x28,0x54,
0x54,0x15,0x11,0x31,0xC0,0x47,0x6C,0xD8,0x33,0x05,0x76,0x55,0xDD,0x1F,0x6B,0x0E,
0x4B,0x9E,0xD3,0x19,0x3F,0x17,0x00,0x00,0x00,0x00,0x49,0x45,0x4E,0x44,0xAE,0x42,
0x60,0x82
};
int main(int argc, char** argv)
{
fltk::Window* w = make_window();
w->label("ok ");
w->color(0xCCBBAA00); // set 8-digit hex bg color here, last two
digits = 0
fltk::SharedImage* im = fltk::pngImage::get("any unique name",
binary_data);
w->align(fltk::ALIGN_CENTER);
w->image(im);
w->show();
return fltk::run();
}
// Two levels of alpha, 16 and 8. I probably went a bit light on
// the alpha, eh? Still, it mixes with any background color.
*
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [RFE] STR #2351: test files fixups (ported version 2.0 to version 2.0) ; -)
I may also need to send ALL of my mods since by now, some of the fixes won't work. For example, my most recent x11 fixups (posted in STR 2351) for fl_offscreen, which may need a new x11.h to work around the name conflicts for "Window", which is also a name used by X, a little better. What is an X Window? Like all things X, it's an XID, so we can get around a few problems by simply using the XID name instead of the X Window name. Stuff like that. I don't see an easy way to respond in the STR, so I'm posting this here. And I need to get back to my own probs soon too. Organizing stuff isn't exactly my strong suit. :-) Greg Ercolano wrote: > DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. > > [STR New] > > Link: http://www.fltk.org/str.php?L2351 > Version: 2.0-feature > > > I asked rainbowsally to package up all mods to date the FLTK2 test files > into a single STR as a tar file. (instead of as separate fixes that went > to fltk.bugs over the last few weeks) > > Apparently many of the test programs were broken or written in FLTK1 > style, so the tar file is an accumulation of fixes/ports. > > > Link: http://www.fltk.org/str.php?L2351 > Version: 2.0-feature > > > ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] My bad... bum makefile upload & re. fluid plugins.
** 1. Oops. I think I sent you a bum Makefile for images/Makefile. It doesn't like the ../lib/...*.so line and in fact doesn't seem to be necessary. ... anymore? Not sure "clean" really cleaned, but in any case, it's currently all compiling even if it's not all working. ** 2. DLOPEN and fluid plugins. I had to manually set DLOPEN to 1 in my config.h to get this far It looks very much like everything except main() in fluid should be moved to a lib so that plugins can find the goodies. I had to include about all of the fluid cxx files in my essai to get this much working, but my essai is still pretty brain-dead. ;-) Fluid will never be a stand-alone app. As a dso it should be possible to get these things working without a system of callbacks and queries. Still messing with this though, so I don't know. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] re themes in fltk-2.0.x-r7513
These notes are from a stock setup, not my personal setup, but the paths are adjusted so I can't test the entire installation, just the obvious stuff that's causing problems. themes/Makefile seems to require a makedepends file. It's basically a timestamp. themes Makefile says to recompile with -fPIC, but should say configure with --enable-shared images/Makefile dynamic linkage has missing refs. add -ljpeg -lpng to make it happy (if congif.h has them set ??). themes/Makefile chokes because there's no 'main' (undefined reference to "start"). This is cause because all the themes need to be linked dynamic. Add the --shared flag AFTER the first file listed (which must be the output file). libfltk2 also needs to be linked in all but 'none.theme'. for example to make kde happy add libfltk2 and --shared flag like so KDE.theme : $(KDE_OBJ) $(THEMECOMMAND) $@ $(KDE_OBJ) $(DSOLIBS) $(THEMELIBS) ../lib/libfltk2_images.so ../lib/libfltk2.so --shared KDE.cxx (or whatever it's called) also needed and "fltk::" prefixes for font names like BOLD. I think there were only two of them. SOME of the other themes may be fixable, but certainly not all of them. There appear to be missing files, 'schemes' that are 'themes' and other stuff that's either been renamed or built on a non-standard system and we don't have the parts that would have made them work. - I'm attaching some files that indicate the changes as they need to appear AFTER configuration is done. The Makefiles are automatically generated so these Makefile changes need to be worked in by whatever is creating them. themes-fixups.tar.gz Description: GNU Zip compressed data ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] Fun stuff -- using fltk::rgbImages to load, display, and save image data
I probably shouldn't bother you folks with this, but... it was a bit of mystery how to convert my old Fl_RGB_Image based graphics routines to FLTK2, so your forebearance is appreciated. Some stuff to play with zlib and loading and saving image data directly to and from fltk2 Images. This may help demystify some of the inner workings of the new rgbImage classes. Did you wonder where the "array" went? Well, it's not there... in fact it doesn't seem to be anywhere until you use the class function "buffer()", and LO! There it is. Anyway, this is just a demo that loads image data from memory, decompresses it, displays it and then compresses the image that is displayed, saves it to disk as hex bytes that are identical to the hex that creates the image in the first place. The raw image (RGBA pixel type) is about 31 K in the Image and about 1.2 K compressed. Almost a 30 to 1 compression ratio, zero-loss. zlib-images.tar.gz Description: GNU Zip compressed data ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] woops.. junky version of pngData. Here's a fixup.
woopsie... pngData.cxx errors. For starters... 1. Two references to dbg() which only exist in the test files should be removed and 2. I forgot to account for alloc_obuffer geting some noise on the stack. That can be nulled out in get_global_lock() which is called by all the begin_read and begin_write functions. Sorry about that. 3. I'm still a little hazy on what c++ does automatically and what it doesn't do so I think there's a problem with nulling out the rgbImage** in the read(rgbImage** ) code. It should be deleted first, no? No... that caused a double free error. Man, I just don't know. Sorry about that too. :-( Here's the cxx/h files as they now stand. You already have working demo code that will continue to work, but we may have a "memory leak"??? if we don't delete the rgbImage before nulling out its pointer... or something. pngData-fixups.tar.gz Description: GNU Zip compressed data ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] fluid confused about png & test/jpeg_image.cxx (converted to pure v2)
re. fluid
Fluid needs to make up its mind. If it's going to load a png image, for
example, it needs to...
do this...
* fltk::register_images();
*
before it does this.
* o->image(fltk::SharedImage::get("/some_path/some_image.png");
*
the same as we do for open_display() whether it's open already or not.
Both have a "been_here" flags and both return if it's already been done.
Or if it's inlined data, it needs to NOT do this..
* o->image(fltk::SharedImage::get("/some_path/some_image.png");
*
but instead it should use the static const unsigned char array and do...
well, do... uh, ... well, ... and, uh, well, and...
Well, and moving right along, on another subject.
-
|\___/|
( . .)_
{__-__-_}
(Hippo? Close?)
re. test/jpeg_image (was fl_jpeg_image.cxx)
test/jpeg_image.cxx (pure v2.x) is attached.
jpeg_image.cxx.tar.gz
Description: GNU Zip compressed data
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] test/layout fixed, warning added in AlignGroup.cxx (more missing "begins()"
AlignGroup. Pretty nifty.
Ok... here's how to get it working in the test/layout demo. First of
all, the includes have to be corrected (see fltk2-migrate tool) and
THEN...
Add a bunch of "begins()". Yup. That's all that was wrong with it.
re. AlignGroup.cxx
[AlignGroup is not listed in the class reference docs.]
** in AlignGroup::layout, if children() (number of) is zero, this will
crash with a
floating point exception. Might want to do a "fatal()" warning here
so the user
knows where the error occurred.
Here's what I've done.
In AlignGroup.cxx
#include
And after this line...
int nx = vertical() ? n_lines : n_to_break() ? n_to_break()
: children();
Add this...
// rs->
if(nx == 0)
fltk::fatal("AlignGroup class Error: missing begin()???");
And now that we know what the problem was, it's easy to fix.
see attached (fixed) test/layout.cxx
And here's what it looks like.
Pretty COOL!! That could save a lot of time trying to get buttons laid
out just right for a, say, a calculator or something.
Folks, all these buttons start out at offset 0,0 and size 0,0. Pretty
darned cool.
layout.cxx.tar.gz
Description: GNU Zip compressed data
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] My bugs, your bugs, tips, tricks, and some screenshots.
Entering phase 3 of "My Life And Times With FLTK Version II":
Note: these pix just keep my programming editor from indenting when it
shouldn't. The position of the starting text and thc closed brace do
it, but why not play with that effect a little... So
-
_\ /_
{='.'=}
re. my rework of test/layout.cxx is bum. Needs "begin()" and also, my
guess
at LayoutGroup for the Groups (that layout) appears to be bad (causes
a floating point error somethwere). But later... got some other
stuff to do
first.
-
/ : \__
{.}}(.}}
re. ask (message.cxx, renamed in my system to ask.cxx so it matches the
header name).
* ask needs a default window title
\,
// rs->
static char* default_label = "Notice:";
Window window(3*BORDER_W+ICON_W+INPUT_W,
3*BORDER_H+ICON_H+BUTTON_H);
if(message_window_label && message_window_label[0] != 0)
window.copy_label(message_window_label);
// rs->
else
window.label(default_label);
// (Add a setter if you want to change it) or explicitly use "" if
you want it blank
* ask needs to measure the text and the buttons (whichever is greater)
and
if it's a one-liner and give about 32 pixels margin on the right
instead of
the long window originally created. The following requires no other
mods to
come very close to the ideal message box (defined by windows, qt,
gnome,kde)
shape.
//#define INPUT_W 270
// this looks nicer with typically smaller fonts and is more than
enough
// to handle input text in test/ask, and the window IS resizable
(along
// with the input widget.
#define INPUT_W 180
//#define MIN_BUTTON_W 75
#define MIN_BUTTON_W 64
[Default size after changes (tested with test/ask)]
Andd
[Minimum size after changes]
-
.' '.__
{.}}(.}}
re. fluid
* In fluid fhe file names are often horribly long and we only need to
verify
that we're in the right folder so when the "Wrote: " message is
displayed
it would be nice to clamp string length to something that won't ever
extend past
the limits of the screen, and in fact maybe even something readable,
say about
32 to 40 chars.
[10101010]
[the/quick/brown/fox/jumped/over/the/lazy]/dog -->
[the/quick/brown/fo...r/over/the/lazy/dog]
Here's a fluid message clamped to 32 chars.
Interested? Here's the code changes. [WARNING: This DOES modify the
input string.]
In fluid.cxx add:
// rs->
// shifts (ascii) data in string to fit in field threshold
// bytes long. DOES modify input string.
static char* clamp_path(char* dynstr, int char_threshold)
{
int slen = strlen(dynstr);
int first_half, second_half;
if(slen <= char_threshold)
return dynstr;
second_half = (char_threshold / 2) - 1;
// need room for three dots.
first_half = (char_threshold - second_half) - 3;
sprintf(dynstr + first_half, "...%s", dynstr + slen - second_half);
return dynstr;
}
in fluid.cxx somewhere around line 700 - 724 (after insertion of the
above text), change:
// message("Wrote %s", cname, 0);
message("Wrote %s", clamp_path(cname, 32), 0);
Again, this routine does change the input string so it's private
(static) in the above context and will almost certainly cause you
headaches if you use it as written in other code. ;-) Fair warning.
But it's perfect for this application and could easily be modified to
return a 'newstring()'.
Currently reworking my old v1.x files and learning the ropes here.
It's quite different and quite nice.
And away we go... 'cmon, kitty.
_\ /_
{='.'=}
...or rabbit or whateve you are.
[BTW my hard drive has apparently quit eating soggy cardboard and now
only sounds like someone's popping plastic popcorn sometimes... I think
it might just survive!! This is great. AND I have no idea in the
world why it was making such a racket and vibrating like crazy. Still,
I'm not sure I should have traded my UFO for a SATA drive. We'll see.]
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] FileIcon2 bug (and bug fix).
In FileIcon2.cxx
The code does an inefficient check for kdedir. Either use the scandir
utilities or...
Find the string "kde" in the user's PATH variable and back up to the
start of that path then find the first occurrance of "/" and cut it
there.
You'll start with something like this...
.:/home/fltk2/usr32/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin
and end up with something like this.
/opt/kde3 <-cut-> /bin
This could still miss, but in far fewer cases. Here's a tester snip.
// find-kde.cpp
#include // strdup()
#include // free()
#include // getenv()
#include // printf()
int main(int argc, char** argv)
{
char* pathbuf = strdup(getenv("PATH"));
char* starts = strstr(pathbuf, "kde");
char* ends = starts;
int err = 1; // assume the worst; ALL tests must pass.
do
{
if(!starts)
break; // no luck.
// scan back to start of string or start of buffer.
while(( starts > pathbuf) && (*starts != ':'))
starts--;
// which was it?
if(*starts == ':')
starts++; // advance to actual path
ends = strchr(ends, '/');
if(ends)
*ends = 0;
// terminate string
*ends = 0;
// Now what if this was actually still two or more paths? If
there's
// a colon separator, the kde hit did not have a "/bin" part. This
// SHOULD not happen for the PATH, but then who knows...
// We'll just do a quick check in this version.
if(strchr(starts, ':'))
break; // no "bin" in the kde hit.
err = 0; // clear the error flag
// kdedir = strdup(starts);
printf("found kde here: %s\n", starts);
}while(0); // don't loop
free(pathbuf);
return err;
}
Attached is the same routine, returning a const char* after checking
for KDEDIR in the environment, and still setting the default to /usr if
the path check fails.
It would be nicer against a lighter background but at least it's the
right icon in the config I am using.
FileIcon2.cxx.tar.gz
Description: GNU Zip compressed data
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] bugz
1. With the corrected SharedImage files it becomes apparent
that the scroll bars are not showing automatically and that
the scroll bar buttons are dead in HelpView.
2. The few SharedImage graphics formats that are supported by
default is unrealistic because we used doxygen png,
fltk_shadow.png, and fl_color_chooser.jpg in the manual and
many png's as well as gif's in the Doxygen stuff. There appears
to be no example code showing how to add handlers for these
formats.
3. The HelpView comments suggest that there is a resize()
function but it has apparently been replaced by the layout()
function.
4. HelpView is not interpreting colors correctly. The link_color
should be dark blue, possibly #3D2185 (-> 0x3D218500). It seems
safer to create this as a separate color instead of using
selection_color_
which isn't meant to contrast a white background and which might change
other colors unintentionally.
The biggest of these problems is the scrollbars and scroll
bar buttons which don't appear to be working though clicking
on the scroll bar does scroll the display and update the
position of the bar. This lack of response could also be tied
to why the scrollbars don't automatically show and hide when
the content changes. ???
5. namespacefltk.html is is linked but missing from the Doxygen
files in the fluid2 help->manual link.
6. The 'back' button works!!
7. I accidentally imported the whold x11/run.cxx file.
THIS PROBLEM IS VERY NOTICIBLE IN FLUID2.
if (abs(e_x_root-px)+abs(e_y_root-py) > 3
// || event_time >= ptime+(push?1000:200)) { *** THIS IS WRONG!
***
|| event_time >= ptime+(push?400:1000)) {
And I know it's wrong because I almost have to break my
mouse clicking so fast just to get the widget_panel to pop
up. ;-) I earnestly recommend changing that click timout above.
8. the new xim code seems to be causing the color chooser
in fluid to pop up behind the widget_panel instead of on top.
9. Sliders in fluid live mode and editing mode disagree
on meanings of color names. Live mode doesn't match
colors selected when editing.
Here's unselected colors. You can see by the focus box that this may
indeed be selected, but these colors don't change when there are other
objects highlighted or clicked on in the form..
Here's selected with the entire set of colors used to generate this
test.
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] The changes in these files fix HelpView
Here are the files I had to make very minor changes to in order to fix HelpView. You'll notice that HelpView is not one of them. :-) Pls ignore the buggy code I posted on this subject in the previous note. That COULD have stripped out the whole path, but probably never got a chance to. This set of files now does nothing more, really, than stipping junk off the end of the SharedImage root directory which was almost (but not quite) certainly a trailing slash. SharedImage was too sensitive to trailing slashes, so I wrote the strip_trailing() routine to remove those and also other stuff that could end up tacked onto the end of a path by something typed into an input or editor widget or even from an external app that gets fed into our SharedImage class. Anyway... Do I get the prize? If so, we'd better share it with dumb luck. ;-) Thanks again... SharedImage.h.tar.gz Description: GNU Zip compressed data fluid.cxx.tar.gz Description: GNU Zip compressed data SharedImage.cxx.tar.gz Description: GNU Zip compressed data ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] wait... it gets better...
Heh. :-) It gets even better. What fixed HelpView was my buggy code! I forgot the break; if there were no trailing chars left. That code probably stripped out the entire path! I crack myself up sometimes... What was ailing HelpView? Was it a full path tagged onto a full path? Or was it a newline or something at the end of a path? Stay tuned. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] re. fltk-2.0.x-r7473 configure & Xcursor.h (non-errors)
re. fltk-2.0.x-r7473 Add Xcursor to the (...)/X11 paths in configure. Configure still issues a warning about not being able to compile the headers but it does it anyway. found = yes and usable = yes with this change. Usable had been "no". here's what I changed.. * ac_x_header_dirs=' /usr/X11/include/Xcursor /usr/include/X11/Xcursor /usr/local/X11/include/Xcursor /usr/local/include/X11/Xcursor * Could this be because X doesn't know we're using c++? (#ifdef __cplusplus ... ?) run.cxx has changed. I'll import the changes into my system. Thanks! :-) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] Tip re TabGroup/Wizard design, hooks v. virtuals in static linkage, fluid overlay button prob.
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 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
[fltk.bugs] Tab reordering, retaining parent-child linkages.
This is added to my Groups class public methods declarations in Groups.h
* void set_tab_order(int nwidgets, int nfocus, Widget* o_1, ...);
*
This is added at the bottom of my Groups.cxx file.
*// rs-> tab reordering. Changes tab ordering by removing and
// reinserting child widgets under their original parents in the
// new order and sets the focus widget explicitly.
void Group::set_tab_order(int nwidgets, int nfocus, Widget* o_1, ...)
{
// both the number of widgets and the number of the widget
// to focus are indexed base 1. Null widgets will be skipped.
if(nfocus <= 0) return; // error, focus too low
if(nfocus > nwidgets) return; // error, focus too high.
if(nwidgets < 2) return; // nothing to do
// remove them all and reinsert to set
// new tab order.
Widget** stk = & o_1;
int focus_index = nfocus -1;
Group* parents[256]; // this sets the limit on how many we can do at a
time.
for(int i = 0; i < nwidgets; i++)
{
// ignore null widgets
if(stk[i])
{
Group* super = stk[i]->parent();
parents[i] = super;
super->remove(stk[i]);
}
}
for(int i = 0; i < nwidgets; i++)
{
// ignore null widgets
if(stk[i])
{
parents[i]->add(stk[i]);
if(i == focus_index)
parents[i]->set_focus(stk[i]);
}
}
}
*
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] super short..
My original tab ordering routine only worked for simple linkages. It turns out that my tab reordering was re-inserting the "cards" under my main window. Too bad. It was a neat effect and easy to do in fluid. Anyway, here's the tab ordering routine, now part of my Groups class, which retains the widgets' original parent-child linkage. See next email. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] 2 nicer looking widgets (test/cube.cxx and flud/live_widget)
Noticed in test/cube.cxx The sliders look wide and clunky. Let's go with something a little closer to the new sizes on the scroll bars. I like 20. Around line ... speed = new Slider(390,90,17,220,"Speed"); speed->set_vertical(); size = new Slider(450,90,17,220,"Size"); size->set_vertical(); ... The sliders start looking clunky at around 25, I think. 15 (the size of our scroll bars) might be too narrow, but 40 was really strange looking. -- Want a nicer looking live mode for fluid? My line numbers are probably 50 to 100 lines further down that yours so I'll tell you where I found this in my files and you can adjust for the difference. These are in live_mode_cb(...) which is at my line 2231 in fluid/WidgetType.cxx round my line 2249 change one of the following lines... // live_window = new DoubleBufferWindow(w+20, h+55, "Fluid Live Mode Widget"); // live_window = new DoubleBufferWindow(w+80, h+55, "Fluid Live Mode Widget"); to int minw = w > 120 ? w : 120; // at least get the button inside the box. live_window = new DoubleBufferWindow(minw, h+55, "Fluid Live Mode Widget"); If minw is used elsewhere, use another name. I used 'tmpw' but changed it here to make it's meaning more clear. The above will try to keep at least the button completely inside the green area. (Haven't tested this on a tiny widget yet, sorry, but when I had w+80 as a fix for this problem, it was fine and it looks like the button is 100 and the left and right margins are 10+10, so it SHOULD be fine... more famous last words.) In fluid/WidgetType.cxx around line 2255 (probably much less) change widget position as follows. live_window->begin(); live_window->box(fltk::FLAT_BOX); live_window->color(fltk::GREEN); Button *btn = new Button(10, h+20, 100, 25, "Exit Live Mode"); btn->labelsize(12); btn->callback(leave_live_mode_cb); // live_widget->position(10, 10); live_widget->position(0, 0); In thory, we put the widget fully inside the box with no margin at the top or the sides, only at the bottom for the button to leave live mode. Here's what it looks like. [I hope I remember the screenshot.] [and I did remember. Yay me!] Note: These windows also close when you [x] out of 'em so the button at the bottom isn't even crucial, but I like it so it's still there. - ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] Can you stand a little negative criticizm? ;-)
Noticed in TabGroup in executables.
We need an easy way to disable square dotted lines are on focused
widgets. It's not always appropriate though they look nice enough to
put on every button whether it has focus or not at times.
Can we do both?
But the most important thing is can we disable it on a per-widget
basis. In fluid, we can change the selected color to get a much better
effect, especially for things like TabGroup widgets.
For example with a tab widget with 'color' set to match the window
background and 'selected' set to a slightly lighter color, if
background is 0xEE00 or something like that, the square highlight
box contrasts poorly with the default triangular shaped tabs.
Screenshots. [hope I remember to include them.]
BEFORE
Pretty icky, eh?
In UpBox.cxx we see the note around line 42.
// Maybe this should be a public fltk method?
void drawFocusRect(const fltk::Rectangle& r1) {
Not public, but it should be possible to disable it on a per-widget
basis.
UpBox.cxx has a misleading name, by the way, because it contains all
kinds of box drawing functions including the problematic focus box
drawing routine.
The comments near the top got it right.
// Box drawing code for the Fast Light Tool Kit (FLTK).
That should be reflected in the name as well. (Don't rely on Doxygen to
iron out these connections. We don't all use Doxygen docs cuz you miss
way too much detail.)
Okay, who calls this drawFocusRect() code.
You use Doxygen and I'll use other methods. I'm starting at T = 11:35
am. Ready, set...
It's now 11:37. I had to stop for a smoke... it's called once by one
function in the entire system
Symbol::draw_symbol_overlay, which is ALSO in the poorly named
"UpBox.cxx" file calls it.
Try again? Let's go see who uses that function. And if it's already a
virtual, we may be in business.
Ready set... go...
11 hits. 20 seconds. See why I don't use Doxygen? Well, enough about
that. Here's the important part.
One of the hits is in Symbol.h. (Big surprise, but you realy just
never know... because, after all, the function Symbol::draw... was in
UpBox.)
Here it is.
virtual void draw_symbol_overlay(const Rectangle&) const;
And it IS a virtual. (You are so hot, fltk!) So...
We rewrite the function in our own code removing only the drawFocusRect
part and put it into our main file.
#include // Symbol
#include // drawflags
void fltk::Symbol::draw_symbol_overlay(const fltk::Rectangle& r1)
const {
if (!drawflags(FOCUSED)) return;
fltk::Rectangle r(r1);
inset(r);
if (r.w() > 12) {r.move_x(1); r.move_r(-1);}
else if (r.w() <= 3) return;
if (r.h() > 15) {r.move_y(1); r.move_b(-1);}
else if (r.h() <= 3) return;
// drawFocusRect(r);
}
AFTER
Nice, no?
This probably kills the focus box for everything, though even where I
might want it.
Two main points I want to emphasize here are these.
1. Doxygen is not a good replacement for sensible file
names. It's not even that great for programming at this low level.
2. The focus box drawing routine should be moved out of Symbol and into
something that can be disabled on a case by case basis.
At least that's what I think at this point. It was already a virtual.
I've had to revert to previous code more times than I can count. This
is really a very well designed system, but the filenames need a tweek
here and there, if you ask me.
So... Don't take this terrible news too hard. ;-)
You are still the greatest!
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] prob in fluid tab groups and fix for unrealistic limits in test/size_range.cxx
Noticed in fluid.
TabGroup seems to have a bug. It eats processor time drawing the
widget outline until you insert the first group.
The first group should probably be inserted automatically with a
label (not a name) like 'Tab_1'. If you have other plans it's
easy to delete and it would be helpful for beginners, especially
those of us that never rtfm. ;-) ...until we have no other choice.
I'm on another trail right now so I haven't followed up on that
with a modification.
--
Noticed in test files (which works now whether it did before
or no, which I am not keeping track of -- see my recent test
files upload if the version in the development tree won't play.).
In the file size_range.cxx
The window is set to unrealistic limits with the constraint so small
that the button doesn't initially show. (The WM won't let it resize
to 0, 0.)
UI::UI() {
fltk::DoubleBufferWindow* w;
*// changed startup size to put button near middle of window -rs
**{fltk::DoubleBufferWindow* o = window = new
fltk::DoubleBufferWindow(120, 80);
* w = o;
o->type(241);
o->user_data((void*)(this));
o->begin();
fltk::Button *b = new fltk::LightButton(25, 25, 68, 20, "button");
o->end();
* // changed range (x can shrink by 20 or expand by 80,
// y can shrink by 20 or expand by 40 setting (xmin, ymin, xmax, ymax)
// as follows. -rs
o->size_range(100,60,200,120);
*}
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] HelpView with its vars in a struct (if you want it).
This is a NON-STANDARD upload with the SAME NAME as the other file. If you want to play with it, rename it yourself, or whatever you have to do to keep it out of the rest of the development code. Let me explain. I have made the variables into structs for ::draw(), ::format(), and ::table_format(). Currently it's a work-alike clone, slightly un-optimized (every read is indirect *) but it's ready to build into a system so subroutines that can pass all the variables around as a single pointer. It's a little difficult to test at this point but I think it's currently an exact functional clone of the original code. From here I will try to make the if-else stuff more intelligible. BTW, the first on (::draw()) is loaded with descriptive comments in case you have been puzzled about how it works. It's really a very cool little parser. I may just need to keep track of unknown keywords (tags) and count opens and closes. At least I hope so. Someone did a lot of work on that thing and I'd sure like to see it work. Anyway, in order to make testing easy, I have left the name of this file the same as the original, and it SHOULD be an exact work-alike still. This is a copy of HelpView.cxx (same name -- LOOK OUT!) [See attached.] -- * In this, all the reads are indirect, that is they are reading object->varname rather than object.varname. The 'me' macro only looks like it's addressing the vars directly because it's defined as #define me (*structptr) The reason to use the 'me' macro is because it keeps the code readable. Perhaps more readable than it was, because now we can see who owns what variables. I'll try to get this working with the Doxygen now. It already works with simple HTML. I'll let you know if I have any luck. HelpView.cxx.tar.gz Description: GNU Zip compressed data ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] HelpDialog source mismatch, filename sources, and where HelpView may be choking.
HelpDialog.fl, cxx, and h
The fluid file doesn't match its output files. Both are part of a broken
help system, apparently but its broken for other reasons -- I don't think
the html parser (very cool) is looking for the tag, for starters.
More on this in a bit. First...
Sources of sources.
In order for the fluid file to output the .cxx file...
In HelpDialog.fl at line 172 change
// callback {find_pos_ = view_->find(find_->value(), find_pos_);}
callback {find_pos_ = view_->find(find_->text(), find_pos_);}
In HelpDialog.fl at line 172 change
// /*fl_register_images();*/}
fltk::register_images();
} // <- the close brace is part of the code
And in order for the fluid file to output the .h file change
In HelpDialog.fl at line 41 change
// class FL_API HelpDialog {open
class FL_IMAGES_API HelpDialog {open
Note: FL_IMAGES_API is defined in FL_API.h and has the identical definition
but these changes bring the fluid source into sync with its alleged output.
:-)
If value() and text() aren't synonyms in this context, they
probably should be, but again, this doesn't seem to be my bug.
--
filename_*.c* files.
This is great for static libs but for dynamic ones the penalty for loading
them all at once is zero.
// in filename_absolute.cxx
FL_API int filename_absolute(char *to, int tolen, const char *from,
const char* cwd=0);
FL_API int filename_relative(char *to, int tolen, const char *from,
const char* cwd=0);
// in filename_name.cxx
FL_API const char *filename_name(const char *);
inline char* filename_name(char* a) {return
(char*)(filename_name((const char*)a));}
FL_API const char *filename_ext(const char *);
inline char* filename_ext(char* a) {return (char*)(filename_ext((const
char*)a));}
// in filename_match.cxx
FL_API bool filename_match(const char *, const char *pattern); // glob
match
// in filename_isdir.cxx
FL_API bool filename_exist(const char*);
FL_API bool filename_isdir(const char*);
FL_API FL_FILESIZE_T filename_size(const char *); // return size of file
FL_API long int filename_mtime(const char *); // return modification time
typedef int (File_Sort_F)(const dirent*const*, const dirent*const*);
// in scandir.c
FL_API int alphasort(const dirent*const*, const dirent*const*);
// in filename_list.cxx
FL_API int casealphasort(const dirent*const*, const dirent*const*);
// in numericsort.cxx
FL_API int casenumericsort(const dirent*const*, const dirent*const*);
FL_API int numericsort(const dirent*const*, const dirent*const*);
FL_API int filename_list(const char *d, dirent ***list); // uses
numericsort
// in filename_list.cxx
FL_API int filename_list(const char *d, dirent ***list, File_Sort_F
*sort);
Alphashort and casealphasort aren't even in the same cxx file.
Let me go check the sizes of the object files (stripped) just
for reference and I'll include the results here for in case
you're interested.
File: `scandir.o'
Size: 440
File: `filename_name.o'
Size: 524
File: `filename_match.o'
Size: 1904
File: `filename_list.o'
Size: 1112
File: `filename_isdir.o'
Size: 1760
File: `filename_ext.o'
Size: 544
File: `filename_absolute.o'
Size: 2396
[Uninitialized data which is allocated at link-time won't
be included in the file size.]
I am dynamic linked (at this time) but I may in fact static
link certain apps later. I'm just thinking about this.
These are great little utilities, by the way. Thanks!
---
Ready? What's wrong with HelpView...
The reason the HelpView doesn't work MAY be because it isn't able to
ignore ignore unknown HTML keywords. It should probably count opens
and closes and issue errors if they aren't balanced.
Here's why I think so. If you can, test this.
Change the link in the docs index.html from "html/index.html" to
"preface.html". This will avoid the Doxygen generated docs.
Dunno about you, but for starters I copied my documentation folder to
~/usr32/share/doc/fltk for this test so that the link matched my
customized FLTK_DOCDIR etc. Whatever.
Then fire up fluid and look at the help->manual.
Guess what. No prob.
So the issue is in parsing the Doxygen stuff. No wonder nobody
debugged that thing!! That's as far as I have gotten on this so
far myself. Beautiful parser, by the way. :-)
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] themes.
themes. This is another long one and all I can say in my defense is that it will take a heck of a lot less time to read than it did to write. Still with me? Using the defaults (and risking an unwanted install)... here I go... Running make configures for the 64-bit system I have (which I don't want to compile for reasons that are my own -- I need a 32-bitter). I'm doing this to find out whether the themes ever worked. Maybe not. In the themes directory, 'make' doesn't work because makedepends is missing. It never gets off the ground. The error message that makedepends is missing comes up several times during the 'make' process, and is just one of them so... let's see if that's THE problem only A problem. On the long shot that this is a typo, and it really wants makeinclude, I create a softlink to makeinclude named makedepends which is wrong but.. it's all for the sake of science. ;-) This is after the first attempt to make... make clean make It seems fine. But will it work with a fresh file set. Deleting the whole thing and starting from scratch. makeinclude doesn't need to exist for the softlink to exist. ln -sf makeinclude makedepends make What's your guess. Did it work? Nope. === making src === Makefile:223: makedepend: No such file or directory === making images === Makefile:97: makedepend: No such file or directory === making OpenGL === Makefile:90: makedepend: No such file or directory === making fluid === Makefile:103: makedepend: No such file or directory === making glut === Makefile:92: makedepend: No such file or directory === making test === Makefile:217: makedepend: No such file or directory There are other warnings about float to integer conversions in transform.cxx which MIGHT cause new users to wonder, and which probably should be silenced but certainly the makedepends noise should be turned off. Now my question is, if I go ahead and install will the themes install too? Not likely, because they too had a missing makedepends and they don't show up in the above list. For some reason it appears that makedepends is critical for themes but optional for the rest of the make-ed files. (?) Now I DON'T WANT ANY FLTK2 ANYWHERE IN MY GLOBAL FOLDERS TREE because it will make it uncertain which versions are linking into my apps as I mess with my 32-bitter version of this. So I'm going to hunt down all the /usr/local paths in all the files and change this to my home folder/local and if it doesn't work, know this: I tried. Fair enough? ;-) config.h two hits. Excellent. / I'm using my /home/fox folder, by the way. Thought you might enjoy knowing that. :-) (You don't get it? You win, FLTK. You *are* the greatest. Version 1 was even good enough to give 'em a run for the money because it was so easy to monkey with.) / config status also gets reused sometimes so I'd better fix the appropriate paths in there (but not all need to change). And there we got three hits including 'prefix'. grep '/usr/local' */* Rats!! Some of the binaries already have that set up in them but really all we want to do is see if we can get it to compile. But most of the hits look non-critical, including fluid.cxx but I'll change the fluid too. Thats: fluid/fluid.cxx:docdir = "/usr/local/share/doc/fltk"; Yes, it IS worth your time looking at all this junk... You might want to use the path from the config file instead of duplicating it verbatim because then this path could be changed once in config.h and like the rest of your system, it would be easy to change globally at once source file. Example? Your use of makeincludes is far more sensible than the steaming pile generated by automake, for example. Have any idea how hard it is to hunt down this stuff in a automaked tree? I'll try this myself later but something like this might work. docdir = FLTK_DOCDIR; // from config.h It's already quoted in config.h so don't quote it again or it will unquote the string. I'll go down one more level looking for paths that I need to change. grep '/usr/local' */*/* There's some in the ide folder... no prob. So here we go again. make clean make And now let's see if it's love or war... Did the bum prefix get back into the build somehow? make install mkdir: cannot create directory `/usr/local/include/fltk': Permission denied Who did that? libtool? There is no libtool. Ok... it's in makeinclude. Fixing prefix... fixed... prefix= /home/fox/local ...no offense... and make install Ladies and gentlemen, place your bets. === installing src === Installing include files in /home/fox/local/include/fltk... Installing FLTK1.1 emulation include files in /home/fox/local/include/fltk... Installing fltk2-config in /home/fox/local/bin... Installing static core library in /home/fox/local/lib === installing images === Installing static images library in /home/fox/local/lib === installing OpenGL === Installing static OpenGL library in /
[fltk.bugs] Tab ordering. (Two variables, have you struggled with this too?)
I know I must not be the only one that can't count to three because fltk doesn't have a tab ordering routine yet so I'm not too terribly embarrassed. Got a sec? This is going to take some time. BTW, is a hard drive supposed to blow smoke and sound like a steam engine? Note: I have renamed my message.cxx to ask.cxx because that's the name of the header. As you read the word "ask" below, think "message". I'm in ask.cxx and we are looking at the creation of three buttons labeled Yes, No, and Cancel. They are anonymous critters so we need to look at the widgets structure in a debugger to be sure who is getting linked to the group widget first and who is getting linked last because this sets the search order and the tab order at creation time. In a debugger (I'm using kdbg) we can see FOR SURE that the first button created is the "Yes" button and the last is Cancel. Notice that this *IS* the tab order for an ask widget. And it's not what we expect. We'd like to tab from Cancel to No to Yes, starting the loop with the focus on the Yes button. We can force the parent widget to re-link its children (these buttons) in the right order by using the Group::remove() and Group::add() functions. Here's what we have then, in human terms. [Yes | No | Cancel] ^ focus --> With the focus set on the first button during creation which cycles to No and Cancel when we TAB or even use the arrow keys (which make this appear to rotate backward). And here's what we want. [Cancel | No | Yes] ^ --> focus -> (wraps) Our group is the window so we'll be using that object to do the reordering. First we remove them all from the parent. Let's just call the parent the Group. So first we remove all the widgets from the Group. This doesn't destroy the object, it just breaks the linkage. (Each object is responsible for it's own destruction.) If we were clever, we made a list of these objects beforehand, storing their address in an array which we can use to tell the Group how to re- link these objects. We say: set_tab_order( &window, // the Group 3,// items 3,// gets the focus b2, // Cancel b1, // No b0// Yes ); Then we remove them all and reinsert them all in this order and we'd expect the focus to be on the last linked as it would be if it were the last created And... Everything looks fine except Cancel for some odd reason gets the focus. What went wrong? In the ask code, that code also sets the focus. We can infer from this odd behavior that the focus is set by the index of the focused widget rather than its address or xy position. And it's no longer in the first position; it's now in the third. Here's the code in ask that set the focus. if (!istr) window.set_focus(button); In conclusion, no, a hard drive is not supposed to blow smoke OR sound like a steam engine. I knew you were wondering about that, as I have been. But if you have messed with tab ordering in the past and gave up, due to this two-variable complexity now you know what went wrong. Looking at this... [Cancel | No | Yes] We can see that the one we want is now in the third position. set_focus->(widgets[nwidgets-1]) --- See a full implementation in the attached file which I'll name ask-message, since there's some confusion about what it really is. ;-) Yup. Either a steam engine or a carpet factory... I'm wondering if getting a SATA drive was such a great idea now. Oh! And now it sounds like it's eating something... like soggy cardboard. So I hope I get this out before it decides to take a nap or something. ask-message.cxx.tar.gz Description: GNU Zip compressed data ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] ps...
P.S. There are two spelling of glVisual & glvisual. I went with the lowercase version (for consistency) and made a macro alias for it, so that nothing breaks. Also the name of gl_start.cxx is uh... Where's it's header? ;-) (It's gl.h if it's anything.) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] fluid twee (live mode), docs/reality divergence, better thread demo
fluid live mode.
This is around line 2250
// changed w+20 to w+80 rs->
live_window = new DoubleBufferWindow(w+80, h+55, "Fluid Live Mode
Widget");
This is around 2260. I commented out the resizable() line.
// live_window->resizable(live_widget); // <-rs
The resizing scales the contents so it's not so good.
-
No biggie, but if the string funcs are in fltk namespace the
docs need to be changed or the code does.
I think the string.h file *IS* in fltk namespace?
This is in fltk/string.h
#include "FL_API.h"
FL_API extern char* newstring(const char *);
etc...
-
Add a minimal pause (1 microsecond) to add better time sharing
between threads.
In fltk/lock.cxx
#include
void fltk::lock() {usleep(1); init_or_lock_function();}
This still doesn't fix the attempt to scroll the browser to
the bottom in the threads demo though. The Browser is a
monster and probably has too much to do to scroll to the
bottom. I replaced them with simple TextDisplay Widgets
and it cruises right along.
See attached 'thread-display' tarball.
There are a couple of notes down around the #include
And the fact that the browser widgets weren't time sharing tells
us something. We probably can't hog all the time in threads (fd's).
Timeouts and especially the X queue needs plenty of time to
send messages to complex widgets like the Browser.
I think this is the problem because when I was playing with
this, the app completely hung. X was unable to to anything.
What I did that caused it to hang was to try to send a
cbScroll call back a command in a timeout loop so that
the browser would scroll in a timeout.
Boy! That sure didn't work. =-O
threads-display.tar.gz
Description: GNU Zip compressed data
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] Some more notes and a tab_order() function to set the tab order in groups
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
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] fast_slow fixed..
fast_slow in the test folder is now fixed. The fluid file now generates the correct code. fast_slow-fixed.tar.gz Description: GNU Zip compressed data ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] Cast to Widget in Accellerator demo, dbl-click timeout fix(?), script to aid code migration...
In accellerator (see my previous mod).
Changed callback parameter cast from a) void* to Button** to b) void* to
Widget**. Widget has LOTS of great new features in 2.x. Very nice. The
work-around in 1.x was quite involved at times.
-
TODO. This is my personal todo because I don't want to mess with the
base system too much until I have all the other stuff (including
schemes?) working.
Mouse clicks aren't right in X. The double click timeout is too short
(should be 400 ms +/- 100 ms) and the event loop isn't eating up button
release events the way the old one did. This is important, but I can't
remember where I noticed it.
Currently trying this, and it seems to help.
in run.cxx around line 1220
* /// rs-> testing.
/*
if (abs(e_x_root-px)+abs(e_y_root-py) > 3
|| event_time >= ptime+(push?1000:200))
*/
// Note: dbl-click timer = 400 ms, release/reset = 1 second.
// Hopefully I'm interpreting this correctly?? -rs
if (abs(e_x_root-px)+abs(e_y_root-py) > 3
|| event_time >= ptime+(push?400:1000))
// ... etc...
{
e_is_click = 0;
*
--
Code migration tools.
*NO WARRANTEES? You betcha. This is radical, but can save you time.
Keep backups.
*
Here's a script I used to get about 90 percent of the fix-ups in the
test folder done. I commented out the ones I created as I used them.
It's not a complete list but if you like to live dangerously, here you go.
I have not included the C code for 'replace-in-file'. If you don't know
how to write one yourself you probably shouldn't be messing with this.
Game? Change the long names first to avoid creating new strings you
need to modify.
Also.. The fnr code could be modified to create a translation table.
Also, also, this will NOT fix stuff like the bug in the adjuster demo
where similarly named widgets act very very differently.
I'm off to see what's up with the image demos, so you're on your own
with this.
---> doit.sh (It's a plain text file, so type 'sh doit.sh' to run)
## cd to the correct folder as/or if required.
# find and replace globally in the directory, requires
# a search and replace utility that will read ONE entire file
# copy the file with replaced text to a new buffer and write
# that new buffer out to the original filename. My utility is
# is replace-in-file
# this is the bash function that does find/replace globally
fnr() #
{
srch=$1
repl=$2
for file in *
do
replace-in-file $srch $repl $file
done
}
#fnr fltk/compat/FL/Fl_Value_Slider.H fltk/ValueSlider.h
#fnr fl_line_style fltk::line_style
#fnr "fl_rect(" "fltk::strokerect("
#fnr fltk/fl_message.h fltk/ask.h
#fnr fl_message fltk::message
#fnr Fl_Window fltk::Window
### do NOT doit MenuItem MenuItem
#fnr Fl_Widget fltk::Widget
#fnr Fl_Box fltk::Box
#fnr Fl_Value_Slider fltk::ValueSlider
#fnr Fl_Choice fltk::Choice
#fnr Fl_Slider fltk::Slider
#fnr Fl_Browser fltk::Browser
#fnr Fl_Button fltk::Button
#fnr Fl_Return_Button fltk::ReturnButton
#fnr fl_input fltk::input
#fnr Fl::run fltk::run
##
#fnr Fl_Align_Group fltk::AlignGroup
#fnr Fl_Align fltk::Align
#fnr FL_ALIGN_TOP fltk::ALIGN_TOP
#fnr FL_ALIGN_BOTTOM fltk::ALIGN_BOTTOM
#fnr FL_ALIGN_LEFT fltk::ALIGN_LEFT
#fnr FL_ALIGN_RIGHT fltk::ALIGN_RIGHT
#fnr FL_ALIGN_TOP_LEFT "fltk::ALIGN_LEFT | fltk::ALIGN_TOP"
##
#fnr FL_NO_BOX fltk::NO_BOX
#fnr FL_DOWN_BOX fltk::DOWN_BOX
#fnr Fl_Callback fltk::Callback
## X stuff
#fnr fl_display fltk::xdisplay
#fnr fl_screen fltk::xscreen
#fnr fl_visual fltk::xvisual
#fnr Fl_Group fltk::Group
#fnr Fl_Button fltk::Button
#fnr Fl::args fltk::args
##
#fnr Fl::help fltk::help
#fnr fl_xpixel fltk::xpixel
#fnr fl_colormap fltk::xcolormap
#fnr fltk/fl_draw fltk/draw
#fnr fl_color fltk::color
#fnr FL_BLACK fltk::BLACK
##
#fnr 'FL_SOLID' 'fltk::SOLID'
#fnr 'FL_DASH' 'fltk::DASH'
#fnr 'FL_DOT' 'fltk::DOT'
#fnr 'FL_DASHDOT' 'fltk::DASHDOT'
#fnr 'FL_DASHDOTDOT' 'fltk::DASHDOTDOT'
##
#fnr FL_CAP_FLAT fltk::CAP_FLAT
#fnr FL_CAP_ROUND fltk::CAP_ROUND
#fnr FL_CAP_SQUARE fltk::CAP_SQUARE
#fnr FL_JOIN_MITER fltk::JOIN_MITER
#fnr FL_JOIN_ROUND fltk::JOIN_ROUND
#fnr FL_JOIN_BEVEL fltk::JOIN_BEVEL
##
#fnr fl_vertex fltk::addvertex
#fnr fl_begin_line strokepath
#fnr fl_end_line closepath
### fixups
#fnr fltk/compat/FL/fltk:: fltk/
#fnr fltk/fltk:: fltk/
#fnr Button.H Button.h
#fnr Group.H Group.h
#fnr Window.H Window.h
## risky but some "fltk::" stuff may need to be unquoted.
##fnr "\"fltk::" "\""
exit
## must be done manually. These apply also to descendents of these classes.
Valuators: bounds() => range()
Choice: menu() => item()
fl_rgb() in the context of a color(rgb(...)) MIGHT not be needed at all.
thus:
fltk::color(fl_rgb((uchar)(sliders[0]->value()),
(uchar)(sliders[1]->value()),
(uchar)(sliders[2]->value(;
becomes:
fltk::color((uchar)(sliders[0]->value()),
(uchar)(sliders[1]->value()),
(uchar)(sliders[2]->value()));
#
[fltk.bugs] Quizz for developers & Adjuster test works now
Let me show you why the Adjuster demo didn't work. See
the callback at the bottom.
See if you can figure out why casting the thing to a Box*
showed the Box's name being the hex value of it's X dimension.
That is if you got that far. ;-) Enjoy!!
adjuster.cxx
*#include
#include
#include
#include
#include
#include
fltk::Adjuster* a1;
fltk::Adjuster* a2;
fltk::Group* b1; // a no-click button
fltk::Group* b2; // a no-click button
void adjcb(fltk::Adjuster* a, void* v);
int main(int argc, char** argv)
{
fltk::Window* w;
w = new fltk::Window(325, 105, "fltk::Adjuster");
w->begin();
{
// We'll play with two adjusters and two widgets to
// show the values.
char buf1[32] = {0};
char buf2[32] = {0};
a1 = new fltk::Adjuster(90, 32, 67, 25);
a1->callback((fltk::Callback*)adjcb, (void*)(&b1));
fltk::Adjuster* a2 = new fltk::Adjuster(280, 10, 24, 75);
a2->set_vertical();
a2->callback((fltk::Callback*)adjcb, (void*)(&b2));
// we will use a group as a label display but we'll give
// it a read/write buffer we can update with Adjuster
// outputs. Basically it's a button that doesn't 'click'.
b1 = new fltk::Group(20, 32, 70, 25, buf1);
// and by the time we're done decorating it, you'd never
// know it was just a Group. :-)
b1->box(fltk::DOWN_BOX);
b1->color((fltk::Color)0xff00);
b1->align(fltk::ALIGN_INSIDE);
// and another one.
b2 = new fltk::Group(208, 32, 70, 25, buf2);
b2->box(fltk::DOWN_BOX);
b2->color((fltk::Color)0xff00);
b2->align(fltk::ALIGN_INSIDE);
}
w->end();
w->show();
fltk::run();
return 0;
}
// Here's the callback
void adjcb(fltk::Adjuster* a, void* v)
{
// Cast the group pointer to a button so we can write to
// the label. Both descend from Widget, that is their
// structs 'look' similar, so we can use button's
// features on the common struct fields.
fltk::Button* b = *(fltk::Button**)v;
// we made sure to put writable memory in the group label
// so we can write to it.
char* text = (char*)b->label();
// let the adjuster format its own output into the buffer
a->format(text);
// and re-assign the rext to the group's label.
b->label(text);
// and be sure the new text appears in the next flush.
b->redraw();
fltk::flush();
}
*
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] The Daily Roach...
The Daily Roach... [This is not going to be as bad as it sounds]
Reminder: I'm rebuilding my fltk2 from scratch for a 32 bit system
on a 64-bit platform IN a dedicated home folder for test with zero
possibility of linking the wrong files or libs that are left overs
from previous working versions.
I'm up to test/line_type in the test folder. Some of the
oldies are starting to play ball. I.e., I'm beginning to "get it".
Most of the changes (not all!) involve including
instead of and renaming the classes from
Fl_ to fltk::
Ready for today's report card?
{o}}{O}}
Possible gotcha. The fracviewer.h, c, and cxx code exists in
several different forms.
The h file used in the demos is the very simple one that
inits the enum like this.
typedef enum { FLYING=1000, POLAR } MovementType;
I renamed mine to fracviewer_4test.h to avoid confusion.
I also renamed the .cxx file which works with the demos
fracviewer_4test.cxx
Then in the fractals demo I included both of those explicitly
to avoid having to build a new static lib to deal with it and
put them in a subdirectory so as not to mix them up with the
rest of the test source files.
#include "inc/fracviewer_4test.h"
#include "inc/fracviewer_4test.cxx"
The author writes in the sources that this utility is intended
to be modified per use. But the names should not be the same
when the code isn't. I think this is a problem with you C++
guys. Your polymorphism and type safety penchants are diametrical
opposites in cases like this. :-)
Anyway...
I also removed fracviewer.c (not cxx) and it's 'h' file from
the glut lib build folders because it wasn't getting built and in
only causes problems. I still have 'em but they are 'extra'
utilities, not standard ones.
Having problems with multiple or missing definitions of...
agvViewTransform();
... and other agv funcs?
That's what your problem was. Same names, different code.
--
{o}}{O}}
fltk/glut.h
This struct was causing problems. I'm not sure this is the
final fix, but the compiler doesn't like storage classes
("extern") for structs and the struct declaration was missing
the final semicolon after the close brace (as shown).
Was...
// Font argument must be a void* for compatability, so...
//extern FL_GLUT_API struct Glut_Bitmap_Font
//{
// fltk::Font* font;
// int size;
//}
I changed mine to
typedef struct Glut_Bitmap_Font
{
fltk::Font* font;
int size;
};
But in fact this MAY be the name of a specific struct though I've
recompiled from scratch and run as many test files as I can and it
seems ok so far.
---
I added the missing virtual destructors to the classes with virtual
functions.
It's just good form, even if there's zero chance of someone allocating
memory
in a routine that grabs hold of one of those virtual funcs.
AssociationType
AssociationFunctor
TabGroupPager
in the test folder, the editor.cxx file at around line 492 has a typo.
exit/exist.
// if (fltk::ask("File '%s' does not exit. Do you want to create one?",
if (fltk::ask("File '%s' does not exist. Do you want to create one?",
Actually I did want to create an exit but then I noticed an open Window..
-
test/image_file.cxx
This file set has many problems but is well worth the effort to fix it.
These changes don't completely fix it, but it gets it started.
around line 487 add the following copped from fluid code.
#define nosuch_width 16
#define nosuch_height 16
static unsigned char nosuch_bits[] = {
0xff, 0xf0, 0x81, 0x88, 0xd5, 0x90, 0x69, 0xa8, 0x55, 0x94, 0x69, 0xaa,
0x55, 0x94, 0x69, 0xaa, 0xd5, 0x94, 0xa9, 0xa8, 0x55, 0x95, 0xa9, 0xa9,
0x55, 0x95, 0xa9, 0xab, 0x01, 0x81, 0xff, 0xff};
static fltk::xbmImage nosuch_bitmap(nosuch_bits, nosuch_width,
nosuch_height);
size() should be part of the Window class but it's not. This correction
is at around line 512 (after insertions above) in image_file.cxx
// image_window->size(w, h);
image_window->size_range(w,h,w,h);
Other problems include the nifty, but unimplemented ::get(filename);
method for the image classes. ::guess(name) is also missing but also
more than likely a very cool idea. I think it probably tries to find
the file with one extension after another, [png][xpm][...] iteratively.
I have not yet attempted to fix that because I don't know how it works.
fluid designer windows.
A button designed with a down box draws with an up box.
---
fluid designer windows.
A light button appears not to do thin boxes at all.
///
{0}}{0}}
///
test/scheme.cxx
Here's another great one to get working and I haven't nailed it yet myself.
I'm using linux.
Something in fltk/x.h makes playing with X in fluid generated test
code not work and fl_config.h doesn't exist. Is it the name of the
X Window? I could b
[fltk.bugs] cancel that 'exit()' bug rep't.
cancel that 'exit()' bug rep't. My debugger got out of sync with the sources and it wasn't clear that that line wasn't executing. There is no problem with clobbering exit() in fltk2. I'll try to be more careful in the future. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] A few minor issues and one serious one. 'exit()' is an stdlib function.
A few minor issues and one serious one. 'exit()' is an stdlib function.
The bad one is at the bottom. But first a few more notes
In Fluid.
Missing Alt-B menu selection to toggle the widget bin. The accelerator
workd but when the bin goes missing new users will have no idea how to
get it back.
The menu item used to be in the Edit menu.
-
In the test folder.
There's a recurring issue with trying to
#include
This file doesn't exist and I suspect it's left-over code from a
transitional
state between fltk v1.x and v2.x.
A POSSIBLE fix (also moving it to 2.x version) would be to replace
that line with
#include
And then replace the other includes with their fltk counterparts. This
may not always work but it did for the 'connect' test (such as it is).
This...
//#include
//#include
Then becomes this...
#include
#include
And all the Fl_ become
fltk::WidgetNames
---
In the src folder.
There are two versions of a file chooser. There's FileChooser and
file_chooser. And there's a third variation in the compat/FL folder.
Fl_File_Chooser.
This is confusing and could likely lead to more problems than it solves.
--
re. test/image_file.cxx, missing "nosuch_image" definition. That's the name
of the missing definition.
// borrowed from fluid. rs->
#define ns_height 16
#define ns_width 16
static unsigned char ns_bits[] = {
0x00, 0x00, 0x80, 0x01, 0xc0, 0x03, 0xe0, 0x07, 0x80, 0x01, 0x80, 0x01,
0x80, 0x01, 0x80, 0x01, 0x80, 0x01, 0x80, 0x01, 0x80, 0x01, 0x80, 0x01,
0xe0, 0x07, 0xc0, 0x03, 0x80, 0x01, 0x00, 0x00};
static fltk::xbmImage nosuch_bitmap(ns_bits, ns_width, ns_height);
Still having probs with this one thinking an fltk::Box is an
fltk::Symbol! How'd
THAT happen? =-O I think it's declared properly.
In fluid these boxes are fltk::InvisibleBox, even if they have frames
or borders. I'll try replacing a "Box" declaration with "InvisibleBox"
and see what happens.
-
*In fluid designed windows.
When you 'exit(0)' it no longer leaves the application because
this name has used in the fltk system. This is unfortunate
because there is no compile-time warning that the exit(0)
(#include ) is not present.
*
The fix may be simple, but this is a fairly serious problem.
You disagree? Let me put it this way...
It hardly makes sense to do all this extra typing to avoid
name clashes and end up clobbering an stdlib function, does
it? ;-)
I'm seeing lots of improvements in fltk2 over my old fltk,
but this one is _bad, bad, bad._ This should be fixed asap.
--
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] take it or leave it.. :-)
After a hair raising tour of the themes, I decided to get my feet wet
in the test/ demos. :-)
These are now my second impressions.
src/fltk_theme.cxx
Around line 37... Notice that fltk_theme IS defined below.
#if USEX11
extern "C" bool fltk_theme() {return false; /* true? */}
/* Maybe _WIN32 should use the Windows version anyway? It would work!
*/
# include "x11/fltk_theme.cxx"
#elif defined(_WIN32) ...
And x11/fltk_theme.cxx (as it turns out) redefines fltk_theme() at
around line 322
Since we are using X11 and only those who are will enter this logic
branch,
Remove this around line 37 of src/fltk_them.cxx
//extern "C" bool fltk_theme() {return false; /* true? */}
No guarantee that the file will work after this, but at least it will
compile.
-
In x.h the following logic is VERY counterintuitive. When is USE_X11
defined? This
notice that USE_X11 is not simply defined, it's a value. One would
assume that this
file will cause errors unless it loads itself recursively or
something. Should this
be checking "! defined(USE_X11)" instead of simply "!USE_X11"?
#ifndef fltk_x_h
# define fltk_x_h
# if defined(_WIN32) && !USE_X11
# include "win32.h"
# elif defined(__APPLE__) && !USE_X11
# include "osx.h"
# else
# define USE_X11 1
# include "x11.h"
# endif
#endif
-
There are apparently two jpeg_image demos in the test folder. I
removed fl_jpeg_image.cxx test for now. It needs compat/FL stuff and
recurses terribly either before or after I messed with it. But unless
or until the compat stuff is bullet proof this one is a mess.
-
dnd needs a more conclusive demo to show that it's not simply
copy/pasting to/from the (main) clipboard which should not be at all
involved in DND.
-
Re. test/exception.
We Linux folks CAN do structured error handling, by the way. It
involves reading a struct that is cleverly hidden in the mess of junk
above a signal callback in order to extract the pointers to the cpu
registers that are apparently pushed during a setjmp() longjmp().
(Assuming intel cpu type...) By modifying the eip (or xip, for 64
bitters), you can control where the program resumes -- probably to a
normal try - catch block. (Other cpu's? You're on your own.)
I have done this (very reliably) on a 32-bit system, but have not
tested it on 64.
For those not aware of what possibilities this opens up, I should say
that probably the most common usage would be for for testing whether
memory is ours or not, and for checking if a memory location is
write-protected.
for example..
char* memlocation = (char*)test_address;
testid = TEST_READ;
char a = *memlocation; // will dump
if it's not ours. Could be a null ptr, etc.
testid = TEST_WRITE;
*memlocation = a; // will dump
if it's write protected
This method of exception handling (fully taking over handling of
low-level exceptions) is not simply a try - catch or assert function.
It fully handles serious errors the way glib handles double-free, etc.,
but allows us to continue IF we know what caused the error. (So these
are inserted and removed after one-time use.)
My tkf Forths, console version, and QT4 version use it. Hopefully
these are the right links, if you want to get ahead of me on this.
http://rainbowsally.net/tkf/tkf-02.52-installer.tar.gz
// see tkf.f file and find 'except' or even 'obj' might take you
there.
http://rainbowsally.net/tkf/tester/09-07-17/tkf-qt4-test.tar.gz
// I forget where I hid it in this one but I think it's part of the
array of
// signals we intercept. I'd grep 'SIG' and see what shows up.
No apologies for the amaturish C/C++ code. I wasn't interested in a
professional looking C application. I am not accustomed to the
interpreter not being part of the compiler in these systems. I like
it, but it still seems ODD! :-)
Some assembly required, but not much. But this is not for strictly
high-level coders or for newbies. It's the real thing and can hang
very badly if you don't understand what it's about or enjoy living
dangerously.
More later...
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] Woop... one more quick note.
The main reason the 'connect' test didn't work is because the older version made windows so that they automatically started a group so that you don't have to explicitly win->begin() ... win->end(). I had to add those. That old feature is a good one. Not sure if it clobbers any other effects but it simplifies early experience with fluid... works like magic. :-) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] OH! Forgot to mention...
Yeah... Linux wants -lXcursor in fltk2-config for sure. That has come up a few times already as I have messed with the test code and themes (with very little luck in the themes because they are, how shall I say... a good example of why people should do themes in external plugins.) You just compile the lib the way you'd do an executable but with no main() and you link it with LD_FLAGS or whatever they're called like this... BLAH = --shared -fPIC The Position Independent Code (PIC) may not even be too important, but it can't hurt. The 'main()' function is the caller. It works. Not too confusing if you think about it. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] dlopen note & connect fixed (such as it is)
I can't see how you do plug-ins yet but I think you should use dlopen (or OpenLibrary() ) and dlsym() (or GetProcAddress() ) to talk to dynamic libs so that theme developers aren't tempted to monkey with the base code and end up with three (I think it's three) different versions of fltk all competing with each other. The themes (it appears) should be an entirely different project, cooperating with fltk, but not dominating it. I wanted to mention this now, though I'm not up to speed on what you have going on, because I saw a note about dlopen in config.h It's standard stuff. Here's connect (in the test folder). It's fixed but it's not a good demo yet. This should have a light button that turns on and off and sends a message through the timeout queu to another widget that does the talking to whatever it's talking to so that the button itself doesn't appear to hang. But for now... Humble beginnings. :-) At least it compiles. See attached. connect.cxx.tar.gz Description: GNU Zip compressed data ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] more impressions and possible font issue with dynamic shared objects (linux)
fltk2 - more first impressions... then some notes. *Re. fluid2 * default should probably be non-resizable for widgets. Window, resizable maybe ok. The problem is that buttons growing and shrinking along with the rest of the window is ugly. Folks at QT dealt with this by creating 'expanders' that do the growing and shrinking so that the spacing between widgets can change but the widgets themselves remain a predictable size. *Noticed during a non-standard rebuild of the entire system.* There are many missing files from the 'forms' subfolder and the includes are wrong even if those files all existed. These missing files include stuff like Fl_Timer.h (should be upper case H but is '#include'-ed with lowercase) but has calls to functions that weren't defined in 1.6x (dunno about 1.7x, but I don't think they were defined there either) to Fl_FormsBitmap.h, which simply doesn't exist and may never have existed at all. - *Possible font issue with dynamic shared objects in linux. * While reworking this to 32-bit dso's on my linux 64-bitter I noticed that some problems could occur with fonts (undefined references) and some other things. Most of the other stuff is probably related to how I've redone this thing but the fonts I think may be an issue that can come up for yous guys. I had to add these to my fltk2-config script. LD_LIBS add: -lXfont -lfntstubs I also added -Xcursor -Xpm, which is fairly standard stuff on any X system. Likely to solve more problems than it causes, in any case. If folks have probs with dyn libs in linux with missing defs in font-related stuff, it's almost for sure that screwy -lfntstubs file that needs to be linked. And *that's "-lfntstubs" without the 'o'. It's NOT-> "-lfontstubs". * Here's what I see when I 'locate' libfntstubs on my machine. /usr/X11R6/lib/libfntstubs.a /usr/X11R6/lib64/libfntstubs.a Those are needed, apparently for dso's. And I guess that's enough about that. Just a few minor tweeks and I'll be digging into the 'innerds' of this thing and seeing what you've done under the hood. Hope my perspective is somewhat useful, but if not... :-) It won't be the first time. Later... ;-) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] 2.0 bugs & tweeks
Bugz? *Noticed in docs. * The revision numer is wrong on the index page. Revision 17 by Bill Spitzak, Michael Sweet, Craig P. Earls, Matthias Melcher, Nicolas Kaiser, your_name_here *Noticed in fluid. * *Splash screen* disappears too quickly. Give it about 1.5 to 2 seconds. (ALL RIGHT!! The "wrote code" dialog really gets to the top! Another snip for me to study.) *Tooltip timeouts*: Too many tooltips obscure the clickable fields. A suggestion: When we LEAVE a window it should reset the tooltip timeout so we don't immediately get hit with a tooltip, which may obscure the underlying widget that we need to get at. *Input widget*: After inserting the path, set the cursor at the end of the string. When we hit Alt-F+S (Save/Save-As) a file chooser pops up. The input field is initially blank. No prob so far but this is probably when the path should be shown. But when you type the first character, it inserts the path and does NOT set the cursor at the end of the string. The problem this causes is that the user will blast away and only the first character will end up at the end of the path string, all the other characters will appear at the beginning of the string. *The Ask* (question mark) dialog still has the tab order backward. This can be fixed in the *.fl file by reversing the order of the creation of the three anonymous buttons or it can be done in fluid by doing it there. If you need to assure that the enter button has the focus that button may need a name and something like enter_button->focus(); (I don't know the right names for these functions yet because I'm not fully set up. I'll give you guys a break for a while. I need to get set up... :-) Thanks again. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] How to compile fltk as a 32-bitter (with dso's) on a 64-bit machine
Got some bug reports but first...
Build 32-bit libs and apps on a 64-bit machine. Don't mess with
./configure. It'll likely get you nowhere.
_*This is for Linux.*_ I don't write spyware and I don't write apps
that run ON spyware.
*One of the nice features of fltk is the makeinclude file. It keeps all
the variables in one place. So this is going to be (relatively) quite
easy. Try it my way first, then vary it to your liking. Uninstalling
is as simple as deleting the folders and possibly deleting two paths
which we'll get to in a moment.
*
Here's a step-by-step I wrote as I actually did this just moments ago.
1. Create folders (at *least* the lib folder) under your home ~/usr32
folder.
*~/usr32
|-- bin
|-- include
|-- share
`-- src
*
2. run make
This is just to create initial configuration that can be modified. We
don't even care if it chokes as long as it creates the makefiles and
especially the file named 'makeinclude'.
3. Change flags in makeinclude... keep it static linked for now. The
-m32 flag compiles for a 32-bit machine, the -g3 is for debugging info
which can be stripped later... use -O2 if you don't want it.
* # flags for C++ compiler:
was#OPTIM= -O2 -Wall -Wunused
isOPTIM= -m32 -g3 -Wall -Wunused
*
*Be careful when using the tilde macro for your home directory.* You
NEED the space between the -L and the ~/ so the interpreter doesn't
think the tilde is an alpha character. Other than that... it's fairly
simple to add the new lib folder to the search paths.
* # libraries to link with:
add LDLIBS = -L ~/usr32/lib ...
add GLDLIBS = -L ~/usr32/lib ...
*
4. run 'make clean' and 'make' again.
At this point you should get some error messages about missing libs.
They may in fact be on your system but with an extension that LD can't
understand.
For example, the first missing 32-bit lib the linker complained about
in my case was:
*ld: skipping incompatible /usr/lib64/libGLU.a when searching for -lGLU
ld: cannot find -lGLU
*
We expect the extension is *.so.1* or .*so.1.2.xyz*, so we look for it
this way.
find /* -name libGLU.so* <--<< works but kinda overkill and harder
to use right.
Or maybe better yet, and certainly faster, iteratively insert '/*' in
the path until you get a hit.
*ls /lib/libGLU.so*
ls /*/lib/libGLU.so* <--<< mine hits here in less than a second.
ls /*/*/lib/libGLU.so*
*
So I got it. Here's what ls (and find) found.
*/usr/lib/libGLU.so.1.3
/usr/lib/libGLU.so.1
*
These are both the same file. The so.1 links to the so.1.3 and we
need a generic so with no extension.
5. Back at step 1, we created a lib folder. Link the allegedly missing
.so. as .so in the new ~/usr32/lib folder.
For example to link in my missing libGLU
* pushd ~/usr32/lib # changes dir and saves our
old place
ln -s /usr/lib/libGLU.so.1 ./libGLU.so
popd# return to where we're working
*
That was all it took to get mine up and running, but if you have more
32-bit libs that need to be renamed...
6. Repeat from step 4 until you know what they are and where they are.
There's a fair chance you won't have to download a thing, but if you do,
try to install them in the same !/usr32/lib folder and you can play with
it as much as you like without messing with the main system at all.. and
*NONE of this requires SUPER-USER privileges.*
Nice? :-)
Ok, but what have we got now. I have a static lib loaded with debug
info that I don't want to use. I want a dynamic/shared lib.
Step number 7 coming up. This is best done as a script so you can edit
it easily.
7. Go into the installation lib folder (not the ~/usr32/lib folder) and
create this script. It doesn't have to be executable. We'll run it
with bash manually.
file: mk-dso --->
* # a subroutine to handle the nuts and bolts.
mk_dso() # base_name
{
LIBNAME=`basename $1 .a` # remove the file extension for the name
rm -rf tmp# make sure we start clean
mkdir tmp # make a new one
cd tmp# go there
ar -x ../$LIBNAME.a # explodes the lib into all the object files
# this line compiles it all to a shared library in the lib folder above.
g++ -m32 --shared -fPIC -o ../$LIBNAME.so *.o
cd .. # go back up a dir.
cd lib 2>/dev/null# this should fail, but we need to be in 'a' lib
rm -r tmp # cleanup
}
mk_dso libfltk2.a
mk_dso libfltk2_gl.a
mk_dso libfltk2_glut.a
mk_dso libfltk2_images.a
* <---
This file can be run from the commandline as 'sh mk-dso'
Initially you may want to add some 'read key' commands to stop every
once in a while to make sure it's doing what you expect since bash can
be very precise even when we aren't. ;-)
When you're finished you'll have four dso's named...
*> ls *.so
libfltk2_gl.
[fltk.bugs] Everything you never wanted to know about fltk 2.x
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 ' 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 tha
[fltk.bugs] thank you!
Got the fltk 2.x ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] Issues, appending text, and real, async messages to widgets...
Two issues here.
1. Text->append(). I've done this. Pls see details below.
2. and we need another loop that's like a timeout loop but which can
manage malloc-ed memory for passing parameters in messages.
/*1. Text->append("string");
*/
How many times have you needed to append text to the end of a
Text_Display or a Text_Edit widget?
Almost always, right?
Well, both can be handled at once since Fl_Text_Editor inherits
Fl_Text_Display. On a 16 bit machine you'd need to do something else to
get to the end of the buffer, but this will handle a buffer up to 2 gigs
in size for a 32/64-bit machine and is a very simple, fairly easy to
understand implementation.
In Fl_Text_Display.H
*void insert(const char* text); // <-previous existing line in the file
void append(const char* text); // <-rs add
*
In Fl_Text_Display.cxx add this below Fl_Text_Display::insert(...) to
keep 'em sorta in order.
*/*
** Append "text" at the the end of the buffer and show the new position
*/
void Fl_Text_Display::append(const char* text)
{
insert_position(0x7FFF); // insert at end (32-bits max positive
integer)
insert(text);// insert
scroll(0x7FFF, 0); // scroll to end (32-bits max positive
integer)
}
*
/*2. msg_dispatch(Fl_Widget* receiver, uint msgID, uint nParams, ...);
*/
I'm not sure if that parameter list above is the right format for a
message dispatcher but the message dispatcher will need to copy the
parameters to new memory, mark it as not read, and send the message
(faked key presses, faked draw commands, movement, repositioning, etc.)
to the receiver (possibly looked up in a group so only the receiver
gets the message?) in a timeout loop a) to make sure it's asynchronous
and b) to assure that the event loop is running.
When the reciever returns, the memory (queued pointers may be marked as
reusable or freed on the spot. (Haven't thought about multi-thread
issues at all yet, but it must be thread-safe as well...)
This will hopefully GREATLY enhance our ability to do things like resize
and move sub-widgets to where they should appear and how they should act
in new composite classes.
---
BTW, my latest experiments with stay-on-top windows in KDE involve
grabbing a screen shot of the border before switching to override... ick.
But...
maybe.
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] let's call it a ...
Let's call it a bug. :-) Or a bug fix.
Here it is if you want it.
Images left or right of text in buttons. I haven't got my alpha
drawing wired into fltk yet (not sure yet where to insert it) so the
translucent part still looks white. I haven't tested any of these
alignments except FL_ALIGN_LEFT so far.
This is in fl_draw.cxx. Most of the code is new.
// The normal call for a draw() method:
void Fl_Widget::draw_label() const
{
int X = x_+Fl::box_dx(box());
int W = w_-Fl::box_dw(box());
// rs->
int state = 0;
if(align()&(FL_ALIGN_LEFT|FL_ALIGN_RIGHT))
state = 1; // bit 0;
if (W > 11 && state == 1) {
X += 3; W -= 6;
}
if((label_.image) && (label()))
state |= 2; // bit 1
// not planning to mess with align_center, but I might...
// if((align() == 0) || (align() & FL_ALIGN_INSIDE))
if((align() & FL_ALIGN_INSIDE))
state |= 4; // bit 3
// rs->
if(state == 7) {
// It's aligned left or right (or center <- scratch that), and
inside and has
// both text and image. Save and restore coords and draw
// the text and the image separately.
// Need some handles to make the read-only stuff accessible
// and we'll name them in accordance with other usage..
Fl_Image** po_image = (Fl_Image**)&label_.image;
char** po_label = (char**) &label_.value;
int ww = W, xx = X;
Fl_Image* saved_image = *po_image;
char* saved_label = *po_label;
int image_margin = label_.image->w() + 4;
// left aligned? do this...
if(align() & FL_ALIGN_LEFT)
{
// first the text only
xx += image_margin;
ww -= image_margin;
*po_image = 0;
draw_label(xx, y_+Fl::box_dy(box()), ww, h_-Fl::box_dh(box()));
*po_image = saved_image;
// then the image only, at the original coordinates
*po_label = 0;
draw_label(X, y_+Fl::box_dy(box()), W, h_-Fl::box_dh(box()));
*po_label = saved_label;
}
else // if(align() & FL_ALIGN_RIGHT)
{
// first the text, then the image to the right of it
*po_image = 0;
draw_label(X, y_+Fl::box_dy(box()), W, h_-Fl::box_dh(box()));
*po_image = saved_image;
// Then the image, right-aligned! or we'd have to measure the
// length of the text written.
xx = xx + ww - image_margin;
ww = image_margin;
*po_label = 0;
draw_label(xx, y_+Fl::box_dy(box()), ww, h_-Fl::box_dh(box()));
*po_label = saved_label;
}
// else // it's center aligned: default
// {
// xx += 2 * image_margin;
// ww -= 2 * image_margin;
// *po_image = 0;
// draw_label(xx, y_+Fl::box_dy(box()), ww, h_-Fl::box_dh(box()));
// *po_image = saved_image;
// xx = X;
// ww = W - 2 * image_margin;
// *po_label = 0;
// draw_label(xx, y_+Fl::box_dy(box()), ww, h_-Fl::box_dh(box()));
// *po_label = saved_label;
//
// }
}
else
draw_label(X, y_+Fl::box_dy(box()), W, h_-Fl::box_dh(box()));
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] one more thing.. don't copy Qt code for stays on top..
one more thing.. don't copy Qt code for "stays on top".. Those things are buggy. They can re-launch through reboots... at least the Qt3 widgets can. (I forget which version.) But if you don't really understand the entire code-- don't do it. Also, if you've ventured down this path, the _net_wm_stays_on_top Atom/message is apparently for the 'test' in qdesigner-- only. I had to delete/rename my test executable to get it to quit popping up in triplicate! Don't. That's my opinion, anyway. There must be a way of putting a frame on a splash screen after creation (reparent, hints from a splash screen, something like that), and that's probably what we should be doing. I'll shut up for a while now. ;-) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] bugz? You want bugs? :-)
With the exception of Erco's work and one other (who no longer works
with fltk, apparently), most of the s/ware I've seen linked at the fltk
forum has been, how shall I say?
It's like... Like mine. Half baked, incomplete, or just screwy.
Should I make bug reports about other people's work? It's linked here
at the fltk page. I think not.
But this, I think is your problem. What I want to report is that it
took me about two hours (so far) to find stuff to play with, ideas to
explore, and again, it's Erco's work that has been the most
inspirational. Beautiful stuff. (But the tree widgets are too
complicated... I'd remove the preferences or put them in one of the
main files, for starters -- and I'd fix foo.cxx so that it gets two
parameters for it's printf("%s,%d") requirement... instead of just
one. No biggie.).
But wait! It has been suggested to me that I check my email settings.
I don't WANT email. I don't WANT to be a developer (been there and
done that and it's usually a bad fit between my crazy exploratory
"computer research v. computer science" approach. So all I want to do
is challenge the developers here... to raise questions, suggest new
approaches, and DEMONSTRATE the functionality, if not the
implementation of some of my "mad science".
Try this! This time for sure...
1. We need a better way to get control of subwidgets in new classes.
Just combining them into a group is not adequate. This may be possible
without breaking into the main fl_event handler, but I haven't seen how
to do it yet, somy approach is to really take over the fl_event
handler. (Fl::handle(int).)
2. We need an easier and BETTER way to draw boxes; one that can be used
to copy/clone themes from other applications easily. The most straight
forward way to do this would be to take a screen shot of the other
application(s) and use those graphics (encoded with alpha) to print box
characters (yes, it's very retro-- character graphics) which can be
accomplished with a simple graphic editor and an alpha converter.
3. We need a way to easily pass messages to widgets through the timeout
loop. Some functions won't work until the event loop (Fl::run()) is
running. (This is not hard, but it should be a documented, standard
feature.)
4. We need an icon view.
5. We need something like Erco's treeview widgets, but with a simpler
interface. Perhaps the ugly part can be hidden somehow -- it's really
a very very nice implementation with the exception of how keys are (or
aren't) handled and some limitation on where one can click, which I
think also traces back to the problem of breaking into the main loop to
grab events meant for other widgets.
6. We need a way to control widgets (and again the main loop is the
suspect) so that they can be animated in the fluid designer -- if not
connected!! (I think it was a terrible mistake for Qt4 to quit
animating buttons.)
I hope this message is on topic. :-)
My bug report is this, however.
7. Your email list is too hard to get at. It should be publicly
viewable by those of us who prefer to remain anonymous, but who want to
play with an excellently designed toolkit with incredibly simple and
easy to understand examples, and that shows real-life X windows sample
code that you can't find anywhere else on the net. (But you need to
include debugging info to see it work.)
8. So I have one more suggestion. And this may be way off target since
I don't even use the stock installer or makefiles. There should be an
option to compile with debug info in one's own home folder. And if you
don't want your test apps to be a meg each, compile fltk as dso's.
That too is what I do, but it's up to you guys. :-) I've got my own
plans. I'd like to think I can offer some ideas to you guys, but it
seems like development is pretty much dead on the 1.xx versions. I
diffed 1.6x and 1.7x or something and there were almost no changes.
So this raises some questions as well. Where can I get 2.x? Do I even
want it? (I'm curious about the gtk+ theme but I'll bet it's one of
those hand drawn things also.)
Go to the fltk page and see if you can find version 2.x. You've got
only 2 hours... better get started. :-)
And again, I do NOT want to be a developer. You guys have to have
pretty thick skin to take all this criticism, and I just can't handle
the negativity... ;-)
In conclusion. BREAK INTO THE MAIN EVENT LOOP. You'll be glad you did.
At least I think so... ;-) I'm going to try to get the combo box
clone (Input_Choice) to work (and to position and resize correctly) by
way of reading events (either in the group widget or if necessary, in
the main fl_event loop).
And concluding my conclusion: I truly do thank you for this software.
It's the most fun I've had in years.
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] I just got a note about my posting to the wrong place.
I am a member of fltk, but I don't see another way to post to anyone. If you don't like these posts as bug reports, fire back another email, maybe a warning... with a good email address to post to. ;-) FLTK rocks. I know it's old, but I was messing with Qt for a while and it's just so complex and locked-in I'll continue to inform you of bugs (mostly my own so far) until such time as I find a better place to send my own error reports and repair tips to. ;-) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] some fun snips to play with..
Just some notes. Fun stuff if you don't know about this yet.
But a note about X Window lists first.
I didn't include the demo code because it LOOKS more dangerous than
it is. The thing is, you can send (at least KDE) to the BOTTOM of a
window list which will remove all your taskbar stuff, and docked
windows, leaving you with a full image of the desktop. And this
situation persists until you can change focus. I can do this
easily, but someone with a different setup might not be able to find
a window to focus on, though I'd think clicking in the upper left
corner might do the trick because I've noticed that there are
several windows there, that are only 1 x 1 pixel !!
So let's start with the scary one. Then some minor toys to play with
follow.
*/// //
/// X Window lists.
// How do I get a list of windows that I can use to set
// zorder with?
}//
...
Window root = RootWindow (display, screen);
Window dummywindow;
Window *children;
unsigned int nchildren, i;
XWindowAttributes attr;
nchildren = nTopWindows = 0;
XQueryTree (fl_display, root, &dummywindow, &dummywindow, &children,
&nchildren);
for (i = 0; i < nchildren; i++)
{
if (XGetWindowAttributes(fl_display, children[i], &attr) &&
(attr.map_state == IsViewable))
{
Window aTopWindow = children[i];
// do something with aTopWindow, maybe add to a list.
nTopWindows ++;
}
}
XFree(children);
// do something with nTopWindows or copied list of top windows.
}//
/// //
/// key bindings can be used to manipulate a text
/// edit widget. The bindings are listed in
/// Fl_Text_Edit.cxx and the parameter 'c' will be
/// the control/shift or whatever mask.
Example:
}//
// Adds functions to an already existing Fl_Text_Editor widget so it's
fluid-
// compatible. Init with aClass(objName); where 'objName' is a
Text_Editor named
// in fluid.
class aClass
{
public:
aClass(Fl_Text_Editor* text_editor);
void append(char* s);
Fl_Text_Editor* te;
};
aClass::aClass(Fl_Text_Editor* text_editor)
{
// must be done after make_window runs so the object
// really exists...
te = text_editor;
}
void aClass::append(char* s)
{
// in order to make sure we're at the end of the buffer we
// precede appending with a call to simulate ctrl-end and
// to make sure it's visible after appending, we ctrl-end
// again afterward.
Fl_Text_Editor::kf_ctrl_move(FL_End, te);
te->buffer()->append(s);
Fl_Text_Editor::kf_ctrl_move(FL_End, te);
return;
}
/// //
/// No hang on exit(0)
// Under some circumstances (creating objects on the
// fly?) the window may not be able to close on its
// own. If this is a problem in an application...
#include // SIGKILL
#include // exit();
// not sure where getpid() comes from. maybe
void cbQuit(Fl_Button* b, void* params)
{
kill(SIGKILL, getpid());
exit(0);
}
*
I haven't checked if this leaves memory leaks or anything but it does
clean 'em out of the process table (like xkill or ksysguard or
gnome-system-monitor).
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] I think I misspoke...
I think I misspoke... The init of the buffer is at the end of the inits in the Fl_Text_Display.cxx file, not in the class. I think I said "class", but that wouldn't do any good. :-) Workin' on TopMost or Stays_On_Top windows with borders currently. Got a routine to read all the top windows in the display into a list at least (for z-ordering in linux). It's based on xkill code from X.org. I'll be in touch... Unless... unless you guys already have that figured out? The flags in 1.63 are a mess and we either have to do an X reconfiguration or use another window to generate creation 'hints', I think. Anyway... here I go again... ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] Text_Edit/Display init bugfix and data compression for embedded image data, etc.
Text_Display is inherited by Text_Edit and both crash because the mBuffer is not initializing when the class is created. At the END of the class, after all the other stuff is set up add something like this. Fl_Text_Buffer* tmp = new Fl_Text_Buffer(); // default size is fine. --- Here are some mods. - Fl_PNG_Image that can also write PNG data to a file. This has not been cleaned up yet, but it works on my system for now. I'll clean it up later. - zData for compressing data in memory. This makes files comparable to gzip, but doesn't store permissions, etc. It's mainly for compressing graphics to embed in files. The resulting file size may be a fifth the size of one created by fluid. The only dependency on fltk for this class is the Enumerations.H file, and even that is only for the typedef of 'uchar'. - zImage is what it's about. The small (32 bytes) header is enough to generate fltk image files. See the header definitions to figure out what it does and how to extract the w(), h(), and d() parameters from the headers. Hopefully the syntax will be similar enough to fltk standard stuff that usage will be fairly intuitive for old-timers. See attached files. 01-PNG_Image-read-write.tar.gz Description: GNU Zip compressed data 02-zdata-zlib-for-embedded-data.tar.gz Description: GNU Zip compressed data 03-zImage-image-data-compression.tar.gz Description: GNU Zip compressed data ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] not a bug.. more alpha colors testing.
It seems best NOT to put the alpha rendering routine in the main
draw_image loop after all. It can mess up some stuff like fluid. At
least it does right now.
So as a C = A + B function it's more predictable and still very useful,
though this test is a bit funky.
As you can see in [A] the bottom line and especially the leftmost pixel
is 'add'ing to the color of the background.
This is built on top of an ordinary button, it's just the 'image' data
created by
1. o->hide() on the original button to get a shot of the background
with fl_read_image()
then
2. o->image() using a png image imported from SVG.
Here's the latest alpha adder, such as it is.
->
typedef struct
{
uint x, y, w, h, size;
}WIDGET_RECT;
void get_rect(WIDGET_RECT* a, Fl_Widget* o)
{
a->x = o->x();
a->y = o->y();
a->w = o->w();
a->h = o->h();
a->size = a->w * a->h;
}
void get_rect(WIDGET_RECT* a, Fl_RGB_Image* o)
{
a->x = 0;
a->y = 0;
a->w = o->w();
a->h = o->h();
a->size = a->w * a->h;
}
Fl_RGB_Image* get_screen_image(Fl_Widget* o, uchar alpha)
{
WIDGET_RECT r;
get_rect(&r, o);
uchar* array = fl_read_image(0, r.x, r.y, r.w, r.h, alpha);
Fl_RGB_Image* tmp = new Fl_RGB_Image(array, r.w, r.h, 4);
return tmp;
}
typedef union
{
struct
{
uchar red;
uchar green;
uchar blue;
uchar alpha;
}byte;
void* cref;
}PIXELS;
#include
Fl_RGB_Image* add_alpha_images(Fl_RGB_Image* image_1, Fl_RGB_Image*
image_2, int x_where, int y_where)
{
WIDGET_RECT r;
get_rect(&r, image_1);
Fl_RGB_Image* tmp = image_1;
Fl_RGB_Image* fg = image_2;
uchar* array = (uchar*)malloc(r.size * 4);
memcpy(array, image_1->array, r.size * 4);
Fl_RGB_Image* bg = new Fl_RGB_Image(array, r.w, r.h, 4);
bg->alloc_array = 1;
int X = x_where; int Y = y_where; int W = fg->w(); int H =
fg->h();
int bgW = bg->w(); int bgH = bg->h();
// clip
if((W + y_where) > bg->w())
W = bg->w() - y_where;
if((H + x_where) > bg->h())
H = bg->h() - y_where;
//...
if((W <= 0) || (H <= 0))
return 0;
PIXELS acc;
PIXELS* src = "">
PIXELS* pdest = (PIXELS*)bg->array + X + (Y * bgW);
PIXELS* dest;
PIXELS s;
PIXELS d;
uint alpha, beta;
for(int y = 0; y < H; y++)
{
dest = pdest;
for(int x = 0; x < W; x++)
{
alpha = src->byte.alpha + 1;
beta = 260 - alpha;
s = *src;
d = *dest;
acc.byte.red = (((s.byte.red*alpha) + (d.byte.red*beta)) >>
8);
acc.byte.blue = (((s.byte.blue*alpha) + (d.byte.blue*beta))
>> 8);
acc.byte.green = (((s.byte.green*alpha) + (d.byte.green*beta))
>> 8);
acc.byte.alpha = 255; // or master alpha?
*dest = acc;
src++;
dest++;
}
pdest += bgW;
}
return bg;
}
<-
The code is probably a mess. I'm just still trying to wrap my brain
around C/C++. I'm a Forth fan and it's just soooOO... different.
:-) Not sure I'm releasing memory where I should and I'm not sure how
these C++ objects delete themselves or when they do it.
Still having lots of fun.. losing hair and cussing like wild
sometimes, but it's coming along. :-)
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] not a bug... alpha pix for fl_draw_image
[Woop I might have accidentally sent this without the file. Sorry, if
you get two of these emails.]
Still getting up to speed, but I think my system is diverging from the
norm about now. The changes I can remember are listed at the bottom.
Got this...
This is with one brown gradient drawn by fltk mixed on a black
background with alpha = 255 to 0 (linear) with a SVG exported alpha
drawing 'add'ed on top. The white borders of the windows are alpha=255
and the turquoise filled area is from the SVG image with transparency
gradient. It looks right or that color of background(s).
Still testing, but here's how we do it...
// This is in currently in my fl_draw_image.cxx and will be
rewritten in ASM when
// it's fully tested.
-->
// H
void visit_fl_draw_image(){}
// for little-endian
typedef union
{
struct{
uchar red;
uchar green;
uchar blue;
uchar alpha;
}byte;
uint rgba;
void* cref;
}Rs_ABGR;
// C++
static void xrgb_converter(const uchar *from, uchar *to, int w, int
delta)
{
// intel 386 -rs
// INNARDS32((from[0]<<16)+(from[1]<<8)+(from[2]));
Rs_ABGR* psrc = (Rs_ABGR*)from;
Rs_ABGR* pdest = (Rs_ABGR*)to;
Rs_ABGR src_pixel;
Rs_ABGR dest_pixel;
Rs_ABGR s;
Rs_ABGR d;
Rs_ABGR acc;
uint alpha;
uint beta;
//# define INNARDS32(f) \
// U32 *t = (U32*)to; for (; w--; from += delta) *t++ = f
delta = delta >> 2; // 4 bytes at a time
for(; w--; psrc += delta)
{
// multiply by alpha + 1 to shift result into next higher byte
// and mask off the low byte of the results for both r+b (one
// calculation) and g (another calculation).
// Then shift the result back down and set new alpha (255) for
// the result.
src_pixel.rgba = (psrc->rgba &0xFF00FF00) +
psrc->byte.blue + (psrc->byte.red << 16);
alpha = src_pixel.byte.alpha + 1; // shifts bits into next higher
byte
beta = 256 - alpha; // used to add background image,
no XOR/NAND.. yet
dest_pixel.rgba = pdest->rgba;
s.rgba = (src_pixel.rgba & 0x00ff00ff) * alpha;
d.rgba = (dest_pixel.rgba & 0x00ff00ff) * beta;
acc.rgba = ((s.rgba + d.rgba) & 0xff00ff00) >> 8;
s.rgba = (src_pixel.rgba & 0xff00) * alpha;
d.rgba = (dest_pixel.rgba & 0xff00) * beta;
acc.rgba += ((s.rgba + d.rgba) & 0x00ff) >> 8;
acc.rgba = 0xff00 + acc.rgba; //(acc.rgba >> 8);
*pdest++ = acc;
}
}
<--
// other stuff I can remember...
Turned colormap off in config.h. Not sure if this made any difference
thought.
changed alpha drawing in demo because this alpha is additive with
colors behind. It was showing to dark.
Set for 32-bit little-endian INNARDS.
fl_draw_image.cxx.tar.gz
Description: GNU Zip compressed data
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
