Re: [fltk.general] errow message window

[Greg Ercolano]

Paul Rogan wrote:
> my application can (and does!) throw multiple err messages out to the same 
> 'current' error window, which i am happy about for support purposes as i can 
> better envisage the 'path' back from root cause and subsequent effects. 
> Sometimes however the insert calls mean the first messages are pushed up off 
> the surface and a click and cursor arrows are needed to view all content. I 
> would like to know if the window and its multiline input can be made to grow 
> with insert calls, or should i just keep to a simple browser option instead 
> of multiline inp?

Not sure I follow this completely, but it kinda sounds like you're
using an Fl_Multiline_Input and want to be able to append lines
to it using insert(). I think that would be:

fmi->position(fmi->size());
fmi->insert(new_text);

We should probably add an Fl_Input_::add() method to Fl_Input_..
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] How to draw multiple images on same canvas

[Greg Ercolano]

Kim Nguyen wrote:
> ..bode and hankel..

..for those that are wondering:

http://en.wikipedia.org/wiki/Bode_plot
http://en.wikipedia.org/wiki/Hankel_function

Regarding the problem, yes, some code snippets please.
I can't tell what's going on from the description.

I don't see reference to a draw() function here, so I'm
wondering: is the actual graph drawing code being done
from a draw() function (good), or from a callback (bad)?

In fltk, drawing functions like fl_line(), fl_rect(), etc.
can only be reliably called from an overridden draw() function.
(see below).

If I were implementing a window with multiple graphs,
I'd make each 'graph type' a separate widget class,
each deriving from Fl_Box, eg:

class BodeGraph : public Fl_Box {
..
public:
BodeGraph(int X,int Y,int W,int H,const char *L=0) : Fl_Box(X,Y,W,H,L) {
}
void draw() {
Fl_Box::draw();
// YOUR BODE GRAPH DRAWING CODE GOES HERE
}
};

class HankelGraph : public Fl_Box {
..
public:
HankelGraph(int X,int Y,int W,int H,const char *L=0) : Fl_Box(X,Y,W,H,L) {
}
void draw() {
Fl_Box::draw();
// YOUR HANKEL GRAPH DRAWING CODE GOES HERE
}
};

[..]
void main_window() {
Fl_Double_Window *w = new Fl_Double_Window(..);
w->begin();
BodeGraph   *bg = new BodeGraph(..);// make the bode graph
HankelGraph *hg = new HankelGraph(..);  // make the hankel graph
w->end();
}

I think this is what you;d want in a general way.
There's not really many other ways to do it, actually.

Any kind of callback that needs to affect drawing
should (1) modify variables that the draw() function refers to, then
(2) call redraw() and (3) return.

The redraw() call will schedule FLTK to redraw the canvas on the next
iteration of the main event loop, Fl::run().
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] FLTK as a game library

[Greg Ercolano]

Robert Arkiletian wrote:
> On Mon, Jan 3, 2011 at 10:16 PM, CIB  wrote:
>> Yeah, I'm going to use BSD sockets. I have quite some experience with them 
>> from python, and I don't mind the API too much. I'm likely going to add my 
>> own abstraction with something like RPCs on top though.
>>
> 
> you can use add_fd to listen to sockets without multi threading in fltk.
> 
> http://fltk.org/doc-1.1/Fl.html#Fl.add_fd
> 
> The main gui event loop handles listening to the socket.
> I have used it in simple games like network battleship. But I used
> pyFLTK (python version of fltk)
> 
> You can see some examples at Greg's site
> http://seriss.com/people/erco/fltk/#add_fd

Yes.. and there's a 'current' version of this example in 1.3.x svn
in the examples/howto-add_fd-and-popen.cxx which, by coincidence
I recently modified to support both unix and windows.

In case you don't have access to SVN, here's a paste of the
example (with GPL headers removed).


#include 
#include 
#include 
#include 

#ifdef _WIN32
#  define PING_CMD "ping -n 10 localhost"   // 'slow command' under windows
#  ifdef _MSC_VER
#define popen _popen
#define pclose _pclose
#  else /*_MSC_VER*/
#include  // non-MS win32 compilers 
(untested)
#  endif /*_MSC_VER*/
#else
#  include 
#  define PING_CMD "ping -i 2 -c 10 localhost"  // 'slow command' under unix
#endif

// GLOBALS
FILE *G_fp = NULL;

// Handler for add_fd() -- called whenever the ping command outputs a new line 
of data
void HandleFD(int fd, void *data) {
  Fl_Multi_Browser *brow = (Fl_Multi_Browser*)data;
  char s[1024];
  if ( fgets(s, 1023, G_fp) == NULL ) { // read the line of data
Fl::remove_fd(fileno(G_fp));// command ended? disconnect 
callback
pclose(G_fp);   // close the descriptor
brow->add(""); brow->add("<>");   // append msg indicating 
command finished
return;
  }
  brow->add(s); // line of data read? append to 
widget
}

int main(int argc, char *argv[]) {
  Fl_Window win(600,600);
  Fl_Multi_Browser brow(10,10,580,580);
  if ( ( G_fp = popen(PING_CMD, "r") ) == NULL ) {  // start the external 
unix command
perror("popen failed");
return(1);
  }
  Fl::add_fd(fileno(G_fp), HandleFD, (void*)&brow); // setup a callback for 
the popen()ed descriptor
  win.resizable(brow);
  win.show(argc, argv);
  return(Fl::run());
}

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Linker error with images...

[Greg Ercolano]

Ian MacArthur wrote:
> Percy wrote:
>> And I am linking these libs:
>> fltkd.lib fltkimagesd.lib fltkpngd.lib comctl32.lib
> 
> I was gong to say that you seem to be missing the zlib stuff, but I see 
> Matthias already replied.
> 
> One thing you might want to watch out for is link order; generally 
> speaking, it is Good Form to list the libs that provide a function 
> *after* any objects or other libs that *use* a function - this allows 
> the linker to make some optimizations for things it knows are not needed 
> later...

Since compile/link flags comes up so much for VS, I wonder if we
shouldn't include an example list of compile/link flags in README.win32.

Possibly too, a hint in README.win32 to look at the "Build Log" for
various FLTK test programs to see what the actual compile/link flags 
are, eg:

 Very simple FLTK app: See "Build Log" for test/hello
FLTK app using images: See "Build Log" for test/pixmap_browser
FLTK app using OpenGL: See "Build Log" for test/glpuzzle
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] rubberbanding cursor

[Greg Ercolano]

Matthias Melcher wrote:
> On 28.12.2010, at 06:50, Sam wrote:
>> Also, a vector-type graphics would use XY coordinates origin in the lower 
>> left corner. [..]
> 
> [..] the FLTK "slow" graphics calls also support a 2D transformation matrix.

I've never noticed our 2D matrix stuff before.. cool!

Giving the docs a quick look, I take it the matrix transformation
functions only affect a subset of the fl_xxx draw functions, is that
the case? Namely:

fl_begin_polygon()
fl_vertex()
fl_curve()
fl_arc()
fl_circle()
..a few others..

I'm looking at the 1.3.x docs on "Drawing Things", subsection
"Drawing Complex Shapes" which seems to list functions affected
by the 2D matrix all grouped together.

Correct me if I'm wrong, I take it anything /not/ in that list
is unaffected by the 2D matrix, eg:

fl_line()
fl_rect()
fl_draw()
..etc..

..is that correct?

If so, maybe the reference docs for these functions should refer
to these groupings, or at least mention if the functions are affected
by the 2D matrix or not, as it seems unclear (to me at least)
when reading the reference docs for e.g. fl_arc() and fl_draw()
that one is affected by the 2D matrix, and the other is maybe not.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] rubberbanding cursor

[Greg Ercolano]

Matthias Melcher wrote:
> On 28.12.2010, at 06:50, Sam wrote:
>> Also, a vector-type graphics would use XY coordinates origin in the lower 
>> left corner. [..]
> 
> [..] the FLTK "slow" graphics calls also support a 2D transformation matrix.

I've never noticed our 2D matrix stuff before.. cool!

Giving the docs a quick look, I take it the matrix transformation
functions only affect a subset of the fl_xxx draw functions, is that
the case? Namely:

fl_begin_polygon()
fl_vertex()
fl_curve()
fl_arc()
fl_circle()
..a few others..

I'm looking at the 1.3.x docs on "Drawing Things", subsection
"Drawing Complex Shapes" which seems to list functions affected
by the 2D matrix all grouped together.

Correct me if I'm wrong, I take it anything /not/ in that list
is unaffected by the 2D matrix, eg:

fl_line()
fl_rect()
fl_draw()
..etc..

..is that correct?

If so, maybe the reference docs for these functions should refer
to these groupings, or at least mention if the functions are affected
by the 2D matrix or not, as it seems unclear (to me at least)
when reading the reference docs for e.g. fl_arc() and fl_draw()
that one is affected by the 2D matrix, and the other is maybe not.

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] fltk and Fluid under Ubuntu 10.04 lts

[Greg Ercolano]

Derek Prowse wrote:
>>  On my system, 'apt-file list fluid|grep bin'
>>  shows me fluid is installed in /usr/bin/fluid:
> 
> This is fascinating Greg. I installed apt-file and ran this
> exactly as you did and get the exact same result:
> 
>  # apt-file list fluid | grep bin
>  fluid: /usr/bin/fluid
>  fluidsynth: /usr/bin/fluidsynth
>  libfluidsynth-dev: /usr/include/fluidsynth/seqbind.h
> 
> When I go to usr under /home/derek/usr/bin fluid does not exist in bin.

If you have a 'usr' directory in your home dir, that's odd.


> Is there another /usr/bin/ ?

No, there's only one /usr/bin.
That'd be in the 'usr' directory off the root of the drive.

/home/derek/usr/bin is totally different; that's a 'usr' directory
in your home directory.

> Thanks for your help. I guess I'm just going to have to go back to windoz for 
> this.

This stuff is the same on windows and mac too; linux is no different.

In windows the equivalent situation would be
c:\usr\bin vs. c:\home\derek\usr\bin which again would be
different dirs for the same reasons. Unix is the same, just
without the "c:", and the slashes go the other way.

Don't mix up relative paths (usr/bin) with absolute paths (/usr/bin)
The leading slash is what makes the difference.

Try opening a terminal window and running 'which fluid'
to see where fluid is installed; it might be in your PATH already.

Assuming fluid is in your path, you should be able to change
the Exec= line to just read Exec=fluid
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] fltk and Fluid under Ubuntu 10.04 lts

[Greg Ercolano]

Derek Prowse wrote:
> I am at a loss for now.

On your system it may have installed in a different place
from mine, as you're on 10.04 and I'm on 8.04.

On my system, 'apt-file list fluid|grep bin'
shows me fluid is installed in /usr/bin/fluid:

# apt-file list fluid | grep bin
fluid: /usr/bin/fluid
fluidsynth: /usr/bin/fluidsynth
libfluidsynth-dev: /usr/include/fluidsynth/seqbind.h

Similarly, determine where the fluid binary is installed
on your system, and modify the Exec= command accordingly.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] fltk and Fluid under Ubuntu 10.04 lts

[Greg Ercolano]

Derek Prowse wrote:
> I have all installed with Synaptic Package Manager, I didn't do
> anything fancy, but I can't launch FLUID from Applications/Programming/ menu.
> I get an 'Error' message box with this disheartening information.

I just tried 'apt-get install fluid' (the equiv of using Synaptic)
on Ubuntu 8.04 and can replicate.

Yes, it seems the folks who made the 'fluid' package did it incorrectly.

I don't think any of us on the FLTK team manages that package;
someone downstream from us did it.

Anyway, problem seems to be with this file:

$ more /usr/share/applications/fluid.desktop
[Desktop Entry]
Name=FLUID
Comment=FLTK GUI Designer
TryExec=fluid
Exec=cd %D && fluid %F  <-- PROBLEM HERE
Icon=fluid
Terminal=false
Type=Application
MimeType=application/x-fluid
Categories=Development;GUIDesigner;


In short, to solve, I think you can just:

1) Edit /usr/share/applications/fluid.desktop in a text editor

2) Change that "Exec=" line to instead read: Exec=/usr/bin/fluid

..then try Applications -> Programming -> FLUID again, and it should 
work.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Using FLTK without a Persistant GUI

[Greg Ercolano]

imacart...@gmail.com wrote:
> Though fork() per se will not work on win32 either - though you can of 
> course exec another process in a way that's analogous...

Yes; CreateProcess() has [excessively] numerous flags
that can be used to achieve very similar behavior to the
traditional unix fork/exec combo.

There's also ways to get exit codes, and test to see
if the process exited (both blocking and non-blocking).
All Win32 API stuff, but it works well. You just have to
read a hell of a lot of Win32 API documentation. For instance,
if you read the CreateProcess() docs, you'll find this exponentially
spans outward into separate docs on structures within structures.
Worth reading all that stuff. As much as I dislike the Win32 API design,
it is somewhat well documented, and seems to 'behave' if you play by
their specific rules, and don't try to 'intuit' too much.

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Using FLTK without a Persistant GUI

[Greg Ercolano]

John Hoare wrote:
> Perhaps maybe it would be better to follow Greg Ercolano's suggestion,
> and fork() off another binary that handles the videoStream(), and
> communicates to it through a pipe.

Do you need a pipe? If the data is coming from a device,
maybe the main program can pass the (separate) video program
the name of the device to read so it can get the data itself.

This would keep things modular, and allow even a script to
monitor the robot's data.

Otherwise, yes, a pipe could work. Shared memory might be
another option.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Using FLTK without a Persistant GUI

[Greg Ercolano]

John Hoare wrote:
> Perhaps If I give you an example of how my library is used, you (or
> someone) can give me a better way to achieve this.
> 
> Picture* pic = robot.takePicture("color");
> pic->show(); //blocks until image is closed
> 
> This code should take a picture from the robot, and then open a display
> window, and display the picture. From my understanding, this should be
> easy: open a window, and then call Fl::run(), which will return once the
> image is closed.

This sounds a lot like a normal dialog where the program
doesn't proceed until the dialog closes, eg:

dialog = new YourPictureDialog();
dialog->takePicture();
dialog->show();
while (dialog->visible()) {
Fl::wait(.10);
}

..this way the program can then do other stuff.

The other way to do this would be to make a separate program
and run it from the main app. Assuming there's little interaction
between the two, this might be reasonable. Then the main app
can choose whether to wait for the separate program to finish,
or continue running doing other things. I'd think that would work
well for realtime video as well. This way you can give that separate
process higher priority for realtime playback (if needed).

You can probably do it with threads too, where the thread
provides the data to a common area that the main thread can
"pixel blit" into the video window. Basically a 15 or 20
ticks-per-second timer can read the common area for new data
and blit it to the screen. Use locking to keep the data safe
from races.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] How to create new theme for fltk?

[Greg Ercolano]

Matthias Melcher wrote:
> On 19.12.2010, at 17:36, Sparkaround wrote:
> 
>> It is a good idea. But does this break the license of fltk? What should I do 
>> to fit the license?
>> Only need make the source code of  MyFl_** availabe to public or the whole 
>> application based on "MyFl_**". I hope the application can be  linked to 
>> fltk statically.
> 
> If you change FLTK itself, you must make the changes public. If you add your 
> own widgets, even when they are "inside" the library, you do not need to 
> publish anything. You can link statically, it's a specific addition to the 
> library because that's what the original developers wanted to do for their 
> commercial apps.

I think he's commenting about the idea of making a copy of an existing
FLTK widget /code/ in his project's directory so that he can then 
modify it.
I think he would then need to make that new code public.

The way I read the license, I think you'd need to make the new widget 
code
public. ie. post a patch here on the group if it's something you think 
only
a few people could use, or if you think it could be added to FLTK, post 
an
STR as an RFE.

I did this myself when I added ANSI XTERM sequence support to Fl_Browser
so that one could change colors and fonts of text within a single line
of an Fl_Browser. This was a weird mod probably not useful to add to 
FLTK
itself, so I posted it on the group as a patch to make it "public".
(fltk.development, Subject: "Fl_Browser mod for ANSI" in March 2008)

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] How to create new theme for fltk?

[Greg Ercolano]

Sparkaround wrote:
> And Fl_Text_Display use fl_rectf so that I can't set background image for it 
> without rewriting plenty of draw methods. And it will be a difficutl to 
> update these draw methods if fltk updated.

I suppose you could grab a 'snapshot' of the fltk widget in question
(just the .cxx and .H file for the widget in question),
and make it part of your code base, renaming it to something like
MyFl_Text_Display, then hack the draw() code as you like.

This way even if FLTK updates, your version of the widget remains
constant, and you don't have to worry about FLTK updates as much,
since the public interfaces usually remain consistent.

It sure beats hacking FLTK directly, as then it becomes very
hard to update FLTK, as you have to 'merge' all your customizations
every release, and that leads to madness.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] How to create new theme for fltk?

[Greg Ercolano]

Sparkaround wrote:
> To Greg:
> Thanks. I need to know what is the reasonable way to implement the theme
> as simple as possible for plent of widgets and can be easily updated with the 
> new release of fltk-1.3.x.

I'd suggest making wrappers for all the widgets you plan to use.
I did this in my app, just to make it easy for me to change behaviors 
as needed.

So I'd make MyInput, MyChoice, MyTextEditor, etc. which all derive from
FLTK equivalents. Then I can redefine their draw()/handle() routines
as needed for particular behavior. Or even override the constructor
to, for instance, create a right click popup menu for the Fl_Input
so one can have Copy/Paste options.

These can then be used in fluid easily; let's say you need to make
a form full with about 20 Fl_Input's. Create the first one, and
in Properties, change the Class: to MyInput. Then, just make copies
of that instance over and over where you need them, and each will
be a MyInput version of Fl_Input.

> TO imacarthur:
> Aqua-style tabs? Do you mean the colorful tabs.cxx in the test directory
> of current release of fltk-1.3.x? Thanks.

Pretty sure Ian's referring to my 'Gel Tabs' widget:
http://seriss.com/people/erco/fltk/Fl_Gel_Tabs/

..which I've been using for the last few years in my commercial apps, 
eg:

http://www.seriss.com/rush-current/submit-maya-tile/gifs/submit-maya-tile-screenshot.jpg

The above widget, and others are listed below the index on my FLTK 
cheat page:
http://seriss.com/people/erco/fltk/#WidgetsAndApps

You might be interested in the 'matte button' widget as well:
http://seriss.com/people/erco/fltk/Fl_Matte_Button/

..probably a good starting point for something more complex.

I think both of these completely override the draw() function,
but could probably be more easily implemented with an overload
of the box drawing function; I haven't really made use of that
technique, but maybe should.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] glut + handle() (Re: STR#2482)

[Greg Ercolano]

I'm guessing your "UI" class is not actually derived
from an FLTK widget. If so, that's the reason your
handle() method isn't being called; FLTK doesn't know about it.

What you need is to make a class that /derives/ from an FLTK widget,
and define your handle(int) method there, so that it /overrides/
fltk's own internal handle() method.

Look at this example which shows just that:
http://seriss.com/people/erco/fltk/#GLCursor

This example derives a class "MyGlWindow" that derives from
Fl_Gl_Window (in this case, but could just as easily be an Fl_Window)
and defines a handle() method to override Fl_Gl_Window's own.

Note that the handle() method calls Fl_Gl_Window::handle(e) to pass
the event down to the derived class's handle() method, so that the
underlying class gets a shot at processing the event too. Be sure
yours does this, and preserves the return value for the handle()
method, which is very important.

In your case you can probably get what you want by leaving your
existing UI class alone, but make a separate new class
called MyGlutWindow, in a file called MyGlutWindow.H, eg:

#include// include the widget..
class MyGlutWindow : public Fl_Window { // ..that you derive from
public:
MyGlutWindow(int X,int Y,int W,int H,const char *L=0) : 
Fl_Window(X,Y,W,H,L) {
}
int handle(int e) {
..do your event handling here..
}
};

Then in fluid, open the 'Properties' for the FLTK window you're
trying to grab the events for, and under the C++ tab in the properties dialog,
set the Class: to MyGlutWindow.

Make sure your fluid file has a "#include ",
so that when fluid writes out the code, that include is always
saved into the .cxx and/or .h file that fluid generates.

This way fluid will use your derived window class instead of Fl_Window
in your ui->make_window() call.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

[fltk.general] glut + handle() (Re: STR#2482)

[greg ercolano]

Moved this question from STR#2482; Ingvar writes:
> [while using FLTK+glut]
> I tried to make my own key-up callback function, and calling it from the 
> handle:
> int UI::handle() {
>   switch (Fl::event()) {
>   case FL_KEYUP:
> //printf("You released: %c\n", Fl::event_key());
> callMyKeyboardUpFunc(Fl::event_key(), 0, 0); //TODO: FIX, TEST!!
> break;
> 
> But for some reason, the handle function is not receiving any events since I 
> added my glut code.

 You should maybe show us a bit more, but note the
 handle() function's signature takes an int parameter as well.

 So you must change:

BEFORE: int UI::handle() {
  AFTER: int UI::handle(int e) {

 ..to receive events properly.

 Also, then you can use 'e' instead of Fl::event()
 in your switch().

 Be sure to also pass the event down to the base class widget
 (whatever FLTK widget your "UI" class derives from) to prevent
 eclipsing events from the widget.

 Also, be sure to preserve the return value of the base class's
 handle() call, and pass it through your call. eg:


int UI::handle(int e) {
 int ret = Fl_SomeBaseClass::handle(e);
 switch (e) {
  ..do stuff, setting 'ret=1;' if you handled and event..
 }
 return(ret);
}

  ..where Fl_SomeBaseClass is the name of the FLTK class your UI
  widget derives from.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] How to create new theme for fltk?

[Greg Ercolano]

>>> I also have some vague memory of there being a way to hook into
>>> FLTK's drawing routines from an app to affect all widget drawing,
>>> which I /think/ involved some function pointers..

Matthias Melcher wrote:
> The easiest way to create something like a theme is to override
> the standard box styles. This is easily done by providing functions
> that draw boxes differently. See Fl::set_boxtype()
> 

Yep, that's it. With that I was able to find this article:
http://www.fltk.org/articles.php?L697
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] How to create new theme for fltk?

[Greg Ercolano]

>>> I also have some vague memory of there being a way to hook into
>>> FLTK's drawing routines from an app to affect all widget drawing,
>>> which I /think/ involved some function pointers..

Matthias Melcher wrote:
> The easiest way to create something like a theme is to override
> the standard box styles. This is easily done by providing functions
> that draw boxes differently. See Fl::set_boxtype()
> 

Yep, that's it. With that I was able to find this article:
http://www.fltk.org/articles.php?L697

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] How to create new theme for fltk?

[Greg Ercolano]

You can re-theme individual widgets by wrapping them in a C++ class
in the app code.

I also have some vague memory of there being a way to hook into
FLTK's drawing routines from an app to affect all widget drawing,
which I /think/ involved some function pointers. I can't remember
where there's example code, but I think some code was made available
here on the newsgroup some years ago. If I find it, I'll follow up,
and maybe add it to the cheat page/fltk examples dir.

But as far as /externally/ providing themes (ie. just providing images,
and/or techniques that don't involve code changes), I'm quite sure
1.x doesn't support this. Not sure about 2.x.


imacart...@gmail.com wrote:
> On 11/12/10 08:00, Sparkaround wrote:
>> Is it possible to create a custom theme without patching fltk?
> 
> What version of fltk?
> And what do you actually mean by theme? There seem to be variant 
> interpretations of just whet is meant by theme...!
> 
> Anyway, all that aside, and discounting the theme support in fltk-2 as 
> it seems to be frequently (currently?) broken, then I'd say that you can 
> achieve a lot simply by subclassing your widgets and doing a little work 
> in the draw() methods to create your new look - I've done this, and Greg 
> has some neat examples on on cheat pages (see his Aqua-style tabs demo 
> for one example, though he has others.)
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] button focus

[Greg Ercolano]

Paul R wrote:
> Hi all,
> 
> I have an error message window that pops up when required. I would
> like the user to be able to simply hit enter to clear it from screen,
> the window has an ok button to do this. However when the window
> is shown i cannot seem to get the button ready for events, i have tried
> the take_focus() call but it does not seem to work, the focus does not
> switch to the button, or anywhere else, the window is just 'there'

Try using an Fl_Return_Button instead of a regular button.
Spacebar is normally the keynav way to trigger a button when it has 
focus.
When you want the Enter key to do it, us an Fl_Return_Button.

See also: the 'ask' program in the test directory,
which shows how the enter key works in a dialog.

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] help downloading fltk on Visual C++ express

[Greg Ercolano]

Anna wrote:
> I am trying to load fltk using Visual C++ express.
> I have tried the various versions, but I cannot find
> the file fltk.dsw.

Probably your file browser is stripping off the .dsw extension
because recognizes it as a VisualC file, so it's probably showing up
as just 'fltk' in your browser, but it's really called fltk.dsw.

If you open up a DOS window and do a directory listing of the
visualc directory, you should see the fltk.dsw file in there.

>  I tried clicking on the file fltk in visualc, 

Yes, that's probably the fltk.dsw..

> but it could not load the other programs.

You may have left over project files from attempting to build
using one of the other files in that dir.

Suggest closing visual studio, removing (or renaming away) your
current fltk directory, and re-extract from the tar file.
Then open Visual Studio and open the fltk(.dsw) file.

If a dialog pops up asking yes/no/yes to all,
hit 'yes to all' and it should load up.

Then you can change the Debug -> Release,
right click on 'Solution FLTK' in the 'Solution Explorer'
and click 'Build Solution'.

It should go more or less just like this video:
http://seriss.com/people/erco/fltk-videos/fltk-ms-vs-build.html

Note the comments below the video regarding what's changed since
this video was made.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] DND crash (r7979) related to UTF8?

[Greg Ercolano]

Greg Ercolano wrote:
> --- snip
>   Xutf8TextPropertyToTextList(fl_display,
>+  (const 
> XTextProperty*)&text_prop, &text_list, &list_count);
> --- snip

Huh, just did an update -- it's gone now ;)
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] DND crash (r7979) related to UTF8?

[Greg Ercolano]

Alvin wrote:
> The segfault occurs in:
> Fl_x.cxx:
> int fl_handle(const XEvent& thisevent): line 964.

While looking at that area of the code, I found this nutty line
in 1.3-current:

--- snip
  Xutf8TextPropertyToTextList(fl_display,
   +  (const 
XTextProperty*)&text_prop, &text_list, &list_count);
--- snip

That weird little '+' in front of the pointer is
'compilable' and won't affect operation, but I'm thinking
it should be removed..
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Callback functions in a class method?

[Greg Ercolano]

Albrecht Schlosser wrote:
> On 07.12.2010, at 19:24, Greg Ercolano wrote:
> 
>>  devs: is there a doxygen tag that can pull example code
>>  straight from a directory into our docs e.g. as a \code block?
>>  I'm sure there's probably Makefile hacks to do this with sed(1),
>>  but I imagine doxygen might have something.
> 
> http://www.stack.nl/~dimitri/doxygen/commands.html#cmdinclude
> 
> Untested, never used by me. But I thought google'ing for doxygen
> and include should show something ;-) . The docs look exactly
> like what we would need.

\include -- sweet!

Something to keep in mind for the future, for really simple
example code. (ie. under a page).
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Callback functions in a class method?

[Greg Ercolano]

Sam wrote:
>> Greg Ercolano wrote:
>> [example code snipped]

> Beautiful, thanks Greg. These little snippets of code would be great
> for the programming manual.

Yes, I think the thing to do is flesh out our new 'examples'
directory, and have the ref manual's widget docs refer to these
by name.

I did this with the new Fl_Table and Fl_Tree widgets in fltk 1.3.x..
would be good if this were fleshed out a bit more.

Optimally, many of my 'cheat sheet' examples should probably
find their way into the fltk/examples directory as well for
this purpose.

Pasting code into the manual is probably a bad idea, because
documented code can often go stale over time. Probably better
to refer to files that we know build OK.

devs: is there a doxygen tag that can pull example code
straight from a directory into our docs e.g. as a \code block?
I'm sure there's probably Makefile hacks to do this with sed(1),
but I imagine doxygen might have something.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Callback functions in a class method?

[Greg Ercolano]

Greg Ercolano wrote:

>   Note that with this technique, 'this' can be passed to the
>   callback, so that it has access to this instance of the class. eg:
> 
> static void Sample_Callback(Fl_Widget*, void *data) {
>   MyMenuBar *mmb = (MyMenuBar*)data;  // get 'this'
>   mmb->xxx(); // now can access non-static 
> class elements/methods
> }
> [..]
> MyMenuBar(int X,int Y,int W,int H):Fl_Menu_Bar(X,Y,W,H) {
>   add("&File/&Sample", 0, Sample_Callback, (void*)this); // <-- pass 
> 'this' to cb
> }

Here's an example that shows this in action.

This opens two windows, each with its own instance of the custom
menubar. Each menubar instance has unique, instance specific data
that the static callback can access when the File -> Do Callback
item is chosen by the user in each window:

 snip
#include 
#include 
#include 
#include 
#include 
//
// Example of derived menubar class with callback that can access class 
instance data -erco 12/07/10
//
class MyMenuBar : public Fl_Menu_Bar {
const char *id_;// instance-specific data
public:
void id(const char* val) { id_ = val; }
const char* id() const   { return(id_); }
static void MenuCallback(Fl_Widget *, void *data) {
// Show how we can access instance-specific data
MyMenuBar *mmb = (MyMenuBar*)data;
printf("Sample callback, instance '%s'\n", mmb->id());
}
MyMenuBar(int X,int Y,int W,int H):Fl_Menu_Bar(X,Y,W,H) {
add("&File/&Do Callback", 0, MenuCallback, (void*)this);// 
passes 'this' to cb when invoked
}
};
int main() {
// WINDOW #1 + MENUBAR
Fl_Window w1(0,0,400,400,"Window #1");
MyMenuBar m1(0,0,400,25);
m1.id("Menu #1");   // set instance specific data
w1.end();
w1.show();

// WINDOW #2 + MENUBAR
Fl_Window w2(400,0,400,400,"Window #2");
MyMenuBar m2(0,0,400,25);
m2.id("Menu #2");   // set instance specific data
w2.end();
w2.show();

return(Fl::run());
}
 snip
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Callback functions in a class method?

[Greg Ercolano]

Sam wrote:
> // not able to place Sample_Callback as a MyMenubar method
> void Sample_Callback(Fl_Widget *, void *)

Be sure to declare Sample_Callback() as being static.

If that's not the trouble, show us the compiler errors
and the declaration of Sample_Callback() as a global function
in the class.

There's a lot of ways to make menu bars. There's the static
menu array approach:

 snip
#include 
#include 
#include 
#include 
class MyMenuBar : public Fl_Menu_Bar {
static void Sample_Callback(Fl_Widget *, void *) {
printf("Sample callback called.\n");
}
public:
MyMenuBar(int X,int Y,int W,int H):Fl_Menu_Bar(X,Y,W,H) {
static Fl_Menu_Item Sample[] = {
   {"&File",0,0,0,FL_SUBMENU},
   {"&Sample",0,Sample_Callback},
   {0},
   {0},
};
this->copy(Sample);
}
};
int main() {
Fl_Window win(400,400);
MyMenuBar menu(0,0,400,25);
win.end();
win.show();
return(Fl::run());
}
 snip

..or my favorite, using add() which is more dynamic,
and in my mind is easier to read/less to type:

 snip
#include 
#include 
#include 
#include 

class MyMenuBar : public Fl_Menu_Bar {
static void Sample_Callback(Fl_Widget *, void *) {
printf("Sample callback called.\n");
}
public:
MyMenuBar(int X,int Y,int W,int H):Fl_Menu_Bar(X,Y,W,H) {
add("&File/&Sample", 0, Sample_Callback);
}
};

int main() {
Fl_Window win(400,400);
MyMenuBar menu(0,0,400,25);
win.end();
win.show();
return(Fl::run());
}
 snip

Note that with this technique, 'this' can be passed to the
callback, so that it has access to this instance of the class. eg:


static void Sample_Callback(Fl_Widget*, void *data) {
MyMenuBar *mmb = (MyMenuBar*)data;  // get 'this'
mmb->xxx(); // now can access non-static 
class elements/methods
}
[..]
MyMenuBar(int X,int Y,int W,int H):Fl_Menu_Bar(X,Y,W,H) {
add("&File/&Sample", 0, Sample_Callback, (void*)this); // <-- pass 
'this' to cb
}

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] I'm reading an interesting book "C++ in Action" available online

[Greg Ercolano]

Domingo Alvarez Duarte wrote:
> Don't be fooled by it's opnion about K&R, he presents an interesting point  
> of view in his book.
> Be brave an accept hear things that you don't like at first, judje after  
> hear the whol history.

Yes, I did continue past it ;) I was being semi-tongue in cheek.
But the guy is a heathen for the K&R comment. ;) ;) <-- note smilies

He also worked for Microsoft (from '87-'95).
I'd almost dismiss him just for that, but being he worked on the
memory subsystem, kernel debugger, and the object-oriented windows
shell (monad?), I can't really fault those.

But if he'd said he worked on DOS or the Windows API,
I'd have stopped reading and never ever looked back.

Seems the more interesting part of his online book is the stuff
at the end. Haven't read those fully yet, been too busy. But
a lot of stuff in the intro put me off. The C ghetto and all that
about kernels should use C++. Rubs me the wrong way :/

Veering back on topic: books I've read that I've liked that cover
the strengths and gotchyas of C++ (these are NOT free however):

"C++ FAQS" (Cline/Lomow)
"Modern C++ Design" (Alexandrescu)
"Effective C++" and "More Effective C++" (Meyers)

Pretty much anything by Meyers and Alexandrescu are excellent.

The C++ FAQ book is a frigging amazing concentration of knowledge
from all of the C++ language Usenet newsgroups over the years.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] I'm reading an interesting book "C++ in Action" available online

[Greg Ercolano]

> I'm reading an interesting book "C++ in Action" available online at
> http://www.relisoft.com/book/index.htm

   The author lost me in the intro at:

   "[..] this book [..] essentially says [..]
   "Kernighan and Ritchie are not gods".

   Dissin' K&R -- that just ain't right. ;)
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] FL_Tree disabling resize

[Greg Ercolano]

Greg Ercolano wrote:
>   Or, make an invisible box using the techniques described above
>   to disable resizing of the tree in the one direction you want.

Here's an example showing how to do that, since it may seem unclear.

This program makes two separate windows; one where the tree resizes
only on its width, the other only on its height.

In both cases the buttons are 'locked' (don't move or resize)
to show how the behavior can be restricted to just the tree widget.


#include 
#include 
#include 
#include 
#include 
//
// Demonstrate limiting a widget's resizing to just width or height. -erco 
11/29/10
//
// Open two resizable windows: one where window resizing only affects the
// the tree widget's width, the other only affects the tree widget's height.
// In both cases, the extra buttons (A and B) are 'locked down' to show how
// the resize behavior's influence can be limited to just the tree widget.
//
void ResizeTreeWidthOnly() {
  // Desired behavior:
  // Force buttons to not change or move at all, while allowing tree
  // to resize in width only.
  // Technique:
  // Position a resizer widget below the tree so that only the tree's
  // width can change. Since we don't want the buttons to move,
  // but they are above the tree, we protect them from the resizer's
  // influence by putting them in a group, and disabling the group's 
resizable().
  //
  Fl_Double_Window *win = new Fl_Double_Window(230, 300, "Resize Tree Width 
Only");
  win->begin();
  Fl_Group *grp = new Fl_Group(10,10,210,45);
  grp->box(FL_FLAT_BOX); grp->color(47);// make group box slightly 
visible so we can see it (debugging)
  grp->begin();
  new Fl_Button(10, 10,100,25,"A");
  new Fl_Button(120,10,100,25,"B");
  grp->end();
  grp->resizable(0);// protect buttons from any 
resizing behavior
  Fl_Tree *tree = new Fl_Tree(10,50,210,240);
  tree->add("Flintstones/Fred");
  tree->add("Flintstones/Wilma");
  tree->add("Simpsons/Homer");
  tree->add("Simpsons/Marge");
  Fl_Box *win_resizer = new Fl_Box(10,295,210,2);
  win_resizer->box(FL_FLAT_BOX);// make the resizer visible as 
a red box (debugging)
  win_resizer->color(FL_RED);
  win->end();
  win->resizable(win_resizer);  // assign red resizer box as 
window's resizable
  win->show();
}

void ResizeTreeHeightOnly() {
  // Desired behavior:
  // Force buttons to not change or move at all, while allowing tree
  // to resize in height only.
  // Technique:
  // Prevent buttons from resizing and limit tree to only resize
  // on the vertical by placing a tiny resizer box at the far right of the 
tree,
  // and making it the window's resizable.
  //
  // This has the effect of:
  // 1) Preventing the buttons from resizing or moving at all;
  //the resizer box acts as the 'spring' that absorbs resizing
  //behavior away from widgets that are not opposite its edges.
  //
  // 2) Since the tree is opposite the resizer's left edge,
  //the resizer limits the tree widget to only do vertical resizing.
  //
  Fl_Double_Window *win = new Fl_Double_Window(230, 300, "Resize Tree Height 
Only");
  win->begin();
  new Fl_Button(10, 10,100,25,"A");
  new Fl_Button(120,10,100,25,"B");
  Fl_Box *win_resizer = new Fl_Box(225,50,2,240);
  win_resizer->box(FL_FLAT_BOX);// make the resizer visible as 
a red box (debugging)
  win_resizer->color(FL_RED);
  Fl_Tree *tree = new Fl_Tree(10,50,210,240);
  tree->add("Flintstones/Fred");
  tree->add("Flintstones/Wilma");
  tree->add("Simpsons/Homer");
  tree->add("Simpsons/Marge");
  win->end();
  win->resizable(win_resizer);  // assign red resizer box as 
window's resizable
  win->show();
}

int main(int argc, char *argv[]) {
  Fl::scheme("gtk+");
  ResizeTreeWidthOnly();
  ResizeTreeHeightOnly();
  return(Fl::run());
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] FL_Tree disabling resize

[Greg Ercolano]

Slick Dealer wrote:
> I am using a resizable window but would like to disable resizing of a Fl_Tree 
> inside the window. Is there any way to disable Fl_tree from resizing?

Shouldn't matter if it's a tree or any other FLTK widget, the
resizing behavior should be governed by the rules in this article:
http://fltk.org/articles.php?L415+I20+T+P1+Qresize

To completely disable resizing width AND height, just put the tree
into an Fl_Group and set the group's resizable to 0.
This will prevent the children of that group from resizing.

Or, make an invisible box using the techniques described above
to disable resizing of the tree in the one direction you want.

To allow specific behavior for only certain widgets, use groups
to either enclose widgets to protect them from resizing (by setting
the group's resizable to 0), or or to limit a resize box's influence
by putting a resize box within the group.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] multiplemice ?

[Greg Ercolano]

> What are you trying to do with it? I'm curious what it is
> good for (in practice).

I was wondering that myself.

I'm envisioning that with a mouse in each hand
and 2 separate cursors on the screen, one could do
the equivalent of this job (LOL):

http://1.bp.blogspot.com/_uQHPGPrEyDA/SrBPQgCQQKI/AhA/M88UaWSNV2E/s400/Metropolis-clock.jpg

I know a lot of applications make assumptions about mouse
push/drag/release events via a /single/ 'dragging' state variable.

So to have a simple clock program that, for example, allows adjusting
of the separate hour/minute hands at the same time would involve
some special *app-side* coding to keep track of the separate dragging
states.

If there are two mouse cursors, do they each have a little "L" and "R"
so you can tell the left one from the right? Or maybe they're color-coded?
Boggles my mind.. ;)
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Can Widget Detect Hovering Mouse?

[Greg Ercolano]

Duncan Gibson wrote:
>> My .h file generated by Fluid is -
>> // generated by Fast Light User Interface Designer (fluid) version 1.0011

> fluid 1.0011 ! Looks like you're using something really ancient? Maybe
> the "L=0" in both *.h and *.cxx was a bug that has long been fixed.

Gaaak, good catch.

I think he said back in Apr 2010 (old posting here) he was having
trouble switching from 1.0.11 to 1.1.10.

Mike, did you switch, but maybe are still running a very old fluid?
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Can Widget Detect Hovering Mouse?

[Greg Ercolano]

Mike Werner wrote:
> I think I found a fix to the problem Greg. It was in the header file. Fluid 
> generates the line:
> 
>   MyGroup(int X,int Y,int W,int H,const char *L=0);
> 
> Changing  -->char *L=0)<-- to -->char *L)<-- works for me.

Interesting; normally "*L=0" is correct in the .h file,
but shouldn't appear in the .cxx file. Fluid should handle that,
but in the case of the fluid you're using, it seems like it's not.

Anyway, glad you figured it out.. you can actually make two separate
definitions of the ctor if need be in fluid; one with the L and one 
without.
A longer way to end up with the same result, but might be more 
compatible
in your fluid config, eg:

MyGroup(int X,int Y,int W,int H,const char *L) : Fl_Group(X,Y,W,H,L);   // with
MyGroup(int X,int Y,int W,int H) : Fl_Group(X,Y,W,H);   // 
without

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Can Widget Detect Hovering Mouse?

[Greg Ercolano]

Mike Werner wrote:
> Did you use the 'New'->'Code' options of Fluid to generate your example?

Yes, to implement the constructor and handle() method.
To make a new function/method with your own code, you:

a) Use New -> Code -> Function/method  -- creates the function 
prototype/definition
b) Use New -> Code -> Code -- creates the code for the 
function/method

This is how one can implement your own custom functions
and custom methods for custom classes inside fluid.
(To make custom classes, see below)

> I cut and paste the code between your 'snip' lines into a text file called 
> 'hover.fl'.
> Then I opened 'hover.fl' with Fluid. That seems to work. Fluid brings up a 
> small window
> with the ATM box inside it. The Fluid code window shows that a class 
> 'MyGroup' has been
> created inside of which there are two items:

Sounds good so far.

Be sure you're working with the /second/ example I sent,
not the first one. Note I replied to myself with a modified version
of the file.

> 1) something called 'MyGroup' which seems to be derived from FL_Group,

Yes, that 'something' is a class definition, eg New -> Code -> Class,
the custom class being "MyGroup", and yes, that new class is setup
to derive from Fl_Group.

If you poke around in fluid, you can open the MyGroup class
and see the two methods defined inside it; MyGroup() [the constructor]
and handle() [the event handler].

You should be able to look at this by highlighting the item
and hitting F1 to see the properties for the class definition,
which shows how it derives from Fl_Group.


> Next I used Fluid to generate code, resulting in two files:
> 'hover.cxx' and 'hover.h'. Brought those files into a Visual C++ (6.0) 
> workspace
> to compile and run. Ran into problems there. Here's the message ...
> 
> c:\work\work_11\dwss\code\hover\hover.cxx(5) : error C2572: 
> 'MyGroup::MyGroup' : redefinition of default parameter : parameter 5
> c:\work\work_11\dwss\code\hover\hover.h(10) : see declaration of 
> 'MyGroup::MyGroup'
> 
> Make any sense to you?

Can you paste the 2 files here; hover.cxx and hover.h?

The lines in hover.h that define the ctor should look like:


public:
  MyGroup(int X,int Y,int W,int H,const char *L=0);


..and the definition of the constructor in hover.cxx should look like:


MyGroup::MyGroup(int X,int Y,int W,int H,const char *L):Fl_Group(X,Y,W,H,L) {
  // empty
}


If yours look different in some way, esp. the 'L' argument,
it might be an inconsistency with fluid's code generator.

But be sure you're using the second fluid file I sent,
ie. the message that starts off saying:

"Actually, the following .fl file should work better."


___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] 20 more STRs to go

[Greg Ercolano]

Matthias Melcher wrote:
> 2428  1.3.x + OSX compiler warnings with GCC 4.0.1/Tiger  Core Library
> New LOW M
> Is this fixed?

This morning I applied Manolo's fix, tested, and closed.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] 20 more STRs to go

[Greg Ercolano]

Matthias Melcher wrote:
> 
> 2375  Fl_Tree doesn't accept keyboard navigation  Core LibraryActive  
> HIGHM
> Greg, will you find time for this?

Closed that one earlier today.
Leftover issue of child FLTK widgets bumped to a separate STR as an RFE 
for 1.4

> 2306  fltk's use of snprintf() should be hardened -- recommend alternatives   
> Core LibraryNew MOD M
> MUST we fix this?

Not a must.. can be bumped to 1.3.1 or 1.4

> 2426  Fl_Tree: Enter should scroll to show_item(). should scroll only if off 
> screen   Core LibraryNew MOD M
> Greg, will you have time to look at this?

Ya, I can probably solve that one easily.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Can Widget Detect Hovering Mouse?

[Greg Ercolano]

Greg Ercolano wrote:
>   Using that as an example, I made the following entirely within fluid;
>   should do exactly what you describe.

Actually, the following .fl file should work better.

The last example I designed in an older version of fluid,
but when loaded into 1.3.x fluid, it didn't make the derived class code
correctly if the ctor had no 'code' assigned to it. So I added an empty
'code' to the ctor to make it work in fluid 1.3.x.

Also, changed "redraw();" to "window()->redraw();" to ensure the label,
which in this case draws outside the widget, draws correctly when changed.


 SNIP  SNIP  SNIP  SNIP  SNIP  SNIP  SNIP  SNIP
# data file for the Fltk User Interface Designer (fluid)
version 1.0109
header_name {.h}
code_name {.cxx}
decl {\#include } {public global
}

class MyGroup {open : {public Fl_Group}
} {
  Function {MyGroup(int X,int Y,int W,int H,const char 
*L=0):Fl_Group(X,Y,W,H,L)} {open return_type void
  } {
code {// empty} {}
  }
  Function {handle(int e)} {open protected return_type int
  } {
code {int ret = Fl_Group::handle(e);
switch ( e ) {
case FL_ENTER:
label("At The Moment");
window()->redraw();
ret = 1;// FL_ENTER: must return(1) to receive FL_MOVE
break;
case FL_LEAVE:
label("ATM");
window()->redraw();
ret = 1;
break;
}
return(ret);} {selected
}
  }
}

Function {} {open
} {
  Fl_Window {} {open
xywh {631 198 465 385} type Double visible
  } {
Fl_Group group {
  label ATM open
  xywh {25 40 295 275} box FLAT_BOX color 41 labelfont 1 labelsize 19
  class MyGroup
} {}
  }
}
 SNIP  SNIP  SNIP  SNIP  SNIP  SNIP  SNIP  SNIP


___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Can Widget Detect Hovering Mouse?

[Greg Ercolano]

Mike Werner wrote:
> I would like to replace those 3 letters with the words they stand for
> whenever the mouse goes into the box.  I would like this to happen 
> automatically
> without any clicking being done.

You probably want to look for the FL_ENTER and FL_LEAVE events.
You'd have to derive a class, eg. "MyGroup" from the Fl_Group.

> Can this be done from within the Fluid 'Extra Code' area,
> or the 'Callback' definition area? 

If you derive a group, just set the Class: for the actual
widget in your layout (in fluid's properties) to the name
of your derived group, eg. MyGroup. See example below.

> I'd rather not get into writing my own 'handler' function.

Can't avoid that, I don't think.

> I'm not seeing how to do this in the reference.

Here's an example of how to watch mouse movement
without clicks. (I used this for reference for the below):
http://seriss.com/people/erco/fltk/#DrawCoords

Using that as an example, I made the following entirely within fluid;
should do exactly what you describe.

 SNIP  SNIP  SNIP  SNIP  SNIP  SNIP  SNIP  SNIP
# data file for the Fltk User Interface Designer (fluid)
version 1.0109
header_name {.h}
code_name {.cxx}
decl {\#include } {selected public global
}

class MyGroup {open : {public Fl_Group}
} {
  Function {MyGroup(int X,int Y,int W,int H,const char *L):Fl_Group(X,Y,W,H,L)} 
{open return_type void
  } {}
  Function {handle(int e)} {open protected return_type int
  } {
code {int ret = Fl_Group::handle(e);
switch ( e ) {
case FL_ENTER:
label("At The Moment");
redraw();
ret = 1;// FL_ENTER: must return(1) to receive FL_MOVE
break;
case FL_LEAVE:
label("ATM");
redraw();
ret = 1;
break;
}
return(ret);} {}
  }
}

Function {} {open
} {
  Fl_Window {} {open
xywh {631 198 465 385} type Double visible
  } {
Fl_Group group {
  label ATM open
  xywh {25 40 295 275} box FLAT_BOX color 41 labelfont 1 labelsize 19
  class MyGroup
} {}
  }
}
 SNIP  SNIP  SNIP  SNIP  SNIP  SNIP  SNIP  SNIP
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] destructors

[Greg Ercolano]

Paul R wrote:
> What is the method to destroy any windows called open by the main window, if 
> the main window is closed?

If you want the program to shut down when the main window is closed,
then just setup a callback for the main window that exits the program, 
eg:


void MainWinQuit() {
exit(0);
}

int main(..) {
   ..
   mainwin->callback(MainWinQuit);
   ..
   return(Fl::run());
}


MainWinQuit() will be called whenever the main window is closed,
either by ESC or by the user clicking the 'X' in the window manager.

The exit(0); will call all your destructors,
and will of course close all windows.

The MainWinQuit() callback can also be used to check if the user
has unsaved data and post a dialog warning so. If you return() from
the MainWinQuit() callback, you can prevent the main window from being 
closed.



___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Class inheritance on fluid

[Greg Ercolano]

Hmm, but isn't that the same as deriving a MyIntInput class
from Fl_Float_Input, and then referencing it inside fluid
by dropping an Fl_Int_Input widget into the fluid form and
setting the "Class:" field in the C++ properties to MyIntInput?


Domingo Alvarez Duarte wrote:
> Your asii art is a nice solution.
> 
> And you've mentioned:
> 
> ---
>   My approach is to make an 'input' class of my own
>   for each of the input fields (eg. one for Fl_Input,
>   Fl_Choice, etc).
> 
>   And in these classes have a 'name' field (std::string or char*)
>   that is the "database name".
> ---
> 
> I also have to add some extra fields/methods to other purposes.
> 
> I propose that fltk headers should have included a preprocessor directive  
> to easy customizations like that by developers, something like this:
> 
> --
> 
> #include 
> 
> class FL_EXPORT Fl_Float_Input : public Fl_Input {
> public:
>/**
>Creates a new Fl_Float_Input widget using the given position,
>  size, and label string. The default boxtype is FL_DOWN_BOX.
> Inherited destructor destroys the widget and any value associated  
> with it
>*/
>Fl_Float_Input(int X,int Y,int W,int H,const char *l = 0)
>  : Fl_Input(X,Y,W,H,l) {type(FL_FLOAT_INPUT);right_to_left_=1;}
> 
> #ifdef USER_CUSTOM_DEFINED_FOR_FL_FLOAT_INPUT
>   USER_CUSTOM_DEFINED_FOR_FL_FLOAT_INPUT;
> #endif
> };
> 
> 
> Example of a possible ""
> 
> 
> #define USER_CUSTOM_DEFINED_FOR_FL_WIDGET \
>   const char* field_name; \
>   char* storage_space; \
>   virtual bool validate_value() {return 0;};
> 
> #define USER_CUSTOM_DEFINED_FOR_FL_WIDGET_ON_CONSTRUTOR \
>   const char* field_name = NULL; \
>   char *storage_space = NULL;
> 
> #define USER_CUSTOM_DEFINED_FOR_FL_WIDGET_ON_DESTRUCTOR \
>   if(field_name) free(field_name); \
>   if(storage_space) free(storage_space);
> 
> 
> #define USER_CUSTOM_DEFINED_FOR_FL_FLOAT_INPUT \
>   bool allow_negative_values; \
>   virtual bool validate_value() {return allow_negative_values ? true :  
> value_float() > = 0;};
> 
> #define USER_CUSTOM_DEFINED_FOR_FL_FLOAT_INPUT_ON_CONSTRUCTOR \
>allow_negative_values = true;
> 
> 
> 
> 
> This way we can customize fltk for a lot of needs without having to derive  
> new widgets only editing the "" and include our  
> definition file to the library, and we can update fltk sources without  
> much worry about our customizations.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Class inheritance on fluid

[Greg Ercolano]

Domingo Alvarez Duarte wrote:
> I'm facing a problem using fluid, I'm writing forms for view/edit database  
> records I want to name the widgets used to show/edit field information  
> with the same name as the database records, but sometimes those names can  
> conflict with some parent class field/method names, ideally I want a kind  
> of namespace for those fields and that can be don using an internal  
> class/struct without any inheritance.

I've had to do a bit of this myself.

My approach is to make an 'input' class of my own
for each of the input fields (eg. one for Fl_Input,
Fl_Choice, etc).

And in these classes have a 'name' field (std::string or char*)
that is the "database name".

This way I don't need a variable for each field; I just keep
an array of the 'fields', and whenever I want to load or save
the entire form, I have an application level load/save method
that walks the array and either reads or writes all the names
and field contents.

For input checking, all the fields invoke a sanitizer callback
that the app programmer can set (eg. if it's an integer oriented
field, then set up the "integer sanitizer" as the callback).

I avoid keeping C++ variable names for each field, so that
fields can be dynamically created. (In my case I have external
"ascii art" text files (sample below) that define the forms,
so this is a must. But it works for hard coded forms too)

In fluid you can just drop regular input/choice/etc widgets,
but set their 'class' to be your own classes, and configure
the 'callback' to be the sanitizer.

Here's an example of the ascii art files I use for my forms.
The "prompt name" automatically becomes the "database name"
(minus the spaces). The underbars define how wide the fields
are, and the vertical spacing defines the vertical positioning
of the widgets. A parser reads this file and creates the
widgets automatically. I have about 30 such files (each about
5x larger than the excerpt shown here) each with different contents.
Some are multiline fields, or have bodies of text or images embedded
in there as well. Ascii art FTW ;)



<> "Properties"

   AutoDump: "off,fail,done,donefail" ?
  Done Mail: __ ?
  Dump Mail: __ ?


=   WaitFor: __ ?
=Wait For State: "Dump,Done,DoneFail,Fail" ?


Ram: __ ?
   Submit Hosts: __ ?


  Job Start Command: ___ ? Browse
   Job Done Command: ___ ? Browse
   Job Dump Command: ___ ? Browse


 Never Use Cpus: __ ?
 __
 __

 Submit Options: __ ?
 __
 __


___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Small modification to Fl_Value_Input to allow precize steps with leftmouse button

[Greg Ercolano]

Domingo Alvarez Duarte wrote:
> One thing that drives me mad on fluid sometimes is to fine adjust  
> placement/size of widgets, with the left mouse button it is supposed to  
> increment/decrement at 1 steps but most of the time it  
> increments/decrements in ore than 1 step.

You don't need to modify fluid for this.

If you use the regular arrow keys, it moves widgets around
on increments of 1, regardless of what the grid and pixel snap
is set to (eg. Layout -> Grid + Size Settings)
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Fluid with lua script for helpers on codegeneration

[Greg Ercolano]

> And so the language war begins... .

Is there a reason these fluid code generator hooks
couldn't be language agnostic?

I could see FLTK providing sample hook programs
written in some popular programming language (like C++! ;)
to show how it works.

Then advanced users wanting to write their own code gen
hooks could use that for reference, using any language
they like, including lua/perl/python/ruby/etc

Would hate to tie FLTK to any scripting languages to free
it of dependencies. And as light as e.g. lua might be,
wouldn't want to bring it on board just for this.
The fact fluid's c++ code is open means it can be modified
in a language we're all familiar with and runs fast.
Not sure what's to gain by using a scripting language
instead of C++ in this instance.

I must be missing something.

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Why Fl_Int_Input and Fl_Float_Input doesn't have methods toset/getvalue as int or float ?

[Greg Ercolano]

Duncan Gibson wrote:
> Such decoding methods should check for trailing crud so that 0x01x1
> would trigger fail() too. I've tried to subclass to have validating
> input fields before, and once you take cut'n'paste into account there
> are points when the field can be invalid...

Good point.

I think the docs should maybe mention the conversion technique
used, too, so if the user doesn't find that sufficient,
they will know to 'roll their own'.

I think if we use sscanf() and sprintf(), locale specific stuff
comes for free, like differences with decimal points
(where some countries use ',' instead of '.', etc)

Also, sscanf() can be used to do a trailing garbage check, eg:

 snip
const char *s = value();
// Integer conversion
int ival = 0;
if ( sscanf(s, "%d", &ival) != 1 ) {
  fail = 1; // "not an integer"
  return(0);
}
// Trailing garbage check
char junk[5];
if ( sscanf(s, "%d%4s", &ival, junk) == 2 && junk[0] ) {
  fail = 2; // "trailing garbage"
  return(ival); // return partially converted value anyway
}
fail = 0;   // no error
return(ival);
 snip
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Why Fl_Int_Input and Fl_Float_Input doesn't have methods to set/getvalue as int or float ?

[Greg Ercolano]

Domingo Alvarez Duarte wrote:
> It seems a bit logical to have methods to get/set value on then with th  
> respective type, this way we save a lot of work for the users that doesn't  
> need to make conversions to and from then.

This certainly sounds reasonable ;)

Since the Fl_Int_Input and Fl_Float_Input classes are implemented
as .H files only, I'd offer that the methods be made available
in Fl_Input_, since there's no reason floats and ints shouldn't
be accessible to the float, int, and string version of the widget.

For the 'get' methods, I strongly suggest we provide a way
for FLTK to return an error if the value in the widget cannot
be converted.

One way could be to add a fail() method the caller can check, eg:

Fl_Input *in;
[..]
int val = in->value_int();  // get value as an integer
if ( in->fail() ) { // check for conversion error
printf("'%s' is not an integer.", in->value());
}

Regarding naming for the new methods: I don't think we can use
the name "value()" for the int/float methods because C++ doesn't
allow overloading by return type alone (the set method would work,
but get method wouldn't).

So I think we need some new name like value_int() and value_float(),
or some such. And if so, possibly for consistency we should have
value_str()..?

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Fedora 14: 'yum' commands needed to build FLTK

[Greg Ercolano]

Matthias Melcher wrote:
> In README.Unix.txt, I recommend:
> 
>   su root
>   yum groupinstall "Development Tools"
>   yum groupinstall "X Software Development"
> 
> so, basically the same plus Subversion.

Yes, svn, forgot that one.

Looks like "Development Tools" includes some other must haves:
patch, doxygen, valgrind, strace, kernel-dev, gettext..

Plus some other stuff: git, indent, qt3, kernel-dev, gfortran.

Surprised 'xxdiff' isn't in there.. "yum install xxdiff"!
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

[fltk.general] Fedora 14: 'yum' commands needed to build FLTK

[Greg Ercolano]

Just an FYI for anyone wanting to build FLTK on Fedora 14..

Here's the two 'yum install' commands needed to get the compiler
and X dev environment installed on a fresh install:

yum install gcc gcc-c++ autoconf automake
yum groupinstall "X Software Development"

I personally haven't used fedora/redhat in a while since ubuntu,
but found myself needing fedora to get an x86_64 machine running.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] SleepEx() Win32 and fl_create_thread

[Greg Ercolano]

