Marty's typepad

Introducing Kasa - The personal finance tracker for the hashtag era

Kasa - The personal finance tracker for the hashtag era. Randomized testing data displayed.

It's that time of the year again when daylight is only seen from office windows and the darkness of evenings comes way too early. Getting much more home time, I wanted to finally get a better overview of my spending. Fortunately we live in the age of apps - you need something? There's an app for it. I searched for some of that do-it-all-for-you apps, but privacy was my primary concern. Pretty much all the popular personal finance apps take your financial data and upload it to some server to crunch it. I find that completely unnecessary. It's just a bunch of numbers, why does it need to live on a remote machine where I have zero control over it and zero control over who has access to what I spend my money on? All I want is to get the transactions file from my bank every week, throw it at some app, put some tags on things and see where my money goes. Simple enough to not require any fancy servers right?

So I turned my search into the open source ranks as I know there are some popular apps like KMyMoney or GnuCash. I tried all of them and I wasn't happy with any of them. KMyMoney and Skrooge, the duo from KDE Applications suite, are swiss-army knives that I personally find hard to navigate for my simple needs. Skrooge especially - after the import it generates a dashboard with 22 random sized widgets in no particular order. It felt so overwhelming and intimidating that I knew it's not for me and I had to close it immediately (sorry Skrooge). GnuCash takes 7 seconds to load for whatever reason and I couldn't figure out how to categorize transactions, which is the most important feature to me. Then there's HomeBank. This one came closest to what I was looking for but it was missing some features that I wanted, one of which is showing the actual amounts for tags. Also the categorization feels needlessly complicated. I feel like all the pieces are there, they're just not put together the way I wanted.

At the same time I was really missing coding in Qt. My last two years have been only Android Java and if you've ever worked in that, you know how frustrating it can get at times. Very, if you've never worked with it. Although it's helped a lot by Android Studio, which is just the best IDE I've ever used. Anywho, so there I was, wishing to do some C++/Qt again on long winter evenings without an app I wanted. So I just started coding - cause how hard can it be?™

Enter Kasa

It's a very simple app - you throw an OFX file at it, it stores all the transactions from it in local database, you put tags on them and then you profit. Nothing more, nothing less. For now. The functionality at this point is extremely basic, it's pretty much just a glorified spreadsheet, but already covers lots of my needs.

So what can you actually do? You can (multi-)tag and edit transactions. The tags are then put into a pie chart which shows you exactly where your money goes, tag by tag. You can explore your transactions by tags. You can also set custom date range for the data that it's showing, this way you can immediately get a report for last 7 days, last 17 days, last 7 months, fully up to you.

Here be dragons

Kasa right now is lightyears away from something I'd consider releasing into production. It's pre-pre-pre-alpha, but it's good enough to put it out there and get some extra eyes and hands on it. At this point it needs both code and design. Mainly design. Please get in touch if this sounds interesting to you and you'd like to contribute!

What's next

The main thing I'm working on right now is to provide much better tagging experience, including bulk tagging, tags auto-complete and easy tag removal. After that I'm going to add a setting where you can define your statement period and it will default the date range to that on start (and it will auto-advance each month too). Then it's in serious need of error handling. Right now it's virtually non-existent, it always assumes valid OFX file and so on. This will be crucial. Another thing I want to work on is multi-accounts support. While the database is already set up for that, the rest of the app isn't really; right now I'm mostly focusing on my single credit-card account use case. Next, I want to have some budgeting options per tags and then track how the budget is doing. Eg. set 100/month for eating out, how much was already spent and how much is left? Etc.

Get it (the code)

The app is all open source and you can get it and build it from here. All you need is Qt 5 (including QtCharts), CMake and libOfx.

Potentially FAQ:

What does "Kasa" mean?

The word means "cash register" in Czech. I started with it only as a codeword for the project but then it kinda stuck. I may still rename it somewhere down the line.

Is/Will Kasa be for me?

My ultimate end goal for this project is to be a good personal finance tracker - not manager. I simply want this app to show where the money goes each week/month/quarter based on bank provided files (with manual input later as well). If you want/need anything beyond that, stick with the existing apps like KMyMoney, Skrooge, GnuCash or HomeBank, they're much better suited for that.

Why not help improve existing apps?

I did consider it of course but there are couple reasons - my time for this is extremely limited. All the existing apps are pretty big and I wanted to spend my limited time on actually writing Qt code rather than trying to understand the existing codebases and then try to change those to what I wanted to have. I just wanted to code something and I wanted to scratch my itch. So I just put those two together.

QML/Kirigami?

