Thomas Adam <tho...@fvwm.org> writes: > On Wed, Aug 12, 2020 at 07:25:36PM -0400, Dan Espen wrote: >> A few years ago I spent a couple of days trying to make FvwmForm and >> FvwmScript use shared code to create their widgets. Unfortunately, >> the French comments in FvwmScript defeated my attempts to understand >> what goes on in FvwmScript. > > That's interesting. Do you still have your attempts anywhere? I'm sure we > could find some someone to help translate the comments. I agree -- it's > difficult to follow along.
No, I never made any changes, as I said I just couldn't understand what the code was doing. FvwmScript was impossible for me to follow, but I was able to make substantial improvements to FvwmForm. 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. > This approach of unifying FvwmForm and FvwmScript would be interesting > beginnings to also merging in FvwmButtons to really create some sort of > ludicrous hybrid that could be really flexible. That'll need thinking > through, but I appreciate that wasn't your intent. Yeah, my intent was to have common widgets between them. I thought I could get FvwmForm to look as good as FvwmScript. 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 wanted to do the widgets first. >> In my opinion, FvwmForm does all it's layout correctly, working off >> the fonts it's using. Plus it has a GUI to configure the fonts it >> uses so you don't have to mess with a config file. >> >> So, since you dropped FvwmForm in fvwm3 did you add an FvwmScript >> dialog to configure FvwmAnimate? > > It was always going to be a tough call. At the time, in conversation with > people the prevailing opinion was that FvwmScript was being used more heavily > because it had a lot of feature that FvwmForm did not. I know the overlap > between the two isn't 100%. > > I haven't yet moved the FvwmForm dialogue across to FvwmScript, but I'm aware > it needs to be done. Okay, at least you know something is missing. > 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. 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. 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. -- Dan Espen
