mkosler / clash Goto Github PK

If I change the width and height, or add a specific new Image, what will happen?

Give the user the ability to separate their skin into separate files. Given that, if they follow a certain naming scheme and directory layout, ClashBuilder could programmatically build a new clash file, rather than rely on the user to provide the information

Clash and ClashBuilder are specifically made for the skin of the GUI elements; fonts need to be changed using HaxePunk's internal methods, not through anything here.

When I toggle between different styles on my (internal) demo, I am suffering a memory leak. Unsure whether this deals with my code or HaxePunk.

Currently, whenever I use Input.mouseX or any of it's variants, the location I get is on the opposite side of the point of the mouse; however, when using Input.mouseX for collision detection, it detects on the same side as the point.

This bug results on awkward behavior for my Handle GUI element.

Currently, there must be three different types of images for all derivatives of Button: normal, hover, and down. Give the option to fallback to using only normal if the user wants to.

Currently, all I can get is the simply haxedoc working. This does not provide enough information necessary for a library. I plan to use chxdoc, but there is currently a bug in it that doesn't allow me to compile the local version. Until that is fixed, this will still be marked as open, even though I have already added the necessary comment tags for the library.

Use HaxePunk's draw functions to create relatively simple skins.

Perhaps give the user the option to not give the widgets their Clash argument, which opens up some manual adjustment options.

Ooo, spooky!

My current hang-up seems simple. I want to allow for people to use different skinning styles or methodologies when using Clash. The three main ones are:

• Single file, where all of the widget images are on a single bitmap, and the user specifies the clipRect for each widget (currently supported);
• Directory-based, where each widget (and each slice within a widget) are on separate bitmaps, and their association is determined by their relative path from a parent directory;
• Mixed, where each widget's associated bitmaps are located via relative paths, but the slices of the widget are within the same file.

The issue I am having is that I would like to have the latter two skinning styles be able to conform to the current .clash file hierarchy, but it is highly unlikely that I will be able to do so. This would lead to a decent amount of refactoring within the Clash data structures so that I can hide the inconsistencies between the types.