[RFC] GTK+ 3 Migration - Alpha-grade Patchset

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[RFC] GTK+ 3 Migration - Alpha-grade Patchset

Tobias Markus
Hi GnuCash developers,

over the last few feeks, I have developed a fundamental patchset that
should get GnuCash up and running in GTK+ 3.

The source code is available at GitHub:
https://github.com/hesiod/gnucash/tree/gtk3

Some independent commits are on the next branch. All GTK+ 3-related
stuff is on the gtk3 branch.

I'm sorry for the sometimes messy commits, but the number of commits is
quite massive already and I really didn't have the time splitting them
up. If you have any questions regarding a particular commit, feel free
to ask me.

DISCLAIMER: This is alpha-quality software and not at all ready for
users! Please do not run GnuCash built from my development tree unless
you want to contribute to the development process. This development
version may delete all your data and eat your CPU!

While I got GnuCash pretty much working under GTK+ 3, a lot of further
(fundamental and architectural) changes are required before even
thinking about a release. Simply spoken, we now have GnuCash working in
GTK+ 3, but using GTK+/Gnome 2 patterns. While it is possible to go
down this path, the user experience will be substandard, especially
compared to the current releases.

Because GnuCash 2.0 was (afaik) coupled to the GTK+ 2 migration, I
suggest that the GTK+ 3 version should be GnuCash 3.0.

A quick word on dependencies: I set the minimum GTK+ version to be 3.18
because I didn't try to compile it with any earlier versions, but
backporting probably isn't too hard.

Major changes already in my tree:
* All "rich" GtkActions/GtkRadioActions/GtkToggleActions were replaced
  by abstract GActions/GMenus. This doesn't sound like a lot, but is a
  major change. Please read the relevant API documentation and do not
  hestitate to ask me if you have any questions about the new GAction-
  based infrastructure. Sorry for not going into more detail,
  but describing the technical peculiarities here would take
  considerably too long.
* I removed the splash screen and replaced it by GApplication's busy
  notification in some places.
* I updated the HTML code to use the Webkit2 API, but it needs some
  more love.
* Using GtkApplication renders everything related to
  gtk-osx-integration unnecessary.
* This is unrelated to the GTK+ 3 migration, but I added a Markdown
  version of the README and added a DOAP project description.
* I changed the action naming pattern from CamelCaseAction to
  dot.separated.action-name, e.g. file.close or account.d

Major stuff not yet migrated:
* In order to migrate the small business module, its entry ledger has  
  to be rewritten, just like the "normal" register.
* AqBanking uses the gwenhywfar UI library, which in turn uses GTK+ 2.
  I have not yet looked into this.
* I removed the old file history/recent files code. There are better
  ways to do this in GTK+ 3.
* I haven't converted every UI definition file to the new format for
  now.

Things that I recommend be dropped/removed for GnuCash 3.0:
* Maintaining both the CMake and autotools-based build system does not
  seem like a good idea, so drop autotools.
* Rewriting the old register is not really viable or useful,
  so drop it. Currently, either the old or the new register is compiled
  to ease transition. (Right now, the new register can be enabled in
  addition to the old register.)
* The dynamic module system (based on GModule) is a nice idea, but the
  
  benefits are dubious at the moment. While the dynamic loading of all
 
  the standard modules incurs a heavy startup delay, there is no
  reason why a user would not want to load all the built-in modules.
  Therefore, all GnuCash modules should be converted into statically
  linked objects. (It is still possible to compile shared libraries
  for Guile at the same time, CMake should have no problem doing
  that.)

Major Changes that I highly recommend for a GnuCash 3.0 release:
* Writing GObject-based code (i.e. GTK+ code) in C is a very cumbersome
  and boilerplate-ish process. Vala makes it possible to write GObject
 
  code in a very concise way, all while compiling directly to C source
 
  (and C headers), making it possible to seamlessy integrate Vala code
  into C code. Other C-to-Vala ports have seen significant decreases in
  
  code size. Porting the UI code to Vala should definitiely ease
  maintainability, correctness and readability without sacrificing
  performance.
* I ported the core application code to use GtkApplication. It would
be 
  nice to change the main window - opened file relationship from the
  current N:1 to a 1:1, i.e. each main window is separate and has
  exactly one opened file. This would simplify the main window code.
  It also seems more intuitive than the current behaviour, since the
  user does not expect that all windows change the opened file if he
  opens a file in one window.
* UI design: see below
* I have not yet looked at translations and accelerators.
* The new register requires some more love.

Nice-to-haves regarding GTK:
* Some GSimpleActions would be better off as GPropertyActions.
* Validate all GtkBuilder files using gtk-builder-tool.
* File Chooser Dialog: Implement proper file format filter.
* xdg-app support
* jqplot as a Git submodule
* Have hints for GtkEntries

Nice-to-haves, other that the UI:
* Replace the GncInt128 with Boost.Multiprecision
* I added initial configuration files for clang-format and clang-tidy.
  The latter could be integrated as a Git commit hook.

Bugfixing paths:
* I have added basic support for compiling GnuCash with the address
  sanitizer (ASan) and the undefined behaviour sanitizer (UBSan),
  although in practice, the former only works using LD_PRELOAD at
  runtime (which is discouraged) due to a Guile error.
* Many of the warnings you see compiling my tree really are valid
  errors and should be fixed.

UI Design Notes:

The current UI has the menubar as the central element. Depending on    
which "plugin page" you're currently looking at, certain menus are
shown or hidden, e.g. the "Transaction" menu is only visible when
viewing a register page. In theory, this behaviour is also available in
my development tree thanks to the EggMenuManager (taken from Gnome
Builder), but I removed the relevant calls for the moment. Please read
on for the reasons. (Search for calls to egg_menu_manager_remove)

