| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #2053
| 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: | X11 |
|---|
| Summary: | It is possible that an instance of a Fl_Window will not have a xclass set. |
|---|
| Version: | 1.3-feature |
|---|
| Created By: | alvin |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | 1.3.0 (SVN: v7863) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | alvin
03:37 Oct 01, 2008 |
| If the user does not specifically set a Fl_Window's (or derivative thereof) xclass(const char*), then it is possible that that instance will not have a xclass. This causes problems for window managers that rely on the xclass (in X its WM_CLASS property) to perform special operations (e.g. Compiz animations, tiling window managers, etc.)
This issue has been discussed in fltk.development.
The attach patch adds a private static const *default_xclass_ to Fl_Window. When Fl_Window::xclass(const char *c) is called, and default_xclass_ is NULL, a copy of c is stored in default_xclass_. When Fl_Window::xclass() is called, either the local member, xclass_, is returned, or, if xclass_ is NULL, default_xclass is returned.
The effectively ensures that every time that Fl_Window::xclass() is called, a valid string is returned.
From what I can tell, by reading FLTK's source, is that when Fl_Window::show(int,char**) is called, Fl_Window::xclass() is examined. If Fl_Window::xclass() returns NULL, a string is constructed out of argv[0] (See Fl_Window::show(int,char**) in Fl_arg.cxx).
In the case of X, when Fl_Window::show() is used to create a window, Fl::make_xid() is called. Fl::make_xid() will then examine Fl_Window::xclass() and use it accordingly. Prior to the attached patch, if Fl_Window::xclass() returns NULL, then the window's WM_CLASS property will not be set. This patch will ensure that this does not happen.
I am not sure what happens when Fl_Window::show() is called for the other operating systems. This patch should be tested by those who have access to those operating systems.
If Fl_Window::show() is used to spawn the first window of the application and xclass is not set (e.g. X class field in fluid is empty or Fl_Window::xclass(const char*) has not be called first), then, I believe, the window will not have a class property. This needs to be tested.
I have also attached a small applciation that spawns a Fl_Double_Window that contains a Fl_Box and a Fl_Button. When the window is shown, the xclass string is used as the Fl_Box's label. Each time the button is pressed, a new instance of the window is shown and the result of xclass is displayed. Prior to this patch, each new window spawned would have "null" displayed. With this patch, each new window inherits the xclass() of the first window shown in this application (i.e. in X, the string "xclass() = xclass_test" is shown).
I have also tested this by setting a Compiz animation for FLUID. As a result, every window created by fluid now has the Sidekick animation occur.
To compile the test app:
fluid -c xclass_test.fl
fltk-config --compile xclass_test.cxx | |
| |
| #2 | alvin
06:27 Feb 27, 2009 |
| Updated patch, str2053-v2.patch, to compile cleaning against svn r6669. | |
| |
| #3 | alvin
04:26 Aug 11, 2009 |
| Uploaded patch that compiles against SVN rev 6841 | |
| |
| #4 | matt
06:01 Feb 27, 2010 |
| Can any of the X11 developers please verify this. It is only an eight line patch. | |
| |
| #5 | greg.ercolano
09:41 Feb 27, 2010 |
| v3 patch fails to apply to 1.3.x current..
will patch manually, and if it 'works' I'll update with a new patch. | |
| |
| #6 | greg.ercolano
10:14 Feb 27, 2010 |
| Confirmed on Ubuntu 8.04:
1) Applied v3 patch manually to svn current and created new patch (v4).
2) Re-checked out 1.3.x (r7168) clean copy
3) Downloaded OP's test program, compiled and ran and it behaved
as described before patch is applied; first window shows
"xclass_test" and all others show "(null)".
4) Applied v4 patch, rebuilt with no errors.
5) Rebuilt OP's test program, now behaves as described when
patch is applied; all windows created show "xclass_test".
I don't see anything wrong with the code offhand; it makes a strdup()
that is never free()ed, but this is intentional to ensure the saved
string lasts the lifetime of the program.
One could argue it should be free()ed before Fl::run() returns,
though I believe plenty of strings remain allocated as normal
behavior already, and as most of us know, exit() absolves all sins
of forgotten free()'s, so should be fine.
I'd suggest the static variable definition include a comment describing
the intention of this, as it is not immediately obvious without
the context of this STR. At very least, comment could refer to STR#2053
for details. (Such a comment was NOT added to the v4 patch) | |
| |
| #7 | AlbrechtS
07:17 Feb 28, 2010 |
| I agree with Greg, the patch looks good, and I can confirm that it works for Ubuntu 9.04. I think that we can check it in as is.
However, I would also like to have
static void Fl_Window::default_xclass(const char *class)
and
static const char *Fl_Window::default_xclass()
or similar as the corresponding set/get methods for the default xclass. This would enable the user to set the default before creating or showing any window and lets her/him also change the default. | |
| |
| #8 | matt
02:30 Apr 05, 2010 |
| Any X11 takers? | |
| |
| #9 | AlbrechtS
02:47 Apr 12, 2010 |
| The problem is less a X11 one than a deficiency to always set up a window's xclass() - at least with a feasible default value.
There are also problems with registering the WNDCLASS under Windows (since fltk 1.3/utf-8).
I'm investigating... | |
| |
| #10 | AlbrechtS
00:00 Nov 15, 2010 |
| Note: the related Windows problem (registering WNDCLASS) has been solved meanwhile (svn r7704).
Setting up and storing the xclass() name still needs some work. | |
| |
| #11 | matt
14:18 Nov 16, 2010 |
| Added code to handle default xclass. Please check. Thanks! | |
[ Return to Bugs & Features ]
|
| |
