This is the talk page for discussing improvements to the FLTK article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to multiple WikiProjects. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Merge?
editSeems like it should be. Not a lot of room for expansion here. Small enough topic. No strong opinion about it though. Jason Quinn (talk) 05:32, 27 August 2010 (UTC)
- Merge with which article? Why not having short articles? mabdul 12:09, 12 November 2011 (UTC)
- Hi, Mabdul. I'm not sure why I ended up commenting here. I may have used an automated tool to help with a merge. I was referring to the FLUID article. Jason Quinn (talk) 03:08, 19 November 2011 (UTC)
There is be no need to merge the articles. If given some time, they will expand to the point that merging would result in a ridiculously large article because these two topics are quite big. Yoreei (talk) 18:23, 16 August 2012 (UTC)
Button allocation in code example
editHow come the button is allocated on the heap? If the pointer isn't needed anyway, it might as well be allocated on the stack. I thought that was usually preferred. Also, since the pointer isn't saved in any way, how is a memory leak prevented? --87.157.207.50 (talk) 00:56, 2 January 2012 (UTC)
Looking at the code, I think the creation of the window sets it as the parent for new controls:
1 Fl_Window* w = new Fl_Window(330, 190); 2 new Fl_Button(110, 130, 100, 35, "Okay"); 3 w->end();
Line 1 creates the window and its constructor does { currentParent = this; }. Line 2 creates the button and its constructor does { currentParent->addChild(this); }. Line 3 does { currentParent = nullptr; }. Had the button been allocated on the stack, the space where the button is sitting would be reused and that would likely crash the program or worse. — Preceding unsigned comment added by 82.139.81.0 (talk) 02:31, 22 June 2014 (UTC)
Architecture section looks like copy-paste
editThe Architecture section partially speaks about GTK+ and states things (written in C, uses GLib object system) that are not true for FLTK (cf. rest of article). I guess it is a copy of a corresponding section in the GTK+ article (probably an old version thereof). Could anyone rework this section? — Preceding unsigned comment added by 92.107.152.103 (talk) 20:32, 2 July 2014 (UTC)
Out of place example program
editThe example program in the Language Bindings section seems a bit out of place. Should it be in another section? Chucksys (talk) 22:22, 17 January 2015 (UTC)
Nuke Connection
editShouldn't Nuke be mentioned? I think that was the history of this library, see here:
https://www.nukepedia.com/interviews/interview-bill-spitzak — Preceding unsigned comment added by 146.152.214.10 (talk) 15:52, 18 October 2019 (UTC)