| | [ Return to Bugs & Features | Roadmap 2.0 | Post Text | Post File ]
STR #1764
| Application: | FLTK Library |
|---|
| Status: | 5 - New |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Unassigned |
|---|
| Summary: | FLTK2.0 should support some form of DrawContext |
|---|
| Version: | 2.0-feature |
|---|
| Created By: | gga |
|---|
| Assigned To: | Unassigned |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post Text ]
| |
| Currently, all draw functions in FLTK operate under a global context, on top of the current active widget.
This is highly problematic.
FLTK's draw functions should be allowed to function on top of a context class. Thus, instead of:
fltk::drawline or fltk::drawtext
you'd have:
dc.draw_line() and dc.draw_text()
This would allow you to inherit from the base DeviceContext class to create your own device context.
For example, it is often needed to have the draw functions work with printing or to have the drawing happen to an off-screen buffer or to an fltk::Image so a separate thread can create or update images.
Also, this would make fltk's code much more multithread friendly, as you could have a draw matrix per context, for example.
This is also needed as some GUI toolkits (X11, for example), now allow updating stuff outside of the main thread.
Currently, FLTK's design makes all this quite impossible without creating different function names for all the same drawing routines. | |
| |
| #2 | fabien
12:27 Feb 22, 2008 |
| interesting point for a potential feature to study in next version probably... | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
FLTK Apps 
