Re: Strange behavior of GitHub

[Geert Janssens]

Frank,

I read the related conversation on IRC today and you raised the concern of 
creating too many 
remotes in your local repository when applying pull requests from there.

Adding a remote only to apply a pull request is not really necessary and I 
never do it. Instead I 
pull the branch from the PR directly into my local repo using "git pull". It 
takes some shuffling of 
the information provided by the PR.

For example, if you get a PR against the gnucash repo with the following 
message (taken from 
the real PR#163):
0-wiz-0 [1]wants to merge 2 commits into Gnucash:master from 0-wiz-0:master
I would locally run this command (with master being checked out and fully up to 
date with 
master on code.gnucash.org):
git pull https://github.com/0-wiz-0/gnucash master

If master on code.gnucash.org has diverged from 0-wiz-0's master branch, this 
will trigger a 
merge action, otherwise it would be a fast-forward.

Sidenote: I used to rebase non-fast-forward PR's to avoid the merge but have 
stopped doing so 
for all but the most trivial PRs. By not rebasing github will properly detect 
the PR to be merged 
after a rebase, one needs to manually close the PR on github. Also a rebase 
makes it harder for 
the author of the PR to sync his local repo with our primary one after the PR 
is pulled.


Here is a breakdown of the relevant info in the PR message compared to the git 
pull command:

[github-user] wants to merge x commits into Gnucash:[target-branch] from 
[github-user]:
[source-branch]
There's an implicit bit of information as well, namely which [repo] the PR is 
targetting. Obviously 
you should work in a local repo for the same source base as in github. So if 
the PR is against 
gnucash-docs, you need to do the git-pull in your local gnucash-docs repo. I 
mention this, 
because you need this bit of information in your git-pull command as well.

So the above translates into
* go to the proper local repo
* check out [target-branch] (master in the example, but can be maint as well 
for other PR's)
* make sure this branch is up to date with code.gnucash.org (using 'git pull' 
without any 
arguments, assuming you don't have local, non-pushed work on your primary 
branches. You 
don't, right?)
* then formulate the pull from another remote (from the [github-user]'s repo):

git pull https://github.com/[github-user]/[repo] [source-branch]

It's slightly more typing than clicking the fancy button on github, but avoids 
the need to make 
each new repo in a PR a remote.

Regards,

Geert

PS: final note - this technique can be used to pull from any other repository 
(online or not) as 
long as the git command can reach the other repository. So the repository URL 
can be a github 
url (https://github.com/...), but equally a url to another online site that 
hosts repositories, or 
even a file path to another repo on your own PC. For more info search the git 
help information 
on repo urls.


On woensdag 26 juli 2017 23:28:01 CEST Frank H. Ellenberger wrote:
> Hi all,
> 
> Dmitry watched, that his PRs disappeared from Maint after I merged them
> in Master.
> 
> So, what happened?
> He sent PR 100-104 to github
> I pulled them via https://github.com/Gnucash/gnucash-docs/pull/...
> sequently into maint, after each calling locally:
> (with git checkout maint)
>  git pull
>  make
>  make check
> 
> He watched, they did not appear in code.gnucash.org/docs.
> 
> I run yesterday locally
>  git checkout master
>  git merge maint
>  make
>  make check
>  git push
> 
> The guides in https://wiki.gnucash.org/docs/{de|ru}/ were regenerated
> last night, while *.{epub|mobi|pdf} are still from 2017-07-01. But that
> is a separate issue.
> 
> Today Dmitry informs me, his commits disappeared from maint on github.
> On my machine I have now 21 unpushed commits in maint.
> 
> I am clueless, but remember before the last release also one commit
> disappeared.
> 
> Does anybody whant to investigate in the current state or can I push
> them now again?
> 
> Regards
> Frank
> 
> 
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel




[1] https://github.com/0-wiz-0
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Branch of gnucash-docs on code.gnucash.org

[Derek Atkins]

Yeah, Frank used hte read-only github repos improperly and tried to
write into them.  But the fact remains that code does use the maint
branch for docs.

-derek

Di Mang  writes:

> Hello!
>
> I think, the reason for this behavior was the disappeared changes from "maint"
> brunch after merging with "master". See topic " strange behavior of GitHub".
>
> Best Regards, 
> Dmitriy
>
> Am 27.07.2017 12:43 vorm. schrieb "Derek Atkins" :
>
> Um, we DO build the maint branch of gnucash-docs.
>
> -derek
>
> "Frank H. Ellenberger"  writes:
>
> > Hi Derek,
> >
> > I am wondering if building the master branch of gnucash-docs is such a
> > good solution.
> >
> > we have one or two documented features of the 2.8 serie in master but
> > the bulk is done on maint: Almost daily improvements of the russian and
> > as spinoff german translation - thanks to Dmitry.
> >
> > If I then forget to run git merge; make check ...
> > the changes do mot appear the next day.
> >
> > So if there are no objections I would suggest to build the maint branch
> > of the docs.
> >
> > Regards
> > Frank
> >
> >
>
> --
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warl...@mit.edu                        PGP key available
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3

[Geert Janssens]

On vrijdag 28 juli 2017 18:07:41 CEST Robert Fewell wrote:
> All, just for information I have been tinkering in the register code,
> mainly on the appearance, hopefully have some thing to pull after the
> weekend.
> What I have done so far is get the header alignment working, added a css
> class to set the background, text and border colours.Changed the sheet cell
> alignment so all the borders are visible, added a css class for the
> GncItemEdit with the border colour used for the cursor and made it fit the
> cell.
> 
> Question, all of the css stuff is stored in the application gnucash.css
> file but if that is missing should there be hard coded defaults so the
> register is still readable or should that file missing stop the application
> being loaded.
> 
> Bob

Bob,

I'm back in town as of today and I'm slowly processing my backlog.

I see you have been busy while I was away. Great!

To answer your question: I would suggest to use the same approach as gtk 
itself does. As the css is critical for the proper display of some of our 
custom widgets, it should be included in the form of a GResource [1] directly 
into the binary instead of a file on disk that may or may not be present. Gtk 
does this for example for its (default) Adwaita theme. More details may be 
found directlyin the gtk sources.

Your css work so far and this mail made me think some more about the css 
concept for gnucash and perhaps we need to refine our initial idea. I'll post 
those in a separate mail though.

Geert


[1] https://developer.gnome.org/gio/stable/GResource.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Gnome dropping Bugzilla

[John Ralls]

As I think everyone knows, we use bugzilla.gnome.org 
 for bug and enhancement tracking.

There's a new banner on every BZ page saying that Gnome plans to drop Bugzilla 
and the CGit repository browser, replacing them with Gitlab.

That isn't going to work for us. I don't think it's going to work for Gnome, 
either, because a bug tracker that can't do word searches isn't capable of 
managing thousands of open bugs 
(https://docs.gitlab.com/ee/user/search/index.html 
), but that's not our 
problem. Our problem is that with our repository not at git.gnome.org 
 there won't be a GnuCash project in GitLab and so there 
won't be a bug tracker. We'll need to get a new one.

Since we do mirror our repos to Github it is a viable option and it does at 
least have better search facilities (or at least they're better documented) 
that Gitlab, see 
https://help.github.com/articles/searching-issues-and-pull-requests/ 
. It 
lacks many other features of BZ: All categorization and status tracking is by 
"labels" and they have no inherent hierarchy or organization.

So I think we're going to need our own bugtracker.

BZ is Free and it should be fairly simple to get the Gnome bug team to ship us 
a dump of our part of the database and set up a redirect once we have our 
instance up and running. The web display on whatever it is that GNU uses (e.g. 
https://savannah.gnu.org/bugs/?group=guile 
) but I dislike that it is operated 
entirely by email. Mantis is popular but is managed by a bug list. It's 
filterable to a fare-thee-well but lacks controlled vocabularies on many of its 
fields so managing a large number of open bugs is a PITA. RT (used by perl's 
CPAN) is also completely email driven. Trac is a little less rudimentary than 
Github--it at least has categories and status fields, but I don't believe it's 
capable of managing thousands of bugs. SourceForge's built in tracker is on the 
same level as Github's with less capable search.

There's a sort of conceptual timeline on the DevelopmentInfrastructure page but 
nothing concrete. I'd guess we have at least several months and perhaps as long 
as a year to have a replacement up and running.

Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gnome dropping Bugzilla

[Derek Atkins]

I have never set up a Bugzilla system, but it's already packaged so it
should be as simple as "dnf install bugzilla" on code and then configuring
it.

code already runs a mysql database for the wiki, so adding another for BZ
shouldn't be a problem.

I dont know how hard it would be to get a DB dump of our stuff in order to
migrate it.

Obviously every URL pointing at gnome's bugzilla would break, including
those in our sources and documentation.

-derek

On Mon, July 31, 2017 3:56 pm, John Ralls wrote:
> As I think everyone knows, we use bugzilla.gnome.org
>  for bug and enhancement tracking.
>
> There's a new banner on every BZ page saying that Gnome plans to drop
> Bugzilla and the CGit repository browser, replacing them with Gitlab.
>
> That isn't going to work for us. I don't think it's going to work for
> Gnome, either, because a bug tracker that can't do word searches isn't
> capable of managing thousands of open bugs
> (https://docs.gitlab.com/ee/user/search/index.html
> ), but that's not our
> problem. Our problem is that with our repository not at git.gnome.org
>  there won't be a GnuCash project in GitLab and so
> there won't be a bug tracker. We'll need to get a new one.
>
> Since we do mirror our repos to Github it is a viable option and it does
> at least have better search facilities (or at least they're better
> documented) that Gitlab, see
> https://help.github.com/articles/searching-issues-and-pull-requests/
> . It
> lacks many other features of BZ: All categorization and status tracking is
> by "labels" and they have no inherent hierarchy or organization.
>
> So I think we're going to need our own bugtracker.
>
> BZ is Free and it should be fairly simple to get the Gnome bug team to
> ship us a dump of our part of the database and set up a redirect once we
> have our instance up and running. The web display on whatever it is that
> GNU uses (e.g. https://savannah.gnu.org/bugs/?group=guile
> ) but I dislike that it is
> operated entirely by email. Mantis is popular but is managed by a bug
> list. It's filterable to a fare-thee-well but lacks controlled
> vocabularies on many of its fields so managing a large number of open bugs
> is a PITA. RT (used by perl's CPAN) is also completely email driven. Trac
> is a little less rudimentary than Github--it at least has categories and
> status fields, but I don't believe it's capable of managing thousands of
> bugs. SourceForge's built in tracker is on the same level as Github's with
> less capable search.
>
> There's a sort of conceptual timeline on the DevelopmentInfrastructure
> page but nothing concrete. I'd guess we have at least several months and
> perhaps as long as a year to have a replacement up and running.
>
> Regards,
> John Ralls
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>


-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

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

Re: Gnome dropping Bugzilla

[Eric Theise]

I'm a fan of the IDEs produced by JetBrains (RubyMine, PyCharm, et al.) but
admit upfront that I have not worked with their tracking product, YouTrack.
Worth a look though? Free hosting for open source projects.

Bug and Issue Tracking overview
https://www.jetbrains.com/youtrack/features/issue_tracking.html

Searching for Issues video
https://www.youtube.com/watch?v=fzkKcG7KIhI&index=23&list=PLQ176FUIyIUbGE728KezWz1J15fHW0S_m

Import from Bugzilla
https://www.jetbrains.com/help/youtrack/incloud/7.0/Import-from-Bugzilla.html

Free Open Source licensing
https://www.jetbrains.com/buy/opensource/?product=youtrack

other Demos and Screencasts
https://www.youtube.com/playlist?list=PLQ176FUIyIUbGE728KezWz1J15fHW0S_m

Eric


On Mon, Jul 31, 2017 at 12:56 PM, John Ralls  wrote:

> As I think everyone knows, we use bugzilla.gnome.org <
> http://bugzilla.gnome.org/> for bug and enhancement tracking.
>
> There's a new banner on every BZ page saying that Gnome plans to drop
> Bugzilla and the CGit repository browser, replacing them with Gitlab.
>
> That isn't going to work for us. I don't think it's going to work for
> Gnome, either, because a bug tracker that can't do word searches isn't
> capable of managing thousands of open bugs (https://docs.gitlab.com/ee/
> user/search/index.html ),
> but that's not our problem. Our problem is that with our repository not at
> git.gnome.org  there won't be a GnuCash project in
> GitLab and so there won't be a bug tracker. We'll need to get a new one.
>
> Since we do mirror our repos to Github it is a viable option and it does
> at least have better search facilities (or at least they're better
> documented) that Gitlab, see https://help.github.com/
> articles/searching-issues-and-pull-requests/  articles/searching-issues-and-pull-requests/>. It lacks many other
> features of BZ: All categorization and status tracking is by "labels" and
> they have no inherent hierarchy or organization.
>
> So I think we're going to need our own bugtracker.
>
> BZ is Free and it should be fairly simple to get the Gnome bug team to
> ship us a dump of our part of the database and set up a redirect once we
> have our instance up and running. The web display on whatever it is that
> GNU uses (e.g. https://savannah.gnu.org/bugs/?group=guile <
> https://savannah.gnu.org/bugs/?group=guile>) but I dislike that it is
> operated entirely by email. Mantis is popular but is managed by a bug list.
> It's filterable to a fare-thee-well but lacks controlled vocabularies on
> many of its fields so managing a large number of open bugs is a PITA. RT
> (used by perl's CPAN) is also completely email driven. Trac is a little
> less rudimentary than Github--it at least has categories and status fields,
> but I don't believe it's capable of managing thousands of bugs.
> SourceForge's built in tracker is on the same level as Github's with less
> capable search.
>
> There's a sort of conceptual timeline on the DevelopmentInfrastructure
> page but nothing concrete. I'd guess we have at least several months and
> perhaps as long as a year to have a replacement up and running.
>
> Regards,
> John Ralls
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Gnucash and css (was: Gtk3)

[Geert Janssens]

Bob,

As hinted in my previous message in the Gtk3 thread, I'd like to zoom in a bit 
on using Css for gnucash.

Let me start with a basic context for this discussion:
* css in gtk (and hence gnucash) is used to define the visual representation 
of the graphical user interface (defined through a set of "widgets").
* for the best user experience the GUI should be consistent in style.
* for standard widgets, gtk defines a default style (the Adwaita theme). 
However users are free to configure a different style (or theme) for their 
environment. Optionally each property in a theme can be overridden at a user 
level by a user-defined css file.

So for standard widgets, gnucash usually doesn't have to do anything. This is 
different for our custom widgets, such as the register and the SX overview 
calendar (both based on a GtkLayout and doing custom drawing via cairo), or 
widgets that define their own functional colors (like the transaction matcher 
in the generic import code).

These widgets don't have a style by default, and hence we need to define it. 
At the same time though, themes should be able to override whatever default 
style we choose. This suggests our own styling should generally have a 
FALLBACK priority rather than APPLICATION priority.

For any style property that is defined in the theme set by the user, this will 
then be used. If we define gnucash-only properties, these will most likely not 
appear in any theme and hence the values from our fallback will be used 
instead.

The tricky part here is to define a fallback that goes well with whatever 
theme the user has set for his environment. Take for example the colors used 
in the SX overview calendar (white background/black text). These may not work 
well with all themes so we should avoid to hard-code properties as much as 
possible. I would instead propose to leverage the style classes as defined in 
GtkStyleContext as much as possible [1]. Again for the SX overview calendar, 
add a style class GTK_STYLE_CLASS_CALENDAR and then use whatever styling 
information that gets set because of this [2]. Perhaps it requires more than 
one style class to be added to get this to work completely. You can look for 
examples in the Gtk source, like the use of the RUBBERBAND class in 
gtktreeview.c [3]. I believe/hope when done carefully this can result in a 
much more consistent GUI for gnucash and may reduce the amount of css we have 
to maintain ourselves.

Then, specifically for the register we have an option that allows the user to 
switch between the system level theme or our yellow/green theme. Building on 
the above, the system level theme should be composed using the right style 
classes. The yellow/green theme on the other hand is the first example I have 
found that warrants a separate css definition. And this time with APPLICATION 
priority because it's supposed to override theme specific styles. I would 
define a new style class (something like "gnc-custom-colors"). And in css 
write a section like this:

.gnc-custom-colors
{
color a: xyz;
color b: abc;
...
}

What the exact properties should be will depend on the properties we combine 
from the built-in style classes. If the built-in style classes for example 
provide a property "separator-color", we should set this property also in the 
.gnc-custom-colors class.

With this css in place, switching from default theme colors to our gnucash 
yellow/green theme is a matter of adding/removing the gnc-custom-colors style 
class from all register related widgets.

This same technique could be used for the label colors (negative numbers in 
red). Only define an additional class ("negative-numbers-in-red" would do 
fine) in which you explicitly set the red color to use and then add or remove 
this class from all widgets that need to be able to display negative numbers 
in red based on the user preference.

The last thing I'd like to bring up is the choice of property names. I read in 
your initial conversion to css you have chosen names very close to the 
internally used variable names. While this is not wrong, I would prefer to use 
names that better describe the property's function.
Let me explain with an example: the rows in the import matcher can have 3 
colors (currently red, yellow or green). These colors support the state of 
each line (unmatched, partially/potentially matched, matched? This may not be 
the exact state meanings).
The name of the class you have chosen describes which property gets changed to 
what. That's 1) redundant, 2) little informative and 3) restrictive. The 
property itself already holds the information (hence redundant), it doesn't 
tell the user why this property is changed (little informative) and will make 
the user hesitate to change it to anything else than a red background 
(restrictive). What if a theme designer decided a better approach to making 
this distinction would be to use a different font ? So rather than making 
class names describing which

Re: Gnome dropping Bugzilla

[Herbert Mühlburger]

What about using Jira?

-- 
Herbert Mühlburger

Email: m...@muehlburger.at
Web: https://blog.muehlburger.at

Am Mo, 31. Jul 2017, um 21:56, schrieb John Ralls:
> As I think everyone knows, we use bugzilla.gnome.org
>  for bug and enhancement tracking.
> 
> There's a new banner on every BZ page saying that Gnome plans to drop
> Bugzilla and the CGit repository browser, replacing them with Gitlab.
> 
> That isn't going to work for us. I don't think it's going to work for
> Gnome, either, because a bug tracker that can't do word searches isn't
> capable of managing thousands of open bugs
> (https://docs.gitlab.com/ee/user/search/index.html
> ), but that's not our
> problem. Our problem is that with our repository not at git.gnome.org
>  there won't be a GnuCash project in GitLab and so
> there won't be a bug tracker. We'll need to get a new one.
> 
> Since we do mirror our repos to Github it is a viable option and it does
> at least have better search facilities (or at least they're better
> documented) that Gitlab, see
> https://help.github.com/articles/searching-issues-and-pull-requests/
> .
> It lacks many other features of BZ: All categorization and status
> tracking is by "labels" and they have no inherent hierarchy or
> organization.
> 
> So I think we're going to need our own bugtracker.
> 
> BZ is Free and it should be fairly simple to get the Gnome bug team to
> ship us a dump of our part of the database and set up a redirect once we
> have our instance up and running. The web display on whatever it is that
> GNU uses (e.g. https://savannah.gnu.org/bugs/?group=guile
> ) but I dislike that it is
> operated entirely by email. Mantis is popular but is managed by a bug
> list. It's filterable to a fare-thee-well but lacks controlled
> vocabularies on many of its fields so managing a large number of open
> bugs is a PITA. RT (used by perl's CPAN) is also completely email driven.
> Trac is a little less rudimentary than Github--it at least has categories
> and status fields, but I don't believe it's capable of managing thousands
> of bugs. SourceForge's built in tracker is on the same level as Github's
> with less capable search.
> 
> There's a sort of conceptual timeline on the DevelopmentInfrastructure
> page but nothing concrete. I'd guess we have at least several months and
> perhaps as long as a year to have a replacement up and running.
> 
> Regards,
> John Ralls
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel