Business Processes

[Linas Vepstas]

On Sun, Nov 25, 2001 at 06:56:07PM -0500, Derek Atkins was heard to remark:
> Mostly..  I'm very new to this GUI thing, and dynamic GUI is even
> further out of my normal purview.

Its easier, actually.  First, write a traditional hello-world 
with two buttons.  Be sure to hook up the buttons to C routines 
that do something. Use gtk_signal_connect() to do this.

Next, design two buttons with glade.  Now, all you have to is 
call glade_xml_new("/some/path/to/glade/file")  and then you
call glade_xml_get_widget ("name that you gave to some widget");
Then you use gtk_signal_connect() same as before.

The point being that you can give any widget any name you want,
and then ge a pointer to it simply by asking for it by name.

> > 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.  

Yes it is ... I'm going to pass on this one. 

> > 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 mean 'glade', not 'guile', right ?

> You somehow still need to signify your 'extra' widgets that guile
> doesn't know about.  

There are ways of dealing with this.  It doesn't hurt to ignore this 
issue for now.

> To me it's still not quite straighforward how
> someone would write the code to implement a generic dialog like this.

I'm not sure of which part of 'like this' you refer to.  
However, keep this in mind:

A GUI dialog is just a tree heirarchy of widgets.  Leaf nodes can be
almost any widget.  Interior nodes must be 'containers' that can hold
other widgets.  Each node is a widget of some type (e.g. 'button', 
'text box').

In glade, you can assign any name you want to any given node.  
You can then ask for that widget by name.  You can then tell the
widget to display itself.

> 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).  

Yes, exactly. But when you read the config file, you read four strings:
one string was "currency".  So your c code creates a "currency"
object.  The second string was "MyWhacked_CurrencyEditor".  You
ask glade create an instance of "MyWhacked_CurrencyEditor", and to
give you a handle to it.  This is a handle to your dialog window.
It will not display on the screen until you tell it to display;
it lies dormant.

The third string in your config file is "MyWhacked_TextEntryWidget";
its a part of the dialog, its a box for inputting text. You ask glade
for a handle to this too.  The fourth string is "entry", which tells
you that the the handle you have is in fact a handle to a GtkEntry
widget.  That means that your C code can now call 

gtk_entry_set_text ((GtkEntry *) handle, gnc_currency_get_value (currency));

and of course:

gnc_currency_set_value (gtk_entry_get_text ((GtkEntry *) handle));

i.e.  the first string was converted to a C struct by a big case
statement that knows about every possible  object in gnucash.
The fourth string was converted to a C struct by a big case statement
that knows about many gtk input and display widgets.

Well, its not a case statement, its a 

if (!safe_strcmp(val, "currency"))  { 
    GNCCurrency *currency = gnc_currency_new();
    ...  
}
else if (!safe_strcmp(val, ...)) { ...}

> > 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?

Rather, "I've been there, done that, the old-fashioned way, and now,
I am ready for the new way".  Its not in gnucash yet, becasue I haven't
started scratching that itch.   


> > "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?

No.  I want to write a tool that will do the SQL automatically for me.
I won't have to deal with hand-coded sql ever again.


> > 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?  

Yes, there are many commercial tools that do this.

> If so, why aren't
> we already using them?  

They're commerical.  And the open-source analogs are half-baked.

> If not, well, that's why I didn't use
> them ;)

I didn't say you should use them.  I said "lets create a mini-tool
of this kind for our own use."   The module system is a part of it.
The extensibility framework you're creating is a part of it.  The 
configurable ledger is another part of it.   The state machine 
would be a fourth part.  And the specify-objects-in-config-files 
would be a fifth part.

We are already going down the path of creating our own home-grown
configurability framework.   I don't think we should stop.

We have to do this home-grown, because no other framework is 
gpl'ed and ready-to-use and is powerful enough (and isn't insanely
compliated).

By doing this, we will learn, the hard way, the ins & outs of 
building configurable frameworks.  And by then, we'll be able 
to start  arguing the meta-meta issues.

--linas


-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933