Under Community Review

Two essential improvement suggestions

1. About saving and automatic saving
In the Editor interface, there are no application scenarios where the project files do not need to be saved. From the user's point of view, what the user wants, is that the project files are saved automatically. Therefore, the existing Save Document should be understood as manual saving, and AutoSave should be treated as manual saving at set intervals. Did you know that the current AutoSave does not actually save the project files, but saves them as temporary files in the system folder, which will only work in the event of an unexpected power failure or program crash. When you understand this, how should you handle AutoSave? 
2. It is recommended to develop the 64-bit program version.
The current program is 32-bit, and its limit available memory is 2G, regardless of whether the user's hardware memory is 16G or even 32G. The memory utilization efficiency of this program obviously cannot keep up with the user's hardware memory. When a large file containing a large number of pictures is processed, such as a 1000-page manual, if it is not divided, the memory used by the program will exceed 2G when the Save Document button is pressed , which will cause memory overflow and that the project files cannot be saved.
 
The above two suggestions are crucial and fatal, and it is recommended to take them seriously.
Jack Zhai
Parents

  • About the first proposal, I do not fully agree. It happened to me to close a file without saving it, because, for instance, I made a wrong search and replace on a very large file, and it would be too long to cancel one by one all and every replacement that were made (mainly when CTRL+Z stops unexpectedly working, as you may have experimented it too). In such a case, i am happy to be able to close my file to come back to a previous version. With a real definitive Autosave, I could not erase all my most recent changes at once.
    However, I still do not understand why the current autosave function freezes the screen when it runs, sometimes for long seconds for big files. It's extremely inefficient. I do not know the actual process, but a workaround, for developers, may be be to run the autosave process on a snapshot/mirror file rather than on the current one, since making the working file unavailable for seconds is certainly not a good way to do it.  

    About your second proposal, I never wondered if Studio was developed in 32 or 64 bits. Now than you pointed it, I can understand why some processes are that long, when working with big .sdlxliff or big .sdltm files. My computer has 64 GB of RAM, and Studio remains desperately slow sometimes.

Comment

  • About the first proposal, I do not fully agree. It happened to me to close a file without saving it, because, for instance, I made a wrong search and replace on a very large file, and it would be too long to cancel one by one all and every replacement that were made (mainly when CTRL+Z stops unexpectedly working, as you may have experimented it too). In such a case, i am happy to be able to close my file to come back to a previous version. With a real definitive Autosave, I could not erase all my most recent changes at once.
    However, I still do not understand why the current autosave function freezes the screen when it runs, sometimes for long seconds for big files. It's extremely inefficient. I do not know the actual process, but a workaround, for developers, may be be to run the autosave process on a snapshot/mirror file rather than on the current one, since making the working file unavailable for seconds is certainly not a good way to do it.  

    About your second proposal, I never wondered if Studio was developed in 32 or 64 bits. Now than you pointed it, I can understand why some processes are that long, when working with big .sdlxliff or big .sdltm files. My computer has 64 GB of RAM, and Studio remains desperately slow sometimes.

Children
No Data