Re: [GNC-dev] GTK3 Mnemonics

[John Ralls]

> On Oct 20, 2018, at 5:01 AM, Frank H. Ellenberger 
>  wrote:
> 
> Hi Chris,
> 
> Am 20.10.18 um 08:30 schrieb Chris Good:
>> Hi Frank,
>> 
>> In your edit of the gtk3 wiki [1], you added in part:
>> 
>> === Circumvent Bad GTK3 Design decisions ===
>>   Get Visible Mnenomics Back 
>> Since GTK3.10 the underlines of the mnenomics are only visible after you
>> hovered the mouse over the element ''and'' pressed alt. 
>> 
>> In $SCOPE/gtk-3.0/settings.ini, add a line:
>> 
>> 
>> [Settings]
>> # Visible Mnenomics
>> gtk-menu-images = true
>> 
>> 
>> which I was glad to see as I had noticed mnemonics seemed to have
>> disappeared from GC 3.
> 
> while my current working area is testing translations and eventually get
> the GUI closer to what I had thought is the HIG, I stumbled in this
> changes in GTK. So I started, to write down, what I collected from the
> internet. Some notes might be incomplete or outdated. So feel free to
> improve them.
> 
>> I tested setting ' gtk-menu-images = true' in settings.ini (Windows 10,
>> GC3.1) and it doesn't seem to do anything for me.
>> 
>> https://developer.gnome.org/gtk3/stable/GtkSettings.htm indicates
>>  gtk-menu-images
>>  gtk-auto-mnemonics
>>  gtk-enable-mnemonics
>> have been deprecated since version 3.10.
>> 
>> In Windows the behaviour I see is that the first time the right click
>> transaction menu appears, mnemonics are NOT shown, but if you either:
>>  Go into a dialog, say Duplicate Transaction, a couple of times (with or
>> without using the Alt key (mnemonic activator))
>>  Or Go into a dialog, say Duplicate Transaction, and use the Alt key
>>  Or Use the Alt key in the right click transaction menu
>> mnemonics are shown from then on in the right click transaction menu.
>> 
>> Note for me, it is not needed to hover the mouse pointer over the element,
>> just hold the Alt key for approx. half to 1 second.
>> 
>> It seems to me that GTK3 wishes to remove any options for using mnemonics
>> and just turn it on using the mnemonic activator key.
>> Can anyone verify that or provide links that indicate how it should work?
> 
> As you noted, the GTK manual is not very helpful. In other, secondary
> sources I read the devs think, it is cluttering the appearance. If they
> think, a cool look is more important than usability ...
> 
> But probably John knows more about this decisions and alternative
> approaches.
> 
>> [1]
>> https://code.gnucash.org/wiki/index.php?title=GTK3=14720=14717 
>> <https://code.gnucash.org/wiki/index.php?title=GTK3=14720=14717>
>> 
>> Regards, Chris Good

No, not really. I try to follow what’s going on but the places I’m lurking 
haven’t yielded much information for the last couple of years.

Regards,
John Ralls

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

Re: [GNC-dev] GTK3 Mnemonics

[Frank H. Ellenberger]

Hi Chris,

Am 20.10.18 um 08:30 schrieb Chris Good:
> Hi Frank,
> 
> In your edit of the gtk3 wiki [1], you added in part:
> 
> === Circumvent Bad GTK3 Design decisions ===
>   Get Visible Mnenomics Back 
> Since GTK3.10 the underlines of the mnenomics are only visible after you
> hovered the mouse over the element ''and'' pressed alt. 
> 
> In $SCOPE/gtk-3.0/settings.ini, add a line:
> 
> 
> [Settings]
> # Visible Mnenomics
> gtk-menu-images = true
> 
> 
> which I was glad to see as I had noticed mnemonics seemed to have
> disappeared from GC 3.

while my current working area is testing translations and eventually get
the GUI closer to what I had thought is the HIG, I stumbled in this
changes in GTK. So I started, to write down, what I collected from the
internet. Some notes might be incomplete or outdated. So feel free to
improve them.

> I tested setting ' gtk-menu-images = true' in settings.ini (Windows 10,
> GC3.1) and it doesn't seem to do anything for me.
> 
> https://developer.gnome.org/gtk3/stable/GtkSettings.htm indicates
>   gtk-menu-images
>   gtk-auto-mnemonics
>   gtk-enable-mnemonics
> have been deprecated since version 3.10.
> 
> In Windows the behaviour I see is that the first time the right click
> transaction menu appears, mnemonics are NOT shown, but if you either:
>   Go into a dialog, say Duplicate Transaction, a couple of times (with or
> without using the Alt key (mnemonic activator))
>   Or Go into a dialog, say Duplicate Transaction, and use the Alt key
>   Or Use the Alt key in the right click transaction menu
> mnemonics are shown from then on in the right click transaction menu.
> 
> Note for me, it is not needed to hover the mouse pointer over the element,
> just hold the Alt key for approx. half to 1 second.
> 
> It seems to me that GTK3 wishes to remove any options for using mnemonics
> and just turn it on using the mnemonic activator key.
> Can anyone verify that or provide links that indicate how it should work?

As you noted, the GTK manual is not very helpful. In other, secondary
sources I read the devs think, it is cluttering the appearance. If they
think, a cool look is more important than usability ...

But probably John knows more about this decisions and alternative
approaches.

> [1]
> https://code.gnucash.org/wiki/index.php?title=GTK3=14720=14717
> 
> Regards, Chris Good

Regards
Frank

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

[GNC-dev] GTK3 Mnemonics

[Chris Good]

Hi Frank,

In your edit of the gtk3 wiki [1], you added in part:

=== Circumvent Bad GTK3 Design decisions ===
  Get Visible Mnenomics Back 
Since GTK3.10 the underlines of the mnenomics are only visible after you
hovered the mouse over the element ''and'' pressed alt. 

In $SCOPE/gtk-3.0/settings.ini, add a line:


[Settings]
# Visible Mnenomics
gtk-menu-images = true


which I was glad to see as I had noticed mnemonics seemed to have
disappeared from GC 3.

I tested setting ' gtk-menu-images = true' in settings.ini (Windows 10,
GC3.1) and it doesn't seem to do anything for me.

https://developer.gnome.org/gtk3/stable/GtkSettings.htm indicates
  gtk-menu-images
  gtk-auto-mnemonics
  gtk-enable-mnemonics
have been deprecated since version 3.10.

In Windows the behaviour I see is that the first time the right click
transaction menu appears, mnemonics are NOT shown, but if you either:
  Go into a dialog, say Duplicate Transaction, a couple of times (with or
without using the Alt key (mnemonic activator))
  Or Go into a dialog, say Duplicate Transaction, and use the Alt key
  Or Use the Alt key in the right click transaction menu
mnemonics are shown from then on in the right click transaction menu.

Note for me, it is not needed to hover the mouse pointer over the element,
just hold the Alt key for approx. half to 1 second.

It seems to me that GTK3 wishes to remove any options for using mnemonics
and just turn it on using the mnemonic activator key.
Can anyone verify that or provide links that indicate how it should work?

[1]
https://code.gnucash.org/wiki/index.php?title=GTK3=14720=14717

Regards, Chris Good


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

Re: [GNC-dev] Ubuntu 16.04 compile: libgwengui-gtk3-0

[Descending Nerdliness]

Thanks David.

Thanks John.



On 07/07/2018 03:25 PM, John Ralls wrote:
>
>> On Jul 7, 2018, at 2:17 PM, Descending Nerdliness 
>>  wrote:
>>
>> Greetings:
>>
>> Compiling GC 3.2 seems to require libgwengui-gtk3-0, but that is not in
>> the ubuntu 16.04 repository.  When I tried to add a later version from
>> debian, I ended up having to upgrade all things related to aqbanking,
>> which eventually killed other things.
>>
>> I have eliminated aqbanking to get past it, but I really need that
>> function. Is there a solution to this?
>>
> GnuCash has its own copy of gwen-gtk3.0 for just this reason. CMake should 
> detect that you need it and build it, so if it doesn't, examine the CMake 
> output to see why not.
>
> Regards,
> John Ralls

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

Re: [GNC-dev] Ubuntu 16.04 compile: libgwengui-gtk3-0

[John Ralls]

> On Jul 7, 2018, at 2:17 PM, Descending Nerdliness 
>  wrote:
> 
> Greetings:
> 
> Compiling GC 3.2 seems to require libgwengui-gtk3-0, but that is not in
> the ubuntu 16.04 repository.  When I tried to add a later version from
> debian, I ended up having to upgrade all things related to aqbanking,
> which eventually killed other things.
> 
> I have eliminated aqbanking to get past it, but I really need that
> function. Is there a solution to this?
> 

GnuCash has its own copy of gwen-gtk3.0 for just this reason. CMake should 
detect that you need it and build it, so if it doesn't, examine the CMake 
output to see why not.

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

Re: [GNC-dev] Ubuntu 16.04 compile: libgwengui-gtk3-0

[David Carlson]

I think that you found out why it is unlikely that Gnucash 3.x will
probably never be back ported to Ubuntu 16.04.

You can find Gnucash 2.6.17, Or close to it at Getdeb.  It might be a
little tricky getting alpha vantage to work, though.  I do not quite have
part working yet.

David C


On Sat, Jul 7, 2018, 4:18 PM Descending Nerdliness <
hisdescendingnerdlin...@rattleit.com> wrote:

> Greetings:
>
> Compiling GC 3.2 seems to require libgwengui-gtk3-0, but that is not in
> the ubuntu 16.04 repository.  When I tried to add a later version from
> debian, I ended up having to upgrade all things related to aqbanking,
> which eventually killed other things.
>
> I have eliminated aqbanking to get past it, but I really need that
> function. Is there a solution to this?
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Ubuntu 16.04 compile: libgwengui-gtk3-0

[Descending Nerdliness]

Greetings:

Compiling GC 3.2 seems to require libgwengui-gtk3-0, but that is not in
the ubuntu 16.04 repository.  When I tried to add a later version from
debian, I ended up having to upgrade all things related to aqbanking,
which eventually killed other things.

I have eliminated aqbanking to get past it, but I really need that
function. Is there a solution to this?

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

[GNC-dev] Ubuntu 16.04 compile: libgwengui-gtk3-0

[Descending Nerdliness]

Greetings:

Compiling GC 3.2 seems to require libgwengui-gtk3-0, but that is not in
the ubuntu 16.04 repository.  When I tried to add a later version from
debian, I ended up having to upgrade all things related to aqbanking,
which eventually killed other things.

I have eliminated aqbanking to get past it, but I really need that
function. Is there a solution to this?

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

Re: [GNC-dev] Captcha; was: GTK3 CSS Active Row

[Alen Siljak]

Frank, thanks a lot. Yes, the new captcha works great!

> Sent: Thursday, April 12, 2018 at 4:47 PM
> From: "Frank H. Ellenberger" <frank.h.ellenber...@gmail.com>
> To: cicko <alen.sil...@gmx.com>
> Cc: gnucash-devel@gnucash.org, "Derek Atkins" <warl...@mit.edu>
> Subject: [GNC-dev] Captcha; was:  GTK3 CSS Active Row
>
> The Captcha should now be fiexed. can you test it?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Captcha; was: GTK3 CSS Active Row

[Frank H. Ellenberger]

Am 12.04.2018 um 12:19 schrieb cicko:
> As it often happens, the solution was quick to find only after the question
> was posted.
> This works well:
> 
> *.register-cursor {
> color: blanchedalmond;
> }
> 
> Here is a gist that adjusts this for a dark theme (still can't add new urls
> to the wiki):
> https://gist.github.com/MisterY/15ea50fee571865ca9efd8c5437a1713

The Captcha should now be fiexed. can you test it?

~Frank

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

Re: [GNC-dev] GTK3 CSS Active Row

[cicko]

As it often happens, the solution was quick to find only after the question
was posted.
This works well:

*.register-cursor {
color: blanchedalmond;
}

Here is a gist that adjusts this for a dark theme (still can't add new urls
to the wiki):
https://gist.github.com/MisterY/15ea50fee571865ca9efd8c5437a1713



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] GTK3 CSS Active Row

[cicko]

