In praise of xlogo | Hacker News Reader

In praise of xlogo

simont.dreamwidth.org

78 pointsTomte25 comments

TIL: xrdb translations.

25 years of X usage, and that one has somehow managed to evade me. Such an awesome (and now that I learned about it - obvious) thing.

These only work with programs written using (and linked to) Xt, the X Toolkit, or something which uses Xt internally, like the X Athena Widgets. More modern toolkit libraries like GTK or Qt are not using Xt, since Xt is ancient; modern toolkit libraries are written directly on top of Xlib or the even more modern XCB.

I don't see age being the prime factor here. The X Toolkit Intrinsics (Xt) are actually a quite nice framework if you want to have an abstraction over Xlib, want some nice event loop functionality or OO features in C. I think I even remember someone writing a paper about using it without a GUI way back when.

Not using it was mostly done because you want to be cross-platform at that level, aren't using C as your core language (Qt, Tk) or just the usual case of NIH you get everywhere (Gtk, which rather invented glib).

I did Xt in college for a Unix Graphics Programming class and it felt so alien to me. The examples in the books (3 or 4 books) we had never seemed to work right. When compared to plain Xlib, OpenGL immediate mode and 3D mode, Java’s AWT and Swing, or even the tiny bit of Win32 I picked up via NanoX/Microwindows, Xt always just felt like dereference vomit, arcane property setting in unrelated objects or contexts and an event loop that magically picked up some events but not others. It was like there was some undocumented state machines that backed the event loop.

I deal with OpenGL a lot so glxgears has been my standby. If it's just X I'm testing I've always used xclock.

I always used xeyes to test X connections in the past.

I wonder if we'll see a wleyes for Wayland, to test Wayland only and not the x11 comparability layer.

As a totally uninformed guess -- no?

Part of wayland's security design decisions is that one program cannot receive events from another program.

An app like xeyes would need cooperation from the compositor otherwise.

It could use a large window and get input from that entire area, right? Not quite the same thing, of course.

Wouldn't that only work when it has focus?

I use xeyes on wayland to determine whether a given app is using Xwayland or not.

> As a ruler. Want to know how big something on your screen is in pixels? Fire up an xlogo, line it up with one edge of the thing, resize until the opposite edge lines up too, and if your window manager puts up a tooltip during window resizing (which I think all the ones I've ever used do), then you know the size.

I don't see a tooltip that shows the window size. I am using Xfce.

Yeah, I wondered about that too. I remember older, traditional window managers like TWM, FVWM, OpenBOX, etc. show this but most newer "Desktop" environment's window managers like XFCE's and Gnome's do not.

Interestingly when sizing a terminal window these WM's show the size in columns and rows and when sizing a "real" window it shows the size in pixels.

Probably an option somewhere to turn it on in newer environments but it's been a while since I used anything but cwm[1] (which does show the window size on resize) so I can't be sure.

[1] calm window manager - https://en.wikipedia.org/wiki/Cwm_%28window_manager%29

Are you using cwm on OpenBSD or on something else? (Just curious.)

OpenBSD is where I discovered it and started using it. First on a laptop that I use to install Beta's and then a few machines at home.

I use a Slackware box at work and was delighted when I found a Linux port[1], now I use it everywhere except on Windows.

[1] https://github.com/zenlinux/cwm

> Interestingly when sizing a terminal window these WM's show the size in columns and rows and when sizing a "real" window it shows the size in pixels.

IIRC there's a window property the app can set on itself to tell the WM of its "resize increment", as well as a "base size". Since the main use case for that is terminal windows (anything that displays fixed-width text), I think most WMs assume that anything with that set on it cares about rows and columns rather than pixels.

xlogo is one of my favourite programs. I have it as the exec line on my xinitrc, so that the only way to logout is by killing xlogo.

or ctrl+alt+backspace unless you disabled it

In my experience, that typically needs to be enabled.

Different distros of course have different defaults.

don't you close it by mistake sometimes? I'd close it to unclutter the screen

It's on a frameless window, in the background. The only way is to type killall xlogo in the terminal.

When a service kicks off, a small XLogo appears to let me know it is active, it goes away when it ends.

Long time back (when xhost by default accepted all connections) in my college lab, I used to redirect DISPLAY to an unsuspecting user sitting on my favorite machine and and bombard them with `while true; do xlogo & done;`

I once used a computer lab where the AIX workstations each had their local filesystems exported to the entire campus via AFS. Even /dev. Including /dev/audio. Which was world-writeable. And there was no apparent volume control for the chassis speaker.

I prefer xeyes

> This [using xlogo as an alarm] is better than an audible alert because it's less antisocial in an open-plan office

And here I am with a loud clicky keyboard and my notifications very much not on mute in protest of my open office.

Reply on news.ycombinator.com