Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dialog.bounds gets reset if the dialog is closed (cannot pass it to a second dialog) #3018

Closed
IgnacioLuxP opened this issue Oct 21, 2021 · 1 comment
Labels
bug high priority scripting Related to scripting API
Milestone

Comments

@IgnacioLuxP
Copy link

IgnacioLuxP commented Oct 21, 2021

A common practice when writing the UI for a script with multiple tabs is to pass the bounds of the first dialog (dlgA) to a new dialog (dlgB) in order to move it to the dlgA's position. This does not work as expected in 1.3-beta6. The (x, y) for dlgB.bounds is reset to (0, 0), moving the second tab to the top left corner of the app's window.

To reproduce, use the Wizard Example script from the sample scripts. It occurs with any script that uses the same approach.

(edit) IMPORTANT: This only seems to occur with the "UI with multiple windows" option enabled (in Edit > Preferences > Experimental > UI with multiple Windows)

The workaround seems to be to cache the previous dialog's bounds and pass this copy to the new dialog. The second time the dialogs are loaded, their bounds will retain their new position, but it's not the one received from the first one.

Please see the attached gifs.

Aseprite and System version

  • Aseprite version: 1.3-beta6 dev
  • System: Windows 10 64bit English

Attachments

No script, just try it out with Wizard Example.lua

1.3-beta 6

wizard dialog 1 3-beta6

1.2.29

wizard dialog 1 2 29

@dacap dacap added bug scripting Related to scripting API labels Oct 29, 2021
@dacap dacap added this to the v1.3-beta8 milestone Oct 29, 2021
@iamOgunyinka
Copy link
Contributor

Getting the source of this bug took quite a while but I think I know what is going on now (not a fix, more like a report on the research). (Please skip to the next paragraph if you're not interested in the technicalities, this is only detailed here for future reference) The problem here is that when you activate the experimental "UI with multiple Window" in Preference, Aseprite uses a conceptual Display that uses a different kind of bounds, different from the traditional bounds when that option isn't checked. When you read the bounds of a dialog, with that option checked, Aseprite uses a different methodology to return the bounds. However, when you close the Window, the flag Aseprite uses to track this Display is already reset and thus, this methodology fails.

The only hack I can come up with now is to cache the bounds before closing the window, like so:

local function prevPage(dlg)
  local bounds = dlg.bounds
  dlg:close()
  for i = 2,#dlgs do
    if dlg == dlgs[i] then
      local newDlg = dlgs[i-1]
      newDlg.bounds = Rectangle(bounds.x, bounds.y,
                                newDlg.bounds.width, newDlg.bounds.height)
      newDlg:show{ wait=false }
      return
    end
  end
end

Can this bug be fixed in a more elegant way? Perhaps but I would leave what to do in scenarios to someone smarter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug high priority scripting Related to scripting API
Projects
None yet
Development

No branches or pull requests

3 participants