On 11.03.2010, at 23:04, Matthias Melcher wrote:
>
> On 11.03.2010, at 22:11, imacarthur wrote:

>>> - Fl_Device for OpenGL
>>
>> Seems good - but can a student do it while Manolo and Albrecht are
>> still working through the Fl_Device/Printer bits?
>
> Yes, you may be right.

Oh, no!  This wouldn't be a problem.  IMHO we're done with development
and need a decision to merge the code ASAP.  Thus, this *should* be
done long before a student starts development.

>>> - Fl_Device for scaling
>>
>> This is for the "zoom" functionality, or...?
>
> Exactly.

Interesting.

> Again, yes, I know, and I agree that this is a problem. I have sample code 
> that implements widgets that give a visual feedback for all these features, 
> including basic controls. So it is truly a GUI wrapper around those 
> functions. Plus it is really an optional library. No need to link if not 
> needed.
>
>> I do wonder, as Duncan suggested, whether we could get someone to
>> build a prototype fltk-123 layer, to demonstrate what actually might
>> work? Would be useful to us, and might be a genuinely interesting and
>> challenging for the student. But impossible to judge whether it is
>> achievable - and there seems little point in setting goals that are
>> not achievable...
>
> OK, I have put that in the list of ideas. Maybe there is a taker for 
> conceptual work?

I really don't know if a student who doesn't know the details of
fltk1 _and_ fltk2 can be able to do this during the given time (three
months?).  But it would really be interesting as a case study or
something like that, if someone could work out a way to do the
"fusion" in a way that could maybe be implemented later based on the
student's work.  But I don't know if such a project would qualify for
GSoC.

Two more project ideas:

(1) improve Fl_Help_View: see Domingo's ideas and more, related to
caching of images and such.  As one point I see that it is absolutely
useless to parse the html page to free the cached images, but this
was probably only done this way (by Mike, IIRC) to keep ABI compat.

(2) redesign Fl_Shared_Image.  I wrote a proposal a while ago, but
this was before we started 1.3, and it would break ABI compatibility.
I could dig and see what I had - I do still think that this would be
useful, especially for point (1) above.

But I can probably not give much more details before you need to write
the application.

And we would need to publish an idea list or so, IIRC.  But if we have
some more time to do this, then we can probably also find some
interesting RFE's in the STR system.

Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to