transistortoas...@fastmail.fm wrote:
> Hello,
> What is the best way to add a delay function in a thread created with 
> fl_create_thread for  FLTK 1.1.8 under win32? I'd like the GUI response to 
> run smoothly even when the delay is running.
> 
> I need the delays to be in the 20ms-200ms range and it's not critical to be 
> accurate. The goal of the delay is just not to make the CPU give all its 
> processing power in a while loop.
> 
> I experimented with SleepEx() in the fct_with_loop and don't understand 
> totally how come it affects threads other than the one it is in.In my bigger 
> program, I created before running fct_wit_loop and the GUI response is pretty 
> sluggish.

Here's a program I whipped up this morning that uses a technique
I like to use, where I interrupt the FLTK event loop every .10 secs
to check for data from the child thread. Child thread never touches
FLTK, just streams data into an array that the FLTK thread 
locks/reads/empties/unlocks.

Builds on windows and linux:


// demo use of FLTK with threads and locking under high load - erco 11/11/10
#include 
#include 
#include 
#include 
#include 

#include 
#include 
using namespace std;

#ifdef _WIN32
//
// WINDOWS
//
#include 
#include 
#define popen   _popen
#define pclose  _pclose
#define COMMAND "dir /s c:\\windows"
#define SYSERR  strerror(errno)
#define SLEEP() //Sleep(1)  // unneeded
#define INITLOCK()  InitializeCriticalSection(&G_lock);
#define LOCK()  EnterCriticalSection(&G_lock);
#define UNLOCK()LeaveCriticalSection(&G_lock);
#define START_THREAD(f,p) { 
\
  unsigned long thread_id;  
\
  HANDLE thread_h = CreateThread(NULL,  
\
 0, 
\
 
(LPTHREAD_START_ROUTINE)f, \
 (LPVOID)p, 
\
 0, 
\
 &thread_id);   
\
  }
CRITICAL_SECTION G_lock;// global lock
#else
//
// UNIX
//
#include 
#include 
#define COMMAND "ls -laR /usr"
#define SYSERR  strerror(errno)
#define SLEEP() //usleep(10)// unneeded
#define INITLOCK()  pthread_mutex_init(&G_lock, NULL);
#define LOCK()  pthread_mutex_lock(&G_lock);
#define UNLOCK()pthread_mutex_unlock(&G_lock);
#define START_THREAD(f,p) { 
\
  pthread_t thread; 
\
  pthread_create((pthread_t*)&thread, 0, f, 
(void*)p);  \
  }
pthread_mutex_t G_lock; // global lock
#endif

vector G_lines; // lines of output from child 
thread -> main thread

void* ChildThread(void *) {
char s[1024];

// RUN A COMMAND, AND ADD ITS OUTPUT TO BROWSER
FILE *fp = popen(COMMAND, "r");
if ( fp == NULL ) {
sprintf(s, "ERROR: '%s': %s", (const char*)COMMAND, (const 
char*)SYSERR);

LOCK();
G_lines.push_back(string(s));
UNLOCK();

return(0);
}
while ( fgets(s, 1023, fp) ) {
LOCK();
G_lines.push_back(string(s));
UNLOCK();
SLEEP();
}
pclose(fp);

LOCK();
G_lines.push_back("*** DONE");
UNLOCK();

return(0);
}

int main() {

// Build FLTK interface
Fl_Double_Window *win  = new Fl_Double_Window(600,800);
Fl_Multi_Browser *brow = new Fl_Multi_Browser(10,10,600-20,800-20);
brow->textfont(FL_COURIER);
win->resizable(brow);
win->show();

// Set up child thread to feed us data
//Let child use as much cpu as it wants to fill the G_data array.
//FLTK will grab some cpu every .10 secs to check for new data
//and will update it when it can.
//
Fl::lock();
INITLOCK();
START_THREAD(ChildThread, 0);

// Event loop
//Let FLTK do its thing, but every .10 secs, check for new
//data from child thread.
//
while ( 1 ) {
Fl::wait(.10);
if ( ! win->visible() ) break;  // user closed window?
LOCK();
{
for ( unsigned int t=0; tadd(G_lines[t].c_str());
}
G_lines.clear();
}
UNLOCK();
}
return(0);
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] mixed font label?

[Greg Ercolano]

s...@sjssoftware.com wrote:
> What I'd like to do is make an Fl_Button with a 2 character
> label, rendering the first character in one font and the
> second in another.  Possible?

If it is just a one-off, you could make a small image with the
two characters on it, and apply it as the button's image().

Otherwise, make a class MyButton that derives from Fl_Button,
and override the draw() method. Copy/paste the code for 
Fl_Button::draw()
(from the fltk Fl_Button.cxx source file) into your widget, and
modify to taste, using fl_font() and fl_draw() to draw each character.

Looking at the draw() code from 1.3.x:

void Fl_Button::draw() {
  if (type() == FL_HIDDEN_BUTTON) return;
  Fl_Color col = value() ? selection_color() : color();
  draw_box(value() ? (down_box()?down_box():fl_down(box())) : box(), col);
  draw_backdrop();
  if (labeltype() == FL_NORMAL_LABEL && value()) {
Fl_Color c = labelcolor();
labelcolor(fl_contrast(c, col));
draw_label();
labelcolor(c);
  } else draw_label();
  if (Fl::focus() == this) draw_focus();
}

..you'd want to take a copy of that code, and replace the draw_label()
calls with your own fl_color()/fl_font()/fl_draw() calls.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] same name ambiguous, failed polymorphism

[Greg Ercolano]

Duncan Gibson wrote:
>> So the book is /NOT/ compiling against FLTK 2.x.
> 
> Mea culpa.

Actually, it's come up before (hence the bold text above,
not actually directed at you ;) but to all the FLTK'ers
here who often find themselves giving advice to people
with the book.

I myself had that perception based on those error messages
I'd seen in those threads.

But looking at the actual examples, I'm happy to see
the book is not about 2.x, it just provides a lib of its own
widget library (called "GUI") that happens to have Widget
and Window classes that the examples refer to, but are actually
implemented in 1.x.

> Greg, do you think you could summarize your findings in an Article
> so that we can refer to it easily in the future?

Sure.

Let's see how it shakes out with eric first, as I see he's
still having trouble, but maybe getting closer with Albrecht's
recent reply.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] simple GUI program can not compile, plz help

[Greg Ercolano]

eric wrote:
> after i install every package and ready to go(compile) some simple fltk 
> program
> from Mr. Stroustrup "Programming-Principle and practice usingC++" 4th ed., 
> chapter 12's first example program(chapter.12.3.cpp copied from his website,
> http://www.stroustrup.com/Programming/

I missed this part of the thread, which shows the link
to the book's website.

According to my take on that page, you only need to download
this one zip file:

http://www.stroustrup.com/Programming/Programming-code2.zip

..which has all the examples from all chapters, and has
a copy of FLTK 1.1.9 along with it.

The zip file comes with:

1) a hierarchy of example programs for each chapter
2) a copy of FLTK 1.1.9 which it will use if no other FLTK is found
3) Makefiles for everything
4) a "readme.txt" file that tells you what to do.

I was able to get the example programs to build by doing
the following:

1) Downloaded the above zip, extracted it

2) cd'ed into the extracted zip directory

3) Ran the following from that directory:

( cd FLTK ; autoconf; make; make install )  # <-- builds 
FLTK 1.1.9, installs it
make# <-- this 
builds all the examples against that FLTK release

 This seems to build all the examples.
 There are some warnings, but it seems to build OK.

Some notes:

 Some of the examples need 'boost' installed.

 Also: you have to build AND ACTUALLY "make install" fltk 1.1.9
 in order for the examples to build with the Makefiles included.
 The example Makefiles don't seem to provide a way to specify
 an alternate directory for the FLTK libs (via an -L flag or
 environment variable). It seems you'd have to edit all the Makefiles
 to make such a change, so it's easier to just do the 'make install')
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] same name ambiguous, failed polymorphism

[Greg Ercolano]

A note to the FLTK folks regarding this thread.

I'm looking over the examples on the book's website.

The code the book compiles against is 1.1.9, not 2.0.

The references you see to 2.x style names (like "Window" and "Widget")
are because he's got classes defined in his own libs with those names.

So the book is /NOT/ compiling against FLTK 2.x.
It really is 1.1.9, but these complaints are about the libs
that come with the book that just so happen to have names that are
similar to the FLTK 2.x names.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] simple GUI program can not compile, plz help

[Greg Ercolano]

eric wrote:
> I get a lot compile errors, which is really out of novice as me to figure out.
> chapter.12.3.cpp:(.text+0x7d): undefined reference to 
> `Simple_window::Simple_window(Point, int, int, String const&)'
> chapter.12.3.cpp:(.text+0x1e7): undefined reference to 
> `Simple_window::wait_for_button()'

The above errors seem to be complaining about code in Simple_window.h,
code that hasn't been posted here (you just posted the .cpp file, not
the .h file on which it depends, and the above errors are about)

