Talk:FLTK
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?
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]Just released yesterday.[1] 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)
- Start-Class Computing articles
- Low-importance Computing articles
- Start-Class Free and open-source software articles
- Low-importance Free and open-source software articles
- Start-Class Free and open-source software articles of Low-importance
- All Free and open-source software articles
- All Computing articles
- Start-Class C/C++ articles
- Low-importance C/C++ articles
- C++ articles
- WikiProject C/C++ articles
- Start-Class Technology articles
- WikiProject Technology articles
- Start-Class software articles
- Low-importance software articles
- Start-Class software articles of Low-importance
- Unknown-importance Computing articles
- All Software articles
- Start-Class computer graphics articles
- Low-importance computer graphics articles
- WikiProject Computer graphics articles