Re: [fltk.development] [RFE] STR #2942: Buttons keep the same color when clicked

2013-04-08 Thread Albrecht Schlosser 

[STR Closed w/o Resolution]

Link: http://www.fltk.org/str.php?L2942
Version: 1.3-feature
Fix Version: 1.3-current


No, sorry. We won't set anything (e.g. selection_color) w/o the user
explicitly requesting it. This would also break apps that have the colors
set as-is. The usual default is to use the selection_color(), and this is
taken from a system color. As I wrote before, the setting you proposed
would also be sub-optimal for other FLTK schemes.

I'm closing this STR now.


Link: http://www.fltk.org/str.php?L2942
Version: 1.3-feature
Fix Version: 1.3-current

___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev

Re: [fltk.development] RFC: method to find top level window?

2013-04-08 Thread Albrecht Schlosser 
On 06.04.2013 07:55, Greg Ercolano wrote:
 Is there a method that returns the top-level window manager window
 for the current widget?

 window() is not it; this just returns the parent window
 which won't be the top-level window when there are
 windows within windows, eg:

 Fl_Window *top = new Fl_Window(..);
 top-begin();
   Fl_Window *sub = new Fl_Window(..);
   sub-begin();
   :

 It seems unlikely we don't have such a thing, but I think
 supporting nested windows is something recent, and I see
 places in our code that do inline loops instead of calling a method.

 If there isn't such a method, would like to suggest we add one,
 the code being something like:

 ---
 Fl_Window *Fl_Widget::toplevel_window() const {
Fl_Window *top = window();
while (top  top-window()) top = top-window();
return top;
 }
 ---

 Comments?

ISTR that we discussed adding such a method a while ago, and that
it probably wasn't done for some reasons. However, thinking about
it, I don't know what this might have been. Too simple ? What, if
the top-level window still has a (non-window) parent widget? Does
it matter ? I don't know.

Anyway, since it's not much code, could we probably add it to the
header file as an inline method ? I think so. If there were a vote
request, my vote would be +1, unless there are reasons not to do
it that I don't know of (yet). Other opinions, votes?

BTW: toplevel_window() doesn't look bad, but what about top_window().
Less typing ;-)

Albrecht

___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev

Re: [fltk.development] RFC: method to find top level window?

2013-04-08 Thread Greg Ercolano 
On 04/08/13 15:32, Albrecht Schlosser wrote:
 On 06.04.2013 07:55, Greg Ercolano wrote:
 BTW: toplevel_window() doesn't look bad, but what about top_window().
 Less typing ;-)

Yes, what I based 'toplevel_window()' on was that in our code,
the term 'top-level' is used fairly consistently to refer to
the real window in a widget hierarchy.

This, as opposed to 'top' as perhaps meaning the window on top
of all others in window depth (along the Z axis)

I have no real preference otherwise.

BTW, on a similar new method train of thought; had to add a method
to Fl_Widget called window_offset() which returns the x/y offset
of the current widget relative to the top-level window (top window? ;)
to fix STR #2944 (r9866).

Again, I'm indifferent on naming; perhaps there's a better name
for what this method should be called.
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev