Age | Commit message (Collapse) | Author |
|
This bumps the rototiller submodule for the new described
settings stuff, among other improvements.
There are some ugly kludges surrounding widget lifecycle since I
destroy setting widgets from their signal callbacks and that
seems to anger gtk/glib. I'm unclear on what the right way is
here, but leaking for now is relatively harmless.
It seems like gtk+ should be holding a reference on the
respective widget across signal deliveries so the callbacks can
potentialy destroy them with the underlying resource freeing
becoming queued. Perhaps there's something like signal
propagation up the heirarchy happening and since I'm destroying
the settings frame higher up the tree and not the specific widget
being signaled things fall over. It's a TODO item to sort out,
at least the resources leaked aren't substantial and it's only on
interactive configuration.
This has also been done in fashion preserving the
--module=foo,bar=baz arguments consistent with classic
rototiller. You can start glimmer with the same syntax --module=
flag, and it will select the specified module and apply the
supplied settings in a way reflected in the GUI.
There should probably be a new '--go' flag added to enable
starting the rendering via commandline. As-is glimmer will
always leave you at a settings dialog waiting for a "Go!" click,
even if you specified module+settings comprehensively via the
CLI.
|
|
mechanical rename making consistent with til_args_t naming
|
|
Simultaneously update includes and call sites to reflect the new
til_ prefix, preserving buildability.
|
|
Make sure there's no outstanding workers potentially scribbling into a
page before tearing down the fb and its pages.
|
|
Just an ergonomic improvement, submodule bump and code change
done at once to keep things bisectable.
|
|
vim droppings
|
|
This deadlocks after a few "Go!" cycles, and the "rtv" module's
"snow" doesn't seem to be drawing anything, despite the explicit
use of "snow" working fine. I suspect it has to do with the lack
of module setup occurring, rtv may have a broken assumption about
the snow module always being setup at runtime and no static default
compiled in. I didn't go look yet.
There's plenty of TODOs and such to take care of, but this looks like
a good foundation to potentialy collaborate on and start thinking about
how things like libhandy would integrate and what directions things
must go to make that workable.
|