STR #2082: Under X, instances of Fl_Window do not have a Window Type set.

STR #2082

Application:	FLTK Library
Status:	1 - Closed w/Resolution
Priority:	2 - Low, e.g. a documentation error or undocumented side-effect
Scope:	2 - Specific to an operating system
Subsystem:	X11
Summary:	Under X, instances of Fl_Window do not have a Window Type set.
Version:	1.3-feature
Created By:	alvin
Assigned To:	matt
Fix Version:	1.3.0
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

Trouble Report Comments:

#1	alvin 06:24 Nov 04, 2008

Under X, instances of Fl_Window do not have a Window Type set. The window type is used by X to provide consistent window decoration and functionality (dock, stacking, etc.) for windows of the same type. Currently, Fl_Windows do not set the window the type and are therefore have "Unknown" window types. Further information relating to this topic can be found here: <http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html#id2522894> I will be submitting a patch shortly.

#2	alvin 06:38 Nov 04, 2008

I have attached 3 files. Either of the patches should be used but not both. Depending on whether STR 2053 <http://www.fltk.org/str.php?L2053> is accepted or not will dictate which patch to use (if this str is accepted). As an aside, I have been using STR 2053 with great success since it was submitted into the STR database. Regardless of which .patch is selected, the following will happen: The patch will add Fl_Window::xtype(), Fl_Window::xtype(Fl_Windowtype) and enum Fl_Windowtype. The patch adds support for two types of windows: Normal and Dialog. There are other types which can easily be added if the need arises. I tried to mirror the implementation for WM_CLASS (e.g. Fl_Window::xclass()). str2082_wo_str2053.patch This patch applies to the current fltk 1.3 svn (6495). It has no dependencies. str2082_w_str2053.patch This patch requires that svn be first patched using the patch from STR 2053. With this patch applied, Fl_Window will fully support both WM_CLASS and _NET_WM_WINDOW_TYPE hints. xtype_test.fl A simple program that spawns a Fl_Window. The Fl_Window will have a xtype of FL_NORMAL_WINDOW. When the button (child of the Fl_Window) is selected, another Fl_Window is shown however with its type set to FL_DIALOG_WINDOW. Under X, the program <TT>xprop</TT> can be used to verify that indeed the appropriate _NET_WM_WINDOW_TYPE is being set. Additionally, if compiz-fusion is installed different animations can be used (i.e. Zoom or type=Normal and Fade for type=Dialog) with FLTK apps. One final note, this patch only alters Fl_x.cxx. I do not use the other OSes that FLTK supports. I leave it to users of those OSes to implement the platform-specific support.

#3	alvin 07:26 Nov 04, 2008

I have attached str2082_fluid.patch. This patches the fluid source to use FL_DIALOG_NORMAL for the dialog windows. This patch depends on either of the str2082 patches to be applied in order for fluid to compile. Aside: My first attempt was to only create patches for the .fl files. I thought the Makefile (svn working copy) would call fluid -c on the patched .fl files. This did not happen. As a workaround, this patch will modify the .fl, .cxx and .h (maybe).

#4	alvin 07:31 Nov 04, 2008

Ugh, I meant to say that str2082_fluid.patch updates some of the Fl_Windows in fluid to use <B>FL_DIALOG_WINDOW</B>

#5	alvin 16:15 Jan 05, 2009

Updated patch files: str2082_wo_str2053-v2.patch, str2082_with_str2053-v2.patch, and str2082_fluid-v2.patch Patches apply cleanly to 1.3.x r6622 Note that only one of str2082_wo_str2053-v2.patch OR str2082_with_str2053-v2.patch should be applied. The former can be applied without having applied <a href="http://www.fltk.org/str.php?L2053">STR #2053</a> while the latter requires <a href="http://www.fltk.org/strfiles/2053/str2053-v1.patch">str2053-v1.patch</a> be applied first.

#6	alvin 08:30 Mar 09, 2009

Updated str2082_fluid-v3.patch. Updated str2082-v2_requires_str2053-v2.patch. The above patches compile cleanly against FLTK 1.3.x SVN r6672

#7	alvin 04:27 Aug 11, 2009

Uploaded patch that compiles against SVN rev 6841. This STR is related to STR#2230. STR#2230 adds further support to menus.

#8	alvin 09:01 Dec 28, 2009

FWIW, I longer use the patch(es) from this RFE and will no longer be maintaining them. I have been using these patches since creating the STR without any problems. Though I believe that the addition of Fl_Window::xtype() is useful, I no longer use Compiz. I have switched to KDE 4 as my desktop environment which includes built-in window compositing. Today, I have removed these patches from my build system and, so far, I haven't notice difference (probably because I do not do anything special with dialog boxes in KDE4). Therefore, I humbly request that this STR be closed. Thank you.

#9	ianmacarthur 10:23 Dec 28, 2009

Actually - for what it is worth - I think these patches (or something *very* like them) is probably something we ought to do under X. Right now, so far as we know, it is only under Compiz that we see side-effects from *not* setting the window type, but still it seems like we ought to, so I think we probably should try and merge this patch into the fltk tree at some point, at least for fltk-1.3. It should fix some dialog and menu issues under Compiz, and not break any other WM, so...???

#10	alvin 11:31 Dec 29, 2009

