| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #904
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 3 - Moderate, e.g. unable to compile the software |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | X11 |
|---|
| Summary: | FLTK on Unix/XWindows: Fluid requires X-Windows to batch compile FLD files. |
|---|
| Version: | 1.1.6 |
|---|
| Created By: | chaircrusher |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | 1.1-current (SVN: v4422) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
No files
Trouble Report Comments:
| |
| #1 | chaircrusher
10:04 Jun 06, 2005 |
| Fluid requires the environment variable DISPLAY to be set, and pointing to a valid X Server, even when it's just generating .cxx/.h/strings files in a batch process -- i.e. 'fluid -c'
Platform RedHat Linux (though I think this is a problem on ANY system that uses FLTK with X Windows)
CVS Snapshot fltk-1.1.x-r4373
ANALYSIS:
If you don't define DISPLAY -- or if DISPLAY doesn't point to a running X Display -- then Fluid exits with the message "Can't open display:"
In fluid.cxx, nearly the first thing that happens is a call to the function 'make_main_window.' This in turn calls 'make_settings_window', which calls 'scheme_cb'
Within scheme_cb, if the environment variable "FLTK_SCHEME" is not defined, than scheme_cb calls fl_open_display, and then calls XGetDefault to retrieve the "scheme" value.
I thought that I could simply test the compile_only flag and suppress calling make_main_window, but that ends up causing a segmentation fault, because in file.cxx:read_file makes calls that eventually invoke Fl_Widget::redraw().
This is a pretty tangled web to unravel -- it appears that Fluid works by making 'live' versions of the widgets, attached to the top-level widget of the Fluid UI. Even though in batch mode, Fluid is creating it's whole user interface, but never displaying it. | |
| |
| #2 | chaircrusher
08:03 Jun 07, 2005 |
| More detail -- the alignment_panel widget in fluid has a scheme menu. It needs to be set up such that the currently selected scheme is selected in the menu.
If you have a scheme selected in your fluid.prefs, or a scheme specified in the environment variable "FLTK_SCHEME", then you don't call fltk_open_display.
If I ruled the universe, I'd put a check in Fl::scheme() to see whether DISPLAY is defined in the environment. If it isn't just set the scheme to "none", otherwise, try the fl_open_display and the call to XGetDefault. I don't think that would cause any trouble in the normal course of events -- if we're in an interactive Fluid session, or if DISPLAY is defined, the XGetDefault will succeed.
The fl_open_display happens in setting up the scheme_choice widget in alignment_panel.fl:
Fl_Choice scheme_choice {
label {Scheme:}
callback scheme_cb
xywh {116 10 115 25} down_box BORDER_BOX labelfont 1
code0 {int s;}
code1 {fluid_prefs.get("scheme", s, 0);}
code2 {scheme_choice->value(s);}
code3 {scheme_cb(0, 0);}
} {
fluid.cxx:
void scheme_cb(Fl_Choice *, void *) {
switch (scheme_choice->value()) {
case 0 : // Default
Fl::scheme(NULL);
break;
case 1 : // None
Fl::scheme("none");
break;
case 2 : // Plastic
Fl::scheme("plastic");
break;
}
fluid_prefs.set("scheme", scheme_choice->value());
}
Fl_get_system_colors.cxx:
int Fl::scheme(const char *s) {
if (!s) {
if ((s = getenv("FLTK_SCHEME")) == NULL) {
#if !defined(WIN32) && !defined(__APPLE__)
const char* key = 0;
if (Fl::first_window()) key = Fl::first_window()->xclass();
if (!key) key = "fltk";
fl_open_display();
s = XGetDefault(fl_display, key, "scheme");
#endif // !WIN32 && !__APPLE__
}
} | |
| |
| #3 | matt
02:49 Jul 15, 2005 |
| Fixed in Subversion repository.
Avoiding the Scheme calls.
Since I am not on an X11 machine at this moment, would someone please verify that this patch was sufficient? Thanks. | |
[ Return to Bugs & Features ]
|
| |
