[lipstick] enablers for devicelock pass code age

[rainisto]

devicelock encryption plugin is introducing new return values (exit 2 and exit 3) for special cases like lockcode is found in history file (stores xx values that config key states) and for lockcode has expired (older than xx days). This change changes boolean call to return int (but keeping the interoperability with for example jolla-home package with the kludge in lines 201-203).

[giucam]

Can't it return an enum instead of a generic int with no defined meaning?

[rainisto]

This is called from qml which doesn't have support for enum's as such. So I need to use int in qml side anyways. I tought that it might be clearer to have int also in c++ side.

And its also more future proof, so if devicelock encryption plugin introduces new return value, then I wouldnt have to create new pull request to lipstick.

But yes with enum's c++ side might be a bit more readable.

[giucam]

This is called from qml which doesn't have support for enum's as such

What do you mean? You can have enums in QML.

[rainisto]

Please tell more? http://qt-project.org/doc/qt-5/qml-enumeration.html#using-the-enumeration-type-in-qml at least states that enums are vars or ints.

[giucam]

Mmh.. ok, but i was thinking that you could still define an enum with the values returned by the plugin.

[pvuorela]

Concur that it would be nice having some named values instead of magic numbers somewhere. This could be the place since it's already swapping return codes 0 and 1.

[rainisto]

Sure if it makes code more readable I can add named values. I'll make an update to pull request tomorrow or so.

[rainisto]

Added enum.

[faenil]

still using "return 0" though :)

[rainisto]

well yes still using return value trickery, because I dont want to lock people out of their devices who using Jolla devel when they update lipstick only. But enum should now 'ducument' the current possible return values from the plugin.

[giucam]

What do you mean? Failed is 0, so returning that, or using it to compare it against a value is safe.
I gather checkValue and setValue are meant to be called from QML too, right? If so, i'd declare Q_ENUMS(ReturnValue).

[rainisto]

Q_ENUMS(ReturnValue) is already declared in line 33 in .h file. It is returning failed as 0 to QML. (Binary itself returns 1 on failed and 0 on success).

Ah sorry my crosseyes didnt notice return 0 lines... fixing.

[rainisto]

Now should be better.

[giucam]

LGTM

[rainisto]

Updated pull request with qmlRegisterUncreatableType so that Q_ENUM is also exported in qml side so for example jolla-home can access enum values.

[giucam]

Is the LIPSTICK_EXPORT necessary for the qmlRegisterUncreatableType call?

[rainisto]

Yes, without the export there was undefined symbol when trying to use the library.

[giucam]

Ok, looks good.

[thp]

If you change the enum, so that OK is 0 and Failed is 1, you don't need do have that thing here, and can just say return process.exitCode();

[special]

Please don't - that would mean if (!runPlugin(...)) { /* plugin returned success */ }, which seems more error-prone.

[special]

..although, since there are positive error codes that also mean failure now, you might be right.

[rainisto]

current enum order is there because of keeping compatibility with jolla-home and settings-system. That way people don't get locked out of their devices if they only update lipstick and somehow forget to update jolla-home and settings-system at the same time. (as those projects have hard coded in some places that OK == 1), so it would be safer to keep compatibility and gradually create pull request to switch hardcoded values to use the enum.

And anyways this pull request is currently on hold as devicelock rewrite study might change the way how the pass code age is handled.

[thp]

I guess this is on hold for now, keeping it open?