Talk:FLTK
{{Talk header}}
{{WikiProject banner shell|collapsed=yes|class=Start|
{{WikiProject Computing|importance=Low|free-software=yes|free-software-importance=Low}}
{{WikiProject C/C++|importance=Low|c++=yes}}
{{WikiProject Technology}}
{{WikiProject Software|importance=Low}}
{{WikiProject Computer graphics|importance=Low}}
}}
Merge?
Seems 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
How 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
The 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
The 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
Shouldn'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)
1.4.0-1 release
Just released yesterday.[https://www.fltk.org/articles.php?L1955] I don't know whether the article infobox needs to be updated. Maybe someone else here can figure this out and fix things as needed. 2601:644:8581:75B0:0:0:0:2CDE (talk) 01:14, 20 November 2024 (UTC)