Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - mattnava

Pages: [1] 2 3 ... 10
Suggestions, Ideas, Bugs / Re: Request: File-> Rename
on: May 13, 2022, 01:25:46 PM
Ah, that sounds tricky, thanks for that explanation. Thanks for looking into it though, its a very nice little quality of life feature! I hope it turns out to be straight forward  for you in the end!

Suggestions, Ideas, Bugs / Request: File-> Rename
on: May 07, 2022, 03:12:00 PM
It would be a nice thing to be able to rename the currently open file without having to back out to the file browser. The logical place to me would be an entry in the file menu for rename that would just pop up an little text input box.

Thanks for your consideration!

Another thing that would make the quick menu more readable would be the ability to choose a subtle tint for each icon. It could default to the current monochrome, but being able to add color would make it easier to find things at a glance.

I use iCloud to store my .artstudio files, and I like to use the Windows iCloud integration to organize files in there en masse. However, .artstudio files do not have image previews on Windows, which makes it hard to do simple things like rename them, because you cant easily see what the image is of.

I assume Mac has .artstudio image previews since Art Studio Pro runs on Mac, but it would be very convenient if Windows could also be supported with this feature.


The confirm button in the transform tool gets vertically squished on an ipad Mini in landscape mode, making it harder to tap. This seems to not be an issue in vertical orientation. See attached image for an example. This is present in the latest beta.

Hey thanks! Glad you like it.

Yeah it’s definitely a trade off, between the first and second mock-up. The first one puts color/opacity editing in one combined key, which simplifies the key ui. However, it makes some kinds of gradients harder to author, where you want a simple gradient for opacity but a lot of keys for color. It can be nice to separate opacity and color in those cases.

Gradients in Art Studio Pro already are set up with separate color and opacity keys, which means the second mockup probably has a higher chance that lucky clan could do it with less trouble (higher chance it might actually happen! Haha). Also they don’t have to do any changes to the color picker ui which simplifies things further.

I included an example of a gradient that would be hard to author with combined color/opacity keys (it’s art studio’s existing gradient editing ui).

Another thought I had is that you would have to be able to add and delete keys- probably just tapping on the bar anywhere would add a key, maybe dragging a key off the bar would delete it. Additionally, another cool thing about either of these designs is they could support the “show midpoints” option in the tool options.

Regarding that affinity photo gradient tool vid- there’s some neat stuff in there! It gives you an interface to edit a gradient after you draw it, and select color keys on the canvas. Personally, I find that the issue with this sort of design is that it can really slow you down if you are just trying to do a lot of gradients overlapping each other, since you are forced to accept each one before you can do another. You also lose the ability to edit it if you switch tools or do any additional actions. There’s lots of ways to design around those issues or make the post-edit ui optional, but I think it’s a level of complexity and control that’s more fitting for a gradient adjustment layer, which persists and can be edited later. And indeed, in the video, he shows that ui is best used with a gradient adjustment layer for this reason. I like the gradient tool remaining focused on one-and-done quick gradients, since it really is not focused on persisting gradients individually. So if it were up to me, I would consider adding something like that to a gradient adjustment layer, but not the gradient tool.

yeah its subtle, but its a 100% repro for me. I'll attach a video demonstrating the issue. In it you can see that every time I swipe to select a brush with the quick menu(its a favorite preset brush), it leaves a little mark where my finger stopped swiping. you can also see that after I make a selection with the lasso tool, if I swipe to select a different tool and then the lasso again, it registers a tap of the lasso when I let go and deselects.

This is on an ipad mini in the latest beta.

I thought of a way to improve this idea a bit and remove the need to add an opacity slider in the color picker for this to work.

In this mockup, there's a simple button on the top of the sidebar that toggles between editing color and opacity keys. This allows color and opacity keys to have different amounts and positions, which is ideal. Opacity keys could use the standard number entry UI to edit their value, and color keys could use the color picker.

This version is more powerful and requires less new UI elements than my original mockup.

If you put a tool like the brush on the quick menu and use the single finger swipe gesture to activate it, the brush will actually make a mark as if that swipe gesture was a paint stroke. I also found that the lasso tool could register a tap when you swipe to select it the same way. This is enough to make it deselect an existing selection, or sometimes even start a new one. Seems like there's a bug to fix here to make it so that tools selected via the single finger swipe quick menu don't register that initial swipe as an actual stroke/tap for the tool.

One more example with a more wild shape!

The jump flood thing Im talking about should handle any shape selection/holes/etc. Its possible to visualize using substance designer's distance node, so I thought Id share an an image to clarify what Im talking about. Im not super sure about how the math works, but a distance field from the selection is used to extend edge colors outward from the mask's shape. If something like this was used for sampling colors for smudge/wet brushes when a selection is active, it would ensure colors outside the selection would not have an effect. It might have its own edge cases, for like small holes causing color bleeding from colors across the hole that are also in the selection, but I think thats acceptable and still an overall improvement.

Awesome, thank you!

The quick menu displays all the tools and things that can be put on the toolbar, but the toolbar lets you give a custom name to them, even letting you use those special icons if you put in the correct codenames.

The quick menu would benefit from this functionality, especially if you are putting favorite presets in it. They show up as "ActivateFavoritePreset1, 2, 3," etc, which makes it real hard to tell what they are. They could be the brush, eraser, lasso, anything, and theres no good indicator.

Ideally, any tool you add to the quick menu would show its icon. In the attached mockup, you can see I did that for the lasso tool.

For favorite tools, it would be real cool if they could show the tool's icon with a little star next to it to let you know its a favorite. Since favorites can store custom settings per tool, a customizable bit of text below it would let you indicate its functionality. for instance, I have the move tool in the mockup as a favorite preset twice, but one is set to duplicate. The custom text is the only thing that would let you know that. The custom text can also describe what kind of brush the favorite is (Pencil, in this mockup), or that a fill bucket is set to lasso mode, etc. There's many more examples of customizations that would benefit from this.

It would make the new quick swipe functionality in the single-finger quick menu gesture very handy for rapidly switching between common tools for a particular workflow. I think it would really make the quick menu nicer and quicker to visually understand as you go.

Thanks for considering this!

I find myself editing it quite a lot!

Yes, I saw that thread! Very good idea there to unbury gradient editing for gradient map layers. I find that anywhere you have to edit a gradient right now, you have to dig through too much ui.

In this post, I’m referring specifically to the gradient tool, not gradient map layers. However I have a suspicion that this ui I’m proposing may also potentially be used with gradient map layers too to speed things up. But I haven’t thought that use through yet.

This idea should make the act of using the gradient tool smoother and require less ui digging each time you want to change the gradient setting. I would love to get the changes from both threads, which I think are 100% compatible!

Pages: [1] 2 3 ... 10