A quick question in relation to GTK3 customization
(https://wiki.gnucash.org/wiki/GTK3). 

I've applied an existing dark theme and that covers general GTK elements.
One issue I have now is that the selected/active register row keeps the dark
text but gets the dark background from the theme.

Does anyone know which selector would apply to the active row in the
register (only!)?

Selectors like "*.register-foreground" work but they affect all the text in
the register (all the rows and headers).

cursor entry {
color: orange;
}
also works but affects only the cell where the cursor is. I've tried just
"entry" but that did not do anything.

Thanks!



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

GTK3 page and Wiki general; was: Feedback about 2.7.8

[Frank H. Ellenberger]

Hi,

Am 31.03.2018 um 13:51 schrieb Geert Janssens:
> I'm fine with moving the FAQ material here, but I would prefer to keep a link 
> from the faq to this page so users can be redirected.

IMHO we should move most content from the FAQ to structured pages of the
respective themes (and after some breeding into the official doc
package). So the FAQ would become primary a link collection.

> I would also propose a less technical name for the wiki page. Most users 
> don't 
> know what gtk is so the wouldn't guess that page would hold information on 
> tweaking the gnucash gui style/theme.

IMHO a page name should be (for easy linking) short, but precise.
Because there was already a GTK page, now moved to GTK2, the name is fine.

> So the page title should rather refer to such keywords: style, theme, tweak, 
> customize,... I'm not very creative in finding good titles right now, so feel 
> free to suggest some for public deliberation.

There are other technics e.g. for keywords use categories, the FAQ and
the search function.

At some places we might consider to insert overview pages, e.g. create
them from the sections of the (now IMHO too long) main page.

> Geert

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

Gtk3 Theming Tool for Windows

[John Ralls]

GnuCash has had since time immemorial a Select GnuCash Theme tool in the 
Windows Start menu. In reality it's just a wrapper around gtk2_prefs [1] and 
that hasn't been updated in almost 5 years--and never for Gtk3.

So I've removed the Select GnuCash Theme tool from the Windows build of 2.7.3, 
but I'd like to put it back if I can find a replacement.

Does anyone know of something that would work?

Regards,
John Ralls



[1] https://sourceforge.net/p/gtk-win/code/HEAD/tree/gtk2_prefs/
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3 Registry fields

[Geert Janssens]

On dinsdag 5 september 2017 18:49:22 CEST Robert Fewell wrote:
> I would like to confirm the behaviour of the new registry so that I can fix
> which ever way is correct, hopefully I can explain what I am seeing...
> 
> If you mouse click on a field, say description, the text highlights and you
> are able to amend but you have no cursor. If you mouse click again, the
> entry becomes focused and you have a cursor, can add text but not delete
> any as the delete key, backspace and escape keys do not work.
> 
> So do we want the entries to work when focused, I assume yes but thought I
> would ask ?
> 
That's a regression indeed. Thanks for looking into fixing this.

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

Re: Gtk3 Registry fields

[Sumit Bhardwaj]

Yes, please. This is different from GTK2 and disconcerting.


Thanks, Bob, for all the work so far for GTK3. So far, it's been a charm.

On Tue, Sep 5, 2017 at 9:49 AM, Robert Fewell <14ubo...@gmail.com> wrote:

> I would like to confirm the behaviour of the new registry so that I can fix
> which ever way is correct, hopefully I can explain what I am seeing...
>
> If you mouse click on a field, say description, the text highlights and you
> are able to amend but you have no cursor. If you mouse click again, the
> entry becomes focused and you have a cursor, can add text but not delete
> any as the delete key, backspace and escape keys do not work.
>
> So do we want the entries to work when focused, I assume yes but thought I
> would ask ?
>
> Bob
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Gtk3 Registry fields

[Robert Fewell]

I would like to confirm the behaviour of the new registry so that I can fix
which ever way is correct, hopefully I can explain what I am seeing...

If you mouse click on a field, say description, the text highlights and you
are able to amend but you have no cursor. If you mouse click again, the
entry becomes focused and you have a cursor, can add text but not delete
any as the delete key, backspace and escape keys do not work.

So do we want the entries to work when focused, I assume yes but thought I
would ask ?

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

Re: Gtk3 master

[Geert Janssens]

On donderdag 31 augustus 2017 19:17:02 CEST John Ralls wrote:
> > On Aug 31, 2017, at 9:11 AM, Geert Janssens 
> > wrote:> 
> > On donderdag 31 augustus 2017 16:17:20 CEST Aaron Laws wrote:
> >> On Thu, Aug 31, 2017 at 9:51 AM, Geert Janssens
> >> >> 
> >> wrote:
> >>> I meant to add still, if we want to keep guile 1.8 support, the
> >>> FIND_PACKAGE(GUILE_EXECUTABLE...) rules should move up inside the
> >>> branches of
> >>> the GUILE2 vs GUILE1 test.
> >>> For GUILE2 it can remain
> >>> FIND_PROGRAM (GUILE_EXECUTABLE guile2.0 guile)
> >>> IF (NOT GUILE_EXECUTABLE)
> >>> 
> >>>  MESSAGE (SEND_ERROR "The guile executable was not found, but is
> >>>  required.
> >>> 
> >>> Please set GUILE_EXECUTABLE.")
> >>> ENDIF (NOT GUILE_EXECUTABLE)
> >>> 
> >>> For guile 1.8 it should become
> >>> FIND_PROGRAM (GUILE_EXECUTABLE guile1.8 guile)
> >>> IF (NOT GUILE_EXECUTABLE)
> >>> 
> >>>  MESSAGE (SEND_ERROR "The guile executable was not found, but is
> >>>  required.
> >>> 
> >>> Please set GUILE_EXECUTABLE.")
> >>> ENDIF (NOT GUILE_EXECUTABLE)
> >>> 
> >>> Regards,
> >>> 
> >>> Geert
> >> 
> >> I don't have guile 1. guile --version; returns "2.2.2" and guile2.0
> >> --version; returns "2.0.14".
> > 
> > Yes, distributions shift this all the time...
> > 
> > I'm still on Fedora 25 which has guile (being 2.0.13) and guile1.8 (being
> > 1.8.8)
> > 
> > While checking these version numbers I saw the copyright notice on guile
> > 1.8 was last updated in 2008(!) and guile 2.0 in 2016. I think it's fair
> > to state guile 1.8 is getting rather outdated and I'll keep my vote to
> > stop supporting it ASAP :)
> 
> I'm very much in favor of dropping Guile-1.8 support.
> 
Good, I'll take it up when I have time available again for gnucash.

> If Guile-2.2 can be made to work without too much effort adding support for
> it would be a Good Thing.
> 
I added some rules to CMakeLists.txt locally to see how it would go. The build 
fails because we still use a few functions that were already deprecated in 
guile 2.0 and now removed completely from guile 2.2.

The ones that came up before the build refused to continue (even with -k100):
- scm_internal_stack_catch: no direct c replacement, but can be done in guile 
code, I have been looking into this in the past, but never finished the job
- scm_listify: to be replaced with scm_list_n. The bad news is this function 
is also used in the swig autogenerated code. So getting this fixed means 
patching swig. So we're back at where we were with gnucash 2.6. No active 
swig-guile maintainer, and the swig-guile code slowly bitrotting and breaking 
with new guile releases. Sigh... If not too much work I may write yet another 
PR for swig.

> BTW, while MingGW64 ships Guile it included Cygwin dependencies--it's a
> MSYS2 package, not a MinGW one--so we can't use it.

Oh, I had missed that :-\

> I've set up the
> moduleset to build Guile-2.0.14, and if Guile-2.2 works I'd change both Win
> and Mac to use that. Unfortunately it doesn't appear that Debian has looked
> at Guile-2.2 even for unstable, but that might be because we're the only
> major package that uses guile. (The other packages are freehold,
> libnlopt-guile0, moron, mailtutils-guile, guile-library, guile-son, and
> gwrap).
> 
> Looks like Fedora has guile-2.2 beginning with F25, but I don't know of a
> good way to find out what packages depend on it or on guile-2.0.
> 
On Fedora you'd use
dnf repoquery --whatrequires ...

There we have aisleriot, autogen, denemo, freehoo, freetalk, gdb-headless, 
geda-utils, gnotime, gnubik, gnutls-guile, graphviz-guile, make, mdk, weechat, 
xbindkeys

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

Re: Gtk3 master

[John Ralls]

> On Aug 31, 2017, at 9:11 AM, Geert Janssens  
> wrote:
> 
> On donderdag 31 augustus 2017 16:17:20 CEST Aaron Laws wrote:
>> On Thu, Aug 31, 2017 at 9:51 AM, Geert Janssens 
>> wrote:
>>> I meant to add still, if we want to keep guile 1.8 support, the
>>> FIND_PACKAGE(GUILE_EXECUTABLE...) rules should move up inside the
>>> branches of
>>> the GUILE2 vs GUILE1 test.
>>> For GUILE2 it can remain
>>> FIND_PROGRAM (GUILE_EXECUTABLE guile2.0 guile)
>>> IF (NOT GUILE_EXECUTABLE)
>>> 
>>>  MESSAGE (SEND_ERROR "The guile executable was not found, but is
>>>  required.
>>> 
>>> Please set GUILE_EXECUTABLE.")
>>> ENDIF (NOT GUILE_EXECUTABLE)
>>> 
>>> For guile 1.8 it should become
>>> FIND_PROGRAM (GUILE_EXECUTABLE guile1.8 guile)
>>> IF (NOT GUILE_EXECUTABLE)
>>> 
>>>  MESSAGE (SEND_ERROR "The guile executable was not found, but is
>>>  required.
>>> 
>>> Please set GUILE_EXECUTABLE.")
>>> ENDIF (NOT GUILE_EXECUTABLE)
>>> 
>>> Regards,
>>> 
>>> Geert
>> 
>> I don't have guile 1. guile --version; returns "2.2.2" and guile2.0
>> --version; returns "2.0.14".
> 
> Yes, distributions shift this all the time...
> 
> I'm still on Fedora 25 which has guile (being 2.0.13) and guile1.8 (being 
> 1.8.8)
> 
> While checking these version numbers I saw the copyright notice on guile 1.8 
> was last updated in 2008(!) and guile 2.0 in 2016. I think it's fair to state 
> guile 1.8 is getting rather outdated and I'll keep my vote to stop supporting 
> it ASAP :)

I'm very much in favor of dropping Guile-1.8 support.

If Guile-2.2 can be made to work without too much effort adding support for it 
would be a Good Thing.

BTW, while MingGW64 ships Guile it included Cygwin dependencies--it's a MSYS2 
package, not a MinGW one--so we can't use it. I've set up the moduleset to 
build Guile-2.0.14, and if Guile-2.2 works I'd change both Win and Mac to use 
that. Unfortunately it doesn't appear that Debian has looked at Guile-2.2 even 
for unstable, but that might be because we're the only major package that uses 
guile. (The other packages are freehold, libnlopt-guile0, moron, 
mailtutils-guile, guile-library, guile-son, and gwrap).

Looks like Fedora has guile-2.2 beginning with F25, but I don't know of a good 
way to find out what packages depend on it or on guile-2.0.

Regards,
John Ralls


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

Re: Gtk3 master

[Geert Janssens]

On donderdag 31 augustus 2017 16:17:20 CEST Aaron Laws wrote:
> On Thu, Aug 31, 2017 at 9:51 AM, Geert Janssens 
> wrote:
> > I meant to add still, if we want to keep guile 1.8 support, the
> > FIND_PACKAGE(GUILE_EXECUTABLE...) rules should move up inside the
> > branches of
> > the GUILE2 vs GUILE1 test.
> > For GUILE2 it can remain
> > FIND_PROGRAM (GUILE_EXECUTABLE guile2.0 guile)
> > IF (NOT GUILE_EXECUTABLE)
> > 
> >   MESSAGE (SEND_ERROR "The guile executable was not found, but is
> >   required.
> > 
> > Please set GUILE_EXECUTABLE.")
> > ENDIF (NOT GUILE_EXECUTABLE)
> > 
> > For guile 1.8 it should become
> > FIND_PROGRAM (GUILE_EXECUTABLE guile1.8 guile)
> > IF (NOT GUILE_EXECUTABLE)
> > 
> >   MESSAGE (SEND_ERROR "The guile executable was not found, but is
> >   required.
> > 
> > Please set GUILE_EXECUTABLE.")
> > ENDIF (NOT GUILE_EXECUTABLE)
> > 
> > Regards,
> > 
> > Geert
> 
> I don't have guile 1. guile --version; returns "2.2.2" and guile2.0
> --version; returns "2.0.14".

Yes, distributions shift this all the time...

I'm still on Fedora 25 which has guile (being 2.0.13) and guile1.8 (being 
1.8.8)

While checking these version numbers I saw the copyright notice on guile 1.8 
was last updated in 2008(!) and guile 2.0 in 2016. I think it's fair to state 
guile 1.8 is getting rather outdated and I'll keep my vote to stop supporting 
it ASAP :)

Geert

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

Re: Gtk3 master

[Geert Janssens]

On donderdag 31 augustus 2017 17:01:10 CEST Robert Fewell wrote:
> Copied your changes locally and was able to build OK.
> Bob
> 
> On 31 August 2017 at 15:17, Geert Janssens 
> 
> wrote:
> > On donderdag 31 augustus 2017 16:01:19 CEST Robert Fewell wrote:
> > > It builds with "guile2.0" removed on that line, also output of which
> > 
> > guile
> > 
> > > is /usr/bin/guile and that version is 1.8.8. I do not have version 2
> > > installed.
> > > Bob
> > 
> > Thanks for detailing this. It turns out the FIND_PROGRAM invocation was
> > incorrect. I didn't catch that because cmake caches such tests :(
> > 
> > I have pushed another commit which fixes this on my system. It also splits
> > the
> > FIND_PROGRAM call for guile 2 and guile 1 environments.
> > 
> > Can you test whether this works for you ?
> > 
> > Geert

Excellent :)

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

Re: Gtk3 master

[Robert Fewell]

Copied your changes locally and was able to build OK.
Bob

On 31 August 2017 at 15:17, Geert Janssens 
wrote:

> On donderdag 31 augustus 2017 16:01:19 CEST Robert Fewell wrote:
> > It builds with "guile2.0" removed on that line, also output of which
> guile
> > is /usr/bin/guile and that version is 1.8.8. I do not have version 2
> > installed.
> > Bob
> >
> Thanks for detailing this. It turns out the FIND_PROGRAM invocation was
> incorrect. I didn't catch that because cmake caches such tests :(
>
> I have pushed another commit which fixes this on my system. It also splits
> the
> FIND_PROGRAM call for guile 2 and guile 1 environments.
>
> Can you test whether this works for you ?
>
> Geert
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3 master

[Geert Janssens]

On donderdag 31 augustus 2017 16:01:19 CEST Robert Fewell wrote:
> It builds with "guile2.0" removed on that line, also output of which guile
> is /usr/bin/guile and that version is 1.8.8. I do not have version 2
> installed.
> Bob
> 
Thanks for detailing this. It turns out the FIND_PROGRAM invocation was 
incorrect. I didn't catch that because cmake caches such tests :(

I have pushed another commit which fixes this on my system. It also splits the 
FIND_PROGRAM call for guile 2 and guile 1 environments.

Can you test whether this works for you ?

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

Re: Gtk3 master

[Aaron Laws]

On Thu, Aug 31, 2017 at 9:51 AM, Geert Janssens 
wrote:

> I meant to add still, if we want to keep guile 1.8 support, the
> FIND_PACKAGE(GUILE_EXECUTABLE...) rules should move up inside the
> branches of
> the GUILE2 vs GUILE1 test.
> For GUILE2 it can remain
> FIND_PROGRAM (GUILE_EXECUTABLE guile2.0 guile)
> IF (NOT GUILE_EXECUTABLE)
>   MESSAGE (SEND_ERROR "The guile executable was not found, but is required.
> Please set GUILE_EXECUTABLE.")
> ENDIF (NOT GUILE_EXECUTABLE)
>
> For guile 1.8 it should become
> FIND_PROGRAM (GUILE_EXECUTABLE guile1.8 guile)
> IF (NOT GUILE_EXECUTABLE)
>   MESSAGE (SEND_ERROR "The guile executable was not found, but is required.
> Please set GUILE_EXECUTABLE.")
> ENDIF (NOT GUILE_EXECUTABLE)
>
> Regards,
>
> Geert


I don't have guile 1. guile --version; returns "2.2.2" and guile2.0
--version; returns "2.0.14".
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3 master

[Robert Fewell]

It builds with "guile2.0" removed on that line, also output of which guile
is /usr/bin/guile and that version is 1.8.8. I do not have version 2
installed.
Bob

On 31 August 2017 at 13:44, Aaron Laws  wrote:

> On Thu, Aug 31, 2017 at 8:28 AM, Robert Fewell <14ubo...@gmail.com> wrote:
>
>> Just tried to build from master after all the recent changes and it failed
>> on guile, currently I am running 1.8 and in the log file I see "Using
>> guile-1.8.x" but it then logs "The guile executable was not found, but is
>> required. Please set GUILE_EXECUTABLE." Looking at CMakeLists.txt, I can
>> build if I comment out the four lines starting at 283. Not sure if they
>> are
>> required or should be moved so will leave for some one who knows what they
>> are doing.
>>
>> On a similar note, I still do a build on my Gtk3.10 VM but have to change
>> line 195 as it states the version should be greater or equal to 3.14, is
>> this just a typo or have I got the minimum version wrong ?
>>
>> Bob
>>
>
> If you remove "guile2.0" from line 283, does it work?
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3 master

[Geert Janssens]

On donderdag 31 augustus 2017 14:28:33 CEST Robert Fewell wrote:
> Just tried to build from master after all the recent changes and it failed
> on guile, currently I am running 1.8 and in the log file I see "Using
> guile-1.8.x" but it then logs "The guile executable was not found, but is
> required. Please set GUILE_EXECUTABLE." Looking at CMakeLists.txt, I can
> build if I comment out the four lines starting at 283. Not sure if they are
> required or should be moved so will leave for some one who knows what they
> are doing.
> 
I meant to add still, if we want to keep guile 1.8 support, the 
FIND_PACKAGE(GUILE_EXECUTABLE...) rules should move up inside the branches of 
the GUILE2 vs GUILE1 test.
For GUILE2 it can remain
FIND_PROGRAM (GUILE_EXECUTABLE guile2.0 guile)
IF (NOT GUILE_EXECUTABLE)
  MESSAGE (SEND_ERROR "The guile executable was not found, but is required. 
Please set GUILE_EXECUTABLE.")
ENDIF (NOT GUILE_EXECUTABLE)

For guile 1.8 it should become
FIND_PROGRAM (GUILE_EXECUTABLE guile1.8 guile)
IF (NOT GUILE_EXECUTABLE)
  MESSAGE (SEND_ERROR "The guile executable was not found, but is required. 
Please set GUILE_EXECUTABLE.")
ENDIF (NOT GUILE_EXECUTABLE)

Regards,

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

Re: Gtk3 master

[Geert Janssens]

On donderdag 31 augustus 2017 14:28:33 CEST Robert Fewell wrote:
> Just tried to build from master after all the recent changes and it failed
> on guile, currently I am running 1.8 and in the log file I see "Using
> guile-1.8.x" but it then logs "The guile executable was not found, but is
> required. Please set GUILE_EXECUTABLE." Looking at CMakeLists.txt, I can
> build if I comment out the four lines starting at 283. Not sure if they are
> required or should be moved so will leave for some one who knows what they
> are doing.
> 
I'm inclined to drop guile 1.8 support completely for master. It's no longer 
supported by upstream and all of the distributions we care about have been 
shipping guile 2.0 for some time now. The last remaining blocker was our very 
own mingw based windows build. However we're in the process of migrating to 
mingw64 which does ship guile2 so I see no reason to keep supporting guile 
1.8.

At the other end of the spectrum, I wonder whether gnucash would work with 
guile 2.2, the current stable guile version...

> On a similar note, I still do a build on my Gtk3.10 VM but have to change
> line 195 as it states the version should be greater or equal to 3.14, is
> this just a typo or have I got the minimum version wrong ?
> 
Gtk 3.10 is still our baseline indeed, because that's the most recent version 
we can easily install on our Travis test environment.

I have just pushed a commit that adjusts this for cmake as well.

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

Re: Gtk3 master

[Aaron Laws]

On Thu, Aug 31, 2017 at 8:44 AM, Aaron Laws  wrote:

> On Thu, Aug 31, 2017 at 8:28 AM, Robert Fewell <14ubo...@gmail.com> wrote:
>
>> Just tried to build from master after all the recent changes and it failed
>> on guile, currently I am running 1.8 and in the log file I see "Using
>> guile-1.8.x" but it then logs "The guile executable was not found, but is
>> required. Please set GUILE_EXECUTABLE." Looking at CMakeLists.txt, I can
>> build if I comment out the four lines starting at 283. Not sure if they
>> are
>> required or should be moved so will leave for some one who knows what they
>> are doing.
>>
>> On a similar note, I still do a build on my Gtk3.10 VM but have to change
>> line 195 as it states the version should be greater or equal to 3.14, is
>> this just a typo or have I got the minimum version wrong ?
>>
>> Bob
>>
>
> If you remove "guile2.0" from line 283, does it work?
>

Oh, and another question. Would you post the output from   which guile;
and   which guile2.0; ?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3 master

[Aaron Laws]

On Thu, Aug 31, 2017 at 8:28 AM, Robert Fewell <14ubo...@gmail.com> wrote:

> Just tried to build from master after all the recent changes and it failed
> on guile, currently I am running 1.8 and in the log file I see "Using
> guile-1.8.x" but it then logs "The guile executable was not found, but is
> required. Please set GUILE_EXECUTABLE." Looking at CMakeLists.txt, I can
> build if I comment out the four lines starting at 283. Not sure if they are
> required or should be moved so will leave for some one who knows what they
> are doing.
>
> On a similar note, I still do a build on my Gtk3.10 VM but have to change
> line 195 as it states the version should be greater or equal to 3.14, is
> this just a typo or have I got the minimum version wrong ?
>
> Bob
>

If you remove "guile2.0" from line 283, does it work?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Gtk3 master

[Robert Fewell]

Just tried to build from master after all the recent changes and it failed
on guile, currently I am running 1.8 and in the log file I see "Using
guile-1.8.x" but it then logs "The guile executable was not found, but is
required. Please set GUILE_EXECUTABLE." Looking at CMakeLists.txt, I can
build if I comment out the four lines starting at 283. Not sure if they are
required or should be moved so will leave for some one who knows what they
are doing.

On a similar note, I still do a build on my Gtk3.10 VM but have to change
line 195 as it states the version should be greater or equal to 3.14, is
this just a typo or have I got the minimum version wrong ?

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

Re: Python bindings and Gtk3

[Mike Alexander]

> On Aug 10, 2017, at 3:22 AM, John Ralls  wrote:
> 
> 3.22.what? I pushed the change to gtk that caused the pango breakage between 
> 3.22.11 and 3.22.12 so 3.22.11 wouldn't have had the problem... and of course 
> if pango is using the fontconfig backend it shouldn't manifest anyway. Of 
> course it's also possible that MacPorts picked up my patch from the bug.

Sorry, it’s 3.22.17.  I didn’t copy and paste enough.

I discovered that switching to the HighContrast theme improved the sizing of 
the tabs so they are similar to the size in Gtk2.  This doesn’t seem like 
something I would expect.

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

Re: Python bindings and Gtk3

[John Ralls]

> On Aug 10, 2017, at 12:31 AM, Mike Alexander <m...@umich.edu> wrote:
> 
>> On Aug 9, 2017, at 1:49 PM, John Ralls <jra...@ceridwen.fremont.ca.us> wrote:
>> 
>> Hmm, looks like both whitespace and font are larger. What version of Gtk+-3?
>> 
> 
> It’s version 3.22.
> 
>> Hmm, looks like both whitespace and font are larger. What version of Gtk+-3?
>> 
>> You can try fiddling with the tab-label styling in 
>> ~/.config/gtk-3.0/gtk.css. There's some guidance in 
>> https://developer.gnome.org/gtk3/unstable/theming.html 
>> <https://developer.gnome.org/gtk3/unstable/theming.html>.
> 
> I’ll take a look at that.
> 

3.22.what? I pushed the change to gtk that caused the pango breakage between 
3.22.11 and 3.22.12 so 3.22.11 wouldn't have had the problem... and of course 
if pango is using the fontconfig backend it shouldn't manifest anyway. Of 
course it's also possible that MacPorts picked up my patch from the bug.

Regards,
John Ralls


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

Re: Python bindings and Gtk3

[Mike Alexander]

> On Aug 9, 2017, at 1:49 PM, John Ralls <jra...@ceridwen.fremont.ca.us> wrote:
> 
> Hmm, looks like both whitespace and font are larger. What version of Gtk+-3?
> 

It’s version 3.22.

> Hmm, looks like both whitespace and font are larger. What version of Gtk+-3?
> 
> You can try fiddling with the tab-label styling in ~/.config/gtk-3.0/gtk.css. 
> There's some guidance in 
> https://developer.gnome.org/gtk3/unstable/theming.html 
> <https://developer.gnome.org/gtk3/unstable/theming.html>.

I’ll take a look at that.

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

Re: Python bindings and Gtk3

[John Ralls]

> On Aug 9, 2017, at 7:28 AM, Mike Alexander <m...@umich.edu> wrote:
> 
>> On Aug 9, 2017, at 12:21 AM, Mike Alexander <m...@umich.edu 
>> <mailto:m...@umich.edu>> wrote:
>> 
>>> On Aug 8, 2017, at 10:23 AM, John Ralls <jra...@ceridwen.fremont.ca.us 
>>> <mailto:jra...@ceridwen.fremont.ca.us>> wrote:
>>> 
>>> I don't know if the MacPorts X-build uses the CoreText or FontConfig 
>>> backend for Pango, but if it uses CoreText it might be your problem.
>> 
>> I don’t know either.  I see that Pango’s configure looks for (and finds) 
>> fontconfig, but then says "checking which cairo font backends could be 
>> used... quartz freetype”.  I suspect it is using fontconfig.  I am using a 
>> Retina display, but the text in the tabs seems like it’s normal size.  There 
>> is a lot of blank space around the text that makes the tab bigger.  In fact 
>> the text itself is smaller in the Gtk3 version.  Here are a couple of 
>> screenshots.
> 
> 
> I guess attachments aren’t allowed, I should have known.  The screenshots are 
> at 
> 
> https://www.dropbox.com/s/9ge32ydfc95fum8/Gtk2%20tabs.png?dl=0 
> <https://www.dropbox.com/s/9ge32ydfc95fum8/Gtk2%20tabs.png?dl=0> (Gtk2)
> and
> https://www.dropbox.com/s/c650pqyjbyl1zvn/Gtk3%20tabs.png?dl=0 
> <https://www.dropbox.com/s/c650pqyjbyl1zvn/Gtk3%20tabs.png?dl=0> (Gtk3)

Hmm, looks like both whitespace and font are larger. What version of Gtk+-3?

You can try fiddling with the tab-label styling in ~/.config/gtk-3.0/gtk.css. 
There's some guidance in https://developer.gnome.org/gtk3/unstable/theming.html 
<https://developer.gnome.org/gtk3/unstable/theming.html>.

Regards,
John Ralls


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

Re: Python bindings and Gtk3

[Derek Atkins]

Mike,

Mike Alexander  writes:

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

*attachments* are allowed

*INLINE* images are not.

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

Re: Python bindings and Gtk3

[Mike Alexander]

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


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

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

  Mike

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

Re: Python bindings and Gtk3

[Mike Alexander]

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

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

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

Re: Python bindings and Gtk3

[John Ralls]

> On Aug 8, 2017, at 6:17 AM, Mike Alexander <m...@umich.edu> wrote:
> 
>> On Aug 7, 2017, at 8:51 PM, Sumit Bhardwaj <bhardw...@gmail.com> wrote:
>> 
>> For the tab issue, can you share a screenshot or something to that effect? I 
>> am on master build and have tabs on right-hand side as well, but it's 
>> perfectly usable.
>> 
> 
> It’s certainly usable, I didn’t mean to imply otherwise.  It’s just that I 
> have to scroll to see all my tabs where I don’t in the old version.  It’s a 
> minor annoyance that should be easily dealt with.  I should probably learn 
> enough about Gtk3 to fix it myself, but if I start playing around with that I 
> won’t get any of the things I should be doing done.  Also, note that I’m 
> using the X Window version, not the Quartz version.  The Quartz version may 
> be quite different (I’m not sure if it’s even being built yet).
> 
>   

Mike,

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

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

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

Regards,
John Ralls



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

Re: Python bindings and Gtk3

[Geert Janssens]

On dinsdag 8 augustus 2017 05:17:09 CEST Mike Alexander wrote:
> > On Aug 7, 2017, at 8:51 PM, Sumit Bhardwaj <bhardw...@gmail.com> wrote:
> > 
> > For the tab issue, can you share a screenshot or something to that effect?
> > I am on master build and have tabs on right-hand side as well, but it's
> > perfectly usable.
> It’s certainly usable, I didn’t mean to imply otherwise.  It’s just that I
> have to scroll to see all my tabs where I don’t in the old version.  It’s a
> minor annoyance that should be easily dealt with.  I should probably learn
> enough about Gtk3 to fix it myself, but if I start playing around with that
> I won’t get any of the things I should be doing done.  Also, note that I’m
> using the X Window version, not the Quartz version.  The Quartz version may
> be quite different (I’m not sure if it’s even being built yet).

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

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

Re: Python bindings and Gtk3

[Mike Alexander]

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

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

Mike

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

Re: Python bindings and Gtk3

[Sumit Bhardwaj]

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

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

-Sumit

On Mon, Aug 7, 2017 at 2:32 PM, Mike Alexander <m...@umich.edu> wrote:

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

Python bindings and Gtk3

[Mike Alexander]

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

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

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

  Mike

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

Re: Gtk3

[Robert Fewell]

I had come across those resource files but was not sure how to implement so
stuck to what I could figure out and it also allowed me to change the css
file without having to rebuild as I understood it.

I have also created a pull request for the register changes / fixes that I
had done without any of the colour updates that I was playing with, need to
digest your other email while I do my monthly VM system update.

Bob

On 31 July 2017 at 20:52, Geert Janssens  wrote:

> On vrijdag 28 juli 2017 18:07:41 CEST Robert Fewell wrote:
> > All, just for information I have been tinkering in the register code,
> > mainly on the appearance, hopefully have some thing to pull after the
> > weekend.
> > What I have done so far is get the header alignment working, added a css
> > class to set the background, text and border colours.Changed the sheet
> cell
> > alignment so all the borders are visible, added a css class for the
> > GncItemEdit with the border colour used for the cursor and made it fit
> the
> > cell.
> >
> > Question, all of the css stuff is stored in the application gnucash.css
> > file but if that is missing should there be hard coded defaults so the
> > register is still readable or should that file missing stop the
> application
> > being loaded.
> >
> > Bob
>
> Bob,
>
> I'm back in town as of today and I'm slowly processing my backlog.
>
> I see you have been busy while I was away. Great!
>
> To answer your question: I would suggest to use the same approach as gtk
> itself does. As the css is critical for the proper display of some of our
> custom widgets, it should be included in the form of a GResource [1]
> directly
> into the binary instead of a file on disk that may or may not be present.
> Gtk
> does this for example for its (default) Adwaita theme. More details may be
> found directlyin the gtk sources.
>
> Your css work so far and this mail made me think some more about the css
> concept for gnucash and perhaps we need to refine our initial idea. I'll
> post
> those in a separate mail though.
>
> Geert
>
>
> [1] https://developer.gnome.org/gio/stable/GResource.html
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gnucash and css (was: Gtk3)

[John Ralls]

> On Jul 31, 2017, at 11:02 PM, Geert Janssens <geert.gnuc...@kobaltwit.be> 
> wrote:
> 
> Bob,
> 
> As hinted in my previous message in the Gtk3 thread, I'd like to zoom in a 
> bit 
> on using Css for gnucash.
> 
> Let me start with a basic context for this discussion:
> * css in gtk (and hence gnucash) is used to define the visual representation 
> of the graphical user interface (defined through a set of "widgets").
> * for the best user experience the GUI should be consistent in style.
> * for standard widgets, gtk defines a default style (the Adwaita theme). 
> However users are free to configure a different style (or theme) for their 
> environment. Optionally each property in a theme can be overridden at a user 
> level by a user-defined css file.
> 
> So for standard widgets, gnucash usually doesn't have to do anything. This is 
> different for our custom widgets, such as the register and the SX overview 
> calendar (both based on a GtkLayout and doing custom drawing via cairo), or 
> widgets that define their own functional colors (like the transaction matcher 
> in the generic import code).
> 
> These widgets don't have a style by default, and hence we need to define it. 
> At the same time though, themes should be able to override whatever default 
> style we choose. This suggests our own styling should generally have a 
> FALLBACK priority rather than APPLICATION priority.
> 
> For any style property that is defined in the theme set by the user, this 
> will 
> then be used. If we define gnucash-only properties, these will most likely 
> not 
> appear in any theme and hence the values from our fallback will be used 
> instead.
> 
> The tricky part here is to define a fallback that goes well with whatever 
> theme the user has set for his environment. Take for example the colors used 
> in the SX overview calendar (white background/black text). These may not work 
> well with all themes so we should avoid to hard-code properties as much as 
> possible. I would instead propose to leverage the style classes as defined in 
> GtkStyleContext as much as possible [1]. Again for the SX overview calendar, 
> add a style class GTK_STYLE_CLASS_CALENDAR and then use whatever styling 
> information that gets set because of this [2]. Perhaps it requires more than 
> one style class to be added to get this to work completely. You can look for 
> examples in the Gtk source, like the use of the RUBBERBAND class in 
> gtktreeview.c [3]. I believe/hope when done carefully this can result in a 
> much more consistent GUI for gnucash and may reduce the amount of css we have 
> to maintain ourselves.
> 
> Then, specifically for the register we have an option that allows the user to 
> switch between the system level theme or our yellow/green theme. Building on 
> the above, the system level theme should be composed using the right style 
> classes. The yellow/green theme on the other hand is the first example I have 
> found that warrants a separate css definition. And this time with APPLICATION 
> priority because it's supposed to override theme specific styles. I would 
> define a new style class (something like "gnc-custom-colors"). And in css 
> write a section like this:
> 
> .gnc-custom-colors
> {
>color a: xyz;
>color b: abc;
>...
> }
> 
> What the exact properties should be will depend on the properties we combine 
> from the built-in style classes. If the built-in style classes for example 
> provide a property "separator-color", we should set this property also in the 
> .gnc-custom-colors class.
> 
> With this css in place, switching from default theme colors to our gnucash 
> yellow/green theme is a matter of adding/removing the gnc-custom-colors style 
> class from all register related widgets.
> 
> This same technique could be used for the label colors (negative numbers in 
> red). Only define an additional class ("negative-numbers-in-red" would do 
> fine) in which you explicitly set the red color to use and then add or remove 
> this class from all widgets that need to be able to display negative numbers 
> in red based on the user preference.
> 
> The last thing I'd like to bring up is the choice of property names. I read 
> in 
> your initial conversion to css you have chosen names very close to the 
> internally used variable names. While this is not wrong, I would prefer to 
> use 
> names that better describe the property's function.
> Let me explain with an example: the rows in the import matcher can have 3 
> colors (currently red, yellow or green). These colors support the state of 
> each line (unmatched, partially/potentially matched, matched? This may not be 
> 

Gnucash and css (was: Gtk3)

[Geert Janssens]

Bob,

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

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

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

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

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

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

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

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

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

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

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

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

Re: Gtk3

[Geert Janssens]

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

Bob,

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

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

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

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

Geert


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

Re: Gtk3

[Robert Fewell]

All, just for information I have been tinkering in the register code,
mainly on the appearance, hopefully have some thing to pull after the
weekend.
What I have done so far is get the header alignment working, added a css
class to set the background, text and border colours.Changed the sheet cell
alignment so all the borders are visible, added a css class for the
GncItemEdit with the border colour used for the cursor and made it fit the
cell.

Question, all of the css stuff is stored in the application gnucash.css
file but if that is missing should there be hard coded defaults so the
register is still readable or should that file missing stop the application
being loaded.

Bob

On 15 July 2017 at 18:12, Robert Fewell <14ubo...@gmail.com> wrote:

> These have been fixed in latest pull request.
>
> Bob
>
> On 12 July 2017 at 21:32, Geert Janssens <geert.gnuc...@kobaltwit.be>
> wrote:
>
>> Bob,
>>
>> I noticed today there are still some differences in keyboard navigation
>> between gnucash before I merged your gtk3 work and the current state. In
>> particular I see File->Close and File->Quit have lost their accelerators.
>> Perhaps there are others still.
>>
>> Regards,
>>
>> Geert
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3

[Robert Fewell]

These have been fixed in latest pull request.

Bob

On 12 July 2017 at 21:32, Geert Janssens <geert.gnuc...@kobaltwit.be> wrote:

> Bob,
>
> I noticed today there are still some differences in keyboard navigation
> between gnucash before I merged your gtk3 work and the current state. In
> particular I see File->Close and File->Quit have lost their accelerators.
> Perhaps there are others still.
>
> Regards,
>
> Geert
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3

[Geert Janssens]

Bob,

I noticed today there are still some differences in keyboard navigation 
between gnucash before I merged your gtk3 work and the current state. In 
particular I see File->Close and File->Quit have lost their accelerators. 
Perhaps there are others still.

Regards,

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

Re: Gtk3

[Geert Janssens]

On zondag 9 juli 2017 18:32:40 CEST Robert Fewell wrote:
> I have just issued a pull request for the changes that I made after Geert
> had copied my branch and most of the changes he pointed out on his review.
> The main ones being the missed alt key combination on some buttons, migrate
> the dialog-import.glade to gtk3 again which stops a crash if you go to
> preferences and a the some miss added style context classes.
> 
> I will try and look at the other points raised this week.
> 
> Bob

Thanks Bob. Everything is pushed to master.

As said on the PR I worked on the pixmaps story today myself as it was 
blocking the Fedora copr builds. So that part is done (except for a harmless 
warning being generated).

I'm not sure I will have more time for gnucash before my holidays by the way 
so feel free to work in any area you choose.

Regards,

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

Re: Gtk3

[Robert Fewell]

I have just issued a pull request for the changes that I made after Geert
had copied my branch and most of the changes he pointed out on his review.
The main ones being the missed alt key combination on some buttons, migrate
the dialog-import.glade to gtk3 again which stops a crash if you go to
preferences and a the some miss added style context classes.

I will try and look at the other points raised this week.

Bob

On 8 July 2017 at 19:54, Robert Fewell <14ubo...@gmail.com> wrote:

> I will have a think about this after I complete all the other required
> changes.
>
> Bob
>
> On 8 July 2017 at 17:46, Geert Janssens <geert.gnuc...@kobaltwit.be>
> wrote:
>
>> On zaterdag 8 juli 2017 17:25:19 CEST Robert Fewell wrote:
>>
>> > The file name can be as you stated, I was thinking about the widget
>> style
>>
>> > contexts, maybe along the lines of GncDenseCal_font_size
>>
>> >
>>
>> > Bob
>>
>>
>>
>> Right. I actually have no idea what is common. The whole css thing is
>> pretty new to me. Did you find any examples in other applications ?
>>
>>
>>
>> I believe though there should be a combination of two things: a widget
>> type specifier (like gncdensecal) and style properties for that widget.
>>
>>
>>
>> So a widget of type gncdensecal can have a property called "font-size"
>> (note dashes are usually used in css rather than underscores).
>>
>>
>>
>> With that you could write css like:
>>
>> gncdensecal
>>
>> {
>>
>> font-size: 10pt;
>>
>> }
>>
>>
>>
>> If you want to alter a property of one particular Dense Calendar, you
>> could use the style context name you have set in your code, something like
>> this
>>
>> #DensCalX
>>
>> {
>>
>> font-size: 10pt;
>>
>> }
>>
>>
>>
>> That's only highlevel code, not fully verified :) More details
>> explanations and examples can be found here:
>>
>> https://developer.gnome.org/gtk3/unstable/chap-css-overview.html
>>
>>
>>
>> For default gtk widgets this is all available by default. And usually
>> we'd want to use the second form (altering css properties of one particular
>> widget instead of a complete widget class).
>>
>> For our custom widgets we'd have to define these widget types and style
>> properties ourselves.
>>
>>
>>
>> Geert
>>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3

[Robert Fewell]

I will have a think about this after I complete all the other required
changes.

Bob

On 8 July 2017 at 17:46, Geert Janssens <geert.gnuc...@kobaltwit.be> wrote:

> On zaterdag 8 juli 2017 17:25:19 CEST Robert Fewell wrote:
>
> > The file name can be as you stated, I was thinking about the widget style
>
> > contexts, maybe along the lines of GncDenseCal_font_size
>
> >
>
> > Bob
>
>
>
> Right. I actually have no idea what is common. The whole css thing is
> pretty new to me. Did you find any examples in other applications ?
>
>
>
> I believe though there should be a combination of two things: a widget
> type specifier (like gncdensecal) and style properties for that widget.
>
>
>
> So a widget of type gncdensecal can have a property called "font-size"
> (note dashes are usually used in css rather than underscores).
>
>
>
> With that you could write css like:
>
> gncdensecal
>
> {
>
> font-size: 10pt;
>
> }
>
>
>
> If you want to alter a property of one particular Dense Calendar, you
> could use the style context name you have set in your code, something like
> this
>
> #DensCalX
>
> {
>
> font-size: 10pt;
>
> }
>
>
>
> That's only highlevel code, not fully verified :) More details
> explanations and examples can be found here:
>
> https://developer.gnome.org/gtk3/unstable/chap-css-overview.html
>
>
>
> For default gtk widgets this is all available by default. And usually we'd
> want to use the second form (altering css properties of one particular
> widget instead of a complete widget class).
>
> For our custom widgets we'd have to define these widget types and style
> properties ourselves.
>
>
>
> Geert
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3

[Robert Fewell]

OK, I will have a go at this on Sunday before I try and make the changes
you have mentioned in your feedback.

Bob

On 8 July 2017 at 17:31, Geert Janssens <geert.gnuc...@kobaltwit.be> wrote:

> Bob,
>
> I had a few merge conflicts to resolve during merge. There was one that
> wasn't
> trivial:
> src/import-export/dialog-import.glade
>
> To be able to continue with the merge I have reverted it to the state on
> master, except for the name changes for the primary dialogs. That way it
> still
> builds fine, but your deprecated widgets changes are lost. There is
> unfortunately no way to sanely resolve merge conflicts in a glade file.
>
> So this file has to be converted again.
>
> What I did is pull in your branch (which also includes my and John's work)
> and
> merged it locally in the current master branch, after resolving the
> conflicts.
> I then pushed this result back to my github repo (gjanssens). So the master
> branch in that repo is now running gtk3.
>
> Note that this branch currently doesn't install if you enable building with
> aqbanking. This is also the case for our central master branch though. It
> looks like there are a few issues with the dist/distcheck/uninstall
> commit. I
> fixed one of them on my local branch but I have no idea how to fix the
> aqbanking one.
>
> Anyway to avoid we have to do this merge again in the future, can you
> (re)base
> your local commits you haven't pushed yet on my master branch ?
>
> I'm holding off on pushing the whole thing to master on code.gnucash.org
> until
> I heard from John.
>
> Regards,
>
> Geert
>
> On zaterdag 8 juli 2017 16:02:01 CEST Geert Janssens wrote:
> > I'm done with reviewing your work. You'll find mi comments directly on
> the
> > github commits.
> >
> > In general - well done! This really brings us much closer to a real gtk3
> > gnucash.
> >
> > As far as I'm concerned your branch is ready for merging:
> > - the tree builds fine
> > - the build executable seems to work barring a few visual details
> >
> > So IMO this is ready to be tested by a bigger audience.
> >
> > Regards,
> >
> > Geert
> >
> > On zaterdag 8 juli 2017 15:01:38 CEST Geert Janssens wrote:
> > > Bob,
> > >
> > > While reading through your changes I note we have lots of places where
> we
> > > make some small tweaks to the default gui style. It shows in your
> commits
> > > because we have to change from GtkStyle api to
> > > GtkStyleContext/GtkCssProvider api.
> > >
> > > This got me thinking about a future streamlining we should consider:
> > > instead of adding code snippets that insert custom CSS, can't we
> collect
> > > all of these snippets in one big CSS file we ship with gnucash, to be
> > > stored in /etc/ gnucash/gnucash.css and which we read at load time ?
> Much
> > > like we now load a custom .gtk3.0-gnucash.css file.
> > >
> > > Both can co-exist IMO, with the latter taking precedence over the
> former.
> > > The one in etc should be "Application" priority the one in the homedir
> > > "User" priority.
> > >
> > > This would keep the code cleaner and separate function from
> presentation.
> > > Especially your initial work of adding style context to most widgets
> is a
> > > big step in the right direction.
> > >
> > > What do you think ?
> > >
> > > Regards,
> > >
> > > Geert
> >
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3

[John Ralls]

Geert,

Great, thanks! That was what I was planning to do today, so it moves me up to 
merging in my mingw64 branch and converting the mingw64 branch of 
gnucash-on-windows to Gtk3.

That blocks windows nightlies so I had it in mind that we’d hold off on merging 
into the official master until then. OTOH we really shouldn’t do any further 
work on the gtk2 master, it will just make more work later.

As for AQBanking, I thought I’d gotten that fixed in the distcheck merge 
commit. One does have to turn it on explicitly when building with Cmake.

Regards,
John Ralls

> On Jul 8, 2017, at 9:31 AM, Geert Janssens <geert.gnuc...@kobaltwit.be> wrote:
> 
> Bob,
> 
> I had a few merge conflicts to resolve during merge. There was one that 
> wasn't 
> trivial:
> src/import-export/dialog-import.glade
> 
> To be able to continue with the merge I have reverted it to the state on 
> master, except for the name changes for the primary dialogs. That way it 
> still 
> builds fine, but your deprecated widgets changes are lost. There is 
> unfortunately no way to sanely resolve merge conflicts in a glade file.
> 
> So this file has to be converted again.
> 
> What I did is pull in your branch (which also includes my and John's work) 
> and 
> merged it locally in the current master branch, after resolving the 
> conflicts. 
> I then pushed this result back to my github repo (gjanssens). So the master 
> branch in that repo is now running gtk3.
> 
> Note that this branch currently doesn't install if you enable building with 
> aqbanking. This is also the case for our central master branch though. It 
> looks like there are a few issues with the dist/distcheck/uninstall commit. I 
> fixed one of them on my local branch but I have no idea how to fix the 
> aqbanking one.
> 
> Anyway to avoid we have to do this merge again in the future, can you 
> (re)base 
> your local commits you haven't pushed yet on my master branch ?
> 
> I'm holding off on pushing the whole thing to master on code.gnucash.org 
> until 
> I heard from John.
> 
> Regards,
> 
> Geert
> 
> On zaterdag 8 juli 2017 16:02:01 CEST Geert Janssens wrote:
>> I'm done with reviewing your work. You'll find mi comments directly on the
>> github commits.
>> 
>> In general - well done! This really brings us much closer to a real gtk3
>> gnucash.
>> 
>> As far as I'm concerned your branch is ready for merging:
>> - the tree builds fine
>> - the build executable seems to work barring a few visual details
>> 
>> So IMO this is ready to be tested by a bigger audience.
>> 
>> Regards,
>> 
>> Geert
>> 
>> On zaterdag 8 juli 2017 15:01:38 CEST Geert Janssens wrote:
>>> Bob,
>>> 
>>> While reading through your changes I note we have lots of places where we
>>> make some small tweaks to the default gui style. It shows in your commits
>>> because we have to change from GtkStyle api to
>>> GtkStyleContext/GtkCssProvider api.
>>> 
>>> This got me thinking about a future streamlining we should consider:
>>> instead of adding code snippets that insert custom CSS, can't we collect
>>> all of these snippets in one big CSS file we ship with gnucash, to be
>>> stored in /etc/ gnucash/gnucash.css and which we read at load time ? Much
>>> like we now load a custom .gtk3.0-gnucash.css file.
>>> 
>>> Both can co-exist IMO, with the latter taking precedence over the former.
>>> The one in etc should be "Application" priority the one in the homedir
>>> "User" priority.
>>> 
>>> This would keep the code cleaner and separate function from presentation.
>>> Especially your initial work of adding style context to most widgets is a
>>> big step in the right direction.
>>> 
>>> What do you think ?
>>> 
>>> Regards,
>>> 
>>> Geert
>> 
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

Re: Gtk3

[Geert Janssens]

On zaterdag 8 juli 2017 17:25:19 CEST Robert Fewell wrote:
> The file name can be as you stated, I was thinking about the widget style
> contexts, maybe along the lines of GncDenseCal_font_size
> 
> Bob

Right. I actually have no idea what is common. The whole css thing is pretty 
new to me. Did you 
find any examples in other applications ?

I believe though there should be a combination of two things: a widget type 
specifier (like 
gncdensecal) and style properties for that widget.

So a widget of type gncdensecal can have a property called "font-size" (note 
dashes are usually 
used in css rather than underscores).

With that you could write css like:
gncdensecal
{
font-size: 10pt;
}

If you want to alter a property of one particular Dense Calendar, you could use 
the style context 
name you have set in your code, something like this
#DensCalX
{
font-size: 10pt;
}

That's only highlevel code, not fully verified :) More details explanations and 
examples can be 
found here:
https://developer.gnome.org/gtk3/unstable/chap-css-overview.html

For default gtk widgets this is all available by default. And usually we'd want 
to use the second 
form (altering css properties of one particular widget instead of a complete 
widget class).
For our custom widgets we'd have to define these widget types and style 
properties ourselves.

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

Re: Gtk3

[Geert Janssens]

Bob,

I had a few merge conflicts to resolve during merge. There was one that wasn't 
trivial:
src/import-export/dialog-import.glade

To be able to continue with the merge I have reverted it to the state on 
master, except for the name changes for the primary dialogs. That way it still 
builds fine, but your deprecated widgets changes are lost. There is 
unfortunately no way to sanely resolve merge conflicts in a glade file.

So this file has to be converted again.

What I did is pull in your branch (which also includes my and John's work) and 
merged it locally in the current master branch, after resolving the conflicts. 
I then pushed this result back to my github repo (gjanssens). So the master 
branch in that repo is now running gtk3.

Note that this branch currently doesn't install if you enable building with 
aqbanking. This is also the case for our central master branch though. It 
looks like there are a few issues with the dist/distcheck/uninstall commit. I 
fixed one of them on my local branch but I have no idea how to fix the 
aqbanking one.

Anyway to avoid we have to do this merge again in the future, can you (re)base 
your local commits you haven't pushed yet on my master branch ?

I'm holding off on pushing the whole thing to master on code.gnucash.org until 
I heard from John.

Regards,

Geert

On zaterdag 8 juli 2017 16:02:01 CEST Geert Janssens wrote:
> I'm done with reviewing your work. You'll find mi comments directly on the
> github commits.
> 
> In general - well done! This really brings us much closer to a real gtk3
> gnucash.
> 
> As far as I'm concerned your branch is ready for merging:
> - the tree builds fine
> - the build executable seems to work barring a few visual details
> 
> So IMO this is ready to be tested by a bigger audience.
> 
> Regards,
> 
> Geert
> 
> On zaterdag 8 juli 2017 15:01:38 CEST Geert Janssens wrote:
> > Bob,
> > 
> > While reading through your changes I note we have lots of places where we
> > make some small tweaks to the default gui style. It shows in your commits
> > because we have to change from GtkStyle api to
> > GtkStyleContext/GtkCssProvider api.
> > 
> > This got me thinking about a future streamlining we should consider:
> > instead of adding code snippets that insert custom CSS, can't we collect
> > all of these snippets in one big CSS file we ship with gnucash, to be
> > stored in /etc/ gnucash/gnucash.css and which we read at load time ? Much
> > like we now load a custom .gtk3.0-gnucash.css file.
> > 
> > Both can co-exist IMO, with the latter taking precedence over the former.
> > The one in etc should be "Application" priority the one in the homedir
> > "User" priority.
> > 
> > This would keep the code cleaner and separate function from presentation.
> > Especially your initial work of adding style context to most widgets is a
> > big step in the right direction.
> > 
> > What do you think ?
> > 
> > Regards,
> > 
> > Geert
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


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

Re: Gtk3

[Robert Fewell]

The file name can be as you stated, I was thinking about the widget style
contexts, maybe along the lines of GncDenseCal_font_size

Bob

On 8 July 2017 at 14:39, Geert Janssens  wrote:

> On zaterdag 8 juli 2017 15:17:45 CEST Robert Fewell wrote:
> > Geert,
> >
> > That sounds like a good idea, not sure about the location, may be in
> > share/gnucash/gnucash.css
>
> Doh... Indeed share/gnucash/ would be much better than /etc. It's
> application
> data, not system configuration.
>
> > Some kind of naming format will need to be decided that makes sense.
> >
> Do you mean for the file name or for the widget style contexts ?
>
> > I can have a look at that after all your initial thoughts !!
>
> That would be great.
>
> Geert
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3

[Robert Fewell]

Thanks for your comments, I have a few more changes to make and then I will
try and get your recomendations done next week.

Bob

On 8 July 2017 at 15:02, Geert Janssens <geert.gnuc...@kobaltwit.be> wrote:

> I'm done with reviewing your work. You'll find mi comments directly on the
> github commits.
>
> In general - well done! This really brings us much closer to a real gtk3
> gnucash.
>
> As far as I'm concerned your branch is ready for merging:
> - the tree builds fine
> - the build executable seems to work barring a few visual details
>
> So IMO this is ready to be tested by a bigger audience.
>
> Regards,
>
> Geert
>
> On zaterdag 8 juli 2017 15:01:38 CEST Geert Janssens wrote:
> > Bob,
> >
> > While reading through your changes I note we have lots of places where we
> > make some small tweaks to the default gui style. It shows in your commits
> > because we have to change from GtkStyle api to
> > GtkStyleContext/GtkCssProvider api.
> >
> > This got me thinking about a future streamlining we should consider:
> instead
> > of adding code snippets that insert custom CSS, can't we collect all of
> > these snippets in one big CSS file we ship with gnucash, to be stored in
> > /etc/ gnucash/gnucash.css and which we read at load time ? Much like we
> now
> > load a custom .gtk3.0-gnucash.css file.
> >
> > Both can co-exist IMO, with the latter taking precedence over the former.
> > The one in etc should be "Application" priority the one in the homedir
> > "User" priority.
> >
> > This would keep the code cleaner and separate function from presentation.
> > Especially your initial work of adding style context to most widgets is a
> > big step in the right direction.
> >
> > What do you think ?
> >
> > Regards,
> >
> > Geert
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3

[Geert Janssens]

I'm done with reviewing your work. You'll find mi comments directly on the 
github commits.

In general - well done! This really brings us much closer to a real gtk3 
gnucash.

As far as I'm concerned your branch is ready for merging:
- the tree builds fine
- the build executable seems to work barring a few visual details

So IMO this is ready to be tested by a bigger audience.

Regards,

Geert

On zaterdag 8 juli 2017 15:01:38 CEST Geert Janssens wrote:
> Bob,
> 
> While reading through your changes I note we have lots of places where we
> make some small tweaks to the default gui style. It shows in your commits
> because we have to change from GtkStyle api to
> GtkStyleContext/GtkCssProvider api.
> 
> This got me thinking about a future streamlining we should consider: instead
> of adding code snippets that insert custom CSS, can't we collect all of
> these snippets in one big CSS file we ship with gnucash, to be stored in
> /etc/ gnucash/gnucash.css and which we read at load time ? Much like we now
> load a custom .gtk3.0-gnucash.css file.
> 
> Both can co-exist IMO, with the latter taking precedence over the former.
> The one in etc should be "Application" priority the one in the homedir
> "User" priority.
> 
> This would keep the code cleaner and separate function from presentation.
> Especially your initial work of adding style context to most widgets is a
> big step in the right direction.
> 
> What do you think ?
> 
> Regards,
> 
> Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3

[Geert Janssens]

On zaterdag 8 juli 2017 15:17:45 CEST Robert Fewell wrote:
> Geert,
> 
> That sounds like a good idea, not sure about the location, may be in
> share/gnucash/gnucash.css

Doh... Indeed share/gnucash/ would be much better than /etc. It's application 
data, not system configuration.

> Some kind of naming format will need to be decided that makes sense.
> 
Do you mean for the file name or for the widget style contexts ?

> I can have a look at that after all your initial thoughts !!

That would be great.

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

Re: Gtk3

[Robert Fewell]

Geert,

That sounds like a good idea, not sure about the location, may be in
share/gnucash/gnucash.css
Some kind of naming format will need to be decided that makes sense.

I can have a look at that after all your initial thoughts !!

Bob

On 8 July 2017 at 14:01, Geert Janssens <geert.gnuc...@kobaltwit.be> wrote:

> Bob,
>
> While reading through your changes I note we have lots of places where we
> make
> some small tweaks to the default gui style. It shows in your commits
> because
> we have to change from GtkStyle api to GtkStyleContext/GtkCssProvider api.
>
> This got me thinking about a future streamlining we should consider:
> instead
> of adding code snippets that insert custom CSS, can't we collect all of
> these
> snippets in one big CSS file we ship with gnucash, to be stored in /etc/
> gnucash/gnucash.css and which we read at load time ? Much like we now load
> a
> custom .gtk3.0-gnucash.css file.
>
> Both can co-exist IMO, with the latter taking precedence over the former.
> The
> one in etc should be "Application" priority the one in the homedir "User"
> priority.
>
> This would keep the code cleaner and separate function from presentation.
> Especially your initial work of adding style context to most widgets is a
> big
> step in the right direction.
>
> What do you think ?
>
> Regards,
>
> Geert
>
> On donderdag 29 juni 2017 11:16:04 CEST Robert Fewell wrote:
> > This is what I have done so far, may of gone too far but every thing
> still
> > appears to be working.
> > I have not touched any Aquabanking stuff, not sure what needs to be done
> to
> > get that enabled but probably would not take long to convert.
> >
> > All glade files are now verified against 3.10 and deprecated widgets
> > changed.
> > Stock buttons changed to the equivalent labels and images changed to
> icons
> > including the GNC_ ones.
> >
> > All deprecated widgets have been changed to 3.10 equivalents apart from
> > GtkUiManager, GtkAction and GtkActionMenu. These are mostly to do with
> > toolbars, menus, accelerator keys and there are no easy real equivalents
> so
> > propose to leave them deprecated to the end and then maybe a decision can
> > be made.
> >
> > I have tried to stay away from the register but some of the commits have
> > replaced some deprecated widgets.
> >
> > I have experimented with some CSS by adding style context classes of the
> > nature "GncImapDialog" to various dialogues and this seems to work quite
> > well down to changing the background colour of different tree views. May
> > continue to add more.
> >
> > There are no doubt some tweaks to be made to align with current version
> but
> > maybe that should wait till the gtk3 branch is updated from master.
> >
> > With version 3.22, I am getting warnings on the console about transient
> > windows not having a parent so may have a look at that next. There are
> > other warnings but they seem to be concerned with GTK itself, may need
> > looking at, not sure. Also with this version we get a whole new set of
> > deprecated widgets that may be an idea to get replaced. Will need to do a
> > complete rebuild on this version to get an updated log file.
> >
> >
> > Bob
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3

[Geert Janssens]

Bob,

While reading through your changes I note we have lots of places where we make 
some small tweaks to the default gui style. It shows in your commits because 
we have to change from GtkStyle api to GtkStyleContext/GtkCssProvider api.

This got me thinking about a future streamlining we should consider: instead 
of adding code snippets that insert custom CSS, can't we collect all of these 
snippets in one big CSS file we ship with gnucash, to be stored in /etc/
gnucash/gnucash.css and which we read at load time ? Much like we now load a 
custom .gtk3.0-gnucash.css file.

Both can co-exist IMO, with the latter taking precedence over the former. The 
one in etc should be "Application" priority the one in the homedir "User" 
priority.

This would keep the code cleaner and separate function from presentation. 
Especially your initial work of adding style context to most widgets is a big 
step in the right direction.

What do you think ?

Regards,

Geert

On donderdag 29 juni 2017 11:16:04 CEST Robert Fewell wrote:
> This is what I have done so far, may of gone too far but every thing still
> appears to be working.
> I have not touched any Aquabanking stuff, not sure what needs to be done to
> get that enabled but probably would not take long to convert.
> 
> All glade files are now verified against 3.10 and deprecated widgets
> changed.
> Stock buttons changed to the equivalent labels and images changed to icons
> including the GNC_ ones.
> 
> All deprecated widgets have been changed to 3.10 equivalents apart from
> GtkUiManager, GtkAction and GtkActionMenu. These are mostly to do with
> toolbars, menus, accelerator keys and there are no easy real equivalents so
> propose to leave them deprecated to the end and then maybe a decision can
> be made.
> 
> I have tried to stay away from the register but some of the commits have
> replaced some deprecated widgets.
> 
> I have experimented with some CSS by adding style context classes of the
> nature "GncImapDialog" to various dialogues and this seems to work quite
> well down to changing the background colour of different tree views. May
> continue to add more.
> 
> There are no doubt some tweaks to be made to align with current version but
> maybe that should wait till the gtk3 branch is updated from master.
> 
> With version 3.22, I am getting warnings on the console about transient
> windows not having a parent so may have a look at that next. There are
> other warnings but they seem to be concerned with GTK itself, may need
> looking at, not sure. Also with this version we get a whole new set of
> deprecated widgets that may be an idea to get replaced. Will need to do a
> complete rebuild on this version to get an updated log file.
> 
> 
> Bob
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3

[John Ralls]

Bob,

Excellent, thanks.

Menus and Actions have moved to GIO: 
https://developer.gnome.org/gio/unstable/application.html 
<https://developer.gnome.org/gio/unstable/application.html> and most of the new 
deprecations in Gtk-3.22 are there as a “heads up” for Gtk-4, which isn’t 
really ready for use by applications yet. Changing to an application model will 
require some redesign and we don’t really have time for that, so we can leave 
those deprecations and document them with a bug.

Regards,
John Ralls

> On Jun 29, 2017, at 2:16 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> This is what I have done so far, may of gone too far but every thing still 
> appears to be working.
> I have not touched any Aquabanking stuff, not sure what needs to be done to 
> get that enabled but probably would not take long to convert.
> 
> All glade files are now verified against 3.10 and deprecated widgets changed.
> Stock buttons changed to the equivalent labels and images changed to icons 
> including the GNC_ ones.
> 
> All deprecated widgets have been changed to 3.10 equivalents apart from 
> GtkUiManager, GtkAction and GtkActionMenu. These are mostly to do with 
> toolbars, menus, accelerator keys and there are no easy real equivalents so 
> propose to leave them deprecated to the end and then maybe a decision can be 
> made.
> 
> I have tried to stay away from the register but some of the commits have 
> replaced some deprecated widgets.
> 
> I have experimented with some CSS by adding style context classes of the 
> nature "GncImapDialog" to various dialogues and this seems to work quite well 
> down to changing the background colour of different tree views. May continue 
> to add more.
> 
> There are no doubt some tweaks to be made to align with current version but 
> maybe that should wait till the gtk3 branch is updated from master.
> 
> With version 3.22, I am getting warnings on the console about transient 
> windows not having a parent so may have a look at that next. There are other 
> warnings but they seem to be concerned with GTK itself, may need looking at, 
> not sure. Also with this version we get a whole new set of deprecated widgets 
> that may be an idea to get replaced. Will need to do a complete rebuild on 
> this version to get an updated log file.
> 
> 
> Bob
> 
>   
> 
> 
> On 16 June 2017 at 20:15, John Ralls <jra...@ceridwen.us 
> <mailto:jra...@ceridwen.us>> wrote:
> Bob,
> 
> Super! Thanks!
> 
> The treatment of stock images was something of a moving target in Gtk3 so you 
> may have to do some config/cmake work to figure out what to use and then 
> conditionally compile based the result. We do need to look good on 3.10-3.22 
> and everything in between. I think complaints about that were one of the 
> motivations for the new release plan for 4.x.
> 
> Change the Glade files as much as you think appropriate and have time for.
> 
> Regards,
> John Ralls
> 
> > On Jun 16, 2017, at 9:24 AM, Robert Fewell <14ubo...@gmail.com 
> > <mailto:14ubo...@gmail.com>> wrote:
> >
> > OK, I have been tapping away with the following progress...
> > I downgraded a clone VM to Gtk+3.10.8 which successfully builds and runs
> > but I seem to of lost some stock images, not an issue as I can temporary
> > replace them
> > but I can use it to make sure I have not included any newer functions.
> >
> > In the original VM I have built and made some changes which can be seen at 
> > My
> > GitHub <https://github.com/Bob-IT/gnucash/tree/gtk3 
> > <https://github.com/Bob-IT/gnucash/tree/gtk3>>
> > I have hopefully done the following but as normal there may be some
> > tweaks...
> > Replaced RC file with CSS file, name may need changing
> > The dense calendar now renders with a white background but can be set with
> > CSS
> > Changed the way tabs are done and now display correctly and fixed the width
> > updates
> > Changed most widgets that had a horizontal / vertical function to the new
> > equivalents.  These were simple function swaps I had in existing patch file.
> >
> > I was going to look at the account edit dialogue but wanted to ask how much
> > do you want the glade files changed ?
> > Change the version and replace deprecated widgets ?
> >
> > There are some further deprecated widgets that I will change if able to as
> > I come across them.
> >
> > Bob
> >
> > On 6 June 2017 at 09:54, Geert Janssens <geert.gnuc...@kobaltwit.be 
> > <mailto:geert.gnuc...@kobaltwit.be>> wrote:
> >
> >> On maandag 5 juni 2017 12:19:24 CEST Robert Fewell wrote:
> >>

Re: Gtk3

[Robert Fewell]

This is what I have done so far, may of gone too far but every thing still
appears to be working.
I have not touched any Aquabanking stuff, not sure what needs to be done to
get that enabled but probably would not take long to convert.

All glade files are now verified against 3.10 and deprecated widgets
changed.
Stock buttons changed to the equivalent labels and images changed to icons
including the GNC_ ones.

All deprecated widgets have been changed to 3.10 equivalents apart from
GtkUiManager, GtkAction and GtkActionMenu. These are mostly to do with
toolbars, menus, accelerator keys and there are no easy real equivalents so
propose to leave them deprecated to the end and then maybe a decision can
be made.

I have tried to stay away from the register but some of the commits have
replaced some deprecated widgets.

I have experimented with some CSS by adding style context classes of the
nature "GncImapDialog" to various dialogues and this seems to work quite
well down to changing the background colour of different tree views. May
continue to add more.

There are no doubt some tweaks to be made to align with current version but
maybe that should wait till the gtk3 branch is updated from master.

With version 3.22, I am getting warnings on the console about transient
windows not having a parent so may have a look at that next. There are
other warnings but they seem to be concerned with GTK itself, may need
looking at, not sure. Also with this version we get a whole new set of
deprecated widgets that may be an idea to get replaced. Will need to do a
complete rebuild on this version to get an updated log file.


Bob




On 16 June 2017 at 20:15, John Ralls <jra...@ceridwen.us> wrote:

> Bob,
>
> Super! Thanks!
>
> The treatment of stock images was something of a moving target in Gtk3 so
> you may have to do some config/cmake work to figure out what to use and
> then conditionally compile based the result. We do need to look good on
> 3.10-3.22 and everything in between. I think complaints about that were one
> of the motivations for the new release plan for 4.x.
>
> Change the Glade files as much as you think appropriate and have time for.
>
> Regards,
> John Ralls
>
> > On Jun 16, 2017, at 9:24 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > OK, I have been tapping away with the following progress...
> > I downgraded a clone VM to Gtk+3.10.8 which successfully builds and runs
> > but I seem to of lost some stock images, not an issue as I can temporary
> > replace them
> > but I can use it to make sure I have not included any newer functions.
> >
> > In the original VM I have built and made some changes which can be seen
> at My
> > GitHub <https://github.com/Bob-IT/gnucash/tree/gtk3>
> > I have hopefully done the following but as normal there may be some
> > tweaks...
> > Replaced RC file with CSS file, name may need changing
> > The dense calendar now renders with a white background but can be set
> with
> > CSS
> > Changed the way tabs are done and now display correctly and fixed the
> width
> > updates
> > Changed most widgets that had a horizontal / vertical function to the new
> > equivalents.  These were simple function swaps I had in existing patch
> file.
> >
> > I was going to look at the account edit dialogue but wanted to ask how
> much
> > do you want the glade files changed ?
> > Change the version and replace deprecated widgets ?
> >
> > There are some further deprecated widgets that I will change if able to
> as
> > I come across them.
> >
> > Bob
> >
> > On 6 June 2017 at 09:54, Geert Janssens <geert.gnuc...@kobaltwit.be>
> wrote:
> >
> >> On maandag 5 juni 2017 12:19:24 CEST Robert Fewell wrote:
> >>> Hi,
> >>>
> >>> I was browsing the IRC logs and Geert mentioned his gtk3 branch, yes I
> >> have
> >>> pulled from there and recently updated my local version which was built
> >>> successfully.
> >>> I tend not to fiddle where other people are working as I would no doubt
> >>> just get in the way or slow down their efforts.
> >>>
> >>> If you would like me to look at some thing, just ask and I will have a
> >>> look, been looking at some schedule bugs but they can wait...
> >>>
> >>> What version of Gtk3 are these changes aimed at, my gtk3 development VM
> >> is
> >>> on 3.20.9 ?
> >>
> >> Hi Bob,
> >>
> >> I'm happy you're willing to jump in as well.
> >>
> >> As John already mentioned (and you could have read on IRC) I'm currently
> >> pretty occupied outside of

Re: Gtk3

[John Ralls]

Bob,

Super! Thanks!

The treatment of stock images was something of a moving target in Gtk3 so you 
may have to do some config/cmake work to figure out what to use and then 
conditionally compile based the result. We do need to look good on 3.10-3.22 
and everything in between. I think complaints about that were one of the 
motivations for the new release plan for 4.x.

Change the Glade files as much as you think appropriate and have time for.

Regards,
John Ralls

> On Jun 16, 2017, at 9:24 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> OK, I have been tapping away with the following progress...
> I downgraded a clone VM to Gtk+3.10.8 which successfully builds and runs
> but I seem to of lost some stock images, not an issue as I can temporary
> replace them
> but I can use it to make sure I have not included any newer functions.
> 
> In the original VM I have built and made some changes which can be seen at My
> GitHub <https://github.com/Bob-IT/gnucash/tree/gtk3>
> I have hopefully done the following but as normal there may be some
> tweaks...
> Replaced RC file with CSS file, name may need changing
> The dense calendar now renders with a white background but can be set with
> CSS
> Changed the way tabs are done and now display correctly and fixed the width
> updates
> Changed most widgets that had a horizontal / vertical function to the new
> equivalents.  These were simple function swaps I had in existing patch file.
> 
> I was going to look at the account edit dialogue but wanted to ask how much
> do you want the glade files changed ?
> Change the version and replace deprecated widgets ?
> 
> There are some further deprecated widgets that I will change if able to as
> I come across them.
> 
> Bob
> 
> On 6 June 2017 at 09:54, Geert Janssens <geert.gnuc...@kobaltwit.be> wrote:
> 
>> On maandag 5 juni 2017 12:19:24 CEST Robert Fewell wrote:
>>> Hi,
>>> 
>>> I was browsing the IRC logs and Geert mentioned his gtk3 branch, yes I
>> have
>>> pulled from there and recently updated my local version which was built
>>> successfully.
>>> I tend not to fiddle where other people are working as I would no doubt
>>> just get in the way or slow down their efforts.
>>> 
>>> If you would like me to look at some thing, just ask and I will have a
>>> look, been looking at some schedule bugs but they can wait...
>>> 
>>> What version of Gtk3 are these changes aimed at, my gtk3 development VM
>> is
>>> on 3.20.9 ?
>> 
>> Hi Bob,
>> 
>> I'm happy you're willing to jump in as well.
>> 
>> As John already mentioned (and you could have read on IRC) I'm currently
>> pretty occupied outside of the gnucash project.
>> 
>> The Gtk3 version to target is 3.10. This is the most recent version on
>> Ubuntu
>> Trusty, which is the base OS for our Travis builds. Any other build
>> platform
>> we care about comes with a more recent version of gtk3.
>> 
>> Feel free to clone my branch and make PR's against it.
>> 
>> So far I've been mostly focused on
>> 1. getting it to build and run (which should be accomplished)
>> 2. Tweak the the register code to make it render properly
>> 
>> For part 1 I needed do replace several Gtk2 functions that have been
>> removed
>> from Gtk3. The code wouldn't build otherwise. I only did minimal changes to
>> get it to run. With that I mean I only replaced removed functions, not
>> deprecated API.
>> 
>> So here are a few opportunities to jump in:
>> - The rendering of the custom calendar in the SX editor is wrong. I think
>> the
>> background isn't rendered, but there may be other things going on there.
>> - Tab titles aren't rendering correctly. They are being rendered as "..."
>> instead of the full (or partially elipsized) text. I suspect this has to do
>> with Gtk3 new paradigm of minimal vs natural width, which we're not
>> handling
>> properly for the tab titles.
>> - There may still be other visual issues I haven't spotted yet. If
>> discovered
>> these should get priority over the next point IMO.
>> - There are lots of deprecated API warnings. Unfortunately Gtk3 has been
>> moving target so there are new deprecations in almost every Gtk3 release. I
>> propose to focus on those function calls which have been deprecated in Gtk3
>> 3.10 or earlier.
>> 
>> I will continue to focus on the register code and will communicate my
>> progress
>> when I get to it.
>> 
>> Regards,
>> 
>> Geert
>> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

Re: Gtk3

[Robert Fewell]

OK, I have been tapping away with the following progress...
I downgraded a clone VM to Gtk+3.10.8 which successfully builds and runs
but I seem to of lost some stock images, not an issue as I can temporary
replace them
 but I can use it to make sure I have not included any newer functions.

In the original VM I have built and made some changes which can be seen at My
GitHub <https://github.com/Bob-IT/gnucash/tree/gtk3>
I have hopefully done the following but as normal there may be some
tweaks...
Replaced RC file with CSS file, name may need changing
The dense calendar now renders with a white background but can be set with
CSS
Changed the way tabs are done and now display correctly and fixed the width
updates
Changed most widgets that had a horizontal / vertical function to the new
equivalents.  These were simple function swaps I had in existing patch file.

I was going to look at the account edit dialogue but wanted to ask how much
do you want the glade files changed ?
Change the version and replace deprecated widgets ?

There are some further deprecated widgets that I will change if able to as
I come across them.

Bob

On 6 June 2017 at 09:54, Geert Janssens <geert.gnuc...@kobaltwit.be> wrote:

> On maandag 5 juni 2017 12:19:24 CEST Robert Fewell wrote:
> > Hi,
> >
> > I was browsing the IRC logs and Geert mentioned his gtk3 branch, yes I
> have
> > pulled from there and recently updated my local version which was built
> > successfully.
> > I tend not to fiddle where other people are working as I would no doubt
> > just get in the way or slow down their efforts.
> >
> > If you would like me to look at some thing, just ask and I will have a
> > look, been looking at some schedule bugs but they can wait...
> >
> > What version of Gtk3 are these changes aimed at, my gtk3 development VM
> is
> > on 3.20.9 ?
>
> Hi Bob,
>
> I'm happy you're willing to jump in as well.
>
> As John already mentioned (and you could have read on IRC) I'm currently
> pretty occupied outside of the gnucash project.
>
> The Gtk3 version to target is 3.10. This is the most recent version on
> Ubuntu
> Trusty, which is the base OS for our Travis builds. Any other build
> platform
> we care about comes with a more recent version of gtk3.
>
> Feel free to clone my branch and make PR's against it.
>
> So far I've been mostly focused on
> 1. getting it to build and run (which should be accomplished)
> 2. Tweak the the register code to make it render properly
>
> For part 1 I needed do replace several Gtk2 functions that have been
> removed
> from Gtk3. The code wouldn't build otherwise. I only did minimal changes to
> get it to run. With that I mean I only replaced removed functions, not
> deprecated API.
>
> So here are a few opportunities to jump in:
> - The rendering of the custom calendar in the SX editor is wrong. I think
> the
> background isn't rendered, but there may be other things going on there.
> - Tab titles aren't rendering correctly. They are being rendered as "..."
> instead of the full (or partially elipsized) text. I suspect this has to do
> with Gtk3 new paradigm of minimal vs natural width, which we're not
> handling
> properly for the tab titles.
> - There may still be other visual issues I haven't spotted yet. If
> discovered
> these should get priority over the next point IMO.
> - There are lots of deprecated API warnings. Unfortunately Gtk3 has been
> moving target so there are new deprecations in almost every Gtk3 release. I
> propose to focus on those function calls which have been deprecated in Gtk3
> 3.10 or earlier.
>
> I will continue to focus on the register code and will communicate my
> progress
> when I get to it.
>
> Regards,
>
> Geert
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3

[Geert Janssens]

On maandag 5 juni 2017 12:19:24 CEST Robert Fewell wrote:
> Hi,
> 
> I was browsing the IRC logs and Geert mentioned his gtk3 branch, yes I have
> pulled from there and recently updated my local version which was built
> successfully.
> I tend not to fiddle where other people are working as I would no doubt
> just get in the way or slow down their efforts.
> 
> If you would like me to look at some thing, just ask and I will have a
> look, been looking at some schedule bugs but they can wait...
> 
> What version of Gtk3 are these changes aimed at, my gtk3 development VM is
> on 3.20.9 ?

Hi Bob,

I'm happy you're willing to jump in as well.

As John already mentioned (and you could have read on IRC) I'm currently 
pretty occupied outside of the gnucash project.

The Gtk3 version to target is 3.10. This is the most recent version on Ubuntu 
Trusty, which is the base OS for our Travis builds. Any other build platform 
we care about comes with a more recent version of gtk3.

Feel free to clone my branch and make PR's against it.

So far I've been mostly focused on
1. getting it to build and run (which should be accomplished)
2. Tweak the the register code to make it render properly

For part 1 I needed do replace several Gtk2 functions that have been removed 
from Gtk3. The code wouldn't build otherwise. I only did minimal changes to 
get it to run. With that I mean I only replaced removed functions, not 
deprecated API.

So here are a few opportunities to jump in:
- The rendering of the custom calendar in the SX editor is wrong. I think the 
background isn't rendered, but there may be other things going on there.
- Tab titles aren't rendering correctly. They are being rendered as "..." 
instead of the full (or partially elipsized) text. I suspect this has to do 
with Gtk3 new paradigm of minimal vs natural width, which we're not handling 
properly for the tab titles.
- There may still be other visual issues I haven't spotted yet. If discovered 
these should get priority over the next point IMO.
- There are lots of deprecated API warnings. Unfortunately Gtk3 has been 
moving target so there are new deprecations in almost every Gtk3 release. I 
propose to focus on those function calls which have been deprecated in Gtk3 
3.10 or earlier.

I will continue to focus on the register code and will communicate my progress 
when I get to it.

Regards,

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

Re: Gtk3

[John Ralls]

> On Jun 5, 2017, at 3:19 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> Hi,
> 
> I was browsing the IRC logs and Geert mentioned his gtk3 branch, yes I have
> pulled from there and recently updated my local version which was built
> successfully.
> I tend not to fiddle where other people are working as I would no doubt
> just get in the way or slow down their efforts.
> 
> If you would like me to look at some thing, just ask and I will have a
> look, been looking at some schedule bugs but they can wait...
> 
> What version of Gtk3 are these changes aimed at, my gtk3 development VM is
> on 3.20.9 ?

I think we're looking at requiring 3.8 or 3.10--whichever introduces css 
theming.

Geert's been pretty busy lately and hasn't touched the branch in 6 weeks, so no 
worries about stepping on him. I'm still struggling with getting the MinGW64 
build to work, so I'm not in the GUI code at all, and we're both going to have 
to shift gears shortly to getting 2.6.17 released.

In that IRC conversation he mentioned a couple of dialogs with layout issues; 
you could start with those or just go through the program looking for places 
where something isn't quite right.

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

Re: gtk3 + webkit

[Bill Nottingham]

John Ralls (jra...@ceridwen.us) said: 
> Geert noted in IRC that
> https://bugzilla.redhat.com/show_bug.cgi?id=1375812 indicates that we need
> to lose the dependency on WebKit1 ASAP, as Fedora intends to drop it from
> distribution in F27.  As Geert notes, WebKit2 is Gtk3-only.  Note, though,
> that on the bug Bill Nottingham suggests that he might flatpack WebKitGtk1
> and request a waiver, and Catanzaro seems to receive that well enough.

In terms of Fedora/EPEL - yes, I'll just bundle in webkitgtk as needed for
2.6.x, and maybe look at flatpak if I get the spare time to do so.

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

Re: gtk3 + webkit

[John Ralls]

> On Feb 2, 2017, at 7:01 AM, Geert Janssens <geert.gnuc...@kobaltwit.be> wrote:
> 
> Bob,
> 
> Thanks for bringing this up.
> 
> While I thought of it, I didn't mention this third option as I didn't feel 
> like maintaining gnome-canvas as part of gnucash.
> 
> As you have done a big chunk of the work we may as well evaluate this avenue 
> anyway, perhaps only as a short term interim solution.
> 
> I'll look at it when I'm ready to take on the Gtk3 work. Note that I have my 
> own local gtk3 branch with several patches to migrate parts over that 
> couldn't 
> be migrated as long as we also supported gtk2.
> 
> I had forgotten to consider our external dependencies. Glad you bring that up.
> 
> * LibOFX is not using gtk at all. It's a non-gui library.
> * Aqbanking depends on Gtk2 indeed via its own dependency on gwenhywfar. I'd 
> need to investigate how difficult it would be to port that to Gtk3.
> * As you suggested goffice will soon be eliminated from our dependency list
> * WebkitGtk2 is Gtk3 only (there's even talk of Gtk4 only soon...). For 
> Win32, 
> we have been building Webkit ourselves from the beginning. From what I've 
> heard it's hard, but both Phill Longstaff and John Ralls have managed this in 
> the past. I assume we will be able to build a newer version ourselves as 
> well. 
> 
> Note that for the Windows build I have been wanting to evaluate Mingw64 for 
> some time now, which does come with a prebuilt version of WebkitGtk2 and 
> several other of our dependencies.The missing ones are isocodes, opensp, 
> libofx, gwenhywfar, ktoblzcheck, aqbanking and dbi. But that's ok, we have 
> been building those ourselves for ages. This experiment will have to wait 
> though until the other priorities have been sorted out.
> 
> Regards,
> 
> Geert
> 
> Op donderdag 2 februari 2017 13:48:32 CET schreef Robert Fewell:
>> Hi,
>> 
>> I was looking at the irc logs and see that gtk3 / webkit upgrade was
>> mentioned and that there were two options mentioned, one was change to some
>> thing like goo-canvas, the other was to complete register2 which I started
>> awhile back and failed to complete.
>> 
>> There is an other option that I came across in planner when I was thinking
>> about trying to convert my attempt to use gtk3 to see if that would solve
>> some issues after I had reverted the later changes. They had incorporated a
>> cut down version of gnome-canvas in there source that works with gtk3 and I
>> decided to give that a go.
>> 
>> If you look at https://github.com/Bob-IT/gnucash/commits/gtk3 you will see
>> that I have added a further reduced version of gnome-canvas along with
>> commits to fix first run compile errors and a converted register using it
>> and cairo.
>> 
>> This uses gtk3, I think a gtk3 version of webkit2 (I get confused about
>> versions), gtk3 version of goffice (this may not be needed with Geerts
>> changes), no aquabanking / ofx as I think that uses gtk2 and there is no
>> gtk3 versions and I believe you can not mix them. To build this you need to
>> disable warnings as errors which should give you a running version of
>> GnuCash with a working register, some things still needed to be changed,
>> namely the size of the drop down arrow on the calendar and to revert some
>> colour changes for testing.
>> 
>> I have made further changes to fix depreciated warnings and glade file
>> changes but I would need to check these against the current master, a lot
>> this was find and replace with gtk3 functions / widgets.
>> 
>> What I have observed is the following..,
>> 
>> Most glade files needed changing to eliminate spaces in the
>> add_builder_from_file line along with changing the depreciated widgets and
>> then realign to match existing layout
>> Gtk stock is depreciated and that changes images / buttons to icon names,
>> to get over this I just removed all images from buttons and to use text
>> only as a start.
>> You need to use inline CSS to achieve bits like the tab colours.
>> 
>> The main thing I could not get my head round was the change in toolbars /
>> menus / accelerator keys. Menu's can not have images on them and the way
>> they are created is totally different.
>> 
>> This was just a look at when I felt like it but may be some thing useful or
>> not worth while. I did have a look to see if I could get this to run on
>> Windows to make sure the changes I made worked but I could only find a gtk3
>> version 3.10.6 and no webkit version but I may not of been looking in the
>> right place.

Geert noted in IRC that https://bugzilla

Re: gtk3 + webkit

[Geert Janssens]

Bob,

Thanks for bringing this up.

While I thought of it, I didn't mention this third option as I didn't feel 
like maintaining gnome-canvas as part of gnucash.

As you have done a big chunk of the work we may as well evaluate this avenue 
anyway, perhaps only as a short term interim solution.

I'll look at it when I'm ready to take on the Gtk3 work. Note that I have my 
own local gtk3 branch with several patches to migrate parts over that couldn't 
be migrated as long as we also supported gtk2.

I had forgotten to consider our external dependencies. Glad you bring that up.

* LibOFX is not using gtk at all. It's a non-gui library.
* Aqbanking depends on Gtk2 indeed via its own dependency on gwenhywfar. I'd 
need to investigate how difficult it would be to port that to Gtk3.
* As you suggested goffice will soon be eliminated from our dependency list
* WebkitGtk2 is Gtk3 only (there's even talk of Gtk4 only soon...). For Win32, 
we have been building Webkit ourselves from the beginning. From what I've 
heard it's hard, but both Phill Longstaff and John Ralls have managed this in 
the past. I assume we will be able to build a newer version ourselves as well. 

Note that for the Windows build I have been wanting to evaluate Mingw64 for 
some time now, which does come with a prebuilt version of WebkitGtk2 and 
several other of our dependencies.The missing ones are isocodes, opensp, 
libofx, gwenhywfar, ktoblzcheck, aqbanking and dbi. But that's ok, we have 
been building those ourselves for ages. This experiment will have to wait 
though until the other priorities have been sorted out.

Regards,

Geert

Op donderdag 2 februari 2017 13:48:32 CET schreef Robert Fewell:
> Hi,
> 
> I was looking at the irc logs and see that gtk3 / webkit upgrade was
> mentioned and that there were two options mentioned, one was change to some
> thing like goo-canvas, the other was to complete register2 which I started
> awhile back and failed to complete.
> 
> There is an other option that I came across in planner when I was thinking
> about trying to convert my attempt to use gtk3 to see if that would solve
> some issues after I had reverted the later changes. They had incorporated a
> cut down version of gnome-canvas in there source that works with gtk3 and I
> decided to give that a go.
> 
> If you look at https://github.com/Bob-IT/gnucash/commits/gtk3 you will see
> that I have added a further reduced version of gnome-canvas along with
> commits to fix first run compile errors and a converted register using it
> and cairo.
> 
> This uses gtk3, I think a gtk3 version of webkit2 (I get confused about
> versions), gtk3 version of goffice (this may not be needed with Geerts
> changes), no aquabanking / ofx as I think that uses gtk2 and there is no
> gtk3 versions and I believe you can not mix them. To build this you need to
> disable warnings as errors which should give you a running version of
> GnuCash with a working register, some things still needed to be changed,
> namely the size of the drop down arrow on the calendar and to revert some
> colour changes for testing.
> 
> I have made further changes to fix depreciated warnings and glade file
> changes but I would need to check these against the current master, a lot
> this was find and replace with gtk3 functions / widgets.
> 
> What I have observed is the following..,
> 
> Most glade files needed changing to eliminate spaces in the
> add_builder_from_file line along with changing the depreciated widgets and
> then realign to match existing layout
> Gtk stock is depreciated and that changes images / buttons to icon names,
> to get over this I just removed all images from buttons and to use text
> only as a start.
> You need to use inline CSS to achieve bits like the tab colours.
> 
> The main thing I could not get my head round was the change in toolbars /
> menus / accelerator keys. Menu's can not have images on them and the way
> they are created is totally different.
> 
> This was just a look at when I felt like it but may be some thing useful or
> not worth while. I did have a look to see if I could get this to run on
> Windows to make sure the changes I made worked but I could only find a gtk3
> version 3.10.6 and no webkit version but I may not of been looking in the
> right place.
> 
> 
> Regards,
> Bob
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


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

gtk3 + webkit

[Robert Fewell]

Hi,

I was looking at the irc logs and see that gtk3 / webkit upgrade was
mentioned and that there were two options mentioned, one was change to some
thing like goo-canvas, the other was to complete register2 which I started
awhile back and failed to complete.

There is an other option that I came across in planner when I was thinking
about trying to convert my attempt to use gtk3 to see if that would solve
some issues after I had reverted the later changes. They had incorporated a
cut down version of gnome-canvas in there source that works with gtk3 and I
decided to give that a go.

If you look at https://github.com/Bob-IT/gnucash/commits/gtk3 you will see
that I have added a further reduced version of gnome-canvas along with
commits to fix first run compile errors and a converted register using it
and cairo.

This uses gtk3, I think a gtk3 version of webkit2 (I get confused about
versions), gtk3 version of goffice (this may not be needed with Geerts
changes), no aquabanking / ofx as I think that uses gtk2 and there is no
gtk3 versions and I believe you can not mix them. To build this you need to
disable warnings as errors which should give you a running version of
GnuCash with a working register, some things still needed to be changed,
namely the size of the drop down arrow on the calendar and to revert some
colour changes for testing.

I have made further changes to fix depreciated warnings and glade file
changes but I would need to check these against the current master, a lot
this was find and replace with gtk3 functions / widgets.

What I have observed is the following..,

Most glade files needed changing to eliminate spaces in the
add_builder_from_file line along with changing the depreciated widgets and
then realign to match existing layout
Gtk stock is depreciated and that changes images / buttons to icon names,
to get over this I just removed all images from buttons and to use text
only as a start.
You need to use inline CSS to achieve bits like the tab colours.

The main thing I could not get my head round was the change in toolbars /
menus / accelerator keys. Menu's can not have images on them and the way
they are created is totally different.

This was just a look at when I felt like it but may be some thing useful or
not worth while. I did have a look to see if I could get this to run on
Windows to make sure the changes I made worked but I could only find a gtk3
version 3.10.6 and no webkit version but I may not of been looking in the
right place.


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

Re: gtk3 and gnucash

[Sriram Ramkrishna]

On Thu, Feb 19, 2015 at 8:00 AM, Geert Janssens
geert.gnuc...@kobaltwit.be wrote:

 That's not completely correct. I intended to investigate MingW64/Msys2 but
 due to lack of time I never got further than superficially looking into it.
 I hoped to continue this at a later time, which so far hasn't happened yet.



 Meanwhile irc user nacho_ posted a few interesting links [1] that may help
 in getting gnucash built under mingw64/Msys2.



We're both on the same IRC server, so feel free to ping nacho with
questions.  Building a momentum will help getting on-par support for
win32 on GTK+.  Which will help other projects as well as yours who
want to continue to use GTK+ on Windows.

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

Re: gtk3 and gnucash

[Sriram Ramkrishna]

On Wed, Feb 18, 2015 at 5:59 PM, John Ralls jra...@ceridwen.us wrote:

 On Feb 18, 2015, at 10:26 AM, Sriram Ramkrishna s...@ramkrishna.me wrote:

 I was doing some searching around and I spotted this thread:

 http://gnucash.1415818.n4.nabble.com/Future-programming-language-td4668935.html

 I was wondering if you were aware of the recent win32 improvements
 that have been made in win32 space?  Paolo and others have done a lot
 of work in this space.

 We would of course love to see a gtk3 port of GNUCash which the GNOME
 Foundation uses to manage its finances as I'm sure a lot of other
 software projects who manage money do as well.

 That's very unlikely any time soon. GnuCash is a bit of a mess, with really 
 bad MVC separation and some poor implementation decisions in the core that 
 contains the business logic. All of that needs to be cleaned up before we can 
 safely migrate to Gtk3.


 OK, thanks for the update!

 As for win32 improvements, no, I haven't seen anything to support that there 
 are any. The latest binaries on www.gtk.org are 3.6, which Tarnyko did 2 
 years ago. There aren't any gtk3 binaries at all on master.gnome.org, only 
 gtk2 ones from 4 years ago. I see a whopping 8 commits this year in gdk/win32.

We are working on doing some improvements.  You can read
Matthias'sblog on the new theme which has support for win32

http://blogs.gnome.org/mclasen/2014/06/13/a-new-default-theme-for-gtk/

is one of many.  So some focus on GTK+ and other platforms.  I
understand that you've worked on an OSX version at some point?


 BTW, after the email exchange that you cited Robert did continue on the 
 GtkTreeView implementation of the register, but he wasn't able to make it 
 stable and gave up. We're still stuck with the 12-year-old implementation 
 based on libgnomecanvas. I'm pretty sure that could be updated to draw 
 directly on a cairo context once someone motivates himself to do it, but 
 there's so much other work that no one has yet taken it on... not that that 
 would move us any closer to Gtk3.

OK, that's unfortunate..


 Please in future address correspondence about GnuCash development to our 
 developer's mailing list rather than to an individual developer.


Will do.  I'll also invite developers to come to GUADEC, as that is
going to be the best place to create relationships and air out some of
the issues.

Thanks for your response, they were helpful.

Kind regards,
Sri Ramkrishna
Director, GNOME Foundation / Engagement Team

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

Re: gtk3 and gnucash

[Paolo Borelli]

Hi John!

I understand from your reply that the win32 port is not your top
priority, but I wanted to point out some things about the current
state of gtk on Windows.

On Thu, Feb 19, 2015 at 2:59 AM, John Ralls jra...@ceridwen.us wrote:
 As for win32 improvements, no, I haven't seen anything to support that there 
 are any. The latest binaries on www.gtk.org are 3.6, which Tarnyko did 2 
 years ago. There aren't any gtk3 binaries at all on master.gnome.org, only 
 gtk2 ones from 4 years ago. I see a whopping 8 commits this year in gdk/win32.


I agree that it is unfortunate that we do not have a proper win32 page
on the site, but I can assure you that the win32 port made huge
progress: most of the fixes are not in the gdk backend which is pretty
self contained, but in individual widgets and underlying libraries. We
are using glib 2.42 gtk 3.14 successfully on Windows.

The lack of standardization on www.gtk.org is also due to the fact
that there are a few different approaches to use gtk on Windows,
depending on your goal and tools:

1) If you are cross compiling, fedora provides updated binaries of the
whole stack and I am pretty sure other distros have similar packages.
The downside of these binaries is that they are built with a runtime
dependencies on the GNU toolchain, so they cannot be used for
interoperability with MSVC

2) MSYS2 has updated binaries and provides a very efficient way to
build your gtk app on windows with mingw.
http://blogs.gnome.org/nacho/2014/08/01/how-to-build-your-gtk-application-on-windows/
has more information and you can see from
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gtk3
that things are kept up to date. Incidentally msys2 provides binary
builds of a lot of other libraries as you can see from that repository
and it is also relatively easy to extract these libraries and use them
with MSVC

3) In case you prefer/need to use MSVC (e.g. you already build your
application with MSVC and you want to be able to easily step into
glib/gtk functions when debugging), we are working on a powershell
script that builds the whole gtk3 stack at
https://github.com/nice-software/gtk-win32 based on the similar script
made by the hexchat developers for gtk2 at
https://hexchat.github.io/gtk-win32/


I hope that helps, and if anyone listening wants to help with the
port, all patches are more than welcome.


Ciao,

 Paolo

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

Re: gtk3 and gnucash

[Geert Janssens]

On Thursday 19 February 2015 07:40:28 John Ralls wrote:
  On Feb 19, 2015, at 12:36 AM, Paolo Borelli
  paolo.bore...@gmail.com wrote:
  
  Hi John!
  
 I understand from your reply that the win32 port is not your top
  
  priority, but I wanted to point out some things about the current
  state of gtk on Windows.
  
  On Thu, Feb 19, 2015 at 2:59 AM, John Ralls jra...@ceridwen.us wrote:
  As for win32 improvements, no, I haven't seen anything to support
  that there are any. The latest binaries on www.gtk.org are 3.6,
  which Tarnyko did 2 years ago. There aren't any gtk3 binaries at
  all on master.gnome.org, only gtk2 ones from 4 years ago. I see a
  whopping 8 commits this year in gdk/win32. 
  I agree that it is unfortunate that we do not have a proper win32
  page on the site, but I can assure you that the win32 port made
  huge progress: most of the fixes are not in the gdk backend which
  is pretty self contained, but in individual widgets and underlying
  libraries. We are using glib 2.42 gtk 3.14 successfully on Windows.
  
  The lack of standardization on www.gtk.org is also due to the fact
  that there are a few different approaches to use gtk on Windows,
  depending on your goal and tools:
  
  1) If you are cross compiling, fedora provides updated binaries of
  the whole stack and I am pretty sure other distros have similar
  packages. The downside of these binaries is that they are built
  with a runtime dependencies on the GNU toolchain, so they cannot be
  used for interoperability with MSVC
  
  2) MSYS2 has updated binaries and provides a very efficient way to
  build your gtk app on windows with mingw.
  http://blogs.gnome.org/nacho/2014/08/01/how-to-build-your-gtk-applic
  ation-on-windows/ has more information and you can see from
  https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gtk3
  that things are kept up to date. Incidentally msys2 provides binary
  builds of a lot of other libraries as you can see from that
  repository and it is also relatively easy to extract these
  libraries and use them with MSVC
  
  3) In case you prefer/need to use MSVC (e.g. you already build your
  application with MSVC and you want to be able to easily step into
  glib/gtk functions when debugging), we are working on a powershell
  script that builds the whole gtk3 stack at
  https://github.com/nice-software/gtk-win32 based on the similar
  script made by the hexchat developers for gtk2 at
  https://hexchat.github.io/gtk-win32/
  
  
  I hope that helps, and if anyone listening wants to help with the
  port, all patches are more than welcome.
 
 Paolo,
 
 Thanks for the update.
 
 As for most cross-platform applications Win32 is the choice of most of
 our users, so it's rather critical that we're able to install or
 build not just Gtk but all of our many other dependencies for Win32.
 Gcc and Gnu make are quite slow on Windows so we prefer to install
 when that's possible. GnuCash uses MinGW/MSys running on Windows for
 its Win32 build environment. Another developer, Geert Janssens, did a
 major rewrite of the build scripts a year ago to update them from
 MinGW-11 to the current version. IIRC he investigated MinGW64/Msys2
 at that time and found that it wasn't suitable, but I don't remember
 why.

That's not completely correct. I intended to investigate MingW64/Msys2 but due 
to lack of time I 
never got further than superficially looking into it. I hoped to continue this 
at a later time, which 
so far hasn't happened yet.

Meanwhile irc user nacho_ posted a few interesting links [1] that may help in 
getting gnucash 
built under mingw64/Msys2.

 Yet another, Christian Stimming, attempted a Fedora
 cross-compile several years ago and wasn't able to get it to work,
 but that's likely been improved in the meantime.
 
 Perhaps this next bit should be discussed on gtk-devel instead of
 here, but if Msys2 is now the preferred source of Gtk win32 binaries
 perhaps the binaries on ftp.gnome.org and www.gtk.org should be
 removed and the www.gtk.org website revised to point to Msys2.
 Indeed, all of what you wrote above should be on the Gtk Windows page
 instead of the apparently outdated information that's there now.
 
I agree it would be most helpful if the primary sources point in the same 
direction...

Regards,

Geert


[1] Start of the conversation is here: 
http://lists.gnucash.org/logs/2015/02/2015-02-19.html#T02:49:54
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gtk3 and gnucash

[John Ralls]

 On Feb 18, 2015, at 10:26 AM, Sriram Ramkrishna s...@ramkrishna.me wrote:
 
 I was doing some searching around and I spotted this thread:
 
 http://gnucash.1415818.n4.nabble.com/Future-programming-language-td4668935.html
 
 I was wondering if you were aware of the recent win32 improvements
 that have been made in win32 space?  Paolo and others have done a lot
 of work in this space.
 
 We would of course love to see a gtk3 port of GNUCash which the GNOME
 Foundation uses to manage its finances as I'm sure a lot of other
 software projects who manage money do as well.

That's very unlikely any time soon. GnuCash is a bit of a mess, with really bad 
MVC separation and some poor implementation decisions in the core that contains 
the business logic. All of that needs to be cleaned up before we can safely 
migrate to Gtk3.

As for win32 improvements, no, I haven't seen anything to support that there 
are any. The latest binaries on www.gtk.org are 3.6, which Tarnyko did 2 years 
ago. There aren't any gtk3 binaries at all on master.gnome.org, only gtk2 ones 
from 4 years ago. I see a whopping 8 commits this year in gdk/win32. 

BTW, after the email exchange that you cited Robert did continue on the 
GtkTreeView implementation of the register, but he wasn't able to make it 
stable and gave up. We're still stuck with the 12-year-old implementation based 
on libgnomecanvas. I'm pretty sure that could be updated to draw directly on a 
cairo context once someone motivates himself to do it, but there's so much 
other work that no one has yet taken it on... not that that would move us any 
closer to Gtk3.

Please in future address correspondence about GnuCash development to our 
developer's mailing list rather than to an individual developer.

Regards,
John Ralls


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

On Gtk3 (was:Re: Gnucash 2.5/6)

[Geert Janssens]

On 08-02-13 16:09, Derek Atkins wrote:

Geert Janssens janssens-ge...@telenet.be writes:


Forgot to mention: Gtk3 was indeed not on the agenda for 2.6. 2.6 is
only meant to be *ready* to be migrated. This means getting rid of all
the deprecated gtk symbols. Other than the register this is done. So
the register rewrite is actually important for this goal, whether we
use the GtkTreeView approach or the libgnome-cairo route.

Personnaly I'd rather see us move to Qt instead of Gtk3 when that
decision has to be made.  My reasoning is that I think the Gtk
developers have lost sight of their target audience, and as a result
keep removing features that are vital.  It's too much of a loose
firehose, and IMHO shouldn't be supported anymore.  Indeed, for my next
desktop re-install I plan to move away from a Gnome desktop and over to
XFCE..
With Gtk3 the Gnome project has chosen a very different course which 
turns out to be very controversial as well. I have both seen people who 
absolutely love it and people who totally can't stand it. My point of 
view? I'm pretty neutral as I don't use it ;) I only used Gnome 2 for a 
while a long time ago, switched to kde then and never returned (this is 
not meant as a kde promo!).


It doesn't look to me they have lost sight of their target audience 
though. I rather think they have deliberately redefined their target 
audience. Inevitable that means some people that used to be targeted no 
longer are and hence don't like the new experience. I think many 
long-time knowledgeable computer users fall into that category. Less 
experienced users seem to like it a lot more.


I'm not here to defend the Gnome project's decisions though. I'm just 
saying whether gtk3 is a good thing or not is rather subjective.


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

Re: On Gtk3 (was:Re: Gnucash 2.5/6)

[John Ralls]

On Feb 12, 2013, at 2:41 AM, Geert Janssens janssens-ge...@telenet.be wrote:

 On 08-02-13 16:09, Derek Atkins wrote:
 Geert Janssens janssens-ge...@telenet.be writes:
 
 Forgot to mention: Gtk3 was indeed not on the agenda for 2.6. 2.6 is
 only meant to be *ready* to be migrated. This means getting rid of all
 the deprecated gtk symbols. Other than the register this is done. So
 the register rewrite is actually important for this goal, whether we
 use the GtkTreeView approach or the libgnome-cairo route.
 Personnaly I'd rather see us move to Qt instead of Gtk3 when that
 decision has to be made.  My reasoning is that I think the Gtk
 developers have lost sight of their target audience, and as a result
 keep removing features that are vital.  It's too much of a loose
 firehose, and IMHO shouldn't be supported anymore.  Indeed, for my next
 desktop re-install I plan to move away from a Gnome desktop and over to
 XFCE..
 With Gtk3 the Gnome project has chosen a very different course which turns 
 out to be very controversial as well. I have both seen people who absolutely 
 love it and people who totally can't stand it. My point of view? I'm pretty 
 neutral as I don't use it ;) I only used Gnome 2 for a while a long time ago, 
 switched to kde then and never returned (this is not meant as a kde promo!).
 
 It doesn't look to me they have lost sight of their target audience though. I 
 rather think they have deliberately redefined their target audience. 
 Inevitable that means some people that used to be targeted no longer are and 
 hence don't like the new experience. I think many long-time knowledgeable 
 computer users fall into that category. Less experienced users seem to like 
 it a lot more.
 
 I'm not here to defend the Gnome project's decisions though. I'm just saying 
 whether gtk3 is a good thing or not is rather subjective.
 

Don't confuse the toolkit with the Gnome Shell. Gtk+ itself hasn't changed that 
much, and many of the changes are about not wrapping services provided by other 
libraries -- like exposing a cairo surface to draw on rather than wrapping it 
with GtkCanvas,
or moving behaviors down to Gio (e.g. menus), I think so that the code can be 
shared with Clutter. Theming is now built in and accomplished with CSS, which 
should be a substantial stability improvement.

A much bigger problem is that since Tor Liliquist dropped out a couple of years 
ago, Win32 support hasn't kept up. There's no pre-built Gtk3 stack available on 
ftp.gnome.org, and there was a recent thread on gtk-devel-list from some Win32 
users complaining that there were patches on bugzilla, widely adopted in the 
wild, that hadn't been applied.

But unless we can recruit some developers to take over where Christian left 
off, we're pretty much stuck with Gtk+.

Regards,
John Ralls


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