Re: CVS update: gnucash/src/scm/report
Wow, this is a huge improvement! I see the development warning and the splash screen in about 5 seconds after startup, and then the account tree comes up in another 5 or so. At least for users with somewhat older hardware like I have, I think this will be a huge usability improvement. It was definitely one of my biggest issues. Thanks a lot! Robert Browning wrote: Date: Monday June 18, 2001 @ 12:59 Author: rlb Update of /home/cvs/cvsroot/gnucash/src/scm/report In directory www.linas.org:/tmp/cvs-serv32066 Modified Files: report-list.scm Log Message: * src/scm/report/report-list.scm: switch to use-modules for some reports. ___ gnucash-patches mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-patches -- Kevin Finn [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: can't build from CVS - link errors?
Kevin Finn wrote: The compile went fine, but I get a ton of g-wrap related errors at link time: http://people.ce.mediaone.net/kevinfinn/errors.txt I removed and rebuilt gnc-dir.h, are there any other gotchas that I missed? I haven't changed g-wrap versions or anything like that since the last successful build I did (Friday night sometime?). Any ideas? It works now after a clean build. I'm not sure what the problem was. Oh well. -- Kevin Finn [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
can't build from CVS - link errors?
The compile went fine, but I get a ton of g-wrap related errors at link time: http://people.ce.mediaone.net/kevinfinn/errors.txt I removed and rebuilt gnc-dir.h, are there any other gotchas that I missed? I haven't changed g-wrap versions or anything like that since the last successful build I did (Friday night sometime?). Any ideas? -- Kevin Finn [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: plugin/module architecture proposal for gnucash-1.7
Bill Gribble wrote: Well, now that the 1.6 release has happened, it's time to start looking forward to the 1.7 series :) This is a proposal that I have been wanting to get off my chest for a while. ... 2. New functionality can be added as modules that require only the installation of a new module rather than an upgrade of the whole system. Module versioning and version dependencies that track module APIs will prevent skew. ... What do you guys think? Specific thoughts/desires about how it should be done? It sounds like an idea whose time has come. A couple questions: - I'm a little nervous about version skew, having recently worked on a project in RL that was transitioning from a monolithic product into separate modules with mixed success. I think a lot will depend on how general the module interfaces can be - the less is known about other modules, the easier to deal with skew if it occurs. - is the function table located in the scheme layer or the C layer? Would a pure-scheme module (say, something that just generates reports at a terminal) still need a C lib to hook up to the function table? - Will each module provide its own g-wrappers, I assume? Maybe there needs to be a mechanism or a policy to avoid collisions in that namespace. -- Kevin Finn [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Compiling GnuCash with Guppy
I've had good luck getting Mandrake binary RPMs (and source) from
Ximian, maybe ftp.ximian.com?
Kevin
Richard -Gilligan- Uschold wrote:
I discovered some precompiled binaries of Guppi for Mandrake, so, I
downloaded and installed them. Of course, this required newer versions of
a number of other packages. I'm currently stumped by: gdk-pixbuf, for
which I can't find a precompiled devel binary for Mandrake. Compiling
gdk-pixbuf from source requires (among others) a newer version of libgal4.
The only binary version I can find for Mandrake are compiled for GLIBC_2.2,
which I don't have and am not going to upgrade to. In the past, I've
resolved this particular dependency by compiling from source.
Unfortunately, I can't locate source for libgale4. I've looked on
rpmfind.net, www.gnu.org, and www.gnome.org.
Any clue where I can fine source for libgal4?
thanks
--
Gilligan|__o .oooO
/| _ \,_ ( )
/p|\(_)/ (_) \ ( Oooo.
/ | \ \_) ( )
) /
[EMAIL PROTECTED] (_/
[EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
--
Kevin Finn
[EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: 1.5.97 first impression
Sounds great! I haven't had as much luck trying to move the splash screen earlier; since I didn't want to do the splash screen before the gnome init stuff (gnc:ui-init), but I do need the report list before creating the report menus, there's definitely some rearranging to do. Even with the report speedup it would be nice to see the splash screen earlier, so I'll still take a look at it some more. Kevin Rob Browning wrote: Kevin Finn [EMAIL PROTECTED] writes: Upgrading to guile 1.4 made things a little faster once the splash screen came up (1-2 seconds rather than 5-6), but the time from starting the program until the splash screen appears is still the same, about 12 seconds. I've been planning to work on gnucash performance issues some more for a while, and kept putting it off until I had time to do it right(TM). However, your transaction-report load time kinda agravated me, so I decided to at least check one of my suspicions. For a while I'd wondered if the way we were using deeply nested top-level environments in order to hide private bindings (which is a good idea) might not be something that guile's evaluator expected, and hence might be hammering a sore spot performance-wise. So to test that I went ahead and converted transaction-report.scm into a guile module -- (gnucash report transaction) and arranged for it to be installed in a suitable place, etc. Testing, I found that for the dummy case of just loading transaction-report.scm, load times went from 4.2 seconds on my system to 0.2 seconds. Then I tested a full gnucash run like this: time gnucash --nofile \ --evaluate '(gnc:depend report/report-list.scm) (exit 0)' before the modularization, this took 11 secs, and after 7, with only transaction-report.scm changed. So it seems like my suspicions were probably correct. I'm going to go ahead and modularize the rest of the reports (for consistency), and then any other files that need it. These fixes won't show up in 1.6.0, but look for a (hopefully) large --nofile startup speedup in 1.6.X. Thanks for the report. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -- Kevin Finn [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: 1.5.97 first impression
Rob Browning wrote:
Guile 1.4 is substantially better, and I'd recommend it -- it's
especially notable for faster loading which is one of the things
that's probably biting you. Guile's actually pretty easy to
build/install, and I'd be happy to help if you need it. Just ask
here, directly, or on guile-user.
Upgrading to guile 1.4 made things a little faster once the splash
screen came up (1-2 seconds rather than 5-6), but the time from starting
the program until the splash screen appears is still the same, about 12
seconds.
Okay I'll have a look at it with strace. Maybe it is stalling on
something really stupid like name resolution.
There was apparently also some issue with guppi -- I think maybe it
was reading from /dev/random, and so it won't finish until the entropy
pool has been full enough to generate all the random numbers it
needs. If things speed up when you move the mouse furiously, then
you'll know that's it :
Although I'm not the original person you were replying to, I did
take a stab at stracing it. I do see reads of /dev/urandom (rather than
/dev/random), but furious mouse movement doesn't seem to get things
loading any faster than leaving it still. With a cursory inspection of
the strace, the only thing that sticks out is a ton of calls to
time(NULL) and times - I assume this is while creating the in-core
splits or transactions(xaccGUIDNew)? In some cases there are stretches
of times calls which suck up several seconds in a row. As someone else
mentioned, the startup process does send my load average up to .96 or
so. A brief chronology of events:
01:03:15.982797 execve(/usr/local/bin/gnucash, [gnucash], [/* 51
vars */]) = 0
(first scm file)
01:03:16.773352 stat(/usr/share/guile/site/init.scm, 0xb480) = -1
ENOENT
(first gnucash scm file)
01:03:17.079993 open(/usr/local/share/gnucash/scm/bootstrap.scm,
O_RDONLY) = 3
(first moves towards loading my data)
01:03:31.193535 stat(/home/kevin/finance, {st_mode=S_IFDIR|0770,
st_size=14336, ...}) = 0
Somewhere around 01:03:36 it actually loads, and I clicked Exit.
I'm not quite sure where the line is in the trace, though. I can
provide the whole trace if anyone is interested.
While I'm thinking about it, has anyone else noticed that page up
and page down in the help browser goes two pages at once, or is it just
me?
--
Kevin Finn
[EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: gnucash 1.5.98 qif import
Bill Gribble wrote: On Wed, Jun 06, 2001 at 01:06:05PM -0700, Dave Peticolas wrote: I don't know about guile-1.4, but on my guile-1.3.4 system, it takes almost 3 seconds to load src/scm/report-list.scm. That is over half the time I wait before the splash screen comes up! So I think you are wrong here. report-list.scm doesn't create any report objects. It just defines the different types of reports. I was talking about the loading of the code in ~/.gnucash/books/foo.scm that actually causes the reports to be created. If you were talking about trying to avoid loading the code that defines what reports are, I misunderstood you. That would be a fairly major departure from our approach now, which is to load all the data-independent Guile code needed by Gnucash at startup time. We would have to rewrite all the reports to somehow define them (so that they appeared in the report menu) without actually evaluating the (define) forms inside the report Scheme files. Pretty tricky. I'm very surprised that the loading is so slow with 1.3.4. Gnucash doesn't take nearly that long to load for me; and if the splash screen doesn't come up while stuff like that is loading, what good is it? Maybe we should shuffle things around to display the splash screen sooner. That won't make things load faster, but eye candy helps pass the time. Maybe a progress bar for startup? Another data point - I got inspired and did some debugging in main.scm where a lot of the other scm files are require'd in. On my machine it takes ten seconds of load time to get through report-list.scm. This is measured by printing the current time before and after '(gnc:depend report/report-list.scm)', using guile 1.4. Digging deeper, the largest load times seem to be register.scm (~3 seconds) and transaction-report.scm (~5 seconds). Like Dave said, these aren't times to actually create and display the reports, because I don't have any reports said to run at startup. This is just time to complete the gnc:depend for each report. I haven't had as much luck determining exactly what goes on within these reports; apparently you can't just stick (display ...) anywhere inside a (let-syntax ... ) that you'd like. Commenting out register.scm and transaction-list.scm from report-list.scm causes gnucash to load about twice as fast for me. Maybe I'll take a look at what it would take to pop up the splash screen a little earlier in the process. -- Kevin Finn [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: gnucash 1.5.98 qif import
Bill Gribble wrote: On Wed, Jun 06, 2001 at 01:06:05PM -0700, Dave Peticolas wrote: I don't know about guile-1.4, but on my guile-1.3.4 system, it takes almost 3 seconds to load src/scm/report-list.scm. That is over half the time I wait before the splash screen comes up! So I think you are wrong here. I'm very surprised that the loading is so slow with 1.3.4. Gnucash doesn't take nearly that long to load for me; and if the splash screen doesn't come up while stuff like that is loading, what good is it? Maybe we should shuffle things around to display the splash screen sooner. That won't make things load faster, but eye candy helps pass the time. Maybe a progress bar for startup? Honestly, gnucash loads fast enough for me that I thought a progress bar would be a waste of time, but if people are going to be using 1.3.4 and it's that slow maybe we should rethink that. On my system, it takes 13 seconds from starting gnucash from a terminal until I see This is a development version. The splash screen comes up within the next second. Then, 5 seconds after that (19 since the startup) the main account window pops up. This is without any reports set to run on startup; when I do have reports there's an additional length of time (depending on the report) during report generation when the account window is basically unusable. I assume some guile loading is going on before the development version warning, but is there really 13 seconds' worth? I ran this test on a K6-2 350MHz desktop with 192M RAM, and loaded and unloaded gnucash a couple times before making the measurement in order to achieve what should be the best case on my system. My data file size is 1.5Mb. In comparison, almost everything else on my system except for Netscape starts up in 1-2 seconds. I'm amazed that others are seeing much faster load times; is the startup guile code so processor-intensive that it is causing the delay I'm seeing? Contrariwise, is anyone else experiencing really long load times like I am? Maybe I'll give guile 1.4 a try and see if that improves things, since this is really a low-end machine at this point in time :) The only thing that seems strange to me is that the splash screen takes a while to come up; maybe if that could be moved earlier into the startup sequence? I'm partial to progress bars or marching icons like the Gnome startup screen since they give me some indication that the app hasn't totally hung (which might be an issue if other users are also seeing this sort of load time), but I can see how some would find them annoying so that doesn't matter to me too much either way. The other thing is that the splash screen doesn't redraw if it's occluded during the startup process and then uncovered. Maybe a longer-term goal would be to figure out how to make sure GUI updates continue to occur during lengthy operations like data file loading and report generation. -- Kevin Finn [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: gnucash 1.5.98 qif import
Leach, Chris J (Oakton) wrote: It would be nice if moving parent moved the subtree. It would be nicer if the tree was presented and you could drag and drop subtrees It's been a while since I've imported from QIF, but I agree that it would be nice to be able to drag-and-drop account in order to reorder the hierarchy in the account tree window, even if you're not just importing. My original set of accounts were based on the MS Money default categories that I started with years ago, some of which no longer make any sense. One of my wish list items for the next development cycle would be to be able to re-arrange the account tree more-or-less at will. I think the last time I tried, changing an account's name didn't update all of the accounts' transactions' splits in other accounts with the new account name, although I haven't tried this in a while and so it may work right now. While I'm thinking about it here are some other things that would be nice for the future. Some of these I don't have any idea how to do, but I'd be willing to learn if no one else is already planning for them: Wish list: - rearrange account hierarchies - book closing - my initial equity account that I started with when migrating over from MS Money doesn't mean much now, a year and a half hence. I know there was some discussion about book closing on the list at one point but I don't know what the latest plan is. - startup and/or file load time - although I'm still using guile 1.3.4, is the scheme performance on startup significantly improved with guile 1.4? It was so painful to set up a development environment in the first place that I'm cautious about changing things if I don't need to :) Also being able to close my books and scrub out transactions from past years would probably help the load time too. My apologies if it's too soon to start looking forward to the next development cycle; I've been hanging onto a fairly involved set of reconcile enhancements that I'm ready to send out. -- Kevin Finn [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Compiling Guppy. was RE: 1.{56} dependency list
Phillip Shelton wrote:
Hmmm. As far as I know ( and I would like to have someone more
knowledgeable than I help out here) you need the 3.1 DTD in the catalog, as
jade is looking for the 3.1 DocBook DTD. Is there any way of telling which
catalog file that jade is using?
I am sure that having more that one catalog file can make things very
confused.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Richard
-Gilligan- Uschold
Sent: Tuesday, May 29, 2001 10:53 AM
Cc: [EMAIL PROTECTED]
Subject: Re: Compiling Guppi. was RE: 1.{56} dependency list
I had docbook-3.1-13mdk.i586.rpm installed but I reinstaled it:
rpm -i --replacepkgs docbook-3.1-13mdk.i586.rpm
install-catalog: install of docbook DTD
docbook DTD already in catalog
rm -Rf /usr/src/RPM/BUILD/Guppi-0.35.5/
there was no /var/tmp/[Gg]uppi*
/%{tmpdir}/Guppi-0.35.5-root-root/usr/X11R6/lib
What does your %{tmpdir} point to? Mine was /var/tmp
I'm thinking, maybe jade is not looking in the rigtht place
for docbook, or something similar?
I had the same docbook problems and never could find a Mandrake RPM that
would set up things properly. I eventually got the gnucash manual
working with the following info:
http://www.nwalsh.com/docbook/dsssl/doc/install.html
http://www.linuxdoc.org/LDP/LDP-Author-Guide/tools.html
I know nothing about docbook (OK, before setting it up I knew less than
nothing, *now* I know nothing :) but this worked for me.
--
Kevin Finn
[EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
question for gtk gurus
I'm interested in adding quickfill capability to the transfer
dialog (based on the Description field), because that would make things
just that much more convenient when using the automatic credit card
payment transfers (and ultimately I would like to add an automatic
interest transfer at the beginning of reconciliation of bank statements,
credit card statements, etc., but that's off in the future). I've
liberally copied the quickfill code from:
gnucash-sheet.c (gnucash_sheet_insert_cb/delete_cb)
table-allgui.c (gnc_table_modify_update)
quickfillcell.c (quick_modify)
and it almost works. That is, if I type the first character of a
matchable description into the Description entry, the rest of the word
is added, the remaining letters are selected, and the cursor is moved
appropriately, just like quickfill in the register. However, if I type
a second letter, the selection isn't added and the cursor isn't moved.
As far as I can tell, I am using gtk_entry_select_region and
gtk_entry_set_position correctly, and checking the entry afterwards does
indicate that the text is selected, even though it doesn't appear to be.
What I'm doing is listed below, are there any gotchas that I'm
missing? I can post the whole thing if that would help, I haven't done
so now because it's full of printfs and would need some cleanup.
Thanks for any ideas, I think I'm really close to getting this to
work.
Kevin
...
if( ( match = gnc_quickfill_get_string_match( xferData-qf, new_text_w
) )
( match_str = gnc_quickfill_string( match ) )
safe_strcmp( new_text, old_text ) )
{
gtk_signal_handler_block (GTK_OBJECT (entry),
insert_signal);
gtk_signal_handler_block (GTK_OBJECT (entry),
delete_signal);
gtk_entry_set_text( entry, match_str );
gtk_signal_handler_unblock (GTK_OBJECT (entry),
delete_signal);
gtk_signal_handler_unblock (GTK_OBJECT (entry),
insert_signal);
/* stop the current insert */
gtk_signal_emit_stop_by_name( GTK_OBJECT( entry ), insert_text );
gtk_editable_set_position( GTK_EDITABLE(entry), new_text_len );
gtk_entry_select_region( entry, new_text_len, -1 );
/* this printf indicates that the widget has the right
text selected, even though it doesn't appear so on the
screen. */
printf(gnc_xfer_description_insert_cb end: selected %d %d\n,
GTK_EDITABLE(entry)-selection_start_pos,
GTK_EDITABLE(entry)-selection_end_pos );
}
--
Kevin Finn
[EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: kudos and a problem with the welcome report
Dave Peticolas wrote:
This should be fixed now, thanks. If you find a way to repeat the
config file corruption problem, please let us know.
If I get similar report errors ("an error occured while generating
this report") is there an easy way to get the actual error messages
without digging into the report code itself? I recall the old-style
reports would dump out a guile backtrace from the problem point.
--
Kevin Finn
[EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: kudos and a problem with the welcome report
An update after playing around with this today - if I go into the
reports menu and select the "welcome extravaganza" report, it does come
up correctly and after that it seems to work when I restart.
Another interesting thing that I ran into was while customizing the
"income accounts" report - if I edit the report options, go to the
accounts tab, and control-click to remove one of the preselected
accounts (for example, I have separate accounts for "gross pay" and
"bonuses", and I don't want to include bonuses when I'm budgeting for
the future), when I click "OK" to exit the options dialog I see all of
the accounts get deselected so there is no income account chart visible
in the main screen. After this happens, even if I go back and "select
default" in the accounts options, I can't get the report to display
because the same thing happens.
Kevin
Kevin Finn wrote:
Unfortunately, although the "Welcome" report came up fine the first
one or two times I launched GnuCash, after that I seemed to get some
corruption in the config-1.6.auto file and the report wouldn't load.
The config file had:
(gnc:config-file-format-version 1)
;GnuCash Configuration Options
(B4C0@(B4C0@on: __guibinary corruption
(let ((option (gnc:lookup-option gnc:*options-entries*
"__gui"
"reg_column_widths")))
((lambda (option) (if option ((gnc:option-setter option) '(("transfer"
. 250) ("debit" . 97) ("credit" . 97) ("balance" . 97) ("reconcile" .
20) ("description" . 245) ("num" . 53) ("date" . 114) option))
...
and I saw the following warning on startup:
gnucash: [W] "failure loading ""/home/kevin/.gnucash/config-1.6.auto"
Exiting and restarting seems to have fixed the corruption in my config
file, but the report isn't fixed and still claims that an error occurred
while running it. Is there any way to get the error messages out of the
report? I'm thinking of something like the Netscape javascript
console. gnucash --debug didn't display any errors. Can I somehow
reinitialize my config-1.6.auto file so that the welcome report works
again?
Kevin
--
--
Kevin Finn
[EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
window manager exit doesn't work?
With the latest CVS, using the window manager's "exit"
functionality doesn't really exit gnucash, although it looks like it
since it closes all windows. The following change fixes the problem for
me, although since it seems like this problem was introduced during the
MDI changes recently, and I haven't tried this with all the different
MDI modes, I'm not sure if this is really the correct solution.
The gnc_shutdown call seems to be what the "Exit" toolbar button
does, and gnucash does exit correctly if you just click on that button
rather than the WM exit control.
Kevin
--- ./src/gnome/window-main.c Sun Apr 15 06:01:03 2001
+++ ./src/gnome/window-main.c Sun Apr 15 16:57:54 2001
@@ -69,7 +69,8 @@ static void gnc_main_window_create_menus
static void
gnc_main_window_destroy_cb(GtkObject * w) {
- gnc_ui_destroy();
+ gnc_shutdown(0);
+ /* gnc_ui_destroy(); */
}
--
Kevin Finn
[EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
remembering dock items' position
Hello, I'm interested in adding support so gnucash will remember the positions of the various dockable items on the main account window, primarily so I can drag the summarybar to the bottom of the window and have it stay there across invocations of gnucash. Depending on how the future chart-based gnucash main window works this addition might be helpful there too, and this could also be extended to any dockable elements of the register windows, etc. This looked pretty easy to do once I spent a little time looking at the gnome dock* APIs, and I almost have it working (just have to find some time this evening). My question is this: does anyone care whether the position information is stored with the rest of the user preferences in ~/.gnucash, or stored with the other gnome apps' position information under ~/.gnome? I notice that the information on the last file(s) opened in Gnucash (i.e. the files listed under the File menu) is stored in ~/.gnome/Gnucash, and since it is pretty easy to get gnome to handle this that is my first preference, as opposed to writing a g-wrapped config-file access routine. However, I'm concerned with how this works for gnucash users who aren't gnome users. Either implementation looks to be pretty simple. Any thoughts? Kevin -- Kevin Finn [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Gnucash CVS.
On Monday 12 February 2001 02:50, Christophe Guychard wrote:
Furthermore, the Stylesheet window does not display nice.
see styleesheets.png snapshot attached.
Christian Stimming wrote:
This bug affects the german translation as well: All the widget sizes are
more or less tailored to the english labels. Any language which happens to
need more space will look pretty ugly. We need some work here...
Actually, you see this with LANG=en as well if you bump your
default font size up to 140 from the default of 120. Although I would
almost think it's more than just the font size itself, because if I grab
the right-hand side of the window and drag it larger, I see much more of
the "Background Pixmap" text entry and a "Browse" button that was
totally off the right side of the window. The change in size of the
window that's necessary to see the whole thing is much larger than the
difference in font size it seems.
Also, if I close the style sheets window and then attempt to select
it again from the menu, it can't be opened again. The attempt to
re-open it generates this error:
Gtk-CRITICAL **: file gtkwidget.c: line 1425 (gtk_widget_show):
assertion `GTK_IS_WIDGET (widget)' failed.
Kevin
--
Kevin Finn
[EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
a couple interesting bugs
I ran into the following couple bugs with the latest cvs gnucash
this evening. I can get more debugging output if necessary, but
hopefully the description will ring a bell with someone.
1. When adding a new interest transaction for an asset account that I
use for a CD, I used the transaction completion feature by typing the
first few letters of the description to fill out the transaction, and
then just changing the actual transaction amount. However, the
autocomplete filled in "15 + 7/25" rather than the dollar amount 15.28.
The fractional representation remains even if I change the amount to
"15.86", for example - it is replaced by "15 + 43/50", but when I tab
away or hit enter to complete the transaction, this is replaced by
"1.01". This doesn't happen with all new transactions, but seems to
happen with when I autocomplete from a previous transaction which was
for interest or a dividend on an asset account. I did see this once for
my phone bill when autocompleting, too. If I go back and update the
transaction after this problem has occurred, I have no problems entering
"15.86" or whatever the value should be and going on.
I can reproduce this as necessary. I have the "auto decimal" preference
enabled.
2. Open an account window. In the main gnucash account list
window, click on save. While the save is going on, click the
window manager "close window" button on the account window. This
triggers a segmentation fault. This is easier to do with a rather large
file of transactions, mine is slightly over 1M in size.
With gnucash --debug enabled, I get this error:
Gtk-WARNING **: invalid cast from (NULL) pointer to `GtkWidget'
The bug-buddy stack trace (doesn't seem too helpful):
0x40baa2f9 in wait4 () from /lib/libc.so.6
#0 0x40baa2f9 in wait4 () from /lib/libc.so.6
#1 0x40c16f68 in ?? () from /lib/libc.so.6
#2 0x40ae76e6 in waitpid () from /lib/libpthread.so.0
#3 0x400f645a in gnome_segv_handle () from /usr/lib/libgnomeui.so.32
#4 0x40b1e9d8 in killpg () from /lib/libc.so.6
#5 0x404619a2 in g_list_foreach () from /usr/lib/libglib-1.2.so.0
#6 0x535610ec in ?? ()
Let me know if I can provide some more info,
Kevin
--
Kevin Finn
[EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: GUI - accounts vs. transactions
On Wed, 04 Oct 2000, Bill Gribble wrote: The fundamental unit of display in the register is the transaction. In any display mode, the transaction's date, description, and number are shown. the key to understanding the register display is to note that the register generally shows a single account, and for each transaction, splits affecting that account ARE NOT SHOWN. The only time you can directly see the split affecting "this account" is from a register for another account. In double line mode ONLY, you can also see the Memo for the split affecting "this account". Toggling between "multi-line" (which shows all splits except for the ones in "this" account) and "double line" mode can be disconcerting until you understand this. I share some of the same confusion as Terry in at least one regard. I've been making entries into my checking account for my paycheck, which also show up in my Income account for Gross Pay. Actually, I've only made one real entry; since that original entry I've just been duplicating the last paycheck when looking at my checking account in the register, and changing the Memo field. Now when I look from the perspective of the Income account, all of the Memo fields still show the memo from the original transaction that was the basis for the duplicates (I'm using Double Line mode, BTW). This is a little disconcerting; at least in that it violates the "principle of least surprise". The reason that I say this is I had been under the impression (granted, without thoroughly reading the manual) that each register view was really just a different way of looking at the same transaction. So since the transaction date, Description, and income/expense matched up, it is surprising that the Memo fields do not. The explanation that I'm really looking at two different splits of the same transaction certainly makes sense in terms of double-entry bookkeeping, but it does make things more confusing to the user in this case. Since the primary goal of double-entry has already been subverted (because the monetary amount is copied into the various splits automatically, rather than entered twice by the user to ensure that the amount is correct), is there any way that the Memo fields could be similarly copied between splits in the case of duplicated transactions? Or if there's an easy way to get duplicated transactions to come out looking right that I've missed, please let me know. Kevin -- Kevin Finn [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: check auto-numbering
On Thu, 31 Aug 2000, you wrote: I have been noticing something about the check autonumbering that should probably be fixed by someone. I write a check on one checking account to transfer funds to another checking account. That works fine. Now on the second account, whenever, I try to use auto-numbering, the next number is incremented from the check number from the "other" account. This occurs even if I correct the number and then on subsequent checks use autonumbering. The autonumbering routine is picking up the number from the "wrong" account and ignoring numbers from the account for which the register window is open. I have seen something like this as well, although it was within the same checking account. I had some check numbers missing from the sequence (because my wife has that check book and hadn't used them yet). So if the sequence went 534, 535, skip a whole bunch, 700, 701, ..., then when I would try to enter a new check 702, the number would be filled in as 536. This would happen whenever I restarted Gnucash, although once I corrected 536-702 in one session the problem was gone for the remainder of that gnucash session. I looked into it a little bit and it had to do with the next value of the number cell which holds the check number. Somehow as my records were loaded, check 535 would be the last one loaded (even after 701), so that the blank transaction at the bottom of the register would have it's next value initialized to 536 rather than to 701. I haven't had much luck investigating further, though. Kevin This probably isn't a high priority for anybody to fix and certainly doesn't crash gnucash. It's just one of those things that, when they afflict your configuration, really get under your skin. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel -- Kevin Finn [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
make install problems?
I get an error when running "make install". I don't know how long I've had this error, since I don't usually look at the tail of the make install output. Apparently I'm missing db2html - where can I get that from? Kevin Making install in C make[3]: Entering directory `/home/kevin/gnucash/gnucash-cvs/doc/sgml/C' make[4]: Entering directory `/home/kevin/gnucash/gnucash-cvs/doc/sgml/C' make[4]: Nothing to be done for `install-exec-am'. (db2html gnucash.sgml) /bin/sh: db2html: command not found make[4]: [gnucash/index.html] Error 127 (ignored) /bin/sh ../../../mkinstalldirs /usr/local/share/gnome/help/gnucash/C /bin/sh ../../../mkinstalldirs /usr/local/share/gnome/help/gnucash/C/image /bin/sh ../../../mkinstalldirs /usr/local/share/gnome/help/gnucash/C/stylesheet-images for file in gnucash/*.html; do \ basefile=`basename $file` \ /usr/bin/install -c -m 644 ./$file \ /usr/local/share/gnome/help/gnucash/C/$basefile; \ done /usr/bin/install: ./gnucash/*.html: No such file or directory make[4]: *** [install-data-local] Error 1 make[4]: Leaving directory `/home/kevin/gnucash/gnucash-cvs/doc/sgml/C' -- Kevin Finn [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: How to commit prefs before the user presses Apply?
On Fri, 04 Aug 2000, Dave Peticolas wrote: Kevin Finn writes: Is there a way to force the setting of an option right away? I suppose could add a flag to the generic options structure that would make it call the setter right away, but I'm hesitant to make such a large change to the option structure if there's an easier way. There isn't an easier way, but I think this needs to be done in a slightly different way. We can't change the option value until the user hits 'Ok' or 'Apply' under any circumstances -- that violates the semantics of the dialog. So, I think options need a new callback that is invoked whenever the GUI implementation of the option is changed by the user. The callback would be invoked with the new value as an argument. Would you like to work on this? So a generic addition to gnc:make-option (and the functions that call it) for this callback? I guess then make-complex-boolean-option wouldn't really be necessary for this case, although I'll still send the patch for it. Hi Kevin, it occurred to me that solving the problem you mentioned will also probably require a callback when the dialog is opened so the 'partner' option can be grayed out as appropriate. This is getting complicated :) That makes sense. I can take a look at this stuff. Kevin Finn [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
How to commit prefs before the user presses Apply?
I'm trying to set up a complex boolean option in the prefs, such that you can include the definition of a function in an option definition and the function will be called when the option is selected. The immediate use for this would be so that toggling a boolean option could immediately make another option selectable or not selectable. I have this all set up in the setter function, so that the setter sets the value and also calls the specified function. Unfortunately, the setter doesn't seem to get called immediately when you toggle the option - it only gets called when the user selects "Apply" or "OK". This doesn't work that well if you're expecting option 1's setter to "grey out" option 2 - the constraint on the user of making a particular option non-selectable doesn't take effect until the user clicks "Apply". Is there a way to force the setting of an option right away? I suppose I could add a flag to the generic options structure that would make it call the setter right away, but I'm hesitant to make such a large change to the options structure if there's an easier way. Any thoughts? -- Kevin Finn [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: loading config.auto from config.user
It works great now - thanks. Kevin On Wed, 12 Jul 2000, Dave Peticolas wrote: Kevin Finn writes: On Tue, 11 Jul 2000, you wrote: Kevin Finn writes: src/scm/design.txt specified this method: (load "~/.xacc.auto") which is a little out of date it seems. Try (gnc:load "~/.gnucash/config.auto") That was one of the first things I tried, but I see: Whoops, you're right. I added the .gnucash directory to the search path in current CVS. Try this: (gnc:load "config.auto") dave -- Kevin Finn [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: loading config.auto from config.user
On Tue, 11 Jul 2000, you wrote:
Kevin Finn writes:
src/scm/design.txt specified this method:
(load "~/.xacc.auto")
which is a little out of date it seems.
Try
(gnc:load "~/.gnucash/config.auto")
That was one of the first things I tried, but I see:
gnucash: [D] "loading user configuration"
gnucash: [D] "gnc:find-in-directories looking for ""~/.gnucash/config.auto"" in
"("/home/kevin/.gnucash/scm" "/usr/local/share/gnucash/scm")
gnucash: [D] " checking for ""/home/kevin/.gnucash/scm/~/.gnucash/config.auto"
gnucash: [D] " checking for ""/usr/local/share/gnucash/scm/~/.gnucash/config.a
gnucash: [D] "Running functions on hook "startup-hook
and my preferences don't get loaded. I've also tried the full path rather than
the ~ path with no more success. Using (gnc:load "../config.auto") I see the
following additional debug info before the startup-hook:
gnucash: [D] "found file ""/home/kevin/.gnucash/scm/../config.auto"
gnucash: [D] "loaded file ""/home/kevin/.gnucash/scm/../config.auto"
I will update the document to reflect that.
Also, is cvs.gnucash.org down, or is it just my ISP's DNS that hasn't updated
yet? I can ping www.gnucash.org successfully.
It's DNS. Use 207.170.121.1 in the meantime.
Thanks,
Kevin
dave
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
--
Kevin Finn
[EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
loading config.auto from config.user
Hello,
src/scm/design.txt doesn't seem to be entirely correct on the subject of
loading config.user and config.auto any more. In order to set up a config.user
(for testing gnc:set-option-selectable-by-name) and then load config.auto from
it, after some trial and error I had to use this:
(gnc:load "../config.auto")
because the directories searched are
gnucash: [D] "loading user configuration"
gnucash: [D] "gnc:find-in-directories looking for ""../config.auto"" in
"("/home/kevin/.gnucash/scm" "/usr/local/share/gnucash/scm")
I also had to mkdir ~/.gnucash/scm, so the ../ path would work. Should I be
using something instead of gnc:load? I tried primitive-load but that failed to
load config.user correctly. gnc:load doesn't seem to be the correct thing to
use, since it doesn't look in ~/.gnucash normally.
src/scm/design.txt specified this method:
(load "~/.xacc.auto")
which is a little out of date it seems.
Also, is cvs.gnucash.org down, or is it just my ISP's DNS that hasn't updated
yet? I can ping www.gnucash.org successfully.
Kevin
--
Kevin Finn
[EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
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: help on disabling preferences widgets
On Mon, 03 Jul 2000, you wrote: Kevin Finn writes: [...] I think disabling by name would be sufficient - it is consistent with the rest of the options interface. 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. Good point. This would require storing a "selectable" boolean with each option, which might be a waste for the majority of options for which we won't be doing this kind of stuff. The other alternative would be to query the widget to determine its current sensitivity to input. I know there is gtk_widget_set_sensitive(), is there a corresponding function to get_sensitive() ? Since this information is already stored by Gtk+ somewhere, I would rather consult its value if possible. Would it be reasonable to make this error a run-time crash or a popup warning? I'm not sure how you would return an error from a bad option lookup, since there could be many different types of options and what might be an error condition from one would be a valid return value from another (-1 would be a good error value for a boolean, but not for a numeric range option, etc.). For every option which is made available/unavailable by another option (example: a boolean to enable a range option) we could just store the name of the "parent" option in the enabled/disabled option, and it could query its parent to find out whether it should return a value, or whether it should signal an error. It would be nice if we could only use "variably enabled" options when their selectability is controlled by another option, but I think there might be cases where we would enable/disable certain options on the basis of other things, such as whether the user has money in the account or something like that. Maybe we could just pass each option an optional parameter which is a callback function. If the option has such a callback, it can fire that off to determine if the option is allowed to be queried right now, and can use that to decide whether to return a value or signal an error. The callback could know to check the boolean option enabled/disabled flag, or check account balance, etc. The callback could also be checked if someone tries to set the value - you couldn't change a disabled option in the GUI but maybe you could try to in a script/report, so that might come in handy. A "am I enabled?" callback would be the most comprehensive way to handle this sort of thing, without adding overhead for options which don't need that complexity. Please don't take my comments as definitive, though - Dave Peticolas wrote most of the options code, and he may have other ideas. Thoughts, Dave? Robert Merkel[EMAIL PROTECTED] ---- -- Kevin Finn [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
help on disabling preferences widgets
Hello, I'm trying to set up the preferences dialog for auto decimal point so that there is a check box to enable/disable the feature and then a range of values for how many decimal places will be automatically created. Is there a way to grey out or disable the range widget when the checkbox is disabled? I've looked through the existing .scm files but I haven't found any existing code which disables/enables a widget (which I could use in the callback for the checkbox function). Is there any existing code that does this that I could look at? Kevin -- Kevin Finn [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: cvs 2000-06-26
Tip suggestion: Type + in the Num field of the register to fill in the next check number. Kevin On Mon, 26 Jun 2000, you wrote: CVS has been updated. New Stuff (Development Branch): + Robert Graham Merkel's tip-of-the-day patch. We need tips! If there was a tidbit of information you wish you had known when you started using GnuCash and/or started tracking your finances, please submit it as a tip (two strings, one displayed under the other.) dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED] -- Kevin Finn [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Accounts/catagories, splits, and autonumbering...
On Fri, 23 Jun 2000, Bill Gribble wrote: Clark Jones [EMAIL PROTECTED] writes: [...] A less important feature, but one who's absence is still annoying, is an "autonumber" -- in Quicken, in the "transaction number" column, I can just hit the 'n' key, and it will automatically give me the next number in the sequence. Hit the "+" key in gnucash for the same function. Thanks, Bill Gribble Wonderful! I too have been searching for that function since switching from MS Money a few months ago. I think there might be a little problem with it if you don't always have consecutive check numbers, though. For example, if I start Gnucash and the first check in the account is 534, and then there are some holes in the sequence and the last check is 600, if I start a new entry and hit '+' I get check number 535, not 601. However if I first fill out check 601 by hand, and then hit + for the next check, it correctly shows 602. It seems like the last check number is saved while the program is running but doesn't remain across shutdowns. What I would expect would be that the + key would always generate 1+the value of the highest-numbered check or maybe the most recent check in the account. While I'm writing, here's something else that might exist in Gnucash but I haven't found yet. Is there a way to type in dollars and cents without typing the decimal point? For example, I want to type "2000" and have it register as "20.00", not as "2000". I haven't seen an option to turn that on and would be willing to add that functionality if it doesn't currently exist. Thanks again to everyone for creating such a great piece of software - I really enjoy no longer rebooting to balance the checkbook. Kevin Finn [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Accounts/catagories, splits, and autonumbering...
It was possible in MS Money 2.0, I don't know if it's available in any recent financial software. I think that some adding machines (pre-PC era) used to have a mode of operation like that; my grandfather was a CPA and I recall he used to do something similar for long columns of figures. I've just gotten used to not using the '.' and so some of my checks recently have been entered as 100x what I wrote them for :) Kevin On Fri, 23 Jun 2000, Dave Peticolas wrote: Kevin Finn writes: While I'm writing, here's something else that might exist in Gnucash but haven't found yet. Is there a way to type in dollars and cents without typin the decimal point? For example, I want to type "2000" and have it register a "20.00", not as "2000". I haven't seen an option to turn that on and would b willing to add that functionality if it doesn't currently exist. Is that a feature of Quicken? (Not that it needs to be, I've just never heard of that functionality before). dave -- Kevin Finn [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
