I'm currently making a docking panel library for AIR! Video demo below.
https://www.youtube.com/watch?v=YeprS-1gvLI

At 2/16/18 12:42 PM, Gimmick wrote: I'm currently making a docking panel library for AIR! Video demo below.
https://www.youtube.com/watch?v=YeprS-1gvLI

Can I commission you to do my UI code? It's all XML layout in HaxeUI, but I still hate it...

I like it hundreds of times more than actually coding my own UIs, but I still hate it

At 2/16/18 09:43 PM, MSGhero wrote:

At 2/16/18 12:42 PM, Gimmick wrote: I'm currently making a docking panel library for AIR! Video demo below.
https://www.youtube.com/watch?v=YeprS-1gvLI

Can I commission you to do my UI code? It's all XML layout in HaxeUI, but I still hate it...

I like it hundreds of times more than actually coding my own UIs, but I still hate it

Heh, call me crazy but I didn't like using FXML to create UI in Java, and actually preferred putting all the layout in code for some reason (if I had to guess, a - weak - possible reason being that I had to change the XML files and I kept forgetting to do so, but doing it in code was more natural and I forgot less...maybe I'm just used to the old way of doing it.) If HaxeUI's anything like FXML, then I'll have to pass up on that offer :P

FWIW, you can change all the controls in this library, no need to get stuck with the default :D I'll probably release the library sometime next week or the week after that. I might also do a writeup later on how it works if anyone's interested.

Edit: Would this library be compatible with OpenFL?

At 2/17/18 12:25 AM, Gimmick wrote: Edit: Would this library be compatible with OpenFL?

If it’s just as3 code and not an ANE, yes after converting it to hx. If it’s an ANE, yes but only for AIR export.

OpenFL (Lime really) has native window support on cpp targets, which would be interesting to see here.

At 2/17/18 08:32 AM, MSGhero wrote:

At 2/17/18 12:25 AM, Gimmick wrote: Edit: Would this library be compatible with OpenFL?

If it’s just as3 code and not an ANE, yes after converting it to hx. If it’s an ANE, yes but only for AIR

Nope, the best part about this library is that it requires no ANE's whatsoever! The same code should work on Mac & Windows without any changes!

Have nothing to do atm so might as well describe the system I'm using for the docking library I'm working on.

Basically, there's 2 parts: The containers and the docking mechanism.

-
The containers form a simple tree. Each container has references to two other containers, and the default container has either two containers immediately below it, or it has none. There's also a "side" for the containers, either top and bottom, or left and right, and of course, center (which is that container itself).

Whenever panels (or anything, really) are added, it's added to the container by default (fill), or you can choose to add it to a particular side (i.e. left, right, top, bottom). If you add it to the left side, then - and here's the important bit - it creates two new containers, and moves all its contents to the opposite side of the container you want to add to (e.g. if you want to add a panel to the left side, it creates two containers and shifts everything into the right side, including the containers below it, etc.).

If there's already a side, say left, then the side you want to add it to is searched. If it exists, then it's added there; otherwise, it's again created and the contents shifted again, but this time the side is that of the complement of the new one supplied. For example, suppose there's a container with side LEFT (and implicitly, RIGHT) and if you want to add anything to the left or the right side, then it will do so. However, if you want to add something to the bottom side, it'll create a new pair of containers, top and bottom sides, shift everything to the top, and add whatever you want to add to the bottom.

In short, it's a basic binary tree. I was considering using a quadtree earlier (where there was a distinct left, top, right and bottom for each) but I came across issues with resizing: which one took priority first? Now it's just based on the order in which they were added, and it looks cleaner too. This has its problems, but there's ways to work around it.
-

There's two parts to docking: 1) finding the mouse's position on the screen (not just within the bounds of the program) and 2) finding out what the mouse is currently under.

As it turns out, the NativeDragEvent and NativeDragManager handle both those tasks!

While dragging, the stage coordinates are used to find the position of the mouse (this works even when dragging outside the bounds of the window) and it's converted to screen coordinates using the nativeWindow.globalToScreen function. Then, while the mouse is over a container (by using a NativeDragOver event) it'll show where to dock, and if the user drops it on a given side then it'll auto-dispatch a NativeDragDrop event. This is then used to check whether the user has dropped it on a container within a window, or not (the action associated with the drag is null, if not dropped over a container) and from there, the window for that panel's container is displayed at that location.

N.B.: Each panel has an associated container that's "parked" in a window of its own. Whenever a panel is to be docked, it's moved there and that window displayed. Other panels can also be docked in those containers, and when moving and merging containers, the contents of the containers are moved, not the containers themselves, so the containers of the panels remain parked throughout the lifetime of the program. New containers are created whenever a panel is nested deeper and deeper, rather than moving their parked containers, because it's easier to handle.

If anyone has any questions or suggestions, feel free to ask/tell. I'm currently stuck on a problem involving the sizing of the containers (when one container has one side with a panel, and the other side with multiple layers of containers, all empty save the last one, what happens? How would the root-level container "know" that there's empty space everywhere except the deepest level, and the other side of the root level?)

At 2/15/18 02:52 PM, Luis wrote: i still make all my art in flash mx

That was the first version of Flash I ever used. I fully approve of your choice

Here comes yet another Flixel-OpenFL compatibility attempt. Good news is that this one isn't a nightmare merge conflict. https://github.com/HaxeFlixel/flixel/pull/2133

A mod for the OpenFL forums said like 75% of threads are flixel people asking about things that were already fixed up to two years ago, so this helps them as well.

At 3/1/18 06:20 PM, MSGhero wrote: Here comes yet another Flixel-OpenFL compatibility attempt. Good news is that this one isn't a nightmare merge conflict. https://github.com/HaxeFlixel/flixel/pull/2133

A mod for the OpenFL forums said like 75% of threads are flixel people asking about things that were already fixed up to two years ago, so this helps them as well.

"I couldn't build for Flash on this line, with error: "flash.display.Graphics has no field drawQuads". Using latest OpenFL and lime develop branches."

Would that be fixed by making a call to drawTriangles() with two triangles per Quad instead?

At 3/4/18 12:30 PM, Gimmick wrote: "I couldn't build for Flash on this line, with error: "flash.display.Graphics has no field drawQuads". Using latest OpenFL and lime develop branches."

Would that be fixed by making a call to drawTriangles() with two triangles per Quad instead?

That was fixed a few days ago on dev, are you using the latest latest? Might need to bring it up with Joshua.

At 3/4/18 01:05 PM, MSGhero wrote:

At 3/4/18 12:30 PM, Gimmick wrote: "I couldn't build for Flash on this line, with error: "flash.display.Graphics has no field drawQuads". Using latest OpenFL and lime develop branches."

Would that be fixed by making a call to drawTriangles() with two triangles per Quad instead?

That was fixed a few days ago on dev, are you using the latest latest? Might need to bring it up with Joshua.

Er, I'm just browsing the github page of it and that seems to be the latest pull request. Also, it might just be me doing something wrong but the dev branch on github shows flixel/graphics/tile/FlxTilesheet.hx as practically empty.

At 3/5/18 11:28 AM, Gimmick wrote: Er, I'm just browsing the github page of it and that seems to be the latest pull request. Also, it might just be me doing something wrong but the dev branch on github shows flixel/graphics/tile/FlxTilesheet.hx as practically empty.

Wait, I meant latest latest OpenFL along with the latest version of the PR for flixel. FlxTilesheet isn't empty in the PR.

At 3/5/18 05:59 PM, MSGhero wrote:

At 3/5/18 11:28 AM, Gimmick wrote: Er, I'm just browsing the github page of it and that seems to be the latest pull request. Also, it might just be me doing something wrong but the dev branch on github shows flixel/graphics/tile/FlxTilesheet.hx as practically empty.

Wait, I meant latest latest OpenFL along with the latest version of the PR for flixel. FlxTilesheet isn't empty in the PR.

Nope, it's still drawQuads().

At 3/6/18 05:33 AM, Gimmick wrote:

At 3/5/18 05:59 PM, MSGhero wrote: Wait, I meant latest latest OpenFL along with the latest version of the PR for flixel. FlxTilesheet isn't empty in the PR.

Nope, it's still drawQuads().

Wait, nevermind, drawQuads() exists in the OpenFL branch.

At 3/6/18 06:17 AM, Gimmick wrote: Wait, nevermind, drawQuads() exists in the OpenFL branch.

Let me know how your performance goes using it. It's a far simpler (and at this point probably better) PR to merge in compared to the other one.

As promised, here's the docking framework I'd been working on earlier. (note, I've just uploaded everything on Github at once, and the experimental branch is technically the one you'd want to use, since it's based on whatever needs my current, and more practical, use case is rather than whatever is in the demo) Maybe one of you Haxe whizzes can work on a port if you're interested, for some reason HaxeDevelop always fails build due to some port or the other always being in use :\

If you have any questions, feel free to ask. Also, I seemed to have joined the dark side: just a few posts earlier, I was ranting against AS3YAML's supposedly unnecessary use of layers of interfaces and other design patterns, but I seem to have fallen into much the same trap...it's now I realize that that's there because extensibility was desired. That said, this should work with any setup! (...although it seems like a case of "favor composition over inheritance" taken to the extreme fwiw)

At 3/6/18 07:27 PM, MSGhero wrote:

At 3/6/18 06:17 AM, Gimmick wrote: Wait, nevermind, drawQuads() exists in the OpenFL branch.

Let me know how your performance goes using it. It's a far simpler (and at this point probably better) PR to merge in compared to the other one.

I see. I wasn't personally the one using OpenFL, though, that was a quote from the pull request linked earlier. I should imagine it's not detrimental to performance, though.

Just noticed @Diki comments more on necro threads than anyone else here.

At 3/10/18 10:43 PM, MSGhero wrote: Just noticed @Diki comments more on necro threads than anyone else here.

Feels good man. Come at me.

At 3/11/18 03:10 PM, Diki wrote:

At 3/10/18 10:43 PM, MSGhero wrote: Just noticed @Diki comments more on necro threads than anyone else here.

Feels good man. Come at me.

Poor ASHTONSPAFFORD won't realize the thread was locked for another decade

@MSGHero @GeoKureli would you be interested in doing a code review of AIRDock? I'm not sure whether I'm falling into the trap of cargo cult programming, or whether having 40+ classes is justified (lol)

At 3/30/18 01:06 PM, Gimmick wrote: @MSGHero @GeoKureli would you be interested in doing a code review of AIRDock? I'm not sure whether I'm falling into the trap of cargo cult programming, or whether having 40+ classes is justified (lol)

I'm pretty terrible at looking through an entire API for constructive criticism, I'll try but I recommend typing out a how-to page describing exactly how devs should plan to utilize it, I tend to do this as early as possible and I usually end up finding what's weird about my code, once the intended utilization is solid you just work backwards to make it work, then optimize it

At 3/30/18 01:06 PM, Gimmick wrote: @MSGHero @GeoKureli would you be interested in doing a code review of AIRDock? I'm not sure whether I'm falling into the trap of cargo cult programming, or whether having 40+ classes is justified (lol)

I have to give your code an F because your braces aren't cuddled.

At 3/30/18 05:40 PM, MSGhero wrote:

At 3/30/18 01:06 PM, Gimmick wrote: @MSGHero @GeoKureli would you be interested in doing a code review of AIRDock? I'm not sure whether I'm falling into the trap of cargo cult programming, or whether having 40+ classes is justified (lol)

I have to give your code an F because your braces aren't cuddled.

I'm shocked, I honestly thought you'd have given an F for using hungarian notation instead. (Also, it is cuddled - functions that are one line long have cuddled braces! muhaha)

At 3/30/18 01:17 PM, GeoKureli wrote: I'm pretty terrible at looking through an entire API for constructive criticism, I'll try but I recommend typing out a how-to page describing exactly how devs should plan to utilize it, I tend to do this as early as possible and I usually end up finding what's weird about my code, once the intended utilization is solid you just work backwards to make it work, then optimize it

I see! I'll make a writeup on it sometime next week or so. (To be pretty honest, I think I've been coding for how it could be used rather than how it would be used - most of the things I've made with it are pretty basic too and a lot of it's just "the default")

At 3/30/18 01:06 PM, Gimmick wrote: @MSGHero @GeoKureli would you be interested in doing a code review of AIRDock? I'm not sure whether I'm falling into the trap of cargo cult programming, or whether having 40+ classes is justified (lol)

Literally didn't even look beyond seeing a 2000 line class. No class should ever be 2000 lines :)

At 3/30/18 01:17 PM, GeoKureli wrote: I recommend typing out a how-to page

I've been writing a wiki! Does this look OK enough as a tutorial/explanation? I'll be writing an API reference later (way, way later, though)

At 4/6/18 04:07 PM, Rustygames wrote:

At 3/30/18 01:06 PM, Gimmick wrote: @MSGHero @GeoKureli would you be interested in doing a code review of AIRDock? I'm not sure whether I'm falling into the trap of cargo cult programming, or whether having 40+ classes is justified (lol)

Literally didn't even look beyond seeing a 2000 line class. No class should ever be 2000 lines :)

Trying to break it down, but no matter which way I see it, that's more or less the "brain" of the class - everything is handled by it. The only way I can think of breaking it down is to have delegates which handle each task separately, but it seems like damn near everything cross-cuts everything else. I'll take a look at it after my exams get over - maybe end of May or so :\

At 4/6/18 04:07 PM, Rustygames wrote:

