RE: CTRL macro conflict on AIX 5.2 - wchar versions of form and menu functions

[Thomas Dickey]

On Fri, 12 Mar 2004, Jim Idle wrote:

>
>
> -----Original Message-----
> From: Thomas Dickey [mailto:address@hidden
>
> >> My next question is whether there are currently any plans to add wchar
> >> support to the menu and form/field processing code?  I wondered if
> >> there was any reason this had not been extended into forms and menus - 
> >> other
> >> than time?
> >
> >not time - I just didn't happen to think of it, since my focus has always
> >been on the ncurses library itself.
> >
> >I've started working on this.  Mike Aubury pointed it out, and the past
> >few patches have been directed toward this.  At this point I'm using the
> >ncurses.c 'r' test, fixing the issues that prevent it from working (by
> >pasting a wide-character from dialog's UTF-8 demo into an input field).
>
> That's good to hear. I already hacked a version together for my own
> testing purposes, but I really didn’t fancy playing with all the
> autoconf/configure stuff.

I think the configure-script aspect is fairly stable (rather ugly in the
places where it determines what #define's it needs).

> Menu code takes about 10 minutes to do, but the form stuff is a bit more

if even that much - it should "just work" (but I haven't studied it that
closely to see if there are problem areas).  Handling input is more work,
since more assumptions in the code tend to break there.

> intricate and took a bit longer; in the main, because it is using macros
> to calculate offsets into the buffers and making assumptions about char
> *.

I did notice that.

> In case it's useful info for your efforts, the easiest way (at least as
> I saw it) was to change to use UTF-32 for the internal forms buffers and
> reference them as int (UINT32 strictly speaking I guess) rather than
> char. This way the form code logic is fairly easy to deal with -
> converting between UTF-32 and wchar representations is trivial and
> surrogate pairs go away as an issue for calculating offsets into buffers
> etc. Other, probably obvious stuff is things like using iswspace() to do
> word wraps and the other iswxxx functions where appropriate etc.

yes, that would make it simpler.  A problem with doing just that is that
there are calls that return the buffer address - those would have to be
modified to return a pointer to a multibyte string equivalent of that. But
I haven't gotten far enough to worry about that.

Currently (aside from some unrelated bug-fixes), I'm looking to see how to
make the insert-character logic work properly.  The form library uses
winsch(), and then assumes that it inserted one column of data.  Acting on
that assumption, it follows with a wmove() to the "next" column.  Last
week I got partway into debugging a workaround for that detail, but it's
not done yet.  And, yes - it's occurred to me that this approach may not
work out, and it would be easier to convert libform's internal data to
wchar_t's.

> I think it's perhaps a bit more tricky to decide whether the functions
> should just change to accept different parameter types if enable-widec
> is used, or whether there should be new function names that accept wchar
> arguments (which seems somewhat cleaner and in keeping with the current
> xopen specs for curses I guess). However, you probably already have
> ideas on that.

Actually X/Open makes the old-style interface accept a multibyte string.
So (for cases where it doesn't radically simplify the caller), it is
workable to just handle that in the caller.  X/Open doesn't specify the
libform interface, but changing the field buffers to wchar_t* from char*
would make anything that used those header fields incompatible.

> I would greatly prefer to use the mainline code, than my own hacked
> version of menu and form, so I am glad to hear that you are dealing with
> it :-). Obviously, I would be happy to offer any assistance that seemed
> useful but I understand if you would prefer to just get on and do it
> yourself.

I'm not against getting patches - but they don't always do all of the work
(since I still have to understand what they do & repair things that aren't
complete).

>
> Thanks,
>
> Jim
>
> >There are some isolated things that I've seen which need attention - they're
> >bugs, but not on the thread I'm following.
>
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.618 / Virus Database: 397 - Release Date: 3/9/2004
>
>
>
> _______________________________________________
> Bug-ncurses mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-ncurses
>

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net