The "entire menu" thing is pretty common, these days. In fact, GTK2 has first order support for [un]merging menus for just that reason. There's actions that are "global" and some that are contextual, and we present them together.
You can add new tabs by opening accounts registers, reports or budgets. I don't know how else you'd like to add new tabs.
Showing the window before it's been populated isn't great, but it's a consequence of some changes that occurred in the last couple of weeks regarding making the application initialization less silly. If you think this is really intollerable, file a bug.
GnuCash is pretty flexible; so long as the accounting requirements are based in basic accounting principles -- which you would hope they are [!:)] -- you should be able to model and account for it in GnuCash. We have a setup for templated account trees, which can then be created as a unit [i.e., "I want a data-file with 'Checkbook', 'Loan' and 'Renter Expenses' accounts"]... we already have a contribution of the German SKR03-04 account tree, which sounds very similar to your situation. We'd love a contribution of the account tree if you can provide it!:)
Well, there's both maintainability and feature reasons to move to gtk2 (and, generally, modern libraries), as well. It does require non-trivial changes; "optional" gtk1 and gtk2 front-ends would be a massive undertaking that no one has helped do.
While the overall dependecy profile of gnucash is large, it's really not that large; but it certainly sits very high up on the desktop application stack, so there's a lot of depth below it. In any case, the dependencies are there for two reasons: it's a comparatively featureful app as well as... over-engineered. I'd rather reduce some of the dependencies through simplificiation of the code base.
In any case, static linking binaries is generally silly.
Well, we use gtkhtml for rendering the reports, which emit html. While we used to have it setup to do "arbitrary" browsing, I'm pretty sure that's not working in 2.0. It [abritrary browsing from w/in GnuCash] is certainly not a direction the current devs are interested in going.
GnuCash has always had a "light" affiliation with gnome... so, yes, it's primarily GTK, but it is GNOME-specific dependencies as well. Using gconf, for instance... and goffice for graphing.
wik, the GnuCash developers agree. We've been focusing very intentionally and narrowly on getting the gtk/gnome2 port out the door w/o many other changes to minimize risk, but once this release is out, I think you'll see some large simplifciations of the codebase.
The gtk1 libraries are soon simply not going to be distributed by distros, and with them software that depends on them. I too was fine with the UI, but we (GnuCash) would rather keep being distributed.
Yeah, W6 is "cute", but ultimately not semantically rich enough.
DublinCore covers a lot of the digital artifact information [title, authors, publisher, &c.] Where is wgs48, and when is actually covered pretty well by W6, if only because it's not clear what "when" is referring to.
If anything, I'd say W6 is really useful as a set of stakes in the ground for being super-classes... it might work better as a the roots of an Upper ontology.
If you think about it, the S-P-O relation from RDF is the thing that actually allows interoperability between different [namespaced] properties... since it's clear into which role all extension goes -- as new Properties.
Yeah... RDF is the simplest thing in the world. Subject+Property+Object... Object is either another Subject, or a literal value.
And N3 [or Turtle] is a far better serialization than XML.
Semantics are important, but _agreement_ is even more so. The hope of RDF is that when we get away from the sillyness of XML and start agreeing about how to speak about relations [in terms of SPO], we can start talking about more interesting things like schema and semantics.
I've got a TDK Mojo, and I like it well enough, though I'm not that demanding... I just want to make a reasonable mix, put it on random and sometimes forward past tracks that don't strike me as perfect for the moment. It does that quite fine.
I don't know if it fits the bill in your circumstance, but there are business-accounting features in CVS GnuCash, and I know the developer would love to get feedback on it as we approach 1.7.beta/1.8.
Well, in CVS there's a Druid to help setup Mortgage/Loan-repayment Scheduled Transactions... I'd really appreciate you're trying it out, as I don't have a loan/mortgage myself, and it seems like everyone has slight differences in the way their's works, anyways.
Scheduled Transactions are in CVS now, and could use some Feedback; they'll definitely be in 1.8, which we are hoping to get out in a couple/few months.
The more forward-looking stuff I hope to add for 2.0, which is quite a ways off. If you're interested in jumping in and getting something basic [like a report which would contain some of the functionality] done for 1.8, please do so.:)
I'd rather see the "book" released as a collection of RecipeML files, so that I could re-arrange/import/manipulate them down the road...
I care nothing about Word nor PDF. Give me docbook sources, so that I can [again] reformat to my eBook for use in the kitchen... or to my custom kitchen appliance, should I ever make that exist.
Given the state of the populous [sedentary, generally-low-metabolism males] I'd try to focus on healthier stuff. For instance, Chicken in Mango Sauce is quite tasty [just made it last night], and is better for you than corndogs.
Unfortunately, I don't know if anything other than very basic forecasting [read: computing the defined Scheduled Transactions for N months into the future] will make it into 1.8. I have a lot of ideas for how I want to do budgeting, but I don't have a lot of time.
Help [even just testing or usage feedback] is much appreciated.
If you're curious as to my thoughts about how budgeting may work in GnuCash -- perhaps in the future [2.0?] -- check out the mailing list archives as far back as November 2000.
Slashdot Mirror
The "entire menu" thing is pretty common, these days. In fact, GTK2 has first order support for [un]merging menus for just that reason. There's actions that are "global" and some that are contextual, and we present them together.
You can add new tabs by opening accounts registers, reports or budgets. I don't know how else you'd like to add new tabs.
Showing the window before it's been populated isn't great, but it's a consequence of some changes that occurred in the last couple of weeks regarding making the application initialization less silly. If you think this is really intollerable, file a bug.
Yeah. That screen shot is from 1.6, which was released in 2001. The website will be revised once the port-related bugs are in-hand.
GnuCash is pretty flexible; so long as the accounting requirements are based in basic accounting principles -- which you would hope they are [! :)] -- you should be able to model and account for it in GnuCash. We have a setup for templated account trees, which can then be created as a unit [i.e., "I want a data-file with 'Checkbook', 'Loan' and 'Renter Expenses' accounts"] ... we already have a contribution of the German SKR03-04 account tree, which sounds very similar to your situation. We'd love a contribution of the account tree if you can provide it! :)
Well, there's both maintainability and feature reasons to move to gtk2 (and, generally, modern libraries), as well. It does require non-trivial changes; "optional" gtk1 and gtk2 front-ends would be a massive undertaking that no one has helped do.
... over-engineered. I'd rather reduce some of the dependencies through simplificiation of the code base.
While the overall dependecy profile of gnucash is large, it's really not that large; but it certainly sits very high up on the desktop application stack, so there's a lot of depth below it. In any case, the dependencies are there for two reasons: it's a comparatively featureful app as well as
In any case, static linking binaries is generally silly.
FWIW, Rob hasn't been a lead developer or even working on the project for a few years now.
Well, we use gtkhtml for rendering the reports, which emit html. While we used to have it setup to do "arbitrary" browsing, I'm pretty sure that's not working in 2.0. It [abritrary browsing from w/in GnuCash] is certainly not a direction the current devs are interested in going.
GnuCash has always had a "light" affiliation with gnome ... so, yes, it's primarily GTK, but it is GNOME-specific dependencies as well. Using gconf, for instance ... and goffice for graphing.
wik, the GnuCash developers agree. We've been focusing very intentionally and narrowly on getting the gtk/gnome2 port out the door w/o many other changes to minimize risk, but once this release is out, I think you'll see some large simplifciations of the codebase.
The gtk1 libraries are soon simply not going to be distributed by distros, and with them software that depends on them. I too was fine with the UI, but we (GnuCash) would rather keep being distributed.
Compile a list of passwords.
Break it into M components, such than N of them are required to be reassembled to create the list.
Give the M shares to trusted friends and family -- i.e., such than no N of them won't collude to fuck you over.
When you die, instruct the executor to re-assemble the shares.
Yeah, W6 is "cute", but ultimately not semantically rich enough.
... it might work better as a the roots of an Upper ontology.
DublinCore covers a lot of the digital artifact information [title, authors, publisher, &c.] Where is wgs48, and when is actually covered pretty well by W6, if only because it's not clear what "when" is referring to.
If anything, I'd say W6 is really useful as a set of stakes in the ground for being super-classes
XML != extensibility.
If you think about it, the S-P-O relation from RDF is the thing that actually allows interoperability between different [namespaced] properties... since it's clear into which role all extension goes -- as new Properties.
Yeah ... RDF is the simplest thing in the world. Subject+Property+Object ... Object is either another Subject, or a literal value.
And N3 [or Turtle] is a far better serialization than XML.
Semantics are important, but _agreement_ is even more so. The hope of RDF is that when we get away from the sillyness of XML and start agreeing about how to speak about relations [in terms of SPO], we can start talking about more interesting things like schema and semantics.
Yup, there's a vocabulary for that... http://ideagraph.net/xmlns/ibis/w6/
It has been ported to OSX, and is distributed as part of fink, IIRC.
s h
Yup; recent, but there: http://fink.sourceforge.net/pdb/package.php/gnuca
GnuCash can, actually. You can define arbritary commodities and currencies... keep the exchange rate up to date, &c.
... LSW? ;)
USD, CND, EUR
And, unfortunately, whomever submitted the article text doesn't understand it either.
... the "I all agreed it's time for me to move on" joke is like 4/10ths as funny without the creative-differences citation. /me headshakes
I mean, shit
I've got a TDK Mojo, and I like it well enough, though I'm not that demanding... I just want to make a reasonable mix, put it on random and sometimes forward past tracks that don't strike me as perfect for the moment. It does that quite fine.
I don't know if it fits the bill in your circumstance, but there are business-accounting features in CVS GnuCash, and I know the developer would love to get feedback on it as we approach 1.7.beta/1.8.
Well, in CVS there's a Druid to help setup Mortgage/Loan-repayment Scheduled Transactions... I'd really appreciate you're trying it out, as I don't have a loan/mortgage myself, and it seems like everyone has slight differences in the way their's works, anyways.
I'm working hard to get that into 1.8. ;)
Scheduled Transactions are in CVS now, and could use some Feedback; they'll definitely be in 1.8, which we are hoping to get out in a couple/few months.
:)
The more forward-looking stuff I hope to add for 2.0, which is quite a ways off. If you're interested in jumping in and getting something basic [like a report which would contain some of the functionality] done for 1.8, please do so.
From the .plan of a great sysadmin I once knew ...
"Being a System Administrator is like being the phone company. Nobody ever calls up to say 'you know, this thing works great. Thanks!'"
Thanks, Gabe.
Thanks, Vadim.
Thanks, csoft.net guys.
Thanks, Jonathan.
Thanks, root.
I'd rather see the "book" released as a collection of RecipeML files, so that I could re-arrange/import/manipulate them down the road...
I care nothing about Word nor PDF. Give me docbook sources, so that I can [again] reformat to my eBook for use in the kitchen... or to my custom kitchen appliance, should I ever make that exist.
Given the state of the populous [sedentary, generally-low-metabolism males] I'd try to focus on healthier stuff. For instance, Chicken in Mango Sauce is quite tasty [just made it last night], and is better for you than corndogs.
But, I don't see why this is better than SOAR^H^H^H^Hrecipesource.
Unfortunately, I don't know if anything other than very basic forecasting [read: computing the defined Scheduled Transactions for N months into the future] will make it into 1.8. I have a lot of ideas for how I want to do budgeting, but I don't have a lot of time.
Help [even just testing or usage feedback] is much appreciated.
If you're curious as to my thoughts about how budgeting may work in GnuCash -- perhaps in the future [2.0?] -- check out the mailing list archives as far back as November 2000.