Offline support

[Tatsh]

Save a persistent queue until network connectivity is regained.

[Tatsh]

It appears ~/.wakatime.db is an extremely simple SQLite database that QSql can probably connect to for writing records. http://qt-project.org/doc/qt-4.8/qsql.html

$ sqlite ~/.wakatime.db '.schema'
CREATE TABLE action (
            file text,
            time real,
            project text,
            language text,
            lines integer,
            branch text,
            is_write integer,
            plugin text);

[Alan Hamlett]

Offline support is already implemented in https://github.com/wakatime/wakatime, so let's use that instead of re-implementing. We can either include that package somehow or download it from github after kate-wakatime is installed. Then the plugin becomes much simpler and only needs to send the abs path of the current file to that python program and we also get offline support, syntax language detection, etc.

[Tatsh]

I am okay with doing that. However, I would still like to use the mode (language) as detected by Katepart as I think it is more accurate and less generic. If ->mode().length() == 0 then do not pass a language argument to the Python script and let it do the language detection.

If you decide to start this, generally use the KDE classes of Qt things, like in this case KProcess: http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKProcess.html

Doing things this way should hopefully keep the project close-to-ready for KDE 5, instead of worrying about breaking changes in Qt 5.

I think a separate issue can be made about how the package gets installed. On Gentoo and MacPorts my preference would be that wakatime become system installed (managed by Portage and Port, respectively) or just be in $PATH. emerge kate-wakatime would pull in both the Python package as a runtime dependency and the plugin. So really, all the code has to do is determine wakatime from $PATH (this could be the default behaviour). For Gentoo, this is normal. Perhaps even for others including MacPorts. On checking the plugin on, the detection could be done, and if the binary is not found, we can alert the user and tell them to install it, or have a button to install it that basically does what the Xcode plugin installer script does.

Issue #5 is about making a configuration dialog. Although this is mostly for specifying the API key, I can put fields to specify the Python application path and where the Wakatime package lives (for example if it is in a separate virtualenv). If it is safe, this information can be stored in ~/.wakatime.cfg under a new section and QSettings class can continue reading/writing this file (instead of creating another file).

[Tatsh]

@alanhamlett I have created the variant you spoke of. It runs Wakatime (where wakatime must be in PATH; no Windows support).

I have not yet created a way to specify the location of python (Python 2 I presume), and a place to specify where the wakatime is. But mostly this is because on any *nix system wakatime can be in PATH and executed that way rather than having to prefix the python.

Needs more work, but I would appreciate your thoughts on the change. This is largely based on how the Xcode plugin works, but I am watching over the task that launches because I want to make sure never to have more than one wakatime process running.

[Alan Hamlett]

I would still like to use the mode (language) as detected by Katepart as I think it is more accurate and less generic

I agree, it's best to use Kate's language detection and only use wakatime's language detection (via Pygments library) if Kate doesn't specify a language.