Re: GnuCash page on GO site

[Jody Goldberg <jody gnome org>]

On Sun, Feb 22, 2004 at 09:05:01PM -0600, Linas Vepstas wrote:
> Hi all,
> 
> > > 5/ widgets -- specifically:
> > >    a/ register [or, a generic cell-range editor abstracted which a
> > >       financial-account register could be built on]
> > 
> > My sentiments exactly; I always think of GnuCash and how it could be
> > using Gnumeric-widgets whenever I'm using Gnumeric.  (Holy bejeez I
> 
> Gnucash has a profoundly different model of a 'cell-range' 
> than gnumeric.  Its a huge amount of rather complex, hairy code 
> to get it right. 

Agreed.  Gnumeric's sheet 'widget' (it's actually a FooCanvas Item)
is not generally useful and I'd expect similar limitations for the
GnuCash register.
 
> One thing I fear slightly about this "lets leverage other stuff"
> conversation is a backsliding of features & functions.  GnuCash
> has at various times gotten over-eager developers involved who
> were unaware of existing function and managed to trash it while
> porting to the new 'whiz-bang' interfaces.  Its not quite as 
> catastrophic as a ground-up-re-write (recall the 6-year-long
> netscape-to-mozilla transition), but it is similar, just 
> on a smaller scale.

While there is the potential for some decrease in functionality
initially I'd hope that if there are more of us working to polish
the same pieces we can give individual portions more time.  It's
taken a few weeks of my time to partially rewrite some of gnumeric's
custom toolbar widgets and add GtkAction wrappers with the goal of
supporting editable menus/toolbars one day.  The result is better
than those in gal, but there is still work to do.  If someone from
abi could add their nifty extension to the font name selector, while
others worked on some of the other widgets we could all get
something better sooner.   Sure it's not a panacea, but with decent
communication and some focus I believe it's a win.

 
> For example: gtk2 ctree ... is deprecated.  But the new tree
> functions lack many of the features in the old tree.  I've got one
> app (gnotime, ex-gtt) that has been ported to gtk2 years ago but 
> uses deprecated ctree because of this.  What's worse, the deprecated
> features that gnotime needs also happen to be features that the 
> user-interface-guideline people think are "bad features", and so
> theres this political tension: the missing features can't be added.

So stick with CList.  gtk-3.x is not even a dream on the horizon at
this point.  While I wouldn't advocate using deprecated features in
general, there's no reason not to continue using them in existing
code.  Especially when you've got a good rationale.

We've all been burned by what I'd bet were similar things in the
past.  There is suddenly some momentum here.  Let's see if we can
use it to finally collaborate.