| | [ Return to Bugs & Features | Post Text | Post File | Prev | Next ]
STR #2178
| 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: | Core Library |
|---|
| Summary: | Allow Fl_X::make_xid() to call user defined function |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | sanel.z |
|---|
| Assigned To: | Unassigned |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post Text ]
| |
| #1 | sanel.z
04:35 Mar 22, 2009 |
| Fl_X::make_xid() is central place for OS specific way for window creation. The bad way is that it is too monolithic; there is no way to do something before window is mapped, without copying all the code.
For example, setting titlebar icon via X's libXpm could only be handled when X window is fully constructed, but before it is mapped (via XMapWindow).
Also, setting some WM-specific properties (like _NET_WM_TYPE_*) is best recognized by window managers when window is not mapped yet; setting these properties on mapped windows requires pretty up-to-date window manager that could recognize these changes.
So, function prototype and implementation could look like this:
void Fl_X::make_xid(Fl_Window* win, XVisualInfo *visual, Colormap colormap, void (*before_map)(Fl_Window*) = 0) {
// ... all the code
if (before_map)
(*before_map)(win);
XMapWindow(fl_display, xp->xid);
// ... rest of the code
}
Fl_Window parameter for user callback is useful so user can access Fl_Window data.
Also, there could be a callback function after XMapWindow() was called, but before fully was drawn. | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
FLTK Apps 
