x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

jrk · 2013-12-14 12:00:54

I'm proud and happy to announce my very own window switcher for EWMH compatible window managers.

Features:

Light-weight: No additional libraries except XCB, Xft and OpenGL
Exposé-like: Shows thumbnails of all your windows for selection
Window selection with keyboard and mouse
Draws window icons from _NET_WM_ICON or WM_HINTS
Draws window titles from _NET_WM_NAME and/or WM_NAME & WM_CLASS
Unfocused windows are black and white & slightly blurred
Entirely configurable through Xresources (man 1 xrdb)
Automatic configuration reload (e.g. after xrdb -load) without restart
Makes use of OpenGL for fast and appealing graphical effects
GLSL shaders in external file, stringified at compile time
Written in modern C++11 with a modular object oriented approach

Caveat: Needs OpenGL >= 3.0! If in doubt, check with glxinfo.

Please read the README carefully.
If your question is not answered here, or you have problems getting it to run, then feel free to ask me or to open an issue on GitHub.

If you like and use it, then please star me on GitHub {and,or} vote on AUR.
That'll give me some feedback about how many people actually use it (plus, it makes me happy )

[Edit]
* Link to GIF
* Fixed link to AUR pkg
[/Edit]

Last edited by jrk (2013-12-19 09:26:26)

Unia · 2013-12-14 12:45:48

Can you post a screenshot?

jrk · 2013-12-14 20:06:02

I hear you.
I figured a GIF might serve the case even better!

Last edited by jrk (2013-12-14 20:13:22)

ooo · 2013-12-14 22:50:27

I would try this if I just hadn't setteled back to gnome3. looks pretty cool

but I'd like to be able to make the full size windows hidden from background when its activate, or only have the background image visible..
and also hide the window title and icon

drcouzelis · 2013-12-15 00:38:55

Thank you for making this window switcher. I think I'm seeing a bug.

The windows look "garbled": https://www.cs.drexel.edu/~drc56/arch/2 … _scrot.png

Here is my OpenGL information (Radeon open source driver):

$ glxinfo | grep -i open
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD CEDAR
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.5
OpenGL core profile shading language version string: 1.40
OpenGL core profile context flags: (none)
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 9.2.5
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:

My window manager is Openbox, no compositing. I'm using the "x-choyce" package. Let me know if there's anything I can do to help fix this issue.

Thank you!

Last edited by drcouzelis (2013-12-15 00:48:47)

jrk · 2013-12-15 10:56:25

ooo wrote:

[..]
I'd like to be able to make the full size windows hidden from background when its activate, or only have the background image visible..
[..]

There are two ways to do this.
1) Use just one full screen window as drawing surface.
2) Use compositing (which means more less to implement a complete window compositor like compton)

Both ways would require a complete rewrite of the program.
Also, for the first solution, you'd also need to run a compositor if you wanted (partial) transparency.
In addition, my goal was to create a usable, good looking window switcher which works without running an extra compositor.
So, I guess that's not going to happen.

ooo wrote:

[..]and also hide the window title and icon

Well, that's something I could implement easily.

drcouzelis wrote:

[..]Let me know if there's anything I can do to help fix this issue.

Sorry to hear that you have issues with this.
Are those windows unmapped (on another desktop or hidden?)
Can I get the output of xwininfo for one those windows please?
It's interesting to see that at least one window works. Is there something noteworthy different about it?
Thanks!

drcouzelis · 2013-12-16 02:57:18

jrk wrote:

Are those windows unmapped (on another desktop or hidden?)
Can I get the output of xwininfo for one those windows please?
It's interesting to see that at least one window works. Is there something noteworthy different about it?

Here is my test scenario: Start Openbox. Start "x:choyce" from the command line. Open four windows (plus conky). Press Super + Tab.

It seems that x:choyce will display a window correctly if it has never been loaded by x:choyce before (usually). Once it has, or if I simply tab-through or mouse-over a window while using x:choyce, it will immediately become garbled and remain garbled each time I press Super + Tab.

Firefox:

  Absolute upper-left X:  257
  Absolute upper-left Y:  42
  Relative upper-left X:  1
  Relative upper-left Y:  20
  Width: 1165
  Height: 985
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +257+42  -258+42  -258-23  +257-23
  -geometry 1165x985+256+22

PCManFM:

  Absolute upper-left X:  1
  Absolute upper-left Y:  505
  Relative upper-left X:  1
  Relative upper-left Y:  20
  Width: 655
  Height: 544
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +1+505  -1024+505  -1024-1  +1-1
  -geometry 655x544+0-0

urxvtc:

  Absolute upper-left X:  389
  Absolute upper-left Y:  661
  Relative upper-left X:  1
  Relative upper-left Y:  20
  Width: 644
  Height: 388
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +389+661  -647+661  -647-1  +389-1
  -geometry 80x24+388-0

conky:

  Absolute upper-left X:  7
  Absolute upper-left Y:  3
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 251
  Height: 421
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +7+3  -1422+3  -1422-626  +7-626
  -geometry 251x421+7+3

DeaDBeeF:

  Absolute upper-left X:  823
  Absolute upper-left Y:  25
  Relative upper-left X:  1
  Relative upper-left Y:  20
  Width: 804
  Height: 698
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +823+25  -53+25  -53-327  +823-327
  -geometry 804x698-52+5

scottjad · 2013-12-17 11:42:01

Very nicely done! It works great for me under StumpWM on Debian.

I've tried several of these types of programs over the years and yours is the best I've seen. I was so pleasantly surprised when I tried hjkl navigation (before reading all of the the readme) and it worked!

Not showing a preview of windows on other workspaces is a nice touch (not sure if it's intentional or a result of something about X). Making all but the selected previews black and white is also a nice touch. You might want to make both of these optional though.

A few ideas, which I understand if you reject, are:
- A non-grid layout, perhaps a single horizontal line (Edit: By this I mean limit the number of windows per column to one. Perhaps make this number configurable)
- A way to limit windows by typing part of the title
- (Edit: Another feature I thought of was making a way to invoke the switcher on a subset of windows based on a title or class query, or maybe just a list of window ids so I can use whatever tool I want to create the subset of windows. Like show me only mplayer windows. This one seems harder since x:choyce is continually running and you can't just bind a key in your window manager to run something like "x:choyce --class mplayer" or "x:choyce --windows 0x2000169,0x3200003")

Thanks for sharing!

Last edited by scottjad (2013-12-17 13:55:18)

jrk · 2013-12-17 19:18:12

drcouzelis wrote:

Here is my test scenario: Start Openbox. Start "x:choyce" from the command line. Open four windows (plus conky). Press Super + Tab.
It seems that x:choyce will display a window correctly if it has never been loaded by x:choyce before (usually). Once it has, or if I simply tab-through or mouse-over a window while using x:choyce, it will immediately become garbled and remain garbled each time I press Super + Tab.

Thanks Doc!
I've been digging a bit into this issue and I think it's related to the OpenGL context getting messed up by configuring the window (e.g. {un,}mapping, resizing).
I was never really aware of this, because
1) my windows were not garbled like yours and
2) the damage handling (i.e. redraw when the window's contents change) covered the effect.

Currently I'm looking at how to handle window resizing, etc. properly in terms of an OpenGL context. Seems not to be to easy, worst case might be that I have to destroy/re-create the context every time. But that's just implementation yadda yadda. If I have something running, I'll give you a notice, so you can try it out.
[Edit] Want something funny to read? Here you are. I can certainly feel that persons pain. [/Edit]

scottjad wrote:

Very nicely done! It works great for me under StumpWM on Debian.
[..] I was so pleasantly surprised when I tried hjkl navigation [..]

Glad you like it and good to hear that it works!
I'm a Vimmer, so that was the obvious choice.

scottjad wrote:

Not showing a preview of windows on other workspaces is a nice touch (not sure if it's intentional or a result of something about X).

It's indeed something about X. You basically cannot use the backing pixmap of an unmapped window. You can, but the window had to be mapped at least once. Then you get the latest content, but still no live updates. For now I've chosen the easier route.

scottjad wrote:

- A non-grid layout, perhaps a single horizontal line (Edit: By this I mean limit the number of windows per column to one. Perhaps make this number configurable)
- A way to limit windows by typing part of the title

* A different layout should be easily implementable. If you want to take a look at it yourself, peek at layout_t.hpp (the interface) and grid.{c,h}pp (the current implementation. I'll put in on my agenda.
* dmenu style window-by-typing selection is already on my agenda, as soon as I have time again.

scottjad wrote:

- (Edit: Another feature I thought of was making a way to invoke the switcher on a subset of windows based on a title or class query, or maybe just a list of window ids so I can use whatever tool I want to create the subset of windows. Like show me only mplayer windows. This one seems harder since x:choyce is continually running and you can't just bind a key in your window manager to run something like "x:choyce --class mplayer" or "x:choyce --windows 0x2000169,0x3200003")

I'm not sure about that one. It's certainly doable, but I designed x:choyce to run in the background because creating the thumbnail windows & their opengl context is pretty heavy lifting. Depending on how much windows you want to preview it'll most probably give you not the experience you want (something like tens of ms of delay to show the thumbnails). I'll keep it in the back of my head though.

Last edited by jrk (2013-12-17 19:22:54)

progandy · 2013-12-17 19:40:31

jrk wrote:

scottjad wrote:
- (Edit: Another feature I thought of was making a way to invoke the switcher on a subset of windows based on a title or class query, or maybe just a list of window ids so I can use whatever tool I want to create the subset of windows. Like show me only mplayer windows. This one seems harder since x:choyce is continually running and you can't just bind a key in your window manager to run something like "x:choyce --class mplayer" or "x:choyce --windows 0x2000169,0x3200003")
I'm not sure about that one. It's certainly doable, but I designed x:choyce to run in the background because creating the thumbnail windows & their opengl context is pretty heavy lifting. Depending on how much windows you want to preview it'll most probably give you not the experience you want (something like tens of ms of delay to show the thumbnails). I'll keep it in the back of my head though.

You could create a unix socket and use it to push parameters to the already running instance I think.

jrk · 2013-12-17 20:29:14

progandy wrote:

You could create a unix socket and use it to push parameters to the already running instance I think.

Yeah, but I'd rather prefer to use dbus for this.
However, that would mean a rewrite of the main loop, because I'd need to use select() and file descriptors for xcb + dbus (or a listening socket).
Alternatively I could use threads, which means locking. Anyhow, not a quick fix.

jrk · 2013-12-18 20:25:16

drcouzelis:
Can you try out the develop branch?
I think the issue should be fixed there.
Oh, and it would be nice if you could open an issue on github (with a link to your initial post or so), just for reference.
Thanks!

drcouzelis · 2013-12-19 02:37:19

That's the same as installing the "x-choyce-git" package, correct? I just installed it. I'm afraid the changes haven't had any effect. Everything is the same.

I'll try to open a ticket later tonight.

Thank you!

(Yay, 2000 posts!)

Last edited by drcouzelis (2013-12-19 10:35:15)

jrk · 2013-12-19 09:24:06

drcouzelis wrote:

That's the same as installing the "x-choyce-git" package, correct? I just installed it. I'm afraid the changes haven't had any effect. Everything is the same.

Unfortunately not. That would be the 'x-choyce-dev-git' package. Sorry for the confusion. However, it'd be much easier for you to run something like this:

cd /tmp; git clone -b develop https://github.com/jrk-/x-choyce/ && cd x-choyce/src && make && echo ok && ./x:choyce

Thanks!

[Edit]
I've fixed the link to the AUR package above. My bad, sorry again.
[/Edit]

Last edited by jrk (2013-12-19 09:27:32)

drcouzelis · 2013-12-19 10:34:51

jrk wrote:

cd /tmp; git clone -b develop https://github.com/jrk-/x-choyce/ && cd x-choyce/src && make && echo ok && ./x:choyce

I did a quick test, same result.

I'd like to test some more configurations (window managers, applications, drivers...), but I'm afraid it'll be a few days until I have time. Thank you!

Last edited by drcouzelis (2013-12-19 10:35:24)

jrk · 2013-12-19 20:14:16

drcouzelis wrote:

I did a quick test, same result.
I'd like to test some more configurations (window managers, applications, drivers...), but I'm afraid it'll be a few days until I have time. Thank you!

I'm sorry to hear that you're still having trouble.

It's very nice of you that you want to investigate this. A few ideas of what I can think of:
* Can you try out the proprietary ATI driver? (you're using the Gallium renderer which I cannot try out myself unfortunately)
* I don't know anything about driver options for ATIs on Linux, but is it possible that you switch to Mesa?
* If you can, try a compositing manager (e.g. compton) with the glx backend (e.g. compton --backend glx)

A bit of googling brought up this, but that's from 2010.

Based on previous experiences (speak Nvidia), I've created a branch called nomipmaps, where I simply disabled mipmap generation. If you like, you can try it out, just like the develop branch (git clone -b nomipmaps; etc.).

Your help is greatly appreciated, thank you!

drcouzelis · 2013-12-24 01:45:28

Quick update:

jrk wrote:

Based on previous experiences (speak Nvidia), I've created a branch called nomipmaps, where I simply disabled mipmap generation. If you like, you can try it out, just like the develop branch (git clone -b nomipmaps; etc.).

The windows are displayed correctly with this branch.

I did notice something peculiar though... Didn't someone say x:choyce is only supposed to show the windows on the current desktop? When I Mod + Tab I see all windows (windows are other desktops are blank + icon + title).

jrk · 2013-12-24 09:08:03

drcouzelis wrote:

jrk wrote:
I've created a branch called nomipmaps
The windows are displayed correctly with this branch.

Thanks for testing it! At least now I know that it's either related to the Mipmap generation or the texture rebinding. Mipmaps are necessary for smooth scaling, but one could do without them. Given the problems that continuously arise with these, I'm tempted to either disable them or just make them configurable.

drcouzelis wrote:

I did notice something peculiar though... Didn't someone say x:choyce is only supposed to show the windows on the current desktop? When I Mod + Tab I see all windows (windows are other desktops are blank + icon + title).

That's the desired behaviour. Windows from other desktops (unmapped windows in general) are shown blank + icon + title. For one that a technical limitation (X does not provide backing pixmaps for unmapped windows), but also intended. I'd like to group windows by desktop and make it configurable whether to show only windows from the current desktop or not. Well, let's see..

drcouzelis · 2013-12-24 13:05:05

jrk wrote:

That's the desired behaviour. Windows from other desktops (unmapped windows in general) are shown blank + icon + title.

Oops! I was mistaken about what I remembered reading in this thread. You're right!

jrk wrote:

scottjad wrote:
Not showing a preview of windows on other workspaces is a nice touch (not sure if it's intentional or a result of something about X).
It's indeed something about X. You basically cannot use the backing pixmap of an unmapped window. You can, but the window had to be mapped at least once. Then you get the latest content, but still no live updates. For now I've chosen the easier route.

Thanks for your work!

Arch Linux

#1 2013-12-14 12:00:54

x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

#2 2013-12-14 12:45:48

Re: x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

#3 2013-12-14 20:06:02

Re: x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

#4 2013-12-14 22:50:27

Re: x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

#5 2013-12-15 00:38:55

Re: x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

#6 2013-12-15 10:56:25

Re: x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

#7 2013-12-16 02:57:18

Re: x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

#8 2013-12-17 11:42:01

Re: x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

#9 2013-12-17 19:18:12

Re: x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

#10 2013-12-17 19:40:31

Re: x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

#11 2013-12-17 20:29:14

Re: x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

#12 2013-12-18 20:25:16

Re: x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

#13 2013-12-19 02:37:19

Re: x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

#14 2013-12-19 09:24:06

Re: x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

#15 2013-12-19 10:34:51

Re: x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

#16 2013-12-19 20:14:16

Re: x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

#17 2013-12-24 01:45:28

Re: x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

#18 2013-12-24 09:08:03

Re: x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

#19 2013-12-24 13:05:05

Re: x:choyce, a light-weight, Exposé-like window switcher for X (+OpenGL)

Board footer