See the comment in the test program below (which you should compile on a machine with XFree86 4.0 installed with "-L/usr/X11R6/lib -lXaw"); it explains the bug. I want to emphasize yet again that XFree86 4.0 is not ready for prime time and really shouldn't be the default XFree86 version in the next RedHat release. I have also submitted a bug report about this to the XFree86 development team. /* This program illustrates a bug in the Text widget (or perhaps the AsciiText widget) in XFree86 4.0. When you click on the "command1" button, two different character replacements are done in the displayed text wiget before the insertion point, and redisplay is disabled while both replacements are done. Note that the insertion point moves when redisplay is reenabled; it shouldn't (this is the bug). When you click on the "command2" button, redisplay is enabled after the first replacement and then disabled again; in this case, the insertion point is not incorrectly changed by the two replacements. */ #include <X11/Intrinsic.h> #include <X11/Shell.h> #include <X11/StringDefs.h> #include <X11/Xaw/AsciiText.h> #include <X11/Xaw/Box.h> #include <X11/Xaw/Command.h> #include <stdio.h> Widget text; void callback(Widget widget, XtPointer closure, XtPointer call_data) { XawTextBlock block; int position; int mode = (int) closure; block.firstPos = 0; block.length = 1; block.ptr = "F"; block.format = XawFmt8Bit; printf("Setting insertion point\n"); XtVaSetValues(text, XtNinsertPosition, 8, NULL); printf("Disabling redisplay\n"); XawTextDisableRedisplay(text); XtVaGetValues(text, XtNinsertPosition, &position, NULL); printf("position is %d\n", position); printf("Replacing character 0\n"); XawTextReplace(text, 0, 1, &block); XtVaGetValues(text, XtNinsertPosition, &position, NULL); printf("position is %d\n", position); if (mode == 1) { printf("Enabling redisplay\n"); XawTextEnableRedisplay(text); printf("Disabling redisplay\n"); XawTextDisableRedisplay(text); } printf("Replacing character 4\n"); XawTextReplace(text, 4, 5, &block); XtVaGetValues(text, XtNinsertPosition, &position, NULL); printf("position is %d\n", position); printf("Enabling redisplay\n"); XawTextEnableRedisplay(text); printf("\n"); } int main(int argc, char *argv[]) { Widget shell, box, command1, command2; XtAppContext context; XtCallbackRec callback_list[2] = {{0}}; shell = XtOpenApplication(&context, "Test", NULL, 0, &argc, argv, NULL, sessionShellWidgetClass, NULL, 0); box = XtVaCreateManagedWidget("box", boxWidgetClass, shell, NULL); text = XtVaCreateManagedWidget("text", asciiTextWidgetClass, box, XtNeditType, XawtextEdit, XtNstring, "foo\nbar\nbaz\nfrelt\n", XtNinsertPosition, 8, XtNheight, 100, NULL); callback_list[0].callback = callback; command1 = XtVaCreateManagedWidget("command1", commandWidgetClass, box, XtNcallback, callback_list, NULL); callback_list[0].closure = (XtPointer) 1; command2 = XtVaCreateManagedWidget("command2", commandWidgetClass, box, XtNcallback, callback_list, NULL); XtRealizeWidget(shell); XtAppMainLoop(context); return(0); }
verified problem still exists in xfree86 4.0.1.
Unfortunately, the XFree86 team has pretty much deprecated Xaw, and other older X stuff like Xt. While they accept patches to fix bugs, they do not actively support the legacy code. At least that is my understanding from talking with Keith Packard nd David Dawes at LWE. Since this stuff is quite ancient, I won't realistically be able to try to bughunt this one until I've covered all higher priority bugs. Since I know you're actively working on xaw though I'm undefering this bug. If you can submit me a patch like you've been doing with all the other xaw related stuff, I'd be more than glad to add it to X and run it upstream to ensure the fix gets in the core codebase. Thanks in advance.
Update.. Xaw is not unsupported... Xt is "discouraged" and considered obsolete. At any rate it would be nice to fix any bugs in them nonetheless.
Please try XFree86-4.0.3-12 from: ftp://people.redhat.com/mharris/xfree86 I believe this problem is solved now. Do you see it working now?
It does not appear to me to be resolved. Here's what I have installed right now: XFree86-twm-4.0.1-0.37 XFree86-75dpi-fonts-4.0.1-0.37 XFree86-devel-4.0.3-13 XFree86-xf86cfg-4.0.3-13 XFree86-100dpi-fonts-4.0.1-0.37 XFree86-tools-4.0.1-0.37 XFree86-libs-4.0.3-13 XFree86-xfs-4.0.3-13 XFree86-Xvfb-4.0.3-13 XFree86-doc-4.0.1-0.37 XFree86-Mach64-3.3.6-32 XFree86-VGA16-3.3.6-32 XFree86-4.0.3-13 When I compile and run my test program, it behaves as described in the bug report, i.e., incorrectly.
Verified in 4.0.3 as still a bug. Sending upstream.
I don't know if this is fixed in current XFree86 or not (haven't tested), but perhaps you could comment. I've sent your various xaw patches to XFree86.org several times now, and they do not apply them. No response back as to why or anything. I've just re-sent all patches you've sent us once again, and am hoping that they apply them this time, or provide acknowledgement of receipt and explain why they're refused, even if that explanation is simply "low priority". Just as a suggestion for future bug reporting that might help keep us all in code sync, and hopefully resulting in the stock XFree86 releases containing all bugfixes from the wild... when reporting a bug, particularly if it has an attached fix, could you also report the bug to xfree86, and send patches to fixes. (Or just CC both). I'm going to close this as RAWHIDE for now, hoping it is fixed. If it is still broken, feel free to reopen, and please notify the XFree86 team as well. I wish they had a bugzilla database too. ;o(
Wonder of wonders, this appears to be fixed in XFree86 4.2.0. I have, indeed, sent most of my fixes to the XFree86 folks directly, in addition to reporting them to you. Presumably, they're ignoring my stuff because no one is really maintaining Xaw. Sigh.
*** Bug 121805 has been marked as a duplicate of this bug. ***