UI Paper Cuts / my personal misc. wishlist

[betalars]

This is a thread where I will put a bunch of really annoying things about using Graphite that I hate while using it but preferably would be low hanging fruits to fix.

They are purposefully written in a complaining tone. This is not because I don't love your work and your projects. I just really really dislike paper-cuts and like to whine so you can fix it. 😇

Edit: I will be posting bigger stuff that warrants discussions in the replies and and a lot of misc other small things, I'll just compile here. I'm first getting it out of my brain ☑️ then mark if there is an issue/planned feature about it when I get the time to look trough other issues ℹ️ and if it has been resolved ✅

ℹ️/☑️ Missing Line spacing and Text Alignment options for text fields partially known
☑️ Missing Autowrap and Paragraph Formatting (Indent, Paragraph Spacing etc) Options
☑️ I wanna have smart node-based layouting tools. I wanna autocad my flyers! (moved to seperate suggestion)
☑️ Why is there no alignment node? I want alignment options as a node. (moved to seperate suggestion)
☑️ Why don't we just have a look at the Godot approach to containers and add those?
ℹ️ Missing CMYK preview-togge (even when working in RGB)
☑️ I wanna write pixel shaders in my svg. please can I have pixel shaders?
ℹ️ Better Gradients (everything I wanted is right now already being planned)
ℹ️ images do not become outlines or at the very least transparent in outline mode
☑️ I want a convenient way to create color palettes. And I want it so changing the color in one spot changes that everywhere. known issue, but no plans yet
☑️ wait, svg can work with css variables ... how do I set that up?
ℹ️ svg can do animations. Where's my keyframes and timeline?
☑️ I want a script note so I can do cursed things with xml
ℹ️ okay an entire scripting language is hard, can I have at the very least regex so I can mess with xml? > planned
ℹ️ only supports pixel units at the moment

[betalars]

The Rasterize Footprint is annoying

The Rasterize node footprint by default is a 100x100px at document origin.
This is especially confusing to new users (why does my shape disappear when I try to rasterize it) and I think in the long run will also be really annoying for power users.

The easy fix is using the canvas size as default.
The better solution is to have the footprint parameters act as an override. When they are unset, a reasonable preset should be used. That preset could either be the current canvas size or better even: the bounding box of the input.

[0HyperCube]

With the current design of the system, I believe so. Maybe @TrueDoctor might want to confirm?

[Keavon]

The future plan is to rasterize the full viewport bounds, but it isn't feasible due to the costly performance of high-resolution image rendering at the moment. Once that pipeline becomes GPU-driven, that will be resolved.

[betalars]

Maybe implicit conversion from path objects to raster objects using the document dpi and path bounds could also work? Allowing users to plug paths directly into taster inputs would be kind of hacky, but I think it is worth the time-save of not having to put rasterize nodes everywhere.

I think implicit conversions are really helpful to detangle node-graphs and speed up wotkflows even tho it is not a concept most rust programmers are fond of 😉

[adamgerhant]

This would mean that the rasterise node gets the bounds from the noise node and the noise node gets the bounds from the rasterise node

