Config & Gnome (Was Re: Working lp5250d...)

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
+---