+TITLE: qDoList a QML based todo-list manager.

• The what and the Why.

A holiday project of a physicist, trying not to forget how to write programs in C++.

The code quality leaves much to be desired, and most of what I did has a hacky feel to it. However the program is thoroughly tested, so it could be used as a daily driver.

It's a todo list manager. When it's in a finished (post-alpha) state, I expect it to be the same thing to Todoist, as KeepassX is to LastPass.

• List of Features
  • [X] Tasks can be moved
  • [X] up and down within the same model
  • [X] promoted and de-moted across models
  • [X] This is accomplished using the keyboard
  • [X] Or the convenient dragHandles provided on the left
  • [X] Multiple todo lists can be, [5/5]
  • [X] loaded
  • [X] Saved
  • [X] Automatically synced to disk
  • [X] And re-loaded when a file changes on disk
  • [X] Viewed from a nice sidebar that goes away for small windows.
  • [-] Todo lists are stored in [2/7]
  • [X] Plain text Json
  • [X] Binary Json
    • [X] It turned out that this format offered little advantage over human Readable JSON, and definitely worse than ORG.
  • [ ] Org mode.
  • [-] Stripped out of C-like comments [1/3]
    • [X] They can be loaded,
    • [ ] Tracked
    • [ ] And synced back.
  • [ ] Stripped out of shell-like comments [0/2]
    • [ ] loading
    • [ ] syncing
  • [ ] Stripped out of Haskell Source code
  • [ ] Todoist lists.
  • [-] Has a command-driven interface. [5/6]
  • [X] There's a command-line on the bottom
  • [X] It can add normal level tasks.
  • [-] It can parse natural language e.g.
    • [X] "by tomorrow" or "next week"
    • [ ] Also things like "monday" "tuesday" etc.
    • [X] You can also add a scheduled date,
    • [X] if a date is specified in a plaintext form e.g. 3/20, it's first assumed to be month/day/year and only then the other way around.
    • [X] In English
    • [-] In Russian (the translations are there but don't load)
  • [X] Additional subtasks can be added by putting them inside curly braces and splitting with commas.
  • [X] Same can be done by putting comma separated subtasks after a colon.
  • [X] a "+" asks the manager to find the closest match from all open tasks.
    • [X] if there's a unique match at the top level the task is marked.
  • [X] The recently opened files are saved persistently across sessions
• Install ** From source Disclaimer, This is not recommended, and is not the way you should be installing the program in general. But this is a holiday project to build a portfolio, and compiles relatively quickly, so go right ahead.

I intend to create appropriate packages, but they're not ready at this stage.

+begin_src bash

git clone https://github.com/appetrosyan/qDoList.git

+end_src

Next enter the qDoList directoty, and run

+begin_src bash

qmake && make

+end_src

Which in turn should create the executable. Put it in /bin or /usr/bin, give it permissions and use to your heart's content. ** On ArchLinux The PKGBUILD is provided in the repository, so

+begin_src bash

makepkg -si

+end_src

*** AUR Install using an AUR helper of your choosing (yay, aura etc.)

e.g.

+begin_src bash

yay -S qdolist

+end_src

or

+begin_src bash

pacaur -S qdolist

+end_src

*** Known non-feature.

I still haven't designed an icon, and the .desktop file simply doesn't exist. I'm working on it.

** On Mac OS X.

It builds and runs on OS X. In fact, after the recent update there's no disadvantage in building on any platform. If Qt supports it, then the program runs on it.

** Android

Builds and runs, but has some functional deficiencies. I'm workin on it.

** IOS

Builds runs and no functional deficiencies. It misses an icon, and the file selection dialog is ... unsightly. There's also the lock-in issue. Currently, the only way of installing on IOS is through an apple developer account: I haven't published it on the App Store.

** Windows

Works as intended. Still looks like a smartphone app.

• License.

This program is licensed as GPLv3.

This means that you can take it. You can modify it, but you need to let me know what changes you've made, and commit them upstream.

• The educational value of this project

I've created gui application in Java, C++ using many toolkits, C# and HTML.

What I've found is the following: QML compares negatively to every one of them.

** The pros:

• bindings are a convenient feature
• the language is built from the ground up to accommodate UI design.
• Animations and states allow for truly interesting designs, that are easily put together.

** Cons:

• Looks /ugly/ unless you do a lot of tinkering.

• The design tools are useless.

  • They crash every five +minutes+ seconds.
  • KDevelop doens't interpret the QML very well.
  • Surprisingly, QtCreator is even worse at that.

• The linters

  • Do not detect an issue when its there.
  • Detect an issue when it isn't
  • Do not provide basic help with JavaScript.

• C++ interfacing is ... it's shit.

  • Widgets were directly accessible without any translations, and can be put together from .ui files.
  • Every C++ type had simple and understandable semantics, the interface was purely declarative, while the backend handled all of the logic.
  • Signals sent from UI elements were the ONLY and non-redundant way of interfacing with C++.

• Front-Back communication is redundant and inefficient.

  • Sending a signal from QML. It's slow, you need to have MOC, and most of the time there's no type checking.
  • Invoking a method directly from QML. you need to have an ugly global variable, but so far it's the simplest. The only thing is that the function needs to be declared a slot, MOC'd and there's no type checking.
  • Reading and writing to QML properties from C++. It's like the ugly global variable approach... only worse. It also defeats the purpose of having QML.

• Compare that with the simple approach of widgets.

  • Every widget had an object name, it was accessible with its type, and had signals.
  • You could have connected sophisticated signals that sent data to sophisticated slots. (e.g. sent data)
  • With C++11 support, you could have type-checked compile time function reference signal/slot connections.

• It's an interpreted language.

  • With QtQuick controls 2, you cannot have a C++ widget embedded in QML.
  • In theory every controls element can be implemented in C++. However since object aggregation cannot be done the same way, you cannot actually compile a widget, it's always interpreted.
  • Things are slow. Sure they did GPU offloading, but surprisingly the program is slower. What's the point of using it?

• It's not providing a Native Look and Feel.

  • The widgets are gone, and QQC2 is not bringing them back.
  • Things on Linux need to be painfully adjusted to fall in line with the surrounding applications.
  • On Mac OS X, QML implements so few of the API's that the application doens't even attempt to look normal.
  • Sometimes lack of native integration breaks workflow, e.g. no native menubar support made my BetterTouchTool setup redundant

• It has no identity of its own.

• The C++ debugging tools are useless.

• There are no QML debugging tools.

  • Since it's an interpreted language, most errors require a recompile to be found.
  • Since it's in early adoption,

• Donating.

At this point, there's no reason to donate, however, if you decide that you want to help, here's a few options.

For Russian residents this might be easier.

[[Yandex.Wallet][https://money.yandex.ru/to/410016490055091]]

Or PayPal: a-p-petrosyan@yandex.ru either works