kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #12228
Re: Moving field-texts with connecting line to component; potential patch
On 7 February 2014 05:53, Nick Østergaard <oe.nick@xxxxxxxxx> wrote:
> I like the way it works. But when using it on a component with a filled
> rectangle the line keeps appearing as an artifact. This does not happen with
> non filled rectangles. Se attached image.
This is an interesting artifact, that happens due the way a component
is drawn and re-drawn when moving and when stopped moving.
Essentially on start-move, the component is re-drawn once in XOR mode
to erase it from the background, then drawn again in XOR mode to move.
This is done for each movement.
The final step is to draw it once in GR_COPY mode. This is where I
hook in, erasing the last line in XOR mode. However, since labels are
drawn after the component (which is re-drawn as well), this leaves a
visual artifact.
My tentative idea to fix this, I think the only way is to actually
have the transition to and from move mode with a step in-between,
essentially a 'prepare to move' and 'finish move'.
The task for the component is to erase the original footprint in
'prepare to move' (right now assumed to be simply possible by emitting
a redraw-regular-component-with-xor), and in the 'finish move' to
erase the drawing while moving. This is followed by a GR_COPY draw of
the mode in original mode. Also this explicit mode would make the need
for the additional 'remember if we last moved' state go away, so
overall cleaner. Additional costs would be that there is a final
GR_COPY draw at the end of a move operation (but that is needed in any
case to get rid of this artifact).
This solves the general problem that components, while they move, need
to look exactly as the regular components, while in this case we
introduce a slightly different way to draw. Also an additional state
might help to work on some artifacts that happen now while drawing as
well (letters that have overlapping segments create artifacts now as
well on move).
I try to find a simple and least invasive solution for this tomorroish.
-h
>
>
> 2014-02-07 Brian Sidebotham <brian.sidebotham@xxxxxxxxx>:
>>
>> On 7 February 2014 10:31, jp charras <jp.charras@xxxxxxxxxx> wrote:
>> > Le 07/02/2014 09:22, Henner Zeller a écrit :
>> >> Hi,
>> >> While moving a field text (REFERENCE, VALUE and such) in the
>> >> schematic, it is possible to loose the visual sight to which component
>> >> it belonged to, in particular in tight spaces (which is typically the
>> >> time when you need to start moving labels around). At least once I
>> >> swapped the visual designators with different components .. creating a
>> >> mess.
>> >>
>> >> So while moving such a label, I think it would be good if there was a
>> >> visual indicator to which component that label belongs to -- a simple
>> >> line would do. This would only be drawn while moving is in progress;
>> >> see attached image how this could look like.
>> >>
>> >> I have prepared a patch that does that (the image is done with this
>> >> patch):
>> >>
>> >> https://github.com/hzeller/kicad/compare/master...show-belongs-to-edge-while-moving-labels
>> >>
>> >> As the way to draw differs for not-moving vs. moving (there is an
>> >> additional line), the very first draw operation with XOR doesn't make
>> >> sense, as the line hasn't been there before. Likewise the opposite
>> >> when stopping moving. So here I keep a little state in the SCH_FIELD
>> >> component that keeps track if the _last_ draw operation was seeing
>> >> IsMoving(). I haven't found if there is a better way within the
>> >> framework to better get informed about these transitions. If so,
>> >> please point me how to implement that more elegantly.
>> >>
>> >> And as usual, here the patch download link:
>> >>
>> >> https://github.com/hzeller/kicad/compare/master...show-belongs-to-edge-while-moving-labels.diff
>> >>
>> >> cheers,
>> >> -henner
>> >
>> > Good idea.
>> > This feature was existing in Pcbnew, but not in Eeschema.
>> > May I ask you to have a look to our coding style policy
>> > (see Documentation/coding_style_policy.pdf) before submitting a patch.
>> >
>> > Thanks for your interest in Kicad.
>> >
>>
>> This is a great feature, thanks for your interest Henner!
>>
>> Best Regards, Brian.
>>
>> _______________________________________________
>> 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
>
Follow ups
References