Patch through GUI

Started by
-1 comments, last by Trienco 18 years, 4 months ago
Just some ideas and left overs from the last "project", but if anybody with experience with some large and complex programs would have any comments or insights that would be appreciated. Last time around I did the whole boring Gui part first. Managing characters, equipment, the whole drag and drop stuff. Then it was time to do more of the actual game (a pretty boring combat tool for the old D6 system with optional 2D/3D, square/hex/polynet maps). Laziness (and lack of planing) made me create this map as another gui element and add more and more game logic to it. But it worked nicely, as part of the gui it had its click, drag, move and key functions called and just added some more specific callbacks (onCharacterSelected instead of onClick, etc.). Only drawback was that it needed to have the focus to register key events. Planned on solving this by allowing to register a default receiver for events that aren't handled by any other element. Writing yet another Gui I am wondering if this might actually be a useful (optional) feature. So let's say you are using input library x where you would usually go and register callback functions for mouse and key events. It would seem logical that these callbacks pass them on to the gui and if the gui doesn't handle them will pass them on to the game. But say the gui is like one of these old Voodoo cards and lets you register callback functions for unhandled mouse and key events, you would now register the gui input functions as callbacks for the input function and the games input functions as callbacks for the gui. The functions would still return whether they handled it or not, so you're not forced to use this. Question is: would that seem like a concept that makes using it more comfortable or am I missing a lot of special cases and difficulties that would reduce it to useless bloating?
f@dzhttp://festini.device-zero.de

This topic is closed to new replies.

Advertisement