X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Mon, 27 Jul 2015 08:28:30 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] pcb-rnd feature poll: please vote In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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