On 30 Oct 2012, at 19:49, Patrick wrote: > So I have been practising with fltk and most of it is straight forward. > > I was just hoping to get some clarifications. > > I am still a bit weak with C/C++
There are many tutorials for C++ online that will probably help here. Be worth a look at any rate. > in this snippet: > Fl_Window *window = new Fl_Window(340,180); > > is "window" actually a child struct that is initialized by the FL_Window > struct and then partially propagated with values be the new FL_Window call? You need to google for some notes on C and C++ syntax, but here goes anyway: Fl_Window *window That says: The variable name "window" represents a pointer (the *) to a widget of type Fl_Window. new Fl_Window(340,180); That says: Create (on the heap) a new widget of type Fl_Window, of size 340,180 pixels, and return a pointer to it. The returned pointer is then stored in the variable "window" for later use. > In this case is Fl_Window referring to both a struct and a method ? Technically Fl_Window is referring to a "class" here (though a class and a struct are essentially similar, that may be a level of detail you want to just ignore for now!) The first occurrence is the class type, the second occurrence is the constructor method of the class. In C++, classes and their constructors have the same names. This looks confusing and redundant! The Fl_Window class is a widget object that knows how to make an actual GUI window on whatever host operating system you are building the code for. > There are lots of "includes" in fltk programs: > #include <FL/Fl.H> > #include <FL/Fl_Window.H> > #include <FL/Fl_Box.H> > > > Is this so that we only have to pay for what we use? In effect, yes. Encapsulation and all that; each header contains only the parts that it needs, to keep things separate and hence easier to maintain. Contrast this with the MS practice of sticking *everything* in one header "windows.h"... > Is the libfltk.a archive a small piece of glue code to tie together the > functionality of the various includes. It's 2 mb, so i am guessing there > isn't so much in there. That is the whole of fltk - that lib contains the binary blobs that form all of the widgets that are linked into your code. In practice you never link in every widget, so you never get the full 2 MB in your final object... > When we do this: > Fl_Box *box = new Fl_Box(20,40,300,100,"Hello, World!"); > Are we again creating a struct? That's another widget class; one that knows how to draw a simple rectangular box on to an enclosing Fl_Window object. The parameters to the constructor say it is to be drawn offset 20,40 pixels from the top left corner of its parent window, and that it will be 300 pixels wide by 100 pixels high, and containing a text label saying "Hello, World!" (in time-honoured fashion.) > does the geometry manager actually fill > in values in it's parent struct or is it living a separate life but tied > together via libfltk.a ? Um, you've lost me now...? _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
