|
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!
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.