Re: gnucash.org vs. lists.gnucash.org [was: GnuCash Draft Concept Guide, or, Whose WIki Is This, Anyway?]

[John Ralls]

> On Dec 1, 2017, at 8:25 AM, D via gnucash-devel  
> wrote:
> 
> Certainly. I've just used what my mail program puts in.
> 
> On December 1, 2017, at 8:31 PM, Geert Janssens  
> wrote:
> 
> Oh, David,
> 
> Completely unrelated to this discussion... Can you use gnucash-
> de...@gnucash.org in the future as mail address for the list rather than 
> gnucash-de...@lists.gnucash.org ?
> 
> While both work the one without "list" in the domain is the one the list 
> manager itself promotes. When I do a reply-all on mails sent to gnucash-
> de...@lists.gnucash.org, my mailer automatically adds both addresses which 
> would make the list receive my message twice. I usually try to catch this 
> before I send the mails, but as with my previous mail I do miss it from time 
> to time...
> 

I've got a better and even weirder reason to prefer gnucash-devel@gnucash.org: 
When I send mail to gnucash-de...@lists.gnucash.org and route the mail through 
comcast.net (my ISP) the mail bounces because the terminal comcast
mail server won't talk to lists.gnucash.org. It's perfectly happy to talk to 
gnucash.org even though it's the same computer (the one we fondly refer to as 
"code"). That means I always have to check the CC when I reply-all to make sure 
it's the right address.

Regards,
John Ralls


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

Re: GnuCash Draft Concept Guide, or, Whose WIki Is This, Anyway?

[D via gnucash-devel]

Certainly. I've just used what my mail program puts in.

On December 1, 2017, at 8:31 PM, Geert Janssens  
wrote:

Oh, David,

Completely unrelated to this discussion... Can you use gnucash-
de...@gnucash.org in the future as mail address for the list rather than 
gnucash-de...@lists.gnucash.org ?

While both work the one without "list" in the domain is the one the list 
manager itself promotes. When I do a reply-all on mails sent to gnucash-
de...@lists.gnucash.org, my mailer automatically adds both addresses which 
would make the list receive my message twice. I usually try to catch this 
before I send the mails, but as with my previous mail I do miss it from time 
to time...

Thanks!

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

New boolcolor option

[Jose Marino]

Hi,
I would like some feedback about a new report configuration option that
allows the user to select a color and enable/disable the option at the same
time.
I've posted the current implementation in my repo (
https://github.com/jmarino/gnucash) in branch "new/boolcolor-option".
Link: https://github.com/jmarino/gnucash/commits/new/boolcolor-option
The new option is demonstrated in the cashflow-barchart report.

The motivation came from John Ralls in PR #215, where he suggested letting
the user choose colors in some of the standard reports. The easiest thing
would have been to add color options to the reports but that could create
some repetition in the options dialog. For example, in the
cashflow-barchart report, we would have these options:
  * Show Income
  * Show Expense
  * Show Net Flow
  * Income Color
  * Expense Color
  * Net Flow Color
I thought it would be much cleaner and nicer to combine the boolean and
color options into one.

The new option is called "boolcolor" and it's a combination of a
simple-boolean option and a color option, i.e., a check-button (and label),
and a color chooser button side by side. It is implemented as a new gtk
widget "GncBoolColor" that packs the check and color buttons together. The
gtk code for the new widget was copied and adapted from the GncDateEdit
widget.

From guile, a new boolcolor option is created with:
(gnc:make-boolcolor-option
 section
 name
 sort-tag
 documentation-string
 default-value
 use-alpha)

Where "default-value" is a list containing the state of the check button
and a color string: (#t "#ff") -> enabled, blue.
And "use-alpha" is a boolean, indicating if the gtk color chooser should
use alpha transparency (like in the plain color option). Since the color is
specified as a string there's no need for the range option here. The last
commit in my branch uses this new widget in the cashflow-barchart report as
an example.

So for feedback:
- Is this a good idea? Creating a new widget for this purpose?
- Is the use of the plain color option preferred? Even if it leads to a
busier options dialog.
- Would it be better to extend the existing color option instead of
creating a completely new option and widget? The presence of the check
button would be made optional to recover the functionality of the plain
color option.
- I'm not in love with the name "boolcolor", couldn't think of anything
better.
- What about specifying the color as a string? This is different than in
the plain color option but I think it's more flexible. A color can be
specified as a CSS color with "#ff" or "rgb(0,0,255)" or "blue", and
can be directly passed to be interpreted by the html engine.

Jose

NOTE: I sent this email to the gnucash-devel list a few days ago before I
joined the list. It's been caught in limbo waiting for approval. Just
letting people know in case it shows up twice.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GnuCash Draft Concept Guide, or, Whose WIki Is This, Anyway?

[Geert Janssens]

Oh, David,

Completely unrelated to this discussion... Can you use gnucash-
de...@gnucash.org in the future as mail address for the list rather than 
gnucash-de...@lists.gnucash.org ?

While both work the one without "list" in the domain is the one the list 
manager itself promotes. When I do a reply-all on mails sent to gnucash-
de...@lists.gnucash.org, my mailer automatically adds both addresses which 
would make the list receive my message twice. I usually try to catch this 
before I send the mails, but as with my previous mail I do miss it from time 
to time...

Thanks!

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

Re: GnuCash Draft Concept Guide, or, Whose WIki Is This, Anyway?

[Geert Janssens]

David,

I agree this wasn't handled as it should have been. My apologies for that even 
though I'm not directly responsible for it.

I was and still am in favor of removing these pages and I appreciate the 
creative solution you applied as a compromise.

I don't know why Frank decided to revert your changes without any prior 
discussion or why he insists on keeping those pages around. I'll let him 
clarify that part.

I understand your desire for more clear procedures. I don't know what to 
propose unfortunately. On my own here I have been considering what kind of 
policy could work for a group of volunteers who choose to spend their free 
time on the project.

What we have now (a weak consensus based policy) has worked most of the time. 
But it falls flat as soon as a conflict arises. Is this out of fear of losing 
a precious volunteer or rather because the other volunteers prefer to focus on 
things they enjoy doing rather than resolving conflicts ? Perhaps a bit of 
both.

So what could work in a volunteer based community ? It should be something 
that takes little time and effort in general of all parties involved 
(volunteers don't have much time or energy to spare aside from the real 
contributions they want to make).

I'm open to suggestions at this point.

Regards,

Geert

Op vrijdag 1 december 2017 04:57:38 CET schreef David T. via gnucash-devel:
> Frank,
> 
> I am struggling right now to find the right way to bring up the issue of the
> Gnucash Draft Concept Guide, which still resides on the wiki.
> 
> As you know, I have proposed on numerous occasions (most recently, two and a
> half weeks ago) to have these pages removed from the wiki, since they are
> out of date, inaccurate, poorly written, superceded, and can turn up in
> search results, giving users incorrect information about Gnucash and its
> features and functions.
> 
> In that recent thread, four people responded to my request to remove the
> Draft Concept Guide. Only you appeared to support retaining these pages,
> although your primary concern was with the mechanical aspects of Google’s
> search algorithm, upon which I have no expertise to comment. (I will note
> that fixing one search engine result set does not preclude some OTHER
> search engine now or in the future from finding and returning these pages
> despite your best intentions).
> 
> You actually offered to move these pages to your own user area, but John
> noted that might not actually hide the results.
> 
> Two days ago, I went to the wiki to search for information about creating
> reconciliation reports in response to a question on the user list, and when
> I entered “reconciliation” into the wiki’s OWN search box, 4 of the first 5
> hits were for the Draft Concept Guide.
> 
> Since there had been no support for your position to keep the pages, and
> since you had had two and a half weeks to take whatever action you had
> proposed to do (and not taken any), I felt it was time to address the Draft
> Concept Guide issue directly.
> 
> I did not delete the pages outright (since I do not have the rights to do
> that), but I did what I considered to be the next best thing, which was to
> replace all the text in those pages with the latin nonsense that printers
> have used for hundreds of years to mock up page layouts (“Lorem ipsum”). I
> even made sure to retain the various structural elements in the pages,
> going so far as to replace headings and bullet points with latin phrases of
> similar length.
> 
> Since, as far as I understand, your only reason for retaining these pages is
> to serve as some sort of model for the Gnucash community to use for wiki
> pages, my technique allowed these model pages to be retained *without*
> their turning up in any search results, anywhere. So, that’s the best of
> both worlds, right?
> 
> Apparently not, as within hours, you had gone and reverted all my changes.
> 
> So, I have a few questions to ask of you, Frank, and of the community.
> 
> 1) First, Frank: What exactly is so special to you about these pages? Why do
> you insist that they remain forever on the wiki? The only reason I have
> heard from you is this idea that the pages could provide wiki page template
> examples. But, my most recent changes preserved the template aspect without
> retaining the problematic language—and you still reverted the changes. So,
> there seems to be something *else* with these pages that makes you feel so
> protective. What is it? My recent changes seem to prove that there is
> something in the text itself that you are attached to. Can you explain
> clearly what that attachment is?
> 
> 2) Frank, in the past, you have chastised me for reverting changes that you
> had made on wiki pages, and informed me that it is considered rude to do
> so. So, why are you so consistently rude to me? This is not the first time
> that you have reverted my changes.
> 
> 3) To the community: Whose Wiki is this, anyway? I have presented to the
> community on separate 

Re: GnuCash Draft Concept Guide, or, Whose WIki Is This, Anyway?

[Adrien Monteleone]

David,

I recall replying to such a thread and being in agreement. Perhaps there was 
more than one.

I see no reason to keep out of date pages on a wiki. The entire purpose of a 
wiki is to be able to keep it up to date and to have multiple editors.

If a static info section is desired, then a basic HTML page can be used instead.

The wiki software has ‘templates’ as a feature. We can define our own. We don’t 
need to keep old pages around as ‘samples.’

As for ALL search engines, someone just needs to do two things:

1. remove ALL links TO the outdated pages if they will not be updated. 
(otherwise, just update them)
2. insert a NOFOLLOW rule in the robots.txt file for those pages. (again, only 
if they won’t be updated)

Optionally, a permanent redirect rule on those pages can be added to the 
.htaccess file for the site.

Doing all three would prevent any search engine from finding the pages. The 
only way they could be found is via a scraper or trying to hit the page 
directly via it’s URL - very unlikely.

If that’s still not enough. The pages or section in question could even be 
restricted with a DENY rule in .htaccess and limited only to certain IP 
addresses or people with a certain password. That way, even a scraper or 
someone entering the URL directly can’t see them unless they are so privileged.

But really, the pages should just be removed. A wiki is not a place for a 
‘working draft’ especially one that is so out of date. There are documentation 
procedures and a place for the working copy to be stored.

Regards,
Adrien

> On Nov 30, 2017, at 9:57 PM, David T. via gnucash-devel 
>  wrote:
> 
> Frank,
> 
> I am struggling right now to find the right way to bring up the issue of the 
> Gnucash Draft Concept Guide, which still resides on the wiki.
> 
> As you know, I have proposed on numerous occasions (most recently, two and a 
> half weeks ago) to have these pages removed from the wiki, since they are out 
> of date, inaccurate, poorly written, superceded, and can turn up in search 
> results, giving users incorrect information about Gnucash and its features 
> and functions. 
> 
> In that recent thread, four people responded to my request to remove the 
> Draft Concept Guide. Only you appeared to support retaining these pages, 
> although your primary concern was with the mechanical aspects of Google’s 
> search algorithm, upon which I have no expertise to comment. (I will note 
> that fixing one search engine result set does not preclude some OTHER search 
> engine now or in the future from finding and returning these pages despite 
> your best intentions). 
> 
> You actually offered to move these pages to your own user area, but John 
> noted that might not actually hide the results.
> 
> Two days ago, I went to the wiki to search for information about creating 
> reconciliation reports in response to a question on the user list, and when I 
> entered “reconciliation” into the wiki’s OWN search box, 4 of the first 5 
> hits were for the Draft Concept Guide.
> 
> Since there had been no support for your position to keep the pages, and 
> since you had had two and a half weeks to take whatever action you had 
> proposed to do (and not taken any), I felt it was time to address the Draft 
> Concept Guide issue directly. 
> 
> I did not delete the pages outright (since I do not have the rights to do 
> that), but I did what I considered to be the next best thing, which was to 
> replace all the text in those pages with the latin nonsense that printers 
> have used for hundreds of years to mock up page layouts (“Lorem ipsum”). I 
> even made sure to retain the various structural elements in the pages, going 
> so far as to replace headings and bullet points with latin phrases of similar 
> length.
> 
> Since, as far as I understand, your only reason for retaining these pages is 
> to serve as some sort of model for the Gnucash community to use for wiki 
> pages, my technique allowed these model pages to be retained *without* their 
> turning up in any search results, anywhere. So, that’s the best of both 
> worlds, right?
> 
> Apparently not, as within hours, you had gone and reverted all my changes.
> 
> So, I have a few questions to ask of you, Frank, and of the community.
> 
> 1) First, Frank: What exactly is so special to you about these pages? Why do 
> you insist that they remain forever on the wiki? The only reason I have heard 
> from you is this idea that the pages could provide wiki page template 
> examples. But, my most recent changes preserved the template aspect without 
> retaining the problematic language—and you still reverted the changes. So, 
> there seems to be something *else* with these pages that makes you feel so 
> protective. What is it? My recent changes seem to prove that there is 
> something in the text itself that you are attached to. Can you explain 
> clearly what that attachment is?
> 
> 2) Frank, in the past, you have chastised me