Re: Bug 106383 feature request: close year end
Marco Balmer [EMAIL PROTECTED] writes: What is the status of this feature request? Bug 106383 feature request: close year end http://bugzilla.gnome.org/show_bug.cgi?id=106383 I know it's only a feature request, but I'd like to use such a feature. (As with most projects, the requests (or bugs) existing has nothing to do with code changes... we need more people to do work, not suggest features.) As you're aware, there is some code for Close Books in SVN, but – your assertion in comment #10 notwithstanding – it's not known to be stable. AIUI, it's quite incomplete. I don't imagine it will be re-enabled for 2.2... It might be helpful if you write up a description of the testing you did, and what the effects of the feature were. That might convince someone that it is (not) worth re-enabling for 2.2, or at least give us all a clearer picture of what work remains. I've personally not even used it, let alone looked at the code. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpVj8HSWLi2s.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash 2.1.4 Released
Thomas Bushnell BSG [EMAIL PROTECTED] writes: It's the second of those two interpretations. And it's only a problem for people using scheduled transactions. Ok, then next question. What exactly happens if a user tries to load a new-format file into an old gnucash? It will generically complain that the file is unreadable; I forget the exact error message text. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpIu9YGNjgLg.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash 2.1.4 Released
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Ah, good. Thanks for indulging me. This all sounds like it's exactly the best one can expect, given the necessity of changing the format in the first place. It could be better ... 1.8/2.0 could (non-)silently ignore XML sub-trees that they did not understand. Then, 2.2 could emit both the old (FreqSpec) and new (Recurrence) structures and the files would be backward-compatible. Of course, it'd be custom, new code to generate a FreqSpec from a Recurrence, and there are features of the Recurrence that can't be expressed in a FreqSpec, but only if used could 2.2 refuse to save in pre-2.2 format. Unfortunately, our XML error handling sucks. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpisPqizQuHN.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash Testplan First Draft
Derek Atkins [EMAIL PROTECTED] writes: ahmad sayed [EMAIL PROTECTED] writes: 2 - Modify the widget code to be accessible, I prefer this but not sure how feasible is it? , That's the big question.. It's written on a GnomeCanvas and.. quite annoying. The new register-rewrite will make it easier to test, obvioualy, but that's not finished yet. I would suggest trying to figure out if the register is basically testable as soon as possible. It might have a big impact on the rest of your work... -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpprkSvSPjV8.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Since Last Run dialog concerns
Tim Wunder [EMAIL PROTECTED] writes: It's not always a good thing to pile everything into a single view. Some things need to be separated. Particularly reminders, or upcoming SXs, from current SXs that require immediate action. I don't agree; I don't think it's piled ... in the regular case, I have maybe one reminder and two to-create SXes ... so three things to see. I guess it could be 2 pages with 1 or 2 things each, but it seems like one unit of interaction is better than two, here. I'm not so sure about the need to separate the reminders out from the others ... Additionally, it seemed that /every/ SX was listed, regardless of its state, even those that were neither reminders nor ready to be created. There is no reason that the SLR should display SXs that are neither in a reminder state, nor in a to be created state. That's a good point ... they don't really deserve a line-item at all. I've noted this in src/doc/sx.rst. I have lots of SXs, yet I fail to see the usefulness of the expand/contract widgets. It strikes me as clutter. Do you actually use that? I think the need to expand and contract the SXs in the display would go away if there were an ability to filter transactions. No, I don't. Here's another thought I just had while looking at the SLR. Much of the clutter I see are Reminder SXs with variables that are expanded by default in the tree view. Would it be possible to only expand the variables if the SX is in a to be created state and not a reminder? That would go a long way towards de-cluttering the view, IMO. Another really good idea, noted. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgp5mYuYwfmnw.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Generic importer:QIF
Chintan Agarwal [EMAIL PROTECTED] writes: frequent occurrence of the word Transaction, I could not successfully find the definition of the data-type(=Transaction data-type). If you could point src/engine/Transaction.[ch] You will generally want to familiarize yourself with the Engine, as it's the core datatypes of the system. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgp8nAN7Ta1u9.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r16208 - gnucash/branches/csv-import/src/import-export/csv - Added a bunch of comments to gnc-csv-import.c.
Benjamin Sperisen [EMAIL PROTECTED] writes:
Log:
Added a bunch of comments to gnc-csv-import.c.
Modified:
gnucash/branches/csv-import/src/import-export/csv/gnc-csv-import.c
+/* This struct contains all of the data relevant to the preview dialog
+ * that lets the user configure an import. */
You should take a quick look at the doxygen syntax
http://www.stack.nl/~dimitri/doxygen/docblocks.html. In short, if you make
these javadoc-style comments /** ... **/, then they'll show up in the
generated documentation, basically for free. There are some other tags and
rules that are useful for annotating parts of the documentation strings like
variables and identifiers.
(Note that in terms of doxygen, we use the 'javadoc' (not Qt) form, and '@'
(not '\').)
typedef struct
{
[...]
+ GtkDialog* dialog; /* The dialog */
This comment doesn't add anything, and doesn't need to be there.
+ GtkTreeView* treeview; /* The treeview containing the data */
+ GtkTreeView* ctreeview; /* The treeview containing the column types */
+ GtkCheckButton* sep_buttons[SEP_NUM_OF_TYPES]; /* Checkbuttons for common
separators */
+ GtkCheckButton* custom_cbutton; /* The checkbutton for a custom separator
*/
+ GtkEntry* custom_entry; /* The entry for custom separators */
+ gboolean approved; /* This is FALSE until the user clicks OK. */
} GncCsvPreview;
For these, for doxygen, you'll want to say /** This is FALSE [...] */, I think.
+/* Event handler for when one of the separator checkbuttons is clicked. */
static void sep_button_clicked(GtkCheckButton* widget, GncCsvPreview*
preview)
{
+ /* The stock separator charactors */
char* sep_chars[] = { , \t, ,, :, ;, -};
Why not just call the variable stock_sep_chars, and dispense with the
comment?
+ /* A list of all the separators that have been checked. */
GSList* separators = NULL;
Similarly, if the variable is 'checked_separators'...
+ /* Go through each of the separator buttons. */
for(i = 0; i SEP_NUM_OF_TYPES; i++)
{
+/* If this button is checked, add the corresponding character to
+ * the separators list. */
if(gtk_toggle_button_get_active(GTK_TOGGLE_BUTTON(preview-sep_buttons[i])))
separators = g_slist_append(separators, sep_chars[i]);
}
+ /* If the custom button is checked ... */
if(gtk_toggle_button_get_active(GTK_TOGGLE_BUTTON(preview-custom_cbutton)))
{
+/* ... get the separator string from the custom entry ... */
char* custom_sep = (char*)gtk_entry_get_text(preview-custom_entry);
-if(custom_sep[0] != '\0')
+if(custom_sep[0] != '\0') /* ... and if it isn't blank add it to the
separators list. */
All of these comments describe exactly what the code already says. They are
no longer signal.
-static void encoding_selected(GOCharmapSel* selector, const char* enc,
+/* Event handler for a new encoding being selected. */
+static void encoding_selected(GOCharmapSel* selector, const char* encoding,
GncCsvPreview* preview)
{
+ /* This gets called twice everytime a new encoding is selected. The
+ * second call actually passes the correct data; thus, we only do
+ * something the second time this is called. */
static gboolean second_call = FALSE;
+ /* If this is the second time the function is called ... */
if(second_call)
Ick. This stateful behavior should be avoided if at all possible. Is there
a way to instead be conditional on the correctness of the data? Or
eliminate the double-call?
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgpOwjHIRQazx.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: I'd like to create an applet for gnucash
Martin Kaffanke [EMAIL PROTECTED] writes: The design of gnucash makes me not to extend gnucash. For that what you [...] What do you think about splitting gnucash into an frontend and a backend (data-server)? I suggest you would find it nice, but there aren't any people which have time for that. :( That's a good summary of the situation. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgp3EmhEQpeQb.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Custom reports / [ I'd like to create an applet for gnucash ]
Jeroen Nijhof [EMAIL PROTECTED] writes: I guess the actual problem that Martin has is: custom reports are too obscure! I've found out how to do them now: generate the report as usual, Yup! So -- (1) the manual does not mention the possibility to save custom reports, it would be nice if it does (in the section about reports) New text as a patch against gnome-docs is welcome. (2) Even when I had figured out that it was possible to save custom reports, I still could not find how to: because having to rename the report before you are offered the opportunity to save it is counter-intuitive. What would probably be a better user experience is that the 'Add Report' button is always active, but that for a report that is not renamed it brings up a pop-up window asking you for a name to save the report under. Presently, it should complain that the report needs to be renamed, but it does not at that point prompt you for the new name. And on a related matter: if you rename a report, and then rename it back, then the 'Add Report' button is still active. Should it be? Probably not. The reports system needs a major overhaul, but this aspect of it is one of the more annoying parts, true. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpu0pWmrdMAd.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: PATCH - QofCollection to be a GObject
Daniel Espinosa [EMAIL PROTECTED] writes: Updated PATCH, it fixes some problems not finished, but now it works with TRUNK and the resent 2.1.5 release. I voiced this on IRC, but should mention it here... I've only cursorily reviewed the patch; regardless, I don't think it should be applied to trunk until after 2.2 is branched or released. I don't think any unnecessary infrastructure changes need to be applied at this point. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpsidey2we7i.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: development version suitable for user testing?
Gernot Hassenpflug [EMAIL PROTECTED] writes: I'd be happy to test the development version of GnuCash for debugging purposes, but am hesitant to do so (there is no debian or ubuntu package to make it easy) as I am not certain that it is intended for users to test it. From the documentation on the GnuCash website I see only some features and bug fixes, not really a summary of what is the difference between the unstable and stable release. Do the developers recommend ordinary users to try it out? Yes. 2.1.5 is release candidate 2 ... 2.2.0 is imminent. Please try it out, if possible. I'm not sure what you're expecting, but as to the differences between the stable (2.0.x) and unstable (2.1.x - 2.2) releases, I direct your attention to the What's New in GnuCash 2.1.5? section of the announcement at http://www.gnucash.org/#070702-2-1-5.news. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpCkrxmWxZei.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Re (IRC): 2.2.0 and auto-save
Christian Stimming [EMAIL PROTECTED] writes: Following this way of thought I would decide for choice #1, leave as-is for 2.2.0. What do the other developers say? I like option 3. The implemented auto-save doesn't behave in the conventional way (with a separate checkpoint file); it probably should before being enabled by default. Regardless, some will still want the feature, especially since we have an alternate mechanism for creating checkpoint files that could be used in the case of an undesirable autosave. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpueP0dYjdDC.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Comment on interface
JT Justman [EMAIL PROTECTED] writes: Vahur Lokk wrote: lease and thats it. In order to pick a vendor from my huge 4-vendor list I have to use search. First, its bit of an overkill and not very convenient. Second, there is not a way to see, who I actually have in my [...] Hi, Vahur! This is exactly what I've been wishing for, and the reason [...] Sometimes I can leave some windows open, which helps, but not to the point that it doesn't bug me. Speaking of bugs, see http://bugzilla.gnome.org/show_bug.cgi?id=101456. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpIZwH8R3GQd.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 2.1.5 Binary
NEMMERS, BRENT [EMAIL PROTECTED] writes: When will the 2.1.5 binary for windows be available? SourceForge only has the executable for 2.1.4. Zoltan Levardy [EMAIL PROTECTED] writes: i have found the link has not working (http://download.sourceforge.net/gnucash). This link was coming from the http://www.gnucash.org/#070702-2-1-5.news feed. Where is the latest windows setup file 2.15? http://lists.gnucash.org/pipermail/gnucash-devel/2007-July/020864.html -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgphkvq5ZP3lD.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Using gnome-doc-utils for help files
Pierre-Antoine Lacaze [EMAIL PROTECTED] writes: I'm beginning the French translation of Gnucash's help, and have been suggested that it would be a good move to look into converting gnucash-help to gnome-doc-utils [1]. g-d-u is supposedly the preferred way for documentation handling, and make use of po files. I more or less ported it already, and would like to know if there is a compelling reason not to move over. I fear myself with po files the lack of flexibility required in highly technical, country-specific documentation. For a bit more color, you and I discussed this on IRC [1], though the other day you came back and seemed to indicate that it didn't work out so well [2]. So, is that a compelling reason to not move over? In any case, can you please post a patch against the gnucash-docs sources that implements gnome-doc-utils? [1] http://lists.gnucash.org/logs/2007-07-02.html#T16:29:51 [2] http://lists.gnucash.org/logs/2007-07-03.html#T14:35:27 -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgp2lJbrInCEu.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: broken link
Derek Atkins [EMAIL PROTECTED] writes: Hmm, yeah, it looks like that URL should be more like: http://sourceforge.net/project/showfiles.php?group_id=192package_id=5582 Updated. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpZJmmRWMyGI.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Licensing clarification, updates
(Back in February...) Josh Sled [EMAIL PROTECTED] writes: Licensing - In new files (and old files related to this code that I hold copyright on), I've removed the or any later version clause. I have problems licensing under a license that I haven't read, or that can change in ways I disagree with. At some point I'll make this change for all source files I hold copyright on, and I intend to not use the clause on sources I (re)write in the future. Some of the core devs had an (off-list) discussion about this back at the time. The summary is: - we all agree it is unfortunate that the license for all the sources isn't identical; that was already (minorly) true before my changes. - a couple of us are not willing to license under or any later version. - no one really has any objection to a hypothetical OpenSSL exception. As per http://svn.gnucash.org/trac/changeset/16254: I've summarized the state of the LICENSEing at the top of the file. I've added specific text for the OpenSSL exception as derived from http://en.wikipedia.org/wiki/Openssl#The_exception. I've added this text to files I have copyright on that do not include the or any later version text. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpd4p1S2rtR5.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: small doc patch
Hale Boyes, Kevin [EMAIL PROTECTED] writes: $ cd gnucash-docs-trunk $ svn diff Index: guide/C/ch_capgain.xml === --- guide/C/ch_capgain.xml (revision 16247) +++ guide/C/ch_capgain.xml (working copy) @@ -59,7 +59,7 @@ titleEstimating Valuation/title paraAs mentioned in the introduction to this chapter, capital gains are -the profits received from the same of an asset. This section will describe +the profits received from the sale of an asset. This section will describe Applied r16259; thanks! (Attachments work better than in-lined patches, especially – as above – because of wrapping.) -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpOKT4utZc2j.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: QIF Import
Derek Atkins [EMAIL PROTECTED] writes: Unfortunately there is no QIF Spec per se, but a google for QIF Format should be useful. Mike... I recall wikipedia's entry on QIF as being pretty good, as well. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpBeC6AjzfuD.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: dogtail test suite status
ahmad sayed [EMAIL PROTECTED] writes: Waiting your comments :), I committed the code to the dogtail branch i created a new dir under src called src/test-dogtail it contains my up to date code. Sorry for the delay; I was out of town last week... I'm planning on reviewing progress later today. Unfortunately, I don't see any commits to the dogtail branch in svn. Do you get any errors when you do an `svn commit`? Did you `svn add` the src/test-dogtail directory? What does `svn status` say? -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpEz3ZvNXENa.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Licensing clarification, updates
Christian Stimming [EMAIL PROTECTED] writes: * In addition to this, contributions by the following devs are licensed under GNU GPL, Version 2, or (at your option) any later version: cstim, ..., and all source code files that contain this clause. I prefer the license to be attached to the file; at least as a level of indirection. E.g., the file could just say Licensed under GPLv2, OpenSSL exception (see LICENSE). I don't think it's as good to have an indexing license file that described all the individual source files, or tried to create classes by contributor. Also (or alternatively), couldn't we also say All contributions before [some date in the past] are licensed under GPLv2 or any later version? When thinking about the license on a per-contribution basis, I think the most precise wording could include the fact that you used to contribute code under GPLv2 or later, but then changed your mind at [some date in the past] and everything since then is GPLv2-only? I'm not sure to what end. The VC history contains this information, to some degree, as well. Also, I think I'd be interested to license my contributions under (brand-new) GPLv3 in addition to the common GPLv2 license. I think this could be added in the LICENSE file by stating something like In addition to this, contributions by ..., cstim, ... are licensed under GPLv3 as well. Should something like this rather be avoided, or would that be fine? What do the others plan so far? I think that sounds fine; I'd still modify the text of the files individually, as I said above. I've not had time to review the GPLv3 myself, yet. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpqbhQnn4Xv3.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Release Manager needed
Derek Atkins [EMAIL PROTECTED] writes: My only caveat is: s/make dist/make distcheck/ Whoops, yes, of course ... obviously, I don't actually do it myself well enough to know that. :/ -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpFhWFX92Gng.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: installation
(This really belongs on gnucash-user, so I've CC'ed it there instead.) Anna Ash [EMAIL PROTECTED] writes: I can't figure out how to install this program. I downloaded it and found it was some achieved/zipped files and got them unzipped but can't seem to locate an install file. Any information would be greatly appreciated. I'm assuming you're referring to GnuCash-2.2.0. If you're on Windows, you'll want to download and run the executable at http://downloads.sourceforge.net/gnucash/gnucash-2.2.0-setup.exe. If you're on unix, you'll want to wait until your distribution/vendor offers a pre-built package of Gnucash 2.2, and install it using your distribution's package manager. I'm not sure what you downloaded, since you didn't identify it at all, but if it's the sources, then it should have an INSTALL at the top. If you have the sources, it's possible to compile the software yourself (on either unix or Windows) ... more information on that can be found at http://wiki.gnucash.org/wiki/Building. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpBFwfzQBENM.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: dogtail test suite test harness
ahmad sayed [EMAIL PROTECTED] writes: 2 - I'm able to test the register and i compelete a smplified version of tutorial 1 and 2. This is great. :) the bad news is: 1 - In order to be able to access some components, I use some raw inputs, according to dogtail the raw input is to do mouse click using the coordinate, Like rawClick(wiget.position[0], widget.position[1]) (As Derek asked:) are these window x,y coordinates, or logical widget locations? 2 - I got a problem with expanding the tree in the account pages so i only could create an account like Expenses:Taxs only parent and child more account like Expense:Taxs:Insurance currently no luck with them Where does the problem lie? With dogtail, I imagine...? It seems somewhat important that we're able to test files as generated with our Common Accounts account-template. BTW: i tried to play with gnucash register code, and atk but i make a very slight progress, like making dogtail read the register as table but it will require a lot of time the register code is too big. Yeah. :( Feel free to completely ignore this, but maybe it makes sense for you to look at the 'register-rewrite' branch, and see if you can contribute at least a basic dogtail-based test using that register. It should be far easier, and hopefully we'll move to that codeline in the (near) future. you suggested some approach like Junit, I tried pyunit and it looks nice to me, do you have any issues regarding using it to organize our test cases. It looks like you've started down that path. Whatever you're comfortable using is good, but things that are established and will time (like python's `unittest` module) are always good to leverage. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpQIaySiouMB.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CSV Import Update
Benjamin Sperisen [EMAIL PROTECTED] writes: What can the importer do now? 4. It can handle three different column types: Amount, Date, and Description. The columns can be in any order. Other columns you may want to support: - transaction number - transaction identifier - comment It might be that the easiest thing to do is just concatenate some of those fields together into the memo of the resultant transaction, rather than try to get a 1-to-1 mapping to gnucash fields. 5. This is not necessarily a CSV import issue, but the date parsing function does not yet take into account the issue raised by Thomas (https://lists.gnucash.org/pipermail/gnucash-devel/2007-July/020954.html). I'm not sure if the mixed-separator issue is significant outside of QIF files, or otherwise wide-spread. I did notice that converting the txt-format downloads I can get from Bank of America (which look like `lynx -dump`ed versions of their html, honestly) into CSV left me with just 'mm/dd' dates (no year). That doesn't seem all that unreasonable, and should be supported as well. Problem 4 will largely take time, but if anyone has any CSV files that they'd like to try this with, feel free -- the code should be stable enough that it's not totally unusable at this point. As long as you Another thing I noticed with my manufactured CSV file was that some of the lines had '$'s before the value, and some had column-based credit/debit value distinctions; I could imagine other CSV-providers that used +/- for such a distinction. This might end up as an RFE building on this project, but handling these cases seems pretty important. encountered that before (though I could be wrong). I'll also have to learn some about regular expressions, as I know next to nothing about them, to add the functionality. FWIW, regexp is one of the most useful things I've ever learned, so don't hesitate! :) Anyway, that's where the code is and where it still needs to go. As always, let me know if you have any comments or suggestions! This is looking very good... very nice work, so far. :) -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpsUIhrzPrGu.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r16282 - gnucash/branches/csv-import - Fixed some bugs, attempted to get STF code working with goffice 0.2
Benjamin Sperisen [EMAIL PROTECTED] writes:
Trac: http://svn.gnucash.org/trac/changeset/16282
Modified: gnucash/branches/csv-import/src/import-export/csv/gnc-csv-import.c
===
--- gnucash/branches/csv-import/src/import-export/csv/gnc-csv-import.c
2007-07-08 18:42:22 UTC (rev 16281)
+++ gnucash/branches/csv-import/src/import-export/csv/gnc-csv-import.c
2007-07-08 20:21:49 UTC (rev 16282)
@@ -751,13 +754,8 @@
* user gives up. */
while(!((parse_data-error_lines == NULL) || user_canceled))
{
- /* TODO remove printfs */
- printf(start %d %d\n, g_list_length(parse_data-transactions),
- g_list_length(parse_data-error_lines));
- gnc_csv_preview_errors(preview);
- user_canceled = gnc_parse_to_trans(parse_data, account, TRUE);
- printf(end %d %d\n, g_list_length(parse_data-transactions),
- g_list_length(parse_data-error_lines));
A good alternative to printf is
g_(debug|message|info|warning|critical|error). They have the same
formatting/varags support as printf, but with conditional effect. And with
our logging framework [1], they can be made visible at (the start of) runtime
via
config, without re-compiling.
[1] http://cvs.gnucash.org/docs/HEAD/group__Logging.html
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgploaowSPw25.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: SQL Backend?
keith [EMAIL PROTECTED] writes: I know there was discussion on the list last year of a data model that was being tested in pg and mysql. But I haven't seen it yet. As Derek says, it appears not to have made it into the branch. (Unless is has some other sneaky name.) It looks like the table and column schema is encoded in the sources. http://svn.gnucash.org/trac/browser/gnucash/branches/gda-dev/src/backend/gda/gnc-transaction-gda.c#L73 -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpa9Zmwfmpw1.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: dogtail test suite test harness
ahmad sayed [EMAIL PROTECTED] writes: Josh Said: you suggested some approach like Junit, I tried pyunit and it looks nice to me, do you have any issues regarding using it to organize our test cases. It looks like you've started down that path. Whatever you're comfortable using is good, but things that are established and will time (like python's `unittest` module) are always good to leverage. (good to leverag) sorry I didn't get the meaning of this expression, i hope it means that you agree with me on using pyunit :). Yes. :) -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpmBY9gjMkbW.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: SQL Backend?
Albert Lash [EMAIL PROTECTED] writes: Am I correct in my assumption that this code isn't actually used with the current, non-SQL, backend? That's right; each backend is basically stand-alone. Of course it shares a rough outline with the runtime object model and XML data-model, just by nature. Thoughts? I'm doing a bunch of work on pbooks right now and if any of it can benefit gnucash, I'll try to make it to happen. If you see concrete opportunities for sharing, by all means write it up. I'm sure it's going to come down to the models being just different enough, either because of historical warts or just reasonably different application functionality, that they data models will want to be different. Not to discourage, but it feels like an extra level of effort to try to keep two application's data models in some sort of sync. At the same time, I'd be really interested to know how different from the XRBL model gnucash is. I could just look at the specs, I guess. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpSr8JdDrfQ0.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: data file differences in 2.2
Hale Boyes, Kevin [EMAIL PROTECTED] writes: So, I'd say that once you've saved your data file in 2.2.0 you should not go back to 2.0.5 and save there. This has nothing to do with the data file change noted in the release notes (around scheduled transactions). Yea ... we should obviously make it stronger and more comprehensive for 2.2.1. Thanks for the legwork testing the back and forth between the versions! :) -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpqOmZz4ZSSq.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: updated gnucash's french translation : fr.po
Christian Stimming [EMAIL PROTECTED] writes: One question: #. %s is the name of the weekday #: ../src/engine/FreqSpec.c:829 #, c-format msgid Bi-Weekly, %ss If second 's' is here to use the plural form, could you add a comment for translators? Oops. @jsled: If this should indeed be the plural form of the weekday, then this string is fundamentally broken from an i18n POV - you can't do it this simple in languages other than english. Many weekdays have plural forms that are built differently from each other in other languages. This string should be changed into Bi-Weekly, each %s Does not the translator effect the whole string? I was thinking that the translator would (not) use the trailing-s version depending on if it was appropriate for the translation. I could certainly add more detail in comments; I've started to do that with strings I've added recently. FWIW, the FreqSpec code is dead, and will be removed at some point. At the same time, there's basically-equivalent code in Recurrence, now. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpnpFwdAGS9C.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
FAQ update: request for help
The FAQ http://wiki.gnucash.org/wiki/FAQ has a bit of cruft, and hasn't
really gained a bunch of new items that we've seen with the 2.2 and even the
2.0 releases.
I sketched out a set of new FAQ entries. I'm looking for review of things I
might have missed, as well, as help in generating the copy/text of the
Answer. In some cases I've noted the dates of recent -user threads (see the
archives at http://lists.gnucash.org/pipermail/gnucash-user/) that might be
a good starting point for summarization.
If you have a few minutes to help, please pick one and respond. Even better,
please update the FAQ and just say that you've done so. :)
- to add
- Reply-To munging
- Database backend/branch status.
- Include history re: 1.8, PG backend, c.
- I've lost my account tree page?!
- File New New Account Page
- password protection of datafile?
- mostly in
http://wiki.gnucash.org/wiki/FAQ#Q:_Is_it_possible_to_provide_security_for_GC_data_using_CFS.2C_etc..3F,
but no one is going to phrase their question that way...
- The Register and CJK
- summarize 18-Jul thread, and others.
- ${something_bad} happened. :( How can I debug?
- run in terminal
- console output
- gnucash.trace (location difference between 'nix/osx and windows)
- reordering accounts?
- parent/child vs. sibling order
- delays in transfer between accounts
- summarize 06-Jul thread
- HOWTO: Class accounting
- summarize 02-Jul thread
- HOWTO: VAT
- this seems to be a permathread, and is already somewhat covered in the
FAQ.
- fix the ISO stock FAQ re:
- say private [stock] and options somewhere
- note specifically that you can type over the combobox to create new
types like private.
- Multiple bills with one Payment?
- Just use process payment. Applied in FIFO order. c.
- file extensions
- .xac (though same as the backups), .gnucash, .gnc.
- shared-mime-info registration
- to remove
- gnome2-related entries
- (most) gnucash-1.8-related entries
- to move
- a bunch of §4 (Using GnuCash) questions should be in §7 (Accounting).
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgpiVGl3XTHz0.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: autopackage [was: Hi Guys]
Daniel James [EMAIL PROTECTED] writes: Just wondering if it would be possible for you guys to provide .autopackage files for gnucash for linux. I do plan on downloading and compiling anyway, but I'd love it if I could just double-click ;) (You might want to be careful with your subject line ... this one looks basically identical to other spam in the moderation queue.) We welcome the contribution of a (maintained) autopackage control file; we've had a few requests identical to this one, but no contribution. I note that we do have binary relocation support, from the 'BinReloc' package; c.f. http://svn.gnucash.org/trac/changeset/14862. I believe some of the motivation for this was autopackage. (I'm personally sympathetic to the idea that autopackage is ... broken. Still, I'd happily commit such a contribution.) -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpsgqHMX7kGj.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: SQL Backend?
Albert Lash [EMAIL PROTECTED] writes: That's right; each backend is basically stand-alone. Of course it shares a rough outline with the runtime object model and XML data-model, just by nature. Hmm, I'm a little confused now. The code referenced earlier had to do with GDM, right? And GDM was replaced by QOF? Or is it that they two are different, QOF is used for managing an XML flat file database, and GDM is used for SQL connectivity? I was thinking that QOF could be connected to a SQL backend via ODBC or something. (Not GDM... GDA, the GNOME Data Access layer. :) QOF is the Query Object Framework. It is, roughly: - a C-based object-model like thing (similar to gobject) - a lot of app utility code (similar to some of glib) - a facility for constructing queries that can be evaluated over the in-memory object graph, or translated into a form appropriate for a backend (such as a SQL-speaking relational DB). - a neutral backend layer, allowing a QOF object graph to be persisted either because of runtime object-field update events (i.., mutate the database bit by bit as things change), or on request (i.e., serialize the whole object graph to a file). We currently have a few backends: - src/backend/file: the gnucash XML file backend. - src/backend/postgres/: the historical gnucash PG DB backend. - src/backend/gda/: the in-development gnucash GDA-based DB backend in http://svn.gnucash.org/repo/gnucash/branches/gda-dev/. - lib/libqof/backend/file/: the QOF-provided, application-generic QOF Serialization Format (QSF) backend. - src/backend/dwi/: Linas' DWI/DUI-based backend; not used. Here's some links I found helpful in researching XBRL: [snip] Thanks for those. Is there a basic description of the GnuCash data model around anywhere? Is this information only accessible in the code at the moment? I've read about the accounts, transactions, and splits, and these coincide fairly well with pbooks' accounts, entries, entry_amounts, and transactions. http://svn.gnucash.org/docs/HEAD/ is the root of nightly-generated runs of doxygen over the source tree. http://svn.gnucash.org/docs/HEAD/group__Engine.html looks like a good entry point to talking about the Engine object model. If you grok XML and Relax-NG, then the XML file schema http://svn.gnucash.org/repo/gnucash/trunk/src/doc/xml/gnucash-v2.rnc might be useful ... the structure there maps pretty directly to the object model. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpGsgjEeBg8n.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: dogtail test suite test harness
Derek Atkins [EMAIL PROTECTED] writes: PS: I realize it might be easier now to have all your classes in a single Gnucash.py, but eventually I think it might be better to separate the various classes into separate files, like Register.py, AccountTree.py, NewAccountDialog.py, PriceDialog.py, etc. But this doesn't have to happen right away. Ah, Derek, one thing about this I forgot when we talked on irc ... In python, files correspond to modules; there's no ability to group multiple files into the same module/namespace/package. Thus, the file NewAccountDialog.py, e.g.: class NewAccountDialog (Dialog): # ... ...is a NewAccountDialog module containing the NewAccountDialog class. It's referenced both other files as: import NewAccountDialog foo = NewAccountDialog.NewAccountDialog() If each class corresponds to a file corresponds to a module, it can be very verbose. There is a different form of the import statement, like: # from $module import $name from NewAccountDialog import NewAccountDialog foo = NewAccountDialog() But it's frowned upon. There's also: import NewAccountDialog as NAD foo = NAD.NewAccountDialog() But it not really great either. A different approach is to separate the classes into related groups such as dialogs.py or register.py. Then the fully-qualified names are more manageable: import dialogs, register new_account = dialogs.NewAccountDialog() basic = register.BasicViewRegister() # ... We stay pythonic, but the code gets factored a bit better. Hopefully this is a good middle-ground. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpjuJMHWU0KT.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC Wiki modification
Dan Widyono [EMAIL PROTECTED] writes: Is the main wiki page locked from general edits? Yes. Would someone please modify the Building section such that RH-based distros are on their own page which can be modified? I'd like to insert updated info for RHEL5 / SL5 RedHat (http://wiki.gnucash.org/wiki/index.php?title=RedHataction=edit) is linked from the main page, but does not yet exist; go right ahead. It'd be great if you could incorporate those two existing links that are now a sub-bullet point on the front page; when I (or whoever) sees the changes in [[Recent Changes]], We'll cleanup the front page. Thanks! -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpESzgIwRIfy.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compiling Gnucash 2.2.0 on Solaris 10 x86 using GCC - error
Derek Atkins [EMAIL PROTECTED] writes:
Bugs with gtk or bugs with gnucash?
Bugs against gnucash for using deprecated widgets.
Yes, we still need to remove more of the deprecated objects.
Unfortunately there really isn't a good replacement for GtkCList.
The GtkTreeView just is SO MUCH more damn complicated and there's
not really a simple class similar to the old CList to migrate to.
The Gtk{List,Tree}Store and GtkTreeView isn't that much more complicated.
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgpNBBBFbS6eZ.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compiling Gnucash 2.2.0 on Solaris 10 x86 using GCC - error
Derek Atkins [EMAIL PROTECTED] writes: What version of gtk2 do you have? What configure arguments did you give? This error implies that it can't find GtkCList. This is a deprecated object but should still be available. Right ... IIRC, there's a compile-time option to gtk that doesn't build these deprecated classes. We do (unfortunately) still require them; we should really start filing bugs about that fact. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpX6J0rXVPFQ.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Small feature request: better tab behavior in Split transactions
Christopher Blunck [EMAIL PROTECTED] writes: seen in step #5. If you press tab on step #5 and you are brought to a new subtransaction line why doesn't that ALWAYS happen? Because there's a bug in the tab handling. I believe it's already been filed, but I don't have time at present to find it at http://bugzilla.gnome.org/browse.cgi?product=GnuCash. The bottom line is that there doesn't appear to be a keyboard only way of journalling a split transaction, and that's a huge pain in the neck when I'm journalling my credit card statement (it has over 200 transactions sometimes). Going from keyboard to mouse and then back to keyboard significantly slows me down. I regularly only use the keyboard. With auto-split mode and a bit of extra tab-/arrow-ing after it resets back up to the description, I get by. It is annoying that the focus resets to the description, however. GnuCash 1.x didn't have this behavior. Please help restore the GnuCash 1.x behavior of tabs in split transactions. What you're seeing isn't an intentional change in behavior so much as a side effect of a change in an overly-complex piece of GnuCash (the register). I'm not saying the bug shouldn't get fixed or the behavior shouldn't change, of course. But if you're conceiving of it as an intentional change we can revert, you're wrong. Issue #2: Cancel button in a split transaction doesn't work. The Cancel button in a transaction works exactly as it should: it cancels editing the Transaction. (A bit of clarification: a Transaction contains Splits (lines). All Transactions are split transactions, even if we only show one of the Splits (i.e., in Basic register mode)). Issue #3: Blank doesn't blank a transaction. It takes you to the bottom of the ledger. I understand that this is intuitive to you Given that we have the following concepts: - Cancel Transaction (being edited) - Enter Transaction (being edited) - Delete Transaction - Delete Split (in Transaction) - Remove (all) Transaction Splits - Blank (goto the Blank Transaction) What other names would you suggest? Blank could be safely renamed New Transaction, I think. I think the icon is appropriate, but I'd agree the name there is not as unambiguous as it could be. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpKroHsEgFru.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: PDF of documentation
dave boland [EMAIL PROTECTED] writes: Would it be possible to take the existing documentation and offer it in a pdf file? There's a PDF of the 1.8 documentation available at http://www.gnucash.org/docs.phtml. The overall content hasn't changed all that much for 2.0 (or 2.2), so it's still quite useful. I've added support for 'make pdf' target to the gnucash-docs build files, and while it basically generates a PDF, it looks horrible ... I wouldn't want to distribute it. It'd be great if someone could figure out the incantations to turn docbook into good-looking PDF and contribute them, ideally as a patch against the docs of http://svn.gnucash.org/repo/gnucash-docs/trunk/. Also, does anyone know if a book on gnuCash is in the future? The Tutorial and Concepts Guide started off as a book, as I understand it. I've not heard any plans like those recently. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpplk4X3bFB2.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Some Japanese translation: ja.po
Hiroto Kagotani [EMAIL PROTECTED] writes:
By the way, is there any standard way to translate predefined account
set files in accounts dir? In particular, can I add Japanese specific
accounts here and how can I define act:id elements?
accounts/${langdir}/ contains the translations available for the account
trees, including entirely new, perhaps locale-specific account trees (for
example accounts/de_DE/acctchrt_skr03.gnucash-xea). All installed files are
enumerated at run time to build the dialog's contents, so simply creating a
new file (following the same file-name conventions) and adding it to the
relevant Makefile.am for distribution is sufficient.
I note that there's already an accounts/ja_JP.EUC/, which appears to contain
the common account hierarchy encoded in EUC-JP, but for some reason it's
not mentioned/distributed in the accounts/Makefile.am.
To generate an ID, the most straightforward way is:
[EMAIL PROTECTED] [~]$ uuidgen | tr -d -
15fd93733e2549bea5027450082f9b27
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgpO7mpK9PPHc.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Some Japanese translation: ja.po
Derek Atkins [EMAIL PROTECTED] writes:
The best way I think to generate an account tree for the accounts
hierarchy:
1) create a tree in gnucash
2) save it
Or {File Export Export Accounts}.
I think it's probably much easier (and faster) to do it this way than
to create all the XML by hand.
Probably, yeah.
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgpoeRLGoDaRY.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: startup delay
Herbert Thoma [EMAIL PROTECTED] writes: OK, this itch was sufficiently annoying to scratch (and the scratching was easy enough to do). [...] Please review. Reviewed and applied, r16378. Thanks! :) -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpW4gUM6fihT.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: startup delay
Derek Atkins [EMAIL PROTECTED] writes: I haven't looked at this patch, yet, but does it also work in the case of --nofile and in the case of the first-run dialog (where there IS no main window, just a dialog about whether to import from QIF or run the New File Hierarchy)? Yes and yes. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpVslQpbnvFa.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: startup delay
Geert Janssens [EMAIL PROTECTED] writes: Just out of curiosity, since this is not directly Splash screen related: What happens when Gnucash is already open, and the user selects Open... to open another book ? Will the old book remain open until the new one is fully loaded, or is the old book closed and no new window appears before all the reports on the new one are loaded ? The existing qof session is closed, the window is cleared but retained, and its progress bar is used for the load progress. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpm6kqnGOUzX.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Intro + a bug
Mike or Penny Novack [EMAIL PROTECTED] writes:
Meanwhile, I understand that close the books isn't working. If whoever
is the developer on that portion wants a hand, please get in touch.
The developer who started that work hasn't had a lot of time for GnuCash in
the last few years. I really hope he does respond, but I don't feel out of
order responding on his behalf.
There are two approaches to book closing:
One approach has a structure either above or within the current top-level
data structure of a book. This structure is probably an archive section
that contains transaction/history information outside of the current
financial period. All of the rest of the application (file load/save; the
UI, generally; reports; c.) would need to be extended to support this
indirection.
Another approach would be more procedural, simply creating a new, standalone
datafile for the new period. While we already have the functionality to
export the existing account hierarchy (only and alone), a welcome
extension/variant of that export would probably also...
1/ allow the user to ignore obsolete accounts that the user doesn't want to
carry forward...
2/ create appropriate opening-balance Equity transactions for the rest of the
{Asset, Liability} accounts.
3/ carry relevant commodities and price-db entries forward.
4/ carry relevant (user-selectable) business items (customers,
vendors; unpaid invoices, c.) forward.
I am not in a position to offer to take over since I can't make a long
term commitment not to return to paid work should a tempting offer
arrive* but at the moment have time available.
Well-formed patches that improve the system are welcome regardless of
long-term commitments.
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgpAVgjszlW2N.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Intro + a bug
Mike or Penny Novack [EMAIL PROTECTED] writes: There are two approaches to book closing: Maybe stop right there. As soon as there appear to be difficulties with the only approaches step back one level of the process and maybe more alternatives will appear. I wasn't really saying there were difficulties with either. Or, really, that those were the only approaches, though I did use the definite article. Of course, looking at the idealized solution is a good idea... In other words, what must close the books DO. Let's consider what an [...] OK -- accountants reading this, what have I left out of the close the books process? (I am not an accountant). Consider all the options which would be This is closer to what I outlined as the first option, and what I believe we think of as the right way to do it. I mention the second option because it's far simpler to implement, and still solves a valid use-case for many people: keeping tidy, small files for the current accounting period, allowing that historical information would be in a separate datafile. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgp25xnGHu8hi.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Intro + a bug
Mike or Penny Novack [EMAIL PROTECTED] writes: I have asked there whether this problem is top level directory name or anywhere in the path because if the former, there may be a (relatively) easy fix. GnuCash is the first open app for Windows that I have encountered so far that did NOT create a directory in the user data directory to contain all its configuration data but instead drops all of these directories (and file) separately into the user data directory without grouping them into one subdirectory (increases the risk of a name conflict problem and complicates backup*). Uh, I'm not sure exactly what you mean, but GnuCash does (should) create a $HOME/.gnucash/ dir for its own storage, as well as leveraging the $HOME/.gconf/ storage we've talked about. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpllu5EYmpE9.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Release Manager needed
Andreas Köhler [EMAIL PROTECTED] writes: So, I would like to offer myself as a potential successor of yours as Release Manager. I have not yet added any great feature to GnuCash and I think you'd do a great job, Andreas ... fwiw, you have my support. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpLGBVc57snC.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Intro + a bug
Mike or Penny Novack [EMAIL PROTECTED] writes: account name with an asterisk in it. Can anybody here identify the address of the team working on gnome for Windows because they should be made aware that there is a problem affecting their project. The implication is that the problem isn't FIXABLE (can't make GnuCash work completely properly for all legal Windows user account names) but Andreas already pointed you to http://bugzilla.gnome.org/show_bug.cgi?id=161209; the GNOME team is aware of the problem. that doesn't mean it should be no action. One possibility would be for the first time routine to check whether the directory it is being [...snip...] (Mike, you really don't need to reiterate all this stuff in every email you send.) We'll definitely add something to the 2.2.1 release notes, and if someone gets the desire, they'll add code (or contribute a patch) to display a dialog as you suggest during startup. If you want a more formal way to track the status of those changes, please file a bug at http://bugzilla.gnome.org/browse.cgi?product=GnuCash. In fact, that probably should be done anyways. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpIGdTanTllo.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Feature request: process multiple invoice with single payment
John Z. Bohach [EMAIL PROTECTED] writes:
But documentation enhancements aside, I think others have also expressed
an interest in not always having to do a 'find ...'
{invoice,customer,etc.} and just rather have a drop down list show
everything for that category, but that's getting off on a different
topic.
This is http://bugzilla.gnome.org/show_bug.cgi?id=101456.
Heck, I've even thought of fixing that recently, and I don't use the business
features. :)
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgp0curwjqqNy.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compiling gnucash on Windows XP
Stephen Grant Brown [EMAIL PROTECTED] writes: It runs under one administrator account but not a second administrator account. Does the second account user name contain spaces, '', or any other non-[a-zA-Z0-9] characters? -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgphNd8TOxxpw.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[URL] GnuCash in The Age
A short writeup in their tech section. Nifty. http://www.theage.com.au/news/home-office/something-gnu-for-coin-counting/2007/08/11/1186530667494.html -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpm9PY2d57GK.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gsoc code license
ahmad sayed [EMAIL PROTECTED] writes:
There is request from google to upload our soc code to a specific code
repository, so I confirm that all my files indicate that it is under Gnu
General Public License, sorry not sure how important this issue is, but i
think other gnucash SOC projects should consider this issue also.
http://groups.google.com/group/google-summer-of-code-announce/web/how-to-provide-google-with-sample-code
It looks like a...
$ svn diff -r $branch_point:HEAD
http://svn.gnucash.org/repo/gnucash/branches/${branch} soc.diff
Should work alright, so long as it records newly-created files, which I
believe it does. In order to determine the ${branch_point} revision
number...
$ svn log --stop-on-copy
http://svn.gnucash.org/repo/gnucash/branches/${branch}
Should do the trick; the first revision will be the one that created the
branch.
Also, yes, all sources should be under the GPL.
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgplrRR7YfCn0.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gsoc code license
ahmad sayed [EMAIL PROTECTED] writes: Sorry Josh I might be not clear in my previous Email, the specific repository I mentioned in my Email, is the repository provided by Google itself. No, as per that last link, there's no requirement to submit the code to the Google SVN repository specifically, but only to provide a tarball containing the changes that you've made via the Downloads area of the SoC webapp. The commands I gave against the gnucash repository should help you create that tarball. here is the license issue http://code.google.com/multiple_licenses.html I'm not quite sure what the issue is. GnuCash is licensed under the GPL, and as I understand it, you're contributing your changes under the GPL as well. So, there's no multiple-license issue. also here more details about the repository http://groups.google.com/group/google-summer-of-code-announce/web/how-to-provide-google-with-sample-code All students will need to add a zipped tarball, which can include source files, a single .diff file, multiple .diff files, binary files, etc., to the Downloads section of the Google Summer of Code project. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpmWnfl6Ph9g.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: SLR bug in 2.2?
Tim Wunder [EMAIL PROTECTED] writes: In 2.0.x, if the Since Last Run druid is canceled at any time, all transactions are canceled. In 2.2 it seems that if you cancel the SLR after reviewing the created transactions, the auto created transactions are not canceled (and the book gets dirtied). Is this intended behavior? It strikes me as a bug. Cancel from the SLR, be it at the initial screen or during review, should cancel all SXs. It is the intended behavior. There is no longer a review step as part of the multi-step druid, but instead a single post-SLR way to review (and modify) which transactions were created. In truth, that review page also dirtied the book, while breaking conventions about how the Cancel operation on a Druid should function, as it needed to actually create the transactions in order to review them, there. I considered that the bigger failing. Hopefully the register-rerewrite branch will make it easier to have a register of not-actually-created transactions, which would make it possible to restore the review functionality. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpaXEHCQ78R6.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Can someone help me make the SLR dialog do what I want?
Tim Wunder [EMAIL PROTECTED] writes:
That was easy and I liked the result. Encouraged, I sought to reading more of
the code to see where it builds the list of SXs that get displayed. I want
only SXs that will be in a Reminder, To Be Created, or Automatically Created
state to display. I have a lot of SXs and having those that are neither ready
to be created nor reminders adds unwanted clutter for me.
Most of the code in dialog-sx-since-last-run.c adapts the GncSxInstances
model into a GtkTreeModel, for direct use in the GtkTreeView which is the
(new) SLR dialog.
You may be better served by using a GtkTreeModelFilter to {dis,en}able the
rows you want. This could be exposed via a new control in the dialog, maybe
with default settings in preferences ... I'm moderately opposed to user prefs
for this, though maybe we can hide them in an Advanced section of SX prefs,
or something.
P.S. Another thought I had was to display the SXs in a color-coded manner so
that Automatics could be grey'd (I think the State column is grey'd out
already), the Reminders could be yellow, the To Be Created without variables
could be dark green while the To Be Created that have variables could be
displayd light green. (But that's just a crazy idea my left brain cell
had...)
Color coding is always tricky ... in cultural significance ... in how it
interacts with custom gtk themes (dark-green on black = unreadable) ... the
HIG.
It might be better if they were instead three distinct super-trees (i.e., up
at the root level). Or if the dialog could be pivoted around the two
display modes (grouped by State vs. integrated by SX).
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgpHKr6QitqIV.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Can someone help me make the SLR dialog do what I want?
Tim Wunder [EMAIL PROTECTED] writes:
OK... So I :
Filter specific rows, based on data from a visible column, a column
storing
booleans indicating whether the row should be filtered or not, or based on
the return value of a visible function, which gets a model, iter and
user_data and returns a boolean indicating whether the row should be filtered
or not.
Where do I do this filtering? I guess I'd need to create some sort of
visible
function that would make visible that which I want to filter???
Right ... well... you'll want to make that which you want to filter
*invisible*, but... ;)
When you create the GtkTreeModelFilter, you provide a function that fits the
signature of GtkTreeModelFilterVisibleFunc [1]. That is, make a new function
that has the same return value and arguments, and obeys the semantics
defined, then just use it's name to pass a pointer to the function for the
filtering algorithm to invoke later. Something like:
static gboolean
_gnc_sxslr_filter_func(GtkTreeModel *model, GtkTreeIter *iter, gpointer
data)
{
// filters out even rows
// (I made up the function name; this is all handwavy... --jsled)
gboolean is_even_row = gtk_tree_iter_get_row_number(model, iter) % 2 ==
0;
return !is_even_row;
}
// [...]
GtkTreeModel *filtered_model = gtk_tree_model_filter_new(existing_model,
NULL);
gtk_tree_model_filter_set_visible_func(filtered_model,
_gnc_sxslr_filter_func, NULL, NULL);
This is very similar to the use of an Interface in object-oriented languages
... the function pointer can be thought of as a functional interface.
And WTF is
an iter?
It represents a particular row in a particular model. The 4th paragraph of
[2] has a bit more color.
Generally, you'll want to read [3] to get a sense of how the TreeModel and
TreeView (and the rest of the related classes/types) interact. The design is
non-trival, but I don't really consider it overly complex, either.
[1]
http://library.gnome.org/devel/gtk/unstable/GtkTreeModelFilter.html#GtkTreeModelFilterVisibleFunc
[2] http://library.gnome.org/devel/gtk/unstable/GtkTreeModel.html#id3511622
[3] http://library.gnome.org/devel/gtk/unstable/TreeWidget.html
(All this is in your local devhelp, too.)
Color coding is always tricky ... in cultural significance ... in how it
[...]
Yeah, I know. But it would look purdy if it had colors. ;)
Heh. :)
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgpgxrjZKMMw6.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GNUCash 2.2.1 Startup Time under Windows Vista
Stephen Grant Brown [EMAIL PROTECTED] writes: When I start a new file, how do I populate it with a basic set of accounts? File New New Account Hierarchy (from the Accounts tab). -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgp0bnZPP01eh.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: External App connection to a GnuCash file
Daniel Espinosa [EMAIL PROTECTED] writes: Why I have an error message for the file /usr/local/include/gnucash/qofutil.h in the line: # error No scanf format string is known for LLD. Fix your ../configure so that the correct one is detected! The actual code in qofutil.h file is: Did you include a config.h, which might define one of those HAVE_... values? What/how are you building your sources? What are the steps to open a Session/Book in QOF? Take a look at some of the test files. Try src/backend/file/test/test-load-xml2.c I have the following code: I think that's roughly correct. Are there any Tutorial to use GnuCash's QOF? Not as such. There's plenty of documentation in the code, and there's bunches of GnuCash code that uses QOF, of course. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgp5imQNqdJDH.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: External App connection to a GnuCash file
Daniel Espinosa [EMAIL PROTECTED] writes: I found a macro in /macros/legacy_macros.m4 witch test for sscanf to support %lld (long long decimal integer) if so defines HAVE_SCANF_LLD. I think this is supported in recent gcc versions, then I can safetly define it in configure.in or remove this test in /lib/libqof/qof/qofutil.h. I'm not 100% sure about the provenance of that code, but I'm pretty sure it should not be removed. Well as result of this test program, I'll try to add the missing functions for GncBook and some documentation trying to keep as simple as possible the process to load a book and close it. Which functions are missing? -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgp5d8B2Wjb0z.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Questions about gnuCash backend access
Daniel Espinosa [EMAIL PROTECTED] writes: Well I still wait for my patch to be applied to QofCollection (see bug #453502) and wants to alling the current API convention to GObject's one (see bug #470788). (alling isn't an English word. What do you mean?) Regardless, there's no *requirement* that we change the convention. They're just that ... conventions. At the same time, most of us do want to change the names and what not, but there are better and worse times to do it. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgp0nyZxxgn2r.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: External App connection to a GnuCash file
Daniel Espinosa [EMAIL PROTECTED] writes: I found a some macros used in GnuCash's configure.in file, and I'll trying to add to my program in order to fix this error, does any know how can I do this? Add them to your program's configure.in? Or, if you don't need/want the portability that auto* provides, just figure out what the correct HAVE_[...] value for your machine is and add it to a manually-maintained config.h. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpwCqmLZymir.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Questions about gnuCash backend access
Daniel Espinosa [EMAIL PROTECTED] writes: QOF headers has a lot of coments pointing potencial bugs or even actual bugs Can I add this as bugs in bugzilla? I'm not sure what the advantage would be to having them either in two places (the comment and bugzilla) or one place (bugzilla) which is separate from the code. If you want to submit a patch that addresses a bug, it might be good to create a bugzilla entry as a place to attach the patch ... but mailing it to gnucash-devel is probably just as good. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpRg6fI0oKZZ.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Dogtail UI Harness Status
ahmad sayed [EMAIL PROTECTED] writes: In this phase of SOC the following updates done to the Dogtail UI Harness project, the status as usual is mix of bad and good news. Ahmad... Congrats on a modestly successful Summer of Code project. I'm sure that there's good and bad parts, but that's always the case. :) However, it looks like we have both a framework for running dogtail-based tests, and a whole suite of code for interacting with GnuCash and exercising parts of the user interface. :) If I wanted to add a test for the Scheduled Transaction subsystem ... let's say consisting of: 1/ creating a new Scheduled Transaction with given parameters. 2/ running the Since Last Run dialog. 3/ inspecting a value in the tree view/model. 4/ manipulating the tree view; closing the dialog. 5/ re-opening the Since Last Run dialog. 6/ inspecting a value in the tree view/model. ... how would I go about it? What would I want to add or extend, and in what files. How to invoke just that test to try it out? I guess I'm looking for a bit of high-level documentation. I'm sure I can figure it out if I spend enough time with the code, but something short that points me in the right direction would be great. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpGAvmQYJPzH.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CSV Importer
Benjamin Sperisen [EMAIL PROTECTED] writes: Anyway, most of what I've done has been to address the shortcomings discussed earlier. Benjamin, congrats on a pretty successful Summer of Code project. The importer is looking (and working) pretty well. First, I've reworked the internal error handling code so that, if there are errors, a new column to the right is created listing the errors on each particular row. For example, if a row has abc in its Deposit column, it will put Deposit column could not be understood in the Errors column for that row. I noticed that in my test file, the only regular line in error was a heading line. It'd be nice to have an option of the form ignore file's header line. (Even better, it'd be good to do default column-type assignments based on the contents of that header line. ;) Secondarily, it'd be nice – in the error handling page – to be able to ignore a line in error, easily. It'd be nice to support both the transaction and post date in the importer, since the engine/model does support both, even if the register UI doesn't, right now. Also, I notice the first stage after the file parsing – perhaps part of the Generic Importer, though – is an account tree/selection dialog labeled: Please select or create an apropriate GnuCash account for: ... obviously, it'd be nice if the thought was finished about what account I'm supposed to be selecting for. Second, fixed-width files are now supported. The interface is actually virtually identical to Gnumeric's, as I merged their code into mine, particularly for the context menu for column merging. I couldn't figure this out at all... I couldn't see how to mark the boundaries of columns for a fixed-width file. As well, the lines in my fixed-width file were pretty long, which made the dialog open way too wide... 1.5 screens wide, in fact. :( Were there some test data files that you were using? Are those checked in anywhere? I'll see if I can add mine, after I clean them up, as well. During the fall, I would like to keep working on the importer, even though I won't be able to work quite as much because of school. The next feature I'd like to implement is actual editing within the dialog of data (so that users don't have to go back and manually edit it in a spreadsheet, save and reimport). Nifty. I hope you're able to find the time to continue to work on this... I would also like to thank you, Josh and Christian, as well as the rest of the GnuCash community, for all of your help and guidance over the summer! This was definitely a great learning experience in many practical aspects of open source and software development in general. I have really enjoyed working with all of you and hope to continue in the future. I'm glad you found it worthwhile. Thank you for sticking with it, and getting a nice new feature added to GnuCash! :) -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpzwZFwyv0Od.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Copyright Notice
Dominic Edmonds [EMAIL PROTECTED] writes: On http://www.gnucash.org/index.phtml it shows (c) 2001-2006; surely 2001-2007. Updated; thanks. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpWnim5Sr4rQ.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scheduled Transactions rewrite
Andrew Duggan [EMAIL PROTECTED] writes: Nicely done. The new since last run dialog is really nice. Great job. Thank you. :) -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpRwcWUWexmN.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash help/tutorial/build
Anti Kutoja [EMAIL PROTECTED] writes: I am really sorry to bother you with this, you must enough on your plates as it is, but I am at my wit's end and have not been able to find answers anywhere. Did you search the mailing list? Or basically look at the wiki? I downloaded and installed the docs but still no joy. Did you install the gnucash-docs package? When you contact your distro for support, what do they say? I then downloaded gnucash 2.2 and tried to build and install it myself. The ./configure fails saying it cannot find libgoffice-0.4, 0.3 and -1. I have libgoffice-1.so.2.0.1 in /opt/gnome/lib which is the same place as the libglade that configure does find. You probably need to install -devel packages, such as goffice-devel; for all the dependencies. (Generally, configure looks for pkg-config control files (.pc files), not the shared library itself.) But, you should just install Rauch Christan's RPMs. See http://wiki.gnucash.org/wiki/SuSE. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgp5qqrt8wV91.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash loading
David Dampier [EMAIL PROTECTED] writes: I have downloaded Source code, Windows binary. I am running Ubuntu. How I install what I have downloaded? Is it the proper download for Ubuntu or should I have downloaded something else. No. Install GnuCash through Ubuntu's package manager ... aptitude or synaptic or whatever it is (I'm not an Ubuntu user, myself). Depending on which version of 'buntu you're using, different versions might be available: http://packages.ubuntu.com/cgi-bin/search_packages.pl?searchon=namesversion=allexact=1keywords=gnucash. Unfortunately, it doesn't appear that 2.2 is available on any of them, yet. :/ -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpo1gypmziSM.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: Enable non-capitalized wiki pages?
Derek Atkins [EMAIL PROTECTED] writes: Are we sure we want to live with that? Are you willing to go through each page and check all the links and make sure none got broken? The vast majority of links won't be broken. How about we just fix broken links as we come across them? -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpDr68HZZpe9.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r16543 - gnucash/branches/gda-dev/src - Make GDA backend (sqlite) the default if file: or no access method is
Phil Longstaff [EMAIL PROTECTED] writes: Yeah, we should probably fix this.. Or add other File - Open methods to let the user choose the specific version. I have a modified version of src/gnome-utils/gnc-file.c which allows you to select xml: The gtk_file_chooser returns either the selected uri (with This inverse quoting style is really hard to follow. :/ BTW, what is the qsf backend? It seems to exist independent of the XML backend but also processes XML files. QSF is the QOF Serialization Format. It's a datatype-focused, domain-agnostic way to generically serialize a QOF object graph... going off of memory, it's something like: object guid./guid integer name=id1/integer string name=nameFoo/string boolean name=isTruefalse/boolean !-- ... -- /object It's exactly the opposite of what makes XML useful, by focusing on datatypes, instead of field labels and semantics. There is some QSF export of business objects, and a disabled menu option to QSF export the account tree + opening balances. There is a disabled menu option to QSF import said data, with some abstract/generic mapper that never seemed to work — IIRC, it would crash randomly, and I think if it does succeed it might corrupt the objects. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpK3oWcDvjII.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
Chris Shoemaker [EMAIL PROTECTED] writes: On Tue, Oct 02, 2007 at 11:03:29AM -0400, Derek Atkins wrote: As I've said over and over, the REAL answer is to integrate e-guile and then invoices could be an HTML-template with embedded guile, instead of a scheme program that happens to generate HTML. I'm still waiting for someone to offer to implement that. :-D Just for the record, and because, as you point out, this has been repeated several times... I agree that the solution is an html templating system. However, there are many better examples than eguile, if one is willing to use a scripting language other than guile. I, for one, would not recommend anyone actually attempt to integrate e-guile, as that is essentially equivalent to writing and maintaining our own templating system. Also, I think it's very unlikely that anyone will ever get it to do anything impressive. I strongly agree with this, on all points. Instead, if there is anyone interested, I would recommend that they adapt the swig .i files to the popular scripting language of their preference, and use the popular templating system of their choice. This is a far better engineering decision, IMO, and far easier to do, also. It's probably about 80 hours work to the initial working system for someone already familiar with the relevant tools. While certainly people are free to do as they will, I think it makes sense to have a rational discussion about the particular language/templating system. If I only had the time... I strongly agree with this, too. :/ -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpoc2OeNqqiB.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
Bryan Cebuliak [EMAIL PROTECTED] writes: I will run diff for the second time ever. In the mean time, you have the complete code and the knowledge to fix the crash problem. Ah, but The identity of reports is by name, so you may care to use a different name for the report (at least during development), to prevent those types of crashes. As well, it would allow you to have the old and new versions both available for comparison at runtime. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpK8Q79VjqZu.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
Bryan Cebuliak [EMAIL PROTECTED] writes: copying new onto old reports then restarting gnucash. Any hints on how to get useful log or debugging output here? Take a look at the logging functions at src/scm/main.scm:165 . In anticipation, why does it have to crash? Can this be fixed to allow a more graceful, user friendly failure? Sure, go for it! :) In particular, check out the error handling shim in src/app-utils/gfec.c, and where it's called from src/bin/gnucash-bin.c in `try_load_config_array(...)` and `load_user_config(...)`. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpm0piAmCxDs.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
P. Christeas [EMAIL PROTECTED] writes: Lurking in this list, I have only read the last postings, so excuse me if I'm wrong: Would it pay to let PHP access the invoice data (sth. like a PHP module with bindings to gnc model) ? Then, PHP, widely adopted for html templating, could handle all sorts of forms. Sure. I think there's two main approaches: 1/ use an explicitly language-neutral templating language such as ClearSilver. 2/ pick a new preferred reports language and use a templating system written in it (python: mako, genshi; perl: Template::Toolkit, HTML::Mason; php: itself) As for picking PHP as that language, I think it has some important marks in its 'Con' column. 1/ it appears to be a very large dependency (relative to perl or python) 2/ it's not already installed on system- or desktop- boxes (in the way perl or python have been for a while now). 3/ it sucks. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpGQtGXQ3kfS.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: RFC: Server disk slowly failing, I plan to replace it using tip jar.
Derek Atkins [EMAIL PROTECTED] writes: I was planning to use the tip jar for this purchase, which is why I'm soliciting opinions before I purchase anything. Note that if I order from NewEgg I can usually have the item delivered the next day. On the other hand I wont have time to work on the hardware until probably October 27-28, so we have a little time to come to consensus. So... Comments? Suggestions? Sounds good to me. (Are you thinking of doing the other os/software upgrades at the same time?) -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpzzcmgG574J.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
Stuart D. Gathman [EMAIL PROTECTED] writes: On Wed, 3 Oct 2007, Josh Sled wrote: 3/ it sucks. 3 is not very specific :-) Let me help. IMO the main problem with PHP is its strength - the string subsitution model. Shell programming has I think it is neither a very good programming language or a clean templating language. (FWIW, Perl also has a big ugly language mark in its 'con' column, imho.) -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpLhZSWiyj5B.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gcc 4.2 warnings
Christian Stimming [EMAIL PROTECTED] writes:
Your change, however, is a different expression: With your case, if the char
pointer points to a non-empty string, use it, but otherwise use the pointer
to an empty string.
Which points me to the question: Which gcc warning did you try to fix here?
The warning was TransLog.c:254: warning: the address of 'drecn' will always
evaluate as 'true'.
Looking more into context, it turns out drecn is a local char buffer anyway,
hence it can't be NULL anyway. Because of this, here (and only here) you
should replace the expresssion direcly by drecn, i.e.
- drecn ? drecn : );
+ drecn);
I suggested the {{{ drecn[0] == 0 ? [...] }}} form of the fix.
Of course, drecn[0] == 0 just means the string is already empty.
So, you're totally right; it should just be drecn.
But, there was a bit of a miscommunication about how to make the change,
anyways. As you'd quoted, if drecn[0] == 0, then the string drecn is empty,
and it'll be printed. Otherwise (when drecn actually has a value), it will
use instead.
Thanks for the code review.
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgp1LYZkHTop0.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branch off a 2.2-branch, then merge CSV importer into trunk?
Christian Stimming [EMAIL PROTECTED] writes: Hence, I'd suggest to branch off the stable 2.2 branch now (or: within the next few weeks), and merge the csv-importer branch into trunk directly after that so that more people can have a look at the importer code. +1. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpGzBRYYTKdu.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Thanks...
Please make sure you CC: the mailing list on all replies; you can do this via your mailer's Reply to List or Reply to All features. Anti Kutoja [EMAIL PROTECTED] writes: Hi fellahs, Thank you both very much for replying to my query about the problems of trying to build a gnucash and getting the documentation. I am still in trouble so please bear with me while I tell what I've done so far. I got and installed Rauch Christan's RPM and, although it installed some docs it wasn't enough since gnucash complained about not finding the docs in either of two directories it detailed. I then got and installed the gnucash docs package but that installed in a directory also not found by gnucash. I guess I should have tried to direct the .configure more accurately. I then symbolically linked the docs package stuff into the directory that gnucash had earlier complained that it couldn't find the docs in. There was still one more problem. Under the gnucash directory along the docs required path, there was a sub-directory called doc. This was, apparently, unknown to gnucash and it still complained about not finding the documentation. I resolved that by linking all the contents of the doc directory back into the gnucash directory and this worked... up to a point. When I tried again to launch the tutorial, the kde help module told me there was no documentation for ./gnucash/C/gnucash-guide.xml. I have yelp installed so I launched it and asked for stuff on gnucash. It went away for over an hour without responding so I killed it. Do you think if I re-install the distro and choose the gnome desktop, things will work better? I see that gnucash uses gnome components fairly extensively. Installing packages from your distribution (or established providers like C. Rauch) shouldn't require you to manually guess your way through symlinking directories together. Things might be a bit easier if you reinstalled with a gnome environment, but that's not a requirement for using GnuCash. I managed to get some 2002 pdf tutorial from the gnucash website but there was no mention of things like invoices, sales ledgers and so on. Have these things been added since 2002? If not, are they planned? Accounts/Receivable, A/Payable, Vendors, Customers, Jobs, Payroll and Invoices have all been features since 1.8. I'm not sure which PDF you're referring to since you don't identify it ... but if it's A User Guide to GnuCash by David Gilbert dated Nov 4, 2002 (from http://www.object-refinery.com/gnucash/index.html), then claims to only be current as of the 1.6 release. There is more current documentation available at http://www.gnucash.org/docs.phtml; it's exactly the same as is installed by the gnucash-docs package. Thanks again for your help. Kind Regards - Andy Weaver -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpQkWavoAxpv.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Hebrew translation
Avishay Zafran [EMAIL PROTECTED] writes: Hello i would like to ask if there will be an hebrew translation for this great software? Yes! As soon as someone (you?) contributes one. http://wiki.gnucash.org/wiki/Translation -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpPwjNJKRpSJ.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: optimizing reports
Andrew Sackville-West [EMAIL PROTECTED] writes:
I suppose this raises the larger issue of what is going on long-term
with the reports. Is the amount of work necesary to fix the
performance issues sufficient to warrant looking at the long term goal
with reporting with an eye to just doing that change now? I know
Derek wants to work e-guile into the mix and implement some kind of
templating. Others have suggested binding in a whole 'nother language
for reporting. I don't know the answers and lack the knowledge,
experience and position to answer them.
Should the reporting structure be re-worked altogether? now or later?
Should the current structure be cleaned up in parallel to that effort
to improve performance in the interim? Or should it be left as it is,
just improved?
(What follows are excerpts from some notes I've been working on on the
subject.)
Reports have some problems:
- defined in scheme, hard to modify, weird errors, c.
- emit HTML, no conventional templating
- bad html, no css
- name-based identity
- options are stored as scheme code
- strange to add new report types
- report options are inconsistent
- report options dialogs are not HIG-compliant
In particular, the storage of report options and saved/open reports as
evaluated lisp expressions tightly couples us to a particular technology for
the reports.
The rough form of a revised reporting infrastructure I'd like to see is:
- reports declared as data, rather than registered as code.
- separation of the report generation code from the report rendering
code. something like:
book
v generator, report-provided
report-model (dict)
v renderer (template application)
report-output (html)
v HTML engine, GOG
display
v
{screen,file}
Where the report generator specifically emits only a data structure (language
neutral, dictionary-list-string-number-boolean, c.) that is the input to the
rendering phase. The separation supports separation of concerns, layering,
independent evolution and development/testing.
I think a report might be well-suited to be a bundle ... some structured,
self-contained collection of files. It is a ${format} archive with a
known-location manifest file report.def, which contains the basic report
definition. By example:
foo.tar:
- report.def
- report.script
- template.html
- local.css
report.def:
[gnucash-report-v2]
name = Foo Report
desc = The ISO-1234-26b foo report.
id = 0a1b2c3d4e5f6a7b8c9d0e1f
parent = assets-expense
report-type = scm
load-files = report.asl, helper.asl
options-entry-point = foo-options
generator-entry-point = foo-report
renderer-entry-point = template_apply
template-file = template.thtml
name.fr = Foo Réport
desc.fr = Lé réport du generallies foo...
A goal would be to have something like ~/.gnucash/reports.d/, where a user
could publish a new report (as that single archvie), and other users could
simply save it there and have it appear in their gnucash instance.
On the front-end, we should move to a more normal generation scripting
language (perl, python, ruby) and template-based rendering solution. That
should be consumed by gecko, not gtkhtml, as it doesn't suck.
I could see a time where we are in transition, and have both v1 (existing)
and v2 (proposed here) reports co-implemented.
With respect to the Options, we should convert the options implementation
From scheme + closures to C + GObject/GInterface + signals. The existing
saved/open reports are all basically of the form:
(let ((optionDb (report-default-options report-name)))
(set optionDb 'optionA new-value)
(set optionDb 'optionB new-value)
(create-report report-name optionDB))
As such, we strongly require a guile interpreter to parse/eval all this. As
the options are moved into C, they'll need bindings to support at least
handling these existing files, but should then serialize back into a
non-guile-specific format.
I've started down this path on a private source tree.
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgpYY4yXc1FwY.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Inventory system design: proposal:
Lianto Ruyang [EMAIL PROTECTED] writes: - how to make the select-dialog can show items quickly (i imagine if the items are in thousands the tree-view will be very slow) I'd not worry about this. As a anecdotal data-point, GPMC [¹] handles 16k items in my full playlist without even blinking an eye. [¹] http://sarine.nl/gmpc -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpTuRZ7vT7cX.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems building 2.2.1 (svn) on openSuse 10.3
(Trimming gnucash-user from distribution list. This is clearly -devel traffic.) Davide Imbeni [EMAIL PROTECTED] writes: 2 -- The above allowed make to continue compiling... for a while. Next error, on which I'm currently stuck, is: gcc -DHAVE_CONFIG_H -I. -I../.. -DG_LOG_DOMAIN=\gnc.engine\ -I../../lib/libc -I../../src/core-utils -I../../src -I../../src -I../../src/gnc-module -I../../lib/libqof/qof -I../../lib/libqof/qof -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -Werror -Wdeclaration-after-statement -Wno-pointer-sign -D_FORTIFY_SOURCE=2 -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wno-unused -MT engine-helpers.lo -MD -MP -MF .deps/engine-helpers.Tpo -c engine-helpers.c -fPIC -DPIC -o .libs/engine-helpers.o cc1: warnings being treated as errors engine-helpers.c: In function 'gnc_generic_to_scm': engine-helpers.c:2161: warning: passing argument 1 of 'SWIG_Guile_NewPointerObj' discards qualifiers from pointer target type make[5]: *** [engine-helpers.lo] Error 1 make[5]: Leaving directory `/usr/local/src/gnucash-svn/src/engine' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/usr/local/src/gnucash-svn/src/engine' make[3]: *** [all] Error 2 make[3]: Leaving directory `/usr/local/src/gnucash-svn/src/engine' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/gnucash-svn/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/gnucash-svn' make: *** [all] Error 2 slib and swig are obviously installed. Any suggestions? This is a new warning seen by using gcc-4.2. As building is generally done with -Werror, such warnings are promoted to errors, as you're seeing. You'll need to re-run configure with `--disable-error-on-warning` to let the warnings pass as such until such time as changes are made to build clean with gcc-4.2. Better yet, patches to fix the problems would be great. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpvF2K1Mg5yS.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Symbian
Pizza Margherita [EMAIL PROTECTED] writes: Have you planned any symbian or mobile version of GnuCash? No one has announced they they have completed (or are even working on) such a thing. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpzzAxgYqocn.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems downloading stock quotes [RESOLVED] possible security issue
Richard Geddes [EMAIL PROTECTED] writes: I re-applied the ad blocker, and with my browser, was able to get a quote for RHAT AMD from the yahoo website successfully. When I tried gnc-fq-dump yahoo RHT AMD from the command line and it failed. This leads me to think that F::Q does not work like the browser... it looks like F::Q needs to have name resolution for a set of advertisers on that ad block list. My web browser also responds the ad blocking aliases in the hosts file. F::Q does do web-page scraping to get some quotes. My guess is that there's some coincidental overlap in the hosts used to obtain some quotes as well as serve ads. Some front-end Yahoo load-balanced server, most likely. If you care enough, you could binary-search within that host list to figure out exactly which host causes the problem. I've seen a bit of F::Q sources and know how it interacts with gnucash. The dataflow is specific and uni-directional. AFAIK, F::Q isn't provided with any of your financial data apart from the quote source and symbol itself. Thus, it can't re-provide that data to any other entity. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpKHCbUW0UMp.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems downloading stock quotes [RESOLVED] possible security issue
Richard Geddes [EMAIL PROTECTED] writes: Seems a little odd that F::Q would fail when advertiser domain names are unresolvable... I would figure, if an F::Q encounters an ad domain while scraping, it would ignore it and look for the goodies. I guess I could tcpdump the F:Q connection to see what's going on at the packet level... it's been a while since I've tcpdump'ed, so it'll take me some time to get the output correct. You're assuming that your advertiser host list is both precise and accurate. It may well be neither. Also, as per the mechanism used (changing the resolution for ad hosts to localhost)... when a process encounters a domain, it doesn't know if it's an ad domain or not, it just tries to make the connection to localhost, instead, and fails. For HTTP, this will either be a connection failure, or perhaps a 404 or 500 failure (if you happen to be running an http server on your local machine). It just so happens that for the case of an ad image/flash/javascript in common web browsers, these failures result in the desired effect: no advertisement. Other applications might not fail in the same way. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpUJuOtfna0e.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Symbian
Daniel Espinosa [EMAIL PROTECTED] writes: Things like this is why is better to have a library doing the hardwork and allows the users to create it's interface, I don't know about Symbian, but GDA and GnomeDB have a porting to Maemo (Nokia N800 - I have one:) and that was in a relative short time, even Glom witch uses GDA, have one. Remember that a library based on GLib/GObject can be ported to different plattaforms with few changes: exists a lot of libraries ported to Windows included GDA. You mean libraries like the engine and file backend? :) You seem to be implying that this isn't possible right now, but of course it is. In fact, the gnucash source code is pretty highly portable. Taking just a few pieces as libraries and building a smaller application would be non-trivial, but possible. GObject and GDA aren't the only solutions in the world, you know. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpgelmc0wPRM.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: the old design docs
tim [EMAIL PROTECTED] writes: I see the warning he pointed me to, but the copy http://code.neil.williamsleesmill.me.uk/texi/gnucash-design.html linked from the doxygen start page http://svn.gnucash.org/docs/HEAD/ (under heading Documentation elsewhere in the source tree) is too old to carry this warning which is why I missed it. Perhaps it is worth updating this copy, or pointing the link somewhere else (I could host a copy if needed). We should probably generate this HTMLized version of the texinfo docs, and put it on svn.gnucash.org, then update the link. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpQha3vnDilS.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Can someone help me make the SLR dialog do what I want?
Sorry for the delay in response.
Tim Wunder [EMAIL PROTECTED] writes:
Ugh... I appreciate your responding to my plea for help, but I really need
more basic and fundamental help than that. Assume I know /nothing/ about C
programming, and especially gtk+ programming.
I hope that you didn't find all this too discouraging, and if you did, you'll
feel motivated to try again.
I did some messing around to see if I could grok even a little of what you
told me (and what I read). Without much success, as indicated by:
dialog-sx-since-last-run.c:981: warning: ISO C90 forbids mixed declarations
and code
dialog-sx-since-last-run.c:982: warning: passing argument 1
of 'gtk_tree_model_filter_set_visible_func' from incompatible pointe
I did this:
_gnc_slr_filter(GtkTreeModel *model, GtkTreeIter *iter, gpointer data)
{
// just playing around with a function call
gboolean SX_filter = 1;
return !SX_filter;
}
and then...
//gtk_tree_view_expand_all(dialog-instance_view);
GtkTreeModel *filtered_model =
gtk_tree_model_filter_new(GTK_TREE_MODEL(dialog-editing_model), NULL);
gtk_tree_model_filter_set_visible_func(filtered_model,_gnc_slr_filter,
NULL, NULL);
I'm sure what I've done isn't even close to what's supposed to be done, but
I'm old, so choose your clue bat with care. ;) Don't I need to pass
variables when calling functions or something?
When you use a function pointer like this, you're not actually calling the
function ... you're just passing the pointer to the function for something
else (the GtkTreeModel, in this case) to invoke. When it does eventually
call the function, it do need to pass arguments ... and it's going to pass
exactly the parameters that are expected of functions that fit the
visible_func signature.
Also, how do I query the model (?) to determine its state (autocreate,
to-create, reminder, etc...)?
The filter function only has access to its parameters; its model param is
generically a GtkTreeModel, but you (and the code) can assume it's actually a
GncSxSlrTreeModelAdapter. This class has the GncSxInstanceModel that it's
adapting as the field instances.
From a GtkIter one can get a GtkPath, which has specific indices; these
indices can then be used as list indices into the GncSxInstanceModel (and its
contained objects), to get the specific GncSxInstance that the GtkIter for a
row in the tree model corresponds to.
There is a convenience method in this file to do just those steps, taking the
model and an iter and translating it into the instance :)
GncSxInstance*
gnc_sx_slr_model_get_instance(GncSxSlrTreeModelAdapter *model, GtkTreeIter
*iter)
Once you have the relevant GncSxInstance*, the creation state is in the
fields:
GncSxInstanceState orig_state;
GncSxInstanceState state;
...on the GncSxInstance class/struct
(see src/app-util/gnc-sx-instance-model.h:98).
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgpllxl7jqJJ6.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: price quotes for dates in the past
Greg Balls [EMAIL PROTECTED] writes: Once I started poking around the gnucash code, though, I noticed that there's already a start at this functionality coded up in price-quotes.scm, but I'm not really sure what state it's in. (I'm not the most fluent in scheme/guile/whatever it is.) So, is anyone actively working on this? Is there an objection to using the Finance::QuoteHist module? Any other suggestions? The code in question is from Spring 2001; it was last touched in revision r3988, on 2001-04-17 http://svn.gnucash.org/trac/changeset/3988. The string historical-quotes is not referenced in any other file. I'd start from scratch, using Finance::QuoteHist. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpRuTeowcm12.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash and open source
[EMAIL PROTECTED] (Karl Berry) writes:
Back in August 2006, there was a fairly long thread kicked off by rms
requesting that open source be replaced with free software on the
gnucash.org web page:
https://lists.gnucash.org/pipermail/gnucash-devel/2006-August/018378.html
It culminated in this message from Thomas:
https://lists.gnucash.org/pipermail/gnucash-devel/2006-August/018411.html
which, together with the following replies, seemed to imply that the
changes would be made. But, in fact, they never were -- the web page
still says open source.
Someone else just reported this to rms and me, so we'd like to get it
resolved this time, one way or another. Help?
I've updated the following:
- images sources (/gnucash/trunk/art/{logo,splash,banner}.svg)
- s/Open Source/Free/
- s/Finance/Accounting/ (consistency)
- s/Gnucash/GnuCash/ (consistency)
(This was a more involved than it initially appears, since – it's a bit hard
to see in most versions – but the blue card item actually has a feature (in
the lower right corner) that says Open Source ... well ... said, anyways.)
- the splash screen bitmap export
(awaiting backport to the 2.2 branch)
- the website banner bitmap export
- the text of the website: page title and news items from 2.0.0 through 2.2.1.
The news items mostly said one of two things:
- GnuCash Open Source Accounting Software
- [...] free, open source accounting program
I changed the former but not the latter; the more recent release
announcements don't include it anyways.
Although I agree that the double meaning of free is especially
unfortunate for accounting software, there is no good alternative.
(http://www.gnu.org/philosophy/open-source-misses-the-point.html is rms'
latest essay about this. From the standpoint of GNU and the free
software movement, it would be better to refrain from saying anything
than to say open source.)
Open source might not convey everything that Free (libre) does, but it's
hard to see how it would be better to not say anything.
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgpfaWcTghBzx.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r16613 - gnucash/trunk - s#Open Source#Free#, s#Finance#Accounting#, s#Gnucash#GnuCash#
Andreas Köhler [EMAIL PROTECTED] writes: Am Mittwoch, den 05.12.2007, 09:57 -0500 schrieb Josh Sled: Author: jsled New Revision: 16613 Trac: http://svn.gnucash.org/trac/changeset/16613 Modified: gnucash/trunk/art/banner.svgz gnucash/trunk/art/logo.svgz gnucash/trunk/art/splash.svgz gnucash/trunk/src/pixmaps/gnucash_splash.png Log: s#Open Source#Free#, s#Finance#Accounting#, s#Gnucash#GnuCash# BP is there any particular reason you left out art/icon.svgz? Ah, not a good one. I thought it was the Tango-ified icon, which has no text, but as you point out it's the blue card one. I've updated it as well, even thought it's not really used, AFAIK. Thanks... -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpsebJ62sBQt.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Changing SX Causing GnuCash to Hang
Volker Englisch [EMAIL PROTECTED] writes: I have a scheduled SX setup to automatically add a fixed amount of interest to a savings accounts at the end of a month. I changed this SX so that the amount is a variable from this point forward. However, when I'm trying to close the tab of the Scheduled Transaction Editor (the Close Button is on the tab) GnuCash hangs and I have to kill the application. The only message on the command line is this: *** glibc detected *** gnucash: corrupted double-linked list: 0x43405158 *** I have tried to change this SX several times on two different systems (one running FC5 - svn r16583 on 2007-11-14 and one running FC6 - svn r16372 2007-07-29) with the same result except that the error message is not displayed on the FC6 system. Choosing a different SX to modify in the same way results in the same problem. I haven't seen this problem reported before. Should I report it in Bugzilla? I'm taking a look at it right now, so hopefully it won't be alive for long, but it'd be nice to have a bug filed either way, yes, please. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgp3P4xYBBEEb.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Changing SX Causing GnuCash to Hang
Josh Sled [EMAIL PROTECTED] writes: Volker Englisch [EMAIL PROTECTED] writes: I have a scheduled SX setup to automatically add a fixed amount of interest to a savings accounts at the end of a month. I changed this SX so that the amount is a variable from this point forward. However, when I'm trying to close the tab of the Scheduled Transaction Editor (the Close Button is on the tab) GnuCash hangs and I have to kill the application. The only message on the command line is this: *** glibc detected *** gnucash: corrupted double-linked list: 0x43405158 *** I have tried to change this SX several times on two different systems (one running FC5 - svn r16583 on 2007-11-14 and one running FC6 - svn r16372 2007-07-29) with the same result except that the error message is not displayed on the FC6 system. Choosing a different SX to modify in the same way results in the same problem. I haven't seen this problem reported before. Should I report it in Bugzilla? I'm taking a look at it right now, so hopefully it won't be alive for long, but it'd be nice to have a bug filed either way, yes, please. Well, if you haven't filed one yet, don't bother ... but let me know if r16629 resolves the problem, please? -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpxEEfch6eh4.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Changing SX Causing GnuCash to Hang
Volker Englisch [EMAIL PROTECTED] writes: On 12/09/2007 06:41 PM Josh Sled wrote: Well, if you haven't filed one yet, don't bother ... but let me know if r16629 resolves the problem, please? I saw your email a little to late. :-) But yes, whatever you did solved the problem. No more hanging GC when closing the tab. Heh. Great. I've closed the bug, targeting it for 2.2.2, and updated the commit log messages to mention the bug number; the circle is complete. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpa5JNwSKThJ.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r16678 - gnucash/trunk/src/pixmaps - Bug#503889: Install icons according to spec. On Win32, however, don't run the non-existant (?) gtk-update-icon-cache.
Josh Sled [EMAIL PROTECTED] writes:
Author: jsled
Date: 2007-12-18 09:57:12 -0500 (Tue, 18 Dec 2007)
New Revision: 16678
Trac: http://svn.gnucash.org/trac/changeset/16678
Modified:
gnucash/trunk/src/pixmaps/
gnucash/trunk/src/pixmaps/Makefile.am
Log:
Bug#503889: Install icons according to spec. On Win32, however, don't run
the non-existant (?) gtk-update-icon-cache.
Hey Win32 builders. I understand there's no gtk-update-icon-cache, so I
just blocked that whole bit out, I hope correctly. Also, I don't think the
funny gzip -cd ${top_srcdir}/art/icon.svgz [...] should be a problem
looking at other Makefiles, but I'm not 100% sure. So, generally, I'd love
some QA, here:
Property changes on: gnucash/trunk/src/pixmaps
___
Name: svn:ignore
- Makefile
Makefile.in
semantic.cache
+ Makefile
Makefile.in
semantic.cache
16x16
32x32
48x48
scalable
Modified: gnucash/trunk/src/pixmaps/Makefile.am
===
--- gnucash/trunk/src/pixmaps/Makefile.am 2007-12-18 05:44:44 UTC (rev
16677)
+++ gnucash/trunk/src/pixmaps/Makefile.am 2007-12-18 14:57:12 UTC (rev
16678)
@@ -36,10 +36,48 @@
stock_split_title.png \
stock_split_watermark.png
-gncicondir = ${datadir}/pixmaps
-gncicon_DATA = gnucash-icon-16x16.png \
- gnucash-icon-32x32.png \
- gnucash-icon-48x48.png
+gncnormalicondir = ${datadir}/icons/hicolor/48x48/apps
+gncnormalicon_DATA = 48x48/gnucash-icon.png
+48x48/gnucash-icon.png: gnucash-icon-48x48.png
+ -mkdir 48x48
+ cp gnucash-icon-48x48.png 48x48/gnucash-icon.png
+gncmediumicondir = ${datadir}/icons/hicolor/32x32/apps
+gncmediumicon_DATA = 32x32/gnucash-icon.png
+32x32/gnucash-icon.png: gnucash-icon-32x32.png
+ -mkdir 32x32
+ cp gnucash-icon-32x32.png 32x32/gnucash-icon.png
+
+gncsmallicondir = ${datadir}/icons/hicolor/16x16/apps
+gncsmallicon_DATA = 16x16/gnucash-icon.png
+16x16/gnucash-icon.png: gnucash-icon-16x16.png
+ -mkdir 16x16
+ cp gnucash-icon-16x16.png 16x16/gnucash-icon.png
+
+gncscalableicondir = ${datadir}/icons/hicolor/scalable/apps
+gncscalableicon_DATA = scalable/gnucash-icon.svg
+scalable/gnucash-icon.svg: ${top_srcdir}/art/icon.svgz
+ -mkdir scalable
+ gzip -cd ${top_srcdir}/art/icon.svgz scalable/gnucash-icon.svg
+
+# As suggested by http://live.gnome.org/GnomeGoals/AppIcon
+if !OS_WIN32
+gtk_update_icon_cache = gtk-update-icon-cache -f -t $(datadir)/icons/hicolor
+install-data-hook: update-icon-cache
+uninstall-hook: update-icon-cache
+update-icon-cache:
+ @-if test -z $(DESTDIR); then \
+ echo Updating Gtk icon cache.; \
+ $(gtk_update_icon_cache); \
+ else \
+ echo *** Icon cache not updated. After (un)install, run
this:; \
+ echo *** $(gtk_update_icon_cache); \
+ fi
+endif
+
EXTRA_DIST = \
- ${gncpixmap_DATA} ${gncicon_DATA}
+ ${gncpixmap_DATA} \
+ ${gncnormalicon_DATA} ${gncmediumicon_DATA} ${gncsmallicon_DATA}
${gncscalableicon_DATA}
+
+clean-local:
+ -rm -rf 48x48 32x32 16x16 scalable
Thanks in advance...
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgpyyrf9VFgPs.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Object fields vs slots
Phil Longstaff [EMAIL PROTECTED] writes: What is the rationale uses to decide whether to make an object attribute a field in a structure vs a slot? An Account has the hidden, tax-related and placeholder attributes which are slots rather than fields in the Account structure. What is the reason for that decision? I know slots are used to hold sx information. Are they used extensively elsewhere in the system? Many: Layering. Convenience. Laziness. Very practically, a plugin (e.g. Business) can't define fields on a Engine layer object, for instance. It must use the generic storage. However, that a Transaction's Notes – a very clear first-order field – are in a KVP frame is just bad design. The SX use, imho, is a bit less clear. The fact that a Transaction was created from an SX is just advisory, so it's less threatening that it's in a KVP frame. Still, it'd be nicer if Transactions had a more formal source field, that could be used for this purpose, as well as import, c. This is an argument primarily from laziness. :) They're convenient because the KVP data is (un)marshalled from XML generically; this is a bad excuse for its use, imho. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpqAaLLYGQax.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
random emacs tips [WAS: Re: r16600 - gnucash-docs/trunk/guide/C - Correct …]
Andrew Sackville-West [EMAIL PROTECTED] writes: Certainly I would benefit greatly from a tips and tricks page but most of that actually applies to emacs in general and wouldn't really belong on a gnucash page. Since the only coding I currently do is gnucash, the gnucash devs are forced to teach me emacs in exchange for bits of broken report code rife with spelling errors. Seems fair to me :-P Heh heh. :) cscope -- At the top of your source tree `make cscope.out`. In emacs, while in a .c or .h file, while point is on a function, try «C-c s g» to invoke cscope-find-global-definition, to jump to the thing's implementation. While in a function «C-c s c» to invoke cscope-find-functions-calling-this-function, which is pretty useful. emacs code browser -- I don't use it all that often, but the emacs code browser http://ecb.sourceforge.net/ is pretty nifty. «M-x ecb-activate» will get it active in a buffer, then «C-c . l w» will toggle the navigation pane, showing a tree of everything (includes, typedefs, local variables, function signatures, classes, c.) defined in the file. «C-c . g m» will goto this method pane for selection/naviagation. I'm sure that's just the surface of ECB, which I really should learn in depth. One of the nice things about ECB is that it supports multiple languages … C, scheme, elisp, python, java … -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpkBF5s00ISk.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
