| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3237
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| 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: | Light, radio and check buttons clips off by one and return button rather uggly |
|---|
| Version: | 1.3.4 |
|---|
| Created By: | vuokko |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | 1.3.4 (SVN: v10775) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | vuokko
18:14 Jun 24, 2015 |
| Fl_Light_Button, checkbox and radiobutton clips one pixel too late causing bad look when clipping. Return button clips too late also. Attached screenshot. Please zoom in. | |
| |
| #2 | vuokko
18:17 Jun 24, 2015 |
| This was found on Linux. | |
| |
| #3 | greg.ercolano
21:14 Jun 24, 2015 |
| Attaching zoom.png for clarification | |
| |
| #4 | AlbrechtS
03:46 Jun 25, 2015 |
| Please try the attached patch button_v1.patch. This patch changes Fl_Light_Button::draw() which is also used for Fl_Round_Button and Fl_Check_Button. See also button_v1.png for my test results.
Test statements are intentionally included and active, showing which button is drawn (its label()) and the widget and label positions and sizes, resp.
Not intensely tested, this is more a proof of concept. Fine tuning the clipping is still possible (maybe one or two more bits?).
I did not (yet) check the other button draw methods. Particularly Fl_Return_Button should obviously get another patch...
Thanks for the report and the test program.
Please test and report if this is what you expect. | |
| |
| #5 | AlbrechtS
03:54 Jun 25, 2015 |
| Attached file button_v1a.png shows Fl_Light_Button with focus box. The focus box does not draw over the label text, so I believe that this is the optimal clipping width. | |
| |
| #6 | greg.ercolano
06:52 Jun 25, 2015 |
| I was thinking the same (clip inside the focus box area).
I agree that might be best for looks, though it might make
buttons in existing apps that have text crammed to the limit
to now clip where they didn't before. | |
| |
| #7 | AlbrechtS
09:00 Jun 25, 2015 |
| As I wrote before, there is space for optimization.
(1) The focus box appears to be offset 2 px at the top and left borders, but 3 px at the right and bottom borders. In this case box_dx() is 2 on all sides, so the focus box could be enlarged by 1 px to the right and bottom.
(2) The space between the mark and the label is currently calculated as box_dx() + 2, and this uses the box_dx() value of the widget's box. The same is used for the space to the left, which seems adequate. However, we could shrink the space between the mark and the label, to a constant, maybe 2 or 3.
(3) We could ignore the focus box (space). Focus changes, and we (the users) can probably live with the focus box overwriting the last pixel of the label text temporarily.
(4) If we used (3), then the label would be clipped exactly at the box frame, which might look bad as well. There is also anti-aliasing which can additionally overlap the box frame. I think the best choice might be to leave one px space between the border and the label (ie. right border width = box_dx()+1).
I propose to use (4) and less space (say, 2-3 px) between the mark and the label. This should give us the best look and most label space.
Additionally I'd like to take a look at the focus box drawing, which might be corrected as well, as stated above.
I won't be able to post another patch today, but maybe tomorrow or in the next few days. | |
| |
| #8 | AlbrechtS
06:24 Jun 26, 2015 |
| Please try attached patch button_v2.patch and report if this fixes the issue for you. button_v2.png shows my test results.
This patch includes:
- fixes for all shown button types
- test (printf) statements (deactivated)
- patch for test/buttons.cxx to reproduce my test results
Please use patch -p0 to apply the patch, make, then run test/buttons.cxx.
If this patch is okay, I'll commit only the *real* fixes w/o test/buttons.cxx changes and w/o test statements.
Note that I didn't touch Fl_Widget::draw_focus(). There are some assumptions (W-1, X++, Y++) under certain conditions which I can't confirm now, so I'm leaving this as-is. The result is that the focus frame can temporarily overwrite some pixels of the label. This could happen before as well, hence it is not a regression. Please test yourself.
Comments welcome. | |
| |
| #9 | AlbrechtS
08:21 Jun 27, 2015 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |
