[Tickit-dev] C library updates

[Paul "LeoNerd" Evans]

TL;DR: added new functions;
       more design questions on application structure

---

I've recently been working on the Window layer in the C library. It's
very-almost ready now - I think we have all the code and tests ported
from Perl (with the single exception of the extended drag-and-drop
events whose names start "drag_..."). I haven't yet done the docs
though.

I've also been adding/fixing a few other bits in the core code. Two new
term-related functions make actually writing programs a little neater:

  void tickit_term_observe_sigwinch(TickitTerm *tt, bool observe);
  http://home.leonerd.org.uk/code/libtickit/doc/tickit_term_observe_sigwinch.3.html

  TickitTerm *tickit_term_open_stdio(void);
  http://home.leonerd.org.uk/code/libtickit/doc/tickit_term_open_stdio.3.html

This latter convenience function makes all the examples a few lines
shorter, and while it's at it, enables the SIGWINCH behaviour. That
ensures that the TT instance actually sends EV_RESIZE events when the
terminal is resized - previously C programs couldn't actually detect
that one; it was done in the Perl layer using a handler on $SIG{WINCH}.

---

I noticed that all of the examples in the C library source aren't
*even* using renderbuffer yet; they're on plain printing direct to the
terminal. So I decided to rewrite one of them (demo-xterm256.c) to use
both renderbuffer and show off the new window layer at the same time.

The result isn't too pretty yet though - there's a lot more machinery
in the source code than I'd like:

  http://pastie.org/10310775

My primary concern is that the Window layer doesn't actually perform
any sort of expose-after-resize (because up 'til now, all use of
Windows has been in Perl via Widgets, which have the entire
reshape/redraw logic). So the whole on_geomchange() function is
invented here, along with setting it on line 127. This feels like
internal machinery that should just happen. Also, the initial expose on
lines 131-132 feels awkward. While line 131 could be implied by
internals by making the root window start off fully expose-pending,
line 132 is still needed to "flush" that pending damage to the RB and
hence terminal. Harder to work that into the logic currently.

I know there's bound to be some amount of low-level machinery noise in
any C app, but I think this is a bit much currently. Eventually we'll
have an actual toplevel "Tickit" object itself to act much as the
runloop for the program which would handle these cornercases - maybe
now is approaching the time to consider that?

What do people think here?

-- 
Paul "LeoNerd" Evans

leonerd at leonerd.org.uk
http://www.leonerd.org.uk/  |  https://metacpan.org/author/PEVANS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.leonerd.org.uk/pipermail/tickit-dev/attachments/20150725/a2a7f4d8/attachment.sig>