Fava Desktop

[johannesjh]

I published a GTK application that wraps fava's web GUI. I am currently using flatpak to create an installable app bundle.
EDIT: I renamed the project to favagtk and moved it to https://gitlab.gnome.org/johannesjh/favagtk/

Feedback welcome, I'd be interested to hear your opinions.

Screenshot:

Note: I'd be willing to move fava-desktop into the beancount github group. I just don't feel it is mature enough yet, I probably should first use it for a while and learn from that. Hopefully others will join.

Some questions / considerations:

• Is the name ok for you? Is fava-desktop too ambitious since an electron version also exists?

• Should I keep vendoring the fava dependency by cloning fava using git?

  • Alternatively, it would be simpler if you could release the current master branch of fava as a new version of fava. Then Fava-Desktop could simply depend on it using pip/poetry.
  • Another option would be that Fava-Desktop could depend on Fava using a pip reference to a git commit. But this would likely require to overwrite fava's setup.py's build command in order to trigger the frontend build when fava is installed from sources. See end of this article How To Add Custom Build Steps and Commands To setup.py. If I currently use poetry to depend on fava's git repo, then fava's frontend build is not triggered and fava is broken.

PS Feel free to close this ticket. I opened it as a way of contacting you to kindly ask for your attention and feedback, thank you!

[johannesjh]

I would like to be able to declare a dependency from fava_desktop to fava's git sources like this in fava_desktop's pyproject.toml file:

[tool.poetry.dependencies]
fava = { git = "https://github.com/beancount/fava.git", branch="master" }

The above way of declaring a dependency on fava is currently broken because fava's setup.py does not trigger the frontend build when building fava. @yagebu I would be glad if you could consider pull request https://github.com/beancount/fava/pull/1213 which fixes this issue, thank you!

[yagebu]

Hey, this looks nice, I tried installing it, but unfortunately the installation failed (it seems due to poetry trying and failing to install exact package versions). I'll open an issue.

Is the name ok for you? Is fava-desktop too ambitious since an electron version also exists?

There's no Electron version anymore so I don't see that as a problem. However, I think the name would be a bit too ambitious if it ends up only being usable on Linux. When this has matured and there's some way to get it running on all platforms, then I think the name would be quite fitting :)

I would like to be able to declare a dependency from fava_desktop to fava's git sources like this in fava_desktop's pyproject.toml file

I don't really want to enable depending on Fava's development branches, so I think waiting for the next release and vendoring until then is better.

[yagebu]

@johannesjh I'll make a new release after #1218 is merged or this weekend in any case. You only need to depend on the dev version right now due to the missing support of web components in Webkit, right?

[johannesjh]

thank you very much.

yes, that is true. I only need to depend on the dev version because of https://github.com/beancount/fava/issues/1189

[johannesjh]

Update: I renamed fava-desktop to fava-gtk to better reflect the scope of this project. See https://github.com/johannesjh/fava-gtk

[JaneSmith]

This looks fantastic! I've been watching Beancount and Fava for years now, and always hoped a proper Flatpak package would be put together some day. Any chance you could get this up on Flathub for easier installation?

[johannesjh]

thank you, glad you like it.

I won't upload to flathub just yet because the project is very young and still rather immature. This means I am starting rather slowly, hoping to first gather personal experience as well as feedback from the dev community. I also would like to add some unit tests and automate the build process. Then I can upload ci-builds from a master or release branch to flathub.

I did upload a flatpak package to the releases https://github.com/johannesjh/fava-gtk/releases to make it easy to give it a spin.

[Zburatorul]

@johannesjh, is there any reason to expect that wrapping the rendering in a GUI would make the UI more responsive?

[johannesjh]

I see no reason to expect that.

All responsiveness of fava's GUI is implemented as part of fava using web technology, i.e., using CSS code that takes varying media sizes into account. The GTK wrapper does not add any more responsiveness.

[johannesjh]

Quick update: I have, in the meantime, ported favagtk to GTK4 and packaged it using flatpak. I would like to publish the app on flathub.

@yagebu and @aumayr I would like to ask you as upstream maintainers of fava, do you consent with fava being published on flathub as part of the favagtk app? Details about favagtk can be seen in the pull request to publish favagtk on flathub as well as on favagtk's project page.

[JaneSmith]

I would be very happy to see this on Flathub. I've been using the Flatpak package since it was previously posted about in February 2021, but due to the manual packaging method I didn't realise there have been any updates to it since then.

[yagebu]

@johannesjh: Sure, sounds good, thanks for asking :) Is there some automatism in place to get favagtk updated on updates to its dependencies?

[johannesjh]

ok great!, thank you! here it is: https://flathub.org/apps/details/org.gnome.gitlab.johannesjh.favagtk

Is there some automatism in place to get favagtk updated on updates to its dependencies?

not automated yet. It would certainly be nice to automate this.

to provide some background: in retrospective, the combination of python and flatpak was very tricky and time-consuming to set up. not so much regarding fava and beancount - these were easy. but some packages that smart_importer depends on, specifically scikit-learn and numpy, are difficult to install from source because of their many compile-time dependencies. installing from source is strongly preferred in the flathub community.

favagtk's dependency management consists of the following steps, most of which are automated in a makefile:

1. manual declaration of direct dependencies: these are declared in text files, e.g., requirements/*.in for main application dependencies. there are only very few direct dependencies..
2. automatic updating and freezing of transitive python dependencies. In the makefile, I am using pip-compile to generate requirements/*.txt files with frozen package versions for all direct and transitive dependencies.
3. automatic generation of flatpak build modules aka manifests. In the makefile, I am using using flatpak-pip-generator to generate requirements/*.json build modules from the frozen dependencies. these modules are used in the flatpak build.

to automate the dependency management, a CI-job could check for package updates at regular intervals and submit a pull request. proper tooling for this probably exists already:

• in the python ecosystem, to check requirement files for updates
• in the flatpak ecosystem, there is flatpak-external-data-checker

...it will need some more research and a prototype to set these things up

[johannesjh]

update... I added automated python dependency updates using a CI pipeline that is run at a weekly interval. The pipeline runs pip-compile to update python dependencies, pushes the changes and submits a merge request. technical details are documented in favagtk's MR !8.