Against my own expectations, it seems there's little resistance left even in that mess of paws: it took less than a week to map it all out quite fully this time, discard yet another set of dead parts of it, cut its remaining tendrils and pretense to "independent plugin, part of a common trunk, not just some code in the client", bring it therefore quite in line (though not to internal sanity, it still is what it is) and ready to be made use of, without crashing and without complaining that it doesn't have graphics or skins or resources or whatever else it previously imagined that the user must provide. For instance, here's the gui just using the system's mouse pointer if nothing else is available and the help window gladly showing whenever it's asked to show, looking as best it can with whatever is available at that time:
Having thus made sure that indeed, I can make paws do something useful after all, I'm literally staring at the pile of neatly sorted entrails of the whole thing and I can't make up my mind for the life of me - *what* is even the desired use of this paws-paste? So I'll first write down the brief description of what's there and then I'll spell out this generic question into several more specific questions that can hopefully be answered.
The current client's GUI interface is essentially a lame and broken attempt at implementing the world hierarchy from a... visual perspective1. There's a top "controlling"2 window that keeps track of all the others and does in fact the generic figuring out as to what window is the user interacting with, which ones should show and which ones should hide, all that sort of thing. Being of course a visually controlled world, the top window ends up being... that menu bar at the top (see? it's at the top, right?) of the screen, with the inventory and the quit button and whatnot. It's true that there is otherwise *also* a "mainwidget" thing but... that's just the overall container and doesn't do much at all. Don't ask me why can't that mainwidget be actually main and therefore control the rest, it just isn't. And because those are just windows and the whole codebase at the time simply couldn't do without managers, there's on top of this top a pawsManager with its very own textureManager.
The pawsManager is meant as far as I can tell as the entry point to the paws itself - at least when entertaining the delusion that paws is or can somehow be separate of the rest. The textureManager is one of those endless glorified list-keepers: it keeps its own list of filename-resourcename equivalencies for all images that the GUI uses and otherwise interfaces load/find from the engine's own textureManager, of course. The meagre claim to purpose it has beyond that of list-keeping would be that it packs in one place some format-related processing of 2D images that are supposedly helpful in some cases (though it's unclear if there are all that many such cases in current use). Anyways, aiming to keep changes to a minimum, it can live as such and keep its list too, since I have no intention of saddling EuCore with any internals of the GUI/skin now. There's of course a whole dance around in both pawsManager and its textureManager with translating strings (literally, the "localization" because apparently it makes somehow sense to shove that concern in there), defining "styles" (there's skins and then there's... styles; because one S is not enough and nevermind there's no game worth even one capital letter, yet, we'll add styles to the interface and that'll be grand!) and making oh-so-sure that one is never, ever, under any possible circumstances somehow left without - gasp! - a loaded "skin". Additional, even smaller concerns abound too but by now we get to the microscopic so I'll let them be already, suffice to say that if I'll ever need an example of pointless polishing of irrelevancy, I can certainly use that code.
Past the 2 managers and 2 top-widgets, there is the indistinct mass of ...more widgets. Basically *everything* in the GUI is a widget, from one single slot in the inventory window to the whole inventory window itself. Here I can happily report that indeed, the "off with its dolly" task was most satisfyingly carried out: there were 2 (two!) classes on top of all the usual widget+xml defined just to *support* that and several tendrils sneaking out into non-paws parts too and oh, what joy to cut them out already!
Dolly cast aside and readily forgotten, the reduced pile of widgets is still a considerable pile and otherwise waiting for either full chop or partial cut, depending on what exactly turns out in the least useful in there. The "design" of the whole thing is that each widget has a code class (in client/gui mostly) that is meant to implement what the widget does (and even if it doesn't - there still has to be this code present as a means to register and create the thing, useless as it might be) and an .xml file (in data/gui currently) that defines in principle the layout of the corresponding window to be shown in game, including size, position, contained widgets and used "resources" aka icons and other images. In practical terms this means that new or different widgets still require touching the client, there's no "download this" and run with it really. At a stretch, the .xml layout files could be made perhaps part of the "GUI" .zip and so something that can be downloaded from the server and used but there's a very tight coupling between the code and the .xml so that it's unclear to me if there's much point to it anyway. So Q1 of those more specific questions would be here: is the layout of various GUI windows something we even consider part of a "skin" definition and hence up to GUI designers to produce as part and parcel of offering a client skin for use?
Even after the above trim, there still are about 100 widgets with their corresponding 100 .xml files, so I would rather not list them in here - the list is anyway quite easy to get with a simple ls data/gui in the deployed client's dir. The more specific question here is Q2: what windows do we actually need in the whole interface anyway? I can't quite see the point of 100 windows and it really all seems to me more a matter of ill-thought "design" in the first place, fitting slots in places by hand and adjusting them to be just-so, the usual sort of "artistic" approach to it all. I rather think there has to be a small subset of elements that will do it all and better anyway but at least currently I don't even quite know where to start from with it, as it's not all that clear to me what sort of things we need in the first place. I can even see the point in saying it's too early to bother with that and move on to implementing more of the functionality so that what is needed emerges from there but on the other hand the GUI has to start with something/from somewhere too.
Going through the list of main things as seen from a player perspective so far in Eulora, the Q2 above can get further refined: the most complex window in there is the chat window - does this even still make any sense or should this be only and at most a cli window in fact? Windows like the storage for instance were relatively ok in the beginning and then an utter pain when one has a full storage, reminding me quite precisely of the more generic windows-vs-cli computer use really - do we still want a storage window at all? And where does this stop anyway, as on one hand I can keep going and wonder if the inventory window is useful as such (perhaps it's at least pretty to see them all!) or the container or ...which of those 100 total, in the end? (Then again, I'm a cli radical apparently (hence my asking here), regardless of all the fun I had making textures, heh.)
Windows and widgets aside for a moment, the GUI graphical elements as such would be a set of tiny icons like arrow-this-way and that-way, backgrounds, buttons, scrollbars and the like. Currently even this is a bit of a mess in that there's no standard set at all, but a proliferation of arrow-up and arrowUp that are two different arrows pointing "up" (and this is probably what they tried to solve with the whole "styles" layer of grime on top, myeah). Nevertheless and as boring as it sounds to do it, a basic set can certainly be extracted and then forced even upon the existing widgets, certainly. The potentially troublesome part though comes from a current ugly mix of actual GUI elements (e.g. buttons) and 2D representations of game objects (e.g. a key in inventory). The currently deployed client makes no real difference and effectively lists those 2D representations as GUI "resources" like all the rest (so for all the fun, one could in principle very well set their buttons to look like Omlette Du Disgorge, why not). While I have nothing against buttons looking like omlette-du-disgorge, game objects are a very different category from GUI elements and I don't think they should be mixed at all. Even focusing solely on the very practical perspective, GUI elements get their representations (if any) from a skin.zip file (if it exists at all), while game objects are first of all a potentially infinite set, not known upfront and even potentially changeable on an item by item basis during play. So question Q3 here would be: does this separation make sense or is there some better way to go about sorting this out? (As I'll need to sort out this part at some point anyway, it can't really remain as it is.)
All the above out of the way and in the open for discussion, I can happily report that the client's code continues to shrink for now as it increases in usefulness and otherwise there are still parts that will end up most likely discarded in the end, as they get increasingly left behind (the original net part comes first to mind). While there is still quite a lot to implement on both client and serverside, I think the next steps will have to be alternating client and server development, introducing the new things (finally!) and sorting out otherwise what troubles remain, as they pop up. In other words, there's still a lot of hard work ahead but finally getting out of the swamps and it's such joy to be out of them too!
The attempt is so visible and the whole thing is so broken from so many points of view that I don't even have the heart to laugh at it anymore. It's one of those things that are not even wrong yet. ↩
The corresponding parent classes are even called exactly that, for bonus points of similarity of names being a great thing in code: controlwindow and controlledwindow. ↩