STR #2145

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

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

STR #2145

Application:FLTK Library
Status:5 - New
Priority:2 - Low, e.g. a documentation error or undocumented side-effect
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:FL_ROUND_UP_BOX+Fl_Button+"gtk+" scheme: focus box draws outside widget
Created By:greg.ercolano
Assigned To:matt
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
#1 greg.ercolano
21:26 Feb 08, 2009
#2 greg.ercolano
22:30 Jul 25, 2015
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
#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:


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.
bottom left image   bottom right image

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


Comments are owned by the poster. All other content is copyright 1998-2023 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.