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. > 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. > 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. > 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'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! Kindly, Thomas
