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

Navigating in the text editor tab is super slow + suggestion: confirmation message for overwriting a file #1286

Open
Felina-Lain opened this issue Feb 26, 2024 · 3 comments
Labels

Comments

@Felina-Lain
Copy link

I just had this issue, using Version 0.16.1-5a10925 which led me to loose hour of work. Context:

I got manuskript recently, found it easy to use and quite practical, but ran into an issue very quickly: navigating between chapters in the text editor is extremely slow. And I don't mean 5 secondes delay, I mean up to 30 secondes to open a 3000 words chapter.

Which then led me to my lost work and my suggestion (because I'm pretty sure it's too late to recover my chapter)
I was trying to create a copy of one of my chapters, to have two version to try different things in both in parallel. I copied the chapter without issue (right clicking it and choosing copy). Then I tried pasting it into the folder I'd created for it. The navigation lagged behind so hard, so that when the subfolder opened, instead I clicked paste while my mouse was over another of my chapters.
There was 0 confirmation message or warning, and I didn't realise the horror right away. When I did I tried to recover the work, but there was no deleted file, or anything. And the revision option was off because the settings said it could create bugs and crashes so I hadn't dared turning it on.

So one: I'd like to understand why it's running so slow. The software itself is on my ssd. It shouldn't be that slow, I think?

Second, I'd very much like to suggest a confirmation popup whenever you try to overwrite a file with another in the menu. Like
"Are you sure you want to overwrite [file A] with [file B]?"

If I need to add some log files, for the "super slow" problem, I'll do it.

@TheShadowOfHassen
Copy link
Contributor

Manuskript, unfortunately, at the moment is very laggy for larger files. The way to fix it is to completely rewrite the system, which is being done. Unfortunately, this project is mostly worked on by one developer @TheJackiMonster, and he is busy with other projects.

I am really sorry that you lost your story. I've had it happen too, it stinks. The best way to prevent project fatalities is to back up your story, I'd do it at least once every day. This problem would also be fixed in the new gtk rewrite.

@TheJackiMonster
Copy link
Collaborator

The performance currently is bottle-necked by the CPU in most cases, not the drive. That's because every change of a file (chapter, scene, ...) will cause processing in terms of conversion for visual representation as well as potential spell & grammar correction, word counting and some other features automatically.

The idea to fix that is already there and partially implemented. But that's as part of a whole GUI rewrite which takes a lot of time and resources. But the basic concept is that we process each file asynchronously so that no lag is caused for the end-user (only a short period of loading in worst case).

For now I can only recommend creating backups frequently.

@Felina-Lain
Copy link
Author

Manuskript, unfortunately, at the moment is very laggy for larger files. The way to fix it is to completely rewrite the system, which is being done. Unfortunately, this project is mostly worked on by one developer @TheJackiMonster, and he is busy with other projects.

I am really sorry that you lost your story. I've had it happen too, it stinks. The best way to prevent project fatalities is to back up your story, I'd do it at least once every day. This problem would also be fixed in the new gtk rewrite.

The performance currently is bottle-necked by the CPU in most cases, not the drive. That's because every change of a file (chapter, scene, ...) will cause processing in terms of conversion for visual representation as well as potential spell & grammar correction, word counting and some other features automatically.

The idea to fix that is already there and partially implemented. But that's as part of a whole GUI rewrite which takes a lot of time and resources. But the basic concept is that we process each file asynchronously so that no lag is caused for the end-user (only a short period of loading in worst case).

For now I can only recommend creating backups frequently.

Fair enough, thank you both for the answers, pretty much what I thought as well. I knew going in that manuskript was still in dev, so I did expect bug, but obviously wasn't cautious enough. That's me burned once ^^"
Thanks for all the work on it though, the software really got potential!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants