[vidarh]

Yeah, the colour choices were pretty random, I need to clean it up.

X11 visuals are severely annoying. I get they made sense in the 80's and 90's - I spent time in computer labs where the machines ranged from monochrome to SGI Indy's, with 8-bit palette, and 15 and 16 bit direct color displays in between, but I'm all for just assuming 32-bit bgra is available these days.

Any server supporting XRender needs to support it anyway as it's one of the standard formats for XRender. (I don't know if you've looked at the XRender library code, though, but one of the things that made me facepalm was that even though it requires a handful of standard visuals, the new Xrender call that returns the visuals for Xrender does not just return a list of the handful of standard formats as part of the response - you need to filter the full list of visuals and match them to depths and bit masks... Not that it's a lot of code, but it just so aggravatingly pointless)

> what do you think an idiomatic ruby binding for yeso would look like?

I think a bit of a mix between the Python and Lua would get you pretty close. Don't look at "my" X11 client for idiomatic Ruby :) It was "inherited" from an older client, and it's very closely following the protocol more so than idiomatic Ruby, and I'll eventually try to massage it into something nicer.

To take your examples, we'd probably want to use blocks. E.g. I could see the munching squares example looking something like this in Ruby:

    def munch(t, fb)
      fb.each_row do |y|
         fb.each_col do |x|
            fb[x,y] = ...
         end 
      end
    end

You could also use the approach you use more directly, and I'm sure nobody would think that was weird either:

    def much (t,fb)
      fb.each_row do |y, p|
         fb.each_col do |x|
            p[x] = ...
         end
      end
  end

For the main bit, "new" will always directly return the window, but it's not unreasonable to then either `yield self if block_given?` in the constructor to allow similar code to your Python version:

    Yeso::Window.new(...) do |w| .. and so on; end

or wrap that in a class method:

     Yeso::Window.create(...) do |w|
        (0..).each {|t| w.frame {|fb| much(t,fb) } }
     end

(Endless infinite range is "new" since 2.6)

The class method vs. constructor only really buys you that you can make it slightly harder to accidentally keep the object around since you can prevent it from being directly returned. I think overall that's probably the most common approach even when the constructor supports taking a block directly.

[kragen]

this is motherfucking gold, thank you so much