patches
Just a quick note to everyone who has submitted a patch since Friday. I haven't been ignoring them -- I've been out of town. It's going to take me a while to get through all the mail that's been on the list, but rest assured I *will* get to your patch. thanks, dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: help on disabling preferences widgets
Robert Graham Merkel writes:
Kevin Finn writes:
I can take a stab at it - I'm interested in picking up more Gtk+. Do
es it
make more sense for each option to provide access functions that other opt
ions
can use to enable/disable it, or perhaps just have those other options
disable the affected option "by name" ("Section" + "Option name", etc.)?
Access functions would be better encapsulation, but on the other hand it
would be a lot of overhead to provide that ability for every prefs option
that
exists, since enabling/disabling won't be needed for 95% of the prefs. I'
m
thinking of something like:
gnc_set_option_selectable( "General",
"Auto Decimal Point Range",
GNC_F );
in the spirit of gnc_lookup_boolean_option. What really gets changed is t
he
"sensitive" property of the widget that is connected to "Automatic Decimal
Point".
I think disabling by name would be sufficient - it is consistent with
the rest of the options interface.
Disabling by name would be just fine. Keep in mind, though, that disabling
would most often be done in scheme, or at least the information that one
option's sensitivity depends on another option's value should be stored
in the scheme option structure. The option GUI code should not know the
'meaning' of the options -- it just implements the GUI.
Given that this capability isn't needed for most options, I think it
would be easiest to implement this using the 'setter' function of the
boolean option object. I anticipated that boolean options might need
to be more sophisticated than they are now, which is why I called the
current boolean option constructor a 'simple-boolean-option' in the
scheme code. So, I would suggest defining another boolean option
constructor which allows you to specify a callback to be invoked when
the option changes its value, and then use that callback to
disable/enable the other option as appropriate.
Kevin, would you like to work on this? It would be mostly scheme work.
As you point out, changing the sensitivity of a widget is just one
gtk+ call.
Which brings me to another point - if we make options mutable, should
it be an error if we try to read a muted option's value? If an
option is disabled, the option's value is not relevant to
the current state of gnucash, and code should not be trying to read
that value. I think, therefore, that it should be an error and
signalled as such.
I consider an option being editable in the GUI and an option's value
being irrelevant to be independent concepts, so I don't think this
situation should necessarily be an error.
dave
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
suse rpm
someone promised a sus rpm is it avail? -- Rolando Roman icq 3783184 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Account-level meta-information
Robert Graham Merkel writes: In response to the mail that's being going back and forth WRT reports, it has occurred to me that we really need some account-level meta-information beyond the fixed fields and text notes we already have. Bill Gribble is working on this very thing. Accounts, Transactions, and Splits will have a set of key-value pairs which will be used in the future instead of adding new fixed fields. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
On Fri, Jun 30, 2000 at 01:39:07PM -0500, Bill Gribble wrote: Clark Jones [EMAIL PROTECTED] writes: in stockmarket quotations, e.g., nonsense like "73 213/256". However, the SEC has told the U.S. stock markets "thou shalt decimalize", and though Partially true, but stock prices are an important part of gnucash, and while the US stock exchange is going decimal "pretty soon", there are historical prices which will always be in 64ths and the bond market is not likely to decimalize any time soon (according to Jon Trowbridge, who does this stuff for a living; is that a correct interpretation of your mail to me?). Yes. There are also lots of other examples from futures markets, which are a wonderful source of pricing perversity. For example, 10yr and 30yr US Govt Bonds trade in 32nds, and 5yr Bonds trade in 64ths. Soybeans futures (as well as Corn, Oats and Wheat) are quoted in 1/8th of a cent per bushel. These are all powers of two. Powers of two can all be represented exactly in decmal. The converse fails: poers of ten cannot always be exactly represented in binary. -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
Well, floating point is definitely NOT the proper solution for US dollars (or any other currency of which I am aware -- anybody know a currency still in use that isn't decimal? The UK abandoned the "shillings pence" in the '60's). I believe some former British colonies still use pounds, shillings, and pence. -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: suse rpm
Rolando Roman wrote: someone promised a sus rpm is it avail? There's a suse rpm on the gnucash ftp site, but AFAIK we're still ironing out a couple of dependencies. I'm running suse 6.4, and have a missing 'g-wrap'. Folks running 6.3 seem to have others. I am using Gnome with Enlightenment as my desktop, so some of the problems don't seem to affect me. Many folks are travelling this week so it may be a few days before this gets ironed out. Note that I am running 1.2.5 (as I recall - the last in the 1.2 series) quite successfully, installed from RPM. Upgrading later is evidently not a problem, so if you're just starting out this might be a good way to get going. GB -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Zeroing account balances
What's the proper way in gnucash to zero account balances? Like at end-of-year, when you want to start over gross income at zero, and income/expense categories... -- Matthew Vanecek Visit my Website at http://mysite.directlink.net/linuxguy For answers type: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' * For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something... -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: suse rpm
this rpm for suse is worst then the standard one i get more failures root@Ptorico:/home/landy rpm -Uvh gnucash-1.4.1-1.i386.rpm error: failed dependencies: eperl is needed by gnucash-1.4.1-1 nana is needed by gnucash-1.4.1-1 swig is needed by gnucash-1.4.1-1 xmhtml is needed by gnucash-1.4.1-1 xmhtmld is needed by gnucash-1.4.1-1 gettext is needed by gnucash-1.4.1-1 libxmld is needed by gnucash-1.4.1-1 gnlibsd is needed by gnucash-1.4.1-1 scheme is needed by gnucash-1.4.1-1 g-wrap is needed by gnucash-1.4.1-1 root@Ptorico:/home/landy On Tue, 04 Jul 2000, Gary Bickford wrote: Rolando Roman wrote: someone promised a sus rpm is it avail? There's a suse rpm on the gnucash ftp site, but AFAIK we're still ironing out a couple of dependencies. I'm running suse 6.4, and have a missing 'g-wrap'. Folks running 6.3 seem to have others. I am using Gnome with Enlightenment as my desktop, so some of the problems don't seem to affect me. Many folks are travelling this week so it may be a few days before this gets ironed out. Note that I am running 1.2.5 (as I recall - the last in the 1.2 series) quite successfully, installed from RPM. Upgrading later is evidently not a problem, so if you're just starting out this might be a good way to get going. GB -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED] -- Rolando Roman icq 3783184 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Plotting...
Matt Martin [EMAIL PROTECTED] writes: So what I'm wondering is: are there plans for integrating something more sophisticated (and hopefully interactive) than gnuplot ? Way back somebody proposed a framework for interactive graphics or similar. Yep. We've been working closely with Jon Trowbridge (of guppi) to integrate things. We'll have interactive callbacks, etc. From what I've seen he's been doing outstanding work. I would imagine that this kind of stuff would have to be compiled as guile would be too slow for graphical callbacks, no ? Actually, guile is far more than fast enough for this kind of thing. If you think about it, calling a callback is a very cheap operation. As long as we're not trying to do something like render an image from guile (pixel-by-pixel or something), we should be fine. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Problem with Make
Robert Graham Merkel [EMAIL PROTECTED] writes: I'm afraid your gcc setup is broken. Until you get that sorted out, you won't be able to compile gnucash. Sorry! Do you know if this problem was ever resolved? The problem seemed to be with alloca being undefined, and after I poked around in the gcc man pages for a bit, it seems that alloca is undefined (or at least must come from a lib) if -ansi is used: The functions `alloca', `abort', `exit', and `_exit' are not builtin functions when `-ansi' is used. So I think the problem should go away if -ansi is just removed from the options. I belive Dave has killed off --enable-warnings in the latest CVS, so that should fix the problem. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: help on disabling preferences widgets
On Tue, 04 Jul 2000, Dave Peticolas wrote: Robert Graham Merkel writes: Kevin Finn writes: [...] Disabling by name would be just fine. Keep in mind, though, that disabling would most often be done in scheme, or at least the information that one option's sensitivity depends on another option's value should be stored in the scheme option structure. The option GUI code should not know the 'meaning' of the options -- it just implements the GUI. That makes sense. I wasn't entirely clear on the distinction between the responsibilities of the scheme and the top-level.c code, but that clears it up. Given that this capability isn't needed for most options, I think it would be easiest to implement this using the 'setter' function of the boolean option object. I anticipated that boolean options might need to be more sophisticated than they are now, which is why I called the current boolean option constructor a 'simple-boolean-option' in the scheme code. So, I would suggest defining another boolean option constructor which allows you to specify a callback to be invoked when the option changes its value, and then use that callback to disable/enable the other option as appropriate. I don't know if you'd seen the other mail that I sent yesterday, I had sort-of worked around to the idea of a callback as well. Having a separate complex-boolean-option makes the whole thing a lot cleaner. Kevin, would you like to work on this? It would be mostly scheme work. As you point out, changing the sensitivity of a widget is just one gtk+ call. Sure, I'll take a look at it over the next few days. Which brings me to another point - if we make options mutable, should it be an error if we try to read a muted option's value? If an option is disabled, the option's value is not relevant to the current state of gnucash, and code should not be trying to read that value. I think, therefore, that it should be an error and signalled as such. I consider an option being editable in the GUI and an option's value being irrelevant to be independent concepts, so I don't think this situation should necessarily be an error. So the callback from when the boolean is changed might need to change the value of the no-longer-editable option to a "safe" value? What about the case where we make an option non-editable due to something besides another option, for example we disable an option if the account balance is zero or something like that. Since there's no boolean option to check for whether our non-editable option is editable or not, do we need to provide a way to query the editable status of the option? Can we query the Gtk+ "sensitive" status of a widget, or do we have to store that state? Kevin Finn [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Account-level meta-information
Robert Graham Merkel [EMAIL PROTECTED] writes: Can we put this discussion on hold somewhat until the rest of the developers get back from holiday? I think we've posed some concrete problems, which have led to some rather interesting suggestions improving the engine.. However, I believe some work has been going on in this area and I'm sure that Dave and Rob will have quite a bit to say on this. Well, we had been planning, and I think Bill's been working on, adding a frame/slot, key/value pair, hash-table, whatever you prefer to call it to several of our basic data types. This is to be used to record whatever meta-level information we need for a given object. In fact, the plan is to have two hashes in each relevant data structure, one reserved hash-table, for "official" use, and one for whatever the user likes -- this second table would also act as an effective testing ground for new systems that might eventually become "official". I believe Bill's implementing these for Transactions, Splits, and Accounts, and is using the glib hash tables. He's also writing the code, which will be apocryphal as soon as I finish the text data format, to read/write these structures. The data value for a given key can be another hash, so the structure is recursive. Once this is done, we'll have to have good documentation indicating what different keys are being reserved for. For example, it seems clear that, as Richard has suggested, that we need to record the links between related accounts when handling a dividend. This can be done with reserved key pairs like "dividend-from", etc. Frankly, you could argue that we could just switch to the hash table as our fundamental data structure, but I'd like to address that right now. While it would be possible, it's probably worth while to keep the more important fields, which will be accessed much more often and are *always* needed, as actual fields in a struct. However, if we make sure to always use setter/getter functions to manipulate these fields, then we can change the internal representation to whatever we like without external impact. Does this seem to match OK with what everyone needs? -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Problem with Make
[EMAIL PROTECTED] () writes: The solution is re-installing gcc?? I must download any package??? Try compiling without the -ansi argument. If that allows the simple test program to compile, then you can probably get past your current gnucash compile problem by just updating to current CVS, or by not using --enable-warnings. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Unbound variable:pointer-token-null?
Robert Graham Merkel [EMAIL PROTECTED] writes: Agreed, this is a serious bug. The g-wrap maintainer has just released a new version, and I expect the problem may be related to that. I'll give it a try, and see if that's the case. We need a README on the ftp site. No one's supposed to be using g-wrap 0.9.4 for gnucash yet. People should still be using the previous version. I have to get some patches to Dave before gnucash will work with the new version. I'll try to do that shortly. It's probably cheaper than dealing with a README : -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Unbound variable: pointer-token-null?
Robert Graham Merkel [EMAIL PROTECTED] writes: Thanks for that, you just saved me a bit of tracking down. Now I'll have to figure out why Rob Browning removed that function from g-wrap. Check out the NEWS or ChangeLog files for 0.9.4. Basically I've reworked pointer tokens so that there's no such thing as a null pointer token any more. G-wrap handles passing back C NULL's as #f now, and if you pass in #f to a g-wrapped function, g-wrap will convert it to a NULL before calling the underlying C function. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: help on disabling preferences widgets
Kevin Finn writes: On Tue, 04 Jul 2000, Dave Peticolas wrote: Robert Graham Merkel writes: Kevin Finn writes: [...] Disabling by name would be just fine. Keep in mind, though, that disabling would most often be done in scheme, or at least the information that one option's sensitivity depends on another option's value should be stored in the scheme option structure. The option GUI code should not know the 'meaning' of the options -- it just implements the GUI. That makes sense. I wasn't entirely clear on the distinction between the responsibilities of the scheme and the top-level.c code, but that clears it u top-level.c can use the meanings of the options, it's dialog-options.c that should be 'meaning neutral'. So the callback from when the boolean is changed might need to change the val of the no-longer-editable option to a "safe" value? What about the case wher we make an option non-editable due to something besides another option, for example we disable an option if the account balance is zero or something like that. Since there's no boolean option to check for whether our non-editable option is editable or not, do we need to provide a way to query the editable status of the option? Can we query the Gtk+ "sensitive" status of a widget, do we have to store that state? You can query the sensitivity state of a widget using the gtk argument api, but I still don't think we should equate 'user editable in the gui' and 'changeable by implementation code'. I don't see a problem in general with the implementation code setting or reading the value of an option with an insensitive widget. I suppose it might be useful to make an option value read-only or completely inaccessible, but I wonder if that would create more complexity than its worth. Just because a currently 'irrelevant' value is being read, doesn't mean it's going to be used incorrectly. For example, it may just be used to save the option to another representation. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Problem with Make
Rob Browning writes: Robert Graham Merkel [EMAIL PROTECTED] writes: I'm afraid your gcc setup is broken. Until you get that sorted out, you won't be able to compile gnucash. Sorry! Do you know if this problem was ever resolved? The problem seemed to be with alloca being undefined, and after I poked around in the gcc man pages for a bit, it seems that alloca is undefined (or at least must come from a lib) if -ansi is used: The functions `alloca', `abort', `exit', and `_exit' are not builtin functions when `-ansi' is used. So I think the problem should go away if -ansi is just removed from the options. I belive Dave has killed off --enable-warnings in the latest CVS, so that should fix the problem. Nope. Didn't think of that . . . Doh! Robert Merkel [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: help on disabling preferences widgets
Kevin Finn writes: Out of curiosity, what is the query that you would use to determine the gtk sensitivity? I've looked at the Gtk+ on-line tutorial, and under "Widget Attributes" they listed gtk_set_sensitive, but no get_sensitive. It also mentioned that "sensitive" is part of the widget state, but I didn't see a function to get the state. You need to use the gtk_widget_get call. Check out http://developer.gnome.org/doc/API/gtk/gtk-object-properties.html for more info about gtk object properties. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
