Dialog Widget Modify Visibility in v1.3-beta 1

Hi,

Thanks for releasing the 1.3 beta! I look forward to exploring all the new features and changes. The built-in dark theme in itself is very cool and much appreciated.

Onto the bug report:

I’m trying out the beta on Windows 10.

I’ve been using – or maybe abusing – dialog onchange functions in one widget to modify the visibility of another widget.

dlg:combobox {
    id = "tweenOps",
    label = "Tween:",
    option = defaults.tweenOps,
    options = tweenPresets,
    onchange = function()
        local isPair = dlg.data.tweenOps == "PAIR"
        local md = dlg.data.clrSpacePreset
        dlg:modify {
            id = "aColor",
            visible = isPair
        }

        dlg:modify {
            id = "bColor",
            visible = isPair
        }

        dlg:modify {
            id = "clrSpacePreset",
            visible = isPair
        }
    end
}

I do this to keep a dialog relatively compact and to clarify which inputs are associated with which preset. In Aseprite v1.2.7, when a widget was hidden, the dialog would adapt, resizing the dialog’s height. In the beta, a dialog starts out looking like this:

dialogBug01

Then if I change the tween combo box from “PAIR” to “PALETTE”, the input widgets below it should be hidden. Instead, I get overlap:

dialogBug02

If I drag the dialog around by its title bar to trigger a refresh, then it changes to this:

dialogBug03

The overlap is gone, but the window hasn’t resized.

As I mentioned parenthetically, it’s quite possible that I’ve been abusing the api in the first place, and that older versions of Aseprite have been too permissive when they shouldn’t have been. If so, what would be a better way of going about this? Or should it just be avoided in the first place? Maybe some warnings in the scripting API documentation about resizing and refreshing a dialog, or modifying a widget from another could be added.

To figure out if it was my scripts causing the problem, I tried goofing around with some built-in menus, like the open new sprite and the color curves menu. The only other thing I noticed was that if I opened the color curves dialog from one of my script dialogs, resized the color curves dialog, then tried to return focus to my script dialog a white border appeared around the color curves dialog.

To clarify, I’m taking for granted that the expected Aseprite behavior is to not let you return focus from color curves back to a script dialog, and do not have an issue with that.

Thanks much for any insights y’all might provide. Congrats on the beta release!
Jeremy

1 Like

Hi @behreandtjeremy, check the new Aseprite v1.3-beta3 released today to see if this issue is fixed.

1 Like

The issue is fixed. Thank you!

1 Like