| [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3075
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Core Library |
Summary: | Fl_Tabs don't show labels for Fl_Window children |
Version: | 1.3-current |
Created By: | Belgiansteve |
Assigned To: | AlbrechtS |
Fix Version: | 1.4.0 (SVN: v12185) |
Update Notification: | |
Trouble Report Files:
No files
Trouble Report Comments:
|
#1 | Belgiansteve 09:34 Apr 30, 2014 |
| Hi, When a Fl_Tabs has an Fl_Window as one of its children, the label for that window does not show on the corresponding tab. This is probably because the labeltype for a Fl_Window is forced to be FL_NO_LABEL (setting the labeltype() before the tabs are drawn is no use). I would be very grateful if this behavior could be modified so that labels for Fl_Window children can be displayed. Thanks! | |
|
#2 | ianmacarthur 03:13 Sep 05, 2014 |
| Embedding a window in a tab might be a bit fragile anyway - does it work on all platforms? (I'm suspicious it might be a bit odd on OSX for example...)
As a workaround, putting a group in the tab, then putting the window in the group, should get things going? | |
|
#3 | AlbrechtS 09:40 Nov 03, 2014 |
| I'm afraid this doesn't work as the OP expects and probably will never do. However, as Ian wrote, using a normal group (Fl_Group) as the Fl_Tab's child and having a window embedded in the group seems to work. I tested this only very short on Linux, and it seemed to work as expected.
However, this is not a documented or guaranteed behavior. It is probably not portable, so we might eventually document that this is not allowed. Currently I can't say this for sure though...
I reduced the priority of this STR to 2 (Low) since this is really an undocumented side-effect: Windows are currently not supported to be children of Fl_Tabs. | |
|
#4 | AlbrechtS 09:52 Nov 03, 2014 |
| Note to myself and other devs:
There is code in Fl_Window::show() that duplicates setting the labeltype() as it is done in the constructor (depending on Fl::scheme_bg_). This is suspicious, and probably wrong. It overrides any labeltype() a window has been given, so that setting a labeltype() does not work in an Fl_Tabs widget, since the children are hidden and showed when tabs are selected.
I found this suspicious code in src/Fl_x.cxx, src/Fl_win32.cxx, and src/Fl_cocoa.mm. I believe that setting the labeltype in the c'tor is intended, but it should not be done in show(). Needs investigation why this is done now, and whether it can be removed in a future version of FLTK. | |
|
#5 | AlbrechtS 11:57 Mar 01, 2015 |
| See also Fl::reload_scheme() in src/Fl_get_system_colors.cxx at its very end:
// Set (or clear) the background tile for all windows...
// FIXME: This makes it impossible to assign a background image // and/or a label to a window. IMHO we should be able to assign a // background image to a window. Currently (as of FLTK 1.3.3) there // is the workaround to use a group inside the window to achieve this. // See also STR #3075. // AlbrechtS, 01 Mar 2015 | |
|
#6 | matt 17:09 May 23, 2015 |
| Just as a side note: I added OpenGL windows to the Tabs test quite a while ago. They switch correctly and keep their position on all platforms. Fl_Window is a much simpler class, and Fl_GL_Window is derived from it, so, yes, Fl_Window can be in a Group that is inside a Tab... . | |
|
#7 | AlbrechtS 09:14 Mar 06, 2017 |
| Fixed in Subversion repository.
svn r12185 fixes label drawing for direct Fl_Window children in Fl_Tabs widgets.
This is done by temporarily assigning a label type if the child's label type is FL_NO_LABEL which is true for all Fl_Window children (see comments #4 and #5). Images still can't be shown for Fl_Window children because of the facts shown in these comments. A better fix is planned for the future, but I consider this STR resolved.
FWIW: I'm going to post a new test and demo program that includes a window child in tabs with different alignment flags shortly on STR #3076.
@OP (Belgiansteve): Can you confirm this commit fixes the issue for you? | |
|
#8 | AlbrechtS 10:49 Nov 18, 2017 |
| This STR has not been updated by the submitter for two or more weeks and has been closed as required by the FLTK Configuration Management Plan. If the issue still requires resolution, please re-submit a new STR. | |
[ Return to Bugs & Features ]
|
| |