[feat] ability to disable images

[bigboss59400]

Hi, Sometimes you will want to not display images to have a more compact drawing. Is there a way to do it ? a define would be wonderfull but I guess it will not be that easy The alternative I found is to make a small script that will removed images field...

[tobiasfalk]

Do you mean the image that you can attach to a connector or wire? If yes, you can just not attach it, and it will not be displayed.

[bigboss59400]

Let me explain again, On the same wiring, I would like to switch between displaying the images of the connectors and not displaying them.

[tobiasfalk]

So if I understand you correctly, you want to theimage: <image> tag defined but want to have the ability that wireviz practically ignores it? If so, we could add a comandline option like -SupresImages that yust prevents wire wiz from drawing the images.

[bigboss59400]

exactly, that would be wonderful !

[tobiasfalk]

@kvid and @martinrieder

[martinrieder]

What about commenting the image definition using #?

[bigboss59400]

that's what I'm doing but that required to edit the file, the solution proposed by @tobiasfalk is a good one

[martinrieder]

@bigboss59400 wrote:

Sometimes you will want to not display images to have a more compact drawing.

@tobiasfalk wrote:

If so, we could add a comandline option like -SupresImages that yust prevents wire wiz from drawing the images.

that's what I'm doing but that required to edit the file, the solution proposed by @tobiasfalk is a good one

I am not sure if it is a good idea to clutter the CLI with switches to disable specific features. This should be more broadly defined as a "compact mode". We already have hide_disconnected_pins and mini_bom_mode in the syntax for a similar purpose. Note that a compact_view has been suggested in another context, but the same motivation. See https://github.com/wireviz/WireViz/issues/268#issuecomment-1107926742.

How about a CLI switch that would disable certain YAML keys, just as if they were commented out (fallback to defaults) ?

--disable_key=image # defaults to no image 
--disable_key=mini_bom_mode # default is false
--disable_key=hide_disconnected_pins # default is true

[kvid]

I agree with @martinrieder that a more generic CLI optional argument is better than a very specialised one. Maybe we can think even wider to obtain a more complete functionality:

• Maybe it also should be optionally possible to prefix the attribute with one or more levels of context, like e.g.: X1.image (or maybe somthing like CSS context syntax)
• Maybe it also could be possible to inject or override a value as a CLI argument - similar to what is possible with tweak.override?

Such a functionality doesn't need to be 100 % complete to be accepted as a PR, but it's often useful to think about generic use cases when designing new features.

[martinrieder]

@kvid what you are suggesting is similar to yamlpath. No need to reinvent the wheel... 😊

[kvid]

@kvid what you are suggesting is similar to yamlpath. No need to reinvent the wheel... 😊

I don't know anything about yamlpath - I took a peek through your link, but it was too much to read today. It seems to be based on Ruamel (a fork from pyyaml with YAML v1.2 support that is considered in #223), but I don't know what is added on top, or if it might be worth the effort swapping out the pyyaml library to simplify adding a CLI argument for manipulating YAML contents.