Freron MailMate

Comments and changes to this ticket

• 

  benny November 2nd, 2018 @ 02:20 PM

  Again, do you see the same behavior in the latest test release: Hold down option when clicking “Check Now” in the Software Update preferences pane.

  (I'm not able to reproduce these issues.)

• You flagged this item as spam.
  

  Mike Conley November 2nd, 2018 @ 03:50 PM

  Interesting. Just tried this at home, and it works fine. So there's something about my work machine's environment that's different. I did check the permissions on the preferences files in /Library/Preferences/, and they look okay. Anything else I should look at?

• You flagged this item as spam.
  

  Mike Conley November 6th, 2018 @ 01:11 PM

  This problem persists on my work machine. What should I look at to determine what's different from my home machine?

• 

  benny November 6th, 2018 @ 01:49 PM

  Window states are saved in the preferences. You could perhaps check if this happens as expected. You can read the value like this:

  defaults read com.freron.MailMate "NSWindow Frame MmComposer"
  

  Maybe it's not the only preferences value which cannot be saved....

  You can try deleting the value like this:

  defaults delete com.freron.MailMate "NSWindow Frame MmComposer"
  

• You flagged this item as spam.
  

  Mike Conley November 6th, 2018 @ 01:59 PM

  Okay, I've figured out what's going on.

  • Launch MailMate.
  • Open a new message window. Resize it in a way you don't like.
  • Bring the Browser window to the foreground; the newly-opened message window is now behind it.
  • Open another new message window. Resize it to your liking.
  • Close the second message window.
  • Open another new message window.

  Note that the third new message window has the dimensions of the first message window (the one behind the browser), not the second one (the one you just closed).

  That's what was happening on my work machine. I had a message window open and hidden behind the browser, and all the new message windows were being created using that window's size, rather than the size of the most recently opened and resized message window. This strikes me as incorrect behaviour; the new window size should be set based on the most recently opened window.

  Another approach is to do what Mailsmith does, and add an item to the Window menu that explicitly records the window size; this eliminates any ambiguity, and, I think, is actually a better approach.

• 

  benny November 6th, 2018 @ 02:06 PM

  • State changed from “new” to “resolved”

  I'm glad it's resolved. When a window closes then its frame is saved. I'll consider if it is better to do this after resizing, but I'm pretty sure that some other user would then come up with a different order of events leading to a different kind of “illogical” behavior :-)

  Implicitly saved window sizes is kind of the macOS way, but (in general) I'm trying to move in the direction of explicitly saved states (for mailbox settings which are currently not working well). I don't think I'll do that for windows though...