| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #694
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 3 - Moderate, e.g. unable to compile the software |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | Box-eating Fl_Choice |
|---|
| Version: | 1.1.6 |
|---|
| Created By: | wilson.afn |
|---|
| Assigned To: | mike |
|---|
| Fix Version: | 1.1.7 (SVN: v4033) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
| |
| #1 | wilson.afn
17:53 Jan 08, 2005 |
| foo.fl
1k | |
| |
| #2 | wilson.afn
13:24 Feb 05, 2005 |
| foo.pgm
23k | |
Trouble Report Comments:
| |
| #1 | wilson.afn
17:53 Jan 08, 2005 |
| Carefully constructed Fl_Choice pulls a Mike Tyson on a neighboring Fl_Box. Foo.fl, included, shows the problem. Compile and invoke "-s normal" (if necessary), and rechoose the middle item, "bar".
Notes: FC3 (all yum'ed up), but also under a creaky old mingw (GCC 2.9.5?) and wine. | |
| |
| #2 | wilson.afn
07:06 Jan 11, 2005 |
| A followup:
It would appear (and in hindsight it should have been obvious) that it's the Fl_Box with the masochistic tendency to offer up its ear to the teeth of the Fl_Choice, and the latter has no recourse but to bite it off.
The same wound is inflicted by a fl_color_chooser() gizmo, even "-s plastic", but it is quite difficult to repeat since the precise position of the gizmo depends on the exact cursor position and color passed to the gizmo. | |
| |
| #3 | wilson.afn
07:10 Jan 11, 2005 |
| By "fl_color_chooser()", of course, I meant "fl_show_colormap()" ;D. | |
| |
| #4 | mike
11:12 Feb 05, 2005 |
| What should I do to reproduce this? I've tried this on my own FC3 system and was unable to get any visual artifacts to show up!
| |
| |
| #5 | wilson.afn
13:45 Feb 05, 2005 |
| Foo.fl didn't do it for you? On my system, I invoke "fluid foo.fl". In the fluid main menu, Alt-g compiles and executes the program as "./foo -s normal".
(I see this is technically wrong. It should be "... -s none", but it seems to have the same effect on my box. It brings up the non-plastic scheme which would otherwise be used since I have some goofy FLTK_SCHEME environment variable set to "plastic" to make FLWM look kewl.)
The effect does *not* show up "-s plastic". I have xwd-ed and gimped together a before and after view of the afflicted area into the posted file, foo.pgm, so you can at least see what I'm seeing. And yes, I am currently sober!
I am using the closed-source NVIDIA driver. I'll try it on my wife's box and let you know if there's any difference.
BTW, you may have to use xview to see it; foo.pgm segfaults flphoto. I knew you'd want to hear that :<D. | |
| |
| #6 | wilson.afn
14:40 Feb 05, 2005 |
| More news: Wife's mobo NVIDIA with open-source driver and IBM laptop with Neomagic graphics both exhibit the problem (with object generated by my box). WM that jockeys windows opaquely (e.g., FLWM) causes similar effect when another window is dragged slowly *upward* or *leftward* across the shadow-boxed widget.
It seems to me, the shadow-boxed outline is trespassing outside the widget extent. A little work with xmag and a little digging into the sources seems to show that the lower and right box border is drawn 4-pixels wide while Fl::box_dx() etal allow for only one pixel. | |
| |
| #7 | mike
17:42 Feb 05, 2005 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |
