Re: [fltk.development] WM_CLASS property for fluid windows

[Alvin]

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

Carlos, I have created a patch  that
hopefully fixes this. It will work for all FLTK apps, not just Fluid. In a
nutshell, if a WM_CLASS has not been set by the using by calling
Fl_Window::xclass(const char*), then the WM_CLASS that was first window
shown will be reused.

Could you try it and see if it does what you are asking.

Thanks.

-- 
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

[Alvin]

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

[Fabien Costantini]

> 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
___
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]

> Albrecht Schlosser wrote:
> 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.
No prob,
I guess what I really would like to emphasize as for today is:
The Fl class is much too populated IMHO and with static methods that should be 
located as static methods in other classes.

I suppose that those who maintain to the doxygen documentation will quite 
understand what I mean by this :-)

This said, we don't want to change that for Fl existing static methods because 
I believe we would risk to fall in one of the traps where we've been in FLTK2; 
meaning that if the 1.3 version features too many uncompatible changes with 
1.1.9, many fltk users won't even try to use it.

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

[Alvin]

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

[Albrecht Schlosser]

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]

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
___
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]

>
>
> > 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

[MacArthur, Ian (SELEX GALILEO, UK)]

> 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

[Fabien Costantini]

> 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

[Albrecht Schlosser]

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)]

> 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.

I have a chunk of code where (due to the stupid and awkward args
processing I'm doing at application startup) it isn't practical to call
show(argc, argv)... So I call show() instead, but always make a point of
calling Fl::get_system_colors() before I call show() the first time.

I haven't looked closely at the fluid sources, but maybe there's some
reason there why it doesn't call show(argc,argv).

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?


> (plus argv[0] is not always valid anyways, but IIRC Greg has a  
> collection of functions to get the executable path on all platforms?!)

That might have been me, actually. Or at least, I have code for
determining the executable path on the majority of platforms, if we need
it.

-- 
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

[Alvin]

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

Re: [fltk.development] WM_CLASS property for fluid windows

[matthiasm]

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  xclass>#.

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]

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?
___
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

[Alvin]

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 #. 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

[matthiasm]

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

[Alvin]

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