Eeschema: Graphic line style "solid" does not save.

added priorityundecided statusnew labels

I'm observing the same issue

Application: Eeschema
Version: 5.99.0-unknown-r18419-5b078893, debug build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.66.0 OpenSSL/1.1.1g-fips zlib/1.2.11 brotli/1.0.7 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.4/openssl/zlib nghttp2/1.40.0
Platform: Linux 5.6.11-200.fc31.x86_64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    Build date: May 16 2020 22:44:53
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
    Boost: 1.69.0
    OpenCASCADE Technology: 7.4.0
    Curl: 7.66.0
    Compiler: GCC 9.3.1 with C++ ABI 1013

Build settings:
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=OFF
    KICAD_USE_OCC=ON
    KICAD_SPICE=ON
    KICAD_STDLIB_DEBUG=OFF
    KICAD_STDLIB_LIGHT_DEBUG=OFF
    KICAD_SANITIZE=OFF

It appears that the "default" for graphic lines is different than normal lines for some reason... (see https://gitlab.com/kicad/code/kicad/-/blob/master/eeschema/sch_line.cpp#L254), but there are a lot of places in the code that are assuming that the default style is a solid line rather than different for different types of lines.

@kicad/code/lead_devs is there a reason for this distinction? Is it to allow differentiation between the graphic lines and the wires/buses? If so, there is probably a need to ensure we haven't overlooked this difference in other places.

I am thinking one can say a wire is usually (by default) a solid line, and a graphic line a dashed line.

The "legacy" reason is the fact when printing in B&W a schematic, the graphic lines and the wires do have the same look.

Having say that, I can say we should always in files save all parameters, regardless the default value.

We already in the past have issues just because (for some good or bad reason) we changed the default values.

Micro optimization is not good for me.

We also in code avoid expecting the default value is the right value. For me, a default value is an acceptable and working value, not the right value.

If open *.kicad_sch in text editor and manually add "(type solid)" and open this file in eeschema, then lines displayed as solid. But after saving file in eeschema added strings "(type solid)" dissapears and on the next opening lines are dashed again.

Like Alex was saying, this issue is not about the default of the drawing line types. It's about the fact that with the new s-expression schematic format, the line style property is not serialized correctly.

The reason for my confirmation of the behavior is that there are other places in the code that seem to be making an assumption that the solid line style is the only default style - not just the s-expression parser. For us to have two different types of default line styles, it means we shouldn't be blindly and silently falling through cases inside switch statements - like what is currently done at common/plotters/DXF_plotter.cpp:101, common/plotters/SVG_plotter.cpp:279, and eeschema/sch_line.cpp:50. Instead, we should be asserting in the default case before failing back to something - since the fact that we have two different defaults means we shouldn't be passing in the PLOT_DASH_TYPE::DEFAULT value to these switches because we could end up with the wrong value selected.

While the reported issue is in the s-expression parser, analyzing the code to find the root cause of issues can always bring out other subtle issues or misconceptions that need to be addressed at the same time - otherwise we can end up with more problems in the future. That was the reason for my query - when I dug into this, I saw these other issues and wanted to clarify exactly what our code intention is - hence my closing comment:

If so, there is probably a need to ensure we haven't overlooked this difference in other places.

The default line type is not serialized because it's the default and is set internally to the default. This is by design. If we really need to save every default value, that's fine but it significantly increases the file size which decreases the parsing speed accordingly.

@stambaughw the problem is there are hard-coded assumptions that solid is the default line style instead of using the actual default styles for the lines, see:

The default line type is not serialized because it's the default and is set internally to the default. This is by design.

Is the default value for the saved file written in the file somewhere? It better be. For example, if somebody decides to change the default line style in the code to something else in a year .... it will break all old designs which then will have the wrong default. Or maybe the option will be added to let the user decide upon the favorite line style settings in the future .... and that'll be the default ... in any case implicit assumptions in data like that don't sound like a good idea IMHO.

@oleg.endo The same issue existed in the previous file format for stroke widths. If they were set to 0, the default width for a given line type would be used to draw the object. I'm not opposed to always serializing the line stroke information, text settings, etc. but I'm sure there will unintended consequences. Default object colors cannot be saved, other wise when the user changes the object color setting, the old default color will be used. I'm pretty sure that is not what we want.

We ran into this with sheets. Since the user has no way of specifying default, it doesn't really work. (If they happen to set the colour to the same as the default, we don't actually know if that means they want the default or they want "red", which just happens to be the current default.)

So there's a checkbox at the top of the colours editor that says whether to show colours overridden in specific objects or not.

@stambaughw Hmm .. but this means, I can spend hours on making beautiful (at least to my eye) drawings and whatnot, send the design to another guy and he'll see something completely different ... because his defaults were different. Maybe the other guy doesn't know that (which is likely) and he might re-do all the work .. send me the files back .. and this turns into infinite ping-pong. Even if that's the old behavior, it's quite annoying and makes sharing designs difficult. Maybe it's not that bad with colors. At least there are now color schemes for printing being added.

It's sounds like the same problem as sharing PDFs but not embedding the fonts in the file. Some people will just see garbage on their screens because they don't have the necessary "defaults" on their system.

Maybe it'd be better to use a separate "default" value setting (and show to which concrete value it resolves) and then have the other explicit value settings, for example ...

Line style: {default|line|dash|dot|dash-dot}

At least that'd make it more obvious what's going on, IMHO.

Adding a default token will certainly require some serious retooling of the schematic and symbol library editors. Default has many meanings. There are hard coded (source code level) defaults and user setting defaults which in some circumstances overlap.

I think I'd rather see us abandon default entirely. Always save the settings; allow users to override them if they want. (Kind of like CSS.)

Aren't the line style defaults not user configurable? If so, the only worry is the code changing the default not the user.

So what takes precedence, default, user, or file setting? In the past, if something was set in the file it took precedence of all other settings. If it wasn't defined in the file the hard coded default was used unless there was a user setting that was different from the hard coded default.

I'm with Jeff here. If we see file size issues out of it, there's always Ian's compression project :)

@craftyjon That's fine. It will greatly simplify the formatter code by removing all of the default checks. That still doesn't resolve the "what does default mean" issue but that is a separate issue and out side scope of this one. I propose adding a default token for line thickness, type, and color which will always get saved to the file and fall back to the current behavior where it's defined.

Just so we are on the same page. All line strokes will be fully defined. A line stroke definition with all defaults would look like this:

(stroke (width default) (type default) (color default))

I will also write the full text definition as well.

Why not save the actual default value instead of the token default? That way, if we change the defaults later, files saved earlier will still look the same.

Or if knowing that it was the default is important for UI reasons, could default be a modifier, like (width 1.5 default) or whatever?

@craftyjon Saving the default value would work but it means opening the schematic on another system with different defaults would look exactly as it did on the original system. It has never worked this way in the past so blow back should expected. The other option is to do what we have always done an use 0 to indicate the default line width and a color of 0,0,0,0 to indicate the default color which is less readable but maintains the current behavior. I would prefer the latter until we define any new behavior(s).

I say take the blowback now. The GUI has stated for some time "for new items", suggesting that the defaults are not saved, they're just something to initialise the values from.

If you save it as (width 1.5 default) we could add an option if we really wanted to that is "use my default instead of file defaults", not that I expect most people would want that behavior. I think for most people they expect files they move around to look the same, not for those files to take on local default settings.

I am thinking one can say a wire is usually (by default) a solid line, and a graphic line a dashed line. The "legacy" reason is the fact when printing (in B&W) a schematic, the graphic lines and the wires do have the same look.

Having say that, I can say we should always in files save all parameters, regardless the default value. We already in the past have issues just because (for some good or bad reason) we changed the default values. Micro optimization is not good for me.

We also in code avoid expecting the default value is the right value. For me, a default value is an acceptable and working value, not the right value.

Here is what I am planning:

Save all line widths in the default units (not 0) so it will always show as the line width used to create the schematic. If the default width is defined to something else, the line width in the file will be shown which is the current behavior.
Save all line types so the default line type will be the appropriate line type for a give line. This is effectively the current behavior.
Colors are a different issue. I will use the unspecified color if that is what is defined (COLOR4D::UNDEFINED which is 0,0,0,0) so that the color behavior will be the same as the current behavior.

If we wish to add an additional default option to any or all of these parameters, that would be a separate issue.

assigned to @stambaughw

added eeschema prioritymedium statusconfirmed labels and removed priorityundecided statusnew labels

Eeschema: Graphic line style "solid" does not save.

Description

Steps to reproduce

KiCad Version

Designs

Child items ...

Activity