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.
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. 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. 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. Let me know. Jesus Varela On Tue, Jun 16, 2020, 7:57 PM Jack <ostrof...@users.sourceforge.net> wrote: > While going through old bugs to find any which can be closed for various > reasons, I found one requesting that report output be made available in > ods format. While this would be very close to what you get by importing > a csv output into libreoffice calc, it could have actual formulas, and > possibly better formatting. My initial thoughts were far too > simplistic, but in process of digging into the souce code, I came up > with questions. > > It looks to me like the csv and html output are both handled within the > same functions, and are always both created, no matter which is > requested, and then only the requested format is output. I suppose it > doesn't make too much of a performance difference, but if we do add more > output formats, would it be worth separating them and only producing the > one requested? > > In terms of how to actually approach producing ods files, it seems far > more complex than either csv or html. An ods (any open document format > file) is a zipped collection of several files, and while most of the > actual content appears to be in a single xml file (I suppose similar is > some ways to the html output) the other files are probably not simply > boiler-plate which can be copied. So - I started looking for any > Framework which might help wtih this. I have not yet looked into how > Calligra does it, but I did find kreports, which seems to be > appropriate, and although at least one description I found calls it a > framework, it is not (yet?) formally a KDE Framework. > > I know this is not a high enough priority to any of the other developers > to be likely to work on it, but I have enough interest to at least make > an attempt. The only thing to lose is my time. If I did, I would > propose first separating the two current output formats, so adding a > third would be less "invasive" to the existing code. I would then also > start exploring both Calligra and kreports, to see if either has a > reasonably KDE way of doing this without reinventing the wheel. > > One additional note - I see an early commit by Lukasz related to the > porting of the reports to a plugin, and also pointing out that the > graphical reports are handled differently from textual reports. I > suppose that's not critical here, but it suggests that the graphical > reports might also eventually be output as odg (open document drawing?) > files. > > Thoughts or comments? > > Jack > >