At 3/30/18 01:06 PM, Gimmick wrote: @MSGHero @GeoKureli would you be interested in doing a code review of AIRDock? I'm not sure whether I'm falling into the trap of cargo cult programming, or whether having 40+ classes is justified (lol)

Literally didn't even look beyond seeing a 2000 line class. No class should ever be 2000 lines :)

Looked at the class again, most of it's boilerplate getters and setters, single line functions, utility functions, import statements, about 200 lines of an internal class and the rare comment. There's about 12 large functions which seem central to the class and the rest, well, not quite. How should I go about refactoring this so that it's reduced? Most of the variables seem to just be connections to interfaces themselves, suggesting there's not really much that the class does on its own (making this more like a manager class instead).

At 4/20/18 01:05 PM, Gimmick wrote: How should I go about refactoring this so that it's reduced?

I do several things when I notice a class getting large, but really I now do those things before a class ever gets large:

I'm a fan of collecting related info into single classes. So in your class you have a bunch of things with a "cl_" prefix. Not sure if they're all related, but I might take all and put them into a single "cl"-related class. Maybe your main class manages them to a certain degree, which you could replace with functions that are defined in the other class.

You have a lot of event handling related code, and I feel like all of that could go somewhere else. Not just the functions, which could be inconvenient to move to a new class, but every variable the functions touch within reason. Up to you how to define it, whether AIRDockManager or EventManager or whatever, but I'm mainly saying that your main class should never see the details of "event management" of any container.

Maybe a public API that calls private functions located in other classes, and those are organized somehow.

It's really an organization kind of thing, and much easier to do with experience early on in a project. Some classes "require" thousands of lines because all of that is appropriate to handle in that class, but that's usually a flash.display.Sprite or flixel.FlxSprite kind of thing.

At 4/20/18 08:59 PM, MSGhero wrote:

At 4/20/18 01:05 PM, Gimmick wrote: How should I go about refactoring this so that it's reduced?

I do several things when I notice a class getting large, but really I now do those things before a class ever gets large:

I'm a fan of collecting related info into single classes. So in your class you have a bunch of things with a "cl_" prefix. Not sure if they're all related, but I might take all and put them into a single "cl"-related class. Maybe your main class manages them to a certain degree, which you could replace with functions that are defined in the other class.

You have a lot of event handling related code, and I feel like all of that could go somewhere else. Not just the functions, which could be inconvenient to move to a new class, but every variable the functions touch within reason. Up to you how to define it, whether AIRDockManager or EventManager or whatever, but I'm mainly saying that your main class should never see the details of "event management" of any container.

Maybe a public API that calls private functions located in other classes, and those are organized somehow.

It's really an organization kind of thing, and much easier to do with experience early on in a project. Some classes "require" thousands of lines because all of that is appropriate to handle in that class, but that's usually a flash.display.Sprite or flixel.FlxSprite kind of thing.

I see, so the AIRDock class would delegate all the "nitty gritty" of docking (event handling related stuff) into a separate class -- but it'd require the previous cl_ variables (and sadly no they're not related at all, the cl_ just happens to be a wildcard prefix for instances and "other" classes).

Should I keep those variables in the AIRDock class and have it manage them directly, and just pass those variables into the event handling class for it to manipulate? It'd be a bit counterproductive to move all those variables directly into the event handling class, because then I'd eventually end up with the same AIRDock class, just with a different name.

Thanks for the advice, I'm still figuring this stuff out. I'll take a look at it in a few days or so when I get more time.

Flixel was FINALLY updated to the latest OpenFL version. It's actually been years, and dozens of Flixel's issues on GitHub are being closed for the simple fact that newer OpenFL already fixed them.

At 4/22/18 08:47 AM, MSGhero wrote: Flixel was FINALLY updated to the latest OpenFL version. It's actually been years, and dozens of Flixel's issues on GitHub are being closed for the simple fact that newer OpenFL already fixed them.

Wait, so OpenFL fixed Flixel's issues in OpenFL itself and Flixel just went "oh, it's already fixed, nothing to be done here", or OpenFL fixed Flixel's issues in the Flixel project and it was updated?

At 4/6/18 04:07 PM, Rustygames wrote: Literally didn't even look beyond seeing a 2000 line class. No class should ever be 2000 lines :)

If it's possible, can you go through it again? Removed a helluva lot of redundant code and now the total LOC is around ~1700, or 1500 sloc according to Github (although when I counted it manually it was about ~1100 - maybe it doesn't account for comments?)

Edit: Can't believe it's been more than a month since the last post :\