Search the Community
Showing results for tags 'state'.
Found 2 results
Summary Many tools provide a preview mode, which shows the effect of using the tool prior to execution. This preview mode is very useful, since it allows the user to see the result of applying e.g. the erase tool, or a brush, etc. Unfortunately, it does not work consistently: it ceases to work if the user tries to draw a line that connects the previous application of the tool to its current position using the shift key. The situation is further exacerbated by the fact that the position of the previous application of the tool (the origin point of the line) is lost when a line is created and then undone (e.g. if the result is sub-optimal, which cannot be determined prior to execution due to previously mentioned inconsistency in the preview). Directions to demonstrate preview mode inconsistency On a blank canvas, move the pointer (set to any paint/brush/erase tool that allows the use of shift to create a straight line) over the canvas. A preview of the effect of the tool becomes visible. Left-click while on the canvas to apply the tool. Move the pointer some distance away from where it was previously applied. Now a preview in the new location is shown. Hold down the left shift key. Expected behavior For tools that can be applied in a line via the shift key, the preview should change to reflect the outcome of the line being applied; e.g. for the erase tool, it should show a line consisting of background color/transparency that connects the previous invocation of the tools to the new cursor position. Actual behavior The preview continues to show the result of applying the tool in a single location (located at the pointer position). But when applied with the L-shift key held down, the actual outcome differs from the preview. As I mentioned before, this wouldn't be so troublesome if the program reverted all internal parameters to the prior state upon execution of the Undo command. But Undo is inconsistent in that it only reverts visual changes, rather than all internally stored values as well (e.g. l coordinates of where a tool was applied in a prior step). Directions to demonstrate inconsistency in program state Load an image, then use the erase tool in line mode (L-shift) to remove part of it (e.g. for isolation of a foreground object contained therein): apply the erase tool to an origin point, then hold down L-shift to remove the part of the image that forms a line from the origin point to the current pointer position. Execute the Undo command (CTRL-Z). Holding down L-shift, apply the erase tool once more. Expected behavior Upon executing undo, the previously created line is removed. Furthermore, applying the tool with L-shift held down should once again create a new line stretching from the current pointer position to the position where it was applied in step 1. Actual behavior The line created does not connect to the point created in step 1, but rather to the point where the tool it was applied in step 3. This is not only inconsistent ("Undo" only reverts some parameters to the previous state, not all), but unfortunately reduces the utility of applying tools in a straight line, since the origin point has to be recreated in its previous location (sterp 1), which frequently cannot be done easily/consistently (e.g. if the tool applied uses an alpha gradient -- which includes essentially all tools that can be applied as a line).
Hi folks, It's not really a bug, but more a usability enhancement which could prevent users misunderstandings. I've noticed some cases where checkboxes doesn't use the "mixed" (see Xcode) state. For instance: Create two rectangles Set the stroke option of one to "Scale with object": checked, the other not. Select the two rectangles The expected result would be to use the mixed state for the checkbox. I'm sure this applies to other options, sadly, I did not take note of this when I stumble on them. Thanks for your support and your work always making Affinity software better.