STR #694

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 | Roadmap 1.1 ]

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
Created By:wilson.afn
Assigned To:mike
Fix Version:1.1.7 (SVN: v4033)
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Name/Time/Date Filename/Size top right image
#1 wilson.afn
17:53 Jan 08, 2005
#2 wilson.afn
13:24 Feb 05, 2005
bottom left image   bottom right image

Trouble Report Comments:

Name/Time/Date Text top right image
#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.  
bottom left image   bottom right image

Return to Bugs & Features ]


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