On April 6, 2006 08:40 pm, Chris Shoemaker wrote:
> If not, I think the advantage of wider
> editing of the docs out-weighs the disadvantage of having to manually
> reformat them for offline use.
Good point, I think wider editing of the docs is huge and outweighs any
disadvantage I can think of.
On April 6, 2006 07:24 pm, Bengt Thuree wrote:
> On Fr, 2006-04-07, 09:32, David Grant skrev:
> > But why do you even need docbook in the first place? Why not just use
> > mediawiki?
> >
> > I definitely recommend putting all the documentation in some form of
> > wiki or drupal form so that anyone
On Thu, 2006-04-06 at 22:59 +0200, Christian Stimming wrote:
> The latest 1.9.x releases *used* to write a data file that could still be
> read
> by 1.8.12. That was a very convenient way to get used to the new version but
> all the while keep the 1.8.12 version around and working. My data file
On Fri, Apr 07, 2006 at 11:24:46AM +0900, Bengt Thuree wrote:
>
> On Fr, 2006-04-07, 09:32, David Grant skrev:
>
> > But why do you even need docbook in the first place? Why not just use
> > mediawiki?
> >
> > I definitely recommend putting all the documentation in some form of
> > wiki or drupal
On Fr, 2006-04-07, 09:32, David Grant skrev:
> But why do you even need docbook in the first place? Why not just use
> mediawiki?
>
> I definitely recommend putting all the documentation in some form of
> wiki or drupal form so that anyone can edit pages easily.
>
Ok, I am definitely not an expe
Christian Stimming wrote:
> Recently I also investigated the possibility of editing the whole
> "Tutorial Guide" and also the "Help" directly inside a wiki instead of
> the DocBook files. However, that's not quite possible. It is easily
> possible to import an existing DocBook file collection into
On Thu, 2006-04-06 at 22:59 +0200, Christian Stimming wrote:
> The latest 1.9.x releases *used* to write a data file that could still be
> read
> by 1.8.12. That was a very convenient way to get used to the new version but
> all the while keep the 1.8.12 version around and working. My data file
The latest 1.9.x releases *used* to write a data file that could still be read
by 1.8.12. That was a very convenient way to get used to the new version but
all the while keep the 1.8.12 version around and working. My data file in
question is quite simple -- no business features, no stocks, but n
On Thursday 06 April 2006 3:27 pm, Derek Atkins wrote:
> Neil Williams <[EMAIL PROTECTED]> writes:
> > The way QOF handled #include and other library headers in
> > previous versions has led to applications depending on libqof having
> > spurious dependencies and these cause packaging errors. (bin
[Linas, I hope this message reaches you; I'm not sure which email
address works for you; [EMAIL PROTECTED] never seems to get a response.]
For a while now, presently, and especially with the recent work Neil has
done and the gnucash 2.0 release coming up, it would be nice to have a
way to effect (
Boy, do I feel dumb. I usually look around better than I did this time.
Thanks for pointing it out. I guess this will be one more reminder to
RTFFAQ.
digger
On Thu, 2006-04-06 at 10:19 -0400, Derek Atkins wrote:
> GEEZ! Doesn't ANYONE read the FAQ?
>
> http://wiki.gnucash.org/wiki/FAQ#Q:_Runn
Neil Williams <[EMAIL PROTECTED]> writes:
> The way QOF handled #include and other library headers in previous
> versions has led to applications depending on libqof having spurious
> dependencies and these cause packaging errors. (binary X links against
> library Y but does not use any symbol
GEEZ! Doesn't ANYONE read the FAQ?
http://wiki.gnucash.org/wiki/FAQ#Q:_Running_1.9.x_on_Debian.2FUbuntu_crashes_with_.22no_code_for_module_.28g-wrap_gw_standard.29.22.__What_does_this_mean.3F
-derek
Quoting digger vermont <[EMAIL PROTECTED]>:
Hello All,
I had to do a fresh install of my comp
Hello All,
I had to do a fresh install of my computer which meant starting from
scratch building gnucash from svn.
It seems to build and install okay but I get this error when running:
: In procedure scm-error in expression (scm-error (quote
misc-error) #f ...):
: no code for module (g-wrap gw st
The way QOF handled #include and other library headers in previous
versions has led to applications depending on libqof having spurious
dependencies and these cause packaging errors. (binary X links against
library Y but does not use any symbols).
This has been fixed in QOF CVS by preventing Q
15 matches
Mail list logo
