After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 778042 - Relatively sized charts don't resize when window is resized
Relatively sized charts don't resize when window is resized
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Reports
git-master
Other All
: Normal normal
: ---
Assigned To: gnucash-reports-maint
gnucash-reports-maint
Depends on:
Blocks:
 
 
Reported: 2017-02-01 18:40 UTC by Geert Janssens
Modified: 2018-06-29 23:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Minimal application with webkit view widget (4.68 KB, application/x-compressed-tar)
2017-02-01 18:40 UTC, Geert Janssens
  Details
Change the way reports are loaded (4.24 KB, patch)
2017-02-20 12:40 UTC, Bob
committed Details | Review
Script changes for jplot reports (7.21 KB, patch)
2017-02-20 12:43 UTC, Bob
committed Details | Review

Description Geert Janssens 2017-02-01 18:40:18 UTC
Created attachment 344733 [details]
Minimal application with webkit view widget

This is a continuation of bug 777875.

Basic issue: current master has a feature to set relative sizes for report charts (in percentage of total window size). The problem is this feature only works partly. Assume a report is opened with the chart width and height set to 100%. Upon initial loading of the report, the chart is not at full window width as it should. That's part 1 of the bug.

Now resizing the window won't resize the chart with it. That's part 2 of the bug.

Both parts are puzzling because a minimalistic test application (attached here) based on gtkwebkit does both without any additional steps needed. The test application does the minimal gtk boilerplate to have a window with scrollbars and a webkit_web_view added to it. No special event handlers or anything fancy added. And yet, when you open this test application, the sample chart is promptly sized to full width (there's a minor sizing error due to the scrollbar, but that's gone with the first window resize). While resizing the chart nicely follows.

So something in the way gnucash is using gtkwebkit causes this to fail. This needs further investigation. The test application may be used to study this furhter and compare with how gnucash does things.

It looks like either javascript is only run once in gnucash and hence window resize events are not triggered. Or the resize events are not emitted for some reason, so javascript just sits there and waits. Or jqplot is ignoring the relative width indications and using hard-coded standard sizes instead. This last has happened before depending on the html doctype being set.

Note: the test application uses cmake (and I used ninja as well, although ordinary make will probably work as well). Here are the steps to build and run it:
- download and untar the file
- cd gnucash_webkit_demo
- mkdir _build && cd _build
- cmake -DCMAKE_INSTALL_PREFIX=../_inst -G Ninja ..
(you may need to install a few extra dependencies for this)
- ninja-build
- ninja-build install
- ../_inst/bin/midori
(the name is still midori, after the project I took this from...)
Comment 1 Geert Janssens 2017-02-01 20:57:19 UTC
Update: I have been reverting several changes and noticed that for newly opened charts all seems to work as it should. Webkit properly takes care of all sizing as needed.

The only issue is with charts that are loaded automatically when a book opens. On all tabs except for the very last one, the charts are not rendered at full (relative) size, but at a fixed width and height. The last tab is rendered properly and I found this is only because loading of the uri's is delayed be using g_idle_add. If uri loading is done directly when creating the report page, even the last page is rendered improperly using fixed sizes for the chart.

Interestingly though whether g_idle_add is used or the uri is loaded directly doesn't affect newly opened reports. They will always render using the full window size (which is the default).

So this strongly points in the direction of size allocations not being finished in the notebook tabs while loading the reports at startup. And hence jqplot chooses a built-in fixed size default for plot size.

So in the end it looks like using g_idle_add is still not really the solution here. Perhaps we could trigger on webkit_web_view's "web-view-ready" signal instead to load the uri ?
Comment 2 Bob 2017-02-20 12:40:56 UTC
Created attachment 346259 [details] [review]
Change the way reports are loaded

With these changes the reports are not created until the page is shown,realized. It still uses the idle add to create the page but it is started from the realized call back. Doing it this way has the added advantage that if the app is closed on a non report page, the next start up is quicker as the reports are not created.

This requires the following patch that changes the jqplot scripts.

I have tested this on the my Gnome VM and Windows 10 with various combinations of report with fixed / percent sizes and have not noticed any thing untoward.
Comment 3 Bob 2017-02-20 12:43:21 UTC
Created attachment 346261 [details] [review]
Script changes for jplot reports

I have added the resize function to all jqplot reports and an on load function to bar and line charts. This last change is required when a table is added to the report and the vertical scroll bar appears and covers part of the plot. This was observed in Gnucash and also when opening the generated file in the gnome browser as well as the test app on this bug.
Comment 4 Geert Janssens 2017-02-21 18:53:49 UTC
Bob, I haven't tested your patches yet. I'll do so somewhere this week.

I'm curious though, did you look into web-view-ready as well ? And if so what made you decide not to connect to this signal ?
Comment 5 Bob 2017-02-26 14:37:27 UTC
Geert,

I looked at that signal but could not remember why I decided not to use it so reverted my changes and had another look. Added a call back to print to console and this signal never fires. After a bit a reading, it looks like this signal is only fired after a create-web-view signal which also does not fire and after further reading I think this is used when you create a new window from the page content.

This was proved by right mousing on a link in the balance sheet report and choosing to open in new window and the above signals fired.

Just for info, on my Gnome2 VM, all saved reports fail to reach correct size when opened at start up despite which one had the focus on close. It is only when there is one report that it is correct.

Added a callback to "load-finished", and the available-width/height are 1 and valid when they fail to load and a reasonable numbers when it works.

Bob
Comment 6 Geert Janssens 2017-03-01 11:33:22 UTC
Bob, thanks for investigating and clarifying this.

Looks my "web-view-ready" inspiration of the moment is a dead end after all.
I believe you are dead on by listening for a realize event.

Other than a redundant call to gtk_wiget_show_all I have no
more comments on your code and have pushed it to master. I
tested it locally and it appears to work as advertised this time.
I see no more flickering when reports are opened/loaded.

Thanks for pursuing this!
Comment 7 John Ralls 2018-06-29 23:53:59 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=778042. Please update any external references or bookmarks.