Re: [fltk.development] WM_CLASS property for fluid windows
MacArthur, Ian (SELEX GALILEO, UK) wrote: Anyway, what I was going to suggest is that Fl::get_system_colors() could maybe be extended to cover setting the xclass, to cover those cases where show() is called wrongly at initialisation. Would that help at all? Or something like Fl::set_window_class(MyWindowClassName) before calling show for the first time ? Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
MacArthur, Ian (SELEX GALILEO, UK) wrote: Anyway, what I was going to suggest is that Fl::get_system_colors() could maybe be extended to cover setting the xclass, to cover those cases where show() is called wrongly at initialisation. Would that help at all? Or something like Fl::set_window_class(MyWindowClassName) before calling show for the first time ? Albrecht Or something as Fl_Window::set_class(myClassName) would be IMHO even better in that case. We should be careful from now not to multiplicate (pseudo) global functions in Fl when there is not a good reason to do it. This class is really too populated ... In my cairo addon, I created a state class to limit the number of attributes and methods addons, also, I named the functions as Bill suggested first, but now I wonder if I should not move my static functions to Fl_Window too as the cairo addon granularity is the Window anyway. Fabien ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
Or something as Fl_Window::set_class(myClassName) would be IMHO even better in that case. Yes. I wonder though - if the app has several windows, would we expect to set the window-class individually per window, or would it be a static such that setting it once sets it for all windows? (I'm starting to get confused about overloading the words window and class now - we set the window class using a member function of the Fl_Window class...) -- Ian SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
Or something as Fl_Window::set_class(myClassName) would be=20 IMHO even better in that case. Yes. I wonder though - if the app has several windows, would we expect to set the window-class individually per window, or would it be a static such that setting it once sets it for all windows? (I'm starting to get confused about overloading the words window and class now - we set the window class using a member function of the Fl_Window class...) --=20 Ian IMHO, as the window is already created but not showed from what I read of the current need, it could be a non static function. If it is made clear that it could be intersting to get a default configurable class name for all windows created after a setting, then we could also add an Fl_Window static member... Fabien ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
Albrecht Schlosser wrote: Fabien Costantini wrote: If it is made clear that it could be intersting to get a default configurable class name for all windows created after a setting, then we could also add an Fl_Window static member... That's what I thought of and why I proposed this. If the current default would be to derive the class name from argv[0], then it would be useful to set a global default, but otherwise you're right and it should be a window property - with a useful default value... Fabien, sorry, I didn't read _exactly_ what you wrote. Adding a static Fl_Window member instead of Fl member, as I proposed, would of course do it. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
Albrecht Schlosser wrote: Fabien Costantini wrote: If it is made clear that it could be intersting to get a default configurable class name for all windows created after a setting, then we could also add an Fl_Window static member... That's what I thought of and why I proposed this. If the current default would be to derive the class name from argv[0], then it would be useful to set a global default, but otherwise you're right and it should be a window property - with a useful default value... Albrecht Since xclass is automatically set by Fl_Window::show(int,char**), why not store the string as a static member in Fl_Window as well (e.g. Fl_Window::default_xclass). Basically, when show(int,char**) is called it checks xclass(). Regardless if show(int,char**) creates a WM_CLASS from agv[0] or uses the string supplied by the user, e.g. o-xclass(foobar);, the value is saved in the static memember Fl_Window::default_xclass. I would guess that for 99.999% of the FLTK applications, default_xclass would be set from argv[0] by show(int,char**). Then, when Fl_Window::show() is called, if xclass is not set, the value from default_xclass would be used. This would ensure that every Fl_Window created by the application will have its WM_CLASS set. -- Alvin ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
Fabien Costantini wrote: Albrecht Schlosser wrote: Fabien Costantini wrote: If it is made clear that it could be intersting to get a default configurable class name for all windows created after a setting, then we could also add an Fl_Window static member... That's what I thought of and why I proposed this. If the current default would be to derive the class name from argv[0], then it would be useful to set a global default, but otherwise you're right and it should be a window property - with a useful default value... Albrecht Since xclass is automatically set by Fl_Window::show(int,char**), why not store the string as a static member in Fl_Window as well (e.g. Fl_Window::default_xclass). Basically, when show(int,char**) is called it checks xclass() ../.. Alvin IMHO, the advantage of using only static get/set methods is that we don't add a potentially unused attribute to the Fl_Window base class. This is also the drawback, and it should be analysed whether we should add both static method and window property methods. In all cases, it seems to be a good idea to have the static get/set methods. Fabien My suggestion was only to minimumally extend the current functionality. As of right now, the WM_CLASS is only set for the first Fl_Window created by the app (assuming Fl_Window::show(int,char**) is called. This handles the cases were xclass is set by the developer or, if not set, determined by argv[0]. However, all other Fl_Window's that are created do not have WM_CLASS set. My suggest is only to retain the string that was used. Then every other Fl_Window could use that same string (if xclass() has not been set otherwise). -- Alvin ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
Carlos Pita wrote: Hi all, I'm not sure if I must report this as a bug, tell me so if it's the case. Most fluid windows don't play nice with tiling windows managers (wmii, awesome, dwm, xmonad, ratpoison) which depends on the class or instance of a window to be able to put it into a floating layer or layout. Because of its multi-window nature, fluid is not quite amenable to be tiled. Therefore, as there is no way to make it float instead, it becomes virtually unusable. One solution is to mark every window with the Fluid class, just as the main window already is. Usually tiling wms allow to define layout rules based on a window class/instance/name. Regards -Carlos I have had a similar problem with FLTK apps and Compiz's animation rules. For example, from what I can tell, all windows in FLTK 1.3.x apps (incl. fluid itself) have a type of Unknown. As a result, FLTK windows do not follow the same animation rules as my other windows (KDE mostly). I have the same animation for all FLTK windows rather than different ones for dialogs, normal windows, etc. From using xprop, I believe the setting has to do with _NET_WM_WINDOW_TYPE(ATOM). I don't know anything really about WM_CLASS other than I can use it in the compiz rules. From what I can see (using xprop), only the main fluid window has its class set as Fluid. All the other windows have no WM_CLASS? Does it make sense for windows to inherit the WM_CLASS of the main window? I know FLUID provides a field called X Class for Fl_Double_Window properties. I haven't use it though or even know if that is the same was WM_CLASS. -- Alvin ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
Please file STRs for both issues, preferably with patches ;-) Thanks. On 29.09.2008, at 18:28, Alvin wrote: Carlos Pita wrote: I'm not sure if I must report this as a bug, tell me so if it's the case. Most fluid windows don't play nice with tiling windows managers (wmii, awesome, dwm, xmonad, ratpoison) which depends on the class or instance of a window to be able to put it into a floating layer or layout. I have had a similar problem with FLTK apps and Compiz's animation rules. For example, from what I can tell, all windows in FLTK 1.3.x apps (incl. fluid itself) have a type of Unknown. As a result, FLTK windows do not follow the same animation rules as my other windows (KDE mostly). I have the same animation for all FLTK windows rather than different ones for dialogs, normal windows, etc. From using xprop, I believe the setting has to do with _NET_WM_WINDOW_TYPE(ATOM). http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
matthiasm wrote: Please file STRs for both issues, preferably with patches ;-) Thanks. On 29.09.2008, at 18:28, Alvin wrote: Carlos Pita wrote: I'm not sure if I must report this as a bug, tell me so if it's the case. Most fluid windows don't play nice with tiling windows managers (wmii, awesome, dwm, xmonad, ratpoison) which depends on the class or instance of a window to be able to put it into a floating layer or layout. I have had a similar problem with FLTK apps and Compiz's animation rules. For example, from what I can tell, all windows in FLTK 1.3.x apps (incl. fluid itself) have a type of Unknown. As a result, FLTK windows do not follow the same animation rules as my other windows (KDE mostly). I have the same animation for all FLTK windows rather than different ones for dialogs, normal windows, etc. From using xprop, I believe the setting has to do with _NET_WM_WINDOW_TYPE(ATOM). http://robowerk.com/ I'm up for it, but I need a little clarification. I've checked the source and this is what I see: * When show(argc, argv) is called (in Fl_arg.cxx) for the first window of the application, a check is made to see if xclass() has been set. If not, argv[0] is used. I have tested this and, sure enough, if I make a symlink called turnip to my program, the WM_CLASS is set to turnip,Turnip. Now, my apps have their main(int,char**) created by fluid. I'm not sure what happens when the show() is called instead of show(int,char**). If someone can tell me, it would be greatly appreciated. * Should the xclass() of other Fl_Windows (and its derivatives) be automatically set when show() is called? That is, of course, if not already set? If so, what should it be set to: (1) The same as the first window? Is that valid? (2) Or a distinct name, something like first window xclass#xid of the Fl_Window being shown. For example, the automatic xclass code would create something like fluid#0xdeadbeaf, Fluid#0xdeadbeaf when the widget properties dialog is shown. -- Alvin ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
On 29.09.2008, at 21:37, Alvin wrote: * When show(argc, argv) is called (in Fl_arg.cxx) for the first window of the application, a check is made to see if xclass() has been set. If not, argv[0] is used. I have tested this and, sure enough, if I make a symlink called turnip to my program, the WM_CLASS is set to turnip,Turnip. Now, my apps have their main(int,char**) created by fluid. I'm not sure what happens when the show() is called instead of show(int,char**). If someone can tell me, it would be greatly appreciated. Ah, I was wondering about that. The first show() call in an application always should be show(int,char**) for this and other reasons. I beleive it is in the docs somewhere, but I can see how easy it is to get that wrong. * Should the xclass() of other Fl_Windows (and its derivatives) be automatically set when show() is called? Yes, I think that is acceptable. If so, what should it be set to: (1) The same as the first window? Is that valid? Yes, I beleive that this is coded that way anyways, unless xclass() is set differently in a later call. If no class is given or show() is called, the window class will be FLTK (at least in MSWindows). It would probably be better to use the filename instead, but since argv[0] is not accessable here, we would have to go another route (plus argv[0] is not always valid anyways, but IIRC Greg has a collection of functions to get the executable path on all platforms?!) (2) Or a distinct name, something like first window xclass#xid of the Fl_Window being shown. No, I don't think so. From what I understand, the xclass shoudl be the same to signal to the WM that all windows belong to the same app. Which brings me to the first mail: I am very surprised that Fluid is not behaving correctly, and here seems to be the main problem, because Fluid does correctly call Fl::args(...) and main_window-show(argc, argv). http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
Greg Ercolano wrote: Alvin wrote: matthiasm wrote: Please file STRs for both issues, preferably with patches ;-) Mindless interjection: is this just a matter of modifying fluid to set unique names for the Fl_Window::xclass() of each of its windows? To solve the problem for Fluid, yes. I belive the fix would be to set the X Class field of every dialog in the Fluid source code (.fl files). However, I believe this is symptom of a much wider issue. The issue is, the first window of any FLTK app will have its WM_CLASS set to its argv[0] (unless set by the programmer). However, each subsequent Fl_Window will have no WM_CLASS. -- Alvin ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