Both the heavy usage of menus and the context-sensitive visibility of
menus are discouraged by the Gnome 3 HIG. A more modern UI design would
greatly benefit the GnuCash user experience. (Before continuing, please
have a quick look at the Gnome 3 HIG right now if you haven't yet.)

I haven't spent a great deal of time thinking about a potential new UI
design yet, but in general, it boils down to having the page-specific
actions as buttons inside a toolbar, and general actions in a header
bar (GtkHeaderBar). As an example, let's take the register:
 * New Account: A plus button on the toolbar
 * Register Style: Clicking on "sandwich"-like button opens a popover
   offering the different styles as a slider (as in Nautilus: the
   button left of the sandwich button offers the different Nautilus
   style options)
 * View - Search by: As "search" button in the header bar

In general, you can get a lot of design inspiration by looking at Gnome
Apps, in particular some of the recently refreshed ones, e.g.
Files/Nautilus, Videos/Totem, Maps, Documents or Document Viewer/evince.

Asking the Gnome Design Team for suggestions is also a possible avenue.

Thanks for your time and attention - let's make GnuCash an even better
free software finance manager!

Cheers,
Tobias
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

John Ralls-2

> On Feb 21, 2016, at 11:12 AM, Tobias Markus <[hidden email]> wrote:
>
> Hi GnuCash developers,
>
> over the last few feeks, I have developed a fundamental patchset that
> should get GnuCash up and running in GTK+ 3.
>
> The source code is available at GitHub:
> https://github.com/hesiod/gnucash/tree/gtk3
>
> Some independent commits are on the next branch. All GTK+ 3-related
> stuff is on the gtk3 branch.
>
> I'm sorry for the sometimes messy commits, but the number of commits is
> quite massive already and I really didn't have the time splitting them
> up. If you have any questions regarding a particular commit, feel free
> to ask me.
>
> DISCLAIMER: This is alpha-quality software and not at all ready for
> users! Please do not run GnuCash built from my development tree unless
> you want to contribute to the development process. This development
> version may delete all your data and eat your CPU!
>
> While I got GnuCash pretty much working under GTK+ 3, a lot of further
> (fundamental and architectural) changes are required before even
> thinking about a release. Simply spoken, we now have GnuCash working in
> GTK+ 3, but using GTK+/Gnome 2 patterns. While it is possible to go
> down this path, the user experience will be substandard, especially
> compared to the current releases.
>
> Because GnuCash 2.0 was (afaik) coupled to the GTK+ 2 migration, I
> suggest that the GTK+ 3 version should be GnuCash 3.0.
>
> A quick word on dependencies: I set the minimum GTK+ version to be 3.18
> because I didn't try to compile it with any earlier versions, but
> backporting probably isn't too hard.
>
> Major changes already in my tree:
> * All "rich" GtkActions/GtkRadioActions/GtkToggleActions were replaced
>   by abstract GActions/GMenus. This doesn't sound like a lot, but is a
>   major change. Please read the relevant API documentation and do not
>   hestitate to ask me if you have any questions about the new GAction-
>   based infrastructure. Sorry for not going into more detail,
>   but describing the technical peculiarities here would take
>   considerably too long.
> * I removed the splash screen and replaced it by GApplication's busy
>   notification in some places.
> * I updated the HTML code to use the Webkit2 API, but it needs some
>   more love.
> * Using GtkApplication renders everything related to
>   gtk-osx-integration unnecessary.
> * This is unrelated to the GTK+ 3 migration, but I added a Markdown
>   version of the README and added a DOAP project description.
> * I changed the action naming pattern from CamelCaseAction to
>   dot.separated.action-name, e.g. file.close or account.d
>
> Major stuff not yet migrated:
> * In order to migrate the small business module, its entry ledger has  
>   to be rewritten, just like the "normal" register.
> * AqBanking uses the gwenhywfar UI library, which in turn uses GTK+ 2.
>   I have not yet looked into this.
> * I removed the old file history/recent files code. There are better
>   ways to do this in GTK+ 3.
> * I haven't converted every UI definition file to the new format for
>   now.
>
> Things that I recommend be dropped/removed for GnuCash 3.0:
> * Maintaining both the CMake and autotools-based build system does not
>   seem like a good idea, so drop autotools.
> * Rewriting the old register is not really viable or useful,
>   so drop it. Currently, either the old or the new register is compiled
>   to ease transition. (Right now, the new register can be enabled in
>   addition to the old register.)
> * The dynamic module system (based on GModule) is a nice idea, but the
>  
>   benefits are dubious at the moment. While the dynamic loading of all
>  
>   the standard modules incurs a heavy startup delay, there is no
>   reason why a user would not want to load all the built-in modules.
>   Therefore, all GnuCash modules should be converted into statically
>   linked objects. (It is still possible to compile shared libraries
>   for Guile at the same time, CMake should have no problem doing
>   that.)
>
> Major Changes that I highly recommend for a GnuCash 3.0 release:
> * Writing GObject-based code (i.e. GTK+ code) in C is a very cumbersome
>   and boilerplate-ish process. Vala makes it possible to write GObject
>  
>   code in a very concise way, all while compiling directly to C source
>  
>   (and C headers), making it possible to seamlessy integrate Vala code
>   into C code. Other C-to-Vala ports have seen significant decreases in
>  
>   code size. Porting the UI code to Vala should definitiely ease
>   maintainability, correctness and readability without sacrificing
>   performance.
> * I ported the core application code to use GtkApplication. It would
> be
>   nice to change the main window - opened file relationship from the
>   current N:1 to a 1:1, i.e. each main window is separate and has
>   exactly one opened file. This would simplify the main window code.
>   It also seems more intuitive than the current behaviour, since the
>   user does not expect that all windows change the opened file if he
>   opens a file in one window.
> * UI design: see below
> * I have not yet looked at translations and accelerators.
> * The new register requires some more love.
>
> Nice-to-haves regarding GTK:
> * Some GSimpleActions would be better off as GPropertyActions.
> * Validate all GtkBuilder files using gtk-builder-tool.
> * File Chooser Dialog: Implement proper file format filter.
> * xdg-app support
> * jqplot as a Git submodule
> * Have hints for GtkEntries
>
> Nice-to-haves, other that the UI:
> * Replace the GncInt128 with Boost.Multiprecision
> * I added initial configuration files for clang-format and clang-tidy.
>   The latter could be integrated as a Git commit hook.
>
> Bugfixing paths:
> * I have added basic support for compiling GnuCash with the address
>   sanitizer (ASan) and the undefined behaviour sanitizer (UBSan),
>   although in practice, the former only works using LD_PRELOAD at
>   runtime (which is discouraged) due to a Guile error.
> * Many of the warnings you see compiling my tree really are valid
>   errors and should be fixed.
>
> UI Design Notes:
>
> The current UI has the menubar as the central element. Depending on    
> which "plugin page" you're currently looking at, certain menus are
> shown or hidden, e.g. the "Transaction" menu is only visible when
> viewing a register page. In theory, this behaviour is also available in
> my development tree thanks to the EggMenuManager (taken from Gnome
> Builder), but I removed the relevant calls for the moment. Please read
> on for the reasons. (Search for calls to egg_menu_manager_remove)
>
> Both the heavy usage of menus and the context-sensitive visibility of
> menus are discouraged by the Gnome 3 HIG. A more modern UI design would
> greatly benefit the GnuCash user experience. (Before continuing, please
> have a quick look at the Gnome 3 HIG right now if you haven't yet.)
>
> I haven't spent a great deal of time thinking about a potential new UI
> design yet, but in general, it boils down to having the page-specific
> actions as buttons inside a toolbar, and general actions in a header
> bar (GtkHeaderBar). As an example, let's take the register:
>  * New Account: A plus button on the toolbar
>  * Register Style: Clicking on "sandwich"-like button opens a popover
>    offering the different styles as a slider (as in Nautilus: the
>    button left of the sandwich button offers the different Nautilus
>    style options)
>  * View - Search by: As "search" button in the header bar
>
> In general, you can get a lot of design inspiration by looking at Gnome
> Apps, in particular some of the recently refreshed ones, e.g.
> Files/Nautilus, Videos/Totem, Maps, Documents or Document Viewer/evince.
>
> Asking the Gnome Design Team for suggestions is also a possible avenue.
>
> Thanks for your time and attention - let's make GnuCash an even better
> free software finance manager!
>

Dear Tobias,

That's a huge amount of work, but it's a bit too far-reaching to be considered a patch set and it doesn't really look like something we can merge.

It's also quite possible that we won't ever move GnuCash to Gtk+-3. We haven't decided on a future UI toolkit and if you'd looked at http://wiki.gnucash.org/wiki/Roadmap you'd realize that we have other priorities. Unfortunately it doesn't look like many of your changes advance those priorities, and the way you've done your changes would make it very difficult indeed to cherry-pick out the parts that might be useful.

Had you come here before starting work we could have guided you towards work that could be merged and coached you about making commit messages, style, and the like. Perhaps you'd consider starting over?


About your recommendations:
* We probably will drop autotools in favor of cmake for the next release.

* Vala is not useful to GnuCash. It is usable only with Gtk+ and we need to be able to write GUIs for other platforms. We decided two years ago to redo the guts in C++11 and are working on that.

* Agreed that rewriting the old register isn't attractive, but a developer spent a year trying to get a new GtkTreeView-based register to work right and although he got close, it wasn't suitable for release. I presume that your Gtk3 port is based on that "Register2" code, and since you say that your work isn't releasable either that doesn't augur well for that line of development.

* The dynamic module system is indeed a complication of dubious utility, but Guile works by dlopening libraries; one doesn't dynamically link them. Having GnuCash's executable statically linked and Guile using dlopened shared libraries won't work: They pass objects back-and-forth between each other so they need to use the same binary image. The Gnucash executable might be able to dynamically link the shared libraries instead of dlopening them on startup. It's worth trying out. We do have a long-term goal of getting Guile out of the middle of GnuCash and that would make static linking more feasible.  

*We (I) did extensive performance testing with several multi-precision libraries including boost.multiprecision and found that their dependence on the free store made them unacceptably slow. GncInt128 uses the same algorithms (they're in Knuth) but is stack based and so substantially faster than boost.multiprecision. The gory details can be found by following the long thread beginning at https://lists.gnucash.org/pipermail/gnucash-devel/2014-May/037723.html.

* We certainly recognize that GnuCash's GUI design is a bit dated, but a redesign depends to a large degree on the toolkit one uses. Since we're not ready to choose a new toolkit we're also not ready to undertake a major redesign. Regardless, the Gnome3 HIG is unlikely to factor much in our design decisions.


Regards,
John Ralls




_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

Tobias Markus
On So, 2016-02-21 at 13:22 -0800, John Ralls wrote:

> >
> > On Feb 21, 2016, at 11:12 AM, Tobias Markus <[hidden email]>
> > wrote:
> >
> > Hi GnuCash developers,
> >
> > over the last few feeks, I have developed a fundamental patchset
> > that
> > should get GnuCash up and running in GTK+ 3.
> >
> > The source code is available at GitHub:
> > https://github.com/hesiod/gnucash/tree/gtk3
> >
> > Some independent commits are on the next branch. All GTK+ 3-related
> > stuff is on the gtk3 branch.
> >
> > I'm sorry for the sometimes messy commits, but the number of
> > commits is
> > quite massive already and I really didn't have the time splitting
> > them
> > up. If you have any questions regarding a particular commit, feel
> > free
> > to ask me.
> >
> > DISCLAIMER: This is alpha-quality software and not at all ready for
> > users! Please do not run GnuCash built from my development tree
> > unless
> > you want to contribute to the development process. This development
> > version may delete all your data and eat your CPU!
> >
> > While I got GnuCash pretty much working under GTK+ 3, a lot of
> > further
> > (fundamental and architectural) changes are required before even
> > thinking about a release. Simply spoken, we now have GnuCash
> > working in
> > GTK+ 3, but using GTK+/Gnome 2 patterns. While it is possible to go
> > down this path, the user experience will be substandard, especially
> > compared to the current releases.
> >
> > Because GnuCash 2.0 was (afaik) coupled to the GTK+ 2 migration, I
> > suggest that the GTK+ 3 version should be GnuCash 3.0.
> >
> > A quick word on dependencies: I set the minimum GTK+ version to be
> > 3.18
> > because I didn't try to compile it with any earlier versions, but
> > backporting probably isn't too hard.
> >
> > Major changes already in my tree:
> > * All "rich" GtkActions/GtkRadioActions/GtkToggleActions were
> > replaced
> >   by abstract GActions/GMenus. This doesn't sound like a lot, but
> > is a
> >   major change. Please read the relevant API documentation and do
> > not
> >   hestitate to ask me if you have any questions about the new
> > GAction-
> >   based infrastructure. Sorry for not going into more detail,
> >   but describing the technical peculiarities here would take
> >   considerably too long.
> > * I removed the splash screen and replaced it by GApplication's
> > busy
> >   notification in some places.
> > * I updated the HTML code to use the Webkit2 API, but it needs some
> >   more love.
> > * Using GtkApplication renders everything related to
> >   gtk-osx-integration unnecessary.
> > * This is unrelated to the GTK+ 3 migration, but I added a Markdown
> >   version of the README and added a DOAP project description.
> > * I changed the action naming pattern from CamelCaseAction to
> >   dot.separated.action-name, e.g. file.close or account.d
> >
> > Major stuff not yet migrated:
> > * In order to migrate the small business module, its entry ledger
> > has  
> >   to be rewritten, just like the "normal" register.
> > * AqBanking uses the gwenhywfar UI library, which in turn uses GTK+
> > 2.
> >   I have not yet looked into this.
> > * I removed the old file history/recent files code. There are
> > better
> >   ways to do this in GTK+ 3.
> > * I haven't converted every UI definition file to the new format
> > for
> >   now.
> >
> > Things that I recommend be dropped/removed for GnuCash 3.0:
> > * Maintaining both the CMake and autotools-based build system does
> > not
> >   seem like a good idea, so drop autotools.
> > * Rewriting the old register is not really viable or useful,
> >   so drop it. Currently, either the old or the new register is
> > compiled
> >   to ease transition. (Right now, the new register can be enabled
> > in
> >   addition to the old register.)
> > * The dynamic module system (based on GModule) is a nice idea, but
> > the
> >   
> >   benefits are dubious at the moment. While the dynamic loading of
> > all
> >  
> >   the standard modules incurs a heavy startup delay, there is no
> >   reason why a user would not want to load all the built-in
> > modules.
> >   Therefore, all GnuCash modules should be converted into
> > statically
> >   linked objects. (It is still possible to compile shared libraries
> >   for Guile at the same time, CMake should have no problem doing
> >   that.)
> >
> > Major Changes that I highly recommend for a GnuCash 3.0 release:
> > * Writing GObject-based code (i.e. GTK+ code) in C is a very
> > cumbersome
> >   and boilerplate-ish process. Vala makes it possible to write
> > GObject
> >  
> >   code in a very concise way, all while compiling directly to C
> > source
> >  
> >   (and C headers), making it possible to seamlessy integrate Vala
> > code
> >   into C code. Other C-to-Vala ports have seen significant
> > decreases in
> >   
> >   code size. Porting the UI code to Vala should definitiely ease
> >   maintainability, correctness and readability without sacrificing
> >   performance.
> > * I ported the core application code to use GtkApplication. It
> > would
> > be 
> >   nice to change the main window - opened file relationship from
> > the
> >   current N:1 to a 1:1, i.e. each main window is separate and has
> >   exactly one opened file. This would simplify the main window
> > code.
> >   It also seems more intuitive than the current behaviour, since
> > the
> >   user does not expect that all windows change the opened file if
> > he
> >   opens a file in one window.
> > * UI design: see below
> > * I have not yet looked at translations and accelerators.
> > * The new register requires some more love.
> >
> > Nice-to-haves regarding GTK:
> > * Some GSimpleActions would be better off as GPropertyActions.
> > * Validate all GtkBuilder files using gtk-builder-tool.
> > * File Chooser Dialog: Implement proper file format filter.
> > * xdg-app support
> > * jqplot as a Git submodule
> > * Have hints for GtkEntries
> >
> > Nice-to-haves, other that the UI:
> > * Replace the GncInt128 with Boost.Multiprecision
> > * I added initial configuration files for clang-format and clang-
> > tidy.
> >   The latter could be integrated as a Git commit hook.
> >
> > Bugfixing paths:
> > * I have added basic support for compiling GnuCash with the address
> >   sanitizer (ASan) and the undefined behaviour sanitizer (UBSan),
> >   although in practice, the former only works using LD_PRELOAD at
> >   runtime (which is discouraged) due to a Guile error.
> > * Many of the warnings you see compiling my tree really are valid
> >   errors and should be fixed.
> >
> > UI Design Notes:
> >
> > The current UI has the menubar as the central element. Depending
> > on    
> > which "plugin page" you're currently looking at, certain menus are
> > shown or hidden, e.g. the "Transaction" menu is only visible when
> > viewing a register page. In theory, this behaviour is also
> > available in
> > my development tree thanks to the EggMenuManager (taken from Gnome
> > Builder), but I removed the relevant calls for the moment. Please
> > read
> > on for the reasons. (Search for calls to egg_menu_manager_remove)
> >
> > Both the heavy usage of menus and the context-sensitive visibility
> > of
> > menus are discouraged by the Gnome 3 HIG. A more modern UI design
> > would
> > greatly benefit the GnuCash user experience. (Before continuing,
> > please
> > have a quick look at the Gnome 3 HIG right now if you haven't yet.)
> >
> > I haven't spent a great deal of time thinking about a potential new
> > UI
> > design yet, but in general, it boils down to having the page-
> > specific
> > actions as buttons inside a toolbar, and general actions in a
> > header
> > bar (GtkHeaderBar). As an example, let's take the register:
> >  * New Account: A plus button on the toolbar
> >  * Register Style: Clicking on "sandwich"-like button opens a
> > popover
> >    offering the different styles as a slider (as in Nautilus: the
> >    button left of the sandwich button offers the different Nautilus
> >    style options)
> >  * View - Search by: As "search" button in the header bar
> >
> > In general, you can get a lot of design inspiration by looking at
> > Gnome
> > Apps, in particular some of the recently refreshed ones, e.g.
> > Files/Nautilus, Videos/Totem, Maps, Documents or Document
> > Viewer/evince.
> >
> > Asking the Gnome Design Team for suggestions is also a possible
> > avenue.
> >
> > Thanks for your time and attention - let's make GnuCash an even
> > better
> > free software finance manager!
> >
> Dear Tobias,
>
> That's a huge amount of work, but it's a bit too far-reaching to be
> considered a patch set and it doesn't really look like something we
> can merge.

Greetings John,

first of all, thanks for your comments. No Sweat - I'm not asking for a
merge right now, this is really just a fundamental set of patches to
get GnuCash running under GTK+ 3 and obviously needs more work.

>
>
> It's also quite possible that we won't ever move GnuCash to Gtk+-3.
> We haven't decided on a future UI toolkit and if you'd looked at
> http://wiki.gnucash.org/wiki/Roadmap you'd realize that we have other
> priorities. Unfortunately it doesn't look like many of your changes
> advance those priorities, and the way you've done your changes would
> make it very difficult indeed to cherry-pick out the parts that might
> be useful. 

Please have a look at the roadmap again :D There are only two
paragraphs regarding the UI in the roadmap, and they are "Register
rewrite" - my work is basically building on top of the register rewrite
- and "Eliminate deprecated widgets and libraries" - that's what my
patches are all about - going from GTK+ 2 to GTK+ 3, from webkitgtk to
webkit2gtk, and replacing the deprecated Gnome Canvas based code! :)

Regarding the toolkits, I will respond in detail at the end of this
reply.

About the non-GTK+3-ish changes: I've tried to keep some of the more
general improvements on the next branch, but unfortunately, most of the
changes are complex enough that cherry-picking them from the gtk3
branch is possible, but somewhat complicated. Since the actual coding
work was large enough, I concentrated on getting the initial migration
ready.

>
> Had you come here before starting work we could have guided you
> towards work that could be merged and coached you about making commit
> messages, style, and the like. Perhaps you'd consider starting over?

If by starting over you mean doing some more rebasing to improve the
commit messages, sure! But as I said, I would rather get my gtk3 branch
feature-ready, i.e. implement the major points I mentioned above.
Please let me know which changes were especially unclear or confusing,
and I will happily improve their commit messages.

About the commit messages: I can do better, I promise :D
As mentioned above, I focused on getting the branch ready.
Most of the "Gnome WIP" commits are pretty similar actually, they all
consist of the core GTK+ 3 migration changes, i.e. replacing deprecated
features by their recommended replacements.

What exactly do you mean with style? I tried to have most of my
additions follow the general style of the relevant file.

>
>
> About your recommendations:
> * We probably will drop autotools in favor of cmake for the next
> release.
>
> * Vala is not useful to GnuCash. It is usable only with Gtk+ and we
> need to be able to write GUIs for other platforms. We decided two
> years ago to redo the guts in C++11 and are working on that.

John, I didn't mean to say that the entire GnuCash codebase should be
written in Vala, that certainly wouldn't be the right way. My idea is
to rewrite just the UI (i.e. GTK) code in Vala.

Don't get me wrong, I love C++ and C++11/14 most of all! I just thought
that if the UI code is rewritten, and I think we both agree that the
current UI code consists of a lot of boilerplate code, it should be
rewritten in Vala. (But honestly, that's not a very strong opinion of
mine, as I said, I really like C++ too.)

The reason why I suggested Vala instead of C++/gtkmm is that Vala is a
1:1 match to the GObject system, and while gtkmm code is certainly
easier to write that pure GTK+/C code, they aren't really a perfect
match.

My general point is that the UI code, after migrating it to GTK+ 3, has
some parts that could benefit from some refactoring, e.g. removing
certain now unnecessary functions (especially GtkAction/GAction related
stuff). Whether it is rewritten in Vala or in C++ doesn't really matter
from that perspective.

Thinking about it again, a rewrite in C++ obviously gives the
additional benefit of better integrating with the existing core GnuCash
code.

>
> * Agreed that rewriting the old register isn't attractive, but a
> developer spent a year trying to get a new GtkTreeView-based register
> to work right and although he got close, it wasn't suitable for
> release. I presume that your Gtk3 port is based on that "Register2"
> code, and since you say that your work isn't releasable either that
> doesn't augur well for that line of development.

Yes, my code is entirely based on Register2. As you said it, it still
has some quirks, but I am sure they can be solved with not too much
further work. While it is possible to rewrite the old register using
GooCanvas/Clutter/the GOffice GocCanvas/whatever, it seems like double
work, since Register2 is quite close.

When I say that my code is not releasable right now, I do not mean that
there are fundamental flaws with it - it just needs some more
polishing. That doesn't mean that my work is fundamentally flawed :D

>
> * The dynamic module system is indeed a complication of dubious
> utility, but Guile works by dlopening libraries; one doesn't
> dynamically link them. Having GnuCash's executable statically linked
> and Guile using dlopened shared libraries won't work: They pass
> objects back-and-forth between each other so they need to use the
> same binary image. The Gnucash executable might be able to
> dynamically link the shared libraries instead of dlopening them on
> startup. It's worth trying out. We do have a long-term goal of
> getting Guile out of the middle of GnuCash and that would make static
> linking more feasible.  

Thanks for the clarification, that's what I expected.

>
> *We (I) did extensive performance testing with several multi-
> precision libraries including boost.multiprecision and found that
> their dependence on the free store made them unacceptably slow.
> GncInt128 uses the same algorithms (they're in Knuth) but is stack
> based and so substantially faster than boost.multiprecision. The gory
> details can be found by following the long thread beginning at https:
> //lists.gnucash.org/pipermail/gnucash-devel/2014-May/037723.html.

Again, thank you very much for the clarification. That thread was an
interesting read.

> * We certainly recognize that GnuCash's GUI design is a bit dated,
> but a redesign depends to a large degree on the toolkit one uses.
> Since we're not ready to choose a new toolkit we're also not ready to
> undertake a major redesign. Regardless, the Gnome3 HIG is unlikely to
> factor much in our design decisions.

You mentioned above that GTK+ 3 is not the direction you want to take
the project, and you suggest that the design direction you want to take
is should be based on the "new" toolkit.
To be honest, I don't think GnuCash needs to have one exclusive and
authorative UI, and I don't really see a problem supporting more than
only one toolkit - just like GnuCash has a SQLite, a MySQL and an XML
backend and supports Windows, Mac OS X and Linux. In fact, other
projects like VLC have done that for years.

Now, let's say that some developers would like to include a Qt UI.
CuteCash obviously already succeeded doing that, even if it has not
received significant improvements since 2011 and is based on the
somewhat outdated Qt4 toolkit. Is there any reason not to have both
GnuCash (if GnuCash will be the GTK GnuCash) and CuteCash? I wouldn't
say so.

Since I like GTK+, I would prefer to have GnuCash use, besides any
other toolkits, GTK+ 3, where new development happens - and I see no
reason not to change GnuCash to support GTK+ 3 and to move the UI a bit
close to the Gnome 3 HIG. Please bear in mind that this does not
necessitate a complete and major redesign of the entire UI.

All in all, thanks again for your feedback and I'm looking forward to
your reply!

Kind regards,
Tobias
>
>
> Regards,
> John Ralls
>
>
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

Geert Janssens-4
In reply to this post by Tobias Markus
Hi Tobias,

For some reason I missed your original announcement. Your reply to John made me find it.

Anyway...

First off, thanks for the effort you have spent so far to migrate gnucash to gtk+3. I gather this is
a huge job (and the size of your branch confirms this).

I agree with John we haven't decided on our future toolkit yet. However I also believe gtk+2 is a
dead end and porting from gtk+2 to gtk+3 is currently the least effort we can make to stay
relevant. Even if it may turn out gtk+3 won't be the future officially endorsed toolkit by the core
developers at some point, it will bring gnucash now to a actively supported toolkit. So I am all
for getting gnucash running under gtk+3.

Having said that, I unfortunately also have a few reservations with your current approach.

I looked a a few commits in your branch. My first impression is that the conversion happened
slightly chaotically (like in a coding frenzy). That's fine for a first code run. However we prefer
our central code to be more structured. The idea is that not only you at this point in time needs
to understand what happened. All other gnucash developers should as well. And that means
both at present as well as 5 years in the future.

So to get your work merged it will need some clean up at least.

A few general suggestions:
1. Better commit messages. Each commit message should summarize what the commit does.
2. Make changes as atomic as possible. One commit should focus on one change. Depending on
the change, a commit can be large or small. As long as it remains clear what that commit is
doing.
3. Split out cosmetic changes (like whitespace and indentation fixes) from functional changes.

I'll add more comments below between your message.

On Sunday 21 February 2016 20:12:58 Tobias Markus wrote:

> Hi GnuCash developers,
>
> over the last few feeks, I have developed a fundamental patchset that
> should get GnuCash up and running in GTK+ 3.
>
> The source code is available at GitHub:
> https://github.com/hesiod/gnucash/tree/gtk3
>
> Some independent commits are on the next branch. All GTK+ 3-related
> stuff is on the gtk3 branch.
>
> I'm sorry for the sometimes messy commits, but the number of commits
> is quite massive already and I really didn't have the time splitting
> them up. If you have any questions regarding a particular commit,
> feel free to ask me.

No need to apologize and we're not in a hurry. As said before however, your branch will need
tidying before it can be merged.

>
> DISCLAIMER: This is alpha-quality software and not at all ready for
> users! Please do not run GnuCash built from my development tree unless
> you want to contribute to the development process. This development
> version may delete all your data and eat your CPU!
>
> While I got GnuCash pretty much working under GTK+ 3, a lot of further
> (fundamental and architectural) changes are required before even
> thinking about a release. Simply spoken, we now have GnuCash working
> in GTK+ 3, but using GTK+/Gnome 2 patterns. While it is possible to
> go down this path, the user experience will be substandard,
> especially compared to the current releases.
>

Well, current release is obviously the baseline to compare with. If there are regressions in the
current functionality, these need to be fixed indeed before release.

> Because GnuCash 2.0 was (afaik) coupled to the GTK+ 2 migration, I
> suggest that the GTK+ 3 version should be GnuCash 3.0.
>

Perhaps indeed.

> A quick word on dependencies: I set the minimum GTK+ version to be
> 3.18 because I didn't try to compile it with any earlier versions,
> but backporting probably isn't too hard.
>
We will have to check what's available in the distributions we intend to support. The two most
conservative ones typically are Debian and RHEL.
Current stable Debian (8.0/Jesse) is at gtk+ 3.14.5. I don't think Debian will have another major
release at least one year before the next major gnucash release.
RHEL (7.2) is at gtk+ 3.14.13.

So I expect we will need to support 3.14.

> Major changes already in my tree:
> * All "rich" GtkActions/GtkRadioActions/GtkToggleActions were replaced
> by abstract GActions/GMenus. This doesn't sound like a lot, but is a
> major change. Please read the relevant API documentation and do not
> hestitate to ask me if you have any questions about the new GAction-
> based infrastructure. Sorry for not going into more detail, but
> describing the technical peculiarities here would take considerably
> too long.
> * I removed the splash screen and replaced it by GApplication's busy
>   notification in some places.

What's the motivation to remove the splash screen ? GnuCash is a slow loading application.
Several users prefer to have a splash screen indicating progress (like LibreOffice does for
example).
And yes, I understand that we could optimize loading speed to avoid the need for a splash
screen altogether. But we're not there yet by a long shot.

> * I updated the HTML code to use the Webkit2 API, but it needs some
>   more love.

That's a nice improvement. We were lagging on the Webkit upgrades. There is an important
reason for that though: it's almost impossible to build webkit on Windows. Do you intend to
tackle that part as well ? We'll need a usable Webkit2 library on Windows before we can land
your webkit2 api.

As an aside: I would prefer to see the migration to the Webkit2 API as a separate project from
the gtk3 migration to reduce the amount of moving parts per branch. If gtk3 migration depends
on webkit2 API, it should be done first. If not, it can also be done after the gtk3 migration has
stabilized.

> * Using GtkApplication renders everything related to
>   gtk-osx-integration unnecessary.

That would certainly be nice. John is in a better position to confirm or deny this.

> * This is unrelated to the GTK+ 3 migration, but I added a Markdown
>   version of the README and added a DOAP project description.

So now there are 2 README's to keep in sync and an additional DOAP description. I would
propose to keep only one README file. I have no strong preference over plain vs Markdown.
What benefit is the Markdown edition ?

And what benefit does the DOAP file bring us ?

Lastly as you say yourself, this is not Gtk+3 migration related, so would best be submitted as a
separate PR.
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

Geert Janssens-4
In reply to this post by Tobias Markus
On Monday 22 February 2016 18:56:24 Tobias Markus wrote:

> On So, 2016-02-21 at 13:22 -0800, John Ralls wrote:
> > > On Feb 21, 2016, at 11:12 AM, Tobias Markus <[hidden email]>
> > > wrote:
> > >
> >
> > Dear Tobias,
> >
> > That's a huge amount of work, but it's a bit too far-reaching to be
> > considered a patch set and it doesn't really look like something we
> > can merge.
>
> Greetings John,
>
> first of all, thanks for your comments. No Sweat - I'm not asking for
> a merge right now, this is really just a fundamental set of patches
> to get GnuCash running under GTK+ 3 and obviously needs more work.
> > It's also quite possible that we won't ever move GnuCash to Gtk+-3.
> > We haven't decided on a future UI toolkit and if you'd looked at
> > http://wiki.gnucash.org/wiki/Roadmap you'd realize that we have
> > other
> > priorities. Unfortunately it doesn't look like many of your changes
> > advance those priorities, and the way you've done your changes would
> > make it very difficult indeed to cherry-pick out the parts that
> > might
> > be useful.
>
> Please have a look at the roadmap again :D There are only two
> paragraphs regarding the UI in the roadmap, and they are "Register
> rewrite" - my work is basically building on top of the register
> rewrite
Not quite. You are mixing migration to gtk+3 with rewriting the register in gtk. Two
major/fundamental changes in one go. As said in my other mail, that means two objectives to
keep track of and to untangle in case something is not working well. That's a large additional
burden in the maintenance phase later on.

Don't get me wrong. I believe both objectives are valuable. But one after the other, not in one
go.

> - and "Eliminate deprecated widgets and libraries" - that's
> what my patches are all about - going from GTK+ 2 to GTK+ 3, from
> webkitgtk to webkit2gtk, and replacing the deprecated Gnome Canvas
> based code! :)

Again: 3 major migrations in one go. Same objections. Untangle these 3 migrations please.

>
> Regarding the toolkits, I will respond in detail at the end of this
> reply.
>
> About the non-GTK+3-ish changes: I've tried to keep some of the more
> general improvements on the next branch, but unfortunately, most of
> the changes are complex enough that cherry-picking them from the gtk3
> branch is possible, but somewhat complicated. Since the actual coding
> work was large enough, I concentrated on getting the initial
> migration ready.
>
> > Had you come here before starting work we could have guided you
> > towards work that could be merged and coached you about making
> > commit
> > messages, style, and the like. Perhaps you'd consider starting over?
>
> If by starting over you mean doing some more rebasing to improve the
> commit messages, sure! But as I said, I would rather get my gtk3
> branch feature-ready, i.e. implement the major points I mentioned
> above.

And this is where we seem to disagree on the approach. Getting a branch feature-ready at the
expense of strategic considerations is making it harder on everybody else that is interested in
your work.

I'll repeat I prefer change sets that are well structured (to the extent possible), even if that
means the end goal of feature completeness takes longer to achieve. It saves time in the
maintenance phase which is generally much longer still than the initial implementation phase.

Don't get me wrong. I do appreciate what you have achieved so far and the time and effort you
put into it. I do ask you to consider the other developers' time as well by refactoring your code
into a more coherent set of patches.

> Please let me know which changes were especially unclear or
> confusing, and I will happily improve their commit messages.
>
See above for my first impression.

> About the commit messages: I can do better, I promise :D

Good :)

> As mentioned above, I focused on getting the branch ready.
> Most of the "Gnome WIP" commits are pretty similar actually, they all
> consist of the core GTK+ 3 migration changes, i.e. replacing
> deprecated features by their recommended replacements.
>
Ok. Let the commit messages reflect this. It will probably make it considerably more easy to
digest your branch.

> What exactly do you mean with style? I tried to have most of my
> additions follow the general style of the relevant file.
>
> > About your recommendations:
> > * We probably will drop autotools in favor of cmake for the next
> > release.
> >
> > * Vala is not useful to GnuCash. It is usable only with Gtk+ and we
> > need to be able to write GUIs for other platforms. We decided two
> > years ago to redo the guts in C++11 and are working on that.
>
> John, I didn't mean to say that the entire GnuCash codebase should be
> written in Vala, that certainly wouldn't be the right way. My idea is
> to rewrite just the UI (i.e. GTK) code in Vala.
>
> Don't get me wrong, I love C++ and C++11/14 most of all! I just
> thought that if the UI code is rewritten, and I think we both agree
> that the current UI code consists of a lot of boilerplate code, it
> should be rewritten in Vala. (But honestly, that's not a very strong
> opinion of mine, as I said, I really like C++ too.)
>
> The reason why I suggested Vala instead of C++/gtkmm is that Vala is a
> 1:1 match to the GObject system, and while gtkmm code is certainly
> easier to write that pure GTK+/C code, they aren't really a perfect
> match.

That does make sense indeed. On the other hand the current objective is the slowly migrate
away from the GObject system, replacing it with true C++ OO.

One important reason for that is portability to mobile platforms (think IOS, Android). Some time
back it looked like glib/GObject was a major roadblock in that direction. I don't know whether it
still is, but at the time that was one major driving factor to switch to C++. The future GUI
toolkit will also be evaluated in that context.

>
> My general point is that the UI code, after migrating it to GTK+ 3,
> has some parts that could benefit from some refactoring, e.g.
> removing certain now unnecessary functions (especially
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

John Ralls-2
In reply to this post by Tobias Markus

> On Feb 22, 2016, at 9:56 AM, Tobias Markus <[hidden email]> wrote:
>
> On So, 2016-02-21 at 13:22 -0800, John Ralls wrote:
>>>
>>> On Feb 21, 2016, at 11:12 AM, Tobias Markus <[hidden email]>
>>> wrote:
>>>
>>> Hi GnuCash developers,
>>>
>>> over the last few feeks, I have developed a fundamental patchset
>>> that
>>> should get GnuCash up and running in GTK+ 3.
>>>
>>> The source code is available at GitHub:
>>> https://github.com/hesiod/gnucash/tree/gtk3
>>>
>>> Some independent commits are on the next branch. All GTK+ 3-related
>>> stuff is on the gtk3 branch.
>>>
>>> I'm sorry for the sometimes messy commits, but the number of
>>> commits is
>>> quite massive already and I really didn't have the time splitting
>>> them
>>> up. If you have any questions regarding a particular commit, feel
>>> free
>>> to ask me.
>>>
>>> DISCLAIMER: This is alpha-quality software and not at all ready for
>>> users! Please do not run GnuCash built from my development tree
>>> unless
>>> you want to contribute to the development process. This development
>>> version may delete all your data and eat your CPU!
>>>
>>> While I got GnuCash pretty much working under GTK+ 3, a lot of
>>> further
>>> (fundamental and architectural) changes are required before even
>>> thinking about a release. Simply spoken, we now have GnuCash
>>> working in
>>> GTK+ 3, but using GTK+/Gnome 2 patterns. While it is possible to go
>>> down this path, the user experience will be substandard, especially
>>> compared to the current releases.
>>>
>>> Because GnuCash 2.0 was (afaik) coupled to the GTK+ 2 migration, I
>>> suggest that the GTK+ 3 version should be GnuCash 3.0.
>>>
>>> A quick word on dependencies: I set the minimum GTK+ version to be
>>> 3.18
>>> because I didn't try to compile it with any earlier versions, but
>>> backporting probably isn't too hard.
>>>
>>> Major changes already in my tree:
>>> * All "rich" GtkActions/GtkRadioActions/GtkToggleActions were
>>> replaced
>>>   by abstract GActions/GMenus. This doesn't sound like a lot, but
>>> is a
>>>   major change. Please read the relevant API documentation and do
>>> not
>>>   hestitate to ask me if you have any questions about the new
>>> GAction-
>>>   based infrastructure. Sorry for not going into more detail,
>>>   but describing the technical peculiarities here would take
>>>   considerably too long.
>>> * I removed the splash screen and replaced it by GApplication's
>>> busy
>>>   notification in some places.
>>> * I updated the HTML code to use the Webkit2 API, but it needs some
>>>   more love.
>>> * Using GtkApplication renders everything related to
>>>   gtk-osx-integration unnecessary.
>>> * This is unrelated to the GTK+ 3 migration, but I added a Markdown
>>>   version of the README and added a DOAP project description.
>>> * I changed the action naming pattern from CamelCaseAction to
>>>   dot.separated.action-name, e.g. file.close or account.d
>>>
>>> Major stuff not yet migrated:
>>> * In order to migrate the small business module, its entry ledger
>>> has  
>>>   to be rewritten, just like the "normal" register.
>>> * AqBanking uses the gwenhywfar UI library, which in turn uses GTK+
>>> 2.
>>>   I have not yet looked into this.
>>> * I removed the old file history/recent files code. There are
>>> better
>>>   ways to do this in GTK+ 3.
>>> * I haven't converted every UI definition file to the new format
>>> for
>>>   now.
>>>
>>> Things that I recommend be dropped/removed for GnuCash 3.0:
>>> * Maintaining both the CMake and autotools-based build system does
>>> not
>>>   seem like a good idea, so drop autotools.
>>> * Rewriting the old register is not really viable or useful,
>>>   so drop it. Currently, either the old or the new register is
>>> compiled
>>>   to ease transition. (Right now, the new register can be enabled
>>> in
>>>   addition to the old register.)
>>> * The dynamic module system (based on GModule) is a nice idea, but
>>> the
>>>  
>>>   benefits are dubious at the moment. While the dynamic loading of
>>> all
>>>  
>>>   the standard modules incurs a heavy startup delay, there is no
>>>   reason why a user would not want to load all the built-in
>>> modules.
>>>   Therefore, all GnuCash modules should be converted into
>>> statically
>>>   linked objects. (It is still possible to compile shared libraries
>>>   for Guile at the same time, CMake should have no problem doing
>>>   that.)
>>>
>>> Major Changes that I highly recommend for a GnuCash 3.0 release:
>>> * Writing GObject-based code (i.e. GTK+ code) in C is a very
>>> cumbersome
>>>   and boilerplate-ish process. Vala makes it possible to write
>>> GObject
>>>  
>>>   code in a very concise way, all while compiling directly to C
>>> source
>>>  
>>>   (and C headers), making it possible to seamlessy integrate Vala
>>> code
>>>   into C code. Other C-to-Vala ports have seen significant
>>> decreases in
>>>  
>>>   code size. Porting the UI code to Vala should definitiely ease
>>>   maintainability, correctness and readability without sacrificing
>>>   performance.
>>> * I ported the core application code to use GtkApplication. It
>>> would
>>> be
>>>   nice to change the main window - opened file relationship from
>>> the
>>>   current N:1 to a 1:1, i.e. each main window is separate and has
>>>   exactly one opened file. This would simplify the main window
>>> code.
>>>   It also seems more intuitive than the current behaviour, since
>>> the
>>>   user does not expect that all windows change the opened file if
>>> he
>>>   opens a file in one window.
>>> * UI design: see below
>>> * I have not yet looked at translations and accelerators.
>>> * The new register requires some more love.
>>>
>>> Nice-to-haves regarding GTK:
>>> * Some GSimpleActions would be better off as GPropertyActions.
>>> * Validate all GtkBuilder files using gtk-builder-tool.
>>> * File Chooser Dialog: Implement proper file format filter.
>>> * xdg-app support
>>> * jqplot as a Git submodule
>>> * Have hints for GtkEntries
>>>
>>> Nice-to-haves, other that the UI:
>>> * Replace the GncInt128 with Boost.Multiprecision
>>> * I added initial configuration files for clang-format and clang-
>>> tidy.
>>>   The latter could be integrated as a Git commit hook.
>>>
>>> Bugfixing paths:
>>> * I have added basic support for compiling GnuCash with the address
>>>   sanitizer (ASan) and the undefined behaviour sanitizer (UBSan),
>>>   although in practice, the former only works using LD_PRELOAD at
>>>   runtime (which is discouraged) due to a Guile error.
>>> * Many of the warnings you see compiling my tree really are valid
>>>   errors and should be fixed.
>>>
>>> UI Design Notes:
>>>
>>> The current UI has the menubar as the central element. Depending
>>> on    
>>> which "plugin page" you're currently looking at, certain menus are
>>> shown or hidden, e.g. the "Transaction" menu is only visible when
>>> viewing a register page. In theory, this behaviour is also
>>> available in
>>> my development tree thanks to the EggMenuManager (taken from Gnome
>>> Builder), but I removed the relevant calls for the moment. Please
>>> read
>>> on for the reasons. (Search for calls to egg_menu_manager_remove)
>>>
>>> Both the heavy usage of menus and the context-sensitive visibility
>>> of
>>> menus are discouraged by the Gnome 3 HIG. A more modern UI design
>>> would
>>> greatly benefit the GnuCash user experience. (Before continuing,
>>> please
>>> have a quick look at the Gnome 3 HIG right now if you haven't yet.)
>>>
>>> I haven't spent a great deal of time thinking about a potential new
>>> UI
>>> design yet, but in general, it boils down to having the page-
>>> specific
>>> actions as buttons inside a toolbar, and general actions in a
>>> header
>>> bar (GtkHeaderBar). As an example, let's take the register:
>>>  * New Account: A plus button on the toolbar
>>>  * Register Style: Clicking on "sandwich"-like button opens a
>>> popover
>>>    offering the different styles as a slider (as in Nautilus: the
>>>    button left of the sandwich button offers the different Nautilus
>>>    style options)
>>>  * View - Search by: As "search" button in the header bar
>>>
>>> In general, you can get a lot of design inspiration by looking at
>>> Gnome
>>> Apps, in particular some of the recently refreshed ones, e.g.
>>> Files/Nautilus, Videos/Totem, Maps, Documents or Document
>>> Viewer/evince.
>>>
>>> Asking the Gnome Design Team for suggestions is also a possible
>>> avenue.
>>>
>>> Thanks for your time and attention - let's make GnuCash an even
>>> better
>>> free software finance manager!
>>>
>> Dear Tobias,
>>
>> That's a huge amount of work, but it's a bit too far-reaching to be
>> considered a patch set and it doesn't really look like something we
>> can merge.
>
> Greetings John,
>
> first of all, thanks for your comments. No Sweat - I'm not asking for a
> merge right now, this is really just a fundamental set of patches to
> get GnuCash running under GTK+ 3 and obviously needs more work.
>
>>
>>
>> It's also quite possible that we won't ever move GnuCash to Gtk+-3.
>> We haven't decided on a future UI toolkit and if you'd looked at
>> http://wiki.gnucash.org/wiki/Roadmap you'd realize that we have other
>> priorities. Unfortunately it doesn't look like many of your changes
>> advance those priorities, and the way you've done your changes would
>> make it very difficult indeed to cherry-pick out the parts that might
>> be useful.
>
> Please have a look at the roadmap again :D There are only two
> paragraphs regarding the UI in the roadmap, and they are "Register
> rewrite" - my work is basically building on top of the register rewrite
> - and "Eliminate deprecated widgets and libraries" - that's what my
> patches are all about - going from GTK+ 2 to GTK+ 3, from webkitgtk to
> webkit2gtk, and replacing the deprecated Gnome Canvas based code! :)
>
> Regarding the toolkits, I will respond in detail at the end of this
> reply.
>
> About the non-GTK+3-ish changes: I've tried to keep some of the more
> general improvements on the next branch, but unfortunately, most of the
> changes are complex enough that cherry-picking them from the gtk3
> branch is possible, but somewhat complicated. Since the actual coding
> work was large enough, I concentrated on getting the initial migration
> ready.
>
>>
>> Had you come here before starting work we could have guided you
>> towards work that could be merged and coached you about making commit
>> messages, style, and the like. Perhaps you'd consider starting over?
>
> If by starting over you mean doing some more rebasing to improve the
> commit messages, sure! But as I said, I would rather get my gtk3 branch
> feature-ready, i.e. implement the major points I mentioned above.
> Please let me know which changes were especially unclear or confusing,
> and I will happily improve their commit messages.
>
> About the commit messages: I can do better, I promise :D
> As mentioned above, I focused on getting the branch ready.
> Most of the "Gnome WIP" commits are pretty similar actually, they all
> consist of the core GTK+ 3 migration changes, i.e. replacing deprecated
> features by their recommended replacements.
>
> What exactly do you mean with style? I tried to have most of my
> additions follow the general style of the relevant file.
>
>>
>>
>> About your recommendations:
>> * We probably will drop autotools in favor of cmake for the next
>> release.
>>
>> * Vala is not useful to GnuCash. It is usable only with Gtk+ and we
>> need to be able to write GUIs for other platforms. We decided two
>> years ago to redo the guts in C++11 and are working on that.
>
> John, I didn't mean to say that the entire GnuCash codebase should be
> written in Vala, that certainly wouldn't be the right way. My idea is
> to rewrite just the UI (i.e. GTK) code in Vala.
>
> Don't get me wrong, I love C++ and C++11/14 most of all! I just thought
> that if the UI code is rewritten, and I think we both agree that the
> current UI code consists of a lot of boilerplate code, it should be
> rewritten in Vala. (But honestly, that's not a very strong opinion of
> mine, as I said, I really like C++ too.)
>
> The reason why I suggested Vala instead of C++/gtkmm is that Vala is a
> 1:1 match to the GObject system, and while gtkmm code is certainly
> easier to write that pure GTK+/C code, they aren't really a perfect
> match.
>
> My general point is that the UI code, after migrating it to GTK+ 3, has
> some parts that could benefit from some refactoring, e.g. removing
> certain now unnecessary functions (especially GtkAction/GAction related
> stuff). Whether it is rewritten in Vala or in C++ doesn't really matter
> from that perspective.
>
> Thinking about it again, a rewrite in C++ obviously gives the
> additional benefit of better integrating with the existing core GnuCash
> code.
>
>>
>> * Agreed that rewriting the old register isn't attractive, but a
>> developer spent a year trying to get a new GtkTreeView-based register
>> to work right and although he got close, it wasn't suitable for
>> release. I presume that your Gtk3 port is based on that "Register2"
>> code, and since you say that your work isn't releasable either that
>> doesn't augur well for that line of development.
>
> Yes, my code is entirely based on Register2. As you said it, it still
> has some quirks, but I am sure they can be solved with not too much
> further work. While it is possible to rewrite the old register using
> GooCanvas/Clutter/the GOffice GocCanvas/whatever, it seems like double
> work, since Register2 is quite close.
>
> When I say that my code is not releasable right now, I do not mean that
> there are fundamental flaws with it - it just needs some more
> polishing. That doesn't mean that my work is fundamentally flawed :D
>
>>
>> * The dynamic module system is indeed a complication of dubious
>> utility, but Guile works by dlopening libraries; one doesn't
>> dynamically link them. Having GnuCash's executable statically linked
>> and Guile using dlopened shared libraries won't work: They pass
>> objects back-and-forth between each other so they need to use the
>> same binary image. The Gnucash executable might be able to
>> dynamically link the shared libraries instead of dlopening them on
>> startup. It's worth trying out. We do have a long-term goal of
>> getting Guile out of the middle of GnuCash and that would make static
>> linking more feasible.  
>
> Thanks for the clarification, that's what I expected.
>
>>
>> *We (I) did extensive performance testing with several multi-
>> precision libraries including boost.multiprecision and found that
>> their dependence on the free store made them unacceptably slow.
>> GncInt128 uses the same algorithms (they're in Knuth) but is stack
>> based and so substantially faster than boost.multiprecision. The gory
>> details can be found by following the long thread beginning at https:
>> //lists.gnucash.org/pipermail/gnucash-devel/2014-May/037723.html.
>
> Again, thank you very much for the clarification. That thread was an
> interesting read.
>
>> * We certainly recognize that GnuCash's GUI design is a bit dated,
>> but a redesign depends to a large degree on the toolkit one uses.
>> Since we're not ready to choose a new toolkit we're also not ready to
>> undertake a major redesign. Regardless, the Gnome3 HIG is unlikely to
>> factor much in our design decisions.
>
> You mentioned above that GTK+ 3 is not the direction you want to take
> the project, and you suggest that the design direction you want to take
> is should be based on the "new" toolkit.
> To be honest, I don't think GnuCash needs to have one exclusive and
> authorative UI, and I don't really see a problem supporting more than
> only one toolkit - just like GnuCash has a SQLite, a MySQL and an XML
> backend and supports Windows, Mac OS X and Linux. In fact, other
> projects like VLC have done that for years.
>
> Now, let's say that some developers would like to include a Qt UI.
> CuteCash obviously already succeeded doing that, even if it has not
> received significant improvements since 2011 and is based on the
> somewhat outdated Qt4 toolkit. Is there any reason not to have both
> GnuCash (if GnuCash will be the GTK GnuCash) and CuteCash? I wouldn't
> say so.
>
> Since I like GTK+, I would prefer to have GnuCash use, besides any
> other toolkits, GTK+ 3, where new development happens - and I see no
> reason not to change GnuCash to support GTK+ 3 and to move the UI a bit
> close to the Gnome 3 HIG. Please bear in mind that this does not
> necessitate a complete and major redesign of the entire UI.
>
> All in all, thanks again for your feedback and I'm looking forward to
> your reply!

Geert's done a good job of explaining some of the problems with your commits. I'd like to add to that that I've been down the road of trying to rearrange a too-random commit series into something rational and failed. It's not enough that each commit implement a single conceptual change as described in its commit message: It's also necessary that each commit compiles and passes the tests. If that breaks down then git bisect becomes useless for debugging regressions and that's too important a tool to allow that to happen.

An example of an extraneous change that doesn't belong in this branch—and shouldn't be made regardless—is fef6acc, "Change unusual abbreviation in AUTHORS". "&c" is unusual in the US, but common in the UK. It's not obvious in most typewriter fonts, but an ampersand is actually a rather distorted Et, latin for "and".

1b80944, one of the "Gnome WIP" commits, seems to mix some extract-function refactors, some GApplication implementation, gratuitous edits (e.g. replacing the string "Gnucash Preferences" with "window preferences"), gratuitous commenting-out of debug code and code modernization (e.g. replacing gtk_alignment_set_padding with gtk_widget_set_margin_start), and a complete rewrite of exactly one builder file encompassing 16 files in total. Teasing that one commit apart so that it makes sense and so that each piece builds and tests will be difficult. You seem to have lots of changes like that.

One of the major problems with both the register and register2 implementations is that there's a lot of "business logic" code in register that Robert Fewell pasted wholesale into register2. That code needs to be extracted to a (single) separate layer so that the GUI code only does GUI. This problem isn't limited to register, either: There's tons of "business logic" code spattered throughout gnome and gnome-utils. Had you come to us first I would have explained that to you and tried to get you to work on that first. I'd still like you to do that (in its own feature branch) if you're willing.

If you haven't already done so you should look at all of the Register2 bugs in bugzilla. Register2 has its own category to make that easy.

Since you're presumably familiar with Gtk+ coding style, GnuCash's is the same with one exception: We indent 4 spaces instead of 2.

I'm not in favor of Vala even for Gtk development because very few developers know it. Guile has been an enormous barrier to recruitment for exactly the same reason, and I don't want to compound that problem.

Cutecash is a demo. It implements only part of GnuCash and while Christian tidies things up periodically to keep it working it has never become a serious alternative to Gtk. I think that that's because of the MVC violations I mentioned earlier, but only Christian really knows. When Christian wrote it we were still using subversion and it wasn't feasible for him to put it anywhere but in the main tree. Now with Git he'd probably have it on his personal Github repo.

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

John Ralls-2
In reply to this post by Geert Janssens-4

> On Feb 22, 2016, at 1:57 PM, Geert Janssens <[hidden email]> wrote:
>
>> Major changes already in my tree:
>> * All "rich" GtkActions/GtkRadioActions/GtkToggleActions were replaced
>> by abstract GActions/GMenus. This doesn't sound like a lot, but is a
>> major change. Please read the relevant API documentation and do not
>> hestitate to ask me if you have any questions about the new GAction-
>> based infrastructure. Sorry for not going into more detail, but
>> describing the technical peculiarities here would take considerably
>> too long.
>> * I removed the splash screen and replaced it by GApplication's busy
>>  notification in some places.
>
> What's the motivation to remove the splash screen ? GnuCash is a slow loading application.
> Several users prefer to have a splash screen indicating progress (like LibreOffice does for
> example).
> And yes, I understand that we could optimize loading speed to avoid the need for a splash
> screen altogether. But we're not there yet by a long shot.
>
>> * I updated the HTML code to use the Webkit2 API, but it needs some
>>  more love.
>
> That's a nice improvement. We were lagging on the Webkit upgrades. There is an important
> reason for that though: it's almost impossible to build webkit on Windows. Do you intend to
> tackle that part as well ? We'll need a usable Webkit2 library on Windows before we can land
> your webkit2 api.
>
> As an aside: I would prefer to see the migration to the Webkit2 API as a separate project from
> the gtk3 migration to reduce the amount of moving parts per branch. If gtk3 migration depends
> on webkit2 API, it should be done first. If not, it can also be done after the gtk3 migration has
> stabilized.
>
>> * Using GtkApplication renders everything related to
>>  gtk-osx-integration unnecessary.
>
> That would certainly be nice. John is in a better position to confirm or deny this.
>
>> * This is unrelated to the GTK+ 3 migration, but I added a Markdown
>>  version of the README and added a DOAP project description.
>
> So now there are 2 README's to keep in sync and an additional DOAP description. I would
> propose to keep only one README file. I have no strong preference over plain vs Markdown.
> What benefit is the Markdown edition ?
>
> And what benefit does the DOAP file bring us ?
>
> Lastly as you say yourself, this is not Gtk+3 migration related, so would best be submitted as a
> separate PR.

Several different branches: WebKit2, GApplication, and Gtk3 migration. At least. There's probably more buried in there.

GApplication (NOT GtkApplication, that's obsolete and doesn't work on OS X or replace gtk-mac-integration) is a significant architectural change in the program and is separate from Gtk3 migration. I haven't actually tested it. Have any major applications switched? Aside from obviating gtk-mac-integration and maybe integrating better with the Gnome3 desktop what are the benefits?

A markdown README looks nicer on Github. Markdown is quite legible in plain text, there's no reason to have two.

doap files are used by git.gnome.org for organizing the display of projects. GnuCash has no need of a doap file.

Regards,
John Ralls





_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

Christian Stimming-4
In reply to this post by Tobias Markus
Hi Tobias,

thanks for the interesting work on the gnucash application! I've seen the
other replies here, but I would like to add some remarks to your proposals
with a somewhat different direction:

Am Sonntag, 21. Februar 2016, 20:12:58 schrieb Tobias Markus:
> While I got GnuCash pretty much working under GTK+ 3, a lot of further
> (fundamental and architectural) changes are required before even
> thinking about a release. Simply spoken, we now have GnuCash working in
> GTK+ 3, but using GTK+/Gnome 2 patterns. While it is possible to go
> down this path, the user experience will be substandard, especially
> compared to the current releases.

I think it is great to get some sort of gnucash to run under a more up-to-date
UI toolkit. I think gtk2 is very much a dead-end, let alone those various
custom widgets inside gnucash that are even older. However, only very little
effort is being spent here to switch to a different toolkit. My guess is that
UI developers who work with modern UI toolkits have long abandoned on gnucash
development anyway... but that's just my opinion.

> A quick word on dependencies: I set the minimum GTK+ version to be 3.18
> because I didn't try to compile it with any earlier versions, but
> backporting probably isn't too hard.

In my opinion a switch to a new toolkit will be a radical step anyway, so feel
free to pick as new a version as is convenient to the developers involved.

> Major stuff not yet migrated:
> * AqBanking uses the gwenhywfar UI library, which in turn uses GTK+ 2.
>   I have not yet looked into this.

Yes, that would need some additional effort, because the UI calls that are
needed in the online banking code (of aqbanking) need some UI abstraction and
its author decided to implement his own abstraction, resulting in the
gwenhywfar UI structures. The gwenhywfar UI abstraction has implementations
for gtk2, qt4, qt5. For gtk3 "somebody" will have to port the existing code
there to gtk3, too... I can't tell whether any developer here will volunteer
for this.

> Things that I recommend be dropped/removed for GnuCash 3.0:
> * Maintaining both the CMake and autotools-based build system does not
>   seem like a good idea, so drop autotools.

Yes, absolutely. Autotools has been a pain in the neck for everyone here way
too long. I'm all for dropping it altogether, the sooner the better.

> * Rewriting the old register is not really viable or useful,
>   so drop it. Currently, either the old or the new register is compiled
>   to ease transition. (Right now, the new register can be enabled in
>   addition to the old register.)

Yes, switching to register2 or whatever the more up-to-date version is called
should also happen better sooner than later. However, this will mean a new
version will not be as feature-complete as the previous version. I doubt
whether this is a good goal in any case. Maybe we should be courageous enough
to just call the old gtk2 code a dead end, including all of its beloved
features here and there, and just say we will spend our development time only
in new modern code.

> * The dynamic module system (based on GModule) is a nice idea, but the
>   benefits are dubious at the moment. While the dynamic loading of all
>   the standard modules incurs a heavy startup delay, there is no
>   reason why a user would not want to load all the built-in modules.

Although most of the current modules are used always and hence better linked
in statically, there is still some benefit from the module system: Parts of
our features imply an additional large dependency tree, e.g. aqbanking, or
postgresql. Making them a module will enable distributions to package them in
separate packages, so that users will need the aqbanking dependencies only if
they install the gnucash-aqbanking module, or for postgresql the same. Hence,
I think gnucash should keep some sort of plugin system in any case.

However, currently due to guile's module loading we have additional
requirements on the way modules are used. Others here can explain this better
for sure.

> Major Changes that I highly recommend for a GnuCash 3.0 release:
> * Writing GObject-based code (i.e. GTK+ code) in C is a very cumbersome
>   and boilerplate-ish process. Vala makes it possible to write GObject
>   code in a very concise way

I agree whole-heartedly that writing UI code in C sucks, royally. For me this
has been the major reason to keep away from further gnucash development,
unless I needed some feature myself really badly. I mean, we have 2016. UI
programming should be done in some programming language that is good for this
job. C is not. Pretty much any other high-level programming language will do a
better job here. I don't know Vala so far and I can't judge whether the
benefits will outweigh enough the (presumed) rather small user base. C++,
C#/Mono, or Java are known to me and would do the job well enough, but other
languages are fine, too. Just get away from C w.r.t. UI programming.

As a side note, this might mean the Android App "gnucash-on-android" has a
huge advantage over the conventional desktop application in that it uses an
up-to-date programming language. Maybe some time down the road the Android app
will start to take over the desktop usage of gnucash as well... but  that's a
different discussion.

> UI Design Notes:
>
> The current UI has the menubar as the central element. Depending on    
> which "plugin page" you're currently looking at, certain menus are
> shown or hidden, (...)
> Both the heavy usage of menus and the context-sensitive visibility of
> menus are discouraged by the Gnome 3 HIG. A more modern UI design would
> greatly benefit the GnuCash user experience.

I agree with the statement in general, but I'm not convinced the Gnome 3 HIG
is a goal I would commit to. As you have read in the other replies, others
have their doubts about the Gnome 3 HIG as a wortwhile goal, too. On the other
hand, using just about any HIG will surely improve the usability of gnucash
just by having more consistency and listening to the thoughts that went into
the creation of the HIG. So maybe the Gnome3 HIG isn't such a bad choice. But
as you already saw the choice is currently far from being agreed upon.

Regards,
Christian
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

Christian Stimming-4
In reply to this post by Geert Janssens-4
Am Montag, 22. Februar 2016, 23:42:24 schrieb Geert Janssens:

> > The reason why I suggested Vala instead of C++/gtkmm is that Vala is a
> > 1:1 match to the GObject system, and while gtkmm code is certainly
> > easier to write that pure GTK+/C code, they aren't really a perfect
> > match.
>
> That does make sense indeed. On the other hand the current objective is the
> slowly migrate away from the GObject system, replacing it with true C++ OO.
>
> One important reason for that is portability to mobile platforms (think IOS,
> Android). Some time back it looked like glib/GObject was a major roadblock
> in that direction. I don't know whether it still is, but at the time that
> was one major driving factor to switch to C++. The future GUI toolkit will
> also be evaluated in that context.

I agree that porting from GObject to C++ is a step forward. However, by now I
have my doubts whether that effort is actually well invested anymore. Geert,
are you sure we said C++ would help in "portability to mobile platforms"? For
an android app, it is useless to have "the engine" in C - one needs it in Java
anyway, and that's why Ngewi wrote a re-implementation of our data structures
in Java for his gnucash-on-android app. I don't think a plain C++(11) plus
some boost dependencies would actually help anything when moving the app to a
mobile OS. Instead, C++ just tries to make the further development of the
desktop application somewhat more realistic. But there is just such a large
amount of code...

Regards,

Christian
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

Derek Atkins-3

On Wed, February 24, 2016 4:26 pm, Christian Stimming wrote:

> I agree that porting from GObject to C++ is a step forward. However, by
> now I
> have my doubts whether that effort is actually well invested anymore.
> Geert,
> are you sure we said C++ would help in "portability to mobile platforms"?
> For
> an android app, it is useless to have "the engine" in C - one needs it in
> Java
> anyway, and that's why Ngewi wrote a re-implementation of our data
> structures
> in Java for his gnucash-on-android app.

Yes, it will help.  If the engine were purely in C++ (without Glib) then
we could have just build a JNI layer around that to plug into an Android
UI.  This is actually relatively straighforward -- even moreso if it's a
nice C++ interface.

This didn't work with the existing engine because of the "too many
external dependencies" issue; he would have had to port glib to Android.

>       I don't think a plain C++(11) plus
> some boost dependencies would actually help anything when moving the app
> to a
> mobile OS. Instead, C++ just tries to make the further development of the
> desktop application somewhat more realistic. But there is just such a
> large
> amount of code...

Honestly I think it would help; the issue (in my mind) is the underlying
dependencies under the engine.  If we can remove glib, guile, and other
dependencies and leave it purely at C++ (and arguably boost), I think it
would go a long way to making it easier to port the engine to alternate
platforms like Android and iOS that would require their own UIs.

It does beg the question of whether this is a reasonable goal.  Do these
devices need to interoperate with the desktop gnucash data files?

> Regards,
>
> Christian

-derek

--
       Derek Atkins                 617-623-3745
       [hidden email]             www.ihtfp.com
       Computer and Internet Security Consultant

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: cutecash ([RFC] GTK+ 3 Migration - Alpha-grade Patchset)

Christian Stimming-4
In reply to this post by John Ralls-2
Am Montag, 22. Februar 2016, 21:03:30 schrieb John Ralls:
> Cutecash is a demo. It implements only part of GnuCash and while Christian
> tidies things up periodically to keep it working it has never become a
> serious alternative to Gtk. I think that that's because of the MVC
> violations I mentioned earlier, but only Christian really knows. When
> Christian wrote it we were still using subversion and it wasn't feasible
> for him to put it anywhere but in the main tree. Now with Git he'd probably
> have it on his personal Github repo.

Yes, cutecash was "just" a demo. For me, it was a test case in 2010 whether
Qt/C++ would have been a viable alternative for further UI programming. The
result of the test case after a few weeks was that this is indeed possible.
However, unfortunately there was zero interest around here in using Qt/C++ as
a UI programming language (except for the single GSoC project) , and thus I
abandoned that experiment, too. To my surprise the application still compiled
until recently. The cutecash compile targets were silently dropped last
december in favor of building gnucash itself by cmake, which in turn is surely
a good step.

But no, the Qt frontend did not have problems because of MVC violations
primarely. Instead, the main problem is that we have just such an insanely
large set of various features which all need their little UI here and there,
which would have to be ported one by one by one into a new UI toolkit iff one
wants to keep each and every of them in a new version of the program. The Qt
frontend could have been used right away if there were a demand for a faster
UI or somebody would have implemented some cool new requested feature only in
the Qt frontend, so that the benefit of switching would have outweighed the
drop in feature number. But this didn't happen... even though the Qt frontend
immediately had a full Undo/Redo feature with history, something we still
don't have in the C register because C sucks so much. Oh well.

Regards,

Christian
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

Ngewi Fet
In reply to this post by Derek Atkins-3
On Wed, Feb 24, 2016 at 10:37 PM, Derek Atkins <[hidden email]> wrote:

>
> ...If we can remove glib, guile, and other
> dependencies and leave it purely at C++ (and arguably boost), I think it
> would go a long way to making it easier to port the engine to alternate
> platforms like Android and iOS that would require their own UIs.
>
> It does beg the question of whether this is a reasonable goal.  Do these
> devices need to interoperate with the desktop gnucash data files?
>
>
Yes, judging from my experiences with GnuCash Android, I think it would be
very important for these devices to be able to inter-operate with desktop
gnucash files.
The Android app didn't have support for .gnucash files at the beginning,
but it had to be added because the demand from, and benefit to users was
very great.
By saving the data in the .gnucash format (rather than a new custom one),
users could make edits to their data using desktop GnuCash.
Also many users would like to make quick edits on-the-go, or just open and
view financial status on a tablet while out and about.

The mobile apps may not support every feature at the same time, but having
a common core would allow them to be able to understand the files and
preserve integrity of the data when reading/writing.
As the apps grow and add features, it will just be a matter of finding the
right UX paradigm for the features and exposing it to users.
But the core data, algorithms and storage would already by implemented and
maintained from a common code base. There is benefit of stability and speed
in that.

Anyways, I think this discussion is going into "new thread" territory. :)

Regards,
Ngewi F.
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

Tobias Markus
In reply to this post by John Ralls-2
On Mo, 2016-02-22 at 21:18 -0800, John Ralls wrote:

> >
> > On Feb 22, 2016, at 1:57 PM, Geert Janssens <geert.gnucash@kobaltwi
> > t.be> wrote:
> >
> > >
> > > Major changes already in my tree:
> > > * All "rich" GtkActions/GtkRadioActions/GtkToggleActions were
> > > replaced
> > > by abstract GActions/GMenus. This doesn't sound like a lot, but
> > > is a
> > > major change. Please read the relevant API documentation and do
> > > not
> > > hestitate to ask me if you have any questions about the new
> > > GAction-
> > > based infrastructure. Sorry for not going into more detail, but
> > > describing the technical peculiarities here would take
> > > considerably
> > > too long.
> > > * I removed the splash screen and replaced it by GApplication's
> > > busy
> > >  notification in some places.
> > What's the motivation to remove the splash screen ? GnuCash is a
> > slow loading application. 
> > Several users prefer to have a splash screen indicating progress
> > (like LibreOffice does for 
> > example).
> > And yes, I understand that we could optimize loading speed to avoid
> > the need for a splash 
> > screen altogether. But we're not there yet by a long shot.
> >
> > >
> > > * I updated the HTML code to use the Webkit2 API, but it needs
> > > some
> > >  more love.
> > That's a nice improvement. We were lagging on the Webkit upgrades.
> > There is an important 
> > reason for that though: it's almost impossible to build webkit on
> > Windows. Do you intend to 
> > tackle that part as well ? We'll need a usable Webkit2 library on
> > Windows before we can land 
> > your webkit2 api.
> >
> > As an aside: I would prefer to see the migration to the Webkit2 API
> > as a separate project from 
> > the gtk3 migration to reduce the amount of moving parts per branch.
> > If gtk3 migration depends 
> > on webkit2 API, it should be done first. If not, it can also be
> > done after the gtk3 migration has 
> > stabilized.
> >
> > >
> > > * Using GtkApplication renders everything related to
> > >  gtk-osx-integration unnecessary.
> > That would certainly be nice. John is in a better position to
> > confirm or deny this.
> >
> > >
> > > * This is unrelated to the GTK+ 3 migration, but I added a
> > > Markdown
> > >  version of the README and added a DOAP project description.
> > So now there are 2 README's to keep in sync and an additional DOAP
> > description. I would 
> > propose to keep only one README file. I have no strong preference
> > over plain vs Markdown. 
> > What benefit is the Markdown edition ?
> >
> > And what benefit does the DOAP file bring us ?
> >
> > Lastly as you say yourself, this is not Gtk+3 migration related, so
> > would best be submitted as a 
> > separate PR.
> Several different branches: WebKit2, GApplication, and Gtk3
> migration. At least. There's probably more buried in there.
I have to disagree here:

WebKit2 sounds like a huge step, but it really isn't. As one of the
last things before releasing the patchset, I tried to convert gnc-html-
webkit to WebKit2, and it was done rather quickly (and it works as in
"it shows a report, but I didn't go any further", but that doesn't mean
this really breaks stuff). The report system integration is not working
correctly right now, so I couldn't really test it, but I don't really
expect there are major deal-breakers along the way.

Moving to GApplication sounds unrelated, but it is not: In GTK+ 3,
there are window actions and application actions. Most actions are
window actions, except for file-unrelated actions like Quit, Help,
About, Preferences, etc. The latter actions are - big surprise - added
to the GApplication/GtkApplication. So without moving to GApplication,
the migration to GActions (which, oversimplified, is what moving to
GTK+ 3 is all about), is not possible. Unless you intended to merge the
move to GApplication right now, independently of the GTK+ 3 migration,
I see no reason for the significant effort of separating the two.
>
> GApplication (NOT GtkApplication, that's obsolete and doesn't work on
> OS X or replace gtk-mac-integration)
That is simply not true, GtkApplication is not obselete at all. Why
should the *official* GTK+ tutorial (https://developer.gnome.org/gtk3/s
table/gtk-getting-started.html) use GtkApplication if it was
deprecated?

On gtk-mac-integration: Citing from your gtk-mac-integration repo at ht
tps://github.com/jralls/gtk-mac-integration:

"NB: Applications already using Gtk+-3.4 and GLib 2.36 and later should
use the GApplication/GtkApplication and GMenuModel/GMenu APIs which
make this library unnecessary."

> is a significant architectural change in the program and is separate
> from Gtk3 migration.
No, it's not separate. See above.
> I haven't actually tested it.
Is you having tested GApplication in person a prerequisite for it to be
worth merging?
> Have any major applications switched?
Which major applications? All major applications don't use Guile, so
should Guile be removed from GnuCash?
> Aside from obviating gtk-mac-integration and maybe integrating better
> with the Gnome3 desktop what are the benefits? 
I thought GtkApplication does not make gtk-mac-integration unnecessary
at all?

There is a simple benefit: GnuCash (currently) is a GTK+ application,
and there is no reason why it shouldn't use a feature that improves
integration with the desktop. If you don't like GApplication and GTK+,
just finish CuteCash.
>
> A markdown README looks nicer on Github. Markdown is quite legible in
> plain text, there's no reason to have two.
That is my reasoning, too.
>
> doap files are used by git.gnome.org for organizing the display of
> projects. GnuCash has no need of a doap file.
Ah, so because someone at Gnome uses DOAP files, they are poisoned and
GnuCash should never include a DOAP file?
The Python Package Index Index (PyPi) with over 75k packages uses DOAP
files for their project descriptions.
>
> Regards,
> John Ralls

John, I think we maybe had a somewhat bad start. But please don't write
off everything I do trying to improve GnuCash as bad just because it is
related to GTK+.

Best regargs,
Tobias
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

Tobias Markus
In reply to this post by Christian Stimming-4
On Mi, 2016-02-24 at 22:26 +0100, Christian Stimming wrote:

> Am Montag, 22. Februar 2016, 23:42:24 schrieb Geert Janssens:
> >
> > >
> > > The reason why I suggested Vala instead of C++/gtkmm is that Vala
> > > is a
> > > 1:1 match to the GObject system, and while gtkmm code is
> > > certainly
> > > easier to write that pure GTK+/C code, they aren't really a
> > > perfect
> > > match.
> > That does make sense indeed. On the other hand the current
> > objective is the
> > slowly migrate away from the GObject system, replacing it with true
> > C++ OO.
> >
> > One important reason for that is portability to mobile platforms
> > (think IOS,
> > Android). Some time back it looked like glib/GObject was a major
> > roadblock
> > in that direction. I don't know whether it still is, but at the
> > time that
> > was one major driving factor to switch to C++. The future GUI
> > toolkit will
> > also be evaluated in that context.
> I agree that porting from GObject to C++ is a step forward. However,
> by now I 
> have my doubts whether that effort is actually well invested anymore.
> Geert, 
> are you sure we said C++ would help in "portability to mobile
> platforms"? For 
> an android app, it is useless to have "the engine" in C - one needs
> it in Java 
> anyway, and that's why Ngewi wrote a re-implementation of our data
> structures 
> in Java for his gnucash-on-android app. I don't think a plain C++(11)
> plus 
> some boost dependencies would actually help anything when moving the
> app to a 
> mobile OS. Instead, C++ just tries to make the further development of
> the 
> desktop application somewhat more realistic. But there is just such a
> large 
> amount of code...
>
> Regards,
>
> Christian
I would say it looks like a lot to port right now, but there is a lot
of code - the old register in particular - that could be removed moving
forward, somewhat easing moving to C++.

Best regards,
Tobias
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

John Ralls-2
In reply to this post by Tobias Markus

> On Feb 27, 2016, at 5:32 AM, Tobias Markus <[hidden email]> wrote:
>
> On Mo, 2016-02-22 at 21:18 -0800, John Ralls wrote:
> I have to disagree here:
>
> WebKit2 sounds like a huge step, but it really isn't. As one of the
> last things before releasing the patchset, I tried to convert gnc-html-
> webkit to WebKit2, and it was done rather quickly (and it works as in
> "it shows a report, but I didn't go any further", but that doesn't mean
> this really breaks stuff). The report system integration is not working
> correctly right now, so I couldn't really test it, but I don't really
> expect there are major deal-breakers along the way.

Immaterial. Webkit2 and Gtk3 migration are separate, so they need to be in separate PRs.

>
> Moving to GApplication sounds unrelated, but it is not: In GTK+ 3,
> there are window actions and application actions. Most actions are
> window actions, except for file-unrelated actions like Quit, Help,
> About, Preferences, etc. The latter actions are - big surprise - added
> to the GApplication/GtkApplication. So without moving to GApplication,
> the migration to GActions (which, oversimplified, is what moving to
> GTK+ 3 is all about), is not possible. Unless you intended to merge the
> move to GApplication right now, independently of the GTK+ 3 migration,
> I see no reason for the significant effort of separating the two.

Contrary to my experience: Gramps migrated from Gtk2 to Gtk3 two years ago without adopting any of GtkApplication or GApplication code. Separate PRs.

>>
>> GApplication (NOT GtkApplication, that's obsolete and doesn't work on
>> OS X or replace gtk-mac-integration)
> That is simply not true, GtkApplication is not obselete at all. Why
> should the *official* GTK+ tutorial (https://developer.gnome.org/gtk3/s
> table/gtk-getting-started.html) use GtkApplication if it was
> deprecated?

Because Gtk's developers are no better at maintaining documentation than everyone else's.
>
> On gtk-mac-integration: Citing from your gtk-mac-integration repo at ht
> tps://github.com/jralls/gtk-mac-integration:
>
> "NB: Applications already using Gtk+-3.4 and GLib 2.36 and later should
> use the GApplication/GtkApplication and GMenuModel/GMenu APIs which
> make this library unnecessary."

No argument. That's about new code.

>
>> is a significant architectural change in the program and is separate
>> from Gtk3 migration.
> No, it's not separate. See above.

Repeating: Gramps migrated to Gtk3 and did not rewrite to GApplication.
>> I haven't actually tested it.
> Is you having tested GApplication in person a prerequisite for it to be
> worth merging?

Not only have *I* not tested it but I don't know of any major Gtk application that has either. I'm sure it works fine on Linux but I have no reason
>> Have any major applications switched?
> Which major applications? All major applications don't use Guile, so
> should Guile be removed from GnuCash?

Yes, but that's a separate matter entirely. Examples of other major Gtk applications whose development team maintains Windows and Mac versions include The GIMP and Ardour. GIMP is the progenitor of Gtk -- the TLA originally decomposed as GIMP Tool Kit -- and they have not yet merged their Gtk3 development branch. Not only that but it uses GtkOSXApplication, not GApplication.

What other applications of similar size and with large cross-platform user bases have adopted GApplication?
 

>> A markdown README looks nicer on Github. Markdown is quite legible in
>> plain text, there's no reason to have two.
> That is my reasoning, too.
>>
>> doap files are used by git.gnome.org for organizing the display of
>> projects. GnuCash has no need of a doap file.
> Ah, so because someone at Gnome uses DOAP files, they are poisoned and
> GnuCash should never include a DOAP file?
> The Python Package Index Index (PyPi) with over 75k packages uses DOAP
> files for their project descriptions.

No, because Github *doesn't* use DOAP files adding one to GnuCash accomplishes *nothing*. GnuCash isn't hosted at git.gnome.org and it would be *really* strange for it to be in PyPI.



_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

John Ralls-2
In reply to this post by Tobias Markus

> On Feb 27, 2016, at 5:32 AM, Tobias Markus <[hidden email]> wrote:
> I have to disagree here:
...
>
>
> There is a simple benefit: GnuCash (currently) is a GTK+ application,
> and there is no reason why it shouldn't use a feature that improves
> integration with the desktop. If you don't like GApplication and GTK+,
> just finish CuteCash.
...
>
> John, I think we maybe had a somewhat bad start. But please don't write
> off everything I do trying to improve GnuCash as bad just because it is
> related to GTK+.


You did get off to a bad start, and you've made it worse with this letter.

Perhaps English is not your first language and you are deaf to the attitude that you project: That you think that you're the one who decides GnuCash's direction and that the actual development team are a bunch of incompetent subordinates that you are trying to direct.

The usual way for new developers to get involved with open-source projects is gradually: Small submissions, often bug fixes, that are easy to code-review and test in isolation. That helps the established developers on the project build confidence in the new contributor and to guide him or her towards the project's style and procedures. In time the new developer shows that they're committed to the project, have the necessary skills to take on larger work, and know the project's norms well enough that they know when they need to get input from other developers and to ask for it. You've chosen to do the opposite: You've produced an enormous change that would take many weeks of scarce developer time to review and tried to jam it into the project, disputing the input from the established developers who've tried to guide you.

So start over. First, introduce yourself: What is your interest in GnuCash, what is your experience, what other open source projects have you contributed too, that sort of stuff. Some personal info is a nice addition, it helps to establish a personal connection. Set your Gtk3 change aside for a while and work on some bug fixes. Alternatively, you said that the WebKit2 change is small, so break it out, clean up its history with good commit messages, and submit that as a PR.

Regards,
John Ralls



_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

Tobias Markus
In reply to this post by Geert Janssens-4
On Mo, 2016-02-22 at 22:57 +0100, Geert Janssens wrote:
> Hi Tobias,
>  
> For some reason I missed your original announcement. Your reply to
> John made me find it.
>  
> Anyway...

Hi Geert,

thanks for your feedback, I appreciate it.

>  
> First off, thanks for the effort you have spent so far to migrate
> gnucash to gtk+3. I gather this is a huge job (and the size of your
> branch confirms this).
>  
> I agree with John we haven't decided on our future toolkit yet.
> However I also believe gtk+2 is a dead end and porting from gtk+2 to
> gtk+3 is currently the least effort we can make to stay relevant.
> Even if it may turn out gtk+3 won't be the future officially endorsed
> toolkit by the core developers at some point, it will bring gnucash
> now to a actively supported toolkit. So I am all for getting gnucash
> running under gtk+3.

Thanks a lot.

>  
> Having said that, I unfortunately also have a few reservations with
> your current approach.
>  
> I looked a a few commits in your branch. My first impression is that
> the conversion happened slightly chaotically (like in a coding
> frenzy). That's fine for a first code run. However we prefer our
> central code to be more structured. The idea is that not only you at
> this point in time needs to understand what happened. All other
> gnucash developers should as well. And that means both at present as
> well as 5 years in the future.
>  
> So to get your work merged it will need some clean up at least.

That is totally understandable.

>  
> A few general suggestions:
> 1. Better commit messages. Each commit message should summarize what
> the commit does.
> 2. Make changes as atomic as possible. One commit should focus on one
> change. Depending on the change, a commit can be large or small. As
> long as it remains clear what that commit is doing.
> 3. Split out cosmetic changes (like whitespace and indentation fixes)
> from functional changes.

That's what I have in mind - it's just a lot of work for the ~150
commits I already have, not to mention those to come :D

>  
> I'll add more comments below between your message.
>  
> On Sunday 21 February 2016 20:12:58 Tobias Markus wrote:
> > Hi GnuCash developers,
> > 
> > over the last few feeks, I have developed a fundamental patchset
> that
> > should get GnuCash up and running in GTK+ 3.
> > 
> > The source code is available at GitHub:
> > https://github.com/hesiod/gnucash/tree/gtk3
> > 
> > Some independent commits are on the next branch. All GTK+ 3-related
> > stuff is on the gtk3 branch.
> > 
> > I'm sorry for the sometimes messy commits, but the number of
> commits
> > is quite massive already and I really didn't have the time
> splitting
> > them up. If you have any questions regarding a particular commit,
> > feel free to ask me.
>  
> No need to apologize and we're not in a hurry. As said before
> however, your branch will need tidying before it can be merged.
>  
> > 
> > DISCLAIMER: This is alpha-quality software and not at all ready for
> > users! Please do not run GnuCash built from my development tree
> unless
> > you want to contribute to the development process. This development
> > version may delete all your data and eat your CPU!
> > 
> > While I got GnuCash pretty much working under GTK+ 3, a lot of
> further
> > (fundamental and architectural) changes are required before even
> > thinking about a release. Simply spoken, we now have GnuCash
> working
> > in GTK+ 3, but using GTK+/Gnome 2 patterns. While it is possible to
> > go down this path, the user experience will be substandard,
> > especially compared to the current releases.
> > 
>  
> Well, current release is obviously the baseline to compare with. If
> there are regressions in the current functionality, these need to be
> fixed indeed before release.
>  
> > Because GnuCash 2.0 was (afaik) coupled to the GTK+ 2 migration, I
> > suggest that the GTK+ 3 version should be GnuCash 3.0.
> > 
>  
> Perhaps indeed.
>  
> > A quick word on dependencies: I set the minimum GTK+ version to be
> > 3.18 because I didn't try to compile it with any earlier versions,
> > but backporting probably isn't too hard.
> > 
> We will have to check what's available in the distributions we intend
> to support. The two most conservative ones typically are Debian and
> RHEL.
> Current stable Debian (8.0/Jesse) is at gtk+ 3.14.5. I don't think
> Debian will have another major release at least one year before the
> next major gnucash release.
> RHEL (7.2) is at gtk+ 3.14.13.
>  
> So I expect we will need to support 3.14.
That should be doable.

I'm really not a distributions expert, but wouldn't Debian for example
wait anyway before picking up a version 3.0.0? I thought they would
probably stay with the latest stable series anyway.

>  
> > Major changes already in my tree:
> > * All "rich" GtkActions/GtkRadioActions/GtkToggleActions were
> replaced
> > by abstract GActions/GMenus. This doesn't sound like a lot, but is
> a
> > major change. Please read the relevant API documentation and do not
> > hestitate to ask me if you have any questions about the new
> GAction-
> > based infrastructure. Sorry for not going into more detail, but
> > describing the technical peculiarities here would take considerably
> > too long.
> > * I removed the splash screen and replaced it by GApplication's
> busy
> >   notification in some places.
>  
> What's the motivation to remove the splash screen ? GnuCash is a slow
> loading application. Several users prefer to have a splash screen
> indicating progress (like LibreOffice does for example).
> And yes, I understand that we could optimize loading speed to avoid
> the need for a splash screen altogether. But we're not there yet by a
> long shot.
This is more of a temporary measure. I reasoned that if the loading
speed was improved significantly in time for the release, then the
splash screen wouldn't be needed anymore. And if startup speed was
still rather slow, reintegrating the splash screen into the
GApplication-based code would need some thought anyway to make sure it
integrates well.

GApplication provides a way to indicate to the user that the
application is currently busy via g_application_mark_busy. I included
that in the startup process, so even if the splash screen wasn't needed
anymore, the user would receive some feedback.
>  
> > * I updated the HTML code to use the Webkit2 API, but it needs some
> >   more love.
>  
> That's a nice improvement. We were lagging on the Webkit upgrades.
> There is an important reason for that though: it's almost impossible
> to build webkit on Windows. Do you intend to tackle that part as well
> ? We'll need a usable Webkit2 library on Windows before we can land
> your webkit2 api.
Sorry, but I'm no expert in doing Unix-ish stuff on Windows :D
>  
> As an aside: I would prefer to see the migration to the Webkit2 API
> as a separate project from the gtk3 migration to reduce the amount of
> moving parts per branch. If gtk3 migration depends on webkit2 API, it
> should be done first. If not, it can also be done after the gtk3
> migration has stabilized.
Please have a look at my answer to John's post, but in short: Porting
the code to WebKit2 was a breeze, but I haven't conducted any thorough
testing yet.

>  
> > * Using GtkApplication renders everything related to
> >   gtk-osx-integration unnecessary.
>  
> That would certainly be nice. John is in a better position to confirm
> or deny this.
>  
> > * This is unrelated to the GTK+ 3 migration, but I added a Markdown
> >   version of the README and added a DOAP project description.
>  
> So now there are 2 README's to keep in sync and an additional DOAP
> description. I would propose to keep only one README file. I have no
> strong preference over plain vs Markdown. What benefit is the
> Markdown edition ?

Markdown is a standardized markup format, meaning it looks nice in
GitHub and the likes of it. It is also quite human readable, so it
could replace the plain text README.

Note that the Markdown README needs to be updated to include
descriptions for the CMake build process.
>  
> And what benefit does the DOAP file bring us ?

There is no killer feature I can point at right now. DOAP files are
essentially standardized project descriptions and there are various
applications making use of this. I see no reason not to include it -
it's just a single file and does not require any more effort on the
GnuCash side.

>  
> Lastly as you say yourself, this is not Gtk+3 migration related, so
> would best be submitted as a separate PR.

It is on a separate branch, next. (gtk3 is based on next)

>  
> > * I changed the action naming pattern from CamelCaseAction to
> >   dot.separated.action-name, e.g. file.close or account.d
> > 
> Again what is the motivation for this ?

Consistency: The GAction infrastructure introduces dot-separated
prefixes. The most import of those are the app. and win. prefixes found
in the GMenu descriptions, which indicate whether an action is
application-wide or window-specific. (It seems much better to call an
action win.file.import.csv than win.FileImportImportCsvAction.) There
are some other ways to make use of custom prefixes which I didn't
include yet.

>  
> > Major stuff not yet migrated:
> > * In order to migrate the small business module, its entry ledger
> has
> >   to be rewritten, just like the "normal" register.
>  
> Yep.
>  
> > * AqBanking uses the gwenhywfar UI library, which in turn uses GTK+
> 2.
> > I have not yet looked into this.
>  
> Ok. Just stating the obvious: this may require patches to gwenhywfar
> upstream.
>  
> > * I removed the old file history/recent files code. There are
> better
> >   ways to do this in GTK+ 3.
>  
> Such as ?

I haven't looked into this in detail yet, but it seems that recent
files are supported by the file chooser dialog without any requirements
in the application code. Try File->Open, the sidebar includes an
element called "Recent".

>  
> > * I haven't converted every UI definition file to the new format
> for
> >   now.
>  
> Ok.
>  
> > 
> > Things that I recommend be dropped/removed for GnuCash 3.0:
> > * Maintaining both the CMake and autotools-based build system does
> not
> > seem like a good idea, so drop autotools.
>  
> As John said, we will likely drop autotools at some point. Cmake is a
> very recent addition so it needs some time to mature.
>  
> > * Rewriting the old register is not really viable or useful,
> >   so drop it. Currently, either the old or the new register is
> > compiled to ease transition. (Right now, the new register can be
> > enabled in addition to the old register.)
>  
> I looked into rewriting the old register at some point. It's
> certainly viable. I agree it not being very useful though.
>  
> Of course we intend to ship only one register. During development
> though it's convenient to be able to use both registers side by side.
>  
> The main advantage of such a set up is that you can quickly compare
> behavior for both in the same gnucash run. We had several brave users
> helping out in the beta testing which didn't have sufficient
> experience to rebuild gnucash. I would prefer to keep this situation
> until we're sure the new register is matching or superseding the old
> one stability and feature wise.

Unfortunately, the old register just won't compile right now, since
Gnome Canvas has been dropped completely. It certainly is possible to
port it to GooCanvas, but I think there are better ways to spend your
time.

Aside from porting it to GooCanvas, you would ideally also migrate it
to use style sheet based rendering (essentially everything that
modifies colors would need some work).

>  
> > * The dynamic module system (based on GModule) is a nice idea, but
> the
> >   benefits are dubious at the moment. While the dynamic loading of
> all
> >   the standard modules incurs a heavy startup delay, there is no
> >   reason why a user would not want to load all the built-in
> modules.
>  
> There is. You can run gnucash in headless mode to update price
> quotes. The headless mode is not using all the modules and wouldn't
> want to. I am not really in favor of this construct for several
> reasons. However that's the current situation. I think a nice way out
> of this is creating a separate binary specifically for the price
> quotes updates.

For simplicity, I temporarily dropped the fetch price quotes feature
because it wouldn't have been viable to include it in the new
GApplication code. Creating a separate binary, as you said it, should
be rather simple and get the job done. That was my thought when I
implemented the move to GApplication.

>  
> >   Therefore, all GnuCash modules should be converted into
> statically
> >   linked objects. (It is still possible to compile shared libraries
> >   for Guile at the same time, CMake should have no problem doing
> >   that.)
> > 
> John already suggested guile requires dynamic linking. And there's
> not only guile, we also more or less support python bindings.
>  
> I do agree that GModule is most likely overkill. Converting away from
> that needs to be done carefully. Most of our gmodules perform one-
> time initialization steps that will need to find another place.
>  
> And care must be taken this is called from all possible code paths
> (main gnucash application, guile bindings, python bindings, quotes
> updater,...)
>  
> And here also, this work is unrelated to gtk3 migration and can be
> done in a separate branch.

Yes.

>  
>  
> > Major Changes that I highly recommend for a GnuCash 3.0 release:
> > * Writing GObject-based code (i.e. GTK+ code) in C is a very
> > cumbersome and boilerplate-ish process. Vala makes it possible to
> > write GObject 
> >   code in a very concise way, all while compiling directly to C
> source
> >   (and C headers), making it possible to seamlessy integrate Vala
> code
> > into C code. Other C-to-Vala ports have seen significant decreases
> in
> >   code size. Porting the UI code to Vala should definitiely ease
> >   maintainability, correctness and readability without sacrificing
> >   performance.
>  
> I don't know vala (though I have heard of it). And I have heard both
> vala enthousiasts as well as vala haters (even Gnome Builder's
> Christian Hergert seems to be in the latter camp). Considering where
> the current coding efforts are headed, vala can have a place in the
> gui code at best. The core code will be in c++. And then my next
> question is (again) portability. Is vala readily available on OS X
> and Windows (more precisely in mingw) ? If not, it would be a non-
> starter unfortunately.

Yeah, gtkmm/C++ really seems like a better idea.

>  
> > * I ported the core application code to use GtkApplication. It
> would
> > be 
> >   nice to change the main window - opened file relationship from
> the
> >   current N:1 to a 1:1, i.e. each main window is separate and has
> >   exactly one opened file. This would simplify the main window
> code.
>  
> Nice at first sight and from a coding point of view. I'm not
> convinced yet it will also improve the user experience.
>  
> Unlike a text to a word processor, gnucash' data is not linear. For
> example transactions (or more precisely splits) are organized into
> accounts which are represented in account registers. There isn't one
> single register in which you can edit *all* splits. Well, there is of
> course (the general journal), but it's most difficult interface to
> use to manipulate and interpret your data so registers per account
> were implemented.
> Then there are reports of all kinds, interfaces for invoices/bills,
> budgets, scheduled transactions,...
> Each of them has it's own user interface.
> Having only one window would mean only one interface can be visible
> at a time. To quickly switch between interfaces tabs could be used.
> Oh, wait, this is the default behavior of gnucash. Then suppose I
> want to compare the contents of my bank account register to the
> report I ran on it. Or I want to compare my credit card register with
> my bank account register. These are real life situations. I can't do
> this with one window with tabs. And I know users who definitely
> prefer each tab to be in a separate window instead for this very
> reason.

I agree. I think this area might benefit from some further thought.

>  
> >   It also seems more intuitive than the current behaviour, since
> the
> >   user does not expect that all windows change the opened file if
> he
> >   opens a file in one window.
>  
> I understand your reasoning. On the other hand the current gnucash
> concept is that you can have only one file open at once. So all
> windows belong to that file. So gnucash users do know that all
> windows change the opened file. It's a different paradigm from
> typical applications. It's worse even, gnucash currently *can't* have
> multiple files open at once. The internal code just can't handle
> that. (To be complete there is a hacky work around by opening multipe
> instances of gnucash itself, but that's not relevant here).
>  
> I personally find this to be a design oversight from the early days.
> But again that's the legacy we have now.
>  
> Having said all that, if we can come up with an elegant UX within a
> single window interface allowing the interactions currently possible
> with the multi-window interface, I wouldn't mind going for single-
> window. I don't see that yet though...

On the other hand, why not combine both approaches and offer both
multi-window and multi-file workflows, i.e. 1 GtkApplication to 1 File
and 1 GtkApplication to Many Gtk(Application)Windows?

>  
> > * UI design: see below
> > * I have not yet looked at translations and accelerators.
>  
> Ok.
>  
> > * The new register requires some more love.
> > 
> Did you do anything to the new register other than converting it to
> gtk3 ?
>  
> Also here I would have preferred to see the new register stabilized
> and finished in the gtk2 edition *before* moving it to gtk3. Doing
> the two together gives us 2 moving targets and makes it more
> difficult to track where a future problem exactly started.

I wanted to prevent changing something from one deprecated interface to
another deprecrated interface and only discovering so in the following
migration work.

>  
> > Nice-to-haves regarding GTK:
> > * Some GSimpleActions would be better off as GPropertyActions.
>  
> Probably fine.
>  
> > * Validate all GtkBuilder files using gtk-builder-tool.
>  
> Would be nice indeed.
>  
> > * File Chooser Dialog: Implement proper file format filter.
>  
> What would that look like ? Old gnucash versions didn't set file
> extensions. And the default extension used to be .xac for a long time
> before it was renamed to .gnucash. So you can have a gnucash book
> called
> foo
> foo.xac
> foo.gnucash
>  
> The last two would be easy. However how can you filter files not
> having an extension yet only show the ones that are actually gnucash
> files ?

Well, while we are breaking stuff anyway, why not just tell users to
save their files as .gnucash or whatever? Have a big warning pop up at
startup saying they should make sure their files have the proper
extension? Anyway, they still have the option of viewing all files in
the file chooser dialog.

>  
> > * xdg-app support
>  
> Is that something that should happen from within the gnucash project
> ?

Afaik, it would be part of the build process and thus needs some
integration on the GnuCash side. This really is a nice-to-have "because
all the cool kids do it", so it's not urgent at all.

>  
> > * jqplot as a Git submodule
>  
> Ok.
>  
> > * Have hints for GtkEntries
>  
> Ok.
>  
> > 
> > Nice-to-haves, other that the UI:
> > * Replace the GncInt128 with Boost.Multiprecision
> > * I added initial configuration files for clang-format and clang-
> tidy.
> > The latter could be integrated as a Git commit hook.
>  
> Do you see this as optional or mandatory ? The latter would then
> require all developers to have clang on their system ? What about
> clang on Windows ?

Really, this doesn't have to be mandatory. I think you might be able to
run this on the server as a push hook or something similar, obivating
the need for any client to have Clang installed.

>  
> > 
> > Bugfixing paths:
> > * I have added basic support for compiling GnuCash with the address
> >   sanitizer (ASan) and the undefined behaviour sanitizer (UBSan),
> >   although in practice, the former only works using LD_PRELOAD at
> >   runtime (which is discouraged) due to a Guile error.
> > * Many of the warnings you see compiling my tree really are valid
> >   errors and should be fixed.
> > 
> Ok.
>  
> > UI Design Notes:
> > 
> > The current UI has the menubar as the central element. Depending on
>  
> >   which "plugin page" you're currently looking at, certain menus
> are
> > shown or hidden, e.g. the "Transaction" menu is only visible when
> > viewing a register page. In theory, this behaviour is also
> available
> > in my development tree thanks to the EggMenuManager (taken from
> Gnome
> > Builder), but I removed the relevant calls for the moment. Please
> > read on for the reasons. (Search for calls to
> > egg_menu_manager_remove)
> > 
> > Both the heavy usage of menus and the context-sensitive visibility
> of
> > menus are discouraged by the Gnome 3 HIG. A more modern UI design
> > would greatly benefit the GnuCash user experience. (Before
> > continuing, please have a quick look at the Gnome 3 HIG right now
> if
> > you haven't yet.)
> > 
> > I haven't spent a great deal of time thinking about a potential new
> UI
> > design yet, but in general, it boils down to having the page-
> specific
> > actions as buttons inside a toolbar, and general actions in a
> header
> > bar (GtkHeaderBar). As an example, let's take the register:
> >  * New Account: A plus button on the toolbar
> >  * Register Style: Clicking on "sandwich"-like button opens a
> popover
> >    offering the different styles as a slider (as in Nautilus: the
> >    button left of the sandwich button offers the different Nautilus
> >    style options)
> >  * View - Search by: As "search" button in the header bar
> > 
> I'm not ready yet for such changes. My general impression is this
> works well for simple applications but quickly falls short for more
> complicated ones. GnuCash doesn't aim to be "so simple your
> grandmother can use it", or tabletized (at least not the desktop
> version). 
>  
> > In general, you can get a lot of design inspiration by looking at
> > Gnome Apps, in particular some of the recently refreshed ones, e.g.
> > Files/Nautilus, Videos/Totem, Maps, Documents or Document
> > Viewer/evince.
>  
> Unfortunately I don't like this trend on desktops. Again my feeling
> is that in most cases the applications are dumbed down to an absolute
> minimum in order to fit the "keep it simple" mantra.
>  
> I am not sure gnucash belongs in that category.

I wouldn't say that KISS is a bad motto: things that are simple should
be done in a simple (as in not-complicated) way, and complex
functionality should be complex, but not complicated. This doesn't
necessarily mean that GnuCash should be dumbed down: It just means that
simple features should be exposed over simple UI interfaces (e.g. a
button with a plus symbol for "New Account"), and more advanced
features don't have to be hidden or removed for that.

All in all, UX is not a theoretical topic, and before we devolve in
long discussions on which mantra is the best, I suggest I do some of
the changes I have in mind and we talk about what the actual prototype
looks like.

>  
> For completeness I will add that I do agree our user experience needs
> an important overhaul. But it's too early for that.
>  
> > 
> > Asking the Gnome Design Team for suggestions is also a possible
> > avenue.
>  
> Absolutely. As would be KDE's VDG if we were to choose Qt as future
> toolkit.
> > 
> > Thanks for your time and attention - let's make GnuCash an even
> better
> > free software finance manager!
> > 
> Thank you for taking on this migration work !
>  
> Regards,
>  
> Geert

Again, thanks for your invaluable feedback!

Best regards,
Tobias
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

Geert Janssens-4
In reply to this post by Tobias Markus
On Saturday 27 February 2016 14:32:41 Tobias Markus wrote:

> On Mo, 2016-02-22 at 21:18 -0800, John Ralls wrote:
> > > On Feb 22, 2016, at 1:57 PM, Geert Janssens
> > > <geert.gnucash@kobaltwi
> > >
> > > t.be> wrote:
> > > > Major changes already in my tree:
> > > > * All "rich" GtkActions/GtkRadioActions/GtkToggleActions were
> > > > replaced
> > > > by abstract GActions/GMenus. This doesn't sound like a lot, but
> > > > is a
> > > > major change. Please read the relevant API documentation and do
> > > > not
> > > > hestitate to ask me if you have any questions about the new
> > > > GAction-
> > > > based infrastructure. Sorry for not going into more detail, but
> > > > describing the technical peculiarities here would take
> > > > considerably
> > > > too long.
> > > > * I removed the splash screen and replaced it by GApplication's
> > > > busy
> > > >  notification in some places.
> > >
> > > What's the motivation to remove the splash screen ? GnuCash is a
> > > slow loading application.
> > > Several users prefer to have a splash screen indicating progress
> > > (like LibreOffice does for
> > > example).
> > > And yes, I understand that we could optimize loading speed to
> > > avoid
> > > the need for a splash
> > > screen altogether. But we're not there yet by a long shot.
> > >
> > > > * I updated the HTML code to use the Webkit2 API, but it needs
> > > > some
> > > >  more love.
> > >
> > > That's a nice improvement. We were lagging on the Webkit upgrades.
> > > There is an important
> > > reason for that though: it's almost impossible to build webkit on
> > > Windows. Do you intend to
> > > tackle that part as well ? We'll need a usable Webkit2 library on
> > > Windows before we can land
> > > your webkit2 api.
> > >
> > > As an aside: I would prefer to see the migration to the Webkit2
> > > API
> > > as a separate project from
> > > the gtk3 migration to reduce the amount of moving parts per
> > > branch.
> > > If gtk3 migration depends
> > > on webkit2 API, it should be done first. If not, it can also be
> > > done after the gtk3 migration has
> > > stabilized.
> > >
> > > > * Using GtkApplication renders everything related to
> > > >  gtk-osx-integration unnecessary.
> > >
> > > That would certainly be nice. John is in a better position to
> > > confirm or deny this.
> > >
> > > > * This is unrelated to the GTK+ 3 migration, but I added a
> > > > Markdown
> > > >  version of the README and added a DOAP project description.
> > >
> > > So now there are 2 README's to keep in sync and an additional DOAP
> > > description. I would
> > > propose to keep only one README file. I have no strong preference
> > > over plain vs Markdown.
> > > What benefit is the Markdown edition ?
> > >
> > > And what benefit does the DOAP file bring us ?
> > >
> > > Lastly as you say yourself, this is not Gtk+3 migration related,
> > > so
> > > would best be submitted as a
> > > separate PR.
> >
> > Several different branches: WebKit2, GApplication, and Gtk3
> > migration. At least. There's probably more buried in there.
>
> I have to disagree here:
>
> WebKit2 sounds like a huge step, but it really isn't. As one of the
> last things before releasing the patchset, I tried to convert
> gnc-html- webkit to WebKit2, and it was done rather quickly (and it
> works as in "it shows a report, but I didn't go any further", but
> that doesn't mean this really breaks stuff).

Great! So that would make a very valuable first patch set on its own. I realize there will be
some refactoring required as you did the webkit2 part *after* the gtk3 part. But as it's a small
change by your own judgment it shouldn't be too hard to split it out and submit by itself ?

That will allow for the next step to be worked on: getting webkit2 to build on Windows under
mingw (and maybe also on Mac OS X).

Someone will have to spend time on these as well. It would be great if that someone would be
you, though that's not mandatory. If not you, we'll have to wait for somebody else to find time
and figure it out.

> The report system
> integration is not working correctly right now, so I couldn't really
> test it, but I don't really expect there are major deal-breakers
> along the way.
>
I don't understand this remark. What do you mean with "report system integration is not
working right now" ?


<snip>
(I won't comment on the GApplication part as I don't know enough about it)

> > A markdown README looks nicer on Github. Markdown is quite legible
> > in
> > plain text, there's no reason to have two.
>
> That is my reasoning, too.
>
> > doap files are used by git.gnome.org for organizing the display of
> > projects. GnuCash has no need of a doap file.
>
> Ah, so because someone at Gnome uses DOAP files, they are poisoned and
> GnuCash should never include a DOAP file?
> The Python Package Index Index (PyPi) with over 75k packages uses DOAP
> files for their project descriptions.
>
No need to get into arms here...

I didn't know about DOAP files and other than the comments above I still don't really.

On the other hand, gnucash does carry more files that are only used in specific circumstances
(think of the xcode project file for example. If it's useful for external projects that can be a fair
reason to include it. Does it have to be stored in the top-level directory ?
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

John Ralls-2
In reply to this post by Tobias Markus

> On Feb 27, 2016, at 8:15 AM, Tobias Markus <[hidden email]> wrote:
>
> On Mo, 2016-02-22 at 22:57 +0100, Geert Janssens wrote:
>>  
>>> * I ported the core application code to use GtkApplication. It would be
>>>   nice to change the main window - opened file relationship from the
>>>   current N:1 to a 1:1, i.e. each main window is separate and has
>>>   exactly one opened file. This would simplify the main window code.
>>  
>> Nice at first sight and from a coding point of view. I'm not
>> convinced yet it will also improve the user experience.
>>  
>> Unlike a text to a word processor, gnucash' data is not linear. For
>> example transactions (or more precisely splits) are organized into
>> accounts which are represented in account registers. There isn't one
>> single register in which you can edit *all* splits. Well, there is of
>> course (the general journal), but it's most difficult interface to
>> use to manipulate and interpret your data so registers per account
>> were implemented.
>> Then there are reports of all kinds, interfaces for invoices/bills,
>> budgets, scheduled transactions,...
>> Each of them has it's own user interface.
>> Having only one window would mean only one interface can be visible
>> at a time. To quickly switch between interfaces tabs could be used.
>> Oh, wait, this is the default behavior of gnucash. Then suppose I
>> want to compare the contents of my bank account register to the
>> report I ran on it. Or I want to compare my credit card register with
>> my bank account register. These are real life situations. I can't do
>> this with one window with tabs. And I know users who definitely
>> prefer each tab to be in a separate window instead for this very
>> reason.
>
> I agree. I think this area might benefit from some further thought.
>
>>  
>>>   It also seems more intuitive than the current behaviour, since
>> the
>>>   user does not expect that all windows change the opened file if
>> he
>>>   opens a file in one window.
>>  
>> I understand your reasoning. On the other hand the current gnucash
>> concept is that you can have only one file open at once. So all
>> windows belong to that file. So gnucash users do know that all
>> windows change the opened file. It's a different paradigm from
>> typical applications. It's worse even, gnucash currently *can't* have
>> multiple files open at once. The internal code just can't handle
>> that. (To be complete there is a hacky work around by opening multipe
>> instances of gnucash itself, but that's not relevant here).
>>  
>> I personally find this to be a design oversight from the early days.
>> But again that's the legacy we have now.
>>  
>> Having said all that, if we can come up with an elegant UX within a
>> single window interface allowing the interactions currently possible
>> with the multi-window interface, I wouldn't mind going for single-
>> window. I don't see that yet though...
>
> On the other hand, why not combine both approaches and offer both
> multi-window and multi-file workflows, i.e. 1 GtkApplication to 1 File
> and 1 GtkApplication to Many Gtk(Application)Windows?

That's a deeper problem than can be solved in the UI. The current state of libqof, engine, and backends is that GnuCash can handle only one file/database at a time. We call that a "session" and it's encapsulated in QofSession.

The current functionality, that one can use either one or multiple windows and that any tab can be separated to become its own window if the user wants, must be preserved.

If at some point we're able to have multiple sessions in a single GnuCash instance the UI will have to make very clear indeed which window goes with which session, but not worth worrying about until the core implementation is changed.

Regards,
John Ralls
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

Geert Janssens-4
In reply to this post by Tobias Markus
On Saturday 27 February 2016 17:15:56 Tobias Markus wrote:

> On Mo, 2016-02-22 at 22:57 +0100, Geert Janssens wrote:
> > A few general suggestions:
> > 1. Better commit messages. Each commit message should summarize what
> > the commit does.
> > 2. Make changes as atomic as possible. One commit should focus on
> > one
> > change. Depending on the change, a commit can be large or small. As
> > long as it remains clear what that commit is doing.
> > 3. Split out cosmetic changes (like whitespace and indentation
> > fixes)
> > from functional changes.
>
> That's what I have in mind

Good!

> - it's just a lot of work for the ~150
> commits I already have, not to mention those to come :D
>
That's ok. Take your time. The next major release is at least 1 year from now.

> >  
> > I'll add more comments below between your message.
> >  
> >
> > On Sunday 21 February 2016 20:12:58 Tobias Markus wrote:
> > > Hi GnuCash developers,
> > >
> > >
> > >
> > > over the last few feeks, I have developed a fundamental patchset
> >
> > that
> >
> > > should get GnuCash up and running in GTK+ 3.
> > >
> > >
> > >
> > > The source code is available at GitHub:
> > > https://github.com/hesiod/gnucash/tree/gtk3
> > >
> > >
> > >
> > > Some independent commits are on the next branch.

I didn't realize "next" was actually the name of a branch. I read it to mean "some other branch
with follow-up commits to be merged afterwards".

I looked at the next branch. Most of the commits on that branch are fine to me, except for:

1. One commit adds egg-menu-manager files, but is not using them in any way (yet). Move this
into the gtk+3 branch to the point you actually need them.
2. I haven't check whether your clang-format-style definition matches the formatting we have
been doing so far with astyle from time to time. The last time I ran it was with these settings:
astyle --indent=spaces=4 --brackets=break --suffix=none
If that's what your clang formatter does I'm fine with it.

Do keep in mind for all subsequent commits we prefer to keep formatting changes in separate
commits from actual code changes. That helps tremendously in bisecting later on.

So if you make these few changes, that part can be merged already as far as I'm concerned.

<snip>

> > We will have to check what's available in the distributions we
> > intend
> > to support. The two most conservative ones typically are Debian and
> > RHEL.
> > Current stable Debian (8.0/Jesse) is at gtk+ 3.14.5. I don't think
> > Debian will have another major release at least one year before the
> > next major gnucash release.
> > RHEL (7.2) is at gtk+ 3.14.13.
> >  
> > So I expect we will need to support 3.14.
>
> That should be doable.
>
> I'm really not a distributions expert, but wouldn't Debian for example
> wait anyway before picking up a version 3.0.0? I thought they would
> probably stay with the latest stable series anyway.
>
True. However there are also the backports. If we stick to a version of gtk+3 that's available on
debian stable, this will make it a lot easier for package maintainers to provide a backport of a
more recent version of gnucash. And so debian stable users can have a choice of the stable
version of a more recent one. That's an opportunity we shouldn't miss out on.

<snip>

> >  
> > What's the motivation to remove the splash screen ? GnuCash is a
> > slow
> > loading application. Several users prefer to have a splash screen
> > indicating progress (like LibreOffice does for example).
> > And yes, I understand that we could optimize loading speed to avoid
> > the need for a splash screen altogether. But we're not there yet by
> > a
> > long shot.
>
> This is more of a temporary measure. I reasoned that if the loading
> speed was improved significantly in time for the release, then the
> splash screen wouldn't be needed anymore. And if startup speed was
> still rather slow, reintegrating the splash screen into the
> GApplication-based code would need some thought anyway to make sure it
> integrates well.
>
Ok. That's a fair assumption. I'll do my mantra thing again here: the loading speed has to be
acceptable on all platforms we currently support. I can tell you that the Windows port
sometimes still loads magnitudes slower than the linux version. So even if we don't need a
splash screen any more on linux, we still may require it on Windows. Time will tell.

> GApplication provides a way to indicate to the user that the
> application is currently busy via g_application_mark_busy. I included
> that in the startup process, so even if the splash screen wasn't
> needed anymore, the user would receive some feedback.
>
What does that indicator do exactly ? And does it work on Windows and OS X as well ?

> >  
> >
> > > * I updated the HTML code to use the Webkit2 API, but it needs
> > > some
> > >   more love.
> >
> >  
> > That's a nice improvement. We were lagging on the Webkit upgrades.
> > There is an important reason for that though: it's almost impossible
> > to build webkit on Windows. Do you intend to tackle that part as
> > well
> > ? We'll need a usable Webkit2 library on Windows before we can land
> > your webkit2 api.
>
> Sorry, but I'm no expert in doing Unix-ish stuff on Windows :D
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
12