Re: E-guile link
Hi Derek, FYI, the e-guile link is back up: http://woozle.org/~neale/repos/eguile/eguile.html I looked at it. It appears intuitive and nice to use. However, how does that fit with Josh Sled's simple roadmap explanation after G2? E.g., We've been really focused on the G2 port and 2.0, and intentionally haven't talked with too much rigor about post-2.0, at the same time there's been a lot of discussion over the last year or so, and I think it breaks out like: ... - Scheme removal ... - Fix modularity system cutpasted from http://www.mail-archive.com/gnucash-devel@gnucash.org/msg12143.html Is Scheme/Guile staying in or going out? Would e-guile be deleted within the year and replaced? Sincerely, Brian -- Contagious Design! web . design . photo Brian Rose . web programmer (604)-630-2426 . brianATcontagiousdesignDOTnet ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash design / new features
Another option we've discussed previously is e-guile.. This would make invoice templates effectively hand-written HTML with embedded guile.. So if you wanted to change the look at feel of your invoice you would just edit the HTML until it looked how you wanted it to look.. And then the embedded guile interpreter would run the template you created and display it with the relevant information. Then we could also distribute a bunch of templates (similar to iBiz) and you could choose one or create your own. I like this idea. Unfortunately as I was looking for an e-guile link I noticed that the author restructured his website and the old page is no longer there. I just emailed him about it. As I recall e-guile was effectively a single source file, so we could just copy-and-paste it into GnuCash and then someone would just need to figure out how to integrate it into the report subsystem and set up a runtime environment for a report template. Once we have access to that source I would like to look into it. Sounds good, but what do you think, Derek, about 2,3, and 4--directly above? I think they sound like a great idea. I would love for someone to dedicate time to coalescing all the various docs, finding out what docs are missing, what docs are duplicated, and honing down our docs into: user-docs (gnucash-docs package) dev-docs (in doxygen) build docs (README, HACKING, ...) arch docs (everything else, which bridges the gaps) I don't believe we'd need something like Drupal for this; I think this could all be done in CVS/SVN. Hmmm, but is there anywhere that says in stuff like in version 2.5 we will have whatever, and in v. 3.0 will be these features as well. A current roadmap I guess. Is it not neccessary to have all this and the docs above on the/a website? Right now there is the wiki, gnucash.org, and then independent developers' sites all with different info. I want to sound rude, just that I was confused at where Gnucash is going after G2, so I thought if I am confused maybe others are as well--hence the website suggestions. For example, I read the QSF part on Neil's site and now I wonder what QOF/QSF has to do with G2, SQL backend, multi-user support, I am sorry and maybe I am a bit green on developing such an app, but I just don't get any of the stuff with QOF/QSF. Is it part of the Free the data concept or to support multiple backends/platforms or what? Sincerely, Brian -- Contagious Design! web . design . photo Brian Rose . web programmer (604)-630-2426 . brianATcontagiousdesignDOTnet ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash design / new features
Oh, no! different info. I want to sound rude, just that I DO NOT want to sound rude! Yikes! Sorry! This is a good point (except for the wanting to sound rude part ;). yeah. Well, people really do judge a book by its cover and a project by its interface and its website-E.g., Does it have lots of cool original eye candy that looks fairly new, So, if we want to attract more users, developers, etc--this is why I like Firefox. Looks great, but is a good product too. it breaks out like: - General simplification - Report handwavecleanup/handwave - Scheme removal - Finalize QOF extraction - Fix modularity system - Features - DB-backend/SQLite integration. - Budgeting - Book closing - Lots - SX using QOF (to support above) - Register rewrite in simple widgets. Ok. Sincerely, Brian -- Contagious Design! web . design . photo Brian Rose . web programmer (604)-630-2426 . brianATcontagiousdesignDOTnet ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash design / new features
Hi, I suggest you look at QSF and maybe help me finish off the conversion routines and invoice export. I will look at QSF, first. Well, for one it would be really awesome if the invoice template was similar to iBiz, http://www.iggsoftware.com/ibiz/index.html . 1. We don't want to have specific external targets from within gnucash like that - the reference you quote is a moving target and if we try to fix against it, it will always be a case of catch-up. I wasn't suggesting mimicking iBiz. 2. Someone else will undoubtedly have yet another target that should be considered. Probably. Maybe we could come up with something to enable customizing invoices without leaving the Gnucash GUI and iBiz applies one way. So, several suggestions could be incorporated to create something better than the wisdom of anyone person. 3. QSF *can* deal with ANY external customisation requests. By having just the data required, you can develop a simple Perl/Python/PHP/whatever process that parses the XML and produces the template / report / format you need for whatever your target may be. It's designed to be all things to all men and once a conversion script is created, it remains current because all that is changing is the internal data - not the QSF format itself. Sounds very high-level, generalized, and vague. I.e., I don't understand, but maybe I will after reading about QSF. Highly flexible, but using a GUI and a template creator. If it's flexible enough to import data into that template, QSF can provide the data. It's just a question of a suitable script to process the output. Who is expected to write the script? Who is Gnucash intended for? Are you happier in GUI development or CLI or both? Web dev and backend stuff is where I am most comfortable. Sounds perfect. Backend stuff will be the invoice QSF which still needs a few tweaks in src/business/business-core/gncInvoice.c and src/backend/qsf/qsf-backend.c - contact me off-list if you'd like to look into that and I can send you some examples. I will read about QSF. 2. Tips and advice on how to manage the gnucash codebase. The tools to use and links to their documentation. Conventions and when to use branches. 3. A concerted effort to bring the existing disparate docs into one cohesive whole that is relevant, friendly, welcoming, genuinely helpful and bridges the gap between the gnucash-docs package and the gnucash-devel archives. 4. Regular and consistent updates to all documentation components. Realistically, this can only be achieved by using a tool that provides write access to all developers with CVS/SVN commit rights plus a few others with documentation skills - i.e. some form of CMS. I'd recommend Drupal. Sounds good, but what do you think, Derek, about 2,3, and 4--directly above? Sincerely, Brian -- Contagious Design! web . design . photo Brian Rose . web programmer (604)-630-2426 . brianATcontagiousdesignDOTnet ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash design / new features
Hi all, 1. OSX already has GnuCash via X11 and Fink (there could be licence problems with a native Cocoa port and it is not being considered). Ok. 2. KDE can run GnuCash if the Gnome libraries are installed. KDE also has it's own alternatives to GnuCash. Just a thought. 3. The web page idea is FAR more difficult than you may imagine and NONE of the work above even comes close to a HTML/PHP/Perl front end. I've done work on QSF (XML) which *could* be used to render GnuCash (and other QOF) data as HTML for purposes of data mining and customised reports but that's definitely as far as it goes. Hmm, I was hoping it would be possible to use Gnucash via the desktop for one user and via a webpage for another user simultaneously--maybe that is a longer way off than I thought. 2. Mozilla designed for plugins from the very earliest stages, it's not easy to build a system into an existing program. True. 3. Plugins can only go so far and still won't meet everyone's needs. IMHO, it is better to provide easier, more robust access to the data itself and let users handle it in Perl or PHP, Python or whatever. QSF is a flavour of XML that has a Schema and is intended to provide this simple and flexible data access. http://www.data-freedom.org/ Well, the site explains the theory pretty well. However, I am throwing out ideas for consideration to make Gnucash tasty to an enduser/small business owner who isn't a Linux guy--e.g., avoids the command-line and doesn't want to code. What functionality do you want in your module? Well, for one it would be really awesome if the invoice template was similar to iBiz, http://www.iggsoftware.com/ibiz/index.html . My wife uses iBiz. I don't like a lot of it--(it is to click-happy for me), however the invoice template creator is pretty good. It uses a web template like method of specifying where everything goes for an invoice template. Highly flexible, but using a GUI and a template creator. It seems very daunting and time consuming. There's no escaping that one. Developing in gnucash could quite easily consume 150% of your available time. The discipline to control that must come from you, as must the motivation to persist. Most any project is similar that way, isn't it? So I guess it depends on your motivation, your perspective and your itch. ... We each need our own itch for motivation. Are you happier in GUI development or CLI or both? Web dev and backend stuff is where I am most comfortable. What's your itch? Well, I am not sure other than above on invoices and what others have mentioned in this thread. My primary purpose is speaking up is because I want to help enable more productivity and more small business users and hence a better, stronger Gnucash. Derek mentioned that there were enough web programmers. Is there a need for people to port documentation from the dev list and doxygen to the web to help enable new programmers with Gnucash to be productive more quickly? Sincerely, Brian -- Contagious Design! web . design . photo Brian Rose . web programmer (604)-630-2426 . brianATcontagiousdesignDOTnet ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
