On Fri, 2005-10-07 at 14:57 -0400, Chris Shoemaker wrote: > Well, it meets my needs. I guess we won't know if it meets other's > needs until they try it and tell us.
What's in the tree now is incomplete, and needs to be at least disabled if not removed. It's hard to believe that your implmentation won't need any more work before the 2.0 release... no offense, and I've not seen the code at all, but I just doubt it. If our stated goal for an (overdue) 2.0 release is "gnome2 port with 1.8 feature parity", then it's a distraction to do anything else. I realize there are already other instances of new features in the codebase, but I don't think that's justification of more. I think it should be committed, disabled (maybe debug-enabled), and picked up after G2/2.0. > I haven't removed all use of FreqSpec. Recurrence covers a broader > concept than FreqSpec. (start date) IMO, Recurrence is what FreqSpec > should've been. I think Josh agrees. The goal has always been to have these two systems use the same mechanism. I do agree that Recurrence should replace FreqSpec. > Converting SX to use Recurrence would make for cleaner code, (IMO) a > nicer GUI, and remove at least 2 bugs(*). But, I think that's too big > a job for G2 and also too big to block budgets for. I also think it's > better done incrementally. (Assuming budgets are in 2.0, which I don't think they should be...) I'd be fine if both FreqSpec and Recurrence are in the code at the commit, and frankly even at the release. Ideally, though, the concepts merge ASAP, and certainly not past the following release. I'm happy to handle the SX side of the switch (as I generally need to cleanup the SX code), but I'm not going to do that until after 2.0. ...jsled -- http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
