There's no other title fitting this. Here's the priceless context for the question above, context worth not one thousand but 100 000 lines of open source code, at the very least:

The above is the amazing result of trying to make use of all those psSlot and psSlotManager and pawsManager with their drag-and-drop wonder and marvel functionality, a true crowning achievement and glory of open source development. I ask the bloody "manager" class to drag something across the screen, as it claims it does and as a result it... breaks everything else pretty much, as nothing really updates anymore and the thing leaves a trail wherever it goes. But all is well, I'm sure, at least according to the manager and to everyone else working very hard and tirelessly and wonderfully and so on¹.

As I am apparently still naive enough to try and debug even the above sort of madness, I ended up in short order following a back and forth web of calls that are increasingly bringing to mind the way chaotic systems tread their path, ever random when it concerns the very next step, ever building nevertheless the same known shape in the end, as predictable as it can be. To give a clear view of how this goes, here it is: the widget calls the manager and the manager calls then the mouse class that calls back the widget that calls its parent class that calls back the manager that calls -at another time- the mouse class that calls...

Fortunately, those days I get at least faster out of such naivety and optimism and so I stopped just about there and didn't waste any further time with it but looked instead at some way to do it more directly. I suppose by now it's not surprising that all that crazy web of shit for "drag and drop" was anyway on top of and to the side of a somewhat less crazy "move with mouse" and then it turned out that even that was spurious and in fact the core class of ALL widgets in that bloody gui even had a method specifically for ..."center on mouse" sort of thing - and it even worked! So I made therefore my own "drag" as I had made my own prototype inventory window and my own prototype console overlay and my own seedling for the rest and let the many managers rot and fester in there unused and increasingly cut away from everything until that day when I'll finally get around to delete the whole mess too and there won't be any difference other than having suddenly a much smaller client that is however way more useful. At any rate, as a result of this most recent adventure, I stand corrected in my initial opinion that there might still be at least a tiny amount of utility in all that PS code - there isn't, there never was, there never can be.

As to the current status of those windows and overlays on my list: I have now a perfectly working way to drag stuff about (not yet to drop it but I don't expect that to be a huge problem, seeing how I am not going to touch any of the PS shit for it, not anymore), as well as working prototypes for both "Console" and "Contents" windows, with a few commands wired in already mainly for testing and poking that Contents view. Everything in those is created from code and without any xml in the loop so that the Contents view for instance can easily create as many slots as one wants, there is no limit of any sort anymore. The logical thing is probably to simply create slots *as needed* and without limit but for now I disentangled (and cut and wrote anew) enough of that underlying widget that has scrollbars - the scrollbars are useful but the design of it otherwise required a bigger hammer to bend into something usable in the least. As you might notice, I even gave in and added arrows for the scrollbars! In any case, all the images and graphics and colours are just for testing for now and I'll gladly use better ones /let someone else design any window whatsoever. For now, here's how the prototypes look like (in order: a test with adding and replacing stuff in the contents view, based on id of the *underlying* object instead of id of slot and other madness; the successful dragging of 'shrooms with icon and everything else):

For the next steps, there would still be first a bit of cleanup around those latest parts and assorted cuts made for it. Then I'll have to see if it makes perhaps more sense to get back one round to adding more working parts on the data side + communications and then let that drive any further development of the GUI itself. At least I'm now quite satisfied that I'll be able indeed, one way or another, to add to the GUI what may be required, even if some parts are very likely to throw some more wtf of the sort illustrated in the very introduction to this and eat as a result rather more time than I'd like to spend on them.

1. It could never not be great and wonderful anymore either, there is no such thing as something *not* being well, nowadays it's either great or otherwise forgotten or simply not mentioned for it's surely the mentioning that is causing the problem in the first place, obviously. ↩

Category: Coding, Eulora

Comments feed: RSS 2.0