[EMAIL PROTECTED] writes:
> It's not clear to me that it is necessary to do the "commits" when
> doing this stuff en mase; I'll see how that goes.
If you're talkinga about the begin/end edit stuff, it might be useful
to defer gui updates (presuming it does).
> As far as I can tell, there's not a separate thread of execution;
> once my Guile code gets running, it appears to have control over the
> whole system until it's done. (The keyboard and widgets "block")
We only have one real "thread" of execution, so interrupts are the
only thing I think you might have to worry about.
Guile does take over, but then hands control right back to gtk_main
via gnc:lowlev-app-main. After that, the only guile code that gets
called until that function returns is code called from callbacks, etc.
> That goes to say that all the locking that is likely necessary is
> already in place.
I think so. Things are *so* much easier when you don't have to deal
with threads. I do that all the time my other work, and it can get
complicated fast, though threads do make some things a lot easier.
> It *appears* that invoking a Guile function is an atomic operation
> from the perspective of the GUI; that's pretty adequate to keep this
> safe.
I think so. Off the top of my head, unless you let gtk get a chance
to handle an event (by returning from a callback, or by calling
gtk_main_iteration or something), it can't do anything until the
current callback returns.
> What I need is some way of getting that as input from some other
> source. Right now, it's being "hacked" manually in Scheme which
> is not a deployable answer.
Ask and ye shall receive. The scheme side list-query-dialog is alive.
I'll send a patch in a day or two when I get a chance to clean it up.
As a teaser:
(new-function 'gnc:choose-item-from-list-dialog
'tSCM
"gnc_choose_item_from_list_dialog" '((const-string title)
(tSCM items))
"Display a dialog with a cancel button, allowing the
user to select an item from a list. The items parameter should be a
list of pairs of the form (name . thunk). The thunk will be called
with no arguments when the user clicks the item associated with name.
If the thunk returns a non #f value, then that value will be returned
as the result of this function in a pair of the form (cons 'result
value). This function may also return 'cancel if the user clicks
cancel, or a raw #f if there's an unrecoverable error.")
I think I also need to add a parameter that allows you to put some
text at the top of the list for a request like "Please select the
right account:"
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
