On Sat, 21 Aug 2010, Hans-Christoph Steiner wrote:

Come on. It only has with the use of the -%d in the sys_vgui calls, whereever the "fs" variable appears. We introduced that to fix a certain problem about sizes, but for some reason, it didn't produce the result we expected (the use of pixel sizes). It will be a small fix like this, by search-and-replace in a few files or so.

Your TkWidgets won't provide the same functionality, and I have no guarantee that it will be any easier to maintain. What will you do differently, so that it becomes easier to maintain ?

I ask because, currently, there's mostly only one structure of GUI widget used in externals other than mine, and it's largely a calque of IEMGUI's, in all cases something quite verbose (though at least it shares some code in g_all_guis.c in the case of IEMGUI). I introduced several new ways of writing GUI externals (the old gridflow way, the new gridflow way, and the desiredata way) but they have been so undiscussed that I wonder whether any new GUI classes would be any different in a good way. It really looks like whatever research I do on the topic of readability and modifiability of the GUI code has to be only for myself, as I don't seem to be getting any honest feedback on it.

what I currently see in /tkwidgets/ seems somewhat different from the usual case, but currently I can't get it to run, and then, it doesn't have a properties dialogue either, and then, it doesn't need to render anything as multiple canvasitems because it's for wrapping Tk Widgets instead of Tk Canvas Items, so, it's somewhat of a different deal anyway.

And it doesn't fix the problem with IEMGUIs, that people will continue to use for quite a while. One of the advantages of the IEMGUIs is that they are transparent (this is something I realised much after I made my rewrite of IEMGUI in early 2004, in which I made them opaque because back then I thought it was better that way).