Feedback on potential new layout creation method

[liquid8d]

Hey all,

I've been gone for awhile, but I will be plugging away again soon on updates for the animate module. In addition, I sparked a quick idea for fast layout creation and want to get some feedback. Layouts in AM are super flexible because anybody can code whatever they dream up - but sometimes that can be a curse, when everyone does everything their own way.

For layouts, most of the time we are just describing the objects we want on the screen (positions, appearance, etc) so I came up with this quick idea of creating scenes in a single object map:

Code: [Select]

fe.load_module("SceneCreator");

SceneCreator.init({
        scenes = [
        //our first scene
        {
            id = "default",
            type = "scene",
            objects = [
                { id = "title", type = "text", msg = "[Title]", x = 0, y = 10, width = fe.layout.width, height = 30 },
                { id = "artwork", type = "artwork", x = 10, y = 90, width = fe.layout.width * 0.5, height = (fe.layout.width * 0.5) / 1.778 },
                { id = "year", type = "text", msg = "[Year]", y = 50, width = fe.layout.width, height = 30 },
                { id = "listbox", type = "listbox", x = 25, y = 100, width = 300, height = 400 },
                { id = "layer1", type = "surface", objects = [
                    { id = "something", type = "text" msg = "This is on a different layer" }
                ]}
            ],
            actions = [
                { action = "onLeft", action = function() {
                    SceneCreator.action("show", { target = "layer1" } )
                }},
                { action = "onRight", action = function() {
                    SceneCreator.action("hide", { target = "layer1" } )
                }},
            ]
        },
        //our second scene
        {
            id = "about",
            type = "scene",
            objects = [
                { id = "title", type = "text", msg = "About SceneCreator", width = fe.layout.width, height = 30 },
                { id = "author", type = "text", msg = "author: liquid8d", y = 50, width = fe.layout.width, height = 30 }
            ]
        }
    ]
});

So in this scenario, we are describing everything upfront - all objects are defined, given an id and placed with the specified properties. You'll notice I have it set for multiple scenes, which would allow for different views that could be switched based on actions that are also defined. Actions would be tied to the various events in AM, and hopefully ease the pain of creating custom functions to handle onKeyUp or other common actions.

This is based on the typical Javascript style init format that many js libraries use. This is still a bit of a draft, but creating a layout this way puts all objects at the forefront of the layout code, in a pretty easy to comprehend definition. You could still do whatever you want once the objects are created, but my hope is actions will allow you to do the most common things, even allowing you to show or hide surfaces (layers) or switching between different "scenes".

Of course, I am also setting it up to where you can register creation of other objects or register other actions, so it can be extended fairly easily and I will make it seamless to add animations as well. Even better, this will translate pretty easily to/from JSON, which I have even more exciting plans for

What do you think?

[keilmillerjr]

Looks like an interesting concept. I'd like to more about the actions. Possibly very basic sample theme?

[liquid8d]

Yeah, as soon as I get some of that added I'll put it on here. If you have thoughts on what you'd like to see let me know, but here's the concept when you would add your own:

Code: [Select]

SceneCreator.register("action", {
    show = function(target) {
        target.opacity = 1.0;
    },
    hide = function(target) {
        //handle close of target
        target.opacity = 0;
    }
})

Basically you are creating functions that will do something with the target, so now you can have something like:

Code: [Select]

    SceneCreator.action( "hide", { target = "someObject" } )

Those actions can be hooked to events that occur - basic events would be of course for key  handlers like  onUp/Down/Left/Right/Select/Back, but can be expanded to include other events..

Also, this is the other thing that would go along with it:

[liquid8d]

I'm still working on this and making some progress. I dumped the initial configuration and tried to simplify things a bit just using chained functions:

Code: [Select]

fe.load_module("scene-creator")
fe.load_module("animate2")

SceneCreator
    .scene("main")
        .add("artwork", { artwork = "snap", x = 0, y = 0, width = 640, height = 480 } )
        .add("image", { id = "darken_art", x = 0, y = 0, width = fe.layout.width, height = fe.layout.height, file_name = "pixel.png", red = 0, green = 0, blue = 0, alpha = 125 })
        .add("text", { x = "10 + 50", y = 0, width = 300, height = 30, msg = "[Title]" })
        .add("text", { id = "year", x = 25, y = 60, width = 200, height = 30, msg = "[Year]" })
        .add("text", { id = "man", x = 25, y = 95, width = 200, height = 30, msg = "[Manufacturer]" })
        .add("listbox", { id = "list", x = 350, y = 25, width = 200, height = 300, bg_red = 0, bg_green = 0, bg_blue = 0, bg_alpha = 200 })
    .scene("test", { x = 0, y = 380, width = 640, height = 480 } )
        .add("image", { file_name = "pixel.png", x = 0, y = 0, width = 640, height = 100, red = 100, green = 50, blue = 100, alpha = 200 })
        .add("artwork", { artwork = "snap", x = 0, y = 0, width = 320, height = 240 } )
        .add("text", { x = 0, y = 30, width = 640, height = 30, msg = "[Title]" })
    .on( "custom1", function(str) {
        fe.signal("reload")
    })
    .on( "Transition.ToNewSelection", function(opts) {
       PropertyAnimation( SceneCreator.find("main.year") ).from( { y = 0 } ).to( { y = 60 } ).play()
       PropertyAnimation( SceneCreator.find("main.man") ).from( { y = 0 } ).to( { y = 140 } ).play()
    })
    .on( "Transition.ToNewList", function(opts) {
       PropertyAnimation( SceneCreator.find("main.list") ).from( { x = fe.layout.width } ).to( { x = 120 } ).play()
    })

So .scene() begins a new scene (aka surface layer) and .add(type) adds an object of the specified type, with the properties provided. Then .on(event) can be used to trigger a function for transition, tick or signal callbacks

You can access the objects by giving them an id property using SceneCreator.find("scene.objectid") - here I'm using it with my   animatev2 module to add animations on certain transitions.

If I can get this to work properly like this, you can fairly easily see the scene setup for the layout, and still do custom code later on accessing the objects.

Still working out a bunch of kinks, but let me know if that makes sense or you have any suggestions.

[bundangdon]

Anything that makes layout creation easier and more effective, especially for us non-programmer types, I'm all for it!

[verion]

Looks great, and the second attempt looks even better.

One question though - is this .scene object similar to surface?
I can see that "test" has defined size but "main" is not - so it is full screen in x=0, y=0?

----

From the designers point of view the biggest challenge is to make layout responsive (adaptable to screen aspect).
Ideally I would like to have SCENES that can function like objects - object that I can place relative to left edge, right edge or center of the screen - see the attached scheme.

If you are designing for one aspect - it really doesn't matter. But for the "responsive" layout it would make a world of difference.

[liquid8d]

A scene IS a surface, but a surface where the scenecreator manages some things for child objects. Yes if you don't define the values for the scene it would default to fill the screen. But you can still add surfaces to a scene (surface on a surface) for say a sub-menu or something. I might even make an "alias" for surface as layer, since that would fit the idea of a scene with multiple layers. But the idea of a scene is the whole screen layout (all displayed objects) and then you can switch from one scene (screen) to another. It's much like the idea of how Overlays are implemented now, but making your own.

A sample use case would be you have a game selection screen. Press right and you are shown a whole different screen with additional game information, press left to switch back to the game screen. ArcadeBliss a keyboard search, that could be a separate scene. I'm playing around a bit to make it more seamless and understandable. There's a lot of quirks that have to be dealt with like if there is audio playing and you switch scenes, do you want the audio muted, etc..

I tried to tackle the multiple aspect (aka "responsive") topic before, but it can get a little muddy - this might be something scenecreator could handle by creating separate scenes for different aspects. My suggestion right now is if you want to support multiple aspects (and everyone should!), use a squirrel table for all your values - it's a method I suggest any layout creator use rather than have numbers thrown all over the layout code or managing multiple layout files per aspect

Code: [Select]

class UserConfig {
    </ label="Aspect", help="The aspect to use", options="16x9,4x3", order=1 />
    aspect="16x9";
}
local flw = fe.layout.width
local flh = fe.layout.height

//set properties on an object
function setProps(target, props) {
    foreach( key, val in props )
        try { target[key] = val } catch(e) {}
}

//use percentages of a value
function per(percent, value) {
     if ( percent == 0 ) return 0
     return ( percent / 100.0 ) * val.tofloat()
}

local settings = {
   "16x9": {
      title = { x = 0, y = 0, width = percentage(33, flw), height = percentage(3, flh), msg = "[Title]", showThis = false }
   },
   "4x3": {
      title = { x = 0, y = 0, width = percentage(25, flw), height = percentage(3, flh), msg = "[Title]", showThis = true }
   }
}

local config = fe.get_config();
local aspect = config["aspect"]

//now start adding objects from settings and setting their properties
local title = fe.add_text("", -1, -1, 1, 1)
   setProps(title, settings[aspect].title)

//access aspect specific property settings like this
if ( settings[aspect].title.showThis == false ) title.alpha = 0

In this case, you do have to redefine the properties for every object in every aspect, but it will make it very simple to adjust settings later. setProps takes care of setting all properties from the squirrel table (as long as they exist) but you can even store non-property values in there that can be used later in your code The per function lets you do percentages of a value like flw or flh, making it even easier to adjust for each aspect, rather than breaking out a calculator..

[jedione]

Q:  sorry but what is point of new layer even....
i just layer everything accordingly  ...pinch and skew,, animate,,   and so on...
is their a benefit to doing it like this?  performance maybe

i think im just a bit lost on the concept and coding....thanks for any info..
i think my problem is i learn by example...if i could see it in action and with a bit of code in a layout
it would hit home.....

ill wait to see ....your an amazing script maker!    thanks..

 

 

[keilmillerjr]

Q:  sorry but what is point of new layer even....
i just layer everything accordingly  ...pinch and skew,, animate,,   and so on...
is their a benefit to doing it like this?  performance maybe

i think im just a bit lost on the concept and coding....thanks for any info..
i think my problem is i learn by example...if i could see it in action and with a bit of code in a layout
it would hit home.....

ill wait to see ....your an amazing script maker!    thanks..

I think the idea behind this is to become uniform and organized. Easy to read and manage.

[liquid8d]

Right, I'm just trying to make things easier for everyone, regardless of their level of coding experience. A layout is pretty simple:

 - create and position objects (hopefully for multiple aspects and orientations)
 - listen for events ( transitions, ticks, signals) and act on them (update objects, run some custom code, show something else, etc)

But everyone goes about that a different way. I'm trying to simplify that by having a standard way to create and positioning objects, hook up the callbacks, and work with multiple surfaces in one simple to use module. If it looks confusing to you, it might need some more work Tell me what would make creating layouts easier for you.

That code above is just one example of how to create and maintain a layout with multiple aspects, which is something many layouts don't do. It's pretty easy to implement, but there isn't many examples on how to do it because everyone goes about it a different way. Just keeping all your values in a squirrel table at the top of your layout is something a lot of layout designers should take advantage of, but don't.

[keilmillerjr]

Some excellent coding concepts/tips in here. The setprops is genius. I'm currently defining the values in a hash but setting them manually.

[verion]

Sounds great! Because the best AM feature (you can do anything you want - if you can code it by hand) can be the most intimidating one. At least for non-coder. And your approach looks more understandable (at least for me).

If you want any help with making/designing a sample layout - let me know. I'll be more than happy to help with the design part of the equation.