Questions about FXAppWhat happens when the application shuts down?The original implementation of FXApp::exit() (from long ago) simply bailed out by calling the global exit(). This was bad for the following reasons: Resources were not reclaimed properly. This could have prevented other applications from starting for lack of resources. It prevented the application from doing any additional processing; the fact that an application is done with doing GUI work doesn't mean it's done with all of its work! A common scenario is a program which collects some info from the user via a GUI, then tears down the GUI and goes into batch mode. The application shutdown process was redesigned to address these and other problems. We now have a nice, prim-and-proper way to get this done in a way that leaves all memory previously occupied by the GUI available for the batch phase. We can also detect memory leaks more easily when all resources are cleaned up after the program is done, since any memory left behind after the destructor (~FXApp()) runs must be due to memory leaks. In the current distribution of FOX, calling FXApp::exit() will invoke FXApp::stop(), which will close all modal windows, then fall out from the top-level event loop (usually, FXApp::run()). Subsequently, the destructor ~FXApp() will cause all reachable resources to be destroyed; it also closes the display connection to clean up server-side resources. Running the destructor ~FXApp() may cause some latent programming bugs to come to the surface: Menu panes (i.e. FXMenuPane instances getting destroyed after their owner has already been destroyed. This usually manifests itself when a FXMenuCommand is trying to remove its accelerator from the FXMenuPane's owner's accelerator table. Since the owner has already been destroyed, this leads to a segmentation fault. The solution is to modify your code so that the owner (which is usually a FXMainWindow or FXTopWindow) to destroy all of the menu panes it has constructed. Icons, images, cursors, fonts and so on should also be destroyed explicitly. Memory debuggers like Purify will report memory leaks because most applications do not properly clean up these resources in their destructors. With the previous implementation of FXApp::exit() (described earlier), these kinds of resources were still "reachable" upon exit, and therefore weren't flagged as "leaks". The general rule is that resources which can be shared by various widgets (including icons, images, cursors, fonts, menu panes, etc.) should be explicitly deleted. You can think of these resources as being "owned" by some top-level widget; for example, an icon which is constructed and used in a dialog box for various buttons should be destroyed when the dialog box is destroyed. How do I find my FXApp object?To get your a pointer to your FXApp application, you need to call the public getApp() function of any FXId object. As FXWindow is a subclass of FXDrawable (a subclass of FXId) every widget in your program has this function. If your code is in an FXWindow or FXId subclass, you can call getApp(), else you should be able to call it from any FXWindow or FXId that you have. If your application uses a subclass of FXApp called MyProgram, you can use a cast to get a MyProgram pointer: ((MyProgram*)getApp()) You can also just call the static member function FXApp::instance(), which returns a pointer to the application object Questions about WidgetsCan text in FXLabel automatically wrap if there is more text than the widget can hold?No. Wrapping requires the getHeightForWidth() or getWidthForHeight() API's, and these require that one of the widget's dimensions be known. However, this is generally not possible for widgets that are nested deep down in the widget tree. At the top level [e.g. with the toolbars], we *can* use these API's since the constraint of the main window's size is directly known. Due to pretty sophisticated recursive layout procedures, we must insist that one thing be true at all times and that is that getDefaultWidth() and getDefaultHeight() always returns the same answer [the answer may be based on the contents, but for a given contents the answer must always be the same]. For a wrapped FXLabel, the width would determine the height, and possibly vice-versa. This would violate the assumption. What is the difference between LAYOUT_SIDE_* flags and LAYOUT_LEFT, LAYOUT_RIGHT,LAYOUT_TOP, LAYOUT_BOTTOM? The LAYOUT_SIDE_* flags are only interpreted by the packer type layout managers. So its no use specifying them for widgets that are not in a FXPacker, FXDialogBox, FXTopWindow or FXMainWindow. The layout manager uses these flags to check on which side of the packer the widget is going to be. A widget may not take all of its assigned space. Thats where the other layout flags come in. The LAYOUT_LEFT,LAYOUT_RIGHT,LAYOUT_TOP and LAYOUT_BOTTOM basically give hints how to position the widget in the available space. (Example: label at the top side of the packer, can be position on left using LAYOUT_LEFT, right using LAYOUT_RIGHT or middle using LAYOUT_CENTER_Y); What's the difference between sending a widget a (SEL_COMMAND, FXWindow::ID_SHOW) message and just calling its show() method directly?It's an efficiency issue, related to the layout algorithm. In most cases, when a window gets the FXWindow::ID_SHOW message, the default handler calls show() and then calls recalc() to mark the window's layout as "dirty" (i.e. scheduled for a re-layout). But since show() and hide() are themselves used in layout() in many cases, calling recalc() inside the implementation of show() and hide() would cause yet another layout() to happen. How can I specify a minimum window size for a FXTopWindow (or one of its subclasses, like FXMainWindow or FXDialogBox)?FXTopWindow has two hints you may use: DECOR_STRETCHABLE and DECOR_SHRINKABLE. Instead of DECOR_RESIZE, specify either one of them to control the resizing of the window. The FXDragCorner doesn't seem to notice these two hints and window managers may not follow these hints .So if your window is supposed to stay fixed size, don't stick a FXDragCorner in the window!!! What's the difference between the parent widget and the owner window?There are two kinds of relationships, parent->child, and owner->owned. For all except the root widget, a parent->child relationship exists. When a parent is destroyed, the parent it its turn destroys the children. In the case of owner->owned, the relationship cuts across the widget tree. In most cases, the programmer needs to make explicit arrangements for owners to delete the objects that they own. For example, a toolbar shell and a main window are on equal levels in the widget tree (both directly under root), but there is an owned/owner relationship also. So the main window must explicitly delete the toolbar shell. It sounds complicated, but the problem really only occurs for top-level windows, i.e. dialogs owned by main window, and so on. Even in pretty large applications, only a handful of such objects typically exist. Think of those owned widgets as icons and fonts, which also must be explicitly destroyed. FXDirList shows a + sign in front of a directory even though the directory has no subdirectoriesThis is an important optimization. Technically, the + should appear only if the directory has subdirectories. Practically, doing it "right" would be an order of magnitude slower, as one would have to scan each subdirectory every time you open a directory. On large (or slow) file systems, the cost of this scan is prohibitive. We chose to eliminate the extra disk I/O by "guessing" that there may be a subdirectory, and if it turns out we were wrong than we correct that guess based on reality. It is very fast. What is the difference between FXScrollWindow and FXScrollArea?Use FXScrollWindow if you want to embed a widget inside of scrolling window. This is handy in case you have a lot of controls but no space to put them. Use FXScrollArea if you're writing your own widget and need to have scrolling capability build in (like FXText, FXList etc.). Why can't I place a fixed-size FXCanvas inside an FXScrollWindow?The FXScrollWindow widget provides a very easy way to make any kind of window scrollable, but for some kinds of content it takes a little extra work. The difficulty has to do with FXScrollWindow's implementation of the layout() member function, which calls getContentWidth() and getContentHeight() to determine the width and height of the FXScrollWindow's single child window (its "content"). These calls to FXScrollWindow's getContentWidth() and getContentHeight() member functions are in turn delegated to the content window's getDefaultWidth() and getDefaultHeight() member functions. The purpose of the getDefaultWidth() and getDefaultHeight() member functions is to return the minimum width and height for a window, given its current state. For example, an FXLabel's default width and height are based on its text string, icon, internal padding and frame style. For many widgets, however, there is no sensible value for the minimum width or height, and for those widgets the getDefaultWidth() and getDefaultHeight() member functions return 1. The FXCanvas widget is one such widget. A common misconception is that if you simply specify the LAYOUT_FIX_WIDTH and LAYOUT_FIX_HEIGHT options in the FXCanvas constructor that the canvas is guaranteed to maintain whatever width and height you specify. This is not how it works! The LAYOUT_FIX_WIDTH and LAYOUT_FIX_HEIGHT options are merely layout hints, suggestions for a child window's layout manager and do not have any effect on a window's minimum width or height as returned by the getDefaultWidth() and getDefaultHeight() member functions. At best, they have an indirect effect on the window's actual width and height (i.e. assuming that the layout manager honors the child window's request for LAYOUT_FIX_WIDTH and LAYOUT_FIX_HEIGHT). So, the solution for realizing a fixed-size FXCanvas inside an FXScrollWindow is to insert a layout manager in between the scroll window and the canvas. Since most of the standard layout managers (such as FXPacker, FXHorizontalFrame and FXVerticalFrame) honor the LAYOUT_FIX_WIDTH and LAYOUT_FIX_HEIGHT layout hints, most any layout manager should do. Your code would look something like this: FXScrollWindow *scrollWindow = new FXScrollWindow(this, LAYOUT_FILL_X|LAYOUT_FILL_Y); FXPacker *contentFrame = new FXPacker(scrollWindow, LAYOUT_FILL_X|LAYOUT_FILL_Y); FXCanvas *fixedSizeCanvas = new FXCanvas(contentFrame, NULL, 0, LAYOUT_FIX_WIDTH|LAYOUT_FIX_HEIGHT, 0, 0, 2048, 2048); Here, the result should be a canvas with fixed size 2048x2048 pixels inside a scroll window. My OpenGL display lists are not shared between different FXGLCanvas/FXGLViewer widgetsThe FXGLCanvas/FXGLViewer actually has two constructors; the normal one does not share display lists; the other one passes into the constructor a pointer to another FXGLCanvas, which it will share lists with. So all but the first FXGLCanvas/FXGLViewer should be constructed with the first constructor. How can I hide the row and/or column headers in FXTable?You can hide the row and/or column header by changing the size of the headers to 0 and setting the header mode to fixed size (by default already set). To hide the column headers: table->setColumnHeaderMode(LAYOUT_FIX_HEIGHT); To hide the row headers: table->setColumnHeaderHeight(0); table->setRowHeaderMode(LAYOUT_FIX_WIDTH); table->setRowHeaderWidth(0); How to repaint widgets during a long computation in a non-threaded application?During your long calculation, periodically dip into the event loop, while blocking all user-generated events; the event loop should just process repaint and resize events, basically. You can use runModalWhileEvents(NULL), which will block all user-input events, and returns when the event queue has been drained. You may have to call this periodically since some types of events can generate more events. In FOX 1.7 this function has an extra parameter which controls the amount of time getNextEvent() waits for events to appear; in 1.7, a call to: runModalWhileEvents(NULL,waittime) will therefore return waittime nanoseconds after receiving the last event from the queue. This is more convenient than the old function, since after returning you can be ensured you've processed the entire batch of events and the system has been brought in sync again. How to force a repaint or an update of a widget?window->update() - Mark area as to be repainted at some time window->repaint() - Force painting of already marked area app->repaint() - Force painting of ALL marked areas app->flush() - Force draw commands to X server immediately sync flag says don't return until drawing has been performed [since X server is another process, this is usually not needed]. Somewhat related: window->forceRefresh() - Force GUI update of window and its children app->forceRefresh() - Force GUI update of entire application app->refresh() - Mark application as needing GUI update pass And: window->recalc() - Mark window as being in need of layout; note that layout works from top down. Thus, recalc() not only marks window, but also all of its parents. window->layout() - Layout interior of window immediately The underlying philosophy is that we want to avoid expensive drawing. update() does this by piling up and merging dirty rectangles and performing them at a later time [after processing all existing events]. The idea is that subsequent events may require yet another redraw, and by delaying it we could eliminate a bunch of intermediate redraws completely. A similar scheme applies when performing layouts. recalc() schedules a layout to be performed at some future time. If changes in window arrangement are made, there are usually more than one of them. We can reconcile the layout once and for all after we're catching up with the event stream. Miscellaneous QuestionsIs the mailing list archived anywhere?
These are the known archives of the foxgui-users mailing list:
What do the different version numbers for FOX mean?
Starting with the FOX 1.0.0 release, FOX library releases will have a version number of the form major.minor.patch. When the minor version number is odd, this indicates that it's a development version of FOX; when it's even, this indicates a stable release version. The intent is for even-numbered releases to keep the header files "untouched", in the sense of DLL compatibility. If bugs are fixed, the patch number will be increased. Thus, applications should be able to link to shared library versions of FOX with confidence. For odd-numbered releases, everything may be changed from one patch level to the next, so one would have to recompile applications (that's the nature of it being a development version!).
What version of FOX should I use?
Is FOX thread-safe? Can I write multithreaded applications with FOX?
FOX assumes one single thread to be responsible for the
User Interface related tasks. This is because certain FOX resources are
not thread-safe; also, because on MS-Windows message queues from a
window are tied to the thread that created that window, it is very
important for portability reasons that it is always the same thread
performing the User Interface tasks.
You can however use any number of threads in your application, as long as they are worker bees, i.e. they do not perform User Interface functions. FOX provides platform independent thread support via the following classes: FXThread, FXMutex, FXMutexLock,FXCondition and FXSemaphore. Synchronization between the User Interface thread and the worker threads can be performed using FXGUISignal. . FOX now also includes support for POSIX Threadsafe functions for file/directory handling
Does FOX have socket support?FOX doesn't contain any specific socket classes, but it does provide a mechanism to allow a programmer to add the socket event handle to the main event loop. Under Unix this simply means calling socket(...) then calling the FXApp::addInput() method with the socket return value. Under Win32, it gets a little or a lot more complicated. Since a windows socket is not a true Win32 event handle, there are two things you can do:
Having said all that, FXEX contains an implementation of socket classes (for server and client) which hide a lot of this complexity away. It uses implemntation No. 1, associate a socket with a Win32 handle. Note: File,Pipe,Socket IO is currently being worked on. (FOX 1.5.7 and above
What about other IO mechanisms such as serial ports?
Does FOX support internationalization?
How does FOX compare to <other toolkit name here>?
Can I use FOX on Mac OS X?
Will FOX someday use STL for strings and Maps?Never say never, but in this case the likelihood of having STL Strings is probably zero.
The question to ask is, what would be the point of switching over to std::string instead of FXString, or std::map instead of FXDict? FOX's data structures are very highly optimized for their purposes and one would probably have a tough time demonstrating that similar classes from the STL are better for those purposes. It's perhaps also important to note that just because FOX doesn't use STL classes in its implementation, that doesn't prevent you from using STL in your application. -- Lyle Johnson
How to setup Anti-aliased FontsTo use anti-aliased fonts in FOX you need to compile FOX with XFT. You can enable this by specifying --with-xft=yes when running configure.
The latest versions of FOX (1.4.x and up) will automatically choose the right default font. For older release you might need to follow the instructions below: To adjust global FOX font, either run "ControlPanel" or go to the FOX registry directory (~/.foxrc) and create a file named "Desktop". In Desktop all fox application wide settings are kept. Note that it may already exist. Next thing you do is create the following section: [SETTINGS] normalfont="Sans,90" Sans is the font name and 90 is the size of the font times ten. If FOX still cannot detect the right font to use (ie. it uses a aliased font, try specifying a more detailed font name like: "Bitstream Vera Sans".
Does FOX provide anyway to load shared libraries or plugins ?
|