On 28.01.2011, at 10:11, MacArthur, Ian (SELEX GALILEO, UK) wrote:
>
>> Google has announced the Google Summer of Code 2011 :
>> http://www.google-melange.com/document/show/gsoc_program/googl
>> e/gsoc2011/timeline
>>
>> I hope FLTK tries to get into it.
>
> It would be cool, but I doubt we can commit to the mentoring
> responsibilities, and do it well enough it be worthwhile. I know that I
> can not - anyione else?
>
> I know a lot of folk think GSOC is like free labour, but it is not -
> done right it is a valuable learning opportunity for the student (and
> mentor!)
> Projects that treat it like free labour don't get asked back...
Well, I spent a few evenings setting up an application for 2010 (see below),
but were blown off pretty unceremoniously. I am sure that they have many
applicants, and I am not bitter, but I was a bit surprised. Maybe I
misunderstood something or my application was wrong, I don't know.
I would have a hard time to make room for mentoring, this year much more than
last year. I will not be able to do it?
>> A great entry would be to completely modularize the system
>> dependent stuff into
>> a system class with functions like SYS_CreateWindow (....),
>> SYS_CloseWindow (....),
>> SYS_GetEventsforWindow (....) to make porting easier and
>
> Um, is this not what the Fl_Device_* abstraction stuff is doing in 1.3
> now anyway? Or am I missing some point?
It's doing it for the graphics system now. I assume he means the same thing for
the window and event system.
>> maybe help it to get a SDL 1.3 systemclass
>> done, which would immediately enable it to run on Android,
>> iPhone, ....
>
> Not sure about SDL - for me it is in the same category as Cairo; works,
> looks nice, portable. But can be slow... And often have no prospect of
> h/w acceleration...
>
> I think we might do better with GL or GL-ES, as they are also portable
> and there's a good chance they will be h/w accelerated.
Assuming we have a windw/event device system in place, I would love to have
minimal drivers for all these Device instances, because all you need to run a
minimal FLTK is a timer event, a click event, and the ability to set the color
of a single pixel. Any OS that can provide these three functions can then run
FLTK apps and would be sufficient for a minimal port.
The developer who's porting FLTK can then work his way up and add more and more
features into the Device interface.
- Matthias
---
We will be mentoring Google's Summer Of Code program with the following ideas:
1: New Application "Fluff"
"Fluff" (working title) will be a new application include with the
FLTK distribution. Fluff will help users to quickly create new
widgets, projects, or libraries. It will help create packages for
distribution, and allow for easy download and installation.
Fluff will be an entirely new program. You will help designing the
application, designing the UI, and implementing it with the help
of the FLTK GUI library.
* 1/2011: The functionality of FLuff will likely go into Fluid, moving
Fluid from an interface designer to a rapid prototyping app designer.
2: New Widget "Fl_Canvas" with drawing application
Fl_Canvas will be a widget that allows easy drawing into back- and
front buffers, zooming, etc. . It will be the base widget for image
manipulation and drawing, and will become an integral part of FLTK.
You will be designing the API for this widget and implement it based
on the existing drawing functions of FLTK. For some feature a base
knowledge in the underlying platforms (X11, WIN32, Cocoa) may be
needed. You will prove the functionality of the widget by designing
and writing a simple paint program.
* 1/2011: still nice-to-have
3: New Library "fltk_connect"
"fltk_connect" will be a new library within the FLTK pack of libs. It
will include Widgets for serial connections, TCP/IP, and based on that
a selection of protocols, likely FTP and HTTP.
You will design the API and feature set and implement the widgets.
Some sample code exists and should be easily integrated. A basic
knowledge in BSD sockets and an understanding of threads is would
be helpful.
* 1/2011: mostly implemented (TCP/IP, FTP, etc.) but would need integration,
error handling, documentation
4: New Rendering Device based on OpenGL "Fl_GL_Device"
FLTK uses a Device abstraction to render all graphics onto the screen.
This particular device will allow innovative user interfaces that
can "hover" on top of OpenGL graphics, comparable to a Heads-Up-
Display.
You will implement this new class based on the API of Fl_Device. A
basic knowledge of OpenGL is required. You will implement a test
application that show this great feature.
* 1/2011: very current!
5: SWIG Integration
FLTK is based on C++, but its API has been ported to a multitude
of languages, like Python and D. SWIG greatly simplifies this task
by providing a wrapper interface for C++ based libraries.
http://www.swig.org/
You will be updating and improving the Interface files required to
link FLTK to new languages. You will be writing a few basic (or
more involved, if you like) examples that show the working wrappers.
This task is based on pyFLTK:
http://pyfltk.sourceforge.net/
* 1/2011: very current!
6: Conceptual work and Implementation: Code Un-Fork (FLTK-123)
FLTK has gone through a code fork many years ago. This fork regularly
leads to great confusion among users. At this point, FLTK1 is the
stable branch, but FLTK2 has a more modern API.
You will help us find a way to map the newer FLTK2 API onto the stable
guts of FLTK1 while staying compatible, generating FLTK3. We do have
a pretty good plan for this, but if you are a C++ guru, you can help
us make the impossible - and your name will be remembered forever.
* 1/2011: very current!
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
