-
Notifications
You must be signed in to change notification settings - Fork 511
-
Notifications
You must be signed in to change notification settings - Fork 511
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
Interrupted brush stroke issues with tablet and 1.2 #1683
Comments
I'm having the same issue, but in a different fashion (on Linux). Apparently, Auto-save isn't required for the stroke-disappearing act to happen. It just happens either way when using the tablet, but doesn't when using the mouse. I've described this phenomenon here, which it may be related to, where b4zz4 has also posted a GIF to demonstrate what we mean: #1371 (comment) |
I think everyone, regardless of platform has been experiencing that. I'm just accustomed to assuming I'll have to redo that stroke or whatever after the auto save or whatever. |
@b4zz4, that’s exactly what I’m getting. @tushantin I can force the behavior by deliberately pressing on a shortcut or stylus button while drawing a vector stroke. Is it possible that you are accidentally pressing one of the stylus buttons (which is really easy to do on a wacom stylus)? @Orphanlast, hopefully that means this can be resolved sooner rather than later. It’s not a huge deal but makes working with a tablet feel less polished than other programs. Honestly the greyed out menu that often occurs at the same time in OS X (which makes it seem related) is a much bigger inconvenience. Redrawing a line is way better than restarting the program. |
@tushantin Just in case if you missed this: Is it possible that you are accidentally pressing one of the stylus buttons? The problem shown by @b4zz4 and @tushantin seems not to be related with autosave and looks more like #1704 |
Only drawing without press a other boton
|
@b4zz4 Please check if you have the same problem with this special version 1.1.3.9 - https://sourceforge.net/projects/opentoonz-morevna-edition/files/stable/1.1.3.9/ |
@Orphanlast I am waiting for your feedback about 1.1.3.9 (my last mail) ^__^ |
@morevnaproject No it seemed to be related, but different issue for me, because I neither needed to click buttons nor enable autosave for lines to disappear — which seemed to be fixed in the build you shared last time. Although, I did also have that button-click / disappear problem. Even more interestingly, the build that you shared just recently, related to the middle-click testing, seems to no longer erase the lines even IF I middle-click or right-click while drawing. Middle-click seems to just end the stroke and allow the line to exist, while right-click makes the stroke assume that the drawing is still continuing, so that you can continue where you left off. |
@tushantin @b4zz4 Please check the build I have posted here - #1704 (comment) |
@morevnaproject The build you provided recently seems to give me the same results as the previous special build: no stroke-disappearing issue, just that the stroke pauses with middle-click until you resume drawing again (which probably isn't a big deal, at least for me, so it's a question of whether that bit of interruption is intended to be there). Hopefully it works for @b4zz4 too in this case. |
Fixed in Morevna Edition 1.2.0.2 by reverting changes of #1659. Official OpenToonz still affected. See relevant comment - #1659 (comment) |
@morevnaproject, thank you. However the problem with reverting back to the previous behavior is that the original tablet glitch in OS X where the brush randomly generated strokes on its own without any deliberate input from the stylus will be a problem again. It would be so helpful to actually have all of the tablet issues (#1058 #618 #756 & etc.) resolved so that tablets could work smoothly across all platforms. |
And there is a bounty still open! |
@artisteacher You right. But tablet fix for OSX breaks behavior for two other platforms (Windows and Linux). Of course it would be good to have real solution, but it surely takes time. So we have decided to roll it back, until it get resolved in favor to have working version on Windows and Linux. |
@morevnaproject Can't you make a special build for macOS users? |
@jpturcotte This is technically problematic to maintain a separate build within our limited resources. We will need to do double work for every release. Let's wait for the fix. |
I understand, although we will have to wait for a long time since nobody is working on this. |
I tested on Windows and found that there is a case that Qt recognizes tablet is touching with pressure = 0 . In the previous modification I added a process to cancel the stroke in such case ( here ) in order to prevent unwanted stroke being drawn while hovering the pen. This workaround may be a probable cause of this issue, at least on Windows. Instead of cancelling a stroke, I'll try inserting a process for ending the stroke just like releasing the pen. |
With the new tablet fix for OS X in 1.2, interrupted brush strokes still seem to have undesirable results. On a vector level, if the brush stroke is interrupted by an accidental button press or auto-save, the unfinished stroke is unable to be finished. After starting a new stroke, the incomplete stroke disappears and is replaced by the new stroke. On other level types, the interrupted stroke behaves like a completed stroke and remains visible. It would be better for auto-save and additional stylus input to be delayed until the brush stroke is finished. In the meantime, the accidental input can be minimized by being careful with the stylus grip (though that does not help the auto-save problem).
Possibly related, the greyed out/inaccessible menu problem #618 seems to be more of an issue than it’s been in a while.
Edit: it seems like auto-save does delay until the stroke is finished when using the trackpad (and mouse?) instead of a tablet. If auto-save interrupting something in progress is what actually triggers the inaccessible menu, delaying autosave until the stroke or etc. is complete could resolve the issue.
The text was updated successfully, but these errors were encountered: