Re: new release schedule?
There is no secret conspiracy hiding release dates, we just haven't made any yet. We have to look at what we want in 1.8 before we set a hard date for it. Dave, Just a heads up, The company that I work for and I have decided to make an amicable split. This will happen shortly, probably before the fourth of July. At that point in time until some distant unknown date in the future, my Sun Ultra will be in storage and I will not be able to assist with the Gnucash project. When I can get on my feet again I'll be back to help out. In the meantime, if anyone knows of anyone in the Los Angeles area that needs a great Solaris admin, please let me know via private email. thanks, alan -- Solaris Resources (Ultra/Intel) http://www.solarisresources.com ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Problem with Translations
-BEGIN PGP SIGNED MESSAGE- On Sunday 24 June 2001 04:50, Dave Peticolas wrote: On 23 Jun 2001 17:31:10 +0200, Christian Krause wrote: After setting LANG=de_DE only some parts of gnucash (1.6.0) are translated in german. I'm not sure why you aren't seeing the right strings. On my system with LANG=de_DE, I see the correct translations in the menu. On my system with LANG=de_DE I see all the correct translations, too. Christian, perhaps you have an old message catalog (of version 1.4.x) still around? So that all the new strings aren't translated? A strong hint for that would be if all the report titles (e.g. Asset Piechart) are *not* translated. Christian Stimming -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) iQCVAwUBOzW1sWXAi+BfhivFAQEiHQQAimGPI7g4/1vVKGpUm3o93vkaNly8OazJ ypNPpY0u0Z46gE9SY1jZVWJl0M1WtrErfwfHyyteJd+VHaE5shOShWVhZ2va3Umf gju0HXo6f5uHx1rBWkp5Zr31OseoaUVgmtCGDon+bFicc4FBrxYMxHT66uu56CUA sosHc4pW4v4= =3c8R -END PGP SIGNATURE- ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
GnuPOS available for download
All, Following from my request for comment, I have arranged for the stuff I have done to be available from ftp.gnucash.org in the /pub/gnupos directory (thanks Dave). This release does compile, but there is not much useful to be gained from doing so. The preferences dialog is mostly blank space, but some of the stuff there does work. Some of it works, but can't be seen because there is (in this version) no output to the screen. There is also a bunch of stuff there that doesn't do anything (yet). Of most use is a chance to look at the glade file to see the user interface I'm suggesting, and a chance to look at what code does exist and see what lunatic things I'm doing that should be changed. Suggestions, feedback, screams of frustration, etc. should probably be sent to me, though I'd like them to stay on this list for a while if people don't mind. Fixes should probably be sent straight to me. If there is sufficient interest I'll set up a list on mail.watersprite.com.au at a later date. I have not made any arrangements for CVSing this as yet. I'll see if there is going to be any input from anyone else first :-). Conrad. -- Conrad Canterford ([EMAIL PROTECTED]) Water Sprite Pty Ltd | Watersprite Pty Ltd: GPO Box 355, | - Australian Tour and Event Management (ATEM) Canberra, ACT 2601 | - Ticketing Division. Mobile: +61 402 697054 | - Catering Services Division. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
PostgreSQL backend versus FreeBSD
So I felt a bit masochistic today and decided to have another go at building everything. So far the biggest problem has been the dependency on non-standard functions like atoll and stpcpy. atoll is easy to replace, since strtoll is ISO C compliant (C99). stpcpy is a bit more difficult since it's used in various shlibs that are part of gnucash (so it's not a matter of including a copy of it in one place. config.h is included multiple times in various source files (ew) so one can't put a copy of stpcpy there (more correctly in config.h.bot). The irony is amusing, since stpcpy is actually tested for, but used unconditionally. Of course a decent string class wouldn't hurt either - alex ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: PostgreSQL backend versus FreeBSD
On 23 Jun 2001 17:50:23 -0700, Alex Zepeda wrote: So I felt a bit masochistic today and decided to have another go at building everything. So far the biggest problem has been the dependency on non-standard functions like atoll and stpcpy. atoll is easy to replace, since strtoll is ISO C compliant (C99). atoll is actually C99 as well, but there might have been a missing #include issue. Anyway, atoll is obsolete so I will replace its use with stroll. stpcpy is a bit more difficult since it's used in various shlibs that are part of gnucash (so it's not a matter of including a copy of it in one place. config.h is included multiple times in various source files (ew) so one can't put a copy of stpcpy there (more correctly in config.h.bot). The irony is amusing, since stpcpy is actually tested for, but used unconditionally. And you shouldn't put function definitions in header files anyway. There is a autoconf mechanism for replacing functions that aren't found. I will see about using that, or just defining our own. thanks, dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Request for comment: GnuPOS - A Point-Of-Sale program
On Sat, Jun 23, 2001 at 07:13:11PM +1000, Conrad Canterford wrote:
| I have started development of a point-of-sale program. I'll spare you
| the long story, but suffice to say that I've used QuickPOS (the
| point-of-sale offering from Intuit/Quicken) and its got holes you can
I've never seen QuickPOS, so I'm curious... I'm guessing it's a
Windoze-based program which provides a full-screen user interface for
the management and operation of a point-of-sale environment. To this,
it provides transaction entry [and eventual payment processing], and
integration with a product database. Since it's got a product list,
it may also perform inventory tracking and ordering...?
| WHAT I WANT
| - interface to gnucash ('cos that is where my accounts are).
What form does this interface take? Does this mean that transactions
entered in GnuPOS show up in the appropriate registers in GnuCash... and
other registers exist in those books for dealing with non-POS business
expenses [like rent/utilities bills and paychecks and such]?
| - configurable gui ('cos not everyone wants things looking the same).
What do people really want to configure in the UI? Seems like they'd
mostly want to customize logos and colors, and maybe some customization
of transaction flow... go from the ring-up screen to a payment-type
screen, then to a receipt/finish screen. Some installs might want a
customer information screen in there, or maybe a rewards-program
screen in the mix... does this seem right?
With respect to this, I'd say that customer information/loyalty tracking is
probably an important [maybe future-] aspect of a POS system. Security is
very important, here, depending on the nature of the information being
collected.
| produces (this should probably also log to a file). The right-side pane
| is intended as a help/prompt/message window. The stuff output to either
| will be programmable.
Seems like it should simply be configurable for most applications...
| - Most of the functionality to resize works mostly ok for what I've
| done, but it needs cleaning up. There are no doubt other options I've
| not considered that could be added.
OT: seems like a springs-and-struts layout option wants to exist in GTK...
but I digress.
| - After a (miniscule) amount of discussion on irc and with friends, I
| have decided an xml-format file is the go for keyboard programming,
| using a state machine setup. I'm not sure how to explain this, so just
| throw ideas at me, and I'll add/change stuff that seems interesting. It
| is my intention that *all* operation go through the state machine (in
| other words, I want no automatic things that happen - everything
| should happen or not happen according to the programming).
At the same time, you don't want each user to have to go through a large
amount of work each time re-creating the stock screens, and especially
their input-handling. I'm thinking here that you want to major elements
in the state-machine description/configuration file.
. Stock screen with configuration/modification descriptions.
. Novel screen definitions, which become/create an Identifier for the
state machine.
Similarly, there should be a simple way for the standard keys/transitions
to be used... default actions, perhaps.
Seems like out of that you end up with a set of widgets like item
entry and name/address entry that can be combined to create screens,
and these have standard navagition and navigational transitions in the
state-machine file.
Said another way, the state machine XML file for a really standard POS
environment shouldn't need to contain anything more than the customization
elements [logos, colors, c].
Just a few other stock widgets you might consider:
. appointment setup
. customer contact information entry/modification
. order/purchase-order generation [for ordering from suppliers]
. inventory lookup
. I'm thinking video store title-lookup
. I'm also thinking we expect this thing we're out of to be delivered
on Tuesday lookup.
| - ultimately, some way is going to have to be found to encrypt the data.
This might devolve into just use a cryptographic file system argument
at some point. OTOH, it's nice not to have that dependency, especially
if the focus is on simplicity for the probably-non-technical end-user.
OTOOH, if the idea is a turn-key system installation, the cryptographic
file system can already be setup and hidden from the end-user.
The standard issues apply here: it should be strong enough that losing the
password will make the data unreadable [all security _does_ rest in the
key], but some procedure exists for a lost key to be recovered. Maybe this
is where a trusted third party can come into the picture, to hold one half
of a key-share that can only be combined with a non-secret key-share that
the user holds [and can write down or whatever w/o compromising security],
which would allow the user to prove identity to the third-party in order
to get their keys back.
The
Re: Editing the tax report
Actually, the tax category specific stuff are the files:
src/scm/report/txf-export.scm and src/scm/report/txf-export-help.scm These
are just lists with the details of the categories and the help. The txf (Tax
eXport Format) has allocated codes for non-US use, but whether any have
actually been defined and are in use for other countries, I really can't tell
you.
If you don't need the txf export feature, you can just tag any account with
the Tax Related boolean, and generate your report.
Gilligan (I wrote the Tax report)
Christian Stimming wrote:
-BEGIN PGP SIGNED MESSAGE-
On Friday 22 June 2001 12:21, Felgentraeger, Marcel wrote:
I just wondered if there is a way to adept the tax report to the country
you live in? In my case this would be Germany
and as far as I have seen, there are many taxes and whatsoever built in
to the default report, that it is more or less
useless to me.
Is it possible for me to edit the categories of the default report, so
that I can use it for my purposes? Has somebody out there
started doing this :)
As far as I know, nobody in Germany has started working on the tax-related
reports and structures. Since I don't know anything about taxes here
(.de), I won't be able to do it either. So, if you like to see it in
GnuCash you are more than welcome to implement that... However, that
would require some programming skills, most notably in the programming
language Scheme (a LISP dialect). You then would edit/extend the file
src/scm/report/taxtxf.scm directly and/or add a new report in that
directory.
Christian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
iQCVAwUBOzNT8mXAi+BfhivFAQGPygQAsnxBn2Ienl4RSg7YaswlEhjpv5XV2Hp+
IaQkfuB49nq6IC5S63DhduM/hIoxusrEPbPwjzfWetciE1hWZ7GtyTKd2Ujt6E0l
/YhFY8ruczMGygCD87C2sO6HcUoZXHVuUyJmnfQp04ZYsu6AKU08B2/1fo4xzpBa
rtFZOaVh03E=
=D5+k
-END PGP SIGNATURE-
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
--
Gilligan|__o .oooO
/| _ \,_ ( )
/p|\(_)/ (_) \ ( Oooo.
/ | \ \_) ( )
) /
[EMAIL PROTECTED] (_/
[EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scheduled transactions
On Mon, Jun 25, 2001 at 12:13:11AM -0400, [EMAIL PROTECTED] wrote: | I've been playing with the scheduled transactions in CVS for a bit. | I couldn't get the instantiation UI to actually create transactions in | the specified accounts. Am I missing something, or is this just not | supposed to be working yet? Still, it's good to start seeing some code. I've seen it create the transactions, but I haven't thoroughly played with it; it's definitely not finished. I think it'll have a big problem with 'once' transactions. My present tree [which I hope to ./make-gnucash-patch tonight] has many fixes for recurrance-frequency state saving/restoring from the UI, which allows me to better play around and test the since-last-run stuff, which is the next big thing to do... I hope to get to this tonight, but it doesn't seem highly probable... probably next weekend. | My initial impression is that I think you have way too much UI. I like UI. ;) More seriously, I like visibility. I want a single dialog which shows me all the relevant info about a thing, in this case the scheduled transaction object. I don't want to cram the editing functionality into the register, as there's just a different thing going on: you're trying to deal with this abstracted-transaction which has some not-fixed transaction data, a recurrance frequency, a start and end date, and a couple of options about the further handling and creation of it. I focused on keeping the GNCFrequency widget as compact as possible, and I think I've gotten it pretty visually small... But maybe this isn't what you mean when you say too much UI... | The scheduled transaction dialog needs to exist for editing, but I | don't think it shouldn't be the primary way to create scheduled | transactions. I'd like to see the Duplicate button in the register | copy the selected transaction to the schedule and pop up the | schedxaction editor to allow the user to specify the frequency. This is indeed the idea ... some sort of button/context-menu-item allowing the user to specify/edit this scheduled transaction, a-la recurring calendar appointments in Outlook/Evo/GnomeCal. I think that both approaches should work... and, in fact, there should be two/three ways to create recurring transactions: 1. Creation through the as-exists SXEditor UI. 2. Right-clicking on any transaction in a register, which will pre-fill most of the data in the as-exists SXEditor, including the template transaction[s] and making a guess at the frequency spec. 3. Analysis of existing/historical data; if (2) is going to have the logic to guess about the template transaction contents and frequency specification, then this should be easy. OTOH, instead of opening up the dozen registers involving scheduled transaction to see what's coming-up to be created, there should be a single dialog [like the list, but improved] which shows exactly what and when things will be created... I've thought about ripping the gnomecal or Evolution week/month-view widgets out for this purpose, but haven't thought about it too much. | Instantiation could be a button or just something that happens on | startup, out to a pre-configurable (not prompted) number of days in | the future. I'm thinking that upon startup, a last-run-date check is made. If the last-run date != today, then we might have scheduled transactions to create... If that list is not empty, then we pop up a dialog similar to the present since-last run dialog. This would allow the user to: . See the transactions that were automagically created [based on the flags in the SXEditor]. . See the transactions that have come due, and will be instantiated; these may require variable bindings, and thus the user is to be prompted for those values. . Maybe, allow the user to select which SXes to defer the creation of. I'm undecided on this functionality... | When run, all the automatic transactions would just | happen, and the manual ones would happen too but with a new s value | in the Reconcile field. s transactions would be included in the | future balance but not the present / cleared / reconciled | balances. I don't think they should be marked 's'... maybe 'f'... but I think even more correct is that they are marked 'n', and are indicated as being in the future because they're past the blue line which denotes 'future' transactions. | A right-click menu item (Enter ?) could convert s | transactions to n. It would be nice if the s transactions showed | with a different background color -- say, light blue as the default. Yes... I was planning on this [right-clicking on future transactions in the register to instantiate them]... check src/doc/TODO-schedxactions. I like the idea of a differently-colored background for doesn't-yet-exist items. | I guess the main reason for that whole dialog-nextrun thing is for | future formula-based transactions. Not solely. I think it's a good thing that unless the user specifies so, there's a
Re: Request for comment: GnuPOS - A Point-Of-Sale program
On Sun, 24 Jun 2001, Josh Sled wrote: | - ultimately, some way is going to have to be found to encrypt the data. This might devolve into just use a cryptographic file system argument at some point. OTOH, it's nice not to have that dependency, especially if the focus is on simplicity for the probably-non-technical end-user. OTOOH, if the idea is a turn-key system installation, the cryptographic file system can already be setup and hidden from the end-user. (Sorry, I've skimmed the discussion so far, so my assumptions may not be 100% correct.) I don't think an encrypted filesystem is the solution. At the very least it doesn't buy you anything.[2] You will necessarily need to encrypt the client-backend communications anyway (assumtion: you ARE planning on multi-station capability yes?) The OpenSSL toolkit exposes several layers: high enough to manage a full-blown SSL session and low enough to provide field level encryption using a variety of techniques and algorithms. But, IIRC, I think the GnuCash team is leaning towards the Mozilla security library because of license issues [1]. I'm not familiar with the Mozilla offering, but it too probably allows field level encryption. John [1] Even RMS (grudgingly) considers OpenSSL linkage into a GPL'd program not a violation of the GPL. He may have changed his mind since, but I believe that was the resolution of the KDE v. OpenSSL GPL dustup. [2] My gut's telling me an encrypted fs would give you a false sense of security as well. The decryption keys are specified during volume mount. Either that or you need to specify them during every I/O operation and I'm not aware of any project to make that API available. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
