Closed kozec closed 7 years ago
Why are the wlcx11 functions needed for public?
They are not exactly needed, but it's something that's nice to have. It allows to implement "Kill window" option in window menu without creating separate connection to X server. But if it means problem, I can create PR without them.
why not have them public though? There is nothing wrong with having as detailed public api as possible, for having options ready for people using wlc? Surely that is not a bad thing... if cluttering is a point, just move them to separate api header?
But if wlc always does this internally when you close a WlcView
, then why bother exposing it? What use case is there for the compositor to go around wlc and send the kill command to the X server itself when wlc already handles it?
If it's not necessary, I don't see why it should be made public.
But if wlc always does this internally when you close a WlcView, then why bother exposing it? What use case is there for the compositor to go around wlc and send the kill command to the X server itself when wlc already handles it?
My main use case is this kind of dialog:
It is supposed to appear when X11 window claims to support WM_DELETE_WINDOW, but doesn't react to event (usually because its process hanged). Currently there is no way to get rid of such window using just WLC api.
Other use case may be allowing user to kill window instead of closing it, as some older WMs does.
@Cloudef sorry to bother you, but I really would like your option on this. Does it looks at least theoretically mergeable? It looks like I'll have to do more crazy stuff with X11 windows (for example, I'm looking at enabling borders on menus right now) and I'm not sure in which direction should I go.
Would it be better to add even more methods to wlc, or scrap even those in this PR and expose XIDs and display connection, so library user can do whatever he wants without help of wlc?
Preferably, you would not need to do anything x11 related. But if it's really needed just expose the display and xids in wlc-xwayland.h or something.
The WLC_BIT_BORDERLESS is okay.
But if it's really needed just expose the display and xids in wlc-xwayland.h or something.
Will do, thanks :)
The WLC_BIT_BORDERLESS is okay.
I'll create another PR just with that for time being.
In my long running attempt to create more traditional WM based on WLC, I found two things to really hard to do outside of wlc:
WLC_BIT_X11
andWLC_BIT_BORDERLESS
view types to help deciding which is which without doing complicated stuff to determine something that WLC already knows.