Age | Commit message (Collapse) | Author |
|
Prior to this in some modules you could manipulate their settings
while watching their output, and the changes would be realized
*immediately*.
Rototiller has firmed up the application of settings so they're
no longer module-global and instead apply to an allocated setup
instance that is then supplied to create_context().
As a result, in glimmer, one must always now click "Go!" to see
the effects of new settings.
|
|
Classic rototiller would get tripped up on empty values in the
args like:
"--module=compose,layers="
This turned out to be an edge case parser bug in
til_settings_new(), so pull in the fix - though I haven't
verified that glimmer suffers similiarly from a setting w/NULL
value.
|
|
glimmer doesn't utilize drm_fb so this doesn't really have any
bearing, but pull in the fixed version anyways.
|
|
glimmer builds shouldn't require sdl2 or libdrm, this version of
rototiller makes those optional and only produces libtil when
both are absent. libtil is the only rototiller component
utilized by glimmer.
|
|
swarm got drawing styles, pull it in
|
|
Improve settings to properly realize changes in the GtkEntry
widgets without relying on "activate" (Enter) exclusively.
Now when such widgets lose focus their value is committed and the
settings panel rebuilt to reflect any value-dependent changes.
This requires some contortions since GTK+ really doesn't like
having its widgets rearranged/destroyed from their signal
callbacks. So now a settings change just queues a rebuild to be
performed as an idle callback, for both the "activate" and
"focus-out-event" cases.
In the course of rebuilding the settings panel, its vbox gets
replaced with a newly constructed one. This requires some manual
preservation of widget focus for things like Tab-based relative
setting navigation/manipulation to function properly.
|
|
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.
|
|
preparatory for supporting rototiller style cli arguments
|
|
Simultaneously update includes and call sites to reflect the new
til_ prefix, preserving buildability.
|
|
fb_rebuild() has been added to facilitate window resizing
This also fixes the unconfigured rtv snow handling
|
|
This should eliminate most if not all of the deadlocking on
module switching problems...
|
|
Since glimmer tears down and brings back up the world at will,
it needs a way to synchronize with idling the threaded renderer.
This may go away if librototiller gets refactored a bit to where
the main rendering loop moves into librototiller, but as long as
that's driven externally there needs to be a way to coordinate
at this level.
|
|
Just an ergonomic improvement, submodule bump and code change
done at once to keep things bisectable.
|
|
glimmer is a gtk frontend for rototiller
|