On Mon, Nov 18, 2013 at 09:19:02PM +0100, Tomasz Wlostowski wrote: > Why don't you write a one A4-page long blueprint, discuss it on the list, > and if your time permits, code the thing?
It was discussed a while ago on the list... something like 'class A has clearance 0.2 with class A but clearance 5 with class B'. And distinction for inner layers (both thermal and electrical properties are different). IIRC it was suggested for striplines and things, the big issue was how to present a GUI for such a thing and avoid combinatorial explosion. > >Also a better 'drag trace' would be even more useful for me than the P&S > >router. Maybe it's a workflow issue of mine, I don't know... > What do you mean by 'better drag trace'? I have environment-aware dragging > in my P&S plans, I'd really appreciate your feedback. First thing in my wishlist: get rid of that 'collinear segments' message, just merge them! One of these day I'll try to attack it. One thing I'm always doing is redraw tracks after moving vias, so I'll guess that 'better dragging' would include 'move a via without having to straighten up the connected traces' (at least in the easy cases). > Every big thing starts with a proof of concept, committing stuff early lets > bugs be hunted down and fixed fast. We are talking about multiplatform > OpenGL, on broad range of HW and drivers of less than perfect quality. That's why I say probably it's because that, because it's not finished yet (example: the line/sketch mode for module elements)... In particular I'm really missing the F1/F2 recentering behaviour. Maybe because usually I don't pan since it's quicker to zoom out/move/zoom in (with a wheel is even faster). And the text legibility issue I already talked about (no idea if it can be fixed however) > Or maybe the real reason you don't like OpenGL is because it doesn't work on > your S3 Virge/Trident/ET4000/Hercules graphics? ;-) It actually works pretty fine even on i915/954, I'm surprised of that; these GPUs usually are crappy in opengl... however almost 2s for the recaching when doing a (relatively simple) 1700 pin board (and that only simply for toggling the sketch mode) feels a step backwards compared to the wxDC code... *and* I actually used OrCAD 1.0 with a 640x400 mono board:P Another thing, as a suggestion/proposal: I noticed the gl view pops up the current layer (good for the copper ones); however it puts down the others (like silk or assembly), unlike the dc mode. I think that a good way to handle this is the one used by *every* CAM system I've seen: you can flag some layers as 'on top' (or 'reference', but on some this means also read only, so it's confusing) so that it switches priority to the current layer but keeps the silk/drawing/comment whatever on top. -- Lorenzo Marcantonio Logos Srl _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
