On Thu, Aug 13, 2020 at 09:02:09PM -0400, Dan Espen wrote: > 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.
Hehe. It's an interesting idea and one which probably still survives to this day. For instance, QT still uses XML to describe layout of widgets -- or it did. But the fact remains that the idea of using text to describe graphical forms is cool. It's a little bit like Perl's now deprecated format specifier, and Oracle DB used to have ways of formatting output to look like forms as well. > 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. Hehe -- thankfully I wasn't using that video as anything instructional, otherwise I'd have been up a creek without a paddle. By the way, I made an assumption that ISPF was somehow old and not used much. But it turns out it's still got a strong following and still maintained by IBM. So where would this typically get used? I can imagine its use for things like help desks and bespoke processes where panels could be rolled out to people for liaising with customers... Mind you, with things like Zendesk and other HTML-based efforts, I can see ISPF being less attractive unless it was already there. > Third, there's zero reasons to write REXX for a menu, the panel itself > can do the entire job. Yeah. I was wondering that. I've used REXX once... I rather liked it, but I wasn't sure it was applicable to what the chap in the video was attempting to do. > 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. I'm going to dig a bit deeper in to this, Dan as I find it all rather interesting. I'll probably chat to you off-list as I'm sure others reading this are probably wondering if FvwmForms is going to become some sort of ISPF emulator (no, it's not! ;)). Incidentally, I did find this (as someone's pet project): https://github.com/daniel64/lspf There's definitely a lot of folks around who are interested in this. Cool. > 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. Yes, I bet you did! > 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. Given the length of their beards, I can only presume that's proportional to their hatred? :) I can understand how some dyed-in-the-wool C chaps being forced to use ISPF wouldn't like it -- and that's just me surmising with ~10 minutes worth of video watching. :) But these panels are a God sent. > I never used Rational Rose. Neither did I in the end. Think we both dodged a bullet there. > 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. Well, even mockups might be useful further down the road. > > 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. Yeah, well, sometimes it's not just about the SLOC. In digging around what FvwmScript offers, and what FvwmForm was doing, I can perhaps understand why we have two similar modules. But the more I look at FvwmScript the more I can see just how similar it is to what FvwmForm does, and that FvwmScript doesn't provide the flexibility that FvwmForm does in how it approaches the text <-> layout point. It's much more explicit/error prone in FvwmScript. I think I'll start in getting some sort of widget parity between FvwmScript and FvwmForm. I probably won't ever end up writing anything to convert FvwmScript configs to FvwmForm -- that's much harder. Not least of which because FvwmScript's config parsing is wholly written in YACC. Then I can look at tables. > By the way, I think you've been doing some impressive work. Cheers! > 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. I never wanted to be a computer programmer. I had my heart set on geochemistry. Turning my hobby (programming) in to my career though hasn't been so bad. But since I do much more management day-to-day than programming now, it does mean I've started to enjoy programming in my spare time now more than I used to. I suppose that's the difference -- you just need to indulge in something else before the bug returns... Whenever that is for you, Dan, let me know. I could use the help! :) Same goes for anyone thinking they don't know C or can't help out. I'd much rather mentor someone than not have them contribute -- as any help is better than nothing, -- Thomas
