Github, Editor Camera, and Checkboxes
Hey Folks! Hope everyone had a good weekend. More of the same here: baby stuff, chores, and brief snippets where I get to read "Leviathan Wakes" and play a bit of "Duskers." Enjoyable, both, but gone are the days where I can sit down for more than 30 minutes at a time, though :)
Before resuming work on the editor today, I decided to see if I could integrate my textfield changes back into Github. It took about an hour to setup Github and create a test project using my fork of OpenFL. And then about another hour of me climbing down the rabbit hole of OpenFL TextField states before I decided this wasn't going to happen. The thing I've done to make it work for me makes some serious assumptions about the situation that won't apply to most. (TextFieldTyle = INPUT instead of DYNAMIC) And doing it the "right" way would mean rewriting TextField to untangle the text selection from the text input code.
Maybe some other time I'll do that. But it's been over a week since I've made anything resembling progress, and I'm desperate to move forward on something. Sorry open source community!
Turning back to the editor, I almost immediately hit another hang up. (FFS!) This time, I think it was neko target and/or OpenFL "next" incorrectly detecting when the game loses focus. I'd click in a text field, then click outside a text field, and the whole app would "pause," locking out all other input. Alt-tabbing would unpause again, but this was not going to be workable. Clearly users would need to click things in the editor without HaxeFlixel locking them out every few seconds.
I briefly considered making a new "data editor" project that just used OpenFL and ditched Flixel. I could then ship the game with an app to play and an app to edit.
However, I quickly realized that I'd need to do some fancy source-sharing between two projects to ensure parity between the data classes and data-reading code. No way. I'm not going to test out FlashDevelop's code-sharing tools. Not after a week of mind-numbing agony trying to get just basic code features working.
So I decided to make my project load an OpenFL-based editor right from the get-go. Later, when I have more patience, I can make a menu screen to let the user choose between play mode and edit mode, and load Flixel or not accordingly. For now, though, I'm hard-coding the damned thing so I can get something on-screen.
After this, I finally had a couple hours of productivity, mainly getting the editor to pan around using WASD, zoom using the mousewheel, and click/draggable data nodes. It was nice to be effectual for a few moments.
Then, I decided to add a checkbox to the data node, and we're back in "what the hell" territory. StableXUI checkboxes are super-easy to add to the screen, but don't show up. I tried looking through the docs for it, but it appears last week's comment about it having good documentation only applies if you're specifying layouts in XML. Hard-coded layouts, not so much.
(Why not specify in XML, you ask? Well, I tried that. But there was no way I could tell to instantiate the same UI multiple times and apply a different set of data to each UI. Adding IDs to each field seemed to crash the app as soon as the second copy of the UI was loaded, since StableXUI seemed to require each ID be unique.)
I tried guessing a few times on input parameters, but no dice. Then, on a whim, I searched on Google and found a Google group for StableXUI. Lo and behold, the latest thread was someone having the exact problem I was. And the dev replied!
Unfortunately, doing what the dev suggested doesn't seem to work.
It's been one of those days. And looking back, it's been one of those days for almost a fortnight. Try one thing, fail. Try to fix it, fail. Discover an alternative, looks promising, fail. Try to roll your own, fail a different way. Finally figure out a way to work around the issue, fail at a new thing. Repeat.
I am really not a fan of open source right now.