Author Topic: B5: Changing workspace doesn't save split window/tab positions  (Read 1911 times)

tim_k

  • Senior Community Member
  • Posts: 141
  • Hero Points: 11
  • -Tim
B5: Changing workspace doesn't save split window/tab positions
« on: September 29, 2014, 04:06:19 pm »
When changing between workspaces on the Linux (RHEL 6.5, 64bit) version, if the document window is split into 2 tab groups (split a window, drag one copy to the right half of the screen) then the workspace is closed, or if I switch to another workspace and back, the edit window reverts to a single not-split view with all the documents in the one window. It does remember the open documents.

If I open the same workspace in the Mac OS version, then switch to a different workspace, the window/tab layout is saved properly. The Linux version can then open the workspace with everything in the right place. Once I've done that once (saved on the Mac) the Linux version seems to figure things out and future changes (moving tabs around, etc) are saved when switching workspaces in the Linux version.

Both Linux and Mac versions are v19.0.0.8. Linux is a VM hosted on Mac OS 10.9.5, and the workspaces and files are shared from the Mac side to the Linux side via VMWare tools.

-Tim

Clark

  • Moderator
  • Senior Community Member
  • *
  • Posts: 4691
  • Hero Points: 379
Re: B5: Changing workspace doesn't save split window/tab positions
« Reply #1 on: September 30, 2014, 01:46:40 pm »
This could be a permissions problem. Make sure the <workspace>.vpwhist file can be written to. If you run it one way and the file contents never change when you close the workspace (assuming you make some sort of change), this is permissions problem.

tim_k

  • Senior Community Member
  • Posts: 141
  • Hero Points: 11
  • -Tim
Re: B5: Changing workspace doesn't save split window/tab positions
« Reply #2 on: September 30, 2014, 02:08:25 pm »
The workspaces were created pre-beta, and the .vpwhistu files (and all others in the directory, and the directory itself) have full permissions on both OS's. Once the Mac version opens/closes the workspace, the Linux version updates the state correctly on subsequent open/close of the workspace- window/tab positions are remembered when changed.

-Tim

Clark

  • Moderator
  • Senior Community Member
  • *
  • Posts: 4691
  • Hero Points: 379
Re: B5: Changing workspace doesn't save split window/tab positions
« Reply #3 on: September 30, 2014, 06:34:24 pm »
Are any changes written to the .vpwhist file if you open this workspace on RedHat. Just open or close some files and then close the workspace. SlickEdit will attempt to write to the .vpwhist file to save the workspace auto-restore information. Save the .vpwhist file before you open and then just use "diff" (or check the file sizes) to see if the contents changed.

tim_k

  • Senior Community Member
  • Posts: 141
  • Hero Points: 11
  • -Tim
Re: B5: Changing workspace doesn't save split window/tab positions
« Reply #4 on: September 30, 2014, 07:35:07 pm »
The .vpwhistu files are considerably different.

I just went through a bunch of gyrations to try and isolate what's going on, and it seems that it's changed a bit in B6.
The first time opening a workspace on Linux that was last saved in v18 the tab layout is wrong, and crunched up to the upper left side of the window. Once it's been saved it continues to open properly. Unless...

If I open the workspace on the Mac side, which is running on a smaller monitor, then close and re-open on linux, all the tabs are in one window, where they were previously in a split-pane config. If I rearrange and close the workspace, things are now preserved across platforms and monitor sizes.

I had a better writeup of this, but your forum's auto- logout punted me before I completed the post, and i don't have time to do it again.

-Tim

Clark

  • Moderator
  • Senior Community Member
  • *
  • Posts: 4691
  • Hero Points: 379
Re: B5: Changing workspace doesn't save split window/tab positions
« Reply #5 on: October 01, 2014, 02:29:36 am »
We will try to reproduce these things. I didn't think the restore code would restore panes for monitors with different resolutions.