FreqSpec and SchedXaction as QOF objects

[Derek Atkins]

I would do it similar to the way the GncAddress is done.  It's still
a second-class object (i.e. you cannot have a FreqSpec on its own)
but you still have consolidated code to perform the import/export
of the FS sub-object...

Also, when you make these changes you should make them to only HEAD
__OR__ g2.  Pick one and stick with it.  David Hampton performs
monthly (or so) merges from Head up to g2, and if you make the same
set of changes in both branches it makes the merge significantly
more difficult.

Beyond all that, I have no problem with QOFizing FS and SX.

-derek

Neil Williams <linux at codehelp.co.uk> writes:

> I'm considering making FreqSpec a genuine QOF object that can be exported 
> directly to QSF and used in date repeat handling beyond the current 
> implementation.
>
> Specifically, I'd like to be able to handle FreqSpec within applications that 
> use QOF as a library and export to QSF. Currently, I have to export the 
> components of a frequency specification as individual integers and dates. If 
> I give FreqSpec a QofObject definition and a QofClass parameter definition, 
> it can be exported as a reference.
>
> I've already tweaked gnc-date.c to handle UTC time and this will form part of 
> the testing before these changes are committed.
>
> This would make using FreqSpec much easier. At present, there is no way to 
> export a FreqSpec distinct from the main data file - only a human readable 
> string. I'd like to able to export a complete scheduled transaction in QSF as 
> well as handle FreqSpec within QSF itself. That would add a useful export 
> function for scheduled transactions. 
>
> Comments? Problems?

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available