ajakubo1/canvasmenu

HTML Canvas menu for games and applications

canvasmenu's Issues

Divide the library into separate files

I think main Menu constructor with it's logic should be separated from all the components logic if we want to support more than just a Button. I can write easy concatenation script to build the library (could cause problems on building on different platforms), or use Grunt or Gulp (what should be very easy), or we can use external libs like require or browserify (what will unfortunately make CanvasMenu heavier, but it will be possible to use it in development mode without building on each change).

Write Element code

Write Element code, which will be extended by new elements

Avoid global variables

For now the lib exposes two variables to the global scope - CM & BUTTON_STATES. It makes no sense at all for me since the latest is used only internally by the BUTTON component. It should be moved somewhere inside it.

Add a tutorial for creating your own elements

Add a tutorial for creating your own elements

Add button type: Multiple choice

New button type: Multiple choice - just as with other buttons, I want it to make them customizable, with support for adding animations

Simplify configuration objects

Using redraw in all possible places makes the library look heavy. How about removing this from the name of all the configurable variables?
So instead of:

var newGameButton = new Button({
    x: 200,
    y: 280,
    width: buttonWidth,
    height: buttonHeight,
    text: "New Game",
    redrawInactiveColor: '#FFFF00',
    redrawFocusedColor: '#660033',
    redrawDownColor: '#FF0033',
    redrawUpColor: '#330033',
    redrawInactiveFont: '#111111',
    redrawDownFont: '#111111',
    font: (buttonHeight * 2 / 5 ) + 'pt Courier'
});

we'll have:

var newGameButton = new CM.Button({
    x: 200,
    y: 280,
    width: buttonWidth,
    height: buttonHeight,
    text: "New Game",
    idleColor: '#FFFF00',
    hoverColor: '#660033',
    activeColor: '#FF0033',
    upColor: '#330033',
    idleFont: '#111111',
    downFont: '#111111',
    font: (buttonHeight * 2 / 5 ) + 'pt Courier'
});

Names like inactive, focused, down and up are not very intuitive. Maybe idle, hover, active (like in CSS) and (... something else for up but I have no idea what for now) sound better? And maybe instead of configuring font & color as two attributes, we can use the object? like this:

var newGameButton = new CM.Button({
    x: 200,
    y: 280,
    width: buttonWidth,
    height: buttonHeight,
    text: "New Game",
    idle: {
        color: '#FFFF00',
        font: ' #111111'
    },
    hover: {
        color: '#FFFF00',
        font: ' #111111'
    },
    active: {
        color: '#FFFF00',
        font: ' #111111'
    },
    up: {
        color: '#FFFF00',
        font: ' #111111'
    },
    font: (buttonHeight * 2 / 5 ) + 'pt Courier'
});

Methods could be added in the same way:

    idle: {
        color: '#FFFF00',
        font: ' #111111',
        fn: new RedrawIdleButton() // fn, event, method, or even 'before' or 
                                   // 'after' will work as a name here
    },

Add button type: Switch

New button type: boolean - just as with other buttons, I want it to make them customizable, with support for adding animations

Test deploy.js on windows

And make it running on windows boxes

Add button type: Radio button

New button type: Radio button - just as with other buttons, I want it to make them customizable, with support for adding animations

Create place to store library API

Create place to store library API - readme.md or gh-pages (or both).

Add tutorial for rebuild

Write short tutorial where library rebuild and customization will be described.

DEMO please

Is there a demo online? So I can quickly see the example? Thanks

Changes in API

I'm opening an issue to consult the community about API I'm giving for my library and it's intuitiveness. Some things may be unintuitive, or maybe I should open some property to the outside which has been closed?

From what I know, @michalbe has something in mind regarding this matter.

I'm pretty much open-minded to any suggestion. So... Let me know what you need, I'll consider it.

Remove automagic menu switching from the background

Setting new menu as a listener to switch between menus is not very clear. Setting a listener that will initiate the menu on fly will be more clear and self explanatory, without unneeded magic happening on the backstage.
So

optionsButton.clickHandler(optionsMenu);

will became:

optionsButton.on('click', optionsMenu.init);

This will simplify events handling in the library's code, and give more explicit control to the end user.

Move tutorial from README.md to Wiki

README is to large to use it effectively

Change `appendButton` to`append`

With new elements, appendButton method won't have any more sense. Adding Switch component or Radio control using appendButton sound strange. I suggest to rename the method to simple append

Making it scale-proof

Right now there may be some bugs when the library is used with scaled web page. Maybe not in animations or button sizes, but button listeners may cause some trouble.

jsFiddle

Add demo files for jsFiddle

Add scoping to the library

Creating separate global constructor for every component will cause mess in the code with more than just two components. So instead of:

var myMenu = new Menu({});
var button = new Button({});

Something like any of the solution below should be implemented:

var myMenu = new CM.Menu({});
var button = new CM.Button({});

var myMenu = new Menu({});
var button = new Menu.Button({});

var myMenu = new Menu({});
// DOM like API, inspired by document.createElement()
var button = myMenu.createButton({});

Describe tests

Describe, how should tests be made (for potential developers which might help with the library).

Add changelog

I need to add changelog to the library, so that I (and anyone else) would know what changes has been made with every version (I wanted to grasp the semantic versioning idea).

Add button type: Text Field

Add button type: Text Field - just as with other buttons, I want it to make them customizable, with support for adding animations

Event handlers support

If we plan to suport more events that just click (like onmouseover, etc.), we can use .on() method instead of the .clickHandler() what's not very intuitive. This pattern is known from jQuery, Angular, KO, and countless number of frameworks, so it will be easy to use for new users of CanvasMenu.
So example from the first sample:

button.clickHandler(function () {
    alert("You've clicked me!");
});

will become:

button.on('click', function () {
    alert("You've clicked me!");
});

For now each element can have just one clickHandler listener, it would be nicer to have multiple of them, like addEventListener compared to onclick. I suggest we should introduce this.events object, where we'll stack those. So

Button.prototype.clickHandler = function (handler) {
    this.onclick = handler;
};

can be expanded to look more/less like this:

Button.prototype.on = function (eventType, handler) {
    this.events[eventType].push(handler);
};

Write some tests

I need to write mocha test to have full coverage + make sure that any potential bugs will be detected when I change the code. Right now I have only Button tested, but I'm afraid it's not as much as I want.