G2 Testing - Register Toolbar
More testing on the accounts register: - When opening a register the focus is on the Save button. Tabbing forward from there changes the focus to the Accounts tab. Tabbing backward from the Accounts tab changes focus to the Transfer button. Only the Transfer and Save buttons can be reached via keyboard commands. I was expecting that I could tab through all of the buttons but maybe they should only be accessible with the mouse? - Save, Close, Delete, Cancel, Blank, Split, Jump button work OK As mentioned before, the Blank, Split, and Transfer button share the same icon. The Schedule button appears to work but I didn't test it. Most of the scheduled transactions were tested earlier. - Duplicate button When opening the calendar to select a date the calendar doesn't get the focus. You're only able to select a date with the mouse but not with the keyboard. Sample: http://www.englisch.us/~volker/G2_Testing/DupCal.jpg When duplicating a transaction the 'Duplicate this Transaction' window opens with the date highlighted. Changing the focus to the number field either by tabbing or clicking with the mouse keeps the date highlighted. - Transfer button When entering a transfer the same behavior for the date field in regard to the calendar as explained under Duplicate button exists. When searching for an account by typing its name, a little window with a single text entry field appears somewhere on the screen listing what has been entered. After a few seconds it disappears. Due to the indentation of the sub-accounts the account names in the account list are getting cut off while there is plenty of space reserved for the account description. Sample: http://www.englisch.us/~volker/G2_Testing/Transfer.jpg See how the highlighted account name is cut off. I would think there should be more space available for the account name and less for the account description. There are no tool tips for the fields under 'Basic Information' (but maybe that's too basic anyway) - Date field in Register When the register window is fairly small (around 5 transactions) and one tries to change a date by selecting from the calendar the calendar window may get cut off and doesn't display an entire month. Sample: http://www.englisch.us/~volker/G2_Testing/RegCal.jpg Please note: This does not happen with the calendar window for the duplicate transaction. Also, opposed to the behavior of the duplicate transaction calendar window the focus _does_ change to the calendar here. - Enter a transaction When entering a transaction with a new account for the transfer field, the message box comes up asking to create the account with the two buttons 'No' and 'Yes'. When tabbing between these buttons a third focus puts the cursor to the text of the question rather then switching between Yes and No. - Splash Screen This is not related to the account register but I don't want to forget. When starting GC the splash screen gets created in the middle of the screen. During the load of the modules it slightly changes (an extra border is added on both sides) and it appears as if the splash jumps a little bit. The sample shows the screen as it gets created and after it changed: http://www.englisch.us/~volker/G2_Testing/Splash.jpg I have another general question for the developers: I often see messages on the console like this ALSA lib confmisc.c:955:(snd_func_refer) error evaluating name ALSA lib conf.c:3479:(_snd_config_evaluate) function snd_func_refer returned error: Permission denied ALSA lib conf.c:3948:(snd_config_expand) Evaluate error: Permission denied ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown PCM default Usage:program_name [address][:port] Would you like me to report these as well or should I ignore them at the moment? -- Thanks Volker Englisch mailto:[EMAIL PROTECTED](h) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: G2 Testing - Register Toolbar
On Fri, Oct 28, 2005 at 01:21:53AM -0400, Volker Englisch wrote: More testing on the accounts register: - When opening a register the focus is on the Save button. Tabbing forward from there changes the focus to the Accounts tab. Tabbing backward from the Accounts tab changes focus to the Transfer button. Only the Transfer and Save buttons can be reached via keyboard commands. I was expecting that I could tab through all of the buttons but maybe they should only be accessible with the mouse? They should be tab-able. I have another general question for the developers: I often see messages on the console like this ALSA lib confmisc.c:955:(snd_func_refer) error evaluating name ALSA lib conf.c:3479:(_snd_config_evaluate) function snd_func_refer returned error: Permission denied ALSA lib conf.c:3948:(snd_config_expand) Evaluate error: Permission denied ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown PCM default Usage:program_name [address][:port] Would you like me to report these as well or should I ignore them at the moment? I don't think these are related to Gnucash. Maybe a bug in ALSA or a permissions problem, but that's just a guess. -chris -- Thanks Volker Englisch mailto:[EMAIL PROTECTED](h) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
RE: G2 Testing - Register Toolbar
Would you like me to report these as well or should I ignore them at the moment? I don't think these are related to Gnucash. Maybe a bug in ALSA or a permissions problem, but that's just a guess. -chris Oh, there are plenty of other messages that are definitely related to Gnucash. The messages I listed just were the latest once I had on my screen. Thanks Volker Englisch Contractor - MSD, Inc. phone: (301) 496-0102 (OTSA) mailto:[EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: G2 Testing - Register Toolbar
on 10/28/2005 12:22 PM Andrew Sackville-West said the following: I know we're OT here, but are you getting any system beeps or other sounds when you tab around in your testing? That may be what is generating those ALSA errors. just a thought I actually don't know. The kids are in bed when I'm working on the computer so I have my speakers turned off. :-) My question was actually not so much in the direction of 'How to fix this' but more like 'Would it help the devs to see these?' Thanks Volker Englisch mailto:[EMAIL PROTECTED] (h) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: G2 Testing - Register Toolbar
I know we're OT here, but are you getting any system beeps or other sounds when you tab around in your testing? That may be what is generating those ALSA errors. just a thought A Englisch, Volker (NIH/NCI) wrote: Would you like me to report these as well or should I ignore them at the moment? I don't think these are related to Gnucash. Maybe a bug in ALSA or a permissions problem, but that's just a guess. -chris Oh, there are plenty of other messages that are definitely related to Gnucash. The messages I listed just were the latest once I had on my screen. Thanks Volker Englisch Contractor - MSD, Inc. phone: (301) 496-0102 (OTSA) mailto:[EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
G2 Testing
Volker has been so inspiring that I've gotten motivated to do some testing. These items are in no particular order. 1) Mouse wheel is inconsistent: When all the accounts are expanded in the accounts tab so that they fill the window, the mousewheel behaves as expected by scrolling. This does not funtion in the register. 2) Register Default Preference: changing the register default style does not apply until the current register tab is closed and reopened. Any open register tabs must be reclosed and re-opened for this to apply. IOW, it is possible to have multiple registers open with different styles. This is surely counter-intuitive at a minimum. 3) Reports: Income Expense: Income Expense Chart === unable to push bar chart. no corresponding terminal messages. adjusted report options does not affect. 4) selecting an account from within a report using the hotlinks increases size of the window by a few pixels each time. just a few. more later A ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: G2 Testing
On Fri, 2005-10-28 at 09:41 -0700, Andrew Sackville-West wrote: Volker has been so inspiring that I've gotten motivated to do some testing. :-) 1) Mouse wheel is inconsistent: When all the accounts are expanded in the accounts tab so that they fill the window, the mousewheel behaves as expected by scrolling. This does not funtion in the register. I committed a fix for this on the 23rd. How recent is your tree? 2) Register Default Preference: changing the register default style does not apply until the current register tab is closed and reopened. Any open register tabs must be reclosed and re-opened for this to apply. That's why these settings are on the Register Defaults page instead of the Register page. :-) Yes, I know just about everything else is instant apply. I was using the Default keyword to distinguish between instant apply settings and not instant apply setting. E.G. The accounts page has a Default Currency that only applies to newly created accounts, the scheduled transaction page has a defaults section that only applies to newly created scheduled transactions, etc. Is there another label or phrasing I could use to make it clearer that these settings only apply when a register page is created? IOW, it is possible to have multiple registers open with different styles. This is surely counter-intuitive at a minimum. I do this fairly often where I'll put one register in journal mode while all the others are in basic mode. It is possible to have these setting instantly affect all open registers. The problem comes when you start looking at which registers are in their default opened state and which have been modified by the user from the View menu since they were opened. Should you apply the new settings to all open registers or only those in the default state? What's the criteria for when you do and don't modify a register? I'd prefer to leave this as just a setting for newly opened registers. 4) selecting an account from within a report using the hotlinks increases size of the window by a few pixels each time. I don't see this problem on my FC4 system. What distribution are you using? Also, which report was this so I can make sure I'm accurately recreating the scenario where the problem occurs. David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: G2 Testing
David Hampton wrote: 1) Mouse wheel is inconsistent: When all the accounts are expanded in the accounts tab so that they fill the window, the mousewheel behaves as expected by scrolling. This does not funtion in the register. I committed a fix for this on the 23rd. How recent is your tree? oct 18. cool. I'll pull down a new one and rebuild. 2) Register Default Preference: changing the register default style does not apply until the current register tab is closed and reopened. Any open register tabs must be reclosed and re-opened for this to apply. That's why these settings are on the Register Defaults page instead of the Register page. :-) Yes, I know just about everything else is instant apply. I was using the Default keyword to distinguish between instant apply settings and not instant apply setting. E.G. The accounts page has a Default Currency that only applies to newly created accounts, the scheduled transaction page has a defaults section that only applies to newly created scheduled transactions, etc. Is there another label or phrasing I could use to make it clearer that these settings only apply when a register page is created? IOW, it is possible to have multiple registers open with different styles. This is surely counter-intuitive at a minimum. I do this fairly often where I'll put one register in journal mode while all the others are in basic mode. It is possible to have these setting instantly affect all open registers. The problem comes when you start looking at which registers are in their default opened state and which have been modified by the user from the View menu since they were opened. Should you apply the new settings to all open registers or only those in the default state? What's the criteria for when you do and don't modify a register? I'd prefer to leave this as just a setting for newly opened registers. okay that makes sense. I only just started diving in and hadn't yet seen the view menu setting for that. 4) selecting an account from within a report using the hotlinks increases size of the window by a few pixels each time. I don't see this problem on my FC4 system. What distribution are you using? Also, which report was this so I can make sure I'm accurately recreating the scenario where the problem occurs. debian unstable. this is Reports=Income Expense=Income Statement. The behavior is consistent for me. I have the accounts tab and the one report open. The first clicked link opens fine. Each subsequent one pushes the bottom of the window down a few pixels. Also, the little diagonal lines for stretching the window are not being redrawn in the right spot. I'll try to get some screenshots up. David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] Chris Shoemaker's budget code
On Friday 28 October 2005 1:41 am, David Hampton wrote:
+/* Define the QofObject. */
+/* TODO: Eventually, I'm think I'm going to have to check if this struct
is + complete.
See below. There are a few omissions from the QOF handling code, one or two
major but mostly minor.
Also, do we need one of those QofParam thingys? */
IMHO, Yes. (It's called a QofClass definition!) Define which parameters of
your object can be queried - maybe to get the list of categories, names,
descriptions, get the individual and total (sum) variances from budget.
Whatever else you decide, *all* qofclass definitions need to specify
QOF_PARAM_BOOK and QOF_PARAM_GUID and the sentinel:
{ QOF_PARAM_BOOK, QOF_ID_BOOK, (QofAccessFunc)qof_instance_get_book,
NULL },
{ QOF_PARAM_GUID, QOF_TYPE_GUID, (QofAccessFunc)qof_instance_get_guid,
NULL },
{ NULL },
Just providing get functions for, mainly, calculated values that could be
useful in generic user-level queries, as supported by cashutil and at some
point, in gnucash. This makes it easier for the user to find out which budget
categories are overspent by more than a certain %. You can never anticipate
all the queries a user will need - that's the entire point of QOF.
I'm pondering about set functions - if there's a role for exporting budgets in
QSF then add a set of parameters that QOF can use to set all critical budget
parameters - a get and a set for those. It might seem strange but in the case
of a husband and wife accounts, it may be important to allow his budgets to
be importable into her file.
The query (get) parameters are more useful right now.
You have various get and set routines already defined in the code - just make
them accessible to QOF. Remember that you can also make static functions
available to QOF (because the QofClass is static) so there's no need to ever
change the API just to add a new parameter. If your API func isn't suitable
as a QofAccessFunc or QofSetterFunc (because of extra arguments or a
different return type), create a static version that is compatible and
reference that in QofClass.
I'll take a look once I've had time to negotiate the hurdles of merging this
changeset into my own trees!
;-)
+static QofObject budget_object_def =
+{
+interface_version: QOF_OBJECT_VERSION,
+e_type:GNC_ID_BUDGET,
+type_label:BUDGET,
A mixed case string may be more appropriate. Budget
I know that's the same as GNC_ID_BUDGET but that's OK.
(That may change in libqof2).
+create:(gpointer (*)(QofBook *)) gnc_budget_new,
Why does this need a cast, Chris? (Hint: It doesn't!)
GncBudget*
gnc_budget_new(QofBook *book)
That's the same prototype as Trans and Account or gncInvoice:
GncInvoice *gncInvoiceCreate (QofBook *book)
Those use a simple create:
create: (gpointer)gncInvoiceCreate,
+is_dirty: NULL,
qof_collection_is_dirty could be used.
+mark_clean:NULL,
qof_collection_mark_clean ditto.
+foreach: qof_collection_foreach,
+printable: NULL,
gnc_budget_get_name could serve for a printable func - it may need a simple
wrapper, see the some of the printable functions in the business code or use
this example:
printable: (const char* (*)(gpointer)) xaccAccountGetName,
+/* CAS: ISTM, it would make more sense to put the typedefs in their
+ corresponding header files, (e.g. Account.h), and to #include all
+ the engine API header files right here. After all, when I jump to
+ the definition Account, I want to end up in Account.h, not this
+ file, like I do now.
The only downside with that is having to include all those headers in other
files that currently just user gnc-engine.h and don't actually need the
object functions.
I used gnc-engine.h because that is where the core object typedefs are
specified:
typedef struct account_s Account;
Those would naturally go into their respective object headers with your
suggestion.
The current file gives us limited includes - OK it brings in QOF but it does
not bring in all the engine objects (which would require QOF anyway!)
+ Also, as it is now, if I want to use the engine api, I need to
+ include this header, plus all the other engine headers for the
+ types whose functions I call, so this header is providing almost no
+ benefit of aggregation.
It does allow you to not have all the objects in unrelated areas. QOF is
mandatory in lots of sections of the codebase, it's almost as pervasive as
glib, but the core objects are not.
But, if it included all the headers I
+ could just include this file. Or would that cause a massive
+ recompile everytime one engine header changed?
Potentially, yes.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpipyrACVEBf.pgp
Description: PGP signature
Re: Gnucash.org SF link...
On Thursday 27 October 2005 5:30 pm, Stewart V. Wright wrote: Hi, I've just decided to upgrade to the 1.8.12 release and the SourceForge link on the gnucash.org front page seems to be broken. It's old - it should reference the prdownloads subdomain. when SourceForge seems to prefer http://prdownloads.sourceforge.net/gnucash As I said, I'm not sure if this is a SF issue at the moment, or not. AFAICT, it's a gnucash issue. The link is broken, unfortunately, I don't have access to fix it but hopefully one of the developers with access will be able to update it to: http://prdownloads.sourceforge.net/gnucash/gnucash-1.8.12.tar.gz?download -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpS3CgIRTSb4.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash.org SF link...
* Neil Williams [EMAIL PROTECTED] [051028 15:26]: I've just decided to upgrade to the 1.8.12 release and the SourceForge link on the gnucash.org front page seems to be broken. It's old - it should reference the prdownloads subdomain. OK. Glad to know it's not necessarily me. For reference I've added it to the Bugzilla: Bug # 320125. Cheers, S. pgp8xyl0v5fsk.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash design / new features
On Friday 28 October 2005 4:58 am, Brian Rose wrote: (switched to devel) And budget support. Chris Shoemaker has been working on this, it's just been added to G2. Also, what would happen if the engine and functionality was separated from the GUI? I'm working on that. QOF is the GnuCash engine without the financial objects and that has been spun out of GnuCash. http://qof.sourceforge.net/ The financial functionality is being separated from the GUI too - the objects (Accounts, Invoices etc.) are to be shared with cashutil: http://linux.codehelp.co.uk/cashutil/ What needs to follow is the financial logic - only part of which is currently embodied in the objects. CashUtil will be folded into the gnucash sources but ONLY after the Gnome2 port is released. Then provide good docs and an api for building a frontend using a web page, KDE, Gnome2, OS X, 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). 2. KDE can run GnuCash if the Gnome libraries are installed. KDE also has it's own alternatives to GnuCash. 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. ... Secondly why not provide similar support for extensions like Mozilla has, that can be easily installed by the user? 1. GnuCash 1.8 has it's own module system because the Gnome1 libraries didn't do what was needed. Gnome2 libraries (in particular GModule) can but this work has only been done so far for the backends. Plugins for backends are part of my plan for QOF and therefore GnuCash. 2. Mozilla designed for plugins from the very earliest stages, it's not easy to build a system into an existing program. 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/ I would be more open to reading docs and using an API to scratch my itches, compared to downloading the gnucash source and studying it for a while to know how my first attempt at a module is going to affect everything else before I can contribute. What functionality do you want in your module? 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. I have been reading the devel lists for a week now and threads gone and on and on. Is there a benevolent dictator/leader or a specific milestone map or are the developers just doing what seems best to each of themselves? The map at the moment is G2. Discussions are ranging over tools and philosophies but that is all about the future. There has been a long standing need to move away from CVS but it cannot start until G2 is sorted out. However, the discussions upon what to use instead and how gnucash development should be organised after G2 have provoked marked differences of opinion between the current group of active developers. As for each to his own, there was angst about my work on QOF but despite all the problems that is now done. I am not a GUI programmer, never have been. I work on gnucash because I want to provide easier access to gnucash data, not because I had any designs for a whizzo GUI frontend or even new GUI components. Others are already far better at that than I will ever be. So I guess it depends on your motivation, your perspective and your itch. I work with command-line interfaces (like cashutil) because I dislike the bloat of GUI programming. I have a need for better data access from various devices and situations so I concentrate on QOF, backends, CLI programs and XML. If you want a quick introduction to the fundamentals of gnucash, you could do worse than look at the cashutil code which is currently a very stripped-down CLI version of gnucash. There is a lot more work needing to be done on cashutil. We each need our own itch for motivation. Are you happier in GUI development or CLI or both? What's your itch? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpmuN6ceHpyg.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Doxygen performance issues
How many of us build the Doxygen HTML regularly? I lurk on the doxygen mailing list and the speed of doxygen has come up. There are a few issues we can look at ourselves. 1. Our doxygen.cfg.in is out of date compared to Doxygen itself. Running: $ doxygen -u doxygen.cfg.in updates the config file to your currently installed Doxygen version. 2. In the new config file, there are options available that may speed up our doxygen generation immensely. Currently, it is SO bad that my (admittedly underpowered) FC3 box runs out of memory when processing G2 Doxygen and restarts X! Some of the newer options address these speed / memory issues. The biggest problem is that our config forces doxygen to accumulate all the diffs in memory until dumping the HTML in a single directory. It is in this stage that my FC3 box falls over and I've noticed performance issues on other boxes where large file writes are impaired compared to a desktop box. I'd hope that doxygen would not update the config in such a way as to make it incompatible with earlier versions but I'm cautious about testing any changes on FC3. Would someone with FC3 be willing to do a before and after time-comparison if I send them a doxygen.cfg.in patch? (And let me know if any config options produce errors like Unknown option in config)? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpIon2hWP8L5.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Doxygen performance issues
On Fri, 2005-10-28 at 22:32 +0100, Neil Williams wrote: How many of us build the Doxygen HTML regularly? Semi-regularly. I'd hope that doxygen would not update the config in such a way as to make it incompatible with earlier versions but I'm cautious about testing any changes on FC3. Would someone with FC3 be willing to do a before and after time-comparison if I send them a doxygen.cfg.in patch? (And let me know if any config options produce errors like Unknown option in config)? I don't have an FC3 development system, but I can test it on FC4 if you like. David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Doxygen performance issues
G'day Neil, * Neil Williams [EMAIL PROTECTED] [051028 16:34]: 1. Our doxygen.cfg.in is out of date compared to Doxygen itself. Running: $ doxygen -u doxygen.cfg.in updates the config file to your currently installed Doxygen version. I really think this relates to the question that was doing the rounds recently (I can't remember the answer) relating to the base release version. Has it been updated to FC 2/3/4 or will the G2 branch remain at RH7.3 ? ;-) We need to ensure that the doxygen version is at most the default version for the base release of the G2 port. My FC3 box is running v1.4.4 currently. I notice that the latest release is 1.4.5, but I'm not sure if/when that will be released for FC3... I'd hope that doxygen would not update the config in such a way as to make it incompatible with earlier versions but I'm cautious about testing any changes on FC3. Would someone with FC3 be willing to do a before and after time-comparison if I send them a doxygen.cfg.in patch? (And let me know if any config options produce errors like Unknown option in config)? I'd be willing to help out with this. (Assuming my FC3 box doesn't die like yours does!) Cheers, S. pgpnYc3FN08XG.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash design / new features
On Fri, 2005-28-10 at 18:00 -0400, Josh Sled wrote: On Fri, 2005-10-28 at 22:06 +0100, Neil Williams wrote: On Friday 28 October 2005 4:58 am, Brian Rose wrote: (switched to devel) From where? Where can I see the original message? ...jsled It's in gnucash-user Here's his post: From months of list reading these are things that concern list users 1. End of financial year close issues 2. Invoice printing including font choice and Fancy invoice customisation 3. Connecting with PalmOS 4. Choosing a customer or vendor when doing invoices or payments is clumsy 5. Cheque printing 6. Multi-user version I would have to add to this list Recurring invoices And budget support. Also, what would happen if the engine and functionality was separated from the GUI? Then provide good docs and an api for building a frontend using a web page, KDE, Gnome2, OS X, ... Secondly why not provide similar support for extensions like Mozilla has, that can be easily installed by the user? I would be more open to reading docs and using an API to scratch my itches, compared to downloading the gnucash source and studying it for a while to know how my first attempt at a module is going to affect everything else before I can contribute. It seems very daunting and time consuming. I have been reading the devel lists for a week now and threads gone and on and on. Is there a benevolent dictator/leader or a specific milestone map or are the developers just doing what seems best to each of themselves? Sincerely, Brian -- Contagious Design! web . design . photo Brian Rose . web programmer (604)-630-2426 . brianATcontagiousdesignDOTnet -- Brian [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
