Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Allow to setup an X11 event filter #49

Closed
wants to merge 1 commit into from

Conversation

falkTX
Copy link
Contributor

@falkTX falkTX commented May 25, 2021

This might be a bit controversial, but I found that I need this if I am going to not keep a forked pugl.

These changes allow to plug in other custom x11 code on top of pugl, that handles its own windows, events etc.
Tested to work with DPF and https://github.com/x42/sofd/

I tried to make it as generic as possible.

Signed-off-by: falkTX <falktx@falktx.com>
@@ -1129,6 +1129,10 @@ dispatchX11Events(PuglWorld* const world)
continue;
}

if (world->impl->eventFilter && world->impl->eventFilter(display, &xevent)) {
continue;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't get it. What is this concretely used for?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

injecting x11 event handling that runs on the same event loop.
the target is to couple pugl with https://github.com/x42/sofd/.

this runs on top of an existing x11 event loop to provide file dialogs with pure x11 calls.

for my old code I had it working alike this event filtering stuff.
I am not sure it is possible to make it work without placing it on top of pugl event loop.
but I can give this a try if you find this too intrusive.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. "Filter" doesn't imply doing so much, to me.

As you predicted, I am not at all a fan of exposing XEvent in the Pugl API at all, but for such uses this seems to have another problem: it requires the use of static data? No world or view is passed, so there's no access to data to actually do anything with. Not having/requiring static data is a largely the point of Pugl existing at all, so I don't think that's appropriate (or something plugin UIs should be doing in general).

That said, I still don't quite get it. Doesn't sofd make its own window? Why can't it just handle its own events? Why does it need per-event access to events in a PuglView?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, there are some problems with it. the static data is one, but that can be easily avoided.
I will try to get this stuff working without messing up with core pugl code.

@falkTX
Copy link
Contributor Author

falkTX commented Aug 14, 2021

I have now implemented sofd in DPF without having to inject into the main loop of pugl, in DISTRHO/DPF@03d53ea
This PR is no longer necessary.

@falkTX falkTX closed this Aug 14, 2021
@falkTX falkTX deleted the x11-event-filter branch August 14, 2021 18:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants