|
On Thu, 3 Jun 2004, Scott Klement wrote: > There are a number of other options as well. I'd hate to think that it's > necessary to hard-code all of the ones that will have to be handled > specially. Hmm... the ones I mentioned are the only ones that show up in the help. > getopt_long() does work, but it's NetBSD's implementation, not GNU's. > There's a listing of the differences between them on the following page: > > http://www.freebsd.org/cgi/man.cgi?query=getopt_long Ok, I'll look at this and make sure it works for both platforms. > Now that I've gotten it to compile, I see that you're overriding lib5250's > keyboard handling? If I type a key in a field that's supposed to be > uppercase-only, it shows up as lowercase then converts to uppercase when I > hit enter. Actually, I'm not overriding it. Right now I'm working on the problem of redrawing the screen. Here's what happens: 1. You press a key. Xlib gets the keypress event and reports the event back to x5250. 2. x5250 finds out what key was pressed from Xlib. x5250 returns the result to lib5250. At this point x5250 knows what key was pressed and remembers it. 3. lib5250 processes the key stroke given it by x5250. Then it calls x5250_terminal_update(). 4. Currently, in order to minimize calls to the Xlib drawing functions, x5250 only redraws the screen if the key stroke cause either network activity to occur (Tn5250Terminal->conn_fd has pending data) or when the keyevent occurred x5250 set a force update flag (currently set on field plus, field minus, and field exit). 5. If the screen isn't redrawn due to one of those conditions, x5250 simply draws the key that it already had to figure out when the keyevent was originally received. This makes sense (if you ignore what lib5250 does to the characters) because x5250 already knows where to put the character and what character to put there. What should be done is that x5250 should remember where the cursor was and ask lib5250 what character should be drawn in just that place. That way we don't have to run through the loop of the whole screen to find the one character that changed and we also get the correct output on the screen. Fewer drawing requests and the correct output :) This particular fix is in the works. > I can type letters in numeric fields -- although it stops me after the > first letter... then error reset doesn't work, you have to hit Ctrl-R > instead of error reset -- and then it doesn't clear the message line, so > you have to just know that pressing ctrl-r worked, despite that error > reset didn't. :) The error reset key (as mapped for xt5250 or tn5250) doesn't exist in x5250 because x5250 is neither an xterm nor a console. x5250 receives the raw key presses as events. This has some advantages (no messing with termcap/terminfo) and some disadvantages (we need a method for keymapping). Fortunately, Xlib provides a way to get user defaults so we have a method for specifying on a per-user and site-wide basis what keys should do what. But it won't involve XTerm since x5250 isn't an xterm. I have some cool ideas on how to let the user change key mapping on the fly and then save those changes using Xlib's user defaults support. As far as the message line goes, the standard message line that contains "X SYSTEM" or "X II" hasn't been implemented yet. What you do have at this point is a changing mouse cursor: when input is inhibited the mouse cursor changes to an X. Of course the standard message line will also be implemented, and the mouse cursor changing will be selected by a user default. The lack of this message line is also why the message waiting indicator does not show up but instead prints "message waiting" to stdout. This message line shouldn't be hard to do, it's just not there yet. btw - the message line that actual messages show up on is there and does work, I refer only to the lowest line of xt5250 that has the cursor position on it and shows such indicators as message waiting, system busy, or system wait. Another note: in my tree I have the left mouse button work as the reset key. Certainly not for everyone, but I think it is a great feature. I was talking with some other people about it and they mentioned the idea of clicking on the "X II" part of the indicator line (once implemented) to reset. And clicking on "MSG" to see the waiting message. > Can I ask why you rewrote that section of display.c/dbuffer.c instead of > using the tried-and-true code? Why reinvent the wheel?! If there was > something lacking in lib5250, why not help improve it instead of replacing > it? I didn't rewrite it and x5250 uses that code unmodified by standard lib5250 calls. > I also see that you're using the GPL. The GPL is incompatible with > OpenSSL, so the rest of TN5250 uses the LGPL. If you use GPL, we won't be > able to distribute x5250 together with lib5250 -- just a warning. Hmm... I'll have to think about this. James Rich Vs lbh guvax bs argjbex frphevgl nf na vzzhar flfgrz, Jvaqbjf vf UVI. -- Wbr Cyhgn
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.