Bug 1974 - Xedit should work with '-xrm *international: false'
Summary: Xedit should work with '-xrm *international: false'
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: App/xedit (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-11-30 15:13 UTC by Paulo César Pereira de Andrade
Modified: 2008-07-14 13:23 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Paulo César Pereira de Andrade 2004-11-30 15:13:52 UTC
I noticed that xorg's version of xedit changed code like:
...
XtVaCreateWidget("textSource", international ?
                 multiSrcObjectClass : asciiSrcObjectClass,
...
to
...
XtVaCreateWidget("textSource",
                 multiSrcObjectClass,
...

  I suggest to revert that change as Xedit.ad file has been
changed to add "*international: True".

  I didn't review everything, but this patch, after proper review,
should be applied:
--
--- commands.c.orig	2004-11-30 21:52:27.253693296 -0400
+++ commands.c	2004-11-30 21:53:15.448366592 -0400
@@ -357,8 +357,8 @@
 	      XtRemoveCallback(scratch, XtNcallback, SourceChanged,
 			       (XtPointer)item);
 	      item->source = scratch =
-		  XtVaCreateWidget("textSource",
-				   multiSrcObjectClass,
+		  XtVaCreateWidget("textSource", international ?
+				   multiSrcObjectClass : asciiSrcObjectClass,
 				   topwindow,
 				   XtNtype, XawAsciiFile,
 				   XtNeditType, XawtextEdit,
@@ -495,8 +495,8 @@
 	    XtSetArg(args[num_args], XtNstring, NULL); num_args++;
 	}
 
-	source = XtVaCreateWidget("textSource",
-				  multiSrcObjectClass,
+	source = XtVaCreateWidget("textSource", international ?
+				  multiSrcObjectClass : asciiSrcObjectClass,
 				  topwindow,
 				  XtNtype, XawAsciiFile,
 				  XtNeditType, XawtextEdit,
--- xedit.c.orig	2004-11-30 21:52:31.490049272 -0400
+++ xedit.c	2004-11-30 22:00:16.520353920 -0400
@@ -74,6 +74,7 @@
 Widget topwindow, textwindow, messwidget, labelwindow, filenamewindow;
 Widget scratch, hpane, vpanes[2], labels[3], texts[3], forms[3], positions[3];
 Widget options_popup, dirlabel, dirwindow;
+Boolean international;
 Boolean line_edit;
 XawTextWrapMode wrapmodes[3];
 
@@ -247,8 +248,9 @@
 		  flags = 0;
 		  XtSetArg(args[num_args], XtNstring, NULL);	num_args++;
 	      }
-	      source = XtVaCreateWidget("textSource",
-					multiSrcObjectClass, topwindow,
+	      source = XtVaCreateWidget("textSource", international ?
+					multiSrcObjectClass
+					: asciiSrcObjectClass, topwindow,
 					XtNtype, XawAsciiFile,
 					XtNeditType, XawtextEdit,
 					NULL, NULL);
@@ -356,10 +358,16 @@
     textwindow =  XtCreateManagedWidget(editWindow, asciiTextWidgetClass,
 					vpanes[0], arglist, num_args);
     num_args = 0;
+    XtSetArg(arglist[num_args], XtNinternational, &international);  
+    ++num_args;
+    XtGetValues(textwindow, arglist, num_args);
+
+    num_args = 0;
     XtSetArg(arglist[num_args], XtNtype, XawAsciiFile);			++num_args;
     XtSetArg(arglist[num_args], XtNeditType, XawtextEdit);		++num_args;
-    scratch = XtVaCreateWidget("textSource",
-			       multiSrcObjectClass, topwindow,
+    scratch = XtVaCreateWidget("textSource", international ?
+			       multiSrcObjectClass
+			       : asciiSrcObjectClass, topwindow,
 			       XtNtype, XawAsciiFile,
 			       XtNeditType, XawtextEdit,
 			       NULL, NULL);
--- xedit.h.orig	2004-09-02 04:40:32.000000000 -0400
+++ xedit.h	2004-11-30 21:55:59.211470816 -0400
@@ -100,6 +100,7 @@
 
 extern Widget topwindow, textwindow, labelwindow, filenamewindow, messwidget;
 extern Widget dirlabel, dirwindow;
+extern Boolean international;
 extern Boolean line_edit;
 
 /*	externals in xedit.c 	*/
--

  Today was the first time I run xorg...
Comment 1 Roland Mainz 2004-11-30 20:40:23 UTC
Unfortunately the patch won't work that way as parts of the Xedit code assume
they can pass a FontSet to the textWidget object used by Xedit. The problem:
FontSets only work with '*international: True' ... ;-(
Comment 2 Paulo César Pereira de Andrade 2004-12-01 05:27:17 UTC
  I assume this code you talk about is the new Xprint support.
  Maybe I am the only person in the world that uses xedit. And I used it daily
for the last 6 years. The changes in the xorg tree just disables almost all the
code I wrote for xedit in those years (like syntax highlight, regex search, etc).
  I am sure it should be possible to have a flag to allow it to work in non
"international" mode.
  Please correct this problem, I just found it accidentally because the
(closed source) project I am working on now needs to run in Suse 9.2, and
found the problem when trying to edit some C source files.
  I know Xaw/xedit is not that great at support of languages that require
multibyte, etc Maybe you will do it properly now :-). But for editing
program files with no accented chars (or iso-xxx) it was very good before
these changes.
Comment 3 Daniel Stone 2007-02-27 01:24:42 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 4 Paulo César Pereira de Andrade 2008-07-14 13:23:17 UTC
  This bug can be considered closed now because xedit now
defaults to compile without Xprint support; if compiled
wit Xprint support, should default to state of bug report.

  But the problem is not really Xprint, but the fact that
Xaw doesn't have a TextWidget that transparently supports
multibyte characters (it is either single byte or wide byte
characters), but all the "cool" features I use (and developed)
like syntax highlight, auto indentation, regex only works
with the "single byte" text widgets.

  Shouldn't really be a huge of a problem to implement Utf8*
widgets as "subclasses" of of Ascii*, as well as
Render/Composite/etc aware widgets, but, at least "prototypes"
should be implemented in some client, like xedit.

  But I don't think this will ever be made, as there is no
demand for it.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.