> chapter.12.3.cpp:(.text+0x100): undefined reference to 
> `Graph_lib::Polygon::add(Point)'
> chapter.12.3.cpp:(.text+0x144): undefined reference to 
> `Graph_lib::Polygon::add(Point)'
> chapter.12.3.cpp:(.text+0x188): undefined reference to 
> `Graph_lib::Polygon::add(Point)'

These appear to be errors about another library, "Graph_lib",
which I take it is something the example needs, and the book provides,
and is something you have to compile separately, and link in with
your application.

This is a more complex situation; you're trying to compile a program
that depends on more than just FLTK, but several other files as well.

So a simple: "fltk2-config --compile " is not enough;
other files need to be compiled first (Graph_lib, whatever that is, etc)

I noticed in the directory listing you provided of your examples,
there's a "Makefile" in there, eg:


r...@eric-laptop:/home/eric/BStrou/usingC++4/code/Chapter12# ls
build.batchapter.12.7.2.cppchapter.12.7.6-1.cpp  
chapter.12.7.8-2.cpp  GUI.cpp   index.html.2  MatrixIO.h 
std_lib_facilities.h
ch12try1.cpp chapter.12.7.3-1.cpp  chapter.12.7.6-2.cpp  
chapter.12.7.9-1.cpp  GUI.h index.html.3  Point.h
std_lib_facilities.h.1
chapter.12.3.cpp chapter.12.7.3-2.cpp  chapter.12.7.6.cpp
chapter.12.7.9-2.cpp  image.jpg Makefile  Simple_window.cpp  Window.cpp

 


Can you paste the contents of that Makefile here?
It will probably give us a good idea of what's involved here.

It's possible that just running 'make' is what you need.
However, it depends on the contents of the Makefile, which
may need some small changes to point to where you have fltk2
installed before 'make' will work correctly.

You could try just running 'make'.


Are you sure the book doesn't recommend how to build all the
examples? I can't imagine they'd recommend using g++ to build
these GUI examples.. only very simple non-GUI apps would build
with just 'g++'.

Is the book's example code and documentation online somewhere?

At very least, paste us the Makefile that is in your project
directory, as that file will likely have all the info in it
on how to build all the examples in that directory. (To use
a Makefile, you would run 'make')

> r...@eric-laptop:/home/eric/BStrou/usingC++4/code/Chapter12# g++ 
> -Wno-deprecated chapter.12.3.cpp Simple_window.cpp Graph.cpp GUI.cpp 
> Window.cpp -lfltk -lfltk_images

Hmm, that's an interesting command line snippet; I'm guessing
the book shows something like that in its text?

From the above, it would appear the app you're trying to
compile depends on various other files.

I'm guessing the Makefile will be the most useful thing
you can paste us at this point.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] simple test arc.cxx not compile(1.1.10)

[Greg Ercolano]

eric wrote:
> dear fltk programers:
> 
>   I copy arc.cxx in test directory to fltk-1.1.10 directory
> then compile it by g++ under ubuntu linux
> ---
> r...@eric-laptop:/home/eric/Dfltk/fltk-1.1.10# g++ arc.cxx
> arc.cxx:28:19: error: FL/Fl.H: No such file or directory
> arc.cxx:29:33: error: FL/Fl_Double_Window.H: No such file or directory

You can't just build programs that depend on other libraries
with with just "g++ ".

In the case of FLTK, you would need "-I/home/eric/Dfltk/fltk-1.1.10"
just to fix the "No such file or directory" errors, but you'd also need
many other flags too, which are OS specific.

FLTK comes with a shell script called 'fltk-config' which can make
compiling easy. So instead of 'g++ arc.cxx', try:

./fltk-config --compile arc.cxx

..since fltk-config just happens to be in the same directory.

Or, if you have 'arc.cxx' in some other directory, then use:

/home/eric/Dfltk/fltk-1.1.10/fltk-config --compile arc.cxx

See 'fltk-config --help' for other flags.

Note that a program manipulating images would for instance need the
"--use-images" flag, and an FLTK/opengl app would need "--use-gl", etc.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Grids or Table widgets

[Greg Ercolano]

>> i mean for example imagine a grid of 'buttons'..
> 
>   I'd suggest using an Fl_Tile and procedurally adding
>   the buttons to that with a for() loop.

   Actually, the Fl_Tile isn't even necessary with the procedural
   technique; you can just add the buttons directly to the window
   (or an encompassing group), setting the positions based on the loop.

   The below is a simple example that makes an A-Z dialog window
   of buttons, where each button generates a callback that prints
   the button's label.

   You can resize the window, and all the buttons grow to follow
   its size as you'd expect.

* * *

#include 
#include 
#include 
//
// Make a grid of buttons
//
static void Button_CB(Fl_Widget *w, void*) {
fprintf(stderr, "You hit '%s'\n", w->label());
}
int main(int argc, char **argv) {
char s[2];
int nboxes = 0;
Fl_Window *win = new Fl_Window(220,260, "test");
for ( int yy=10; yyh()-40; yy += 40 ) {
for ( int xx=10; xxw()-40; xx += 40 ) {
sprintf(s, "%c", 'A'+nboxes); ++nboxes; // label for each button
Fl_Button *but = new Fl_Button(xx,yy,40,40);
but->copy_label(s);
but->callback(Button_CB);
}
}
win->resizable(win);
win->end();
win->show(argc,argv);
return(Fl::run());
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Grids or Table widgets

[Greg Ercolano]

Paul R wrote:
> Can anybody advise on my best approach to implement a 'table' or chart where 
> users can select one at a time.
> 
> i mean for example imagine a grid of 'buttons'..

I'd suggest using an Fl_Tile and procedurally adding
the buttons to that with a for() loop.

> I avoided just adding individual buttons set in a tile in fluid
> as i thought it would be a bit unwieldly to add say 26 individual
> button objects but then nobody has to read the code anyhow so...

To make lots of buttons in Fluid is easy..

Make a button, set up the callback and all the properties
you want for that button (color, style, etc).

Then select it and hit ^C then ^V. Now you have two buttons
with the same props.

Highlight the two and ^C/^V so that you have four.

Now highlight the four, hit ^C, then repeatedly hit
^V several times, so that you can quickly place
four buttons at a time quickly into a grid.

Then you can hand tweak each button assigning
a different label to each button and let your call back
look at the widget's label() to determine which button was hit.

Or, just use Fl_Tile and a for() loop.

There's other ways too.

> Basically i can think of a few ways to hancode it, just wondered
> if anything i could whip up with fluid would be available,
> maybe this is a case where you would write a little more code
> in the dialog boxes of Fluid itself? 

If its only 26 buttons, I'd make em by hand. Similar
to the keyboard test program, which is a fluid hand-laid-out
interface.

You can either position the buttons yourself, or stick
them into a tile if you truly want a 'grid'.

> i take it fluid is not an interpreter so i cannot expect
> to be able to see the objects defined this way appear
> in my design editor view..

Right, but if you set up Alt-G, you'll find the
code/compile/run cycle will be so fast, that you
can type code and see a working program within seconds.

(See the FLTK Fluid video for how to do this)

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] button images

[Greg Ercolano]

Duncan Gibson wrote:
> Matthias wrote:
>> In FLTK 1.3, you can use FL_ALIGN_IMAGE_BACKDROP for alignment.
>> It will first draw the boxtype, then draw a centered image, then
>> draw a centered  text.
> 
> Thanks for the reminder of those new features in 1.3, Matt.
> Looks like this old dog needs to learn some new tricks :-)

Added an example program for this to 1.3.x SVN r7740:
examples/howto-text-over-image-button.cxx

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] button images

[Greg Ercolano]

Matthias Melcher wrote:
> In FLTK 1.3, you can use FL_ALIGN_IMAGE_BACKDROP for alignment.
> It will first draw the boxtype, then draw a centered image, then draw a 
> centered text.
> PS: There are a lot of new alignment values in FLTK 1.3... .

Cool! I've added a comment about that on the cheat page
for my 'text over image' examples.

Here's a simple working example showing how to use that flag;
now one doesn't have to derive a widget just to get an image
to appear under button text.


#include 
#include 
#include 
#include 
#include "gradient.xpm"
//
// Demonstrate how to draw text over an image using new FLTK 1.3.x 
"FL_ALIGN_IMAGE_BACKDROP" feature -- erco 10/25/10
// For the example 'gradient.xpm' image, see: 
http://seriss.com/people/erco/fltk/gradient.xpm
//
int main(int argc, char **argv) {
Fl_Pixmap gradient(gradient_xpm); // see 
"gradient.xpm"
Fl_Window *win = new Fl_Window(160, 75, "test");  // create window

Fl_Button *but1 = new Fl_Button(10,10,140,25,"Button 1"); // create custom 
button
but1->image(&gradient);   // assign image 
to button
but1->align(FL_ALIGN_IMAGE_BACKDROP|but1->align());   // enable align 
to use image as a 'backdrop'

win->end();
win->show(argc,argv);
return(Fl::run());
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] button images

[Greg Ercolano]

Matthias Melcher wrote:
> In FLTK 1.3, you can use FL_ALIGN_IMAGE_BACKDROP for alignment.
> It will first draw the boxtype, then draw a centered image, then draw a 
> centered text.
> PS: There are a lot of new alignment values in FLTK 1.3... .

Cool! I've added a comment about that on the cheat page
for my 'text over image' examples.

Here's a simple working example showing how to use that flag;
now one doesn't have to derive a widget just to get an image
to appear under button text.


#include 
#include 
#include 
#include 
#include "gradient.xpm"
//
// Demonstrate how to draw text over an image using new FLTK 1.3.x 
"FL_ALIGN_IMAGE_BACKDROP" feature -- erco 10/25/10
// For the example 'gradient.xpm' image, see: 
http://seriss.com/people/erco/fltk/gradient.xpm
//
int main(int argc, char **argv) {
Fl_Pixmap gradient(gradient_xpm); // see 
"gradient.xpm"
Fl_Window *win = new Fl_Window(160, 75, "test");  // create window

Fl_Button *but1 = new Fl_Button(10,10,140,25,"Button 1"); // create custom 
button
but1->image(&gradient);   // assign image 
to button
but1->align(FL_ALIGN_IMAGE_BACKDROP|but1->align());   // enable align 
to use image as a 'backdrop'

win->end();
win->show(argc,argv);
return(Fl::run());
}

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] button images

[Greg Ercolano]

Greg Ercolano wrote:
>   If you're working with a button, example #2 is what you want, eg:
>   http://seriss.com/people/erco/fltk/TextOverImageFl_Button

Correction; the above link should be:
http://seriss.com/people/erco/fltk#TextOverImageFl_Button
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] button images

[Greg Ercolano]

MacArthur, Ian (SELEX GALILEO, UK) wrote:
>> What is the method to have the text show over the image that 
>> is set as a label? 
> 
> You mean writing the text on top of the image?
> I don't think we support that as a default option.
> 
>> Can this be done or am i just misreading this?
> 
> You need to make a subclass of Fl_Button and then fix up the rendering
> as you want it in the draw() method.
> It's pretty easy to do.
> Also, IIRC, there's working examples of doing this on Greg's site.

Yes, this example:
http://seriss.com/people/erco/fltk/#TextOverImage

There's two examples there; one deriving from Fl_Widget,
the other deriving from Fl_Button.

If you're working with a button, example #2 is what you want, eg:
http://seriss.com/people/erco/fltk/TextOverImageFl_Button

The trick is to override draw(), and tell the widget
to draw itself *first* (eg. call Fl_Button::draw() first),
followed by the image (eg. fl_draw_image()),
then draw the label text last (eg. with fl_draw()).

With the Fl_Button example, it's critical that the image draw
inside the button's border, so it shows the code needed to do
that correctly (eg. Fl::box_dx() and friends).
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Progress and review callback method

[Greg Ercolano]

<>> if(startBtn->label() == "Continue")
>> [..]
>> This would be better:
>> if(strcmp(startBtn->label(), "Continue") == 0)
> 
> yes point taken, i did not check anything in the docs for that one,
> just wrote it in, i will change, but it does compile and run without issue,
> compiled with gcc and all warnings -w ?

It's not illegal to compare the pointer address of strings.
The compiler won't catch such mistakes regardless of what
the compiler warning levels are set to, as it won't know what your
intentions are.

But as coded, it won't compare the /contents/ of the strings,
which is what you wanted. So even if the label() is "Continue",
it will still fail, because the pointers will always be different.

This is standard C char* stuff which really must be understand clearly
or you'll get a lot of seemingly impossible behavior.

When you work with char* strings, the address of the string
is always being used by the compiler. So you have to use the
C library string functions like strcmp() to compare them.

It's only when you work with the more complex data types
like std::string that you can do things like == on strings
to compare them.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] fltk-1.x : parsing command line arguments

[Greg Ercolano]

Duncan Gibson wrote:
> Greg:
>> Duncan; if you submit your example as an STR request for enhancement
>> to 1.3, I'll see about adding it to the FLTK 1.3 examples dir.
> 
> Thanks Greg, but I dusted off my developer's hat and did it myself.

Great, and I see you added it to the Makefile too, perfect.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Comments not working for certain articles

[Greg Ercolano]

Albrecht Schlosser wrote:
>>> On 22.10.2010, at 15:48, Greg Ercolano wrote:
>>>
>>>> I wanted to add some comments to this article:
>>>> http://fltk.org/applications/articles.php?L449+I0+T+P3+Q#_USER_COMMENTS
>>>> .but when I click on the "Submit Comment" button, I get a white page 
>>>> instead of a comment input form.
> 
> I tried this too, and I can *sometimes* see the same effect, but
> sometimes I can get to the comment form. It seems to have to do with
> having logged in or not, but then I can't reproduce it reliably (i.e.
> sometimes I get the login page if I'm not logged in, and it works,
> but sometimes it doesn't work even if I'm logged in (as dev. of course)).

Yes, I've seen the same; it doesn't always happen.

Maybe it's special characters in the URLs that cause the trouble, not 
sure.
Comparing urls for comments that work vs. don't might yield some 
insight.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Comments not working for certain articles

[Greg Ercolano]

Matthias Melcher wrote:
> On 22.10.2010, at 15:48, Greg Ercolano wrote:
> 
>> I wanted to add some comments to this article:
>> http://fltk.org/applications/articles.php?L449+I0+T+P3+Q#_USER_COMMENTS
>> .but when I click on the "Submit Comment" button, I get a white page instead 
>> of a comment input form.
> 
> Please file an STR against the web page. I am not sure who can maintain this 
> though... .
> 

Yes, though looks like there's several bugs already reported
about being unable to make comments.

I know cgi-bin programming pretty well, so maybe I'll take a look.
I /think/ there's a way devs can access the web stuff, I'll see if
I can figure it out.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

[fltk.general] Comments not working for certain articles

[Greg Ercolano]

I wanted to add some comments to this article:
http://fltk.org/applications/articles.php?L449+I0+T+P3+Q#_USER_COMMENTS
.but when I click on the "Submit Comment" button, I get a white page instead of 
a comment input form.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] fltk-1.x : parsing command line arguments

[Greg Ercolano]

> On 22.10.2010, at 10:17, Duncan Gibson wrote:
> > I've never really needed to handle command line arguments in FLTK
> > before because there's always been some menu option or config file.
> > I was pleasantly surprised at how easy it is once you've managed
> > to grok the docs, and decided to post this simple example.
>
> Nice example - I must confess that I also had problems reading
> the docs and wrote my own argument handling when I needed it.
>
> Wouldn't this example fit well in our (1.3) examples directory?
> ;-)
>
> Albrecht

Duncan; if you submit your example as an STR request for enhancement
to 1.3, I'll see about adding it to the FLTK 1.3 examples dir.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] On Magic Numbers

[Greg Ercolano]

Paul R wrote:
> One thing that has been a sticking point for me though is managing where 
> widgets appear and code when you select new items to include. they seem to 
> pop up at the bottom or in middle of classes even when i selected other areas.
> but in the video there is some 'dragging' around of items to remedy this, how 
> is that done? i dont think i remember a guide to keyboard shortcuts in the 
> manual

To move widgets up and down in the list, highlight the ones you
want to move, and hit F2 or F3 to move them up or down respectively.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] On Magic Numbers

[Greg Ercolano]

Paul R wrote:
>> http://seriss.com/people/erco/fltk-videos/fluid-intro.html
> i dont even know if it has sound but its illustrative enough as it is [..]

Yes, it has sound, definitely.
I'd advise seeing it with sound for sure.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] On Magic Numbers

[Greg Ercolano]

Have a look at the beginner's video tutorial to get a quick idea
on how to play with fluid.

http://seriss.com/people/erco/fltk-videos/fluid-intro.html

Regarding eg. callback and typing into small dialogs, keep in mind
that in these small dialogs, instead of entering all the code for
your callback, you can simply call a function (eg. MyCallback())
and then define the code for that either in a file that you #include
from within your fluid file, or you can define a function within fluid
(eg. New -> Code -> Function followed by New -> Code) so that you can use
a regular text editor window to edit the code, or define a new method as
part of your class defined within fluid.

Inside fluid, you can define a class (New -> Code-> Class), and either derive
it from an FLTK widget (Fl_Window, Fl_Group, etc), or just add widgets to it.
Either way you can then add methods to the class using New-> Code -> Function
and New->Code->Code.

If you don't like using Fluid to define methods, you can do a mix of using
fluid to define some methods, and setting up an #include within fluid
that includes your own file that has method implementations. I do this
myself in some cases where I have a very large application class that has
numerous methods; some Fluid oriented (eg. large menu and dialog definitions)
and some not (utility methods).

I would start by playing around with fluid; you'll get the feel by starting
small, and playing with things.

You should never have to hand edit fluid files; you can use features it has
to either #include or code your own stuff in a way that keeps fluid and your
hand-crafted code separate. Either use separate classes (eg. fluid classes
that derive from your hand made classes) or vice versa (your hand made classes
that derive from your fluid generated classes, like hand-layouts of dialogs).

In many cases I've used fluid to do 'the whole shebang'; the main(), an defining
numerous hand-layout GUI classes including not only the main application, but
of all of its dialogs, and even small classes that might themselves be 'widgets'
of sorts that can be duplicated procedurally.

One of these days I need to make an 'Advanced Fluid' video to follow up to
the above beginner one..

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] fltk-1.1.10: fl_draw(const char* s, int x, int y)

[Greg Ercolano]

Duncan Gibson wrote:
> So I've incorporated the fl_draw() call in an old example that I
> posted several years ago. Basically I want something simple like:
> 
> char buffer[32];
> sprintf(buffer, "%d", value);
> fl_draw(buffer, x() + 30, y() + 30);

Hi Duncan!

Don't forget to set the font ;) eg. fl_font().

FLTK will crash if the font isn't set before the fl_draw() call.


___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] I can't compile FLTK!

[Greg Ercolano]

Stewart wrote:
> I get heaps of errors saying . 

I'm guessing you might have an incomplete install of Visual Studio 
Express,
ie. have not installed the "platform SDK".

VS Express 2005 (the compiler/IDE) is an oddball from the previous 
releases of
VS in that they separated the compiler/IDE from the 'platform SDK'.

Both are "free", but you have to install them separately for some 
reason.
And the platform SDK, IIRC, is a PITA to install correctly.

You'll need to install the platform SDK before you can get VSE to build
any kind of windows apps; not just FLTK, but even tiny WIN32 apps that
have #include  at the top.

For more info, see:

http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/2bfed529-fb6d-48a3-ad48-fc6301486646/

Note that this seems to be solved in the VSE 2008 release, where
you can download/install and be able to build WIN32 apps without
doing the separate 'platform SDK' install.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Undefined reference to fl_graphics_driver

[Greg Ercolano]

If you're only getting the problem when building your own code,
but not when building FLTK itself, check your code for casing typos
for the #include files. a common mistake is #include 
instead of #include  (note case on first 'L')

Such a problem could cause your #include's to come from a previously
'installed' FLTK (eg. /usr/include/) instead of the lib your building
against, eg. /usr/local/src/fltk-x-x-x/.


Marc R.J. Brevoort wrote:
> On Sat, 9 Oct 2010, Ian MacArthur wrote:
> 
>> It is *possible* that your tabs problem is related though, I have in the
>>  past accidentally created Frankenstein builds that were part 1.1 and
>> part 1.3 and the code sometimes would actually run, but then do very odd
>> things...
>>
>> I guess a complete clean and rebuild wouldn't hurt, just in case.
> 
> Well, I guess I'll have to search on. After doing this, I'm still
> getting the same behaviour. It's only on that particular tab, too.
> 
> What happens is that that particular tab is showing fragments of
> other tabs which it seems to be redrawing even though they're not
> visible. The strange bit is, only tabs previously visited will
> blend into the tab exhibiting this *weird* behaviour.
> 
> I can't imagine what could be causing it. I guess I'll try a
> full clean and a rebuild with 1.1.7 to see if that does
> anything (I *know* I've at least seen things work fine with
> 1.1.7 so maybe that will help me rule out some kind of
> regression).
> 
> Best,
> Marc
> 
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] compiling fltk-1.1.10 onwindows764bitwithgcc-4.5.1 from mingw64

[Greg Ercolano]

Ian MacArthur wrote:
> Greg Ercolano wrote:
>> MacArthur, Ian (SELEX GALILEO, UK) wrote:

>>> OK - anyone got a 64-bit big-endian system? Must be someone with a PPC64
>>> box somewhere I guess?

>>  I think my old SGI Indigo2 Extreme might qualify..

> Is that the one that doubles as a room-heater?

It sure does!
And on a hot day like today, very noticeable.
Turned its switch off immediately after testing.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] compiling fltk-1.1.10 on windows764bitwithgcc-4.5.1from mingw64

[Greg Ercolano]

Greg Ercolano wrote:
> MacArthur, Ian (SELEX GALILEO, UK) wrote:
>>>> I don't have
>>>> access to a big-endian 64-bit system to actually verify it on...!
>>> Thanks, I saw it in fltk.commit. I can't test it either (I'm prepared
>>> to install a 64-bit Ubuntu VM soon, though), but the code looks good
>>> to me, AFAICS.
>> OK - anyone got a 64-bit big-endian system? Must be someone with a PPC64
>> box somewhere I guess?
> 
>   I think my old SGI Indigo2 Extreme might qualify..

Latest fltk 1.3.x seems to build OK (with some fixes to unrelated code).
So e.g. in Fl_Preferences.cxx, the 'WORDS_BIGENDIAN' section compiled
without error.

Wasn't sure how to test it exactly, so I made a small foo.cxx
app with the BIGENDIAN code inserted in:

---
#include 
#include 
int main() {
 time_t t = 1234;
 unsigned char b[20];

  union { void *pv; unsigned char a[sizeof(void*)]; } v;
  v.pv = (void *)(&t);

  // BIG ENDIAN
  b[8]  = v.a[sizeof(void*) - 1];
  b[9]  = v.a[sizeof(void*) - 2];
  b[10] = v.a[sizeof(void*) - 3];
  b[11] = v.a[sizeof(void*) - 4];

 printf("%p %02x %02x %02x %02x\n", (void*)&t, (unsigned int)b[8], 
(unsigned int)b[9], (unsigned int)b[10], (unsigned int)b[11]);
 return(0);
}
---

When compiled and run, the result on the SGI (with -64 enabled):

---
# CC -64 -fullwarn -o foo foo.cxx
# ./foo
ffae80 80 ae ff ff
---

I guess that's "right"?

I tried changing the address to 0x9876543210 just to
make it obvious, then ran the code again to make sure
those bottom 4 bytes were being used, and result was
as expected:

---
# CC -64 -fullwarn -o foo foo.cxx
huron 61# ./foo
9876543210 10 32 54 76
  \/\/\/\/ |  |  |  |
   | | | |_|  |  |  |
   | | |__|  |  |
   | |___|  |
   ||
---
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] compiling fltk-1.1.10 on windows764bitwithgcc-4.5.1 from mingw64

[Greg Ercolano]

MacArthur, Ian (SELEX GALILEO, UK) wrote:
>>> I don't have
>>> access to a big-endian 64-bit system to actually verify it on...!
>> Thanks, I saw it in fltk.commit. I can't test it either (I'm prepared
>> to install a 64-bit Ubuntu VM soon, though), but the code looks good
>> to me, AFAICS.
> 
> OK - anyone got a 64-bit big-endian system? Must be someone with a PPC64
> box somewhere I guess?

I think my old SGI Indigo2 Extreme might qualify..
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] compiling fltk-1.1.10 on windows 764bitwithgcc-4.5.1 from mingw64

[Greg Ercolano]

Ian MacArthur wrote:
> So, without any testing whatsoever, here's a guess; try this -
> 
> //unsigned int a = (unsigned int)&t; // four more bytes
>  union { void *pv; unsigned char a[sizeof(void*)]; } v;
>  v.pv = (void *)(&t);
>  // we will extract 4 more bytes from the address of t
>  b[8] = v.a[0];
>  b[9] = v.a[1];
>  b[10] = v.a[2];
>  b[11] = v.a[3];

Nice! Yes, that's definitely The Right Way in this case;
exactly what unions are for.

That compiles fine on my 64bit linux machine with -Wall,
and generates expected results. Made a test program to check it:


#include 
#include 
int main() {
 time_t t = 1234;
 unsigned char b[20];
 union { void *pv; unsigned char a[sizeof(void*)]; } v;
 v.pv = (void *)(&t);
 // we will extract 4 more bytes from the address of t
 b[8] = v.a[0];
 b[9] = v.a[1];
 b[10] = v.a[2];
 b[11] = v.a[3];
 printf("%p %02x %02x %02x %02x\n", (void*)&t, (unsigned int)b[8], 
(unsigned int)b[9], (unsigned int)b[10], (unsigned int)b[11]);
 return(0);
}


Result on my x64 ubuntu:


r...@delta:/var/tmp# g++ -Wall -o foo foo.cxx

r...@delta:/var/tmp# ./foo
0x7fff86b85318 18 53 b8 86
   | | | |  |  |  |  |
   | | | |__|  |  |  |
   | | |___|  |  |
   | ||  |
   |_|
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] compiling fltk-1.1.10 on windows 764bitwithgcc-4.5.1 from mingw64

[Greg Ercolano]

Gabriel Striewe wrote:
> Fl_Preferences.cxx: In static member function 'static const char* 
> Fl_Preferences::newUUID()':
> Fl_Preferences.cxx:140:37: error: cast from 'time_t*' to 'unsigned int' loses 
> precision

Sounds like it's this section:

  if(got_uuid == 0) { // did not make a UUID - use fallback logic
unsigned char b[16];
time_t t = time(0); // first 4 byte
b[0] = (unsigned char)t;
b[1] = (unsigned char)(t>>8);
b[2] = (unsigned char)(t>>16);
b[3] = (unsigned char)(t>>24);
int r = rand(); // four more bytes
b[4] = (unsigned char)r;
b[5] = (unsigned char)(r>>8);
b[6] = (unsigned char)(r>>16);
b[7] = (unsigned char)(r>>24);
unsigned int a = (unsigned int)&t; // four more bytes   <---
b[8] = (unsigned char)a;<---
b[9] = (unsigned char)(a>>8);   <---
b[10] = (unsigned char)(a>>16);
b[11] = (unsigned char)(a>>24);

It appears it's trying to convert the address of the local variable t
into separate unsigned bytes to 'pad out' a UUID construction.

In this case it appears to be immaterial what the 4 bytes are;
The four bytes above it are even random.

I imagine due to the compiler, the address of 't' could easily
be the same on each call since it's a stack variable. Could probably
just be another random number, or re-arranged with the pointer trick.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Fl_Tree Keyboard Navigation Input

[Greg Ercolano]

I should end this thread by saying I made some large SVN commits (r7691, r7692)
that adds all the Fl_Tree patches listed here, and more back on August 26 2010.

Namely:
r7691: http://fltk.org/newsgroups.php?gfltk.commit+v:8075
r7692: http://fltk.org/newsgroups.php?gfltk.commit+v:8076

So if you want the latest Fl_Tree stuff, either check out the current SVN 1.3.x
to get all the features to date. For the to-do list, search the r7691 link above
for "TODO:"
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] compiling fltk-1.1.10 on windows 7 64bit withgcc-4.5.1 from mingw64

[Greg Ercolano]

MacArthur, Ian (SELEX GALILEO, UK) wrote:
>> I tried to use mingw-gcc with the option CC="gcc -m32" to 
>> build a 32bit-binary,
>> but it gave me the same error. 
> 
> Hmm, odd. I'd have thought that would work... Dunno...

Would probably have to add -m32 to the "CXX" macro as well as "CC",
since CC is only used for compiling C source files.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] compiling fltk-1.1.10 on windows 7 64bit withgcc-4.5.1 from mingw64

[Greg Ercolano]

MacArthur, Ian (SELEX GALILEO, UK) wrote:
>> I tried to use mingw-gcc with the option CC="gcc -m32" to 
>> build a 32bit-binary,
>> but it gave me the same error. 
> 
> Hmm, odd. I'd have thought that would work... Dunno...

Would probably have to add -m32 to the "CXX" macro as well as "CC",
since CC is only used for compiling C source files.

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Create an array of Fl_Input* and populate a double array onchange

[Greg Ercolano]

I'd do it this way (below).

Didn't try to debug your code, as problem might be elsewhere in code.
In your callback, instead of using o->userdata(), use 'v', as that's
your userdata in a simple form.

To debug your segfaults, print the value of 'pUI' and tmpfiltermatrix[i]
before atof() line, since one of them is probably NULL or wild.

Yes your callback needs to be static, but as shown below, you can
have static callback invoke non-static callback by dereferencing your UI*
so that your non-static callback can then have free reign over your class.

When you run the following, the Fl_Input's will show the data[] array's values,
and when you make changes to any field, the data[] array is modified, and entire
data array printed to stdout so that you can see it change.

* * *

#include 
#include 
#include 
#include 
#include 
//
// Demonstrate using Fl_Input's to manage an array
// erco 10/09/05
//
class MyUI : public Fl_Window {
int data[10];   // integer data to be managed
Fl_Input *in[10];   // array of Fl_Input widgets

// Nonstatic callback
void HandleInput() {
for ( int i=0; i<10; i++ ) {
if ( sscanf(in[i]->value(), "%d", &data[i]) != 1 ) {// 
assign input string to data array element
fl_message("The string '%s' for input #%d is not an integer", 
in[i]->value(), i);
}
// Print modified data array to screen so we can see it
printf("data[%d] is now %d\n", i, data[i]);
}
printf("---\n");
}

// Raw callback
static void HandleInput_CB(Fl_Widget *w, void *v) {
MyUI *ui = (MyUI*)v;// userdata is pointer to class
ui->HandleInput();  // invoke non-static callback
}

public:
// CONSTRUCTOR
MyUI(int W,int H) : Fl_Window(W,H) {
// initialize array, create input widgets and assign each an item in 
array
char label[80];
char val[80];
for ( int i=0; i<10; i++ ) {
data[i] = i * 100;  // initialize 
data array to some values
sprintf(val, "%d", data[i]);// string 
version of data value for Fl_Input
sprintf(label, "Item %d:", i);  // label of 
Fl_Input that includes index#
in[i] = new Fl_Input(100,10+i*30,100,25);   // create input 
widget, save
in[i]->copy_label(label);   // label it 
with item# for clarity
in[i]->callback(HandleInput_CB, (void*)this);   // assign 
callback too data element
in[i]->value(val);  // initialize 
input field to data[]'s value
in[i]->when(FL_WHEN_CHANGED);
}
}
};
int main() {
MyUI win(300, 500);
win.show();
return(Fl::run());
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] compiling fltk-1.1.10 on windows 7 64bit withgcc-4.5.1 from mingw64

[Greg Ercolano]

Gabriel Striewe wrote:
> ../FL/Fl_Widget.H: In member function 'long int Fl_Widget::argument() const':
> ../FL/Fl_Widget.H:158:39: error: cast from 'void*' to 'long int' loses 
> precision

Note to devs: same issue exists in 1.3.x, since it's complaining about 
this line:

FLTK 1.1.10: long argument() const {return (long)user_data_;}
FLTK 1.3.x:  long argument() const {return (long)user_data_;}

I believe in OP's context, 'void*' is 64bit, but long is 32bit.

In this usage it should be OK, as the void* is being used as
storage for a long, so the fact that it's larger than the data
we're storing shouldn't be an issue in this case; as long as the
value in the void* is a long, no precision loss should occur
if we take it back out as a long, assuming void* is large enough
(which it is in this case).

This ugly hack might sufficiently fool the compiler, at least
for another 10 years, LOL:

long argument() const {return *((long*)user_data_);}

I'm not sure what the 'right' solution is, or if there even
is one for what's being done here.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] displaying data variables dynamically

[Greg Ercolano]

paul wrote:
> hi can anyone suggest a way to output fast changing data, float percentages,
> counter integers etc? do i have to use an output box and mess with string
> conversion and clearing box all time or is there a native printf style 
> formatted call?

Just about anything should work including just changing the label of a 
box.

String conversion is unavoidable, as somewhere along the line the value
has to be converted to a string to be printed. Regardless, the speed of
this will be faster than your eye can perceive, and likely faster than
the graphics adapter can display the font.

I'd suggest using sprintf() to a string, and display the string.
Use an Fl_Box if you want the data to appear on a background, eg:

// Init
box = new Fl_Box(...);
box->box(FL_FLAT_BOX);
box->align(FL_ALIGN_INSIDE|FL_ALIGN_LEFT);

..then whenever you want to update the data to the screen:

// Your data update callback
void UpdateCallback() {
static char s[200];
sprintf(s, "VAL=%d FVAL=%f YVAL=%ld ..", ...);
box->label(s);
box->redraw();
}

You won't have to do the clear, as the label will redraw itself
correctly, since the box is an FL_FLAT_BOX and the text is drawn
inside the box.

Or, as Albrecht described, use Fl_Output and friends, which essentially
does some of the above for you. But if the string of values you're
printing is a complex long printf() style statement, the above is a good
way to go with sprintf()/snprintf()/etc.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] FLTK only returns 5-bit OpenGL color buffers, not 8-bit?

[Greg Ercolano]

Marc Levoy wrote:
> I can't thank you enough for your help - both
> you and Greg.  On the off-chance you might be curious to know
> what my program should look like, I've posted a screenshot at:
> http://graphics.stanford.edu/~levoy/sap-screenshot.jpg

Nice!

BTW, you should try adding:

Fl::scheme("gtk+");

..at the top of your main(), and see if you like the widgets.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Fl_File_Icon ::load_xpm() missing?

[Greg Ercolano]

Roman Kantor wrote:
> I want to load file icon from in-compiled xpm array,
> the documentation (for fltk-1.1.10) describes method as
> 
>   Fl_File_Icon::load_xpm(const char *xpm);
> 
> But this function does not seem to exist at all.
> Also the format for xpm seems not to be correct - xpm should be rather 
> pointer to the array of strings (so sort-off double pointer)?
> Am I missing something?

I did a "grep -r load_xpm ." in FLTK 1.3.x and found this comment
in the CHANGES for 1.1.0b6:

- Fl_File_Icon now uses Fl_Shared_Image to load icon
  images; the load_png() and load_xpm() methods have
  been replaced by a single load_image() method.

So apparently the 1.1.10 docs need to be corrected.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] FLTK only returns 5-bit OpenGL color buffers, not8-bit?

[Greg Ercolano]

Also, did a test with 1.1.10 + Snow Leopard 10.6.4/intel:

[r...@snow] 35 # ./foo
FLTK version = 1 1 10   <--
clipping::handle()
clipping::handle()
clipping::handle()
clipping::draw()
redbits = 8 <--
clipping::draw()
redbits = 8 <--

Built the 1.1.10 from scratch with default flags.

If you plan on running on the latest OSX, then you should probably
use 1.1.10, as it's the most recent in the 1.1.x series.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] FLTK only returns 5-bit OpenGL color buffers, not 8-bit?

[Greg Ercolano]

Marc Levoy wrote:
> aosta.stanford.edu:~/projects/sap% ./test
> FLTK version = 1 1 7
> clipping::handle()
> clipping::handle()
> clipping::draw()
> redbits = 5
> ^C

FWIW, FLTK 1.3.x + Snow Leopard (10.6.4) on a 64bit intel works OK:

[r...@snow] 8 # fltk-config --use-gl --compile foo.cxx
[..]
[r...@snow] 11 # sw_vers
ProductName:Mac OS X
ProductVersion: 10.6.4  <--
BuildVersion:   10F569

[e...@snow] 22 # ./foo
FLTK version = 1 3 0
clipping::handle()
clipping::handle()
clipping::handle()
clipping::draw()
redbits = 8 <--
clipping::draw()
redbits = 8 <--
clipping::handle()
clipping::handle()
clipping::handle()
clipping::handle()
^C

I tried building 1.1.7 from scratch on Snow Leopard but got lots of 
errors,
most likely due to fltk 1.1.7 predating Snow Leopard by several years.
(snow leopard 10.6 released August 2009, FLTK 1.1.7 released Jan 2006.)

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] FLTK only returns 5-bit OpenGL color buffers, not 8-bit?

[Greg Ercolano]

Marc Levoy wrote:
> For an important but infrequently used program based on FLTK, I have suddenly
> found that it is able to obtain only 5-bit color buffers (5+5+5 instead of
> 8+8+8), causing my application to mis-perform.  (I read back the frame buffer,
> so the bitdepth is important to the proper function of the program.)

Does it make a difference if you're using Fl_Window vs. 
Fl_Double_Window?

Sometimes double buffering can limit color resolution, and possibly
something in FLTK changed in the way it initializes that affects
openGL in this way that we can identify and fix.

Also, if you can provide a small FLTK opengl program that shows the 
problem,
that would help.

I'm assuming you're using opengl calls to read back the color depth
and getting 5bit instead of 8bit. Giving us a /small/ program that
shows this (ie. sets up opengl and prints the bit depth values to the 
console)
would really help us track it down.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Attempting to show() a Window

[Greg Ercolano]

Greg Ercolano wrote:
>   Looking at the intentions of your TestWin class,
>   here's what I think you want:
> 
>  snip
> [..]
>  snip

One thing I forgot in that last example is to end() NuWin.

Small mod to last program plus some added comments for clarification.

#include 
#include 
#include 
#include 

// Create a custom class
class TestWin : public Fl_Double_Window
{
Fl_Button *But; // button we'll use to invoke callback
Fl_Double_Window *NuWin;// pointer to second window we show 
when button pushed

// Callback defined inside class
static void Button_CB(Fl_Widget *w, // this pointer will be the button 
itself
  void *v)  // this will be a pointer to the 
TestWin instance ('this' or 'self')
{
TestWin* tWin = (TestWin*)v;// userdata is pointer to self
tWin->NuWin->show();// resolve NuWin through pointer to self
}

public:
// Ctor
TestWin(int w, int h, const char* c=0) : Fl_Double_Window(w,h,c)
{
// Create button inside window
But = new Fl_Button(40, 50, 75, 30, "CB Test");
But->callback(Button_CB, (void*)this);  // configure 
callback with userdata as pointer to self
end();  // end main 
window

// Create a separate physical window
NuWin = new Fl_Double_Window(50, 100, "Hooray!");   // create new 
window, save pointer to it
NuWin->end();   // end new 
window
}
};

int main()
{
TestWin *tWin = new TestWin(150,150,"Test");// create instance of 
custom class
tWin->show();   // show the custom 
class window
return(Fl::run());
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Attempting to show() a Window

[Greg Ercolano]

Looking at the intentions of your TestWin class,
here's what I think you want:

 snip
#include 
#include 
#include 
#include 

class TestWin : public Fl_Double_Window
{
Fl_Button *But;
Fl_Double_Window *NuWin;

// Callback inside class
static void Button_CB(Fl_Widget* w, void* v)
{
TestWin* tWin = (TestWin*)v;// userdata is pointer to self
tWin->NuWin->show();// resolve NuWin through pointer to self
}

public:

// Ctor
TestWin(int w, int h, const char* c=0) : Fl_Double_Window(w,h,c) {
// Create button inside window
But = new Fl_Button(40, 50, 75, 30, "CB Test");
But->callback(Button_CB, (void*)this);  // configure callback 
with userdata as pointer to self
end();

// Create a separate physical window
NuWin = new Fl_Double_Window(50, 100, "Hooray!");
}
};

int main()
{
TestWin *tWin = new TestWin(150,150,"Test");// create instance of 
custom class
tWin->show();   // show the custom 
class window
return(Fl::run());
}
 snip
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Attempting to show() a Window

[Greg Ercolano]

Kjell wrote:
> Hi,
> 
> I've recently taken to experimenting with this graphics library and have
> had some success with it so far.

Just as a side, you may want to look at these links if you haven't
already:

FLTK CHEAT PAGE:
http://seriss.com/people/erco/fltk/

FLTK FIRST TIME USER VIDEO TUTORIALS
http://seriss.com/people/erco/fltk-videos/

> I'm developing my own application with
> the limited knowledge that I have of programming but consider myself an
> intermediate programmer.

The one big problem in the code is the callback tries to manipulate
the userdata argument "void*v", but when you set up the callback, you're
not passing in any user data. So at runtime *v in the callback will 
likely
be NULL, causing a runtime error.

See below.

> int main()
> {
>   Fl_Double_Window* Win = new Fl_Double_Window(150,150, "Test");
>   Win->begin();
> 
>   Fl_Button* But = new Fl_Button(40, 50, 75, 30, "CB Test");

After the above line, you probably want "Win->end();"
so that your NuWin doesn't become parented (inside of) Win.
(I'm assuming you want NuWin as a separate window. If not,
disregard this recommendation)

>   Fl_Window* NuWin = new Fl_Window(50, 100, "Hooray!");

After this, do your NuWin->end();
regardless of the intention of the above.

>   But->callback(Button_CB);

Here lies the problem: the second argument is supposed to be the
userdata; you can leave it unset if you don't plan to use the userdata
in your callback.. but down below it appears you DO try to use it,
so you should set it here; change the above line to read:

But->callback(Button_CB, (void*)NuWin);

..so that the NuWin pointer is passed as the void userdata
to the callback. See below for a needed change to the callback.

So in all, basically you want:

// Define main window
Win = new Fl_Double_Window(..);
But = new Fl_Button(..);
Win->end();
Win->show();

// Define second window
Fl_Window *NuWin = new Fl_Window(..);
But->callback(Button_CB, (void*)NuWin);
NuWin->end();

> void Button_CB(Fl_Widget* w, void* v)
> {
>   TestWin* tWin = (TestWin*)v;
>   tWin->NuWin->show();
> }

Not sure what TestWin is doing here since you don't
actually create a TestWin instance.

I think what you might want instead is:

void Button_CB(Fl_Widget* w, void* v)
{
Fl_Window *NuWin = (Fl_Window*)v;
NuWin->show();
}

If you DO want to use TestWin, then create an instance of it, eg:

// Define second window
TestWin *NuWin = new TestWin(..);   // USE 
"TestWin" INSTEAD OF "Fl_Window"

..and change your callback similarly:


void Button_CB(Fl_Widget* w, void* v)
{
TestWin *NuWin = (TestWin*)v;
NuWin->show();
}

But note that your TestWin class is missing some stuff,
namely the constructor is missing the ": Fl_Window(w,h,c)",
and also the pointers inside are not being initialized to
anything. That class definition will need more work to do
what you want.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Scrolling Fl_Help_View?

[Greg Ercolano]

Marc R.J. Brevoort wrote:
> Hello Domingo,
> 
>> If do you want to try a slight modified version of Fl_Help_view have a
>> look at http://code.google.com/p/luafltk/.
>> I did some modifications that aren't well accepted to be in the official
>> distribution but it helped me get a better result for my purposes.
> 
> What kind of modifications if I may ask?
> 
> Best,
> Marc
> 

There was a thread back in March 2010 on fltk.development about this;
do a search on the webforum for (including quotes):

"Fl_Help_View code cleanup"

Thread started with:
http://fltk.org/newsgroups.php?gfltk.development+v:9351
..which has a description of the changes. Possibly other
changes were added as that thread continued.. it was a long
thread, don't remember details.

Probably very reasonable code fixups, but unfortunately it included
code /reformatting/ that made diffing and regression checking difficult,
and apparently made the code less compatible with the FLTK coding standards
due to the formatting changes, causing these responses:

http://fltk.org/newsgroups.php?gfltk.development+v:9354
http://fltk.org/newsgroups.php?gfltk.development+v:9355

I don't think the mods were rejected on technical merit,
just that the code reformatting made it un-diff'able..
and since Fl_Help_View's code is a bit of a bear, we need
to track it carefully.

Thread got into a few side tracking issues (using code re-indenter's,
issues of static strings, etc), but I think if Domingo went back to the
original source, and made the code changes without reformatting/indenting the
code, and kept the new code in CMP format, and the old code untouched so that
it can all be diff'ed easily, it probably would have been excepted.

I know I myself have had to do such seemingly redundant things in the past
on this and other projects to ensure diff's were minimal.. it's part of the
process of joining on with a code base managed by multiple people; it's 
important
to keep diffs as small as possible.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Scrolling Fl_Help_View?

[Greg Ercolano]

Marc R.J. Brevoort wrote:
> On Wed, 1 Sep 2010, Albrecht Schlosser wrote:
> 
>>> is there any way to programmatically scroll an
>>> Fl_Help_View all the way down?
> 
>> void Fl_Help_View::topline (int top)
>> I didn't test/use it, but the docs say:
>> "If the given pixel value top is out of range, then the text is scrolled
>> to the top or bottom of the document, resp."
>> Thus, setting a very high top value ought to do it.
> 
> That worked- sort of. Actually it scrolls so far down
> then that the content of the screen scrolls off the
> top of the screen.

I think topline() uses size() to determine the max,
so if you use help->topline(help->size() - help->h());
this would probably get you right to the bottom. eg:

#include 
#include 
int main(int argc, char *argv[]) {
  if ( argc < 2 )
{ fprintf(stderr, "usage: %s /path/to/foo.html\n", argv[0]); exit(1); }
  Fl_Window win(300,300);
  Fl_Help_View *help;
  help = new Fl_Help_View(10,10,300-20,300-20);;
  help->load(argv[1]);
  help->topline(help->size() - help->h());  // <<<--
  win.end();
  win.resizable(win);
  win.show();
  Fl::run();
  return(0);
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Animated GIFs - Examples and further thoughts

[Greg Ercolano]

> On Wed, 1 Sep 2010, MacArthur, Ian (SELEX GALILEO, UK) wrote:
> 
 I note that you have used std::vector to hold the animation
 frames...

FWIW, I have an array template class that is very light
(<500 lines) and uses only rudimentary template features.
Very simple workhorse, been using it for years. It handles
generic things; arrays of classes, pointers, and the standard
datatypes. Intuitive usage with [] and integer indexes,
and simple insert/delete functions, sort/qsort/swap and
other simple features. Could make doxygen comments for it.

Or, I could make non-template oriented class that handles arrays
of generic pointers to things. Ditto for linked lists.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Buttons Being Spontaneously Relabeled ?

[Greg Ercolano]

Greg Ercolano wrote:
>   What you don't want to have is this:
> 
>   {
>   char s[80]; sprintf(s, "Frame %04d", 1234);
>   widget.label(s);// BAD! (s goes out of scope 
> before widget does)
>   }
> 
>   ..or this:
> 
>   {
>   static char s[80];
>   sprintf(s, "Frame %04d", 1234); widget1.label(s);   // OK: 
> s is static
>   sprintf(s, "Frame %04d", 4567); widget2.label(s);   // BAD! 
> Reusing s[] will cause widget1 and widget2 to have same value
>   }

   Oh, and I forgot to mention; in those above cases where using label() is bad,
   using copy_label() would work, because then the widget makes a copy of the 
string
   that is managed by the widget internally.

   Why not always use copy_label()? You can, and it will be safe,
   it's just that this makes copies in all cases, even situations where
   a copy isn't needed.

   For instance, widget.copy_label("Test"); makes an 'unnecessary copy'
   because "Test" is a static string that is part of your binary, and
   will remain allocated, but copy_label() will make another copy of it
   in dynamic memory. Just an extra 5 bytes you might say, but in a large
   program it can add up.

   Typically widgets are part of classes, and classes can often keep
   track of the data more efficiently. So a good use of label() with
   dynamic strings would be:

class MyClass {

// Dynamic strings to hold name and address
std::string name;
std::string addr;

// Box widgets for name/address
Fl_Box *name_box;
Fl_Box *addr_box;

   [..]
MyClass::LoadData(char *filename) {
[[..load strings from file..]]

name_box->label(name.c_str());  // OK: 'name' string 
lasts as long as box
addr_box->label(address.c_str());   // OK: 'addr' string 
lasts as long as box
}

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Buttons Being Spontaneously Relabeled ?

[Greg Ercolano]

Mike Werner wrote:
> Has anyone run into the situation where some of their widgets were being 
> spontaneously relabeled?

It sounds like you might be using label() instead of copy_label().

label() does not make a copy of the string, it uses the string
passed to it. This means if that string is changed later or is
deallocated, the behavior of the widget will follow those changes.

Only use label() if you're setting the label to a fixed string
or to a string that for sure will remain allocated for as long
as the widget being labeled. eg:

widget.label("Testing");// OK


{
static char s[80]; sprintf(s, "Frame %04d", 1234);
widget.label(s);// OK: s is static
}

What you don't want to have is this:

{
char s[80]; sprintf(s, "Frame %04d", 1234);
widget.label(s);// BAD! (s goes out of scope 
before widget does)
}

..or this:

{
static char s[80];
sprintf(s, "Frame %04d", 1234); widget1.label(s);   // OK: 
s is static
sprintf(s, "Frame %04d", 4567); widget2.label(s);   // BAD! 
Reusing s[] will cause widget1 and widget2 to have same value
}

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Animated GIFs- Update

[Greg Ercolano]

MacArthur, Ian (SELEX GALILEO, UK) wrote:
> And: Should we even be maintaining our own GIF decoder now? The (LZW)
> patents have lapsed, so we could maybe incorporate libgif (or similar)
> as we do libpng et al, and thus gain the ability to read and write GIF
> files, and process animated GIF and so forth...?

I believe one reason for the internal gif is to allow
FLTK to be compiled without dependence on external libs.

It sucks when people can't even build the toolkit without
first having to build a bunch of other potentially bloated libs,
and find they can't match up the versions for one reason or another,
due to the mix of OS/compiler dependencies.

Things got a lot easier when just the simple image readers
were pulled into the distro. The idea is anyone wanting more
would simply link against other libs.

The HTML widget is a tough one, because it can potentially
be dependent on many, many libs. Sound, network, plugins..
FLTK is supposed to be light, so we don't want the internal
dependencies to get large.

I figure anyone wanting real web browser capabilities
should use external browser libs for that, since that
gets complex quickly, and link them into their FLTK apps.
There are several out there, but I don't use them.

In my case, when I want browser capabilities that's more than
Fl_Help* can provide, I use fl_open_uri() to open the local web browser.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk