Re: Python bindings and Gtk3

[Mike Alexander]

> On Aug 9, 2017, at 12:21 AM, Mike Alexander  wrote:
> 
>> On Aug 8, 2017, at 10:23 AM, John Ralls  
>> wrote:
>> 
>> I don't know if the MacPorts X-build uses the CoreText or FontConfig backend 
>> for Pango, but if it uses CoreText it might be your problem.
> 
> I don’t know either.  I see that Pango’s configure looks for (and finds) 
> fontconfig, but then says "checking which cairo font backends could be 
> used... quartz freetype”.  I suspect it is using fontconfig.  I am using a 
> Retina display, but the text in the tabs seems like it’s normal size.  There 
> is a lot of blank space around the text that makes the tab bigger.  In fact 
> the text itself is smaller in the Gtk3 version.  Here are a couple of 
> screenshots.


I guess attachments aren’t allowed, I should have known.  The screenshots are 
at 

https://www.dropbox.com/s/9ge32ydfc95fum8/Gtk2%20tabs.png?dl=0 
 (Gtk2)
and
https://www.dropbox.com/s/c650pqyjbyl1zvn/Gtk3%20tabs.png?dl=0 
 (Gtk3)

  Mike

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

Re: Python bindings and Gtk3

[Mike Alexander]

> On Aug 8, 2017, at 10:23 AM, John Ralls  wrote:
> 
> I don't know if the MacPorts X-build uses the CoreText or FontConfig backend 
> for Pango, but if it uses CoreText it might be your problem.

I don’t know either.  I see that Pango’s configure looks for (and finds) 
fontconfig, but then says "checking which cairo font backends could be used... 
quartz freetype”.  I suspect it is using fontconfig.  I am using a Retina 
display, but the text in the tabs seems like it’s normal size.  There is a lot 
of blank space around the text that makes the tab bigger.  In fact the text 
itself is smaller in the Gtk3 version.  Here are a couple of screenshots.

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

guile

[Aaron Laws]

I'm using archlinux (https://distrowatch.com/table.php?distribution=arch).
It supplies guile 2.0 and guile 2.2 at the same time as /usr/bin/guile2.0
and /usr/bin/guile, respectively. When I build gnucash, I get errors since
I'm using guile2.2. Perhaps the fix is as simple as:

FIND_PROGRAM (GUILE_EXECUTABLE guile2.0 guile)

(and an analogous change for guild) in CMakeLists.txt ? If someone else
would make this change and confirm that the system can find "guile" as
well, that would be helpful.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Please remove my address from developers list

[John Ralls]

> On Aug 8, 2017, at 9:46 PM, Carlos Molinelli via gnucash-devel 
>  wrote:
> 
> Please remove my name and email from all places where I am listed as a
> developer and/or documentation support.  If I have to do this myself, please 
> send me the web page where I can make this happen.
> 

grep -ri molinelli in both gnucash and gnucash-docs returns nothing, as does 
git log --grep molinelli.

Regards,
John Ralls


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

Re: Please remove my name as documentation support

[John Ralls]

> On Aug 8, 2017, at 9:27 PM, Thomas Bullock  wrote:
> 
> Hello Developers,
> 
> Seven or more years ago I was active in some manner in support of
> documentation.  I have been retired for a year now and do not have the time
> or resources to devote to documentation support.
> 
> Please remove my name and email from all places where I am listed as a
> developer and/or documentation support.  If I have to do this myself,
> please send me the web page where I can make this happen.

Tom,

Can you come up on IRC and discuss this? I'm a bit suspicious because of the 
almost identical request from Carlos Molinelli, who afaict never contributed 
anything to GnuCash.

Regards,
John Ralls

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

Please remove my address from developers list

[Carlos Molinelli via gnucash-devel]

Please remove my name and email from all places where I am listed as a
developer and/or documentation support.  If I have to do this myself, please 
send me the web page where I can make this happen.

Thanks
Carlos Molinelli

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

Please remove my name as documentation support

[Thomas Bullock]

Hello Developers,

