Thomas Adam <tho...@fvwm.org> writes: > On Thu, Aug 13, 2020 at 05:44:10PM -0400, Dan Espen wrote: >> I had a lot of experience with IBM ISPF panels. >> I wanted to model FvwmForm along those lines. >> That's were the data reading and saving came from. > > That's amazing! I really don't know anything about IBM's early software. The > closest I ever got was Rational Rose, back when RUP was popular (early 2000s i > when I was exposed to that at University). Needless to say I've not been > involved with any commercial companies which have used IBM. > > I've just watched a Youtube video which highlighted ISPF Panels. I can now > really appreciate why you were going down that route. What a lot of fun!
Yes, it actually was a lot of fun. But that presentation was painful to watch. First, DTL is crap, you really want to use ISPF as it was originally designed. You create a text image of the screen using punctuation to mark input and output fields. Second, he says you have to restart ISPF to be able to access your changes. But that start command he was issuing does not restart ISPF and he showed himself going to option 7. Once you go to option 7 you no longer have to exit ISPF to be able to use your panel changes. Option 7 puts ISPF in test mode. Any competent ISPF developer would be starting ISPF in test mode anyway. (Test mode just makes ISPF always read the panel definitions instead of using a cached copy.) At work I had a base of about 300 users. I put them all in test mode because I liked to make changes all during the day. Third, there's zero reasons to write REXX for a menu, the panel itself can do the entire job. There's no reason to compile panels. I did tests, you just give ISPF the source and it displays panels fine and just as fast as the compiled panels. On and on. I could probably create a list of 50 things that guy wasn't doing right. I hope you got a feel for it. He showed the TBADD function followed by TBDISP that's the gist of it. You can do all your data verification right in the panel. TBADD is just like creating an array in a unix shell. So you build up an array then in the panel your name for the array. The panel figures out how big the array is and displays as many occurances as it can fit on the screen. A lot of the tables you saw being displayed as he was working are the development panels from IBM. They're totally uninspired, I had a lot of fun creating replacements. I once ran a help desk for a large herd of UNIX C programmers forced into working with ISPF. They pretty much hated the environment. I unleashed a bunch of panels I had written on them and they were converted on the spot. I never used Rational Rose. >> For tables, ISPF lets you say something like here is a line but the line is >> a model >> for a table. So, when you design an ISPF table it's a lot like >> FvwmForm's LINE. You put a bunch of fields on a line with the >> understanding that the data determines how many times the line is >> repeated when displayed. > > Right -- I think I understand this. I'm basing a lot of this from this video: > > https://www.youtube.com/watch?v=eA3rvZwU7e8 > > Is this what you're referring to, Dan? Yep. I wish I could show you some of the stuff I did, but of course that belonged to my employers so I left it behind. >> With FvwmForm, you'd say, here is a line that should be displayed in >> a box 10 lines high. So, for example, with FvwmForm's implementation >> of FvwmTalk, where it shows the last error line, instead you'd say >> I want to show up to the last 10 error lines. > > OK. > >> ISPF itself handles things like scrolling the data if the data is >> bigger than the display area. >> >> So, that's the table part. > > It's really interesting. Just on the mentioned video above, the style looks > similar to a lot of terminal libraries which golang has (one such example > would be: https://github.com/gizak/termui). I appreciate we're talking about > X11 here, but it's still not to see that in 2020, people are becoming more > invested in the terminal and CLIs than they perhaps used to. termui might be close. If you've done table views with QT or tables in GTK they are similar too. >> I had the idea that FvwmForm could display a table of lines, >> let you add or delete lines, or select a line. >> When you select a line you'd see another table of the fields >> on the line. > > I really like this idea. I wonder though how heavy this would be on window > resize? It might flicker through redraws if we're not careful. Well, I did have a plan to make FvwmForm persistent so you wouldn't be reloading the module for every redraw. >> Glad to hear it. >> Fvwm is still pretty far from being able to configure itself. >> I did some work along those lines with FvwmAnimate and FvwmForm-Form >> but didn't get far enough. > > Well, it's back: > > https://github.com/fvwmorg/fvwm3/commit/6e65b85d127de9b18022c8073974c2f3745b14a1 Good, I think you made the right choice and it should save you some work anyway even if the source code base is a bit larger. By the way, I think you've been doing some impressive work. I don't know if I'm slowing down due to age or what, but I'm finding it increasingly hard to do any coding. I've been working out and doing lots of physical work on the house and in the yard. Maybe I'm just reveling in not having to do coding any more. -- Dan Espen
