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
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
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
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?
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
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
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
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
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,
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
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
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
12 matches
Mail list logo
