> ... So I would like to set these as defaults. Similarly, I always
> use 12 pt bold type for labels and I never ever want to have an object
> resizable. YMMD. So we need a ".fdesignrc" file or its equivalent.
I think a set of Resource Manager resources would be somewhat better
inasmuch as it fits with the X programming and user interface model.
> When I load a design from a directory, and then later choose "save" the
> expectation is that it saves back where it was retrieved from. No such
> luck; when I follow the above sequence the designer saves all the files
> back to my home directory. ...
I'm not sure I understand this.
If you start up fdesign in directory `foo' it will, by default, save
to that directory as far as I know. I've never had it do otherwise.
If you start fdesign with something like
fdesign src/graphics/some_project/project.fd
it will, by default, save everything in `src/graphics/some_project/'.
I just tested this and it seems to work correctly for me with 0.86.1
-- I haven't had a chance to install 0.87 on my home box yet.
Do you mean that if you start fdesign and use "Open" to open a .fd
file from some other directory, that it doesn't save things in that
other directory? I guess I could argue that the "Open" and "Save"
functions should probably be disjoint from one another -- I've worked
with programs where they track (for example Adobe Photoshop on the
Maggotbox) and I've found this behavior annoying and even disastrous.
> When using a "choice" object in the designer there is no apparent way to
> specify the text of the choices. That requires hard coding in the output
> file, and a repetition of the hard coding activity if the form is later
> modified using the designer.
I don't see this as a major problem -- or a problem at all, really,
but this could be just my own personal style. As I mentioned in an
earlier posting, most of my menus and choice objects are built more or
less dynamically, since they tend to be somewhat context sensitive. I
see no reason to repeat the hard coding in any case. Just put them in
the initialization code and forget about them. Unless you're
generating your *_main.c and *_cb.c files every time, you'll only need
to write them once. Even if you do, you could probably code up a
custom awk or perl script -- or even a C program with a bit of
yacc/bison and lex/flex -- to merge your additions as a part of the
make process. I've done similar things and it's generally pretty
easy.
> I would like to put all user written code in the foo_cb.c file and leave
> both foo.c and foo_main.c alone. However that requires a hook for
> initialization activities, some of which are xforms stuff, and some of
> which are database stuff not part of xforms. I can always recode
> foo_main.c, but I would prefer a "call back" type mechanism
> automatically embedded in foo_main.c by the designer. Then I could code
> these initialization routines without changing foo_main.c. The same goes
> for exit cleanup routines.
I generally build 99 percent of the user interface in one fell swoop,
output the *_cb.c and *_main.c code at the end of that session, and
then use these modules as bootstrap aids as I begin coding the real
guts of the program. I generally modify the start up code
considerably, anyhow, so an automagic code generator for *_main.c and
*_cb.c would be wasted -- at least for me. I suppose that fdesign
could be taught to keep a database of user supplied callback code but
that strikes me personally as significant Creature Feep. Having a
mechanism to include user provided code in fdesign probably means
having an text editor built in, among other things.
Basically, I use fdesign to generate my user interface specification
and that's about it.
> Finally a "grid" type object for displaying multiple columns of data in
> a single window would fit in nicely with data base applications.
That would be nice.
> Xform has the potential to become the "Delphi" of the X windows world. I
> like it much better than any of the interpetive approaches (e.g.
> tcl/tk). The code is written in c so there is not yet another foolish
> language (YAFL) to learn. But we do need some more flesh on the bones.
I don't know Delphi so I can't comment on it. However, I can say that
one of the things that attracted me to XForms above and beyond the
facility of rapid UI development with fdesign is the fact that it's
(relatively) light weight and dispenses with the (IMHO) complexity of
the Xt Widgets.
Of course, your mildew may vary...
spl
_________________________________________________
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/