On Sun, Jun 22, 2003 at 01:36:36PM +1000, Ben & Michelle Carlyle was heard to remark: > Hello, > > First up, apologies if I'm inadvertantly breaking any list nettiquite. I'm > using an unfamiliar mail reader[1] and am a little unfamiliar with the list > conventions per se. It appears that your standard way to reply to a message > is as a reply-to-all, so I'm following that convention for now :) I've been
Yes, because many people are people are participating in the conversation, and others are listening. (There are about 500?? subscribers to this mailing list). > playing with the settings in Outlook, and it's promised me that it will wrap > my text at 76 characters. If this, in fact, does not happen I'll look for > alternative ways to do this. It worked great. > reason (excuse? :). Anyway, just as a little feedback when she read the > paragraph above she made a few dirty comments about discriminating against > people who can't see well :) I'm one of them. I bought a 21 inchi monitor and run 1600x1200 and adjust font sizes to match. The icons are not to small, and the fonts look very pretty, cause they're big and have lots of pixel detail. > In other words, it would be nice to be able to use the scheduled transaction > display, or the tax setup display at 800x600, even if it meant reducing the > font sizes. Perhaps this is already possible :) I know its possible in gnome 2 I've forgetten gnome1.4 > ints, text, and timestamp. If timestamp is the only one requiring special > processing you may find that it's not that much trouble to use sqlite. The postgres backend uses stored proceedures to help calculate the account balance. If you have a million transactions, you want to avoid having to add all of them together to get the account balance. > Correct me if I'm wrong, and it's quite likely that I am, but mysql doesn't > have transaction support on it's native tables, does it? No, but for a single-user 'embedded' backend, this isn't needed. For multiple simultaneous users, you'll need something better. > I really think that the current no-transaction load/save > default backend for gnucash is the biggest hurdle to it being a truely We've had arguments about this. I take your position. But appearently some people disagree. Next rule of netiquette: by repeating what you want, over and over and over, you sometimes get your wish. And sometimes you get told to go away. -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
