Hi Orson,
I have compiled the current master and tested out the footprint selection.
> On Aug 1, 2017, at 9:08 AM, Maciej Sumiński wrote:
>
> On 07/21/2017 11:34 PM, Piotr Esden-Tempski wrote:
> [snip]
>> 1) If a component is very large in the current zoom level it
On 07/21/2017 11:34 PM, Piotr Esden-Tempski wrote:
[snip]
> 1) If a component is very large in the current zoom level it should be
> ignored. It makes it very difficult to select small components that end up on
> the opposite side of a large component. It is also very unlikely the user
> will
Just to let you know, I have just pushed a patch that implements
Jean-Pierre's idea for choosing the footprint drag anchor.
Regards,
Orson
On 07/20/2017 01:50 PM, Maciej Sumiński wrote:
> Hi Jean-Pierre,
>
> On 07/20/2017 01:44 PM, jp charras wrote:
> [snip]
>>
>> AFAIK, for me "old" issues
about 1), I would suggest to change the selection behaviour of locked
footprints, to only select when parts of the footprint (line, pad,...)
are explicitly selected (not the area between). Area selection should
also not include locked footprints. This is likely something where users
want to
Good points, I'm especially excited about 1), our pcb edges are usually
footprints, so I'm always working inside a footprint, which is continuously
getting selected.
Cheers
On Jul 21, 2017 18:34, "Piotr Esden-Tempski" wrote:
> Hi,
>
> > On Jul 20, 2017, at 4:44 AM, jp charras
1) If a component is very large in the current zoom level it should be ignored.
It makes it very difficult to select small components that end up on the
opposite side of a large component. It is also very unlikely the user will want
to move the thing that is not even visible at the moment
Hi,
> On Jul 20, 2017, at 4:44 AM, jp charras wrote:
>
[SNIP]
>
> AFAIK, when moving a single footprint, the anchor point is either one of its
> pads or the footprint origin, the nearest candidate point from mouse cursor.
>
> Perhaps the algorithm should be slightly
> Perhaps the algorithm should be slightly modified to use the pad if the mouse cursor is inside a
> pad, and the footprint origin if the mouse cursor is inside the footprint (obviously), but not
> inside a pad.
Excellent idea, in combination with Simon Küppers suggestion to highlight the move
I am also currently not up to speed on this topic. However, what could
also benefit usability is to visually highlight the origin that is
being used during the move operation (maybe a green dot or something).
Am 20.07.2017 um 13:50 schrieb Lorenzo Marcantonio:
> On Thu, Jul 20, 2017 at
On Thu, Jul 20, 2017 at 01:44:06PM +0200, jp charras wrote:
> Perhaps the algorithm should be slightly modified to use the pad if the mouse
> cursor is inside a
> pad, and the footprint origin if the mouse cursor is inside the footprint
> (obviously), but not
> inside a pad.
Uhm. That could be,
Hi Jean-Pierre,
On 07/20/2017 01:44 PM, jp charras wrote:
[snip]
>
> AFAIK, for me "old" issues related to the cursor and grid are fixed.
>
> AFAIK, when moving a single footprint, the anchor point is either one of its
> pads or the footprint origin, the nearest candidate point from mouse
Le 20/07/2017 à 13:27, Maciej Sumiński a écrit :
> On 07/20/2017 12:37 PM, Lorenzo Marcantonio wrote:
>> On Thu, Jul 20, 2017 at 12:14:40PM +0200, Maciej Sumiński wrote:
>>> What do you exactly mean regarding the cursor behavior?
>>
>> For example the cursor moving on the grid and using space to
On 07/20/2017 12:37 PM, Lorenzo Marcantonio wrote:
> On Thu, Jul 20, 2017 at 12:14:40PM +0200, Maciej Sumiński wrote:
>> What do you exactly mean regarding the cursor behavior?
>
> For example the cursor moving on the grid and using space to take
> measurement is way faster. AFAIK this is already
On Thu, Jul 20, 2017 at 12:14:40PM +0200, Maciej Sumiński wrote:
> What do you exactly mean regarding the cursor behavior?
For example the cursor moving on the grid and using space to take
measurement is way faster. AFAIK this is already WIP.
Also if you move a footprint in the GAL you use the
Hi Lorenzo,
On 07/20/2017 12:04 PM, Lorenzo Marcantonio wrote:
[snip]
> However before junking it *please* implement everything on the new one
> (like the cursor behaviour which is way more useful to measure than the
> new tool in the GAL view)
What do you exactly mean regarding the cursor
15 matches
Mail list logo