Add context managers for pixmaps and graphic contexts

[m-col]

Context managers for these would mean we don't need try-finally blocks to free them after use, which makes it neater and easier to correctly handle exceptions. Would you be interested in implementing this?

[tych0]

I'm more interested in accepting a patch for it than implementing it myself :-)

…

On Mon, Aug 31, 2020, at 4:40 PM, m-col wrote: Context managers for these would mean we don't need try-finally blocks to free them after use, which makes it neater and easier to correctly handle exceptions. Would you be interested in implementing this? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#109>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAF7VVZ6TR3JJKWIKNOVH7LSDQRFHANCNFSM4QRAMCNA>.

[m-col]

I suspected that would be your response so I have been digging into the code :)

From what I can tell, the context managers would need to be added to the generated xproto.py, because the init.py can't see the xproto stuff. Implementing this in Python would be a piece of cake, but this seems like it would be a Haskell patch. Am I heading in the right direction?

Perhaps I can give my Haskell-loving pal a hard poke.

[tych0]

Can you give an example usage of what you're thinking here? I'm not sure I quite understand what it would look like.

Might be a haskell patch and the haskell is... not pretty. It started out really pretty, but xcb is very inconsistent, and slowly more and more state monads, etc. had to be added :(

[m-col]

This would let us change this:

pixmap = conn.generate_id()
try:
    do_stuff_with_pixmap()
finally:
    FreePixmap(pixmap)

into this:

with conn.generate_id() as pixmap:
    do_stuff_with_pixmap()

[tych0]

I think we've traditionally wrapped this type of thing in libqtile's xcbq; you could just write a little pixmap class there that would do this type of thing. However, it does seem useful more generally, so if you still want to hack on this here's some thoughts.

IMO, doing with conn.generate_id() is a little weird, since you don't actually know how to free the thing at the time you generate it. You could make the thing returned from generate_id() some kind of proxy object which would accumulate things it needs to free when passed into various methods (e.g. queuing a FreePixmap call when CreatePixmap is called); you'd have to make a list of these allocate/free pairs somewhere, though.

Another option would be to do something like with conn.core.CreatePixmap(...), which makes more sense to me and is much less magic. You still have to make the list of allocate/free pairs, though.

Given that you have to create this list manually, maybe it's time to add an xcffib.wrappers type package, which would have the same context managers that we'd put in xcbq?

[m-col]

Yeah that all sounds much clearer. What else would you move from xcbq.py into xcffib.wrappers?

[tych0]

Anything that looks reasonable :). This seems good for a start, but if you see other stuff that looks obvious, that's fine too.