[ Return to Bugs & Features | Post Text | Post File | Prev | Next ]

STR #2145

Trouble Report Files:

	Name/Time/Date	Filename/Size
	#1  greg.ercolano 21:26 Feb 08, 2009	foo.cxx 0k
	#2  greg.ercolano 22:30 Jul 25, 2015	problem.png 13k

Trouble Report Comments:

	Name/Time/Date	Text
	#1  greg.ercolano 21:26 Feb 08, 2009	Attached foo.cxx program shows the focus box is drawing its corners outside of the widget, living 'digital drit' behind on the window background. Probably the focus_box code needs to bring in the left and right edges a bit if the box() type is either of these:      FL_ROUND_UP_BOX      FL_ROUND_DOWN_BOX Those seem to be the only rounded boxes that have UP/DOWN versions affected by this problem, as only box types with an up/down option make them useful for buttons, and thus susceptible to focus boxes. I think FLTK uses an internal array to account for box border widths; maybe a similar technique can be used to recommend focus box sizing..?
	#2  greg.ercolano 20:25 Apr 22, 2009	Possibly the "focus box" can be drawn curved using the same algorithm that draws the curved box, so that the focus box stays within the curved area.
	#3  matt 03:55 Jan 20, 2023	It's also true for many other box types. Since all those are overridable, adding fixed offsets is useless. I suggest that we add a function to fl_box_table so that custom box tables can draw their own version of the focus indicator. The calling function would push the line style and set it to a width of 1 and dots, then calls the focus draw function, it there is one, then pops the graphics style. Otherwise, the driver focus rect function is called.
	#4  AlbrechtS 05:35 Jan 20, 2023	In my vision we'll have a Fl_Scheme* class hierarchy that will be used in basic drawing functions like fl_draw_arrow() etc.. I implemented the basics already in many widgets and for many different objects like fl_draw_check(), fl_draw_radio() etc. In the future Fl_Widget::draw_focus() could then call the scheme's method, or something like that. But that's not yet available. Extending the fl_box_table array (members) must be considered carefully because it would potentially break (or at least complicate) existing scheme additions in the user base. I know of at least one such addition that adds a user defined scheme in a patch. However, adding a member to the end of a struct might be uncritical, and at some time we'll have to do it. If we extended the table, I'd also like a flag that defines whether a certain boxtype has a background or is a frame type (w/o solid background) or even FL_NO_BOX (which is definitely 0). This would help us fixing issues when we (try to) find a parent widget with a background to mark it "dirty" when e.g. outside labels are drawn multiple times and become "fat" because of anti-aliasing effects. I believe there's another STR about this effect, and somewhere in the drawing code we depend on hardcoded boxtypes to determine the "background or not" property. This additional flag could either be added as a bit to the existing flag(s) byte or we could add another member if we change the struct anyway. Sorry for degressing again, but I felt this is somehow related.
	#5  AlbrechtS 05:36 Jan 20, 2023	Note: fl_draw_radio() is still WIP, not yet committed.
	#6  matt 07:59 Jan 26, 2023	I see no problem at all to extend fl_box_table in fl_boxtype.c . New members are appended and initialise to 0 if not set. We can have a set of flags that includes the pixel coverage of a frame (box or frame, fill or partial), an index into the up/down variant of a box, and a function pointer to drawing the focus box. Anything else while we are at it :) ?
	#7  AlbrechtS 05:21 Jan 27, 2023	I agree that it's OK to extend the table if all new members of a table entry can be initialized to 0 as either a sensible default value or a flag that it is *not* initialized. I'm not aware of any other things we'd want to add to the box table.

[ Return to Bugs & Features | Post Text | Post File ]