Is informaltable OK in documentation

[Chris Good]

Hi Devs,

 

Is it OK to use informaltable in documentation? It hasn't been used anywhere
in the help or guide.

I have many levels and guilabel and emphasis look the same in a browser.

 

Here is an example of informaltable in FireFox (I hope it comes thru OK):

 



 

Any other suggestions for differentiating multiple levels without using
numbering?

 

Regards,

Chris Good

 



smime.p7s
Description: S/MIME cryptographic signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Is informaltable OK in documentation

[Chris Good]

Hi Geert,

I don't know how to check how it looks in pdf/mobi/epub.
Do the pdf/mobi/epub versions get built by the daily build?
Perhaps after it is committed, I could see it in the daily build, and change it 
again if it is not acceptable?

Regards,
Chris Good

> On 11 Oct 2015, at 9:50 pm, Geert Janssens  wrote:
> 
> On Sunday 11 October 2015 20:12:33 Chris Good wrote:
> > Hi Devs,
> > Is it OK to use informaltable in documentation? It hasn't been used
> > anywhere in the help or guide.
> > I have many levels and guilabel and emphasis look the same in a
> > browser.
> > Here is an example of informaltable in FireFox (I hope it comes thru
> > OK):
> > Any other suggestions for differentiating multiple levels without
> > using numbering?
> > Regards,
> > Chris Good
>  
> I didn't see the image in my mail client, but it did show up in the list 
> archives. Visually it looks ok to me.
>  
> How does the pdf conversion handle it ? And mobi/epub ?
>  
> If these are ok, I'm fine with you using this element.
>  
> Regards,
>  
> Geert

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Make fail - No rule to make target COPYING

[Matt Graham]

Ignore this one – figured it out.

I had assumed that the gentoo eclass function for downloading the sources ran 
the autogen.sh script, but no... a misunderstanding of the process on my 
account!

Running ./autogen.sh as per the gnucash build instructions on the web fixed the 
problem.

Cheers,

Matt

From: Matt Graham 
Sent: Sunday, October 11, 2015 4:14 PM
To: gnucash-devel@gnucash.org 
Subject: Make fail - No rule to make target COPYING

G’day all,

I’m a bit of a noob, so please bear with me. I’m trying to compile gnucash 
directly from the git sources. Since I work on Gentoo, I’ve been having all 
sorts of fun with overlays and ebuilds... but that’s another story. 

When it begins the compile phase, I get an error:

make[2]: *** No rule to make target ‘COPYING', needed by ‘all-am’. Stop


Looking through the make file generated by automake and configure, I’m guessing 
that this error relates to the following command:

dist_doc_DATA = \
AUTHORS \
   COPYING \
   ChangeLog \
   ...


The variable “dist_doc_DATA” has a number of values in it, and as far as i can 
see “COPYING” is the only one that isn’t a file present. I also can’t find this 
as a file anywhere within the git sources.

Where should I go from here? Does this sound like a Gnucash bug I should raise, 
or is it likely I am missing something simple?

Thanks and regards,

Matt Graham /|\

P.s. If it helps, my ebuild is on my public gentoo repository, cloneable from 
https://github.com/mattig7/MattsPackages.git
I’m using version 2.6.8 – ignore the other ones, haven’t fixed lots of issues 
with them yet. Just realised that I should have changed to 2.6.9 that can 
be next I guess!
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Is informaltable OK in documentation

[Geert Janssens]

On Sunday 11 October 2015 20:12:33 Chris Good wrote:
> Hi Devs,
> 
> 
> 
> Is it OK to use informaltable in documentation? It hasn't been used
> anywhere in the help or guide.
> 
> I have many levels and guilabel and emphasis look the same in a
> browser.
> 
> 
> 
> Here is an example of informaltable in FireFox (I hope it comes thru
> OK):
> 
> 
> 
> 
> 
> 
> 
> Any other suggestions for differentiating multiple levels without
> using numbering?
> 
> 
> 
> Regards,
> 
> Chris Good

I didn't see the image in my mail client, but it did show up in the list 
archives. Visually it 
looks ok to me.

How does the pdf conversion handle it ? And mobi/epub ?

If these are ok, I'm fine with you using this element.

Regards,

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Is informaltable OK in documentation

[John Ralls]

> On Oct 11, 2015, at 4:34 AM, Chris Good  wrote:
> 
> Hi Geert,
> 
> I don't know how to check how it looks in pdf/mobi/epub.
> Do the pdf/mobi/epub versions get built by the daily build?
> Perhaps after it is committed, I could see it in the daily build, and change 
> it again if it is not acceptable?

Yes, they’re all built in the nightly, though that’s the master branch rather 
than maint so your changes would have to be merged first. Mechtilde Stehmann 
has a bunch of PRs up right now so I’ll probably do a merge this evening.

Or you could build the ebooks locally. See 
http://wiki.gnucash.org/wiki/Documentation_Release_Process#Other_documentation_formats
 for instructions.

Calibre, which you’ll need to make the mobi, will also serve to display the 
mobi and epub.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Is informaltable OK in documentation

[Geert Janssens]

Hi Chris,

I'm also willing to run the test for you if you send me a patch.

Regards,

Geert

On Sunday 11 October 2015 22:34:11 Chris Good wrote:
> Hi Geert,
> 
> I don't know how to check how it looks in pdf/mobi/epub.
> Do the pdf/mobi/epub versions get built by the daily build?
> Perhaps after it is committed, I could see it in the daily build, and
> change it again if it is not acceptable?
> 
> Regards,
> Chris Good
> 
> > On 11 Oct 2015, at 9:50 pm, Geert Janssens
> >  wrote:> 
> > On Sunday 11 October 2015 20:12:33 Chris Good wrote:
> > > Hi Devs,
> > > Is it OK to use informaltable in documentation? It hasn't been
> > > used
> > > anywhere in the help or guide.
> > > I have many levels and guilabel and emphasis look the same in a
> > > browser.
> > > Here is an example of informaltable in FireFox (I hope it comes
> > > thru
> > > OK):
> > > Any other suggestions for differentiating multiple levels without
> > > using numbering?
> > > Regards,
> > > Chris Good
> > 
> > I didn't see the image in my mail client, but it did show up in the
> > list archives. Visually it looks ok to me.
> > 
> > How does the pdf conversion handle it ? And mobi/epub ?
> > 
> > If these are ok, I'm fine with you using this element.
> > 
> > Regards,
> > 
> > Geert

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Where to keep future release note snippets for our future 2.8 release ?

[Geert Janssens]

On Saturday 10 October 2015 15:43:31 John Ralls wrote:
> > On Oct 10, 2015, at 12:26 PM, Geert Janssens
> >  wrote:
> > 
> > (Accidentally sent to gnucash-user, I'll repost here for proper
> > follow-up)
> > 
> > I know this is early. We're not thinking about releasing master yet.
> > 
> > However, I just pushed a commit [1] that changes an option on the
> > transaction report. As a result saved reports/open reports may
> > loose one option when users upgrade (if they had set this
> > particular option).
> > 
> > I believe this is information we should pass on to users that are
> > considering an upgrade so they know they have to check their
> > saved/open reports afterwards.
> > 
> > First question would be: what's the best place to put this info so
> > that most users will find it when upgrading ?
> > 
> > My first guess would be the release announcement. I'm open for
> > other/additional locations.
> > 
> > As we're still far away of the new release I worry we'll forget to
> > add this to the release announcement. So what can we come up with
> > to remind us this has to be added when release is due ?
> 
> The release announcement comes from commit messages, so write a good
> one! You could even say “This needs to be mentioned in the release
> announcement” followed by the text you want in the announcement.
> Since this commit is already pushed, make some trivial change to a
> comment and write a commit note about the lost option on it, using
> the same subject line as your first commit.
> 
> Regards,
> John Ralls

Good idea. Done:
https://github.com/Gnucash/gnucash/commit/83f82040

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Where to keep future release note snippets for our future 2.8 release ?

[John Ralls]

> On Oct 11, 2015, at 10:19 AM, Geert Janssens  
> wrote:
> 
> On Saturday 10 October 2015 15:43:31 John Ralls wrote:
> > > On Oct 10, 2015, at 12:26 PM, Geert Janssens
> > >  wrote:
> > > 
> > > (Accidentally sent to gnucash-user, I'll repost here for proper
> > > follow-up)
> > > 
> > > I know this is early. We're not thinking about releasing master yet.
> > > 
> > > However, I just pushed a commit [1] that changes an option on the
> > > transaction report. As a result saved reports/open reports may
> > > loose one option when users upgrade (if they had set this
> > > particular option).
> > > 
> > > I believe this is information we should pass on to users that are
> > > considering an upgrade so they know they have to check their
> > > saved/open reports afterwards.
> > > 
> > > First question would be: what's the best place to put this info so
> > > that most users will find it when upgrading ?
> > > 
> > > My first guess would be the release announcement. I'm open for
> > > other/additional locations.
> > > 
> > > As we're still far away of the new release I worry we'll forget to
> > > add this to the release announcement. So what can we come up with
> > > to remind us this has to be added when release is due ?
> > 
> > The release announcement comes from commit messages, so write a good
> > one! You could even say “This needs to be mentioned in the release
> > announcement” followed by the text you want in the announcement.
> > Since this commit is already pushed, make some trivial change to a
> > comment and write a commit note about the lost option on it, using
> > the same subject line as your first commit.
> > 
> > Regards,
> > John Ralls
>  
> Good idea. Done:
> https://github.com/Gnucash/gnucash/commit/83f82040

Great, thanks!

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel