On 07/09/12 07:24, Roman Kantor wrote:
> I just like to ask if I can post here propositions for paid development
> of new/improved FLTK widgets - if not, please let me know ant I will stop
> post it here.
Sounds cool to me.
Perhaps adding '[JOB]' to the subject line would make it clear
it's a commercial request; this is what I've seen in similar
mailinglists/newsgroups.
> We would like to pay some external experienced fltk user(s) or developer(s)
> for development of these widgets, the result would be released under FLTK
> license
> (LGPL + FLTK exceptions) so we can reuse existing FLTK code and if the fltk
> maintainers would be interested, the code could be also incorporated back
> into FLTK
> tree.
Great. I've done that myself; I called it "a bounty" where I paid
to have an open source widget written.
I've also responded to bounties. I think it works well as a way
to structure a programming job. Avoids a lot of hassle with complex
copyright issues in the work contracts too.
> The first project would start in about 2-3 months and would consist of
> development of extensible and editable rich text HTML widget (similar to
> Fl_Help_View,
> with similar level of tag support - HTML 2.0) but with proper DOM structure
> tree, some additional features like data uri scheme for inlined images,
> proper print
> formatting and HTML copy/paste clipboard support on main platforms (Windows,
> OsX and ?Linux?).
Wow, that's a big one; the DOM is huge based on my experience doing
javascript programming.. too complicated for me to take on, but
someone might be up for it.
However, might it be better to have someone port webkit to FLTK?
Webkit is underneath many popular browsers and toolkits.
It is what Qt uses for its web stuff.
Even though webkit does a lot work for you, you still can end up
with a complex API if you want to provide the app programmer direct
hooks into the DOM to do things like setup C++ callbacks for
'onmouseover' and 'onmouseclick' stuff. And vice-versa, being able
to have external events affect the DOM, eg. changing text and then
'refreshing' the webpage. And stuff like managing page histories,
hooking the back/forward button, etc.
Webkit gets big fast, since you can hook in things like flash,
media players (movies, etc), javascript..
If you go the webkit route, you can have the absolute latest
HTML5 stuff though. I guess there's also editors, error consoles,
all kinds of neat stuff which you can either ignore, or try to
implement into the API.
I don't know much about the subject beyond the above. I've never
worked with webkit from C/C++ before.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
