kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #15518
Re: eeschema drawing behavior?
2014-10-30 22:21 GMT+01:00 Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>:
>
>>> (2a) eeschema: Block Move:
>>> When doing a block move everything of the block is drawn in black, similar to “grab" from (1) but different to normal “move”.
>>
>> And this, the wires and the symbol is black here.
>>
>>> (2b) eeschema: Block Move:
>>> When doing a block move original content is still shown (in color), additionally I have the black instance following my mouse.
>>
>> Ehh, what is the difference between (2a) and (2b)? Seems like two
>> formulations of the same thing.
>
> (2a) was meant to be about the color only, whereas (2b) is that the original item is not removed during the move.
> But yes, same use-case… :)
Ok, then (2b), yes, the original is still colored. I also note that
when I move the block fast the text of the original is drawn again
breifly where it is whole the text, otherwise it is like it was shown
on the image I attached earlier. And by the way, these artifacts seem
to be where two line segements overlap. I now wonder whoat it will be
like if three segments overlap, if that will be white again (using
white background color).
>>> (3) Library Editor: Move:
>>> If I “move” a pin then it is really moved, i.e. the original pin is removed, only the moving one following my mouse is visible (in normal color).
>>> If I “move” a rectangle/text/… (anything else not being a pin?) then the original item is still there additionally to the moving one following my mouse. Looks/Feels more like a “copy” (which it isn’t… if you place it then the original item disappears).
>>> Similar to (2b), but both instances (original/moving) are in normal color.
>>>
>>> Maybe there are some more, those are the ones that I found quite easy just playing around a bit…
>>
>> I think I am seeing the behaivour you describe there. But when U move
>> the text in the library editor, it seems to me like the artifact text
>> is what is kind of missing form the thing actually moved, see the
>> attached screenshot. Note the 74LS03 text that I moved down.
>
> Yes, I guess so… although I don’t see artifacts like you. But, I think this is due to wxWidgets on Linux using XOR to draw/erase which OSX doesn’t support. What you see could probably be some artifacts of XORing - on OSX always the complete old item was drawn.
>
> Thanks, at least it seems that I didn’t brake “normal” behavior… I was not quite sure about changes in some spots that could have caused such “inconsistent” behavior.
Hmm, ok, but what I see on my side was tested with 5217 and wx 3.0.2.
Should my build be newer?
>
> Regards,
> Bernhard
>
Follow ups
References