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 <fltk/run.h>
instead of <FL/Fl.h> and renaming the classes from
Fl_<Class_Name> to fltk::<ClassName>
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<Funcname> 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 be addressed as a ::Window, I think....
Nevermind...
This is around line 1. I disabled both includes.
//#include <fltk/fl_config.h>
//#include <fltk/x.h>
Around line 20, which starts out like this, I added some junk to
just get it to compile. It's not right yet.
#ifndef _WIN32
/// rs->
#include <string.h> // strncpy()
typedef ulong Window;
// Stolen from KDE!
#include <X11/X.h>
#include <X11/Xlib.h>
#include <X11/Xutil.h>
static Display* fl_display;
static Window fl_window;
static int fl_screen;
static int Xvars_inited = 0;
static XVisualInfo fl_visual; // the whole tamale.
void fl_open_display()
{
if(Xvars_inited) return;
Xvars_inited++;
fl_display = XOpenDisplay(0);
if(! fl_display) exit(1); // error
// register various protocols here.
fl_screen = DefaultScreen(fl_display);
// we can make a window, set new error handler and then...
// XVisualInfo fl_visual is defined above
int dummy;
info.visualid = XVisualIDFromVisual(DefaultVisual(fl_display,
fl_screen));
XGetVisualInfo(fl_display, VisualIDMask, &fl_visual, &dummy);
// fl_colormap = DefaultColormap(fl_display, fl_screen);
fl_window = RootWindow(fl_display, fl_screen);
// that's everything we need for most generic X calls
}
#include <fltk/Preferences.h>
class Fl_Config : public fltk::Preferences
{
public:
Fl_Config(char* name);
// returns 0 on success
// int set(char* key, char* value);
// get human readable error report
char* strerror() {return _strerror;};
private:
char _strerror[256];
};
Fl_Config::Fl_Config(char* name) : fltk::Preferences(SYSTEM, "config",
name)
{
sprintf(_strerror, "Unknown error (if any???)");
}
/// <-rs
That puts you (me) somewhere around line 75 now.
And around line 134 or so... rough guess, I disabled one line as
follows.
if ( (r = flconfig.set("default/scheme", scheme)) ) {
fprintf(stderr, "%s: Error- Cannot set default scheme.\n", pname);
// fprintf(stderr, "%s: Error- %s.\n", pname, flconfig.strerror());
exit(3);
The missig class that I guessed at is clearly related to the
fltk::Preferences class, (the code uses fltk style paths as identifiers)
so... someone familiar with that stuff could probably easily take it
over the top from here. The X related part of the code will now work.
----------------
Xforms objects were something like 108 bytes that they hung additional
(SPEC) structs on. FLTK v. 1 was about 96 bytes (if it's a 32-bit app).
}
}
You're now down to about half that. Something like 56 bytes. (The
code part is one-time overhead, so I'm not counting that.)
You are getting a lot of bang for the buck now.
So...
It may sound like I'm very negative about this new version at times, but
I'm not. I'm just trying to be honest about what still needs to be polished
up and/or that I do in my own personal version.
Report card? Still A++ guys. Let's shoot for A+++.
_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs
