[Tickit-dev] API thoughts - window configs, toplevel object configs, ...

[Paul "LeoNerd" Evans]

The current API has a set of functions for accessing various
config-like attributes on a TickitTerm instance:

bool tickit_term_getctl_int(TickitTerm *tt, TickitTermCtl ctl, int *value);
bool tickit_term_setctl_int(TickitTerm *tt, TickitTermCtl ctl, int value);
bool tickit_term_setctl_str(TickitTerm *tt, TickitTermCtl ctl, const char *value);

These all operate on an enumeration, TickitTermCtl, which indexes over
the various configuration options that might be of interest.

There's also a Blueprint that considers making a similar structure for
Windows:

  https://blueprints.launchpad.net/libtickit/+spec/winctl

This would have settings such as the cursor properties on that window,
as well as taking over from the current special-purpose functions like
input-stealing or focus-child-notify.

I'm now further considering that the toplevel object itself may need
some configurations, for things like whether to use the altscreen
buffer. There's also options on things like timing for double- or
triple-click detection, and so on...

At this point, I start to wonder whether having three separate
enumerations of config parameters is the best approach. Perhaps
instead, we could have a single space of options, which various types
of object can optionally recognise. It might simplify language bindings
(as well as reducing the number of support functions needed, because
now we'd only need one set of functions for looking up names or types
of these). It might also simplify cases where e.g. the toplevel
instance just forwards on certain properties into its terminal.

Would this make sense though? What do people think?

 1) Three separate sets of functions, enumerations, etc...

 2) One combined enumeration for all three object types

 3) A different structure entirely?

-- 
Paul "LeoNerd" Evans

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