On 11.03.2010, at 22:11, imacarthur wrote: > > On 11 Mar 2010, at 18:51, Matthias Melcher wrote: >> >> I would be willing to put the time in, but I'd also have to rely on >> the other Core Devs. I'd suggest a special mailing list for a >> possible participant. > > I'd help out where I could, but I can't promise to commit the time; > things are a bit tricky...
That would be great. I will need a backup admin to fill out the application. Could you do that? You would need to sign in here: http://socghop.appspot.com/ and send me your "Link ID". >> So here are my suggestions (that I could get in before tomorrow >> night): >> >> - Fluff: this would be a new app at the side of Fluid. Fluid will >> be purely for interactive user interface creation. Fluff would do >> all the - um - fluff around developing apps: it could >> * install FLTK correctly for non-makefile based systems >> * manage the IDE files (move from Fluid) >> * create new projects from scratch (and their IDE and Makefiles) >> * create packages (a package can contain new widgets and uses the >> above IDE interface to install neatly into the users FLTK environment) >> * install and remove packages >> * online "shop" for packages (remember the Bazaar? Just much >> simpler for the end user) > > Sounds interesting - but too big a job? I'm not sure, maybe it is > feasible. I would cut that down to a minimum with the option of doing more if there is time. >> - image writing > > Useful. I have code that is available as a starting point if anyone > wants it. Supports writing jpg and png, I use it often with fltk, but > it needs fltk-ified if it was to be part of the lib. Yes, this is relatively easy. >> - image reading from RAM > > Matt, you already have this partly working? Yes, but only for a single image format (jpeg) and not for Fl_Shared_Image >> - 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. >> - Fl_Device for scaling > > This is for the "zoom" functionality, or...? Exactly. >> - mouse pointer editor > > Again, Matt, you have already have a starting point for this, I think? Yes, but a full feature app could do so much more ;-) >> - Fl_Cavas widget and Paint test program > > Yup. There used to be a fltk-based app "Anti-Paint" that might be a > good starting point for a Paint program, FWIW. Ah, yes, I remember. >> - new fltk_sound library that wraps the audio calls in Blocks and >> Sudoku > > To be honest, I always use portaudio.... But I guess we could add our > own. > Though I'm not *too* keen on "bloating" fltk with these added > functionalities. I know. It would mess up the Makefiles etc., and where do we begin and where to stop. OTOH, this would be extremely light-weight. Probably less than a hundred lines of code. >> - new fltk_stream library that adds communication widgets like >> serial line and TCP/IP > > Hmm, see comments above about "bloat"... 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? Matthias _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
