KMyMoney issueshttps://invent.kde.org/office/kmymoney/-/issues2021-06-29T22:18:37Zhttps://invent.kde.org/office/kmymoney/-/issues/17Consider adding an opt-in kuserfeedback telemetry2021-06-29T22:18:37ZDawid WrobelConsider adding an opt-in kuserfeedback telemetryA well-explained explicitly opt-in telemetry with a clear stress on privacy in an open-source software should IMHO be passable in 2020.
https://community.kde.org/Telemetry_Use
https://community.kde.org/Policies/Telemetry_Policy
Someth...A well-explained explicitly opt-in telemetry with a clear stress on privacy in an open-source software should IMHO be passable in 2020.
https://community.kde.org/Telemetry_Use
https://community.kde.org/Policies/Telemetry_Policy
Something to discuss further.Version 2021.xhttps://invent.kde.org/office/kmymoney/-/issues/18New Welcome Page2021-11-23T17:28:52ZDawid WrobelNew Welcome PageThe current Welcome Page (`kwelcomepage.cpp`, `kwelcomepage.h`) is very plain and could be designed to be more compelling, especially that it is the first thing presented to a new user.
This can be made to match the contents of what wou...The current Welcome Page (`kwelcomepage.cpp`, `kwelcomepage.h`) is very plain and could be designed to be more compelling, especially that it is the first thing presented to a new user.
This can be made to match the contents of what would be a revamped, visually-compelling and more concise "Features" page of KMM website.
It should be rewritten using a modern QtQuick/QML, for a future adaptation of the whole UI to Kirgami/Maui.
Related issues:
- new home screen: #16
- supporting dark icons: https://invent.kde.org/office/kmymoney/-/issues/2
- revisiting default colors, adding support for dark theme: https://invent.kde.org/office/kmymoney/-/issues/1Version 2021.xhttps://invent.kde.org/office/kmymoney/-/issues/22Remove welcome tips, replace with contextual tooltips and/or product tour2021-09-27T16:32:27ZDawid WrobelRemove welcome tips, replace with contextual tooltips and/or product tourThe welcome tooltips are very much passé by 2020. They are known to provide little help to the users and dropped by the modern app developers in favor of the contextually aware tooltips or the full-blown onboarding tours.
Some good rea...The welcome tooltips are very much passé by 2020. They are known to provide little help to the users and dropped by the modern app developers in favor of the contextually aware tooltips or the full-blown onboarding tours.
Some good read:
* https://www.appcues.com/blog/tooltips
* https://www.trychameleon.com/blog/why-tooltips-are-terrible-and-why-you-should-use-themVersion 2021.xhttps://invent.kde.org/office/kmymoney/-/issues/25Consider replacing Payee matching with a more robust 'if-this-then-that' work...2021-11-12T14:51:52ZDawid WrobelConsider replacing Payee matching with a more robust 'if-this-then-that' workflow rules engineThe current Payee matching is limited in a way that it only allows to do one thing: assign a default category.
Moreover, one can only assign a default category by matching the Payee only [1].
This is very limited and doesn't allow follo...The current Payee matching is limited in a way that it only allows to do one thing: assign a default category.
Moreover, one can only assign a default category by matching the Payee only [1].
This is very limited and doesn't allow following exemplary scenarios:
* Matching the Payee name *and* the Memo.
- some of my banks' scheduled automatic credit-card payment transfers contain the last 4 digits of card paid to in the Memo field
- I have [previously](https://www.mail-archive.com/kmymoney-devel@kde.org/msg19582.html) brought this up on the -dev mailing-list.
* Matching the account
- I assign "Interest Payment" transactions to different income categories, depending on whether the source account is Checking, Saving, a CD, etc.
* Automatically creating a transaction once another is detected
- I have no way of downloading a breakdown of my salary and contributions, but since it doesn't change month-to-month, I could generate the transactions automatically once the salary transfer is detected
* Assigning a category by matching Payee field but not rewriting the Payee field, which is currently impossible.
* Automatically triggering a warning, e.g.:
- when a positive transaction is added to a specified account that must _only_ have charges
- when upon saving the book, a specified account has a non-zero balance (e.g. a "Resolved temporary charges" account)
By extension, this would also include rewriting of the Scheduling functionality into the engine, since the time passing is naturally one of the triggers. ~~Also, I think it could be made a plugin, not core functionality, effectively reducing the complexity of the importing logic.~~ It would need to be a core functionality, and part of the plugin API.
It's my personal opinion, but I think everyone will agree that this type of workflow is more natural to human brain and is already widely recognizable, used by popular products like [Apple Shortcuts](https://support.apple.com/guide/shortcuts/welcome/ios), [IFTTT](https://ifttt.com), or "Scenes" functionality on any of the smart home platforms (Google Home, SmartThings, Apple Home).
Some existing, commercial finance software also uses this approach, providing a very powerful yet simple to use tool: https://lunchmoney.app/features/rules
[1] OFX importer comes with its own, additional matching mechanism. It can match against both Payee and Memo fields, but the mere fact it has its own mechanism makes it even more confusing.https://invent.kde.org/office/kmymoney/-/issues/26Consider removing support for Finance::Quote2021-02-16T21:36:15ZDawid WrobelConsider removing support for Finance::Quote1. There are several open APIs available that provide quotes and has been doing it for many years now. This wasn't the case when Finance::Quote was popular, and obtaining quotes required scraping website's html. It's a personal opinion, ...1. There are several open APIs available that provide quotes and has been doing it for many years now. This wasn't the case when Finance::Quote was popular, and obtaining quotes required scraping website's html. It's a personal opinion, but I consider Finance::Quote redundant by now.
2. Newbie users get confused by its presence in the Security Wizard right next to `Online Source` drop-down list selector: ![Screen_Shot_2020-06-30_at_1.14.36_PM](/uploads/27a51c57f65729a69d6578a195177936/Screen_Shot_2020-06-30_at_1.14.36_PM.png)
3. It requires manual installation of a Perl distribution + cpan module on macOS platform ([1]) and on Windows, since we don't ship it with the binary package. I don't think any of the popular Linux distributions add it as a default dependency, either.
4. It was reported it doesn't work properly ([macOS](https://bugs.kde.org/show_bug.cgi?id=423709), [linux](https://bugs.kde.org/show_bug.cgi?id=390549) – this one is most likely due to a missing perl module)
5. Adds complexity to the codebase
6. Its development [has mostly stalled](http://finance-quote.sourceforge.net), the maintainers don't respond to patch sign-off requests. From my anecdotal evidence, I tried to add support for Warsaw Stock Exchange quotes a few years back and never got a response.
7. While it provides many backends, I have personally tried to use a few (mainly Fidelity) that didn't work at all, because they were written to scrape the prices from old versions of the websites, when the prices weren't published via APIs.
8. Our built-in quotes support provides support for price only. Finance::Quote can provide many more values than just price, yet we ignore them and parse price only anyway:
```
void WebPriceQuote::slotParseQuote(const QString& _quotedata)
{
(...)
QRegularExpression webIDRegExp(d->m_source.m_webID);
QRegularExpression dateRegExp(d->m_source.m_date);
QRegularExpression priceRegExp(d->m_source.m_price);
(...)
```
9. Interestingly, even our manual says that
> Future currency rate updates will not use Finance::Quote, and
will always use the native retrieval method
[1] while macOS ships with Perl, Apple warns against installing own cpan modules or otherwise modifying it. For that reason, sane developers will use a separate perl distribution provided e.g. by HomeBrew. Moreover, macOS 10.15 no longer ships any of the 3rd party frameworks (python, perl, ruby) it previously provided.https://invent.kde.org/office/kmymoney/-/issues/27Consider switching to SQLite backend as the only storage type2021-11-18T18:06:54ZDawid WrobelConsider switching to SQLite backend as the only storage typeMaintaining 2 separate types (or several, if you count all supported flavors of SQL databases) of storage is an overkill we should not afford due to lack workforce, as well as unnecessary confusion brought on our newbie users.
We alread...Maintaining 2 separate types (or several, if you count all supported flavors of SQL databases) of storage is an overkill we should not afford due to lack workforce, as well as unnecessary confusion brought on our newbie users.
We already have an SqLite3 backend (together with SqlCipher encrypted version of it) that offer several advantages over the XML:
1. Less confusion on the non-technical user end. But even for a techie user having to decide between the two is unnecessary mental overhead. Everyone just wants to use the app, not dig deep into "pros and cons" of each right from the beginning. I understand if both formats were maintained for the sake of transitioning users to a new one, but this status quo has been in place for several years.
1. Simplified Application Development
- No custom code for handling SqLite file is needed
- XML code can be removed
- GnuPG code can be removed, since the SqLite database comes with its own, robust encryption.
1. Single-File Documents
We can allow to attach additional files to transactions and embed them in the database file
1. Accessible Content
- SQLite database file is accessible using commonly available open-source command-line tools - tools that are installed by default on Mac and Linux systems and that are freely available as a self-contained EXE file on Windows.
1. Atomic Transactions
- No danger of corrupting a document just because the power happened to go out at the same instant that a change was being written to disk.
- since SqLite3 is a transactional DB, multiple changes can be grouped together such that either all or none of them occur, and so that the changes can be rolled back if a problem is found prior to commit.
1. Incremental And Continuous Updates
- When writing to an SQLite database file, only those parts of the file that actually change are written out to disk. This makes the writing happen faster and saves wear on SSDs. This is an enormous advantage over our gzipped XML file which requires a rewrite of the entire document in order to change a single byte.
1. Performance
- as mentioned above, the file doesn't have to be rewritten completely when saved.
- faster for raw read and writes, since the file is stored in binary format
- SQLite can dramatically improve start-up times because instead of having to read and parse the entire document into memory. In our case the XML file format is gzipped when stored on the filesystem, but is loaded in memory uncompressed.
- our Home Screen presents some summaries of user's Net Worth etc. `KHomeViewPrivate::showNetWorthGraph` contributes to 36% of the overall startup time, as measured by myself using a profiler. Those summaries are calculated using high-level objects, which could be drastically sped up by a dedicated SQL query. This also applies to all other places where we shows summaries and sums of transactions.
![Screen_Shot_2020-07-02_at_1.45.00_PM](/uploads/3f17eda9fed32d5b1c3034e686a2f647/Screen_Shot_2020-07-02_at_1.45.00_PM.png)
- additionally, an Analyzer and Indexing can be used to further optimize the most common and/or heavy queries.
- enables paging: the app only needs to load as much material as is needed to draw on the currently displayed screen and can discard information from prior screens that is no longer in use. This should be doable with the recently added support for models.
1. Easily Extensible
- As an application grows, new features can be added to an SQLite application file format simply by adding new tables to the schema or by adding new columns to existing tables. We already have support in the code for upgrading the database.
- XML upgrades require rewriting substantial parts of the code, while SQL upgrades require rewriting the data access layer's low-level queries only.
1. Concurrent Use By Multiple Processes
1. Multiple Programming Languages
- some additional scripts can be provided externally, e.g for obfuscation/anonymization
- sqlite access can be exposed via API for plugins to optionally manipulate it directly
(Redacted using https://sqlite.org/appfileformat.html)
The potential advantage of XML is being able to
1. ungzip the file and and inspect/edit the XML by hand
1. ???
The potential disadvantages of supporting other SQL backends:
1. KMyMoney is personal finance software, SqLite is perfectly capable of handling the amount of data it could ever generate
2. Additional amount code to support, especially the SQL migration scripts
3. Not many users can take advantage of it, really just other developers and/or DB admins
4. Increases the size of the binary builds with all of the Qt SQL backends required includedVersion 2021.xhttps://invent.kde.org/office/kmymoney/-/issues/29Revisit the toolbar and status bar2021-06-29T22:17:41ZDawid WrobelRevisit the toolbar and status barThis ideally should be consulted with VDG team and incorporate the results of #17.
- [ ] Toolbar should be used for the most common actions, ideally context-aware.
Current toolbar contains items that aren't the *most frequent* u...This ideally should be consulted with VDG team and incorporate the results of #17.
- [ ] Toolbar should be used for the most common actions, ideally context-aware.
Current toolbar contains items that aren't the *most frequent* use cases:
- a shortcut for system calculator
- adding an account or institution
- printing
They should instead be replaced with ones that are used more frequently (e.g. daily):
- Update all accounts
- New transaction
- etc.
- [ ] The toolbar could include the context-aware search widget, if QT5 allows that. Example from macOS: https://developer.apple.com/design/human-interface-guidelines/macos/fields-and-labels/search-fields/
- [ ] The toolbar actions should dynamically!change, depending on the context, e.g.:
- when in ledger view
- they should include the transactions operations (new, edit, delete, duplicate)
- `Enter` and `Accept` should be handled by the same button
- when in Payee view, the Payee manipulation buttons and search bar could be displayed on the toolbar
![Screen_Shot_2020-10-03_at_12.27.21_PM](/uploads/28981131bf874ae05e010c2a03cd610d/Screen_Shot_2020-10-03_at_12.27.21_PM.png)
- when in Tags view, the Tags manipulation buttons and search bar could be displayed on the toolbar ![Screen_Shot_2020-10-03_at_12.28.33_PM](/uploads/7a28db5e4b1b1cf4f91658743402290c/Screen_Shot_2020-10-03_at_12.28.33_PM.png)
- in Accounts and Institutions views, the search toolbar and expand/collapse buttons should be displayed on the toolbar
- in Schedule view, buttons and search bar could be displayed on the toolbar ![Screen_Shot_2020-10-04_at_2.34.12_PM](/uploads/74b4c4f27a63105b97d9460a778e5a8f/Screen_Shot_2020-10-04_at_2.34.12_PM.png)
- [x] The toolbar should default to the text displayed below the icon or not at all. Current behavior with the text alongside an icon is problematic, given that the icons don't fit the window.
- [ ] The status bar should be removed, per KDE's (or any other modern) HIG: https://hig.kde.org/components/assistance/statusbar.htmlVersion 2021.xhttps://invent.kde.org/office/kmymoney/-/issues/30Revisit handling of the currencies2020-10-05T03:42:30ZDawid WrobelRevisit handling of the currenciesKMyMoney currently maintains a list of hardcoded currencies, which are then added on demand by a user to their .kmm file.
This is confusing and could be streamlined by:
1. Maintaining a complete list of currencies in `MyMoneyFile::ava...KMyMoney currently maintains a list of hardcoded currencies, which are then added on demand by a user to their .kmm file.
This is confusing and could be streamlined by:
1. Maintaining a complete list of currencies in `MyMoneyFile::availableCurrencyList()`
2. Moving the `Tools`->`Currencies` dialog to Preferences and having it display *all* of the currencies available, as pointed above.
3. Making `.kmm` not store any currencies that are provided by default
4. Allowing users to add their own currencies by hand and/or modifying price precision of existing ones. The revised/new currencies would be added to .kmm
5. Obsoleting "Remove unused currencies" function.
Alternatively:
1. Moving a complete list of currencies to KMM configuration file
2. As above
3. As above
4. Allowing users to add their own currencies by hand and/or modifying price precision of existing ones – in which case these get saved to/updated in KMM configuration file
5. As Above
Normally I'd be leaning towards the first solution, since in the "old world" a list of worldwide currencies was finite and their characteristics well defined. However, since the advent of cryptocurrencies, it is no longer feasible to maintain a complete list of them, so in the interest of K.I.S.S, the second option appears better to me.https://invent.kde.org/office/kmymoney/-/issues/37QtWebkit v. QtWebEngine discussion2022-03-14T22:51:02ZJack Ostroffostroffjh@users.sourceforge.netQtWebkit v. QtWebEngine discussionBased on the long term deprecation of QTWebkit and migration to QTWebEngine, I asked on the ArchLinux forums why they were still on the former for both KMM and libAlkimia. https://bbs.archlinux.org/viewtopic.php?id=262028 is a link to t...Based on the long term deprecation of QTWebkit and migration to QTWebEngine, I asked on the ArchLinux forums why they were still on the former for both KMM and libAlkimia. https://bbs.archlinux.org/viewtopic.php?id=262028 is a link to that discussion. Starting point is that they just follow the upstream default - so do we want to switch the default to QTWebengine? For further discussion, and forum thread asks whether we actually need either, or could use something with less bloat. I open this issue per suggestion on IRC.
QtWebKit/QtWebEngine are currently used by:
- check printing plugin
- reports plugin
- reconciliation report
- home view
- LibAlkimiaVersion 2021.xDawid WrobelDawid Wrobelhttps://invent.kde.org/office/kmymoney/-/issues/41Should we revamp versioning scheme?2021-06-29T22:16:48ZDawid WrobelShould we revamp versioning scheme?Right now KMyMoney ties its major version number to the KF5/Qt5 frameworks. I'd argue that most users have no idea what KF5 is and they probably couldn't care less. We had briefly touched the subject before and a point was made that KMyM...Right now KMyMoney ties its major version number to the KF5/Qt5 frameworks. I'd argue that most users have no idea what KF5 is and they probably couldn't care less. We had briefly touched the subject before and a point was made that KMyMoney 6 should be reserved for when Qt6/KF6 arrives.
However, I'd argue that major numbers should be instead reserved for when major new functionality is offered to end user. Something press release worthy. The "undo/redo" functionality already present in the master would be a good example of that. Bumping the version up to 6 only because the underlying frameworks change (which themselves don't bring over much) is not sexy in the eyes of the non-geeky end user.
That having said, bumping to version 6 before KF6/Qt6 arrives could be misleading and an anti-pattern. Therefore I would suggest that we consider switching to [CalVer](https://calver.org)) date based format (21.xx? 21.xx.yy?) when our current master is primed for release.
What do you think?Version 2021.xhttps://invent.kde.org/office/kmymoney/-/issues/47We need an official copy (catchphrase) for KMyMoney2022-11-23T05:05:46ZDawid WrobelWe need an official copy (catchphrase) for KMyMoneyI realized we have a bit of unappealing catchphrase (copy) on our website: "_KMyMoney: A Personal Finance Manager for humans_".
We also have:
- "_Personal finance manager_" as a project description in GitLab
- "_KMyMoney: The best Pers...I realized we have a bit of unappealing catchphrase (copy) on our website: "_KMyMoney: A Personal Finance Manager for humans_".
We also have:
- "_Personal finance manager_" as a project description in GitLab
- "_KMyMoney: The best Personal Finance Manager for free users_", also on kmymoney.org, which shows on the browser's tab
None of them sell KMM well, not properly explaining its free (both as in beer and in speech) nature, nor the fact that it is a standalone app, which I personally am sure most still prefer over storing their personal data in the cloud, feeding the commercial Big Data appetite. Not to mention the recent "Gatekeep your privacy" trend/movement, which e.g. Apple seems to be marketing really well.
So I am thinking of something along:
- _Your finances, only yours_
- _Your personal finances – only yours_https://invent.kde.org/office/kmymoney/-/issues/49Preparation for port to Qt62022-09-13T14:54:20ZThomas BaumgartPreparation for port to Qt6We can easily prepare a port to Qt6 with the following changes:
**Mandatory**:
- [x] Port source code to Qt 5.15
- [x] don't use deprecated Qt features (as of 5.15).
- [x] Add `add_compile_definitions(QT_DISABLE_DEPRECATED_BEFORE=0x050...We can easily prepare a port to Qt6 with the following changes:
**Mandatory**:
- [x] Port source code to Qt 5.15
- [x] don't use deprecated Qt features (as of 5.15).
- [x] Add `add_compile_definitions(QT_DISABLE_DEPRECATED_BEFORE=0x050f00)` to CMakeLists.txt to make sure we don't fall back
- [x] Replace all occurrences of QRegExp with QRegularExpression
A bit of care might be necessary, as the syntax changes slightly between the two.
Information about the difference can be found in the [Qt documentation](https://doc.qt.io/qt-5/qregularexpression.html#notes-for-qregexp-users) \
all done (the remaining are inside comments)
- [x] Replace all occurrences of QStringRef with QStringView
Not sure if we use QStringRef at all \
5 of 5 done
- [x] Remove KWebView code, rely on QWebEngineView only _(is this one still needed now that we use QTextBrowser?)_ \
Note that QWebEngine won't be available in Qt6 until 6.2 release: https://wiki.qt.io/New_Features_in_Qt_6.2, which is to be released sometime in September 2021. EDIT: the same link shows that QtWebView is also getting ported to qt6.2, but ideally we'd want to rely on QWebEngine anyway: https://invent.kde.org/office/kmymoney/-/issues/37
- [ ] Update the wiki, amend all the mentions of Qt and Qt5 and add special instructions for handling master (Qt6)
- [x] Port QXmlSimpleReader to QXmlStreamReader
- [x] Port QXmlSimpleWriter to QXmlStreamWriter
- [x] Replace QFontMetrics::width() with QFontMetrics::horizontalAdvance()
- [x] Eliminate usage of QString::sprintf()
- [x] Use version-less Qt cmake targets
- [x] Build with QT_NO_KEYWORDS
- [ ] Investigate usage of Gwenhywfar and potential other libs that depend on Qt
- [ ] More can be added here
**Optional**:
- [ ] Port away from Q_FOREACH/foreach
- [ ] Replace all QHash with std::unordered_map
- [ ] Replace all QSet with std::unordered_set
- [ ] More can be added hereVersion 2021.xAlexander LohnauAlexander Lohnauhttps://invent.kde.org/office/kmymoney/-/issues/56Should we change the way we approach minimum Qt/KF5 requirements?2022-04-24T17:51:03ZDawid WrobelShould we change the way we approach minimum Qt/KF5 requirements?Right now we "floor" the [Qt5/KF5 requirements](https://invent.kde.org/office/kmymoney/-/wikis/Build-environment#dependencies-list-and-minimal-versions-required) based on what popular distros deliver.
This is really only for developers...Right now we "floor" the [Qt5/KF5 requirements](https://invent.kde.org/office/kmymoney/-/wikis/Build-environment#dependencies-list-and-minimal-versions-required) based on what popular distros deliver.
This is really only for developers' convenience, for them to be able to use repository packages without having to compile any dependency from scratch. The actual binary packaging by distributions is mostly unaffected, since:
1. they traditionally rarely back-port new software versions into the released distros – and if they do, they update their dependencies, too.
2. we offer AppImage anyway, and hopefully FlatPak soon.
That having said, "flooring" the version for developers' sake has many disadvantages:
1. we end up with a lot of conditional blocks that intend to support old and new versions of Qt/KF5
2. we are slow to update the code that has been obsoleted upstream
3. since devs use older version of dependencies, not much testing is done with *newer* ones, which upcoming distros use, as well as binary packages (AppImage, macOS DMG, Windows MSI)
3. major changes to the code may be difficult to be made backwards compatible at all, see e.g. !122
4. we are slow to take advantage of API improvements upstream, which in turn can benefit end users with features or us with simplified code and/or dev env
5. not all distros provide sources for the dep packages, which make it difficult to debug and understand issues related to Qt5/KF5 code itself.
What I'd like to suggest, instead, is that we:
1. default to current up-to-date KF5/Qt5
2. with KF5/Qt in vcpkg, we can ask that developers use vcpkg to compile dependencies
3. , or that they do that themselves
4. , or that they use a docker image (that would provide a ready-made dev env with all required dependencies)
4. , or that they use the bleeding edge KDE's own packaging repositories with up-to-date KF5/Qt packages. This, however, may require setting up separate dev env to avoid messing up with their daily driver machines.