Yes please! At this point I'm focusing on the data layer and business logic and I wanted the UI to remain as simple as possible for that, for which QWidgets are good enough. But at some point I definitely want to write a QML UI for this. QItemDelegates are....not so great :) Patches welcome!

When will this be ready for regular use?

I have no dates set. It's just a hobby project to refresh my C++/Qt knowledge and I work on it every now and then. Who knows, maybe it will never see an actual release. But if you wanna help, code or design, be sure to let me know!

That said, happy 2019!

New maintainers wanted: KDE Telepathy, KAccounts, Plasma Notifications and others

As I got a new job unrelated to KDE couple months ago, I'm finding myself having less and less time and motivation to keep up with my maintainer's duties. Therefore I think it's time to pass on some of the KDE things that have my name in the "maintainer" field.

First off, there's the whole notifications stack, which includes KNotifications framework, the fdo notifications server and finally Plasma's popup notifications. The whole stack is relatively simple and does not require much attention, but it could use some forward pushing to not be stuck in 2009 anymore.

Staying in the Plasma land, I'd really like to hand the whole clock + calendar stack to a dedicated maintainer. This is the bottom-right part of the default Plasma panel - the clock applet, the calendar applet, the backend for these applets, calendar events, proper timezones support and all the pieces around.  These things can get quite complex to grasp and improve, yet are a crucial part of the desktop experience and deserve much more attention than they get now.

KAccounts, the system to set up your online accounts, could use some much needed improvements and expansions as well as integrating with the new Akonadi/Sink/Kube-thing. If the last part will not happen, and it certainly doesn't look like it will, I'm afraid that KAccounts in Plasma would no longer serve its purpose and would become a burden rather than a useful system component.

The last one and the biggest one - the 12 repos of KDE Telepathy. Now this project is effectively dead. It hasn't seen any real development for more than a year and basically is just on life support ever since the core team had to leave the project because of job and life constraints. The other factor is also the wide spread of mobile phones and mobile IM clients; chatting on the desktop in not entirely modern interfaces with limited protocol support is not as popular these days. But it would still be nice to have someone at least oversee the couple of incoming patches every now and then.

I think that at least the first two stacks are totally vital for Plasma desktop and really need some attention. If you'd like to put your name on any of the things above, please let me know. I'll make sure to do a proper hand-off with explaining everything :)

Full emojis support for your KDE/Qt applications

So in the past month I've devoted my weekends to get proper emojis support ready for KDE software. Thanks to our fantastic KEmoticons framework, all the heavy lifting is already done, we just needed a theme and utilize the theme.

I've came across this awesome open source set called Emoji One, which features over 1600 emojis and is ready to be used with CC BY 4.0 license. I've created a KEmoticons theme out of the last released set, supporting both the :ascii: notation as well as the unicode symbols which were gladly contributed by David Gil Oliva. This theme of course supports the good old emoticons too :)

And today I'm happy to announce that all is merged in now and will be released with next KDE Frameworks release.

Using it is very simple, if your app is already using KEmoticons, you can just set the EmojiOne theme explicitly and profit. If your app is not yet using KEmoticons, using is as simple as these three lines of code:

KEmoticons *kemoticons = new KEmoticons();
emojiTheme = kemoticons->theme("EmojiOne");
QString textWithEmojis = emojiTheme.parseEmoticons("Your text :poop:");

Additionally, if you want your emojis to be in a specific size, you can now newly apply a size constraint by doing this:

kemoticons->setPreferredEmoticonSize(QSize(16, 16));

...before you call parseEmoticons(..) and your parsed emojis will be in size 16x16 pixels.

What's next?

Emojis parser is nice, but how about input? Right now I have set of QML-with-C++ goodness that provides an enhanced auto-height-resizing TextArea that features emojis autocompletion, emojis rendered inline and a custom plain-text converter to give you back the plain text with the emojis in :ascii: format (with some tweaking it can return the unicode character easily).

Inline emojis with autocompletion

One other thing I have ready is nicely pre-ordered QAbstractListModel-subclass that can be used in popups to allow users to input emojis with mouse.

These extras are not yet ready to be released though, still some issues left to iron out. I think I'll end up bundling all these into its own package and release it standalone. They will require only KEmoticons, Qt and QtQuick.

Qt-only?

Currently the emojis come in KEmoticons framework, which is very flexible and provides tons of features, like support for installing custom themes that you can bundle with your app. All those features unfortunately come with some additional dependencies, but I believe we can cut these down to a single tier-1 dependency. I'll probably look into slimming KEmoticons down in my free time, but if you're interested in using this in your Qt-only app, please let me know and I'll prioritize it.

 

KWallet5 can be auto-unlocked during login again

