kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

I finally got a chance to test this patch, I like it.  It works as
advertised and is very handy.  I have only one minor gripe is that it
appears to space the fields with the same delta no matter what the text
size (see screenshot).  It looks like your placing the center of the
text height at a fixed interval.  This make smaller text (discret:R4 in
my example) appear further away from larger text.  I would like to see
the spacing between each line be consistent maybe even a option to
define what the spacing should be.  Other than that, nice job.  Does
anyone else have any objections?

On 12/2/2015 9:31 AM, Chris Pavlina wrote:
> Thanks, Wayne.
> 
> I'm not sure if the original patch would apply anyway, it's been quite a while. Here's a new one. Not sure if you would want to merge it as a single patch (it's a bit long, about 2k lines), or if you'd rather I split it. I can split it into at least two patches: one to add the manual command, and one that ties it into placement so the labels move as you place parts. Let me know what you think about that.
> 
> As for the options - personally, I think the options in general really should be rearranged a bit _anyway_, and I've been considering poking the mailing list about that. I started a proof of concept branch for a more organized system a while ago but it didn't go very far as I ran out of time. I should have another stretch of development time starting in a few weeks, though. I could rearrange the options a bit for this patch, but I figured I should bring that up, since it wouldn't make much sense to rearrange them twice. Maybe we could just leave them as is for now, and rearrange them more thoughtfully a bit later?
> 
> My options idea was to make a more centralized configuration tool, the way most other EDA tools have, with a tree of categories, rather like this example from Altera Quartus: https://misc.c4757p.com/quartus_options.png . Personally I'd much rather that than the current situation with a whole bunch of specialized dialogs with like four options each. Any thoughts on /that/?
> 
> I don't think my code touches SCH_SHEET_PATH and SCH_SHEET_LIST, though I don't have a chance immediately to look through your branch and see whether mine will merge freely. It does touch SCH_SCREEN. I can look into that in a few days if you'd like.
> 
> On Wed, Dec 02, 2015 at 09:09:37AM -0500, Wayne Stambaugh wrote:
>> Chris,
>>
>> I cannot find the original request for this patch.  I do like the
>> feature.  Since I don't have the patch or a url to your branch, I cannot
>> review the code.  From the video, I have one minor suggestion.  It looks
>> like you added 3 new check boxes to the Eeschema options dialog which
>> makes it even taller than it already is.  Maybe it's time to add a third
>> tab and move some of the controls in the "General Options" tab to a new
>> tab.  I'm not sure what to call the new tab and how to group the
>> controls but it's something that should be done.  Anyone else have any
>> objections or comments about this feature?
>>
>> As for my Eeschema work, you can see what I've done so far at:
>>
>> https://github.com/stambaughw/kicad-eeschema-refactor
>>
>> If your code involves anything with SCH_SHEET_PATH and SCH_SHEET_LIST,
>> there will be conflicts as these two objects are going away and their
>> functionality moved into the SCH_SHEET object.  I'm almost have this
>> step completed.  SCH_SCREENS is also going to be removed shortly.  After
>> that, I will rename SCH_SCREEN to SCH_SCHEMATIC and make SCH_SCREEN a
>> separate object that is used only to store the current sheet display
>> settings.  The final step is to create a top level object (SCHEMATIC?)
>> to act as a container for the entire schematic hierarchy any schematic
>> settings (analogous to the BOARD object in Pcbnew).
>>
>> Cheers,
>>
>> Wayne
>>
>> On 12/1/2015 9:23 PM, Chris Pavlina wrote:
>>> This is mostly directed at Wayne, since he's working on eeschema.
>>>
>>> I have a feature branch I worked on over the summer (back when the release was thought to be closer, and the eeschema rework farther) that implements a field (reference/value) autoplacement on symbols in eeschema. It moves and aligns the fields as you place parts to allow a minimum of manual placement, including some heuristics to avoid overlaps. I've found this to be a _major_ time saver when working on complicated schematics. A preview is here: https://www.youtube.com/watch?v=32FKnrKxe4Y
>>>
>>> Is there any willingness to include this? As far as I can tell, the eeschema work is already somewhat underway, though I don't know to what extent. I'll happily rework my code to fit into the new eeschema code, though it'd be really nice if I could see how the eeschema work is coming along and refactor my own code in parallel. I've been using this since I developed it in July, so it's pretty well tested, and I've kept that branch up to date with respect to the latest code. If accepted, I will happily maintain it through the transition to GAL as well.
>>>
>>> --
>>> Chris
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp

Attachment: auto-arrange.png
Description: PNG image