Lightroom SDK: save_frame issues in Windows version of floating dialog

  • 3
  • Problem
  • Updated 4 years ago
  • (Edited)
The save_frame option for LrDialogs.presentFloatingDialog() seems to have two problems in the Windows version (LR 5.6, Windows 7/8). Its behavior is also substantially different from the Mac version.

Problem 1) The Mac version of save_frame correctly saves the position (upper left corner) of the floating dialog. The Window versions does that too, but in addition it seems to take the width and height of the recently closed dialog and use that as a minimum value for the width and height of all future dialogs opened with the same save_frame identifier. In other words, I cannot subsequently open a dialog anymore which is smaller than the one which was first saved with save_frame, even when I use height and width to set a fixed width in an f:view{} container. This is problematic if I want to open the next floating dialog at the same position, but with different width / height settings (for example, because I am showing a portrait mode photo after a landscape photo).
The Mac version (correctly) does not show this behavior.
Suggestion: implement this in such a way that it behaves like the Mac version, i.e. only the position is stored. This would also be in agreement with the documentation.

Problem 2) LrDialogs.presentFloatingDialog offers - through the onShow() parameter - a function close() which with the plugin can programmatically close the floating dialog. On the Mac, calling close() will close the floating dialog and also update the save_frame position, meaning the dialog will be opened where it was programmatically closed. On Windows, this is not the case, calling the close() function will not result in saving the dialog's position.
This is inconsistent between the Mac and Windows version. From reading the documentation for save_frame ("...automatically save the position of the dialog as one of the plug-in settings."), it is my understanding that the Mac behavior is the correct one.
I can provide an example plugin to demonstrate the effect but don't know how to upload it here.
Photo of Chris Reimold

Chris Reimold

  • 4 Posts
  • 0 Reply Likes

Posted 4 years ago

  • 3
Photo of John R. Ellis

John R. Ellis, Champion

  • 3381 Posts
  • 853 Reply Likes
Have you tried deleting the LR preferences file and seeing it the issues can be reproduced? A couple of years ago (probably in LR 3) I had problems with bad values getting saved for window placements of my LR plugin (with modal dialogs), and I ended up having to delete the preferences file. Once I did that, the problems went away, though I never narrowed down the cause; I suspected that some poison value had gotten into the preferences file during the plugin development.

You can edit the preferences file in a text editor and search for any entries mentioning the plugin identifier (e.g. "com.johnrellis.anytag*").
Photo of Chris Reimold

Chris Reimold

  • 4 Posts
  • 0 Reply Likes
Hi John, that's unlikely because before posting the issue I set up a new test plugin to verify the issue (thus it's independent of the preferences values of my plugin where it originally occured) and also asked Rob (Cole) if he could verify the issue on his system with the test plugin, which he could (thus it's independent of my system). I've now tried your suggestion -deleted preferences file and started LR, the issue persists unchanged. Thanks anyhow. - Chris
Photo of John R. Ellis

John R. Ellis, Champion

  • 3381 Posts
  • 853 Reply Likes
Can you post a Dropbox link to the test plugin .zip? I have a vague memory that I struggled with this issue (or one very similar) with presentModalDialog() in my Any Tag plugin. I've looked at its source and nothing springs to mind, but maybe poking your test plugin might help me remember.
Photo of Chris Reimold

Chris Reimold

  • 4 Posts
  • 0 Reply Likes
https://www.dropbox.com/s/xstkoaxqz88...

To reproduce: (after installing normally and starting from Library menu):
- A main dialog and a helper dialog opens after opening the plugin. The main dialog has save_frame enabled. The helper dialog serves to control (open/close) the other dialog.
To demonstrate problem 1 (as outlined above):
- Move main dialog to another position and close it through the Windows controls e.g. the X in the upper right corner. Frame is now saved.
- Reopen dialog with „Reopen dialog 1 (constant size)“. The dialog is reopenend at the correct save_frame position, this is correct. (note however already the dialog is not opened with 400x200 as written in the dialog, but rather at the originally saved width / height 800x600 - this is problem 2 already - but let’s not digress here).
- Move the main dialog to another position. Close the dialog now with the button „Close dialog 1 programmatically“. The position is not saved in this case. Reopen the dialog with "Reopen dialog (constant size)“. You will see that the last closed position has not been saved. For the Mac it would have been saved in that situation.

To demonstrate problem 2:
- Start plugin anew. Move main dialog somewhere and store its frame by pressing the ‚X‘ close control in the upper right corner. Position is now saved. Unfortunately, width/height is also saved as future minimum dimension for this dialog.
- Click on „Reopen dialog 1, but changing between landscape and portrait dimensions“. Actually, click a few times on this button, it should alternate between opening the dialog in landscape and portrait mode, as defined by width/height in the f:view{} hierarchy. Unfortunately, it always opens the same dialog of original size 800x600, because this are the minimum dimensions with which it was first saved (when we first closed it with ‚X‘).
On the Mac, on the other hand, this button correctly opens alternating landscape/portrait mode pictures.

John - let me mention that I've moved away from this UI idea (dialog reopening in landscape/portrait mode) towards a fixed aspect ratio dialog - thus the resolution of this problem 2) is not as urgent for me anymore personally - nevertheless it would be satisfying to know this resolved one way or another, and problem 1) (while less grave) remains active for me. Thanks for looking into it. -Chris
Photo of John R. Ellis

John R. Ellis, Champion

  • 3381 Posts
  • 853 Reply Likes
Thanks. Not surprisingly, I observed exactly what you did and didn't get any further insight. I poked around quite a bit. The problems only occur with presentFloatingDialog(), not presentModalDialog(). I looked at the key-value pair in the preferences file that stores the save_frame value, and it looked like it was getting properly set.

Interestingly, if you make the main window "resizable = true", then the window's initial size is set from the previous save_frame value, but the user can resize the window down to the minimum size established by the width and height parameters.
Photo of Chris Reimold

Chris Reimold

  • 4 Posts
  • 0 Reply Likes
I'm glad the problem is reproducible. Yes, I noticed this with "resizable" (undocumented!) too, interesting. It's a pity these smaller values can't be stored or at least read somehow (because of the save_frame minimum dimension problem, the smaller dimensions will never get saved).