You are not logged in.

#1 2019-07-03 09:08:00

Portal
Member
Registered: 2019-03-11
Posts: 33

xlib XSelectInput vs XGrab

what is the difference between XSelectInput and XGrab functions? For instance

void WindowManager::Frame(Window w) {
  // Visual properties of the frame to create.
  const unsigned int BORDER_WIDTH = 3;
  const unsigned long BORDER_COLOR = 0xff0000;
  const unsigned long BG_COLOR = 0x0000ff;

  // 1. Retrieve attributes of window to frame.
  XWindowAttributes x_window_attrs;
  CHECK(XGetWindowAttributes(display_, w, &x_window_attrs));

  // 2. TODO - see Framing Existing Top-Level Windows section below.

  // 3. Create frame.
  const Window frame = XCreateSimpleWindow(
      display_,
      root_,
      x_window_attrs.x,
      x_window_attrs.y,
      x_window_attrs.width,
      x_window_attrs.height,
      BORDER_WIDTH,
      BORDER_COLOR,
      BG_COLOR);
  // 3. Select events on frame.
  XSelectInput(
      display_,
      frame,
      SubstructureRedirectMask | SubstructureNotifyMask);
  // 4. Add client to save set, so that it will be restored and kept alive if we
  // crash.
  XAddToSaveSet(display_, w);
  // 5. Reparent client window.
  XReparentWindow(
      display_,
      w,
      frame,
      0, 0);  // Offset of client window within frame.
  // 6. Map frame.
  XMapWindow(display_, frame);
  // 7. Save frame handle.
  clients_[w] = frame;
  // 8. Grab events for window management actions on client window.
  //   a. Move windows with alt + left button.
  XGrabButton(...);
  //   b. Resize windows with alt + right button.
  XGrabButton(...);
  //   c. Kill windows with alt + f4.
  XGrabKey(...);
  //   d. Switch windows with alt + tab.
  XGrabKey(...);

  LOG(INFO) << "Framed window " << w << " [" << frame << "]";
}

why did the author use XGrab at the end for top-level client windows but XSelectInput for frames?

Offline

#2 2019-07-03 11:25:26

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 22,380
Website

Re: xlib XSelectInput vs XGrab

The key difference (no pun intended) is that XSelectInput allows multiple clients to respond to the selected events.  The XGrab* functions, in contrast, will fail if another client is already listening for those keys on that window.

However, I'm not sure if that is sufficient to explain why that was done in this code sample.  In fact it strikes me as *very* odd that bindings like 'alt + F' and 'alt + Tab' would be associated with a non-root window at all.  Generally these are bound once on the root window as the WM starts up, not on each individual window that is being managed.

Most WMs I'm familiar with have a couple calls to XGrabButton or XGrabKey as the WM starts up for "global" WM-wide bindings, like alt-tab window cycling, alt-f4 closing of a window, or for tiling modes, launchers, etc - pretty much anything that could be a user-defined key binding from a config file for the WM.  In response to mapping a new client window, I've only used XSelectInput for the specific events you want to listen to from that window - and I don't recall seeing WM code before that uses the XGrab* functions in this latter context.  (But I've also never looked at WM code written in C++ either, this suggests it is either from one of the major DEs, or fluxbox).

Where is this code from?

Last edited by Trilby (2019-07-03 11:34:38)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#3 2019-07-03 12:03:32

Portal
Member
Registered: 2019-03-11
Posts: 33

Re: xlib XSelectInput vs XGrab

Thanks for the response!

Trilby wrote:

The XGrab* functions, in contrast, will fail if another client is already listening for those keys on that window

So the wm won't be able to XGrab* on a window that another client has already used XSelectInput on?

Trilby wrote:

Where is this code from?

It's from a tutorial series made by a random guy
https://jichu4n.com/posts/how-x-window- … ne-part-i/
The code I was referencing to is in "part III" of the series.
He provided the entire source code at his github page
https://github.com/jichu4n/basic_wm


I am also a bit confused on this whole alt thing... for instance here
http://incise.org/tinywm.html
the author has the line

XGrabKey(dpy, XKeysymToKeycode(dpy, XStringToKeysym("F1")), Mod1Mask, root,
            True, GrabModeAsync, GrabModeAsync);

but he also claims

Raise windows with Alt+F1 (not high on usability I know, but I needed a keybinding in there somewhere)

why is it ALT+F1? Isn't it plain F1 that he is grabbing in his code?

Last edited by Portal (2019-07-03 12:04:17)

Offline

#4 2019-07-03 12:13:10

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 22,380
Website

Re: xlib XSelectInput vs XGrab

You might be better off studying real WM code rather than something that was made up just for a tutorial when it's unclear if that code has actually seen any noteworthy use or testing.

But in the case of the Alt-F1 binding, that all looks good*.  The third parameter to XGrabKey is the modifiers where Mod1Mask is included.  Mod1 is Alt:
https://unix.stackexchange.com/question … eys#119219

*edit: of course it looks good as it's from tinywm! smile  Tinywm is very tiny, but it is an excellent example of using Xlib well.  As noted above, I'd recommend looking to only slightly larger, but also well polished WMs.  DWM used to be next on my list for these purposes, though it has grown quite a bit - it suspect it's still a good one to study, but if you can get dwm code from 5 years ago, that might be even better.

Last edited by Trilby (2019-07-03 12:15:38)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#5 2019-07-06 09:53:59

Portal
Member
Registered: 2019-03-11
Posts: 33

Re: xlib XSelectInput vs XGrab

DWM has 2000 lines of code now.... right? Do you know any WMs worth studying but with fewer lines of code?

Offline

#6 2019-07-06 11:43:44

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 22,380
Website

Re: xlib XSelectInput vs XGrab

I don't know of much between tinywm and dwm in code size.  There are certainly many short-lived projects in that range.  It's a bit of a right of passage of many archers to write their own WM (or crazy people like me write 5 or 6 of them).  You can scan through the "Community Contributions" subforum here to find a bunch of smallish WMs.

Of course, dwm was also not always so large.  I'm pretty sure 0.1 and 0.2 would still work.  If you checkout those tags from git, you'll have a more manageable code base: 0.2 has just over 1300 lines of code.

Of course there's what I've been using as my only WM for the past several years and is only 109 lines of code:
https://code.jessemcclure.org/xtools/file/tmuxwm.c

EDIT: catwm looks like a promising example too.  You can just look through the list:
https://wiki.archlinux.org/index.php/Window_manager

Last edited by Trilby (2019-07-06 12:33:19)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

Board footer

Powered by FluxBB