I've just pushed a patch to KWallet5 allowing you to have your wallet unlocked automagically during login. This patch was originally done by Alex Fiestas for KWallet4, so all credits and free beers go to him; I've merely just forward-ported it.

You'll also require kde:kwallet-pam repo and pass "-DKWALLET5=1" to cmake. This will generate pam_kwallet5.so which then can be coinstalled with the same module for KWallet4 (plus it also enables some ifdef'd code inside the module). If you're still using some KDE4/Qt4 software which is using KWallet4, you will require both modules present.

How to set up kwallet-pam can be found over at Luca's blog (though he said he'll update it for KWallet5 later, so you may want to wait a bit :).

Plasma 5 with KDE Telepathy 0.9

While every effort in KDE Telepathy went to the Qt5/KDE Frameworks 5 porting and KAccounts migration, there are still distros/users that have KDE Telepathy 0.9 (the kde4 one) running in Plasma 5 session. All the applications of KDE Telepathy work just fine, the only problem are the Plasma applets, those are totally incompatible.

So for those cases I've created a small Plasma 5 applet which works with KDE Telepathy 0.9. It can bring your accounts online or offline or open the contact list and accounts settings, just as you're used to and the only dependency is TelepathyQt5. However because of changes in Plasma 5 stuff, it's not perfect.

Every applet in Plasma's systray now must have a full popup-on-click by design. This is in direct contrast with Plasma from kde4 times where applet could be just an icon. This hinders the effect of bringing the contact list up upon simply clicking the applet; now it will open a popup with a button inside. There are two solutions to this though. As middle-mouse button click can still be handled however we want, I've added opening the contact list window to middle-mouse button click too. Or you can just put the applet on the panel, there it will work just fine and you can't tell the difference.

Which applet is which?

 

I've also considered having the icon simply be a KStatusNotifierItem, but that brings more problems than it solves, namely something needs to create and manage it, which would mean new process or new kded4 module and all this complexity was not really worth it, given this is supposed to be a sort of short-time transition crutch only. But other than that small issue, everything works just the same as its newer brother.

The new applet from 15.04 release then features a quick contact list in the popup with a search field so you don't even need to open the full contact list, but you still can either by middle-mouse clicking or from the context menu.

The new KDE Telepathy applet in 15.04

I don't intend to work on the legacy applet anymore, but if you wish to extend it, you can either get it from kde:scratch/mklapetek/ktp-legacy-presence-applet.git or download the tarball from KDE mirrors (there will be version 1.1 released the same date as KDE Applications 15.04).

Facebook Chat in KDE Telepathy is in death bed

As you may or may not have heard, Facebook is deprecating the XMPP gateway for its Chat service by the end of April. That effectively means that no 3rd party applications will be able to send messages to your Facebook contacts. At least not officially.

Why oh whyyy?

Probably money. Facebook needs to generate some income in order to stay alive. They do that (not only) by selling ads of all kinds. I'd argue that Chat is one of the most used Facebook features and so Facebook is loosing tons of $s if people don't use their own ad-powered products. Seeing every other big player turning away from XMPP, this was also just a matter of time (and in fact this was known exactly for a year).

So...KDE Telepathy?

KDE Telepathy uses the same Telepathy backend as Empathy and possibly other clients, I would assume that starting 30th April, you simply won't be able to connect with any Telepathy client or in fact any client at all. So please don't report that as bugs :) The upcoming KDE Telepathy 15.04 version will not even ship with Facebook account being offered to be created.

Soo....hackers?!

At this point, any kind of chatting is as accessible as the Tower of London back in the days; Facebook made pretty good effort to make this as impossible as possible. For example it's impossible to even retrieve a full list of your friends from the API, only those that are actively using the same app as you (which in my case is about 4% of people). Without contacts you cannot send messages obviously sooo....that's a dead end. Personally I wouldn't hold any hopes for chatting on Facebook outside of Facebook (including Messenger).

Is this an early April Fools joke??

Nope. Read the red box at https://developers.facebook.com/docs/chat

What am I gonna do with my life now???

Basically, enjoy the last month of Facebook with KDE Telepathy, have your friends switched to some better service and hold an optional minute of silence in remembering.

Farewell Facebook Chat.

KDE Telepathy joins KDE Applications release bundle as fully ported to Plasma 5

In the past couple months I've been busy porting KDE Telepathy project over to Qt5 and KDE Frameworks 5. I'm happy to announce that the ports have been completed and after about a month of testing, KDE Telepathy was moved to join the KDE Application releases with the nearest release being the 15.04 one. This should ensure more regular releases with new version every 4 months.

