Is this by design or a “feature” that might vanish at some time?
By design.
…
Might it be better to have a dedicated flag for filled? Even if it is just in the GUI (would then set the line width to 0 and make the GUI field non writeable).
2 Likes
Feature discoverability and ui intuitiveness.
5 Likes
Hi, the idea of using the “0” is clever - but Rene is right, its hard to discover.
Whats more: it is a difference if you have a circle with a certain diameter + a line ON this diameter that has a certain width or just a “naked” circle that ends in the middle of the turned off line.
People might expect different behaviours.
However, choosing “0=filled” would prevent circles to vanish when the lines are set to zero ?
Again, Rene is right: combine both methods.
Treating outline and fill as separate entities would be more in line with (most) user expectations, and also be more uniform with Eeschema’s symbol editor.
And stopping someone coming along and reporting it as a bug.
It is not really logical that a line thickness of zero floods the polygon
1 Like
This code has been around for ages. The only thing that changed is that the GUI no longer blocks you from entering 0.
Sure, a flag would be better. Anyone want to get started on 7.0?
I don’t see why this couldn’t go into 6.0, we are not talking about functional changes and 6.0 is not in string freeze
I would naturally be cautious selecting a line thickness of zero, expecting that the outline might become invisible
File format change. (We’re presently allowing them for bug fixes, but I doubt this would get past Wayne’s feature-creep snif-test.)
I feel your pain as developer 
This does however not exclude adding an option in the GUI that then sets everything up in the file format such that it results in a filled polygon.
2 Likes
I’m not at a KiCad machine right now and don’t remember the details, but what about the actual “polygon” shapes? They have always been filled but allow zero line thickness while still being filled, right? IMO all shapes should have the same options and behave identically. But it’s a problem that they have been different in the past.
Polygons are yet another hack. I think they’re always filled everywhere except on Edge.Cuts.
Yes, all this could use a cleanup.
(I’m not in favour of just adding GUI elements because then it’s still the same hack under the hood only with even less predicability.)
This is why it should stay as “hidden” feature till the bottom had been clean out first.
Solution just add hint text that says 0 = filled in the dialog form 
That’s how any UI I have ever done or seen has handled hinting about special values.
1 Like
The ultimate solution is probably to change the file format for 7.0 or later. Each shape has “filled=true/false” attribute. If that attribute doesn’t exist it’s interpreted according to v6 file format while reading, but the attribute is added when writing. Then the line thickness and filling can be independent for all shapes when the attribute exists. I don’t know if such interpretation of the lack of the attribute would be acceptable for KiCad file format/code, though.
Well you guys are in luck. We convert rectangles to polygons when they’re rotated by a non-cartesian amount. But that means if you rotate an unfilled rectangle on a non-edge-cuts layer it suddenly becomes filled.
So now it’s a bug… 
6 Likes