Mail Archives: geda-user/2015/07/27/02:28:11
Hi,
On Sat, 25 Jul 2015, Kai-Martin Knaak wrote:
> gedau AT igor2 DOT repo DOT hu wrote:
>
> I'll reorder according to my prefererences:
Should I assign one token for each of the first 3 items on your list?
>> 2. {large} resurrect the win32 port - only if there are volunteer
>> windows testers
>
> There is a number of geda users at my day-work who prefer to do their
> electronics projects on windows rather than set-up and get used to a
Are you willing to test pcb-rnd windows binaries?
> The reason I did not put the windows port on the top of this list is,
> the lack of transparency. If I remember correctly, the introduction of
> openGL triggered you to fork your own version of pcb. So I guess,
> there is no road to a transparency enabled version of pcb-rnd, be it
> in linux or windows.
Opengl and transparent layers was one of my triggers. There were others
too, it was more like just the last drop.
However, there are many roads:
- I am willing to give commit permissions to virtually anyone who wants to
contribute (as long as their contribution is aligned with the goals of the
project)
- I am not against a compile-time option for opengl if someone volunteers
to maintain it. I just want the default to be non-opengl, and my main
priority is to get things work in the default setup.
- I am not against any sort of optional transparency on the UI if someone
volunteers to do it in a way that it can be turned on/off on the fly. As
I don't need transparency, I probably won't do it.
>
>> 5. {small} UI: component dialog: filter by component tags, not only
>> by name
>
> I see only weak reason to use the chooser in pcb in the first place.
> Footprints are chosen in the schematic. I only use chooser dialogue in
> pcb as a catalogue to see the what is available. This is of course a
> bit of a crutch which is only necessary because gschem lacks proper UI
> mechanisms to scan the library of footprints.
This was true for me with vanilla PCB too. Since pcb-rnd's intconn and
nonetlist patches, I have all my jumper parts selected in PCB as I don't
want them to be on the schematics. Same for mounting holes and chassis.
On the other hand, I want to have a way of chosing footprints
interactively while doing the schematics. Best would be non-guile
scripting in gschem so that an external app can be started that pops up
the dialog (probably it wouldn't be too hard to add a command line option
to pcb-rnd to open the library window only, print the selection on stdout
and exit).
>> 4. {small} UI: be able to manually change text line width
>
> What use case would benefit from this?
I use toner transfer to do silk on some of my boards. Currently pcb makes
up text line widths and I can't use small letters as they become
unreadable with too thick lines. I could tweak some settings to get all
text lines thinner, but then that'd make large text unreadable. Some of
this can be accounted on toner transfer not scaling properly (small text,
thick lines), but there's a more generic issue under the hood.
I am free to change hole sizes, ring diameters, line thickness
anywhere. I don't see why I shoudn't be able to do the same with text line
widths.
>
>
>> 6. {medium?} CORE: clear poly should be a per layer flag (on each
>> objects); so that a line can clear poly on solder-gnd but join
>> solder-pwr
>
> This would break file level compatibility with mainstream pcb. As such
> it would make pcb-rnd, or t least this feature unusable for me.
Yup. Sooner or later it's inevitable to break file compatibility. If
mainstream pcb has new features in the file format, that breaks
compatibilty too. pcb-rnd is not pcb, so I don't worry much. It's
impossible to have both new features and keep 100% compatibility in both
directions (especially if there's zero support from mainstream PCB for
that).
I try to give compatibilty a chance wherever possible, like my flagcomp
patch makes it possible for any PCB variant to add new symbolic flags
unknown to other PCBs in a way that other PCBs will still load and save
those flags. It didn't get merged or implemented in mainstream pcb.
>
>
>> 7. {medium?} CORE: optional inverse silk or copper text: draw a fill
>> rect around the text and make the text a cutout of this fill rect.
>
> When done in a way that is compatible with mainstream pcb, I'd put
> this into the nice-to-have-department.
Would be a text flag.
With flagcomp implemented everywhere: mainstream PCB doesn't write the
stuff in inverse, but preserves the flag in the file on a load-save.
Without flagcomp implemented: mainstream PCB will throw out the flag so if
you ever load and save such a file with vanilla PCB you save an unwanted
diff.
Regards,
Igor2
- Raw text -