>
> On 12.02.2009, at 13:00, Fabio Bracci wrote:
>
> >>> why should I be forced to copy the offscreen while it still
> >>> is the active context?
> >>
> >> fl_read_image only handles the current context, so if you want to
> >> read
> >> from the offscreen, it has to be current.
> >
> > I felt I just needed some more flexibility/usability from the
> > offscreen.
>
> Well, there are two philosophies for API's. You can either send the
> context of your operation with every call, or you can use a current
> context. The difference is this:
>
> draw(context)
> rect(context)
> line(context)
>
> vs.
>
> begin(context);
> draw()
> rect()
> line()
> end(context);
>
> Since most of the time, the context is not change around, we decided
> for the second solution. The functionality is exactly the same:
>
> grab_screen(context)
>
> and
>
> begin(context)
> grab_screen()
> end(context)
>
> are the same. The first line, if written out, would look something
> like this in code:
>
> grab_screen(context) {
> if (current_ != context)
> current_ = begin(context);
> grab_screen()
> }
>
> Nothing gained, nothing lost. FOr the same reason (avoiding repetitive
> typing of "context"), FLTK uses a currrent group for adding more
> widgets, so the clumsy
>
> groupA = new Group()
> buttonA = new Button()
> groupA->add(buttonA)
>
> becomes
>
> new Group()
> new Button()
>
> done.
>
> ----
> http://robowerk.com/
I agree, when setting up a mass of widgets the implicit context is useful.
Nevertheless I would say the two approaches are not necessarily conflicting:
why not to offer both of them?
draw(context)
rect(context)
line(context)
and
begin(context);
draw()
rect()
line()
end(context);
the difference syntactically seems to me that it can be overcome by offering
overloaded member functions. Or maybe the draw(context) and begin(context);
draw(); end(context); are conflicting at some lower level in the framework?
Anyway, this is just an idea. The advantage of the draw(context) is that
there's no space for mistakes and it's simpler for beginners or programmers
which aren't too much interested in a deep knowledge of the framework's
mechanisms: imposing a particular order in these calls makes it lesser
intuitive.
Another consideration is the wished programming style: the implicit context
remembers me of the use of general shared variables like in old C programs,
while rect(context) (or even better, context.addRect() context.add(rect) or
context << rect ) have more OO-fashion.
In a more pure OO programmig style one would avoid asap general shared
variables as much as possible, in principle they break the OO-design.
Those are just a couple of thoughts I got.
Best,
Fabio
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
