kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/31/2014 11:11 AM, Lorenzo Marcantonio wrote:
> Having to draw a new package since a long time I decided to give
> it a try... first of all, at last, the layer toolbar. Really
> useful, of course.
> 
> A couple of buglets: stuff isn't correctly initialized on open:
> the layer (top silk, as default) is not shown initially as selected
> and for some reason the default entity width is 0.2mm. Entering and
> giving OK to the sizes dialog fixes it. 99% that's something that
> could be fixed on the OnOpen event of the frame.
> 
> As of the size dialog: that could be usefully put on the toolbar.
> There is the absolutely useless print button so the size button
> would fit nicely near the pad setting one.

> In the zoom combo what is the 'auto' setting for? if it was
> intended to work like pressing 'home' it doesn't:P also it is not
> updated when zooming with F1/F2 (neither is the zoom value on the
> status bar; maybe some event is not firing). OK, actually I never
> had any use for the zoom value... it's simpler to judge cursor
> movement with actual coordinates.

Hi Lorenzo,

Thank you for the comments, I see here a few good points.
I have never realized that choosing "Auto" from the combo works the
same way as Home hot key. I am also interested if there are users who
use the combo box. I guess most people simply use the mousewheel or
hotkeys (correct me if I am wrong).
F1/F2 do not go throught the zoom list - they compute new zoom
settings basing on the current one. GAL sometimes uses non-standard
zoom values. I do not know if you noticed, but if you zoom using mouse
wheel, the zoom changes depend on the scrolling speed (to be precise -
intervals between consecutive scroll events).

> While on the zooming behaviour: it could be considered to add the 
> recentering behaviour of the zoom (as an option, like in the
> standard mode). It's way faster to use, I don't care about that
> "never warp the cursor dogma" (and *all* CAD programs have their UI
> quirks anyway).
> 
> That's also for the main pcb frame. Example: I want to center on
> component way to the right.
> 
> Traditional recentering behaviour: 1) Zoom out (wheel, some steps
> depending on how far I want to go) 2) Move cursor on the object
> (small movement to the right) 3) Zoom in (wheel, as before in the
> other direction)
> 
> That's two wheel moves and one cursor move. With the non
> recentering behaviour: 1) Zoom out, as before 2) Move cursor as
> before 3) Zoom in as before 4) *Pan to recenter the object* <<<
> Useless step :D

I am wondering - is the step 4 really necessary? The current scrolling
behaviour does not warp the mouse cursor (as advised in UI handbooks)
and still zooms in the object under the cursor. Does it matter if it
is perfectly in the screen center or offsetted a bit?

> Of course the beginner user would pan all the way right, but I hope
> he will learn the technique... by the way the border pan is really
> slow (and I find smooth scrolling tiring on the eye, anyway) so he
> better learn fast :D

Jumpy scrolling requires to warp the mouse cursor, I am trying to
avoid it as much as possible.
It should not be very hard to adjust border panning speed in the code,
but there is still no option UI to do so. It would be better not to
add GAL-specific settings now, as they may confuse users if they do
not apply to the default renderer.

> On the tools: at last the arc tool is complete (applause). Line
> tools has a break vertex function (another applause). However I
> really miss the keyboard cursor motion. Also it seems that pressing
> the arrow keys break the keyboard handling. Like in "ESC and space
> don't work after pressing an arrow". Probably wx interpret the
> arrows as focus change and keyboard events go to another object.
> 
> Still I find the OpenGL nearly usable on the tungsten/intel GPU.
> Aside of drawing speed, proper dialogs visibly flash when popping
> up. It's not a kicad/X issue, I think it's a performance limitation
> of the tungsten (which, by the way, except for the latest X series
> have no fragment shader support in hardware... you can be OpenGL
> compliant even with a fully software implementation). And even on
> windows you *don't* want to use altium with one of these, it really
> sucks:P

I am wondering if the Cairo backend would not work better for you.
Long time ago I was experimenting to enhance the performance [1]. To
gain even more speed, you could also disable antialiasing as I know
you hate it.

Regards,
Orson

[1] https://code.launchpad.net/~orsonmmz/+junk/cairo_fast
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQEcBAEBAgAGBQJUA1VXAAoJEBRwGu1hpbJ17xIH/2bfuPWu72cg20UZNRUpthkE
rQ0KBT5/8IjDe+aJMeMY2lcQihqJglo1XHwup9kD7uZgv/pnCRKyktFuZbY2J8TH
hHbx8inR8en0zUw/+U1HkBV7LSf75LJwZsraPZ8ov+Yh69jeFh0TE5fhVtLd1Uf7
4UdXOzYk85p8DZsXCO1gbCLkiJsPthfHyIw16n1ER6FH3V2zu25J+QXeDVHswflJ
Q8UvnOGx6tXAQWCt6qPdLQoeLrj1xnVNnmWt8uy+jlvCwTJcXTJWrmopBSnpN7IY
pJw0JJWg+BPO2i69kZkFAurj1nS2s75Pl0hpizHMgLEkf8HUi1fghLEblA0XCzQ=
=jZiB
-----END PGP SIGNATURE-----