Thomas Adam <tho...@fvwm.org> 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
