kicad-developers team mailing list archive

[Henner Zeller <h.zeller@xxxxxxx>]

Hi,
Alright, fixed the draw artifact issue with filled boxes, Nick noticed.

The original artifact was due to the fact that the SCH_FIELD element
had to second-guess in which
mode it was in 'normal mode' or 'moving mode'.

This is now fixed the way it should be by explicitly telling the
component, via a flag, in which mode it is in, and have higher levels
that know when moving starts and stops set this mode.

When starting a move, after XOR-erasing the 'normal' representation,
the component is set into wire-rendering mode (which it can use to
choose to render differently than in 'normal' mode; which is what my
SCH_FIELD change is doing).

In the final step of a move operation (end of move or cancel), the
component to draw a final time in XOR mode to erase the wire-frame
representation, so that there  is no visual artifact if that is
different from the normal mode.

This is the 'right' solution to the problem (while the original
solution was more 'second guessing' its mode), does not use any more
memory (it uses one of the bits in the existing flag-field) and it
allows to have the notion of 'something looks different while moving
vs. normal' (which could be used by other components now as well).
Also I looked at the style guide and hope have fixed all issues there.

There are two questions before patching into upstream:
  - To not unnecessarily introduce a new flag, I was using
IS_WIRE_IMAGE, that was not used anywhere in the source code. Was this
the original/intended meaning of this flag ? If not, I am happy to add
a new flag.
  -  In other places in the code that has to do with redraws, there is
some special handling with the USE_WX_OVERLAY macro. I can't really
test this properly in my installation of wxWidgets, so I don't know if
I always do what would be needed in this case.


The original patch is just updated, so the same place here to view:
https://github.com/hzeller/kicad/compare/master...show-belongs-to-edge-while-moving-labels

.. download here
https://github.com/hzeller/kicad/compare/master...show-belongs-to-edge-while-moving-labels.diff

-h

On 7 February 2014 08:51, Henner Zeller <h.zeller@xxxxxxx> wrote:
> 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
>>