For all widgets that support <input file> I've implemented a file-monitor tag attribute that emits a "file-changed" signal which developers can do what they like with, and an auto-refresh tag attribute that calls the widget's refresh function directly and which doesn't emit a signal.technosaurus wrote:I'll have to test it out. My idea was to allow basic board and grid games using svg's include capabilities to place sprites in a grid. I already have a basic framework including simple collision detection.
800ms should be fine for card, board and strategy games
On my computer (Intel Pentium Dual Core T2060 @ 1.6GHz) and with a test application of 256 buttons with 16x16 images I recorded 2.29s refreshing via the file-monitor's signal and 1.39s auto-refreshing.
I tried to write a game at the end of last year and slow refreshing was one issue, but the worst one was the difficulty in conditionally refreshing widgets. I think both of those should be solved now since it's now possible to choose to refresh a widget simply by updating its input file which means you can do that within the shell script.
I'm all up-to-date now with gtkdialog and I'm going to start preparing a source package release, so it would be a good idea for application developers to try it to make sure there aren't any overlooked issues.
Regards,
Thunor