I’m glad you can see it from a positive angle . Thank you for the explanation, I think I found a way to fix it but it will take some time to do it right. Let’s see if I can do it tomorrow :).
I thought there was maybe a simple modification in a qml file.
In the case I’m the only one and if it is complicated, please don’t loose your precious time! I’ll eiducate my fingers better .
Thank you much for your listen in all cases.
No usefull input. Just a big thank you!
I released version 3.0.0 of Captain’s Log that contains fixes for the issues you mentioned, @ric9k @Seven.of.nine . A remorse timer is now shown after closing the write dialog - tap it to continue editing the new entry.
The release is quite well tested but I recommend to make a backup of you database anyway! (You need both logbook.db
and schema_version
files.)
Most notable changes are the new search page and improved tags. Be sure to check it out .
Also, translations are now hosted on Weblate.
Swedish translation updated.
I still use ‘To Do’ list daily and find it indispensable for managing my daily/weekly/ monthly tasks.
Any chance of implementing some of the easier stuff here?
Synchronization with nextcloud tasks - would that be difficult? It would be awesome and make this great little app even more useful as tasks could be shared across devices. Sadly there is no official Jolla tasks app that does this, so this would be a very worthy replacement.
Awesome, thank you!
That’s awesome, glad to hear it!
I haven’t lost hope that I’ll do that someday, yes, but it’s not the highest priority at the moment - Whisperfish and a few other projects must get some love first. I neglected all my apps a bit during the last year (has it been so long already!?) so it’ll take time. Anywhere between 5 days and 5 years, I guess, sorry
That would be hard, I suppose, but a feature like “regularly copy the database to some folder” would be easier, and then you could sync that folder automatically using another app…
I updated and tried Captain’s log.
Now, it’s just perfect!
Thank you much @ichthyosaurus.
By the way, I also discovered and installed Todo list
About syncing the Todo list, what do you think about such possibility:
- stores the todos in a DB handled by mKCal (you can create such DB yourself using mKCal::SqliteStorage() API, where the second argument is a file path that can point to a place handled by your application and not the default restricted system DB).
- modify a bit Buteo CalDAV sync plugin to be able to call it from your application providing where the Todo DB is (by default, the plugin is looking to sync calendars from the system DB).
Would you approve such changes to your application ? I didn’t look at your code yet, so I’ve no idea how many code changes the DB switch would mean. If you think it’s a viable path, I could provide PRs after working on it, or help you doing so if you prefer to do it yourself.
I think this is a great suggestion for improving an already impressive app!
Well, currently the database is handled completely in JS using QML’s LocalStorage
API. Switching the database to C++ would mean rewriting everything from scratch.
Also, the entries are not so much stored as events bound to specific dates. I don’t know how a calendar-centric database could handle the two special cases “this week” and “sometime in the future” - how could that be synchronised? The app uses “magic” dates for these cases at the moment (→ code).
To be honest: I don’t :S. On the other hand, I want to put in some big changes anyway, so it will end with a complete rewrite in any case. But to me it seems completely overkill and way too much work for very little benefit.
That is, unless mKCal can give me a hand with “recurring” entries, i.e. entries that should be repeated every Xth of the month, every X days/weeks, every Xth weekday, etc. That’s something that would be tedious to implement with the current database.
Anyway, thank you very much for offering to help! I’d recommend that you take a look at the code (→ db, → rest) and decide yourself whether its doable without too much effort. You already know mKCal so it’s easier for you to gauge, I guess.
Thank you @ichthyosaurus for your detailed answer. I agree that moving to an mKCal storage would mean major changes to your code. But that looks like an interesting exercise (for me, I would say). Especially since your code is very well written. I’ll try to swap the Storage JS backend you have with a C++ mKCal one keeping more or less the same API. It will help me also to see if mKCal API is well suited for the job.
Actually, it’s not mKCal that will help you for this, since mKCal is just a disk serialisation for events / todos… Events or todos are themselves handled by KCalendarCore from KDE frameworks. This library is taking care of the recurrences for instance. And when you look at the code expanding recurrences with exceptions, rules… I’m happy I don’t have to deal with it myself thanks to KCalendarCore::OccurrenceIterator
!
I was thinking the same thing as @dcaliste while examining the Tasks | OpenRepos.net — Community Repository System app. That currently has issues with syncing and is designed primarily with nextcloud in mind, but is caldav based. I already use cli clients for calendars and tasks (khal), but recently started using: nextcloud-tasks-api · PyPI all of which has been done in javascript, too, but this might be a simple to add library via python which doesn’t incur the build overhead?
Forgot: this is more terse and also does the job, but I prefer the first one: wrapper nextcloud-tasks/nextcloudtasks.py at main · Sinkmanu/nextcloud-tasks · GitHub
This latter is a single file, so less hassle. EDIT: well, it has two deps: caldav and prettytable
Awesome, then I’m excited to see what you come up with :).
Thank you Let’s hope you don’t find the less-well-written parts soon ;).
Oh nice, thank you for the pointers! I’ll see if and how I can make use of that. I presume SFOS already uses these and they shouldn’t make problems with Harbour? I’ll check the docs once I’m less in a hurry…
Nice, thank you! I’ll see if that can be packaged easily because Python packaging for SFOS is still kind of like dark magic to me. I managed to avoid it until now :).
I’m doing a bunch of python stuff right now (fibonacci updates, Solver calculus app) and I have two approaches:
- on chum, with the help of @nephros, I released some libaries (sympy mpmath) which can be included on that dist. channel.
- For harbour I just package them as follows:
a) unpack the tar.gz files of the release in ${project}/${lib}
b) append libs.path = /usr/share/$${TARGET} && libs.files = lib in .pro
c) INSTALLS += libs
d) In .spec installs post section
cd %{buildroot}%{_datadir}/%{name}/lib/sympy-1.9
python3 setup.py install --root=%{buildroot} --prefix=%{_datadir}/%{name}/
rm -rf %{buildroot}%{_datadir}/%{name}/lib/sympy-1.9
This is a damn slow way of building things, BUT, it get’s you into harbour and does at least mean you know EXACTLY what you get from a library, because, obviously, you’ve read every line of exactly that version
I hope I have some time next week to dedicate to your app. hope, hope. And, as @dcaliste suggested, from all the time I admire your swiss meteo app, you write nice code which I should emulate more
Forgot: the .spec which includes application libraries may need a << marcros section
%define __provides_exclude_from ^%{_datadir}/%{name}/lib/.*\\.so\\>
%define __requires_exclude_from ^%{_datadir}/%{name}/lib/.*\\.so\\>
Some create so files. but not often.
@ichthyosaurus I recognized, that I use more and more of your apps(at last I discovered your Configurable keyboard height patch).
I just wanted to say thank you. Is there a possibility to donate you some beers or coffee?
I think his donations page is visible here: