Hi,
Here are some comments/ideas about your patch:
[SNIPPED reason for changes]
> case K_BACKSPACE:
> + /* destructive backspace */
> tn5250_display_kf_backspace (This);
> + tn5250_display_kf_delete (This);
> break;
This will work, but what about those of us who don't want destructive
backspace? This should be a config option so that each user can turn
it off & on as required.
[SNIP]
> + /* If in first position of field, stay there */
> if (tn5250_display_cursor_x (This) == tn5250_field_start_col (field) &&
> tn5250_display_cursor_y (This) == tn5250_field_start_row (field)) {
> - field = tn5250_display_prev_field (This);
> if (field == NULL)
> return; /* Should never happen */
> tn5250_display_set_cursor_field (This, field);
> - if (tn5250_field_length (field) - 1 > 0)
> - tn5250_dbuffer_right (This->display_buffers,
> - tn5250_field_length (field) - 1);
> return;
> }
Once you've removed the "field = display_prev_field (This)" the
"if (field==NULL)" is superfluous, and should also be removed.
But, again, this should be a configuration option, so that users can
turn it on or off depending on their preference. For example, I want
my cursor to go to the previous field when I hit backspace. I'm used
to RUMBA, MochaSoft and standard IBM greenscreen terminals, all of which
backspace to the previous field.
So, if you want backspace to stop, I want it to go to the previous field,
how do we accomodate both of us? With a config keyword.
[SNIP]
> + <Key>BackSpace: string("\177") \n\
This breaks the BackSpace key on my computer. After applying this patch,
BackSpace works exactly like Delete does. In fact, my ASCII chart says
that \177 is "delete". \010 is Backspace. But, maybe that's a
difference between Sweden and the US?
At any rate, without this change, destructive backspace works as I
expected it to. Can try using this instead:
<Key>BackSpace: string("\010") \n\
If that works for you, we could put that in the main distro, and it
SHOULD work for everyone.
> + ~Shift <Key>Insert: string("\033[2~") \n\
> + ~Shift <Key>Delete: string("\033[3~") \n\
These are the escape codes that Insert and Delete send on my system (by
default.) So this works fine on my system (but it worked without doing
this as well)
[SNIP]
> +! Color scheme which is easier on the eyes than the default
> +xt5250*color0: seashell
> +xt5250*color1: red4
> +xt5250*color2: darkblue
> +xt5250*color3: yellow3
> +xt5250*color4: blue3
> +xt5250*color5: magenta3
> +xt5250*color6: blue
> +xt5250*color7: #888888
> +xt5250*color8: white
> +xt5250*color9: red
> +xt5250*color10: green
> +xt5250*color11: yellow
> +xt5250*color12: blue
> +xt5250*color13: magenta
> +xt5250*color14: darkgreen
> +xt5250*color15: #444444
> +xt5250*cursorColor: red
Color schemes are another one of those things that are user-preferences.
It's my opinion that the main distribution of tn5250 should stick to the
default color scheme, so that it looks like a "normal" 5250 terminal.
If you want to change it, I'd recommend changing it with the color
keywords in your tn5250rc file instead of in XTerm, so that when you
update to a new version of tn5250 you don't lose your changes.
>
> The color/colour issue really requres a user configurable option to be
> really user friendly. This will do for now though.
>
By using tn5250rc, the individual user has the ability to override them as
well.
for example, you can have systemwide defaults in
${PREFIX}/etc/tn5250rc
and each user can have his/her customizations in
${HOME}/.tn5250rc
>
> The keyboard issue is actually a mismatch between the XTerm resource file
> and the terminfo entry supplied for 'xterm-5250'. There are more mismatches
> in the terminfo entry ( all the F-keys) but seeing they work I decided the
> interpretation of keypresses was being done outside terminfo/ncurses and
> didn't delve deeper.
>
I'm thinking that this is probably a difference between the Swedish
keyboard and the American keyboard. It's not a "mismatch" so much as it
is an assumption, in the xterm-5250 definition, that all copies of xterm
in all countries send the same escape codes.
Of course, the proper fix is a full-blown keyboard mapping software, but
that's a big project.
> The font issue was solved by putting '-fn 12x24' in the xterm command line
> in the xt5250 script. Can also be solved by setting the default font in the
> XTerm resource file.
Again, a better solution is to modify the tn5250rc file. Again, this
allows you to have a systemwide default as well as a per-user default.
Plus, next time you install a new copy of tn5250, you won't wipe out
your customizations.
To do that, add the following keywords to your ${PREFIX}/etc/tn5250rc
file and/or the ${HOME}/.tn5250rc file:
font_80=12x24
font_132=12x24
> If someone can direct me to a sans serif font of the
> same size I would be greatful though. The serifs clutter the screen.
My only suggestion would be to run xlsfonts(1) or xfontsel(1) to
see if you can find a font that's more to your liking.
Good Luck, and thanks for the feedback!
_______________________________________________
This is the Linux 5250 Development Project (LINUX5250) mailing list
To post a message email: [EMAIL PROTECTED]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/linux5250
or email: [EMAIL PROTECTED]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/linux5250.
