Re: FVWM: FVWM on a high density screen -> FvwmForm
On Sun, Aug 16, 2020 at 08:39:08AM -0400, Dan Espen wrote: ... > ISPF edit. > I don't remember XEDIT well (1978), but I think the 2 editors are very close. not really (aside from running on the same hardware). for your amusement https://invisible-island.net/personal/oldprogs.html#y1982 -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: FVWM: FVWM on a high density screen -> FvwmForm
Lucio Chiappetti writes: > On Sat, 15 Aug 2020, Dan Espen wrote: >> Lucio Chiappetti writes: > >>> Yes, it's called Regina, and is required if one wants to use THE (The >>> Hessling Editor) as editor, which is a very good Unix clone of the IBM >>> VM/CMS XEDIT editor. > >> I remember XEDIT, from a shop that was using CMS for a while. >> I started it up and it looked like hell. >> Most distracting was a column scale right across the middle of the >> screen. Fortunately, I didn't run away and hide. > > (SET) SCALE OFF (better if in one's profile) > > the scale is generally annoying, but can be useful if one is editing > a very wide file and wants to limit visibility and/or editing to > columns n-m (SET VERIFY n m) ... what other editors off the possibility > to limit editing to columns or sets of lines with or without a given > pattern or to select and remove entire columns ? ISPF edit. I don't remember XEDIT well (1978), but I think the 2 editors are very close. I never fooled with any of the ISPF like editors for Windows but I suppose SPFLite would do the job well. Of course it's well known that it's impossible to name an edit feature that Emacs doesn't have. :) I can't remember if I moved the scale or just turned it off. Speaking of scales, I remember when I started using an early version of Emacs on an HP terminal. The HP terminal had a pretty extensive line drawing character set. I set up a scale that looked exactly like a ruler across the top of the screen. numbers, line graduations, and a box around the whole thing. That was to be able to edit MVS Assembler and be able to see col 10, 16, 72. >> I gave it another try and found all the hooks and toggles to customize >> it to my liking > > Yes, it is in my list of favourite easily user-customizable s/w (like > THE, fvwm, alpine ...) Ah, another Fvwm fan. I think it's interesting that the appearance of my Fvwm desktop hasn't changed since I submitted my original screen shot in 2003: https://www.fvwm.org/Archive/Screenshots/2003-08-28_Dan-desk-1280x1024/screenshot.gif Well, I narrowed down the borders and tiled the menus with that blue pixmap on the borders. Other than that, I do not have to suffer with my desktop changing based on the disto's whims of the month. -- Dan Espen
Re: FVWM: FVWM on a high density screen -> FvwmForm
On Sat, 15 Aug 2020, Dan Espen wrote: Lucio Chiappetti writes: Yes, it's called Regina, and is required if one wants to use THE (The Hessling Editor) as editor, which is a very good Unix clone of the IBM VM/CMS XEDIT editor. I remember XEDIT, from a shop that was using CMS for a while. I started it up and it looked like hell. Most distracting was a column scale right across the middle of the screen. Fortunately, I didn't run away and hide. (SET) SCALE OFF (better if in one's profile) the scale is generally annoying, but can be useful if one is editing a very wide file and wants to limit visibility and/or editing to columns n-m (SET VERIFY n m) ... what other editors off the possibility to limit editing to columns or sets of lines with or without a given pattern or to select and remove entire columns ? I gave it another try and found all the hooks and toggles to customize it to my liking Yes, it is in my list of favourite easily user-customizable s/w (like THE, fvwm, alpine ...)
Re: FVWM: FVWM on a high density screen -> FvwmForm
Lucio Chiappetti writes: > On Fri, 14 Aug 2020, Dan Espen wrote: > >> Yep, there is a Unix version of REXX and it's a reasonably good >> scripting language. > > Yes, it's called Regina, and is required if one wants to use THE (The > Hessling Editor) as editor, which is a very good Unix clone of the IBM > VM/CMS XEDIT editor. Heard of it, but I've seen even more references to oorexx. I remember XEDIT, from a shop that was using CMS for a while. I started it up and it looked like hell. Most distracting was a column scale right across the middle of the screen. Fortunately, I didn't run away and hide. I gave it another try and found all the hooks and toggles to customize it to my liking and it ended up being pretty decent for a editor running on a block mode terminal. > Back when using IBMs I never got proficient with REXX (I was > accustomed to EXEC2, and we abandoned mainframes quite early). Just > the bit enough to maintain my THE macros > http://sax.iasf-milano.inaf.it/~lucio/WWW/Opinions/myxedit.html I started with CLIST (part of TSO) with MVS. I got quite proficient but I kept hearing about how great this new REXX thing was, and of course, REXX was the future as far as IBM was concerned. So, I got quite proficient with REXX too. I converted lots of my stuff to REXX, but there is a CLIST capability that REXX is incapable of. I wrote some CLISTS that acted as both TSO commands and Edit Macros. I forget the exact command, but an Edit Macro MUST issue a command early in it's execution to declare itself as an edit macro... Okay, it's the command ISREDIT. The command is invalid in a CLIST but required in an edit macro. You can't test if you are an edit macro because you are not an edit macro until you issue ISREDIT. So, I wrote a TSO command named ISREDIT and had it issue a return code that ISREDIT as an edit macro doesn't. That way the CLIST could tell from the return code whether it had been invoked as a TSO command or an edit macro. I'm not sure if any of this would apply to EXEC2. I wrote EXECs but just for a short while. In case you are wondering, there are very good reasons for commands to act differently when they are an edit macro versus a command. I had an edit macro "P" for invoking a print utility. As a command you want it to bring up a panel and the panel should default to printing the previous dataset it printed. But when you an edit macro you want it to default to printing the dataset you are editing, and you want to issue an edit SAVE before you launch the print. The same reasoning applied to dozens of CLISTS that I had. So, CLISTS lived on for me. -- Dan Espen
Re: FVWM: FVWM on a high density screen -> FvwmForm
On Fri, 14 Aug 2020, Dan Espen wrote: Yep, there is a Unix version of REXX and it's a reasonably good scripting language. Yes, it's called Regina, and is required if one wants to use THE (The Hessling Editor) as editor, which is a very good Unix clone of the IBM VM/CMS XEDIT editor. Back when using IBMs I never got proficient with REXX (I was accustomed to EXEC2, and we abandoned mainframes quite early). Just the bit enough to maintain my THE macros http://sax.iasf-milano.inaf.it/~lucio/WWW/Opinions/myxedit.html
Re: FVWM: FVWM on a high density screen -> FvwmForm
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
Re: FVWM: FVWM on a high density screen -> FvwmForm
Thomas Adam 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
Re: FVWM: FVWM on a high density screen -> FvwmForm
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! > 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? > 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. > 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. > 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 Kindly, Thomas
Re: FVWM: FVWM on a high density screen -> FvwmForm
Thomas Adam writes: > On Wed, Aug 12, 2020 at 07:58:59PM -0400, Dan Espen wrote: >> We had a French developer working with us for many years. >> Right now I can't recall his name, I used to fix up all the >> documentation he wrote. He offered to fix up the comments but >> never got around to it. > > Olivier Chapuis, most likely? Really clever chap. Ended up going on to form > Metisse, as I recall. Yep, that's him. >> I also had a plan to add boxes to FvwmForm. The idea being >> you'd put fields in lines, lines in boxes, then boxes in the form. >> Relief lines around the boxes would be optional. >> Just an idea, I never started that. > > I think that's a nice visual que, and the same could be applied to creating > tables as well. > >> I wanted to do the widgets first. > > This is definitely an area where FvwmScript has the upperhand, although I > admit I've never looked too deeply at how FvwmScript implements the widgets it > offers. > >> Okay, at least you know something is missing. > > One of many things. :) > >> > If you have a list of things which could be moved in to FvwmScript from >> > FvwmForm, I'd be interested in seeing that. One of the things I liked >> > about >> > FvwmForm (I did used to use it, BTW) was it could be told to grab the >> > XServer. >> > So I wrote a FvwmForm instance to do just that in StartFunction to go in to >> > Work or Home mode, which would open certain applications, etc. Although I >> > don't have a need for that now, the ability to grab the XServer would >> > still be >> > useful. >> >> Not sure I understand. > > I was referring to FvwmForm's "GrabServer" option. I used to make use of that > a lot in the FvwmForms I used to use. Ah, slipped my memory. >> If you look at the comments I left in FvwmForm, I had some idea about >> it sitting around as a form display server to make it even faster. >> >> I'm not sure about FvwmScript but I don't think it has the same capability >> to save and reuse what you last entered as FvwmForm does. > > Oh, almost certainly not. Well, then it's really inferior to FvwmForm then. At least for the uses I was putting it to. If you want to manage data with a form, you need to be able to read it and save it. >> Since we are blue skying here, I also had an idea that you could use >> FvwmForm to design new FvwmForms. It would need the ability to display >> tables. > > Could you expand on this a bit? 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. 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. 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. ISPF itself handles things like scrolling the data if the data is bigger than the display area. So, that's the table part. 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. You might be able to see where I thought I needed boxes too. > I'm happy to bring FvwmForm back (to Fvwm3) if the overlap with FvwmScript is > to minimal. But I'd like to still explore in which direction an amalgamation > between FvwmScript <-> FvwmForm should go. If I've overlooked this in the > wrong direction with how things are now, I'm happy to stand corrected! 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. > Kindly, > Thomas A pleasure. -- Dan Espen
