Slab - An Immediate Mode GUI Library In Lua

[yetneverdone]

This issue is identified for long time. I've already posted about it and proposed some sollution, but based on event processing. It can be found here.

In fact, it's not a "bug". It's rather inavoidable result of chosen approavh, based on state only, without processing direct input events.

I think the solution to this was already addressed and PR'ed by megagrump which is now in the `master` and `v1.0.0` branches

Nope. AFAIK, there is no change in this matter in both branches for now... I want to be wrong, however.

Feel free to make PR It would be easier if we can compare the performance of the current `master` branch and your changes

[pirogronian]

I think the solution to this was already addressed and PR'ed by megagrump which is now in the `master` and `v1.0.0` branches

Nope. AFAIK, there is no change in this matter in both branches for now... I want to be wrong, however.

Feel free to make PR It would be easier if we can compare the performance of the current `master` branch and your changes

It's not matter of performance but responsiveness and reliability. And it would mean deep architectural cganfes, as Slab by its design rely on updated state, and events needs some kind of callbacks or message queue. It's something completely different from immediate mode GUI Slab is. So, it would be hard...

[yetneverdone]

Well, we can also compare responsiveness. I just want to make sure it will not take too much garbage

[pirogronian]

Oh so this is indeed a bug. I also notice this on my quite large game but didnt realize it til now.

This issue is identified for long time. I've already posted about it and proposed some sollution, but based on event processing. It can be found here.

In fact, it's not a "bug". It's rather inavoidable result of chosen approavh, based on state only, without processing direct input events.

I think the solution to this was already addressed and PR'ed by megagrump which is now in the `master` and `v1.0.0` branches

Oj, I found the commit that addresses it, but dont understand, how it works without forwarding events from Love... @Grump, could you explain it?

[yetneverdone]

This issue is identified for long time. I've already posted about it and proposed some sollution, but based on event processing. It can be found here.

In fact, it's not a "bug". It's rather inavoidable result of chosen approavh, based on state only, without processing direct input events.

I think the solution to this was already addressed and PR'ed by megagrump which is now in the `master` and `v1.0.0` branches

Oj, I found the commit that addresses it, but dont understand, how it works without forwarding events from Love... @Grump, could you explain it?

Here are related info in the repo from megagrump

https://github.com/flamendless/Slab/pull/107
https://github.com/flamendless/Slab/issues/102

[pgimeno]

From the code patch, it appears that events were dropped because the table was iterated in forwards order, not in backwards order. It also appears that the events were treated as a stack, not a queue.

[pirogronian]

I think the solution to this was already addressed and PR'ed by megagrump which is now in the `master` and `v1.0.0` branches

Oj, I found the commit that addresses it, but dont understand, how it works without forwarding events from Love... @Grump, could you explain it?

Here are related info in the repo from megagrump

https://github.com/flamendless/Slab/pull/107
https://github.com/flamendless/Slab/issues/102

I have finally found the code and way Slab handles events. It's by overriding handlers directly. To me, it's very bad idea, as I may wish to handle events as well. But Slab takes everything for itself. I strongly recommend to enable forwarding funtions instead of overriding handlers.

[yetneverdone]

Oj, I found the commit that addresses it, but dont understand, how it works without forwarding events from Love... @Grump, could you explain it?

Here are related info in the repo from megagrump

https://github.com/flamendless/Slab/pull/107
https://github.com/flamendless/Slab/issues/102

I have finally found the code and way Slab handles events. It's by overriding handlers directly. To me, it's very bad idea, as I may wish to handle events as well. But Slab takes everything for itself. I strongly recommend to enable forwarding funtions instead of overriding handlers.

PRs are welcome for the proposed changes

[pirogronian]

I have finally found the code and way Slab handles events. It's by overriding handlers directly. To me, it's very bad idea, as I may wish to handle events as well. But Slab takes everything for itself. I strongly recommend to enable forwarding funtions instead of overriding handlers.

PRs are welcome for the proposed changes

Ok, my another realisation: Slab actually calls all previously defined handlers by itself. It works with statically defined callbacks, but I'm unsure about other side effects of such a behaviour. Maybe it should be mentioned in documentation to avoid accidental and surprising misbehaviour if user will manipulate with callbacks more dynamically.

[zazabar]

Hey, great lib!

I am trying to figure out how to "consume" the input from the slab ui, so that when the user mouse clicks on the ui it will not call game logic related to mouse click.

example:
1. ui button
2. click on the ui button
3. have gameplay logic on love.mousepressed

ps:
I've dontInterceptEventHandlers = true and the whole code is:

Code: Select all

function love.mousepressed(x, y, button, istouch, presses)
    Slab.OnMousePressed(x, y, button, istouch, presses) -- how do I know that this was actually performed over a window?
    -- if Slab "consumes" the same actions.move_command button then it will early return here
    if actions.move_command == button then
        self.input.move_command = true
    end
end