Seven or more years ago I was active in some manner in support of
documentation.  I have been retired for a year now and do not have the time
or resources to devote to documentation support.

Please remove my name and email from all places where I am listed as a
developer and/or documentation support.  If I have to do this myself,
please send me the web page where I can make this happen.

Thank you.

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

Re: about that restructuring, and .scm files

[John Ralls]

> On Aug 8, 2017, at 6:02 PM, Christopher Lam  wrote:
> 
> Regarding adding new reports
> 
> Apologies if this is the worst time to ask, but I believe I have fixed some
> scheme reports which can be plugged in the following folders. I've tested
> in Windows and Ubuntu and they seem to work well. It'll belong in Report >
> Collected Reports, and would make a nice addition to 2.8 release.
> 
> - scm/gnucash/* will hold gnctimeperiod-utilities.scm and
> report-other-menu.scm
> - scm/gnucash/report/standard-reports/* will hold new reports
> 
> Unfortunately I cannot identify the proper source for the scm/gnucash/*
> folder - it seems to accumulate files from src/engine, src/scm... I guess
> src/scm is the right one? I don't know how to build from source to test.


Chris,

No, it's a good time to ask.

scm/gnucash collects all of the guile binding code from the various modules. I 
don't know what "timeperiod-utilities" is supposed to be, but it sounds like it 
should be an extension of src/engine/gnc-date.cpp. We want to use the same date 
code throughout GnuCash so whatever you need in timeperiod-utilities should be 
written in C++ and should wrap boost::date_time to hide the implementation (so 
that we can easily switch to another implementation if e.g. the C++ committee 
adds something to the standard library or we decide that ICU provides a better 
fit) and then provide Guile bindings via SWIG to support your report changes.

It would be a good idea to get a PR up so that we can give you more detailed 
guidance.

Regards,
John Ralls

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

Re: Source directory restructuring

[Aaron Laws]

On Mon, Aug 7, 2017 at 7:56 AM, 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
>

I echo the other sentiments: This will make it much easier to grok and
contribute to gnucash.

Concerning cutecash, "It's not maintained" may be the case now, but I
remember working on some libqof changes before and having to "maintain"
cutecash since it was breaking because of the changes. It was a bit
irritating. If it's a difficult thing to bring yourself to, perhaps you
could have a friend pull the trigger? ;-)

Thanks for thinking through this and putting it on paper. I look forward to
seeing the fruit of this labour.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Source directory restructuring

[John Ralls]

> On Aug 8, 2017, at 5:50 PM, Sumit Bhardwaj  wrote:
> 
> John,
> 
> If the plan is to dump autotools, should we ask also devs to make sure that
> they can build using cmake? I have had problems in the past and therefore,
> I have stuck with autotools so far.
> 
> What are the things we want to confirm in the cmake toolchain?
> cmake
> cmake install
> cmake check
> 
> Anything else?
Sumit,

No. cmake  srcdir && make && make check && make install or (quite a bit 
faster) cmake -G Ninja  srcdir && ninja check && ninja install.

You generally need to at least specify a -DCMAKE_INSTALL_PREFIX unless you want 
GnuCash installed in /usr/local which back in the day was a reasonable thing to 
do but isn't really anymore. Because of normal linker behavior and GnuCash's 
overuse of loadable modules you also need to uninstall before building, 
especially when changing branches. The incantation for that in cmake is xargs 
rm < install_manifest.txt.

Geert and I use the cmake+ninja build system most of the time and the Windows 
automated build has been using it for just over a year. I think that it's well 
tested. There's a known problem that the dependency graph doesn't capture 
everything especially for some of the scheme modules so allowing too much 
parallelism (setting -j too high on a many-core machine) will try to build some 
things before their dependencies are done. That's not a blocker to dropping 
autotools. The only loose end at present is that there are still a few rough 
edges in the dist target that need to be cleaned up.

Regards,
John Ralls


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

Good write up on Quickbooks -> GnuCash

[Andrew Ruthven]

Hey,

Jon Corbet at Linux Weekly News has written a good article on how to
transition from Quickbooks to GnuCash. For folks who are LWN
subscribers, the article is here:

https://lwn.net/Articles/729087/

For those that aren't, it'll be publicly available on the 14th.

Cheers,
Andrew
-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz | linux.conf.au 2018, Sydney, AU 
  New Zealand's only Cloud:   |  Just a little bit of history
https://catalyst.net.nz/cloud |     http://linux.conf.au
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

about that restructuring, and .scm files

[Christopher Lam]

Regarding adding new reports

Apologies if this is the worst time to ask, but I believe I have fixed some
scheme reports which can be plugged in the following folders. I've tested
in Windows and Ubuntu and they seem to work well. It'll belong in Report >
Collected Reports, and would make a nice addition to 2.8 release.

- scm/gnucash/* will hold gnctimeperiod-utilities.scm and
report-other-menu.scm
- scm/gnucash/report/standard-reports/* will hold new reports

Unfortunately I cannot identify the proper source for the scm/gnucash/*
folder - it seems to accumulate files from src/engine, src/scm... I guess
src/scm is the right one? I don't know how to build from source to test.

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

Re: Source directory restructuring

[Sumit Bhardwaj]

John,

If the plan is to dump autotools, should we ask also devs to make sure that
they can build using cmake? I have had problems in the past and therefore,
I have stuck with autotools so far.

What are the things we want to confirm in the cmake toolchain?
cmake
cmake install
cmake check

Anything else?

Thanks,
Sumit

On Tue, Aug 8, 2017 at 7:36 AM, John Ralls 
wrote:

>
> > On Aug 8, 2017, at 10:29 AM, Geert Janssens 
> wrote:
> >
> > On maandag 7 augustus 2017 21:27:18 CEST John Ralls wrote:
> >> These are to be top-level directories, so the current src goes away,
> right?
> >> The rest assumes that to be the case.
> >>
> > Yes, I would drop src.
> >
> >> 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.
> >>
> > That's reasonable.
> >
> >> I want to get rid of gnc-module too, but it's not easy.
> >>
> > Indeed. I didn't plan this in the first phase. Except perhaps for some
> low
> > hanging fruit (like what I did with a couple of reports subdirectories) I
> > don't think this is something to target for 2.8.
> >
> >> 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?
> >>
> > There's a gui and non-gui aspect to the options. The gui aspect clearly
> should
> > go to the "gnucash" part. The non-gui aspect probably not. In my long
> term
> > idea libgnucash should be able to generate reports (but not display
> them) to
> > allow the bindings (and eventual smartphone apps) access to this
> feature. As
> > things stand now, the report system requires the options. We all agree of
> > course the options are currently a complicated mixture of C and guile
> code
> > which needs serious modernization. That will not be for 2.8.
> >
> > But your general message stands. Lots of code is in the wrong functional
> > source group. And there definitely won't be time to reorganize all of
> that.
> >
> >> 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.
> >>
> > Good idea.
> >
> >> 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.
> >>
> > I realize I'm somewhat hesitant to drop cutecash from the repo. It looks
> I'm a
> > bit emotionally attached to it (although I never used it and only built
> it
> > once to test). That's probably because it's a decent first attempt to
> use qt
> > instead of gtk. And qt for me is one of the few options that can bring
> us one
> > code base for all form factors. (Drifting off into dreaming about
> Utopia...)
> >
> > Anyway sticking with the current situation I believe you are right to
> consider
> > removing it. It's not maintained, and based on the soon to be obsolete
> Qt4 and
> > most importantly it can be recovered should we ever want to do so or are
> ready
> > to go the Qt way and need a base to start from.
> >
> >> 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.
> >>
> > TLD then.
> >
> >> Reports might stand on their own as a separate dependency of gnucash or
> they
> >> could be a subdirectory of gnucash. The same is true of import-export.
> In
> >> one approach  the GUI parts of each would be part of the application
> while
> >> the functional bits would be part of libgnucash. Are the matchers
> >> libgnucash or gnucash?
> >>
> > Long term I would like to see the functional part of both reports and
> import/
> > export be part of libgnucash and the gui's go into gnucash. I think
> there are
> > use cases where smartphone apps and the bindings would benefit from this.
> >
> > For 2.8 that would again be too much work. For this initial step I'd
> consider
> > the plugins directory to be the location to store self-contained,
> loadable
> > modules. There are already a few smaller ones in there. I'd add the
> report and
> > import/export directories in there 

Re: Source directory restructuring

[John Ralls]

> On Aug 8, 2017, at 10:29 AM, Geert Janssens  
> wrote:
> 
> On maandag 7 augustus 2017 21:27:18 CEST John Ralls wrote:
>> These are to be top-level directories, so the current src goes away, right?
>> The rest assumes that to be the case.
>> 
> Yes, I would drop src.
> 
>> 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.
>> 
> That's reasonable.
> 
>> I want to get rid of gnc-module too, but it's not easy.
>> 
> Indeed. I didn't plan this in the first phase. Except perhaps for some low 
> hanging fruit (like what I did with a couple of reports subdirectories) I 
> don't think this is something to target for 2.8.
> 
>> 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?
>> 
> There's a gui and non-gui aspect to the options. The gui aspect clearly 
> should 
> go to the "gnucash" part. The non-gui aspect probably not. In my long term 
> idea libgnucash should be able to generate reports (but not display them) to 
> allow the bindings (and eventual smartphone apps) access to this feature. As 
> things stand now, the report system requires the options. We all agree of 
> course the options are currently a complicated mixture of C and guile code 
> which needs serious modernization. That will not be for 2.8.
> 
> But your general message stands. Lots of code is in the wrong functional 
> source group. And there definitely won't be time to reorganize all of that.
> 
>> 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.
>> 
> Good idea.
> 
>> 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.
>> 
> I realize I'm somewhat hesitant to drop cutecash from the repo. It looks I'm 
> a 
> bit emotionally attached to it (although I never used it and only built it 
> once to test). That's probably because it's a decent first attempt to use qt 
> instead of gtk. And qt for me is one of the few options that can bring us one 
> code base for all form factors. (Drifting off into dreaming about Utopia...)
> 
> Anyway sticking with the current situation I believe you are right to 
> consider 
> removing it. It's not maintained, and based on the soon to be obsolete Qt4 
> and 
> most importantly it can be recovered should we ever want to do so or are 
> ready 
> to go the Qt way and need a base to start from.
> 
>> 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.
>> 
> TLD then.
> 
>> Reports might stand on their own as a separate dependency of gnucash or they
>> could be a subdirectory of gnucash. The same is true of import-export. In
>> one approach  the GUI parts of each would be part of the application while
>> the functional bits would be part of libgnucash. Are the matchers
>> libgnucash or gnucash?
>> 
> Long term I would like to see the functional part of both reports and import/
> export be part of libgnucash and the gui's go into gnucash. I think there are 
> use cases where smartphone apps and the bindings would benefit from this.
> 
> For 2.8 that would again be too much work. For this initial step I'd consider 
> the plugins directory to be the location to store self-contained, loadable 
> modules. There are already a few smaller ones in there. I'd add the report 
> and 
> import/export directories in there as well until we're ready to split them 
> up. 
> My work on the csv importer is an important step in the right direction. For 
> the next major cycle I hope to continue this for the other importers and 
> exporters as well.
> 
>> Gtk+ is very much Gnome and depends on other pieces of the Gnome project.
>> The actual name of the directory isn't really important so we can call it
>> gtk if you'd rather, but there are lots of other Gnome project dependencies
>> that aren't going away as long as we're using Gtk+. Remember that in
>> addition to gnome, gnome-util, and 

Re: Python bindings and Gtk3

[John Ralls]

> On Aug 8, 2017, at 6:17 AM, Mike Alexander  wrote:
> 
>> 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,

I just built quartz on my laptop on the way over from the US last week and 
pushed the changes. 

There's a pango bug, 782393, about drawing double-size with CoreText on a 
Retina screen; it was revealed by a change to Gtk that's mentioned in the first 
note on the bug. I've written a patch which is in Gtk-OSX but it's waiting for 
Bedhad to approve it before I can push it to Pango.

I don't know if the MacPorts X-build uses the CoreText or FontConfig backend 
for Pango, but if it uses CoreText it might be your problem.

Regards,
John Ralls



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

Restarting the free accounting search

[Herbert Thoma]

Hi!

An interesting read: Linux Weekly News is trying to get away from
QuickBooks.

Restarting the free accounting search:
https://lwn.net/SubscriberLink/729088/3513f2cf8674fa1f/

Escape from QuickBooks (with data in hand):
https://lwn.net/SubscriberLink/729087/91644c624f6618ea/


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

Re: Source directory restructuring

[Geert Janssens]

On maandag 7 augustus 2017 21:27:18 CEST John Ralls wrote:
> These are to be top-level directories, so the current src goes away, right?
> The rest assumes that to be the case.
> 
Yes, I would drop src.

> 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.
> 
That's reasonable.

> I want to get rid of gnc-module too, but it's not easy.
> 
Indeed. I didn't plan this in the first phase. Except perhaps for some low 
hanging fruit (like what I did with a couple of reports subdirectories) I 
don't think this is something to target for 2.8.

> 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?
> 
There's a gui and non-gui aspect to the options. The gui aspect clearly should 
go to the "gnucash" part. The non-gui aspect probably not. In my long term 
idea libgnucash should be able to generate reports (but not display them) to 
allow the bindings (and eventual smartphone apps) access to this feature. As 
things stand now, the report system requires the options. We all agree of 
course the options are currently a complicated mixture of C and guile code 
which needs serious modernization. That will not be for 2.8.

But your general message stands. Lots of code is in the wrong functional 
source group. And there definitely won't be time to reorganize all of that.

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

> 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.
> 
I realize I'm somewhat hesitant to drop cutecash from the repo. It looks I'm a 
bit emotionally attached to it (although I never used it and only built it 
once to test). That's probably because it's a decent first attempt to use qt 
instead of gtk. And qt for me is one of the few options that can bring us one 
code base for all form factors. (Drifting off into dreaming about Utopia...)

Anyway sticking with the current situation I believe you are right to consider 
removing it. It's not maintained, and based on the soon to be obsolete Qt4 and 
most importantly it can be recovered should we ever want to do so or are ready 
to go the Qt way and need a base to start from.

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

> Reports might stand on their own as a separate dependency of gnucash or they
> could be a subdirectory of gnucash. The same is true of import-export. In
> one approach  the GUI parts of each would be part of the application while
> the functional bits would be part of libgnucash. Are the matchers
> libgnucash or gnucash?
> 
Long term I would like to see the functional part of both reports and import/
export be part of libgnucash and the gui's go into gnucash. I think there are 
use cases where smartphone apps and the bindings would benefit from this.

For 2.8 that would again be too much work. For this initial step I'd consider 
the plugins directory to be the location to store self-contained, loadable 
modules. There are already a few smaller ones in there. I'd add the report and 
import/export directories in there as well until we're ready to split them up. 
My work on the csv importer is an important step in the right direction. For 
the next major cycle I hope to continue this for the other importers and 
exporters as well.

> Gtk+ is very much Gnome and depends on other pieces of the Gnome project.
> The actual name of the directory isn't really important so we can call it
> gtk if you'd rather, but there are lots of other Gnome project dependencies
> that aren't going away as long as we're using Gtk+. Remember that in
> addition to gnome, gnome-util, and gnome-query there's also register-gnome,
> report-gnome, and (until your latest changes) business-gnome. There's also
> Gtk+ code in import-export, html, and probably a few other places that
> don't immediately come to mind. Setting that aside we still 

Re: Python bindings and Gtk3

[Geert Janssens]

On dinsdag 8 augustus 2017 05:17:09 CEST Mike Alexander wrote:
> > 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).

I don't think it's an X Window vs Quarz thing. The tabs in gtk3 are 
effectively much bigger. It's a matter of theming. I always get the feeling 
the default gtk3 theme has been developed with with touch screens in mind 
rather than keyboard/mouse interaction. Perhaps another theme will do better.

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