glimmer/.git - glimmer is a GTK+-3.0 frontend for rototiller (WIP-quality)

Age	Commit message (Collapse)	Author
2022-03-19	glimmer: first stab at adding settings support	Vito Caputo
	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.
2021-10-01	*: bump rototiller submodule for libtil rename	Vito Caputo
	Simultaneously update includes and call sites to reflect the new til_ prefix, preserving buildability.
2021-02-18	gtk_fb: integrate fb_rebuild() to handle resizes	Vito Caputo
	This wires up the "configure-event" signal on the fb window to trigger fb_rebuild() on resizes in the subsequent gtk_fb_page_flip().
2021-02-17	gtk_fb: move window_{new,destroy} to fb_{init,shutdown}	Vito Caputo
	Pages get allocated before fb_acquire, and when creating similar pages to the underlying window it creates a depenency on the window being available before acquire. So move the window create/destroy to the fb init and shutdown, acquire/release now operate on the image within. This commit also switches to using: gdk_window_create_similar_image_surface() for allocating pages, which may be more performant on backends like X through the use of shared memory.
2021-02-17	gtk_fb: add note about xshm surfaces	Vito Caputo
	After some discussion with chergert on how this could be quicker on X, it seemed worth noting at least something to this effect. The details of doing this seemed annoying, because cairo apparently doesn't just give you an xshm if appropriate via gdk_window_create_similar_image_surface() If that was all that were needed, this commit would just change the cairo_image_surface_create() over to that. But chergert claimed it doesn't do the right thing here, so a comment it is until someone cares enough to to investigate further.
2021-02-17	gtk_fb: no need to explicitly remove tick_callback	Vito Caputo
	This too will automatically get removed on widget destroy
2021-02-17	gtk_fb: no need to destroy c->image	Vito Caputo
	Destroying c->window, the container of c->image, will already do that.
2021-02-16	src: initial commit of something semi-working	Vito Caputo
	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.