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

Small changes to make working with Xwayland easyier #255

Closed
wants to merge 5 commits into from

Conversation

kozec
Copy link
Contributor

@kozec kozec commented Apr 15, 2017

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:

  • Native wayland applications are drawing decoration for themselves, but X11 window has to be decorated by WM/Compositor. This PR adds WLC_BIT_X11 and WLC_BIT_BORDERLESS view types to help deciding which is which without doing complicated stuff to determine something that WLC already knows.
  • Closing X11 windows means connecting to Xserver, querying, sending requests, calling XKillWindow... While WLC already does this internally. This PR adds API to do all that using already existing wlc->x11 connection.

@Cloudef
Copy link
Owner

Cloudef commented Apr 16, 2017

Why are the wlc_x11_ functions needed for public?

@kozec
Copy link
Contributor Author

kozec commented Apr 16, 2017

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

kozec commented Apr 17, 2017

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
Copy link
Contributor Author

kozec commented Apr 20, 2017

@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
Copy link
Owner

Cloudef commented Apr 20, 2017

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
Copy link
Owner

Cloudef commented Apr 20, 2017

The WLC_BIT_BORDERLESS is okay.

@kozec
Copy link
Contributor Author

kozec commented Apr 21, 2017

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.

@kozec kozec closed this Apr 21, 2017
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.

4 participants