Retirement of timekpr-revived, Timekpr-nExT is coming very soon...

Written for Timekpr-nExT by Eduards Bezverhijs on 2019-04-02

Timekpr-nExT development (at least initial set of features) is finally finished and timekpr-revived will not get any updates or bug fixes.
It was a long and bumpy road for me to get Timekpr to the state it's in now, it was quite time consuming. I started it at about in the middle of last year, now it seems to be working just fine :)

This announcement will be a little about development and stuff and while beta testers are finding last minute bugs, I'll post another announcement with detailed description of features of Timekpr-nExT.

-----------------------------------------------------------

If You care about this project, want to contribute a little or just want to help me, soon repository will be public and You could help adding features / testing / translating, or if You don't do that daily / don't have time, there's an option to help me with PayPal: https://tinyurl.com/yc9x85v2 . That would be highly appreciated. Thanks.

-----------------------------------------------------------

Let's start with why I even started this. The thing was that timekpr-revived has quite some shortcomings, exactly as every software does :) It was good for years it existed, but dealing with it and explaining the child all little annoyances and/or strange behavior gave me a little boost to start a better version of something similar.

I had a plans to extend that to a little more than it currently is, but due to lack of interest from anyone, I didn't do that. You can read my announcements about that in announcement section of timekpr-revived.

-----------------------------------------------------------

So the main shortcomings of old timekpr-revived.

One of the thing that gave indeterministic behavior was that timekpr was a “little” desynchronized between daemon and client application, they both read configuration and control files in their own time interval and therefore a user / child was not exactly sure when the time ends. This was influenced with the rate polling interval in timekpr, but in the end for the user, there was a message "session will be ended in about 2 minutes", which was pretty much true, it could end after 15 secs or 1 minute and 37 secs. It was, in fact, a distraction for my user, which would like to see precise time when session ends.

Another thing was that I could not add more than one time interval per day. One might have it's own reasons why that is a good idea, but mine was that in case my user's day sometimes starts at 10:00, so then he could wake up and play a little say from 7:30 to 9:30 and after school + after he has done his homework, he could start playing again from 18:00 - 22:15.

Another thing was that old timekpr used PAM heavily, which is not a bad thing by itself, but that gave users (my user as well) a bit of headache because when account was locked, it just showed "incorrect username or password" error, but everyone expected "this account is locked" which is not exactly how account lock works in linux. So people got frustrated, my user too. There were a config file updates to alter display manager config file, PAM config files etc. which is invasive, but served its purpose.

There were a lack of features, like user could not work past midnight w/o being kicked out, no sleep support, no inactive session time accounting, no time or month allowance, no precise of time accounting etc.

-----------------------------------------------------------

The improvement over timekpr-revived is called Timekpr-nExT.

Before I even started, I laid out a plan to eliminate all of the main shortcomings of older version and started to test how to implement what I had planned.

There were some interesting things, like when I just tested whether features will work, on Ubuntu 14.04 everything worked fine, but more at more completed stage when development went further, it just segfaulted for no apparent reason. So, since 14.04 was going to be EOLed soon, I just dropped idea of supporting it.

At start I wanted to support consolekit and login1 (systemd). After looking around, I decided to support just login1, most of the distros use systemd nowadays, so supporting ck does not make much sense. It should rather easy to support it, but currently implementation files are just empty.

Timekpr uses login1 (systemd) for manager for all interactions, for user list, session list, etc. One of those things are session termination, Timekpr-nExT is asking login1 (systemd) manager to terminate user session, but sometimes on some distros with some login managers it results in black screen which actually means that TTY is switched away from one which drives the graphical display. Graphical display is on TTY7 (ctrl+alt+f7) for older installations like 16.04 and TTY1 for newer ones. Maybe this has smth to do with console not-switching. In case it happens, one can return to correct one by pressing ctrl+alt+fx where x is TTY where login manager is on. I hope users won't be heavily affected by this.

Another interesting thing was how to determine whether session is idle. There are two things which I found I could use to determine whether session is idle: IdleHint and State.
When it works properly (16.04 + Unity and most of Gnome3 on any distro), State shows whether session is active, that means session is focused, for example desktop or console is shown, when one switches away, session state changes to online, which means it’s active, but not focused. IdleHint is means whether session is idle, eg. no-one is doing nothing in the session which basically means it’s locked.
For some reason KDE5 (for example) never set IdleHint to 1, thus session is not considered idle at any time. I even tried to force monitor off via xset, it didn’t work. Sorry KDE5 and other affected users. Maybe it’s time to file a bug :)

Interestingly, sometimes, even in 16.04, I have performance problems getting D-BUS objects, they are stuck for some 10-20 minutes for some reason I don’t know. Sometimes it happens, sometimes not, but calls eventually succeed. I’m trying to cache all objects which are somewhat permanent over the user sessions, so this should not be a major issue. I haven’t seen this behavior in 18.04 or later, though.

There were strange things with Glade as well.

I developed everything on 16.04 and it works flawlessly on it, 18.04 + Gnome3 works as well, including inactive session determination.
Beta testers on 18.04 Gnome3 + ArchLinux on KDE5 and Gnome3 says it’s working fine.

Anyhow, this was really quite a lot to do and I don’t plan to write more on how development went with all little strange thingies which differ from one installation to other, from one DE to other, etc.

-----------------------------------------------------------

I'll address feature descriptions in next announcement, which will happen in about the time Timekpr-nExT is released which will happen pretty soon.

Updated on 2019-04-10.

Read all announcements