[WIP] add session lock support

[PaideiaDilemma]

This is a first proposal for session-lock in hyprtoolkit.

It is intended for hyprlock to be implemented on top of it.

This version here has almost everything that should be needed.

TODOS:

• resolve the FIXME tags (handling of finished event, dispatch of outputAdded)
• button clicks are not working

[PaideiaDilemma]

• user needs to be aware of the finished event

[PaideiaDilemma]

Ok so just to keep track of things, here are the problems I encountered when trying to implement hyprlocks password input field.
Rest of the widgets (Label, Background, Shape) are no problem.

• hyprlock uses scissor to cut the fading dots. I can't replicate that with hyprtoolkit
• CTextElement does have alpha in it's builder, but it doesn't seem to have an effect.
• hyprlock will need to have it's own AnimationManager. We need to integrate that into the event loop so that it ticks for each frame. I don't think we can do this yet.
• hyprlock currently has gradient support for password input field borders. I guess I will keep the code for that, but we would need to support gradients in CRectangleElement to get feature parity.

[vaxerski]

hyprlock uses scissor to cut the fading dots. I can't replicate that with hyprtoolkit

There is an element prop for that it's just not exposed. I'm fine with exposing it (containsChildren clipChildren or something liek that)

CTextElement does have alpha in it's builder, but it doesn't seem to have an effect.

Simple fix

hyprlock will need to have it's own AnimationManager. We need to integrate that into the event loop so that it ticks for each frame. I don't think we can do this yet.

Why not? You can add an event fd to the loop. See pwcenter it uses pw_loop's fd.

hyprlock currently has gradient support for password input field borders. I guess I will keep the code for that, but we would need to support gradients in CRectangleElement to get feature parity.

Yes, shaders have that feature already as I copied them from HL. Just needs an impl in the C++ part.

I'd say get session lock to work in this MR, we'll merge it, then deal with those four issues in subsequent MRs.

Is the lock part gtg?

[PaideiaDilemma]

All of that sounds nice. Thanks!
I had a bit of a conniption with the eventloop. ofc we can add an fd for it.

Lock part needed the denied event. Now I think it would be gtg.

[vaxerski]

xoxo

[vaxerski]

This kinda sucks. I'd rather you'd make some lock state controller.

ILockState that you can get from the backend if you have a lockscreen, and will return nullptr if you dont.

This would play nicely with making Lock Surfaces -> you can only make them once you obtain the lockstate.

std::expected<SP<ILockState>, eLockError> createSystemLock();

[vaxerski]

this could be moved to the ILockState mentioned above

[vaxerski]

no {} max

[vaxerski]

optional WP makes no sense, just return nullptr on fail

[vaxerski]

who forgor to initialize a primitive