Re: Python bindings and Gtk3

[Mike Alexander]

> On Aug 7, 2017, at 8:51 PM, Sumit Bhardwaj  wrote:
> 
> For the tab issue, can you share a screenshot or something to that effect? I 
> am on master build and have tabs on right-hand side as well, but it's 
> perfectly usable.
> 

It’s certainly usable, I didn’t mean to imply otherwise.  It’s just that I have 
to scroll to see all my tabs where I don’t in the old version.  It’s a minor 
annoyance that should be easily dealt with.  I should probably learn enough 
about Gtk3 to fix it myself, but if I start playing around with that I won’t 
get any of the things I should be doing done.  Also, note that I’m using the X 
Window version, not the Quartz version.  The Quartz version may be quite 
different (I’m not sure if it’s even being built yet).

Mike

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

Re: Python bindings and Gtk3

[Sumit Bhardwaj]

Agree with Mike. GTK3 changes are looking fine. So far, only minor issues.

For the tab issue, can you share a screenshot or something to that effect?
I am on master build and have tabs on right-hand side as well, but it's
perfectly usable.

-Sumit

On Mon, Aug 7, 2017 at 2:32 PM, Mike Alexander  wrote:

> You may already know this, but the Python bindings done’t work in the
> current master branch (they still use Gtk2).  I made a brief attempt to fix
> this, but I don’t know either Python or Gtk3 well enough.
>
> I also noticed a cosmetic issue that you may not be aware of because I use
> a non-default window configuration.  I keep the tabs arranged along the
> right hand side of the  window.  In the Gtk3 version these tabs are about
> twice as high as previously.  This means that my tabs don’t fit along the
> side of the window without scrolling.  Before they took up about 2/3 of the
> window height.  This is obviously not a fatal problem, but it is annoying.
>
> In general, I’m impressed by how well this works given the magnitude of
> the change.  It’s going to be a big improvement.
>
>   Mike
>
> ___
> 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

Python bindings and Gtk3

[Mike Alexander]

You may already know this, but the Python bindings done’t work in the current 
master branch (they still use Gtk2).  I made a brief attempt to fix this, but I 
don’t know either Python or Gtk3 well enough.  

I also noticed a cosmetic issue that you may not be aware of because I use a 
non-default window configuration.  I keep the tabs arranged along the right 
hand side of the  window.  In the Gtk3 version these tabs are about twice as 
high as previously.  This means that my tabs don’t fit along the side of the 
window without scrolling.  Before they took up about 2/3 of the window height.  
This is obviously not a fatal problem, but it is annoying.

In general, I’m impressed by how well this works given the magnitude of the 
change.  It’s going to be a big improvement.

  Mike

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

Re: Gnome dropping Bugzilla

[John Ralls]

> On Aug 7, 2017, at 2:24 PM, Geert Janssens  wrote:
> 
> On maandag 31 juli 2017 21:56:37 CEST 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.
> 
> From the link you pass I can't infer it's not possible to do word searches. 
> On 
> the contrary the animated gif under "Search History" displays a search for 
> the 
> word "something" (in addition to a label and milestone).
> 
> Perhaps I misunderstand what you mean here. Or are these features not 
> available in the community edition ?
> 
>> 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.
>> 
> Unless we set up a repository slave at GitLab just like we did with github ?
> 
>> 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.
>> 
> The adhoc categorization and status tracking by "labels" is indeed the weak 
> point IMO.
> 
>> 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.
> A couple of years back I managed a bugzilla installation. It is pretty 
> straight-forward to do so. So having our own bugzilla is certainly one option.
> 
> The drawback is our limited server admin staff and hardware which has come up 
> a couple of times in different conversations. We have two servers (one 
> maintained by Linas and one maintained by Derek). Yet each service is hosted 
> only once and each server has only one admin. So our self-hosting scenario 
> has 
> a redundancy issue. The more services we decide to host ourselves, the more 
> critical this becomes IMO.
> 
>> 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.
> 
> Completely agreed.
> 
>> 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.
> 
> Ok
> 
>> RT (used by perl's CPAN) is also completely email driven.
> 
> Let's not do e-mail driven systems.
> 
>> 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.
> 
> Bottom line is we're pretty used to bugzilla and the way it works. OTOH it 
> seems to be a big hurdle or many newcomers or casual users.
> 
> By the way there's a comparison of various (opensource and proprietary) bug 
> trackers on wikipedia in case we want more options to evaluate:
> https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems
> 
> At this point I'm having a hard time getting my attention on this. I'm mostly 
> focused on getting ready for the first 2.7 development snapshot.
> 
>> 
>> 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.
> 
> Which gives us some time to ponder on this. Hopefully.



It's my understanding that Gnome intends to run their own instance of the 
Gitlab software, so setting up a mirror at Gitlab itself won't get us 
integration with Gnome's instance. We'd need to set up a mirror at 
git.gnome.org . We could use my ID short term and just 
do it, but I think that that might be politically unwise. We'd need to 
negotiate with the admin folks.

Your concerns about admin coverage is well taken, especially with the recent 
outages that Linas recently suffered while he was on extended travel.

Regards,
John Ralls

Re: Source directory restructuring

[John Ralls]

> On Aug 7, 2017, at 2:56 PM, Geert Janssens  wrote:
> 
> So after my houskeeping message in which I have announced the changes to src/
> business and src/libqof, I'd like to bring up my eventual goal for the source 
> tree.
> 
> My main motivation to do all this restructuring is to simplify. There are 
> currently plenty of directories and I often have to guess where to expect a 
> file. The qof vs engine story was one example. Is gnc-date something for qof 
> or for engine ? I find myself regularly searching for a file in the wrong 
> directory.
> 
> So here follows a first proposal for the directory structure I'm targetting:
> 
> * data (for things like art, checks, account hierarchy templates,...)
> * doc (for all documenation)
> * lib (for all source required to build "libgnucash", see below)
> * ui (for all the user interfaces the project currently supports)
> 
> I am omitting some smaller directories here, such as util and macros. They 
> will probably stay on the current top level for now.
> 
> I'm envisioning "libgnucash" as the core library that encapsulates all 
> gnucash 
> related concepts (the accounting concepts such as transaction, split, as well 
> as the data backends). This library is what all applications in the gnucash 
> sphere should depend on to implement the "gnucash" experience. The most 
> obvious is of course the current gnucash as we know it. However at some point 
> this library should ideally also become the core of the Android app and *who 
> knows* one day an IOS app. And closer to the current state, it should also be 
> the library that the guile and python bindings depend on. So all 
> functionality 
> encapsulated in one single library, the API. In practice I think the 
> following 
> directories belong in this libgnucash: core-utils, gnc-module, engine, the 
> backends, app-utils. (Note I would like to get rid of gnc-module still, but 
> that's a whole other discussion and task).
> 
> The ui directory will have a subdirectory for each user interface we support. 
> This is not necessarily a *graphical* user interface though. At this point 
> there are already a number of them:
> gnucash
> cutecash
> bindings (with subdirectories for python and guile)
> 
> The bulk of the other directories are support directories for one of the ui's 
> and I propose to make them subdirectories of each respective ui.
> 
> For example gtkmm is only used by cutecash, so let's store it there (until 
> another ui would also require it, which I consider unlikely to happen still).
> 
> The other directories (gnome-utils, gnome-search, gnome, register, html, 
> report, import-export,...) are all used only in the gnucash application and 
> hence should be moved there. In the move I'd like to try and reduce the 3 
> gnome* directories to one and call it gtk as we're not using any gnome 
> specific technology any more.
> 
> In a later phase I think it would be nice if the core libgnucash could also 
> spit out html reports, but that would require us to refactor the report 
> modules, which I consider too much work to be done at the same time. When 
> this 
> eventually gets done the non-ui part of the report system can then be added 
> in 
> libgnucash to the benefit of all consumers (gnucash/cutecash/Gnc4Android/...).
> 
> Feedback or questions ?

Geert,

These are to be top-level directories, so the current src goes away, right? The 
rest assumes that to be the case.

Let's call the libgnucash directory libgnucash instead of just lib and keep lib 
as the place put code pinched from elsewhere like the bits of libgoffice.

I want to get rid of gnc-module too, but it's not easy.

App-utils has stuff that belongs in libgnucash and other stuff (e.g. options) 
that belongs in the application directory (which I propose calling "gnucash" 
below). There's also code splattered all over everywhere else that belongs in 
libgnucash. How much of a prerequisite to rearrangement is getting the code in 
the right place?

I think that having separate documentation directories (there are two, doc and 
src/doc) is an abject failure from a maintenance standpoint. A lot of stuff was 
written 15-20 years ago and was marked obsolete 10 years ago because it's been 
left to rot. All documentation needs to be in the source files as Doxygen 
comments. We should look through the docs and src/docs stuff and copy anything 
that's still relevant into comments in the appropriate source files and delete 
the docs directories.

I'd prefer that the application code go into a directory named gnucash rather 
than "ui". I'm inclined toward removing cutecash entirely. It made sense for 
Christian to keep it in the Gnucash repository when we were using SVN, but now 
he should just publish it in his own Github repo.

The bindings are mostly (and should probably be entirely) libgnucash bindings. 
They really belong in libgnucash or failing that in their own TLD, not part of 
the application.

Reports might 

Redundant infrastructure (was:Re: Gnome dropping Bugzilla)

[Geert Janssens]

On maandag 7 augustus 2017 18:17:38 CEST Bruce-Robert Fenn Pocock wrote:
> On Mon, Aug 7, 2017, 10:23 Derek Atkins  wrote:
> > Hi,
> > 
> > Geert Janssens  writes:
> > 
> > [snip]
> > ….
> > 
> > > The drawback is our limited server admin staff and hardware which has
> > 
> > come up
> > 
> > > a couple of times in different conversations. We have two servers (one
> > > maintained by Linas and one maintained by Derek). Yet each service is
> > 
> > hosted
> > 
> > > only once and each server has only one admin. So our self-hosting
> > 
> > scenario has
> > 
> > > a redundancy issue. The more services we decide to host ourselves, the
> > 
> > more
> > 
> > > critical this becomes IMO.
> > 
> > …
> > 
> > Of course this doesn't help with the service redundancy.  If there IS a
> > local issue (hardware, power, network) then the service will go offline
> > until it can be repaired.  Granted, I have a large-scale UPS and a
> > natural-gas-powered backup generator so there is no longer a local power
> > outage issue.  However HW and ISP issues are a bit more out of my
> > control.
> 
> I could provide a mirror site for redundancy with my shared hosting (at
> Dreamhost), if that would help. Perhaps just a "hot backup" that could be
> enabled if you did lose connectivity or so far a while, rather than working
> up a more complicated High Availability system. I assume a brief outage
> (eg, hour?) of the bug tracker would not be critical to life.

That's very kind. For the record I have two redundant servers myself that can 
be configured to run as backups/mirrors/whatever of the gnucash 
infrastructure.

This is something I'd like to pick up some time later, when gnucash 2.7/.28 
are taking less of my time. Those are top priority now as several distros are 
starting to drop gnucash due to the webkit obsolescence.

Geert

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

Re: Gnome dropping Bugzilla

[Bruce-Robert Fenn Pocock]

On Mon, Aug 7, 2017, 10:23 Derek Atkins  wrote:

> Hi,
>
> Geert Janssens  writes:
>
> [snip]
> ….
> >
> > The drawback is our limited server admin staff and hardware which has
> come up
> > a couple of times in different conversations. We have two servers (one
> > maintained by Linas and one maintained by Derek). Yet each service is
> hosted
> > only once and each server has only one admin. So our self-hosting
> scenario has
> > a redundancy issue. The more services we decide to host ourselves, the
> more
> > critical this becomes IMO.
>
> …
>
> Of course this doesn't help with the service redundancy.  If there IS a
> local issue (hardware, power, network) then the service will go offline
> until it can be repaired.  Granted, I have a large-scale UPS and a
> natural-gas-powered backup generator so there is no longer a local power
> outage issue.  However HW and ISP issues are a bit more out of my
> control.


I could provide a mirror site for redundancy with my shared hosting (at
Dreamhost), if that would help. Perhaps just a "hot backup" that could be
enabled if you did lose connectivity or so far a while, rather than working
up a more complicated High Availability system. I assume a brief outage
(eg, hour?) of the bug tracker would not be critical to life.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Source directory restructuring

[Sumit Bhardwaj]

This sounds like a great plan to me. It will definitely make understanding
the code easier than the current state.

-Sumit

On Mon, Aug 7, 2017 at 7:23 AM, Derek Atkins  wrote:

> Sounds like a great plan to me!!!
>
> -derek
>
> Geert Janssens  writes:
>
> > So after my houskeeping message in which I have announced the changes to
> src/
> > business and src/libqof, I'd like to bring up my eventual goal for the
> source
> > tree.
> >
> > My main motivation to do all this restructuring is to simplify. There are
> > currently plenty of directories and I often have to guess where to
> expect a
> > file. The qof vs engine story was one example. Is gnc-date something for
> qof
> > or for engine ? I find myself regularly searching for a file in the wrong
> > directory.
> >
> > So here follows a first proposal for the directory structure I'm
> targetting:
> >
> > * data (for things like art, checks, account hierarchy templates,...)
> > * doc (for all documenation)
> > * lib (for all source required to build "libgnucash", see below)
> > * ui (for all the user interfaces the project currently supports)
> >
> > I am omitting some smaller directories here, such as util and macros.
> They
> > will probably stay on the current top level for now.
> >
> > I'm envisioning "libgnucash" as the core library that encapsulates all
> gnucash
> > related concepts (the accounting concepts such as transaction, split, as
> well
> > as the data backends). This library is what all applications in the
> gnucash
> > sphere should depend on to implement the "gnucash" experience. The most
> > obvious is of course the current gnucash as we know it. However at some
> point
> > this library should ideally also become the core of the Android app and
> *who
> > knows* one day an IOS app. And closer to the current state, it should
> also be
> > the library that the guile and python bindings depend on. So all
> functionality
> > encapsulated in one single library, the API. In practice I think the
> following
> > directories belong in this libgnucash: core-utils, gnc-module, engine,
> the
> > backends, app-utils. (Note I would like to get rid of gnc-module still,
> but
> > that's a whole other discussion and task).
> >
> > The ui directory will have a subdirectory for each user interface we
> support.
> > This is not necessarily a *graphical* user interface though. At this
> point
> > there are already a number of them:
> > gnucash
> > cutecash
> > bindings (with subdirectories for python and guile)
> >
> > The bulk of the other directories are support directories for one of the
> ui's
> > and I propose to make them subdirectories of each respective ui.
> >
> > For example gtkmm is only used by cutecash, so let's store it there
> (until
> > another ui would also require it, which I consider unlikely to happen
> still).
> >
> > The other directories (gnome-utils, gnome-search, gnome, register, html,
> > report, import-export,...) are all used only in the gnucash application
> and
> > hence should be moved there. In the move I'd like to try and reduce the 3
> > gnome* directories to one and call it gtk as we're not using any gnome
> > specific technology any more.
> >
> > In a later phase I think it would be nice if the core libgnucash could
> also
> > spit out html reports, but that would require us to refactor the report
> > modules, which I consider too much work to be done at the same time.
> When this
> > eventually gets done the non-ui part of the report system can then be
> added in
> > libgnucash to the benefit of all consumers (gnucash/cutecash/Gnc4Android/
> ...).
> >
> > Feedback or questions ?
> >
> > Geert
> > ___
> > 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
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Source directory restructuring

[Derek Atkins]

Sounds like a great plan to me!!!

-derek

Geert Janssens  writes:

> So after my houskeeping message in which I have announced the changes to src/
> business and src/libqof, I'd like to bring up my eventual goal for the source 
> tree.
>
> My main motivation to do all this restructuring is to simplify. There are 
> currently plenty of directories and I often have to guess where to expect a 
> file. The qof vs engine story was one example. Is gnc-date something for qof 
> or for engine ? I find myself regularly searching for a file in the wrong 
> directory.
>
> So here follows a first proposal for the directory structure I'm targetting:
>
> * data (for things like art, checks, account hierarchy templates,...)
> * doc (for all documenation)
> * lib (for all source required to build "libgnucash", see below)
> * ui (for all the user interfaces the project currently supports)
>
> I am omitting some smaller directories here, such as util and macros. They 
> will probably stay on the current top level for now.
>
> I'm envisioning "libgnucash" as the core library that encapsulates all 
> gnucash 
> related concepts (the accounting concepts such as transaction, split, as well 
> as the data backends). This library is what all applications in the gnucash 
> sphere should depend on to implement the "gnucash" experience. The most 
> obvious is of course the current gnucash as we know it. However at some point 
> this library should ideally also become the core of the Android app and *who 
> knows* one day an IOS app. And closer to the current state, it should also be 
> the library that the guile and python bindings depend on. So all 
> functionality 
> encapsulated in one single library, the API. In practice I think the 
> following 
> directories belong in this libgnucash: core-utils, gnc-module, engine, the 
> backends, app-utils. (Note I would like to get rid of gnc-module still, but 
> that's a whole other discussion and task).
>
> The ui directory will have a subdirectory for each user interface we support. 
> This is not necessarily a *graphical* user interface though. At this point 
> there are already a number of them:
> gnucash
> cutecash
> bindings (with subdirectories for python and guile)
>
> The bulk of the other directories are support directories for one of the ui's 
> and I propose to make them subdirectories of each respective ui.
>
> For example gtkmm is only used by cutecash, so let's store it there (until 
> another ui would also require it, which I consider unlikely to happen still).
>
> The other directories (gnome-utils, gnome-search, gnome, register, html, 
> report, import-export,...) are all used only in the gnucash application and 
> hence should be moved there. In the move I'd like to try and reduce the 3 
> gnome* directories to one and call it gtk as we're not using any gnome 
> specific technology any more.
>
> In a later phase I think it would be nice if the core libgnucash could also 
> spit out html reports, but that would require us to refactor the report 
> modules, which I consider too much work to be done at the same time. When 
> this 
> eventually gets done the non-ui part of the report system can then be added 
> in 
> libgnucash to the benefit of all consumers (gnucash/cutecash/Gnc4Android/...).
>
> Feedback or questions ?
>
> Geert
> ___
> 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: Gnome dropping Bugzilla

[Derek Atkins]

Hi,

Geert Janssens  writes:

[snip]
>> 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.
> A couple of years back I managed a bugzilla installation. It is pretty 
> straight-forward to do so. So having our own bugzilla is certainly one option.
>
> The drawback is our limited server admin staff and hardware which has come up 
> a couple of times in different conversations. We have two servers (one 
> maintained by Linas and one maintained by Derek). Yet each service is hosted 
> only once and each server has only one admin. So our self-hosting scenario 
> has 
> a redundancy issue. The more services we decide to host ourselves, the more 
> critical this becomes IMO.

I'll just point out that, while he was around, JSled had root access to
code.  So we DID have multiple administrators.  Of course that doesn't
help when there's a hardware, power, or local ISP failure.  If there is
another core dev that wants to co-admin code we can talk about access.

Of course this doesn't help with the service redundancy.  If there IS a
local issue (hardware, power, network) then the service will go offline
until it can be repaired.  Granted, I have a large-scale UPS and a
natural-gas-powered backup generator so there is no longer a local power
outage issue.  However HW and ISP issues are a bit more out of my
control.

[snip]
> Bottom line is we're pretty used to bugzilla and the way it works. OTOH it 
> seems to be a big hurdle or many newcomers or casual users.
>
> By the way there's a comparison of various (opensource and proprietary) bug 
> trackers on wikipedia in case we want more options to evaluate:
> https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems
>
> At this point I'm having a hard time getting my attention on this. I'm mostly 
> focused on getting ready for the first 2.7 development snapshot.

As I said in a previous email, I'm happy to set up Bugzilla.

I would set it up from the beginning such that ALL accounts required
admin approval to prevent spam.

I think the hardest part would be working with the gnome bugzilla people
to get a partial DB dump from them.

>> 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.
>
> Which gives us some time to ponder on this. Hopefully.
>
> Geert

-derek

-- 
   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

Source directory restructuring

[Geert Janssens]

So after my houskeeping message in which I have announced the changes to src/
business and src/libqof, I'd like to bring up my eventual goal for the source 
tree.

My main motivation to do all this restructuring is to simplify. There are 
currently plenty of directories and I often have to guess where to expect a 
file. The qof vs engine story was one example. Is gnc-date something for qof 
or for engine ? I find myself regularly searching for a file in the wrong 
directory.

So here follows a first proposal for the directory structure I'm targetting:

* data (for things like art, checks, account hierarchy templates,...)
* doc (for all documenation)
* lib (for all source required to build "libgnucash", see below)
* ui (for all the user interfaces the project currently supports)

I am omitting some smaller directories here, such as util and macros. They 
will probably stay on the current top level for now.

I'm envisioning "libgnucash" as the core library that encapsulates all gnucash 
related concepts (the accounting concepts such as transaction, split, as well 
as the data backends). This library is what all applications in the gnucash 
sphere should depend on to implement the "gnucash" experience. The most 
obvious is of course the current gnucash as we know it. However at some point 
this library should ideally also become the core of the Android app and *who 
knows* one day an IOS app. And closer to the current state, it should also be 
the library that the guile and python bindings depend on. So all functionality 
encapsulated in one single library, the API. In practice I think the following 
directories belong in this libgnucash: core-utils, gnc-module, engine, the 
backends, app-utils. (Note I would like to get rid of gnc-module still, but 
that's a whole other discussion and task).

The ui directory will have a subdirectory for each user interface we support. 
This is not necessarily a *graphical* user interface though. At this point 
there are already a number of them:
gnucash
cutecash
bindings (with subdirectories for python and guile)

The bulk of the other directories are support directories for one of the ui's 
and I propose to make them subdirectories of each respective ui.

For example gtkmm is only used by cutecash, so let's store it there (until 
another ui would also require it, which I consider unlikely to happen still).

The other directories (gnome-utils, gnome-search, gnome, register, html, 
report, import-export,...) are all used only in the gnucash application and 
hence should be moved there. In the move I'd like to try and reduce the 3 
gnome* directories to one and call it gtk as we're not using any gnome 
specific technology any more.

In a later phase I think it would be nice if the core libgnucash could also 
spit out html reports, but that would require us to refactor the report 
modules, which I consider too much work to be done at the same time. When this 
eventually gets done the non-ui part of the report system can then be added in 
libgnucash to the benefit of all consumers (gnucash/cutecash/Gnc4Android/...).

Feedback or questions ?

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

Re: Gnome dropping Bugzilla

[Geert Janssens]

On maandag 31 juli 2017 21:56:37 CEST 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.

>From the link you pass I can't infer it's not possible to do word searches. On 
the contrary the animated gif under "Search History" displays a search for the 
word "something" (in addition to a label and milestone).

Perhaps I misunderstand what you mean here. Or are these features not 
available in the community edition ?

> 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.
> 
Unless we set up a repository slave at GitLab just like we did with github ?

> 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.
> 
The adhoc categorization and status tracking by "labels" is indeed the weak 
point IMO.

> 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.
A couple of years back I managed a bugzilla installation. It is pretty 
straight-forward to do so. So having our own bugzilla is certainly one option.

The drawback is our limited server admin staff and hardware which has come up 
a couple of times in different conversations. We have two servers (one 
maintained by Linas and one maintained by Derek). Yet each service is hosted 
only once and each server has only one admin. So our self-hosting scenario has 
a redundancy issue. The more services we decide to host ourselves, the more 
critical this becomes IMO.

> 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.

Completely agreed.

> 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.

Ok

> RT (used by perl's CPAN) is also completely email driven.

Let's not do e-mail driven systems.

> 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.

Bottom line is we're pretty used to bugzilla and the way it works. OTOH it 
seems to be a big hurdle or many newcomers or casual users.

By the way there's a comparison of various (opensource and proprietary) bug 
trackers on wikipedia in case we want more options to evaluate:
https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems

At this point I'm having a hard time getting my attention on this. I'm mostly 
focused on getting ready for the first 2.7 development snapshot.

> 
> 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.

Which gives us some time to ponder on this. Hopefully.

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

Housekeeping on master branch

[Geert Janssens]

As briefly mentioned on the 2.8 roadmap thread I'm doing some major 
housekeeping on the master branch. This involves a lot of shuffling files and 
directories around.

IMPORTANT ANNOUNCEMENT FIRST: once this work goes into master, you will need 
to clear your build and installation directories and rerun autogen.sh/
configure or cmake again once!

And now on to some more details:

So far I have
- eliminated src/business. All relevant files have been moved to either src/
register or src/gnome. This was the last remaining bit for integrating 
business into the gnucash core.
- de-modularized the scheme-only directories standard-reports and utility-
reports. There was no advantage in this added boilerplate.
- merged src/libqof/qof back into src/engine. Functionally they have always 
formed one unit. Part was as some point split up in an effort to make it an 
independent system library. As this hasn't worked out, time has come to 
simplify our code again by uniting these two.

I'm deliberately doing this very late in the gnucash 2.8 development cycle to 
minimize the merge issues from maint to master. After the reshuffling there 
may be more of such issues.

As this work touches lots and lots of files it may also cause merge conflicts 
with local branches of the other devs. I have found git handles moving and 
renaming files quite well so I expect no merge conflicts on that level. 
However each renamed/moved file will also entail a change in a Makefile.am/
CMakeLists.txt file, which may cause conflicts if your local branches have 
changes in those.

For that reason I havent merged this branch into master right away. Instead 
for now it lives publicly here:
https://github.com/gjanssens/gnucash/tree/reorganize-source-dirs

Those with merge concerns, try to pull this branch locally and see if you get 
merge conflicts by merging your local branches into mine. If you need help 
with this, just let me know, here or on irc.

If there are no major issues by the end of the week, I will go ahead and push 
the branch to master.

Regards,

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