KDE Telepathy stayed moreless the same in the UIs, but lots of things have changed under the hood. First of all KDE Telepathy will now adopt the KDE Applications versioning scheme, meaning that the next release and first Qt5/KF5 based will be version 15.04. There's only little sense in maintaining different internal versions, that just makes things unnecessarily complicated.

Very important change is the switch to an account management infrastructure based on the Accounts SSO project, which is used eg. in Ubuntu's Unity (as well as on the Ubuntu Phone) and in a form also in Gnome or ElementaryOS. The KDE's project integrating Accounts SSO carries the name KAccounts and is now the new way to set up and configure your KDE Telepathy accounts. This will be part of KDE Applications 15.04 release.

KAccounts does have a simple migration of your current KDE Telepathy accounts into KAccounts, it just cannot migrate your passwords, therefore when you first try to connect, you will get prompts for passwords to your accounts, just put them in and tick "Save password" and your password will now be stored with KAccounts. If you're not already using some daily builds of KDE Telepathy with KAccounts, I'd advise to wait with upgrading till beta 2 as I'm working on couple improvements to the migration step.

Next big~ish change is within the metacontacts/contact aggregation framework KPeople. It used to depend on kdepimlibs but after revising some things, the dependency was dropped and KPeople is now fully self-contained framework, transitively meaning no more kdepimlibs dependency for KDE Telepathy.

Both of these transitions were quite complex and so there might be bugs. Please take the opportunity of KDE Applications 15.04 betas and test if everything works to your standards and please report any bugs you encounter at bugs.kde.org product Telepathy or KAccounts or KPeople, so that we may fix them before the final release.

The 15.04 release unfortunately will not feature the calling component of KDE Telepathy, the Call UI. The team is simply undermanned and nobody particularly understands the whole Telepathy calling stack. Therefore it's now left out of releases until it finds a new maintainer who can take care of it and bring it to the standards of the rest of KDE Telepathy suite.

There will be one more KDE Telepathy 0.9 (kdelibs4 based) release, featuring updated translations and couple improvements to the Call UI, after that only critical security fixes will be released for the 0.9 line and all focus will go to the Qt5/KF5 versions.

The Christmas break project - autocompletion of KDE projects for kdesrc-build

kdesrc-build is an awesome tool used a lot around KDE - basically it's an automated build script to which you can just throw any git url and it downloads, configures, builds and installs the project for you. All that plus nice logging features on top. You can read some more over at Jeremy Whiting's recent blogpost.

What I missed for long long time is to have KDE projects autocomplete-able within kdesrc-build so that I don't have to guess or type the exact project names every time. Because on each run kdesrc-build downloads the kde_projects.xml file, the projects database is all there, ready to be used.

So I finally sat down and wrote a simple (and probably all wrong) bash autocompletion script. Now you can just type "kdesrc-build [tab][tab]" and have a list of all KDE projects \o/

As bash scripting is not my cup of coffee, I've put it in a wiki so that people more skilled can easily improve or extend it as they see fit (it would be great if it could autocomplete also the modules you have set in your rc file). I'll leave it to mature there for a bit and then I'd like to move it to the Techbase pages about kdesrc-build. For now it's using xml2 to parse the xml file, so be sure to have that installed.

Get it & edit here: https://community.kde.org/Scratchpad/kdesrc-build-autocompletion

UPDATE: From Ivan Čukić - "A really hackish way for the same thing in zsh: http://marc.info/?t=138943682400001&r=1&w=2"

Clock-to-color wallpaper plugin for Plasma5

Today I came across this interesting idea - http://whatcolourisit.scn9a.org/ - basically it puts the current time as the background color. You really need to see it in action ;)

So I thought - hey, this could be a cool Plasma wallpaper. Yep. And so 10 minutes later, I made it so :)

You can download this zip directly and install like this:

$ plasmapkg2 -t wallpaperplugin -i clocktocolor_wallpaper.zip

 

Looks pretty neat :)

 

Oh and...

Facebook library in KF5: coming soon!

Today I started porting KDE's own fully asynchronous library which talks to Facebook - LibKFbAPI - to Qt5 and Frameworks 5, which should bring back the Facebook Akonadi resource for Akonadi-Qt5 and make it available for Plasma 5, including Facebook Contacts, Facebook Events, Facebook Posts and Facebook Notifications (displayed as regular desktop notifications).

So far the library can connect to Facebook using KAccount's data (more about KAccounts next week) and retrieve logged-in user info.

I expect the port to go quite quickly and the Facebook Akonadi resource should follow up shortly. I'm considering making KFbAPI part of the KDE Frameworks collection, but as it uses some (possibly unnecessary) kdepimlibs bits, it might wait a bit for that to split up and join Frameworks too.

That is all.