Cloudef / wlc

High-level Wayland compositor library
MIT License
331 stars 58 forks source link

Small changes to make working with Xwayland easyier #255

Closed kozec closed 7 years ago

kozec commented 7 years ago

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:

Cloudef commented 7 years ago

Why are the wlcx11 functions needed for public?

kozec commented 7 years ago

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.

Enerccio commented 7 years ago

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?

Timidger commented 7 years ago

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.

kozec commented 7 years ago

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: cantclose

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.

kozec commented 7 years ago

@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?

Cloudef commented 7 years ago

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.

Cloudef commented 7 years ago

The WLC_BIT_BORDERLESS is okay.

kozec commented 7 years ago

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.