> > fdesign is a bit of a nuisance in the way it requires app specific run-string
> > arguments with no alternative way to set them through the GUI. ...
> To subscribers of the xforms list from spl@szechuan.ucsd.edu (Steve Lamont) :
> I find typing
>
> fdesign foo
>
> -- or in my case
>
> fdesign -nocode foo
> To subscribers of the xforms list from "Brian E. Gallew" <geek+@CMU.EDU> :
> Uhm, only if you're *truly* lazy, or have a window manager which is damaged
> beyond all hope.
It's curious to me that some app GUI designers insist on retaining run-string
control. I guess it's a unix mindset.
Personally I don't see what's such a big deal with a File/New menu option.
Some may think it's revolutionary but it has been seen on one or two programs
before now. And far from detracting from the simplicity of fdesign I think it
would enhance it.
I would also like an include file reference to be GUI settable and associated
with (saved in) the .fd file. This would be similar in effect to the -I
option but more versatile.
I know spl and others use a single .fd file for all forms in their interface
and do not see the need for these enhancements but theirs is not the only way
to organise a GUI design. Personally I prefer one .fd file per form.
Amongst other things this means I can design forms which can be used in more
than one application. The mentioned minor enhancements would thus be very
helpful.
Dick
--dick@sqf.hp.com
_________________________________________________ To unsubscribe, send the message "unsubscribe" to xforms-request@bob.usuf2.usuhs.mil or see http://bob.usuf2.usuhs.mil/mailserv/xforms.html Xforms Home Page: http://bragg.phys.uwm.edu/xforms List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/