| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #979
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | FLUID |
|---|
| Summary: | Fluid: group box color not updated |
|---|
| Version: | 1.1-current |
|---|
| Created By: | Portale |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | 1.1.7 (SVN: v4517) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | Portale
13:52 Aug 11, 2005 |
| When changing the box color of a group that is in a tab, the changement is not immediately visible. It is only shown after something else in the dialog was edited.
See the self explaining example. | |
| |
| #2 | matt
14:51 Aug 15, 2005 |
| Color changes are never updated automatically in FLTK. You have to call 'redraw()' on the widget. This we could fix, but since it is called so rarely and triggers a major redraw, we never did.
In case of a Tab inside an Fl_Tabs group, you probably need to call 'redraw()' on the Fl_Tabs as well. That we can not fix since the library does not know if the parrent happens to be a Fl_Tabs which has its very own idea on drawing its graphics. | |
| |
| #3 | Portale
15:03 Aug 15, 2005 |
| I see. This makes sense in the runtime behavior of FLTK. And the application should handle this.
Since this effect is visible in Fluid, Fluid doesn't seem to handle it. Shouldn't then the whole preview dialog be refreshed if the color of a group in a tab (or any color property of any widget) is changed? | |
| |
| #4 | matt
14:06 Aug 16, 2005 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |
