Section 4 of 4 - Prev - Next All sections - 1 - 2 - 3 - 4
may be changed and the effect of changing them by commenting.
+ It's an additional form of documentation for power users of your app.
Many users create an application-specific defaults file of their own.
Those who do usually read the site-wide application defaults file
in order to see what's going on. To allow user-specified defaults
to take precedence over site-wide defaults, application developers
should always give the loosest resource binding and use class names
rather than instance names where possible, in the site-wide defaults file.
+ You can supply multiple versions, each implementing different styles,
languages, presentation arrangements, options, colors, demonstrating
the coherence and adaptability of your application by having the user
changing the value of their customization resource for your application.
Application default files may include other application default files,
making it possible to separate color customization from language
customization, from functional customization, for example.
Disadvantages of using fallback resources for the default resources of
the application:
- Fallback resources were not designed with this purpose in mind.
- Code bloat.
- Users and site administrators will be tempted to edit your source
in order to figure out what resources you have set and to make their
own changes, making things messy and difficult for them when it
comes time to update their sources.
- Anyone can override all of your default resources by supplying their
own application default file, often inexplicably breaking your app.
- You're not taking advantage of one of the most powerful features of
the X toolkit -- its provision for end-users to customize applications.
> I read where fallback
> resources should be a minimum to get the application running or to
> display an error if the application defaults cannot be loaded. Any
> idea what a "minimum" is :-) ?
The X Consortium's mail application, xmh, has an application defaults
file aptly named Xmh. If you remove this file, its fallback resources
are used. In that case it pops up a dialog box warning you that the
application functionality will probably not work because the application
defaults file is missing. This same design can be used as a versioning
check on the application defaults file, when one is used, and xmh implements
that as well -- so you can update your application and the app-defaults
file and implement a versioning check, and report it when the site
administrator failed to install your application correctly.
Now, try using the X Consortium's calculator application, xcalc, without
its application defaults file. Nothing works at all, and, it doesn't say
why, so the application is worthless and uncommunicative without its
application defaults file.
So a minimum is to report that the application defaults file is missing,
or, if you have a simple application, to have the minimum functionality
in place with no decorative resources set.
----------------------------------------------------------------------
Subject: 47.+How to get rid of that annoying flicker during updates?
----------------------------------------------------------------------
(From Young Nicholas , 3/24/95)
Flicker is caused primarily by the time taken between clearing all or part of
a widget's window and redrawing the contents (especially noticeable when the
same contents are redrawn). In Xt-based widgets this involves a round-trip
to the server because widgets first clear their window and then wait for the
Expose event to trigger redrawing. In heavily loaded systems or with slow
networks very significant flicker can occur.
The solution is not to wait for the Expose event but to redraw the contents
immediately after the SetValues call or equivalent. This can be done by
calling the widget's expose() routine in the core_class part of the class
structure, defined in the widget's private header file. You have to simulate
an Expose event but this is not hard. Here is a code fragment using a Motif
Label widget (the commonest widget with this requirement that I have seen).
#include
...
Widget label;
XExposeEvent xeev;
...
xeev.type = Expose;
xeev.display = XtDisplay (label);
xeev.window = XtWindow (label);
xeev.x = 0;
xeev.y = 0;
XtVaGetValues (label, XmNwidth, &w, XmNheight, &h, NULL);
xeev.width = w;
xeev.height = h;
XtVaSetValues (label, XmNlabelString, "Hello world", NULL);
(XtClass (label))->core_class.expose (label, (XEvent *)&xeev, NULL);
Since the redraw is done immediately after the window is cleared by the
XtVaSetValues call the flicker is practically eliminated. The widget's
contents will still be redrawn again when the real Expose event arrives, but
this is not a problem since the window is of course not cleared again first.
If the widget is very large it might also be worth trying to optimise the
rectangle in the simulated Expose event, but that would be difficult in
general.
----------------------------------------------------------------------
Subject: 48.+How are created, managed, mapped, realized, etc. related?
----------------------------------------------------------------------
(From pkimball@netcom.com (Paul Kimball) 11/1/93)
When a widget is first created, memory is allocated to
hold its instance data structure.
After creation, a widget has four attributes
that determine whether it is visible and/or
sensitive to user input. Any of these can be TRUE or FALSE:
Realized If TRUE, widget has gotten a window
from the server. It will display its
graphics in this window.
Managed If TRUE, parent of the widget agrees to
make room for the child via geometry
management. Note that the parent widget
always gets the final say on how big the
child appears.
Mapped If TRUE, server tries to display (map) the
widget's window.
Sensitive If TRUE, widget is sensitive to user input.
That is, the toolkit bothers to process its
input events.
Practically. what this means is as follows:
1. If a widget is unrealized, nothing else matters. It has no
window, and you'll never see it.
2. If a widget is unmanaged, it may have a window, but you
still won't get to see it because its parent
probably won't give it any display room.
3. If a widget is unmapped, it may have a window and the
parent may give it room, but you still can't
use it since the server is not bothering to
display the window.
4. If a widget is insensitive, you may be able to see it
but you can't interact with it.
A widget is most useful when it is Realized, Managed, Mapped
and Sensitive.
A widget is created, by default, in the Unmanaged, Unrealized,
Unmapped, Sensitive state.
When you manage a widget, it becomes mapped, by default. If the
parent is realized, it also becomes realized.
So by default, once you manage a widget, it is usually Managed,
Realized, Mapped and Sensitive:
1. It has a window.
2. The server is trying to display that window.
3. The parent widget has sized the window to some visible
size.
4. The widget is sensitive to user input.
So now you can see the widget and interact with it.
Why would you want to be able to manipulate these attributes
independently? Several cases:
1. You want a widget to be displayed, but not to
accept user input. Use XtSetSensitive() to
set it insensitive.
2. You want to remove a control from a dialog box without
causing the dialog box to resize itself, or
rearrange other controls. Use
XtSetMappedWhenManaged() to disable the default
behavior (mapped if managed) and then call
XtUnmapWidget() to unmap the child.
3. You are connected to a really awful server that has
run out of resources, and you need to give
back some memory. Call XtUnrealizeWidget() to
deallocate the window ID and other resources.
----------------------------------------------------------------------
Subject: 49.+How to use the String definition from a C++ library?
----------------------------------------------------------------------
The X11R4 and later header files are compatible with C++. The Motif
1.1 header files are usable as is inside extern "C" {...}. However, the
definition of String in Intrinsic.h can conflict with the libg++ other
String class and needs to be worked around.
What is the best way to work around this ?
#define String XtString
#include
#undef String
--
Pete Ware ware@cis.ohio-state.edu
The Ohio State University, CIS Dept http://www.cis.ohio-state.edu/~ware
2015 Neil Ave, Dreese Labs 774, w/ (614) 292-8501
Columbus, OH 43210 h/ (614) 488-8516
Section 4 of 4 - Prev - Next All sections - 1 - 2 - 3 - 4
