On Sunday 17 April 2005 4:01 am, Brian wrote: > On Sat, 2005-16-04 at 17:03 +0100, Neil Williams wrote: > > On Saturday 16 April 2005 4:41 pm, Brian wrote: > > > So far I have found that in entering a new vendor bill that the > > > descriptions have a short term memory. It is only for the current > > > bill! Rarely would I have to enter the same description twice in the > > > same bill, but would enter the same descriptions for the same vendors > > > regularly. > > > > I have the opposite - I regularly enter exactly the same description for > > consecutive dates in one invoice covering, usually, a week. I find it > > quite useful when "Mileage" pops up just by typing M. > > Since the two methods are mutually exclusive, there would have to be a > checkbox/option somewhere to toggle between the two modes of operation.
Not necessarily - the main Register windows have the auto-fill feature that simply allows matching with any entered data. You type enough to identify one particular string and the rest could auto-complete. If a single wheel could be used between business windows, both methods would be supported. Why should a config option be required to disable searching within the current window? > > > The above could be implemented in an xml database for smaller > > > requirements but would be more suitable to a regular database for > > > larger numbers of vendors/items to remember. > > > > Why should it be saved externally at all? If you want that kind of > > functionality, it'd be best to not have to type anything and use the new > > XML to create the invoice / bill for you. > > I thought a separate file would make it easier to edit if changes were > made to a supplier product line. That way the database would not grow > too large if a user had a fairly large number of products they > purchased. No, I think you've missed the method here. The auto-fill is automatically generated from the contents of the appropriate windows and the data that created the window. You enter something once and then whenever you are in a suitable window, that entry is cached direct from the QofBook and used to populate the wheel. As soon as anything in the wheel is a unique match to what you have typed so far, it will be used to auto-complete the rest of the field(s) and the user can ignore such a tip or hit Tab or Enter to accept it. There is no need to save the data within the wheel - it is a cache of existing data that is already saved in the book itself. The auto-fill should almost never be fixed or set in code - it is user-specific and all the data it could ever need already exists in the current data file. What you are thinking of is a fixed inventory database where you are only able to make entries that match an existing inventory item - but inventory is not supported. The cache method is more flexible and allows all users to have a suitable auto-complete experience. If you want inventory, then IMHO, I think GnuCash should use some form of external inventory management that does not add huge amounts of code to the main codebase. What I've outlined below would actually add no code at all - it would simply use what will be available in G2. Use a separate program to make the data available to GnuCash (maybe through QSF) but don't do the actual inventory listings and stock listings within GnuCash. Maybe an external database that can be managed by a separate program - used to create new inventory items, add stock to the system, allocate stock to customers exported from GnuCash and export data that GnuCash can use to create invoices. There may well be an existing program that could do this, what I would envisage is the same kind of interface as I'm creating for GnuCash and pilot-link. When data is required, the two programs communicate using QSF XML. At other times, they are completely separate and can be installed independently. So GnuCash would export Customer data (and indeed import new or modified customer data) to/from this other program using QSF XML. The other program could use a QOF wrapper to parse and process the QSF into it's own data tree. GnuCash would then read data from the program, as XML, to create suitable invoices. Merging the GnuCash data into the existing data is also handled within QOF. My pilot-qof program is reading Expenses, Calendar and Contacts data from the Palm and creating data that GnuCash will be able to use to create invoices. This way, you'd never need access to the actual inventory listings within GnuCash - all the data would be exported direct from the supporting program. The other program would also be able to query Palm data - that could be handy! I feel it is important that users of GnuCash are not required to install inventory management when they don't need it. It should be available - there are queries about it quite often - but it does not need to be within GnuCash itself. (I'm all for making QOF standalone too - currently it's copied into GnuCash as a single lump of C.) > AS for submitting patches, The only recent coding I have been doing is > in python/pygtk this past year. I never have actually done any c > coding :-( > , although I did study it some :-) > , recently I have been studying a > c++ book. The closest thing to this type of program I coded was > specialized inventory/sales tracking programs that I did in a dbaseII > compatible setup about 17 years ago. Excellent! Could that be generalised and made into an inventory-for-anyone program? QOF can provide the generic data handling - all you need to do is decide what parameters unite all inventory objects. http://code.neil.williamsleesmill.me.uk/pilot-qof-7.html http://code.neil.williamsleesmill.me.uk/pilot-qof-5.html "Existing objects need to describe themselves to QOF and this can be achieved by using QOF as an external framework around the existing structs. This is how pilot-link is now able to use QOF. " http://code.neil.williamsleesmill.me.uk/pilot-link.html#CONVERSION The actual C code can be done for you: http://qof-gen.sourceforge.net/php/qof-generator.php (It's early days for qof-gen, there may be a few glitches but it does produce usable code that compiles, at least on Debian.) You can use qof-generator to create suitable objects in C that could either wrap around an existing free software program or be used within a new GPL program. > I did start looking thru some of > the code, but it will take some time to figure out where to begin > considering any changes. Hints are always welcome :) That's fine - at least you are open to learning the code! Start with the doxygen output: http://code.neil.williamsleesmill.me.uk/source.html#DOXYGEN Also see my own site for a potted history of how I started with no knowledge of GnuCash (or GNU/Linux GUI's) just a year ago. http://code.neil.williamsleesmill.me.uk/palm.html#BEGINNING http://code.neil.williamsleesmill.me.uk/startqof.html As Derek knows, I'm still learning - but that has not meant I am unable to contribute. http://www.linux.codehelp.co.uk/ > and don't expect > anything quick. Fine, it took me about four months to get under the skin of GnuCash and about 8 months before I had anything useful to contribute. We all have other jobs, other demands, nobody here works on GnuCash fulltime. > I would rather work on coding some changes, but I have > a mountain of book keeping to catch up on. :-) I think extending the auto-complete within the business code to re-use the cache between business windows would be a very useful addition to GnuCash. If you are also willing to investigate inventory management "by proxy", I'll gladly work with you on the QSF communication. You can extend an existing application (as I have with pilot-link) or you can write a new program. Spend time investigating the options and come back to me when you've got a candidate. If you are willing to put in the time on this one, I am sure we can add inventory management to GnuCash without any bloat. I'll help you in any way I can. -- Neil Williams ============= http://www.dcglug.org.uk/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpBGjfpGNe9w.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
