<div dir="auto">I would like to learn more about the code and help contribute. I have a very demanding job and may not get a lot of time however. <div dir="auto"><br></div><div dir="auto">I am still looking for a real cash flow report. One that follows gaap accounting principals. I think I can get the networth close but am not sure if take everything into account. </div><div dir="auto"><br></div><div dir="auto">Another thing I want to put some time into is the cash flow report on the home screen. It doesn't make a lot of sense to me as it is today. I probably need to stare at it a little longer. </div><div dir="auto"><br></div><div dir="auto">In any case, even if I can't work on the code, I am open to contributing ideas, bouncing ideas around, providing a second pair of eyes, or I can test code updates. FYI, I run kmymoney on both gnome(Wayland) and plasma(xorg). There are differences. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Let me know. </div><div dir="auto"><br></div><div dir="auto">Jesus Varela</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 16, 2020, 7:57 PM Jack <<a href="mailto:ostroffjh@users.sourceforge.net">ostroffjh@users.sourceforge.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">While going through old bugs to find any which can be closed for various <br>
reasons, I found one requesting that report output be made available in <br>
ods format.  While this would be very close to what you get by importing <br>
a csv output into libreoffice calc, it could have actual formulas, and <br>
possibly better formatting.  My initial thoughts were far too <br>
simplistic, but in process of digging into the souce code, I came up <br>
with questions.<br>
<br>
It looks to me like the csv and html output are both handled within the <br>
same functions, and are always both created, no matter which is <br>
requested, and then only the requested format is output. I suppose it <br>
doesn't make too much of a performance difference, but if we do add more <br>
output formats, would it be worth separating them and only producing the <br>
one requested?<br>
<br>
In terms of how to actually approach producing ods files, it seems far <br>
more complex than either csv or html.  An ods (any open document format <br>
file) is a zipped collection of several files, and while most of the <br>
actual content appears to be in a single xml file (I suppose similar is <br>
some ways to the html output) the other files are probably not simply <br>
boiler-plate which can be copied. So - I started looking for any <br>
Framework which might help wtih this. I have not yet looked into how <br>
Calligra does it, but I did find kreports, which seems to be <br>
appropriate, and although at least one description I found calls it a <br>
framework, it is not (yet?) formally a KDE Framework.<br>
<br>
I know this is not a high enough priority to any of the other developers <br>
to be likely to work on it, but I have enough interest to at least make <br>
an attempt.  The only thing to lose is my time. If I did, I would <br>
propose first separating the two current output formats, so adding a <br>
third would be less "invasive" to the existing code.  I would then also <br>
start exploring both Calligra and kreports, to see if either has a <br>
reasonably KDE way of doing this without reinventing the wheel.<br>
<br>
One additional note - I see an early commit by Lukasz related to the <br>
porting of the reports to a plugin, and also pointing out that the <br>
graphical reports are handled differently from textual reports.  I <br>
suppose that's not critical here, but it suggests that the graphical <br>
reports might also eventually be output as odg (open document drawing?) <br>
files.<br>
<br>
Thoughts or comments?<br>
<br>
Jack<br>
<br>
</blockquote></div>