This is not correct, since if the rasterize node did not modify the Context, then an infinite vector data generator (which we don't have any at the moment), would still just output a finite amount of vector data based on the viewport bounds. The rasterize node can then just take whatever input it gets, compute its bounding box, and rasterize it. In terms of implicit conversions, I think it would be best for the node graph to automatically insert the rasterize node so that it is visible to the user, instead of doing it automatically.

[Keavon]

Automatic rasterization of vector data is one of the many planned implicit conversions.

[betalars]

The Graph is Cluttered

Please open the Isometric Fountain and take a look at its graph. I just immediately get a headache by looking at it and it makes me never want to look at nodes again. Especially because its running at 5~10 FPS.

I think that is sad because it makes users to not want to use your USP.

I think a good idea would be to just collapse layer and group inputs by default and only reveal it when you actually want to inspect it.

To resolve this, I would use Group layers as a way of just shoving complexity under the carpet. I would on the opposite site of the output visibility toggle put an input visibility toggle that would just hide all the spaghetti.

I know we need to think about how to deal with nodes that input to multiple groups but I think that can be fixed.

[0HyperCube]

You might experience a minor improvement in performance on https://dev.graphite.rs. We could rewrite the graph rendering to <10ms/frame since it isn't really that complicated.

The desire of a node graph is to show a more detailed version of the layer panel. By automatically collapsing everything it is hard to gain an overview of the graph without clicking on everything.

[betalars]

@0HyperCube I am already on the website.

to show a more detailed version of the layer panel

Huh, that is an odd approach tbh. I find graphs are always a lot more difficult to understand, but their benefit is that they make it a lot easier to work non-destructive. I would only want to use a graph to have an easier time wiring up logic, math and constraints and otherwise not look at them too often.

automatically collapsing everything

I mean that can be resolved by adding a show/hide all toggle. I would highly suggest for the sake of simplicity to automatically collapse everything by default to make it less overwhelming, but I think having that toggle set to expand by default is probably also fine.

[otdavies]

Your feedback assumes the node graph visual design is in its final state. We are actively planning on making it more of a fold-out-as-needed approach in addition to having the layer panel provide more data overall. The overarching goal is to provide power users with a graph they can manipulate and build new tooling in. Normal users to continue to operate in a layer based workflow.

You'll notice the node graph and the layer panel stay in sync with each other for this purpose.

In terms of performance, this is being actively worked on.

You're right the graph is scary and huge in its current incarnation for normal "draw a vector scene" usage currently. Thanks for the reminder!

[Keavon]

Yes, performance has been mostly fixed in the dev build, and layer collapsing will be added. But this requires repositioning all layers and nodes, even those which are connected to multiple items that need to shift or not shift, so repositioning them is a pretty nontrivial engineering puzzle that will need future attention.

[betalars]

It won't let me reuse gradients

I don't know how to use the same gradient in different places. Changing one instance of that gradient should change it everywhere.
I don't have a good idea how to do that at the moment. Maybe a "copy/paste reference" option?

[betalars]

I can't change attributes of multiple objects

When I select two circles or maybe even just two objects that both share a fill attribute, I cannot change these attributes as the property panel will be empty as soon as I select more than one object.

I think properties that come up in both objects should still be visible so you can change them for multiple objects at the same time.

This is also where I think it could be cool to "link" nodes or inputs so changing one always changes the other? That would partially resolve my gradient issue too.

[otdavies]

We don't have multi-object editing as of yet (in the layer focused workflow). It is planned. This is a good reminder it is important, thanks!

[0HyperCube]

You can link the values by adding a value node and connecting it to both of the inputs:

There is some UX improvements to make this faster to do in #2822. Note that it is not possible currently to feed a gradient from the graph because we only support making GradientStops rather than the Gradient in the graph. I've opened an issue about this #2875.

[betalars]

Okay I think I have to rethink this strategy. There's about 10 Papercuts on my plate right now and I am afraid many are mainly just half-baked/missing features and some actually do require fundamental reworks of the design philosophy.

I will try to still suggest papercuts if I find them probably ....

[0HyperCube]

It is great to hear suggestions if you'd be so generous to comment them.

[Keavon]

The best approach is to create a list of bullet points, rather than a bunch of posts, since you'll likely be more inclined to write smaller things if it doesn't have to become a separate post each time. Feel free to edit your original post in this thread with those smaller bullet points.

[betalars]

@Keavon @0HyperCube okay then I am just dumping stuff into the top post and create threads for topics that I deem to be actionable. I will probably sift trough it a bit later, but you asked for it so have everything unfiltered.

[betalars]

There is no spell checking T.T

Okay this one is something that isn't quite a usual thing, but I think it is really important:

Automatic spell and preferably even grammar checking! If you ask me, each textbox should maybe even have a language override to enhance Accessibility (Screenreaders beneit from knowing what language text is) and also internationalisation. Quite a lot of projects require text fields with multiple languages.

Having this would have saved me countless times.

[betalars]

✅ I can't unify image dpi automatically on export

I'll 100% make this a proper feature request, but I really don't want to forget it because it is one of the biggest gripes I have with inkscape: you cannot re-scale image elements to a fixed dpi when you export pdf or svg files and it hurts so much. So many times I am exporting a pdf that has 20-30-100 different images with varying dpi and there is just no easy way to make all have the same dpi.

Graphite is partially there because I can actually just rasterize images manually.

But some export script that would just pop one of those rasterize nodes set to some dpi behind each image source would be brilliant.

[Keavon]

Please file this as a feature request issue.

[betalars]

[Keavon]

This is already fixed in dev.