|
Scott Klement wrote: > Hmmm.. not sure what you mean... I'm using the current sources from CVS! > lp5250d doesn't appear to utilize the "config stuff". > > Actually, I prefer it that way. Yeah, I can use the config stuff, and it > works... but I get the occasional weird crash with the "config stuff" > that I have yet to really trace down. > > I find using the new "config stuff" to be cumbersome, even when I'm not > getting crashes. It seems more complicated than the -s -t, etc style > command-line switches. (maybe thats just because I'm not used to it...) It is a bit cumbersome, I think so myself. I didn't really have a better way to accomplish the goals without either a) introducing a lot of additional maintenance or b) not having access to all the options from the command line or c) not having the system generic enough to be used in the Gnome 5250 emulator as well as the console 5250 emulator. BTW, I've resurrected some code from the first attempt at the Gnome 5250 emulator and have gotten it working again, and the config code was a life saver here. > Sure, its nice to be able to "save" my configuration options, but... a > simple shell script or even an alias does that nicely without this whole > complicated configuration mess. > > Please don't take this as negative criticism. I'm a big fan of your work > on this project, and I use this emulator every day. I guess the whole > config file option wasn't to my taste. It *IS* negative criticism, which is not in itself bad (at least you aren't flaming me ;-). I'm open to different/better ways of doing this. I particularly think it's cumbersome because of a few reasons: 1) +/- mean what they really should mean, not what they mean to every other program that accepts +/- (where they mean the opposite - I can't find any example right now.) 2) You can't really use GNU-style long options (--term=IBM-XXXX-X). 3) There is not checking for options which don't get used. These are all kind of related. The issue is that the configuration parser doesn't have any idea what options it should accept (meaning the command-line parser, that is not a big problem with the config file - or maybe it is?) The two possible options for resolution are: 1) Have each `object' (e.g. terminal, session, display, stream) register a table of options it will accept. I thought of this, and even started implementing it, but the drawback is that we couldn't have arbitrary environement strings (env.*); we'd have to decide explicity which ones to allow. 2) Pull the command-line parser out of the generic config code and re-implement it in tn5250.c. Every time we add an option which affects, say, the display, we make a note to implement that option in the command-line interface as well. It gets difficult if we end up doing things like dynamic-loading the front-end (as I've been considering doing so that I don't have to link Gnome-5250 with the curses library ;-) > On Thu, 4 May 2000, Jason M. Felice wrote: > > > ... or you could use the config stuff I wrote and not worry about it ;-) I > > never got around to documenting it, but it's pretty clean and > > straight-forward, if I remember correctly. > > > > -Jay 'Eraserhead' Felice (as he comes up for air briefly from a 60+ >hour/week ... and will shortly going back to said 60+ hour a week project, but am trying to get all of the useful and/or decent code merged before I do so that _someone_ can use it, poke it with a stick, what not. Unless there are any objections, particularly from Mike Madore, I'm going to pull Gnome 5250 into the tn5250 CVS tree so that changes won't get "lost." If it is still buggy (I cleaned it up a bit last night, have to test better), I'll have it disabled by default. That's one of three pieces of code I'm sitting on. The second was an `experimental' pure GTK+ interface that never really got off the ground. If I merge that with the Gnome support, I could have, basically, "Gnome support which still compiles without Gnome." This is good to resurrect the Windows port. The third piece of code is a contribution both Mike and I received which did a lot of Windows NT portability, and implemented a bunch of features which would allow the 5250 code to be used server-side instead of client-side. The server-side stuff was written to allow a third-party product (an AS/400 environment?) to serve 5250 connections... I'm not sure how far a jump it will be from the code in this patch to a tn5250d program/environment/API/whatever, but it is a _big_ step in that direction. I still hope to contribute to this project regularly, but I'd like to stop sitting on this code because I'm not going to be able to predict my free time for a bit, with no clue as to how long a "bit" is. -Jay 'Eraserhead' Felice +--- | This is the LINUX5250 Mailing List! | To submit a new message, send your mail to LINUX5250@midrange.com. | To subscribe to this list send email to LINUX5250-SUB@midrange.com. | To unsubscribe from this list send email to LINUX5250-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.