Thanks for the comments Ian. To help determine whether or not this RFE should be included, I have updated the patch to apply to a clean checkout of branches/branch-1.3 rev 6985. The patch updates the library proper and adds "o->xtype(FL_DIALOG_WINDOW);" to some of FLUID's dialogs. An interesting note though, I tested using the xtype_test.fl and it appears setting the window's type to "_NET_WM_WINDOW_TYPE_DIALOG" is not enough. I have the "Sheet" and "Dialogue Parents (Dims parent of dialog)" effects turned on in KDE4 and FLUID's dialogs appear to act like normal windows. I used xprop to check and the dialogs are in fact "_NET_WM_WINDOW_TYPE_DIALOG". I probed some dialogs that do behave correctly (Filefox's File->Open, KMail's File->Open) and it appears that "_NET_WM_WINDOW_TYPE(ATOM)" is set to both "_NET_WM_WINDOW_TYPE_DIALOG" and "_NET_WM_WINDOW_TYPE_NORMAL"! Also, sometimes "WM_CLIENT_LEADER(WINDOW)" (as in the case of KMail) and "WM_TRANSIENT_FOR(WINDOW)" (as in the case of Firefox) are set. Where, with xtype_test.fl, the dialog window has neither of these set. Therefore, a little more investigation may be required to get full, proper support?

#11	AlbrechtS 05:09 Dec 31, 2009

Alvin, thanks for your work on this, and Ian, thanks for testing. I'd like to add some comments ... The menu animation can obviously be solved by setting _NET_WM_WINDOW_TYPE_MENU, as shown when we discussed this previously by Isaque for FLTK 2.0. See STR #2230: http://www.fltk.org/str.php?L2230 http://www.fltk.org/strfiles/2230/menu_compiz_v2.diff When we discussed this, I added two new flags() to Fl_Widget) that were intended to be used for this, but then I didn't find the time to complete it. So, what we have already is two set/get methods for Fl_Window: [set_]menu_window() and [set_]tooltip_window(). This is somewhat redundant, i.e. the proposed Fl_Window::xtype() would have the same or similar information, but would probably be easier to extend (?). I'm open for both ways, and I think that we could easily remove the two flag bits from Fl_Widget::flags() again, if this is the better way. Any opinions about Fl_Widget::flags() bits vs. Fl_Window::xtype() ? ---- Ian, for testing the compiz animation, you could set the correct _NET_WM_WINDOW_TYPE_MENU depending on Fl_Window::menu_window(), because this is currently implemented already. Does this work?

#12	matt 06:05 Feb 27, 2010

Any chance to wrap this up? In the next version, I propose additional window names, based on the intended use, which would set the required flags. So e should not stress about this too long ;-) (Fl_Toolbox_Window, Fl_Popup_Window, Fl_Modal_Window, Fl_Menu_Window, etc.)

#13	alvin 05:35 Mar 10, 2010

Matt, I like those ideas as well. It would certainly be more in line with the OO approach. Whilst the options are being considered, I have updated the patch so that can be applied to (at the time) latest svn (rev 7235).

#14	alvin 05:38 Mar 10, 2010

I forgot to mention that the new patch file (str2082-r7235.patch) does not touch FLUID any longer. It only patches the library.

#15	matt 02:30 Apr 05, 2010

Duplicate?

#16	AlbrechtS 07:05 Apr 05, 2010

Ian, would you please test attached patch file str2082_window-type.patch to see if this fixes the compiz menu animation issue. This is not directly what this STR is for, but I'd like to complete this now and leave the option to set an internal xtype as suggested by Alvin open for later. Unfortunately I can't test this myself, because I don't see any window animations on my Ubuntu Linux system, even with compiz enabled.

#17	AlbrechtS 07:11 Apr 05, 2010

Correction: I meant *menu* animations. I can see normal window animations though, like flying when minimizing, "wobbling" windows when dragging, and so on. But menus pop up and close instantly.

#18	AlbrechtS 13:35 Apr 06, 2010

Summary / current status: str2082_window-type.patch has been committed (svn -r 7459), and this fixes the menu and tooltip animation by compiz. It does *NOT* generally set the window type for all windows, as proposed by Alvin. This is a more general approach and needs additional info in the window classes as shown in his patch(es). We can address this in another step, maybe soon ...

#19	matt 07:15 Nov 21, 2010

Is this bug going anywhere or do we need to distill this down to what is still needed to close this?

#20	alvin 08:08 Nov 21, 2010

I'm happy with Albrecht's r7459 commit back in April 2006. I have been using a patch locally that also adds Fl_Window::xtype() but, to be honest, I never call that function. The original intent of this feature request was only to make compiz happy when I was using compiz back-in-the-day. Now I use KDE4 4.5.3 and do not need to change anything. I think the xclass fix that was recently committed was all that was needed (if at all). For what it is worth, I vote +1 to close this or move it to 1.4-feature or some other more appropriate future release.

#21	AlbrechtS 13:59 Nov 21, 2010

The primary reason of this STR is fixed, and I although I think that the xtype() approach might be useful to replace some of the flag bits in a future version (as well as Matt's suggestion to use different window types), this does not give us anything we need for FLTK 1.3 now. I suggest to close this STR, as Alvin (the OP) wrote.

#22	matt 03:37 Nov 22, 2010

Fixed in Subversion repository.