[EMAIL PROTECTED] (Linas Vepstas) writes: > > None of these are, IMHO, the hard part. The hard part is the your > > un-written #4 which is the state machine that walks users through the > > various screens to enter the various (necessary) information into the > > system. > > Arghh. In a previous email, you declared that its easy to define > a state machine with a simple config file. So I let that point drop. > Lets see if I can cook up an example:
I think I meant that it's simple to make it a config file (as opposed to hard-coding it).. At least I think (retroactively) that that's what I meant. I certainly never meant that I knew what that state machine should look like. ;) [state machine snipped] > Hopefully, the states, the arrows aka 'state transitions', and the > labels on the arrows are self-evident. > > Is it evident how to write C code that will parse this file, and > perform the correct transitions from one GUI window to another? > Think of this as a kind of fancy 'druid'. Mostly.. I'm very new to this GUI thing, and dynamic GUI is even further out of my normal purview. > At the bottom of each GUI window is a set of buttons and/or pulldown menus > that allow you to move to the next state. Some of these buttons are > greyed out or invisible, depending on who you logged in as. How do you dynamically add/remove buttons from the bottom of a dialog? Yea, I know -- probably GUI programming 101. I must've been sleeping that day (actually, I never even took the class ;) > If you follow my earlier example, than you don't even need to have the > GUI dialogs be hand-coded. They could be glade dialogs coupled to > confile-file-run-time object definitions. Make everything run-time. This works only so far as you can configure all your widgets in guile. You somehow still need to signify your 'extra' widgets that guile doesn't know about. To me it's still not quite straighforward how someone would write the code to implement a generic dialog like this. > > > Should we proceed to the next level of detail? > > > > Honestly I'm not 100% convinced something like this would work. I > > mean, sure, there is probably some way we could post-process a glade > > description file into a C file and compile it. But Ewww. > > No, you completely missed the point. No post-processing whatever. > Nothing is done at compile time. Its all done at run-time. > At gnucash-startup time, you read the config file. The config file > defines objects. You read the glade file. The glade file contains > widget definitions. You match, at run-time, widget names to > object field names. You draw the GUI with glade, and you use the > object definition to move data between GUI and engine and > storage. You still need the C code to attach widgets to data structures. Glade wont attach a GNCAmount or CurrencySelect widget for you; you have to do that yourself (in C, presumably). Similarly, when you are Editing an object you may want to grey-out some of the fields. To me it's not straightforward how this would be done dynamically. I guess, as you mention below, bonobo. But we currently don't depend on bonobo for anything (and Gnucash works fine without it). > That's why I was hoping to slow you down ... Oh. *silly-pouting-face* :) > Like I said, 'been there, done that'. I know of a better way, and > that's what interests me. If it's been done, then why doesn't it actually exist in the code? > > This is the flexibility that I don't know > > how to build. > > Stte machine. See above. > > > > Let me defer the storage/sql questions till later. > > > > Ok, but one thing to keep in mind: What is the point of modularization > > if there exists one module that must know about all the others? > > No, you miss another point. Let me paraphrase you: > > > If you look under the Extensions menu you'll see that I've already got > > widgets for Customer, Vendor, Employee, and Job. Sure, what I've got > > isn't all that extensible. I admit it. But the code is there, it's > > done, and it works. > > "If you look in the src/backend/extnsions directory, you'll see that > I've already got SQL tables defined for Customer, Vendor, Employee, and > Job. Sure, what I've got isn't all that extensible. I admit it. > But the code is almost there, its not hard to write, its > straight-ahead". > > And, for me, tedious and boring. You can create the sql backend for > your new stuff, it might take you a few weeks, maybe less, maybe more. > Theres nothing technically challenging about it. Its just tedious. Sure, it's tedious and boring, but at some level it still needs to be done, no? > I know how to go to the next level. With the right tools, one could > create everything you are creating, in about *one day*. Not weeks > or months but ONE DAY. The GUI, the backend, the reports, the graphs > (we haven't even talked about report generation or graphs!) What "right tools"? Do these tools exist? If so, why aren't we already using them? If not, well, that's why I didn't use them ;) -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel