Alignment of dlg:sliders in column beside dlg:canvas

Scripts & Extensions
1

I am making an extension which generates transformations to a sprite based on the value of several dlg:sliders

I have Dialog with a Preview dlg:canvas that shows what the sprite would look like with the effects at the sliders’ intensity applied

My structure is as follows:

dlg:canvas{
    id = "previewCanvas",
    width = canvasSize,
    height = canvasSize,
   <preview drawing code>
  }

dlg:label{
    id = "modelInfo",
    text = "blah blah blah"
  }

dlg:separator{ text = "Controls" }

dlg:slider{
    id = "Rotation",
    label = "Rotation:",
    min = 0,
    max = 359,
    value = 0,
    onchange = function() updatePreview() end
  }

dlg:slider{
    id = "Kzoom",
    label = "Zoom:",
    min = 0,
    max = 10,
    value = 0,
    onchange = function() updatePreview() end
  }

dlg:slider{
    id="Generic Slider"
    label="Generic"
    min=0
    max=1
}

currently, my dialog looks like this:
Preview on top
Sliders on bottom

I want my sliders to be in a column, to the right of the preview, to be able to fit export buttons and other things below them, what do I do?
Should I remove the dlg:separator{}? is there a type of implementation that simulates a hypothetical dlg:newcolumn(), in the same manner as dlg:newrow() works?

Please help me out, my only other option is opening the preview in a sprite, with the sliders and export in the dialog. Sliders and export with the dlg:canvas on top just don’t fit, at least not on my screen, at my resolution, at the size I want to render the canvas. Its the only way it’d fit

2

To be arranged in columns, afaik widgets have to be the same type (e.g., all sliders, all comboboxes), with only the leftmost widget allowed a label property. Otherwise a new row is triggered, even if always = false in all the other newrow calls.

I suppose you could make your own slider widgets, either as separate canvas widgets or as rectangles within one big canvas. In my experience, planning is needed to avoid a mess of variables, and it’s only worth doing if you will reuse that code a bunch.

Another option would be to create a child dialog, where the main dialog is set as the parent in the child’s constructor. When I’ve tried this, I had a button in the parent dialog show the child. To keep things simple, I set wait = true in the child show call.

childDialogEx
childDialogEx648×535 42.9 KB

[Edit: I’ve never tried tabs, but maybe that’s another option to organize big groups of widgets.]