Re: [Kicad-developers] Future plans on the KiCad library releases?

[Matthijs Kooijman]

Hi Wayne,

> KiCad should not be determining which libraries get loaded just because
> our library layout gets more complex.  I would reject any design changed
> that loaded libraries outside the users control.  Maybe I'm misreading
> this but it kind of sounds like that to me.
My proposal would indeed be to load libraries, without the user
configuring each individual library. However, the user would configure
the entire thing (e.g. "load *all* libraries from the default
distribution") and can disable the entire thing (and load libraries
individually) if he wants more control.

As a user, that is exactly the amount of control I want. I don't realy
care about which official libraries are in my library list exactly, I
just want all of them so I have the broadest choice in components and
footprints.

Additionally, I don't really want to think about this when upgrading. If
I upgrade the libraries package, I really want to still be able to just
use all official libraries, without having to check after each upgrade
if there is perhaps a new .lib file that was not there before (which, I
think, involves removing them all and re-adding them as the easiest way
to do that). Currently, if some symbols are split off into a new
library, and I forget to check this, they will silently disappear from
my choice of symbols, and I might not even realize this (and simply
assume a symbol I am looking for does not exist yet).

Even if I wanted to go through the trouble of checking the library list
on upgrades, I might not always actually realise that I've upgraded when
using distribution packages that get upgraded as part of a bigger
upgrade.

What I write here is how *I* would like to see things as a user. I can
imagine this applies to more, if not most, users as well.


One additional caveat I recently realized: Even if you would
automaticlaly update the list of libraries, you will additionally need
to rename/remap some symbols, since symbol references include the
library name in v5. One way I can imagine this works is to also include
a "rename" specification (perhaps similar to the current rename.json),
which can be used by KiCad to automatically migrate older symbol
references. Or perhaps the rescue dialog can be improved to look among
other libraries for a symbol with the same name and let the user choose
between relinking to such a symbol, or resueing one from the cache.

Gr.

Matthijs


signature.asc
Description: PGP signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Libedit and Modedit Icons

[Wayne Stambaugh]

Thanks Chris!  You got to this before I had a chance to respond.  We
need to calm down and move forward with the stable 5 release.  Getting
hung up on icon details isn't going to get us anywhere.  I should have
pushed all of the off until v6.  Lesson learned.  Now that it's merged,
I will only accept minor tweaks to existing icons.  If you want to do
any significant icon changes, it will have to wait for v6.

On 01/16/2018 12:15 PM, Chris Pavlina wrote:
> Can't we quit this icon bickering? Opinions are like buttholes, you all
> have one and I'm not the least bit interested in seeing yours.
> 
> This thread is getting _exhausting_. Everyone stop replacing everyone's
> icons constantly, everyone stop nitpicking, everyone just go home and
> find something better to do. Maybe someday we'll be able to hire a
> graphic designer to overhaul our stuff - at which point we need to all
> agree that their word is law. Until then let's just be happy we _have_
> icons.

When I was your age, we didn't even have icons.  All we had were
characters and we liked it! Sorry, couldn't resist! :)

> 
> On Tue, Jan 16, 2018 at 10:57:12AM +, Jörg Hermann wrote:
>> A majority of participants on the ML found the new icons a step forward and 
>> we have a commit.
>> We won’t ever reach a point where we can satisfy everybody, so we must live 
>> with the democratic majority.
>> All concerns and inputs raised after the commit are sound, valid and wise 
>> and should be considered for V6.
>>
>> Again I ask, no beg, everybody to get V5 out of the door and not be 
>> distracted by minuscule details like icon design.
>>
>> Don’t get me wrong: UI design is IMPORTANT, icon design is ART and 
>> KNOWLEDGE, but in the bigger picture of the pile of work that represents the 
>> Kicad project as a whole, it is a rather minor feature. I feel this because 
>> Kicad is used by technical driven people, who usually don't care that much 
>> about aesthetics, as long as the knob gets the job done.
>>
>> My 2 ct.
>> Jörg
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] macOS Nightly

[Nick Østergaard]

Yes, and this was introduced in 786312b103

kicad/common/dialog_shim.cpp:573:5: error: use of undeclared
identifier 'ReparentQuasiModal'


http://ci.kicad-pcb.org/job/osx-kicad-adam-head/


2018-01-16 18:42 GMT+01:00 Michael Kavanagh :

> Hi all,
>
> Just a heads up the macOS nightly build seems to be failing. Last
> completed successfully on 12th Jan.
>
> Cheers,
> Michael
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Improving behavior and logic of Findngspice.cmake

[Dan Weatherill]

Hi Carsten,
have you tried specifying -DCMAKE_LIBRARY_ARCHITECTURE=x86_64-linux-gnu
when calling cmake in the build script?

Relevant documentation here, in roughly the 2nd paragraph:
https://cmake.org/cmake/help/v3.0/command/find_library.html

Thanks,
Dan W

On Tuesday, 16 January 2018 19:23:25 GMT Carsten Schoenert wrote:
> Hi,
> 
> as written some days ago I'm working currently on packaging of ngspice
> for Debian main.
> For this I must follow the Debian (packaging) policy [1]. This requires
> the installation of shared libraries into /usr/lib/triplet due policy
> 9.1.1.4 (see [2]). triplet means here the architecture there the
> installation is happen. For i386 this would be the folder
> '/usr/lib/i386-linux-gnu' and for amd64 '/usr/lib/x86_64-linux-gnu' and
> so on.
> 
> The build of the KiCad development tree is currently not working with
> those folders as the cmake snippet for libngspice does not care about
> this constellation.
> 
> I would provide a patch here to fix this but I have no real clue about
> CMake! So I requesting some help here, could please someone with more
> knowledge than me improve the cmake helper for libngspice to search also
> in such folders for the library? The header is already found in the new
> (default) installation folder /user/include.
> So far I've could find relevant and depended information the path there
> to look while searching for libngsice.so would be
> /usr/lib/${CMAKE_LIBRARY_ARCHITECTURE} for CMake.
> 
> And, if someone is going to dig into this could also be added the search
> and pickup of a pkg-config file for libngspice? I will work on adding a
> pkg-config file for libngspice in the next week so it would be great if
> the intelligence for using of a pkg-config file could be added in the
> same go.
> 
> I think something like this logic should be sufficient and not collide
> with the current content.
> 
> if (pkg-config found)
>   do read the pkg-config
> else
>   search for the devel files manually
> fi
> 
> Thanks!
> 
> I gladly help to test modifications of Findngspice.cmake.
> 
> [1] https://www.debian.org/doc/debian-policy/
> [2] https://www.debian.org/doc/debian-policy/#file-system-structure



signature.asc
Description: This is a digitally signed message part.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Improving behavior and logic of Findngspice.cmake

[Carsten Schoenert]

Hi,

as written some days ago I'm working currently on packaging of ngspice
for Debian main.
For this I must follow the Debian (packaging) policy [1]. This requires
the installation of shared libraries into /usr/lib/triplet due policy
9.1.1.4 (see [2]). triplet means here the architecture there the
installation is happen. For i386 this would be the folder
'/usr/lib/i386-linux-gnu' and for amd64 '/usr/lib/x86_64-linux-gnu' and
so on.

The build of the KiCad development tree is currently not working with
those folders as the cmake snippet for libngspice does not care about
this constellation.

I would provide a patch here to fix this but I have no real clue about
CMake! So I requesting some help here, could please someone with more
knowledge than me improve the cmake helper for libngspice to search also
in such folders for the library? The header is already found in the new
(default) installation folder /user/include.
So far I've could find relevant and depended information the path there
to look while searching for libngsice.so would be
/usr/lib/${CMAKE_LIBRARY_ARCHITECTURE} for CMake.

And, if someone is going to dig into this could also be added the search
and pickup of a pkg-config file for libngspice? I will work on adding a
pkg-config file for libngspice in the next week so it would be great if
the intelligence for using of a pkg-config file could be added in the
same go.

I think something like this logic should be sufficient and not collide
with the current content.

if (pkg-config found)
  do read the pkg-config
else
  search for the devel files manually
fi

Thanks!

I gladly help to test modifications of Findngspice.cmake.

[1] https://www.debian.org/doc/debian-policy/
[2] https://www.debian.org/doc/debian-policy/#file-system-structure

-- 
Regards
Carsten Schoenert

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Defer canvas type setting save until destruction of EDA_DRAW_FRAME

[Maciej Suminski]

For me - not entirely, but definitely it is better than the current
implementation. If you run KiCad for the first time and select 'Enable
hardware acceleration' on a machine that does not support OpenGL, it
switches to Cairo (correctly). Then, when you turn off KiCad, it will
save OpenGL as the default canvas and you will not be able to run pcbnew
again until you manually modify the configuration files (or remove them).

I will have another trial at fixing the problem, finally I have an
environment where I can test different solutions.

Cheers,
Orson

On 01/16/2018 07:04 PM, Chris Pavlina wrote:
> Yes! You got it, works for me :)
> 
> On Tue, Jan 16, 2018 at 05:16:57PM +, Chris Pavlina wrote:
>> Sorry I disappeared for a while. I'm building on the machine where I
>> experienced the bug right now.
>>
>> On Tue, Jan 16, 2018 at 04:26:16PM +, Jon Evans wrote:
>>> Wayne/Orson, I'm not sure Chris will have time to review this, could you
>>> please take a look?
>>>
>>> Thanks,
>>> Jon
>>>
>>> On Thu, Jan 11, 2018 at 11:02 PM, Jon Evans  wrote:
>>>
 Updated patch attached (missed initializers in the original)

 On Wed, Jan 10, 2018 at 11:40 PM, Jon Evans  wrote:

> Hopefully this fixes:
> https://bugs.launchpad.net/kicad/+bug/1741787
> although I don't currently have a good way of reproducing the crash.
>
> Chris, if you can give it a try on your crashing machine that would be
> greatly appreciated.
>
> Thanks
> -Jon
>


>>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] One more quick plug for reducing "Clarify Selection" dialogs

[Jeff Young]

Hi Seth,I looked into this, and I’m not sure it helps.  The call-chain between ExchangeFootprints and where the GENERAL_COLLECTOR is instantiated looks something like:




SELECTION_TOOL::RequestSelectionPCB_ACTIONS::selectionCursorSELECTION_TOOL::CursorSelectionSELECTION_TOOL::selectCursorSELECTION_TOOL::selectPointThe first of those has a flags parameter, so I could add FOOTPRINTS_ONLY to the flag set.  But from there it gets dicier because the PCB_ACTION is an event.  The event has a user-data field, but it’s currently being used for the client selection filter, so we’d have to add another level of indirection (or cheat and say any void* with a value less than 100 isn’t a real pointer and holds flags instead — but that’s hard to love).So I think getting rid of the FootprintsFilter would actually increase the cross-section, rather than decreasing it.I’ve attached another version of the patch which includes Orson’s changes along with a guard for the issue you mentioned earlier.  Can you let me know if it helps?Thanks,Jeff.

0001-Avoid-selection-disambiguation-menu-when-possible.patch
Description: Binary data
On 16 Jan 2018, at 18:28, Seth Hillbrand  wrote:I observe a similar issue following Orson's procedure and the new patch.  For me, the selection tool will lock selected when there is no element in the selection, causing the screen to scroll when I move the mouse to the edge and I can't get out of the tool selection.I tried to poke through the patch to see where this might be happening, but I honestly can't tell which of the changes were required to implement the change and which were just changes to the code.I'd like to renew the request for a minimally-invasive patch.  There is no reason to add an additional footprint filter (and by extension an additional place for bugs) to ExchangeFootprints, etc.  I don't think that this is where the issue I experience originates but it increases the bug cross-section.Let me re-iterate: I like this idea.  I think Jeff has a good solution to the problem.  I just think that this particular patch can be less invasive and therefore help bug-hunting in the future.-S2018-01-16 6:46 GMT-08:00 Kristoffer Ödmark :I just tried the patch, I cannot replicate this behaviour in linux at least. Patch works as advertised for me at least.

Application: kicad
Version: (2018-01-16 revision 5571a76e5)-master, release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0
Platform: Linux 4.14.13-1-MANJARO x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.66.0
    Curl: 7.57.0
    Compiler: GCC 7.2.1 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=ON


 -Kristoffer

On 01/16/2018 02:15 PM, Maciej Sumiński wrote:

I am seeing a different behavior, I think it is best shown on a
screencast [1]. When I start dragging a footprint, mouse cursor is
warped back to the drag origin, so the footprint is never moved. If
footprint was previously selected, then selection is cleared, but it is
still stuck.

Cheers,
Orson

1. https://orson.net.pl/pub/kicad_drag.ogv

On 01/16/2018 01:51 PM, Jeff Young wrote:

Hi Orson,

Can you say more about the drag issue?

If I click in a footprint and drag, it drags the footprint.
If I click in a footprint’s pad and drag, it drags the footprint.
Same is true whether footprint/pad was previously selected or not.
Same is true with trackpad 3-finger drag.

Is one of these wrong, or are you seeing different behaviour?

Thanks,
Jeff.


On 16 Jan 2018, at 12:24, Maciej Sumiński  wrote:

Hi Jeff,

I apologize for long delay. I have just reviewed and tested your patch
and the changes look fine, but there is one thing that needs to be
addressed before they can be accepted. Dragging a footprint with mouse
cursor does not work anymore, cursor simply gets stuck at the drag
origin position. Once it is fixed, I am willing to push your patch.

Please also consider that attached patch that fixes the code formatting.

Cheers,
Orson

On 01/09/2018 06:38 PM, Jeff Young wrote:

The heat gets bumped up for multiple reports or when people click “this bug affects me too”.

Patch uploaded.

https://bugs.launchpad.net/kicad/+bug/1708869 

(The duplicate: https://bugs.launchpad.net/kicad/+bug/1503679  )

Cheers,
Jeff.


On 9 Jan 2018, at 16:06, Wayne Stambaugh  wrote:

Hey Jeff,

I'm not sure what a heat of 22 even means?  I don't see any comments or
suggestions in the bug report where 

Re: [Kicad-developers] One more quick plug for reducing "Clarify Selection" dialogs

[Seth Hillbrand]

I observe a similar issue following Orson's procedure and the new patch.
For me, the selection tool will lock selected when there is no element in
the selection, causing the screen to scroll when I move the mouse to the
edge and I can't get out of the tool selection.

I tried to poke through the patch to see where this might be happening, but
I honestly can't tell which of the changes were required to implement the
change and which were just changes to the code.

I'd like to renew the request for a minimally-invasive patch.  There is no
reason to add an additional footprint filter (and by extension an
additional place for bugs) to ExchangeFootprints, etc.  I don't think that
this is where the issue I experience originates but it increases the bug
cross-section.

Let me re-iterate: I like this idea.  I think Jeff has a good solution to
the problem.  I just think that this particular patch can be less invasive
and therefore help bug-hunting in the future.

-S

2018-01-16 6:46 GMT-08:00 Kristoffer Ödmark :

> I just tried the patch, I cannot replicate this behaviour in linux at
> least. Patch works as advertised for me at least.
>
> Application: kicad
> Version: (2018-01-16 revision 5571a76e5)-master, release build
> Libraries:
> wxWidgets 3.0.3
> libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1
> (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0
> Platform: Linux 4.14.13-1-MANJARO x86_64, 64 bit, Little endian, wxGTK
> Build Info:
> wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
> Boost: 1.66.0
> Curl: 7.57.0
> Compiler: GCC 7.2.1 with C++ ABI 1011
>
> Build settings:
> USE_WX_GRAPHICS_CONTEXT=OFF
> USE_WX_OVERLAY=OFF
> KICAD_SCRIPTING=ON
> KICAD_SCRIPTING_MODULES=ON
> KICAD_SCRIPTING_WXPYTHON=ON
> KICAD_SCRIPTING_ACTION_MENU=ON
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCE=ON
> KICAD_SPICE=ON
>
>
>  -Kristoffer
>
> On 01/16/2018 02:15 PM, Maciej Sumiński wrote:
>
>> I am seeing a different behavior, I think it is best shown on a
>> screencast [1]. When I start dragging a footprint, mouse cursor is
>> warped back to the drag origin, so the footprint is never moved. If
>> footprint was previously selected, then selection is cleared, but it is
>> still stuck.
>>
>> Cheers,
>> Orson
>>
>> 1. https://orson.net.pl/pub/kicad_drag.ogv
>>
>> On 01/16/2018 01:51 PM, Jeff Young wrote:
>>
>>> Hi Orson,
>>>
>>> Can you say more about the drag issue?
>>>
>>> If I click in a footprint and drag, it drags the footprint.
>>> If I click in a footprint’s pad and drag, it drags the footprint.
>>> Same is true whether footprint/pad was previously selected or not.
>>> Same is true with trackpad 3-finger drag.
>>>
>>> Is one of these wrong, or are you seeing different behaviour?
>>>
>>> Thanks,
>>> Jeff.
>>>
>>> On 16 Jan 2018, at 12:24, Maciej Sumiński 
 wrote:

 Hi Jeff,

 I apologize for long delay. I have just reviewed and tested your patch
 and the changes look fine, but there is one thing that needs to be
 addressed before they can be accepted. Dragging a footprint with mouse
 cursor does not work anymore, cursor simply gets stuck at the drag
 origin position. Once it is fixed, I am willing to push your patch.

 Please also consider that attached patch that fixes the code formatting.

 Cheers,
 Orson

 On 01/09/2018 06:38 PM, Jeff Young wrote:

> The heat gets bumped up for multiple reports or when people click
> “this bug affects me too”.
>
> Patch uploaded.
>
> https://bugs.launchpad.net/kicad/+bug/1708869 <
> https://bugs.launchpad.net/kicad/+bug/1708869>
>
> (The duplicate: https://bugs.launchpad.net/kicad/+bug/1503679 <
> https://bugs.launchpad.net/kicad/+bug/1503679> )
>
> Cheers,
> Jeff.
>
> On 9 Jan 2018, at 16:06, Wayne Stambaugh  wrote:
>>
>> Hey Jeff,
>>
>> I'm not sure what a heat of 22 even means?  I don't see any comments
>> or
>> suggestions in the bug report where lots of devs and/or users gave it
>> a
>> big thumbs up.  I'm talking about getting some input on the concept
>> and
>> testing on a patch from other devs and users.  I can't remember, did
>> you
>> supply a patch for this?  I don't see one on the bug report.  I need
>> to
>> review and test it at a minimum.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 1/9/2018 10:39 AM, Jeff Young wrote:
>>
>>> Hi Wayne,
>>>
>>> Well, the bug has a heat of 22, so it’s definitely not just me. ;)
>>>
>>> My change doesn’t alter the dragging or selecting behaviour.  All it
>>> does is keep an extraneous “Clarify Selection” menu from coming up
>>> (which I think all our users would consider a bug).  What we
>>> currently
>>> do in these situations is akin to 

Re: [Kicad-developers] KiCad And Quces

[Dan Weatherill]

gnucap would also be very nice, especially for mixed signal stuff.
That said my impression of it is that its development is not especially active 
at the moment.

Dan W


On Tuesday, 16 January 2018 09:22:49 GMT Babar Malik wrote:
> Thanks a lot. As far as my background knowledge is concerned, I am familiar
> with C++ but I didn't executed any project which includes a complete
> software development.
> 
> Babar
> 
> Best Regards,
> Muhammad Babar Malik
> Namal College Mianwali
> An Associate College of University of Bradford
> 
> On 16 January 2018 at 13:38, Christian Gagneraud  wrote:
> > CC Qucs's maintainer, please feel free to extend.
> > 
> > On 16 January 2018 at 21:14, Babar Malik  wrote:
> > > I am much more interested to integrate Kicad and Qucs,  and the first
> > 
> > step
> > 
> > > towards this would be to study the source code of Kicad from scratch.
> > > Can
> > > you please help me regarding to this ? Please guide me from where I
> > 
> > should
> > 
> > > take first step?
> > > your help will be highly appreciated.
> > 
> > Hi Babar, (Please keep mailing list(s) posted)
> > 
> > Integrating KiCAD and Qucs can be done at several levels.
> > Both projects are written in C++, but one uses WxWidgets, while the
> > other is using Qt (3, 4, but not 5).
> > So maybe a possible approach would be to try to integrate qucsator
> > (the core simulation engine) with KiCAD's GUI.
> > That is: do not try to merge/join them at C++ level, but at process level.
> > Please also note that Qucs has some friendly forks that attempts to
> > consolidate alternative simulation engines (ngspice, xyce, gnucap,
> > spice opus, ...)
> > 
> > See eg.: https://qucs-help.readthedocs.io/en/spice4qucs/BasSim.html
> > 
> > I have no authority in any of the aforementioned projects, but may I
> > suggest to contact the developer mailing of each project.
> > Have a look at each project git repo, and don't hesitate to ask
> > question on respective mailing lists.
> > 
> > Some starting points:
> > https://github.com/Qucs
> > https://ra3xdh.github.io/
> > https://github.com/KiCad
> > https://savannah.gnu.org/git/?group=gnucap
> > https://github.com/Qucs/gnucsator
> > 
> > As I said, if you want to integrate qucs and KiCAD, you might want to
> > focus on using qucsator/gnucsator as simulation backend(s) in KiCAD
> > 
> > Don't feel overwhelmed, dive in and ask! ;)
> > 
> > What's your background? What are your skills and experience? It might
> > be useful to present yourself so that community members can understand
> > where you're coming from and how to help you to achieve your goals.
> > 
> > Chris



signature.asc
Description: This is a digitally signed message part.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Implement primitive icon scaling for high DPI

[Vesa Solonen]

Chris Pavlina kirjoitti 16/01/18 klo 01:04:
> I like our font. It looks professional, like it belongs in an
> engineering drawing - waaay better than a certain other package that
> defaults to some serif font (Times New Roman maybe? blehhh). Would be
> nice to be able to change fonts though.
> 
> On Mon, Jan 15, 2018 at 11:00:22PM +, Jeff Young wrote:
>> I agree that it’s not the best, but I’d rather have a better schematic fonts 
>> than sharper icons. ;)

My guess is that better fonts was mostly related to rendering. Pixel
grid fitting, hinting and antialiasing. Gschem sets quite an example
compared to Kicad rough scaling.

-Vesa


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] macOS Nightly

[Michael Kavanagh]

Hi all,

Just a heads up the macOS nightly build seems to be failing. Last completed
successfully on 12th Jan.

Cheers,
Michael
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Defer canvas type setting save until destruction of EDA_DRAW_FRAME

[Chris Pavlina]

Sorry I disappeared for a while. I'm building on the machine where I
experienced the bug right now.

On Tue, Jan 16, 2018 at 04:26:16PM +, Jon Evans wrote:
> Wayne/Orson, I'm not sure Chris will have time to review this, could you
> please take a look?
> 
> Thanks,
> Jon
> 
> On Thu, Jan 11, 2018 at 11:02 PM, Jon Evans  wrote:
> 
> > Updated patch attached (missed initializers in the original)
> >
> > On Wed, Jan 10, 2018 at 11:40 PM, Jon Evans  wrote:
> >
> >> Hopefully this fixes:
> >> https://bugs.launchpad.net/kicad/+bug/1741787
> >> although I don't currently have a good way of reproducing the crash.
> >>
> >> Chris, if you can give it a try on your crashing machine that would be
> >> greatly appreciated.
> >>
> >> Thanks
> >> -Jon
> >>
> >
> >


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Libedit and Modedit Icons

[Chris Pavlina]

Can't we quit this icon bickering? Opinions are like buttholes, you all
have one and I'm not the least bit interested in seeing yours.

This thread is getting _exhausting_. Everyone stop replacing everyone's
icons constantly, everyone stop nitpicking, everyone just go home and
find something better to do. Maybe someday we'll be able to hire a
graphic designer to overhaul our stuff - at which point we need to all
agree that their word is law. Until then let's just be happy we _have_
icons.

On Tue, Jan 16, 2018 at 10:57:12AM +, Jörg Hermann wrote:
> A majority of participants on the ML found the new icons a step forward and 
> we have a commit.
> We won’t ever reach a point where we can satisfy everybody, so we must live 
> with the democratic majority.
> All concerns and inputs raised after the commit are sound, valid and wise and 
> should be considered for V6.
> 
> Again I ask, no beg, everybody to get V5 out of the door and not be 
> distracted by minuscule details like icon design.
> 
> Don’t get me wrong: UI design is IMPORTANT, icon design is ART and KNOWLEDGE, 
> but in the bigger picture of the pile of work that represents the Kicad 
> project as a whole, it is a rather minor feature. I feel this because Kicad 
> is used by technical driven people, who usually don't care that much about 
> aesthetics, as long as the knob gets the job done.
> 
> My 2 ct.
> Jörg
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Implement primitive icon scaling for high DPI

[Chris Pavlina]

On Tue, Jan 16, 2018 at 09:49:51AM +, Fabrizio Tappero wrote:
> Hi Thomas,
> thanks for the pics. All icons seem out of focus to me. I however
> understand that if you need bigger icons you need bigger incons
> 
>  It might make sense to chose a 200% magnification only. In this case
> sharpness is preserved.

I can assure you there is no visible difference in sharpness between
175% and 200% on my monitor.

> 
> I shall also say that if your monitor has a higher enough DPI sharpness due
> to icon magnification should not be visible.
> 
> Cheers
> Fabrizio
> 
> On Mon, Jan 15, 2018 at 4:51 PM, Thomas Figueroa 
> wrote:
> 
> > I’ve attached scaling at 150%, 225%, and 250% (W10, 4k screen with DPI
> > around 280 like Chris). The icons all look fine at all of these scalings.
> > Before Chris’s patch, I manually created bitmaps from the SVGs at higher
> > resolution (2.25x) and they not only scaled very well, they looked very
> > nice. So based on these two experiences, the icons are very capable of
> > scaling appropriately.
> >
> >
> >
> >
> > --
> > *From:* Kicad-developers  > hotmail@lists.launchpad.net> on behalf of Fabrizio Tappero <
> > fabrizio.tapp...@gmail.com>
> > *Sent:* Monday, January 15, 2018 3:52:32 AM
> > *To:* Chris Pavlina
> > *Cc:* KiCad Developers
> > *Subject:* Re: [Kicad-developers] [PATCH] Implement primitive icon
> > scaling for high DPI
> >
> > Hi,
> > Can anybody with a high DPI monitor post some pics at different scaling
> > setting please.
> >
> > An enormous effort was put in making this icons look good in they actual
> > fixed resolution. I am curious how a >250DPI monitor can display icons well
> > regardless of this effort.
> >
> > Cheers
> > Fabrizio
> >
> >
> > On Thu, Jan 11, 2018 at 6:06 PM, Chris Pavlina 
> > wrote:
> >
> >> Yup. For reference my own display is around 280 DPI.
> >>
> >> On Thu, Jan 11, 2018 at 10:35:15AM +, Jeff Young wrote:
> >> > 2560x1440 @ 24” is only 122 DPI.
> >> >
> >> > Apple’s Retina displays are 220 or 227, and the Surface Book in the
> >> original bug report is 267 DPI.
> >> >
> >> > > On 11 Jan 2018, at 09:54, kristoffer Ödmark <
> >> kristofferodmar...@gmail.com> wrote:
> >> > >
> >> > > I have 2560x1440, 24" screens, I think those qualifies as high DPI?
> >> > >
> >> > > The slider value is at 100, and the diag value is at 23. The icons
> >> are ish 5mm large.
> >> > >
> >> > > But i guess that is uneccesary since It seems the scaling works as
> >> intended, I was just doing it wrong, so no errors, sorry :)
> >> > >
> >> > > The scaling seems correct as well, 100 = 5mm, 150 = 7.5, 200 = 11,
> >> measured with a tape measure, so variance in size is expected.
> >> > >
> >> > >
> >> > > Application: kicad
> >> > > Version: (2018-01-11 revision a5b3d8e57)-master, debug build
> >> > > Libraries:
> >> > > wxWidgets 3.0.3
> >> > > libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4
> >> libpsl/0.19.1 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0
> >> > > Platform: Linux 4.9.74-2-MANJARO x86_64, 64 bit, Little endian, wxGTK
> >> > > Build Info:
> >> > > wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+
> >> 2.24
> >> > > Boost: 1.65.1
> >> > > Curl: 7.57.0
> >> > > Compiler: GCC 7.2.1 with C++ ABI 1011
> >> > >
> >> > > Build settings:
> >> > > USE_WX_GRAPHICS_CONTEXT=OFF
> >> > > USE_WX_OVERLAY=OFF
> >> > > KICAD_SCRIPTING=ON
> >> > > KICAD_SCRIPTING_MODULES=ON
> >> > > KICAD_SCRIPTING_WXPYTHON=ON
> >> > > KICAD_SCRIPTING_ACTION_MENU=OFF
> >> > > BUILD_GITHUB_PLUGIN=ON
> >> > > KICAD_USE_OCE=ON
> >> > > KICAD_SPICE=ON
> >> > >
> >> > >
> >> > > On 2018-01-11 01:13, Chris Pavlina wrote:
> >> > >> If your system DPI is already within a certain range it won't do
> >> > >> anything. Are you using a high DPI display? If it's not scaled
> >> > >> correctly, would you please share with me the diagnostic number
> >> reported
> >> > >> by the scale slider in eeschema prefs as well as a rough indication
> >> of
> >> > >> the icons' physical size? Thanks.
> >> > >>
> >> > >> On Wed, Jan 10, 2018 at 11:16:46PM +, kristoffer Ödmark wrote:
> >> > >>> Tried the patch, didnt really notice anything different though, I
> >> guess you
> >> > >>> need to add some custom scaling for this to take effect?
> >> > >>>
> >> > >>>
> >> > >>> On 2018-01-10 22:23, Chris Pavlina wrote:
> >> >  Sure, assign me to it. I should have time to work on it tonight or
> >> >  tomorrow.
> >> > 
> >> >  On Wed, Jan 10, 2018 at 04:20:21PM -0500, Wayne Stambaugh wrote:
> >> > > FYI, the edit footprint dialog in Pcbnew is not sized properly
> >> (at least
> >> > > on windows) which I'm pretty sure is related to your recent HiDPI
> >> work.
> >> > > Do you want me to file a bug report for it?
> >> > >
> >> > > On 1/10/2018 2:01 PM, Chris Pavlina 

Re: [Kicad-developers] [PATCH] Defer canvas type setting save until destruction of EDA_DRAW_FRAME

[Maciej Sumiński]

I have already read the patch, and IMHO it has a chance to fix the
problem. Right now I am building KiCad on an ultraslow virtual machine
that does not support OpenGL 2.1, so stay tuned!

Cheers,
Orson

On 01/16/2018 05:26 PM, Jon Evans wrote:
> Wayne/Orson, I'm not sure Chris will have time to review this, could you
> please take a look?
> 
> Thanks,
> Jon
> 
> On Thu, Jan 11, 2018 at 11:02 PM, Jon Evans  wrote:
> 
>> Updated patch attached (missed initializers in the original)
>>
>> On Wed, Jan 10, 2018 at 11:40 PM, Jon Evans  wrote:
>>
>>> Hopefully this fixes:
>>> https://bugs.launchpad.net/kicad/+bug/1741787
>>> although I don't currently have a good way of reproducing the crash.
>>>
>>> Chris, if you can give it a try on your crashing machine that would be
>>> greatly appreciated.
>>>
>>> Thanks
>>> -Jon
>>>
>>
>>
> 




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Defer canvas type setting save until destruction of EDA_DRAW_FRAME

[Jon Evans]

Wayne/Orson, I'm not sure Chris will have time to review this, could you
please take a look?

Thanks,
Jon

On Thu, Jan 11, 2018 at 11:02 PM, Jon Evans  wrote:

> Updated patch attached (missed initializers in the original)
>
> On Wed, Jan 10, 2018 at 11:40 PM, Jon Evans  wrote:
>
>> Hopefully this fixes:
>> https://bugs.launchpad.net/kicad/+bug/1741787
>> although I don't currently have a good way of reproducing the crash.
>>
>> Chris, if you can give it a try on your crashing machine that would be
>> greatly appreciated.
>>
>> Thanks
>> -Jon
>>
>
>


0001-Defer-canvas-type-setting-save-until-destruction-of.patch
Description: Binary data
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] One more quick plug for reducing "Clarify Selection" dialogs

[Maciej Sumiński]

I am seeing a different behavior, I think it is best shown on a
screencast [1]. When I start dragging a footprint, mouse cursor is
warped back to the drag origin, so the footprint is never moved. If
footprint was previously selected, then selection is cleared, but it is
still stuck.

Cheers,
Orson

1. https://orson.net.pl/pub/kicad_drag.ogv

On 01/16/2018 01:51 PM, Jeff Young wrote:
> Hi Orson,
> 
> Can you say more about the drag issue?
> 
> If I click in a footprint and drag, it drags the footprint.
> If I click in a footprint’s pad and drag, it drags the footprint.
> Same is true whether footprint/pad was previously selected or not.
> Same is true with trackpad 3-finger drag.
> 
> Is one of these wrong, or are you seeing different behaviour?
> 
> Thanks,
> Jeff.
> 
>> On 16 Jan 2018, at 12:24, Maciej Sumiński  wrote:
>>
>> Hi Jeff,
>>
>> I apologize for long delay. I have just reviewed and tested your patch
>> and the changes look fine, but there is one thing that needs to be
>> addressed before they can be accepted. Dragging a footprint with mouse
>> cursor does not work anymore, cursor simply gets stuck at the drag
>> origin position. Once it is fixed, I am willing to push your patch.
>>
>> Please also consider that attached patch that fixes the code formatting.
>>
>> Cheers,
>> Orson
>>
>> On 01/09/2018 06:38 PM, Jeff Young wrote:
>>> The heat gets bumped up for multiple reports or when people click “this bug 
>>> affects me too”.
>>>
>>> Patch uploaded.
>>>
>>> https://bugs.launchpad.net/kicad/+bug/1708869 
>>> 
>>>
>>> (The duplicate: https://bugs.launchpad.net/kicad/+bug/1503679 
>>>  )
>>>
>>> Cheers,
>>> Jeff.
>>>
 On 9 Jan 2018, at 16:06, Wayne Stambaugh  wrote:

 Hey Jeff,

 I'm not sure what a heat of 22 even means?  I don't see any comments or
 suggestions in the bug report where lots of devs and/or users gave it a
 big thumbs up.  I'm talking about getting some input on the concept and
 testing on a patch from other devs and users.  I can't remember, did you
 supply a patch for this?  I don't see one on the bug report.  I need to
 review and test it at a minimum.

 Cheers,

 Wayne

 On 1/9/2018 10:39 AM, Jeff Young wrote:
> Hi Wayne,
>
> Well, the bug has a heat of 22, so it’s definitely not just me. ;)
>
> My change doesn’t alter the dragging or selecting behaviour.  All it
> does is keep an extraneous “Clarify Selection” menu from coming up
> (which I think all our users would consider a bug).  What we currently
> do in these situations is akin to popping up a “Clarify Selection” menu
> with one item in it every time you click on a unambiguous item.
>
> In the corner case all my change does is prevent us from asking: do you
> want to drag the corner of a and b, or do you want to drag the corner of
> b and a, when in fact the two have identical semantics).  Everything
> after the menu (no matter which item you click) is exactly the same.
>
> Same with U and I.  My change has no effect on what is selected, it just
> keeps us from asking: do you want to select the trivial connection
> containing a or do you want to select the trivial connection containing
> b, when in fact both a and b are on the /same/ trivial connection.
> Again, everything after the menu (no matter which item you click) is
> exactly the same.
>
> Cheers,
> Jeff.
>
>> On 9 Jan 2018, at 15:27, Wayne Stambaugh > >> wrote:
>>
>> Jeff,
>>
>> Have actually confirmed that this is the desired behavior for this
>> outside of you own objectives?  I'm not saying that this is or isn't a
>> good idea but I personally don't drag trace corners around so I'm not
>> sure what the appropriate behavior should be.  You should get comments
>> from the dev list and users before you make a change like this.  As far
>> as pushing this to the dev repo, if it's not too invasive I will
>> consider it.  If it is a large change set, I would prefer that we hold
>> off until after the stable release.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 1/8/2018 5:49 AM, Jeff Young wrote:
>>> Wayne, if I could get you to don that old project manager’s hat one
>>> more time:
>>>
>>> If we’re still weeks out from declaring an RC, I wanted to make one
>>> more plug for getting rid of the Clarify Selection dialog when
>>> dragging corners or using ‘U’ or ‘I’ over a corner[1].
>>>
>>> While it’s marked Wishlist, it seriously impacts productivity when
>>> editing tracks, and I think most users would consider it a bug
>>> (particularly in the corner case when dragging the corner is 

Re: [Kicad-developers] One more quick plug for reducing "Clarify Selection" dialogs

[Jeff Young]

Hi Orson,

Can you say more about the drag issue?

If I click in a footprint and drag, it drags the footprint.
If I click in a footprint’s pad and drag, it drags the footprint.
Same is true whether footprint/pad was previously selected or not.
Same is true with trackpad 3-finger drag.

Is one of these wrong, or are you seeing different behaviour?

Thanks,
Jeff.

> On 16 Jan 2018, at 12:24, Maciej Sumiński  wrote:
> 
> Hi Jeff,
> 
> I apologize for long delay. I have just reviewed and tested your patch
> and the changes look fine, but there is one thing that needs to be
> addressed before they can be accepted. Dragging a footprint with mouse
> cursor does not work anymore, cursor simply gets stuck at the drag
> origin position. Once it is fixed, I am willing to push your patch.
> 
> Please also consider that attached patch that fixes the code formatting.
> 
> Cheers,
> Orson
> 
> On 01/09/2018 06:38 PM, Jeff Young wrote:
>> The heat gets bumped up for multiple reports or when people click “this bug 
>> affects me too”.
>> 
>> Patch uploaded.
>> 
>> https://bugs.launchpad.net/kicad/+bug/1708869 
>> 
>> 
>> (The duplicate: https://bugs.launchpad.net/kicad/+bug/1503679 
>>  )
>> 
>> Cheers,
>> Jeff.
>> 
>>> On 9 Jan 2018, at 16:06, Wayne Stambaugh  wrote:
>>> 
>>> Hey Jeff,
>>> 
>>> I'm not sure what a heat of 22 even means?  I don't see any comments or
>>> suggestions in the bug report where lots of devs and/or users gave it a
>>> big thumbs up.  I'm talking about getting some input on the concept and
>>> testing on a patch from other devs and users.  I can't remember, did you
>>> supply a patch for this?  I don't see one on the bug report.  I need to
>>> review and test it at a minimum.
>>> 
>>> Cheers,
>>> 
>>> Wayne
>>> 
>>> On 1/9/2018 10:39 AM, Jeff Young wrote:
 Hi Wayne,
 
 Well, the bug has a heat of 22, so it’s definitely not just me. ;)
 
 My change doesn’t alter the dragging or selecting behaviour.  All it
 does is keep an extraneous “Clarify Selection” menu from coming up
 (which I think all our users would consider a bug).  What we currently
 do in these situations is akin to popping up a “Clarify Selection” menu
 with one item in it every time you click on a unambiguous item.
 
 In the corner case all my change does is prevent us from asking: do you
 want to drag the corner of a and b, or do you want to drag the corner of
 b and a, when in fact the two have identical semantics).  Everything
 after the menu (no matter which item you click) is exactly the same.
 
 Same with U and I.  My change has no effect on what is selected, it just
 keeps us from asking: do you want to select the trivial connection
 containing a or do you want to select the trivial connection containing
 b, when in fact both a and b are on the /same/ trivial connection.
 Again, everything after the menu (no matter which item you click) is
 exactly the same.
 
 Cheers,
 Jeff.
 
> On 9 Jan 2018, at 15:27, Wayne Stambaugh  >> wrote:
> 
> Jeff,
> 
> Have actually confirmed that this is the desired behavior for this
> outside of you own objectives?  I'm not saying that this is or isn't a
> good idea but I personally don't drag trace corners around so I'm not
> sure what the appropriate behavior should be.  You should get comments
> from the dev list and users before you make a change like this.  As far
> as pushing this to the dev repo, if it's not too invasive I will
> consider it.  If it is a large change set, I would prefer that we hold
> off until after the stable release.
> 
> Thanks,
> 
> Wayne
> 
> On 1/8/2018 5:49 AM, Jeff Young wrote:
>> Wayne, if I could get you to don that old project manager’s hat one
>> more time:
>> 
>> If we’re still weeks out from declaring an RC, I wanted to make one
>> more plug for getting rid of the Clarify Selection dialog when
>> dragging corners or using ‘U’ or ‘I’ over a corner[1].
>> 
>> While it’s marked Wishlist, it seriously impacts productivity when
>> editing tracks, and I think most users would consider it a bug
>> (particularly in the corner case when dragging the corner is clearly
>> moving both the tracks listed in the Clarify Selection menu).
>> 
>> I’ve been running the patch for about a week now with no issues.
>> 
>> Cheers,
>> Jeff.
>> 
>> [1] https://bugs.launchpad.net/kicad/+bug/1708869
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 

Re: [Kicad-developers] One more quick plug for reducing "Clarify Selection" dialogs

[Maciej Sumiński]

Hi Jeff,

I apologize for long delay. I have just reviewed and tested your patch
and the changes look fine, but there is one thing that needs to be
addressed before they can be accepted. Dragging a footprint with mouse
cursor does not work anymore, cursor simply gets stuck at the drag
origin position. Once it is fixed, I am willing to push your patch.

Please also consider that attached patch that fixes the code formatting.

Cheers,
Orson

On 01/09/2018 06:38 PM, Jeff Young wrote:
> The heat gets bumped up for multiple reports or when people click “this bug 
> affects me too”.
> 
> Patch uploaded.
> 
> https://bugs.launchpad.net/kicad/+bug/1708869 
> 
> 
> (The duplicate: https://bugs.launchpad.net/kicad/+bug/1503679 
>  )
> 
> Cheers,
> Jeff.
> 
>> On 9 Jan 2018, at 16:06, Wayne Stambaugh  wrote:
>>
>> Hey Jeff,
>>
>> I'm not sure what a heat of 22 even means?  I don't see any comments or
>> suggestions in the bug report where lots of devs and/or users gave it a
>> big thumbs up.  I'm talking about getting some input on the concept and
>> testing on a patch from other devs and users.  I can't remember, did you
>> supply a patch for this?  I don't see one on the bug report.  I need to
>> review and test it at a minimum.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 1/9/2018 10:39 AM, Jeff Young wrote:
>>> Hi Wayne,
>>>
>>> Well, the bug has a heat of 22, so it’s definitely not just me. ;)
>>>
>>> My change doesn’t alter the dragging or selecting behaviour.  All it
>>> does is keep an extraneous “Clarify Selection” menu from coming up
>>> (which I think all our users would consider a bug).  What we currently
>>> do in these situations is akin to popping up a “Clarify Selection” menu
>>> with one item in it every time you click on a unambiguous item.
>>>
>>> In the corner case all my change does is prevent us from asking: do you
>>> want to drag the corner of a and b, or do you want to drag the corner of
>>> b and a, when in fact the two have identical semantics).  Everything
>>> after the menu (no matter which item you click) is exactly the same.
>>>
>>> Same with U and I.  My change has no effect on what is selected, it just
>>> keeps us from asking: do you want to select the trivial connection
>>> containing a or do you want to select the trivial connection containing
>>> b, when in fact both a and b are on the /same/ trivial connection.
>>>  Again, everything after the menu (no matter which item you click) is
>>> exactly the same.
>>>
>>> Cheers,
>>> Jeff.
>>>
 On 9 Jan 2018, at 15:27, Wayne Stambaugh >> wrote:

 Jeff,

 Have actually confirmed that this is the desired behavior for this
 outside of you own objectives?  I'm not saying that this is or isn't a
 good idea but I personally don't drag trace corners around so I'm not
 sure what the appropriate behavior should be.  You should get comments
 from the dev list and users before you make a change like this.  As far
 as pushing this to the dev repo, if it's not too invasive I will
 consider it.  If it is a large change set, I would prefer that we hold
 off until after the stable release.

 Thanks,

 Wayne

 On 1/8/2018 5:49 AM, Jeff Young wrote:
> Wayne, if I could get you to don that old project manager’s hat one
> more time:
>
> If we’re still weeks out from declaring an RC, I wanted to make one
> more plug for getting rid of the Clarify Selection dialog when
> dragging corners or using ‘U’ or ‘I’ over a corner[1].
>
> While it’s marked Wishlist, it seriously impacts productivity when
> editing tracks, and I think most users would consider it a bug
> (particularly in the corner case when dragging the corner is clearly
> moving both the tracks listed in the Clarify Selection menu).
>
> I’ve been running the patch for about a week now with no issues.
>
> Cheers,
> Jeff.
>
> [1] https://bugs.launchpad.net/kicad/+bug/1708869
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
>  >
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
>

 ___
 Mailing list: https://launchpad.net/~kicad-developers 
 
 Post to : kicad-developers@lists.launchpad.net 

Re: [Kicad-developers] Libedit and Modedit Icons

[kristoffer Ödmark]

For me it feels more natural with thins flowing from left to right, so 
that means moving the import arrow to the left side, and also making it 
flowing into the document.


Export also flow from left to right, so making it flowing from inside 
the document to out on the right side. These are good goals.


I also find that when i load something, the closest analogy is to pick 
it up, and saving is putting it down. Note that these do however not 
flow into or out of any document. Unless you save it somewhere else, in 
that case it would flow out (export) and down (save) a combination of 
exportin and putting it down.


The current icons makes this much more clear and is much much more 
intuitive, but the two things you listed are important. I read someone 
claiming that the new icons wasnt well designed, I disagree. Sure there 
may be some design policy not being followed, I wouldnt know. But at 
least the icons now provide recognition and usability with less 
complexity. Which makes my work faster, since I dont have to read the 
tooltip every time. This is what is most important for me.


Thank you Oliver for taking your time and moving this forward.


On 2018-01-16 12:55, Jeff Young wrote:
I think the in/out axis is more important than the left/right axis. 
 So your suggestion would be an improvement.


On 16 Jan 2018, at 11:40, Oliver Walters 
> wrote:


I think you are all correct. During my revamp of the icons I tried to 
achieve two things:


1. Differentiate between import and export based on arrow direction 
(generally import arrows are right to left, and export are left to right)
2. Place import icons on the left, and export on the right (following 
the "flow" outlined in 1)


However this means that both arrows are effectively flowing "out of" 
the document.


I think that if the import icons are moved to the right hand side, 
then they will then look like they are flowing "into" the document.


Thoughts?

On Tue, Jan 16, 2018 at 9:10 PM, Jeff Young > wrote:


FWIW, I also agree that the current import arrow is backwards.

> On 16 Jan 2018, at 07:11, Marco Ciampa > wrote:
>
> Hi Oliver, your thoughts?
>
> On Mon, Jan 15, 2018 at 09:09:48AM +0100, jp charras wrote:
>> Le 15/01/2018 à 08:51, Marco Ciampa a écrit :
>>> Hi Oliver,
>>> about the bikeshedding thing I am not even a developer and I
have the
>>> audacity to say my thoughts about the icons!!!
>>>
>>> Follows my 0.002 euro cents
>>>
>>> My very humble opinion is that the import icon is not that
clear and can
>>> be improved alot in this way: just change the direction and
position of
>>> the arrow, the colour could stay as it is, it doesn't matter.
>>>
>>> I mean that the export icon is (almost) ok since it represent
what I
>>> expect in an "export" icon: the "out" direction is clear:
just describe
>>> an arrow that points _out_ of a document.
>>>
>>> Similarly the import icon should represent the "in"
direction: and arrow
>>> that point _into_ a document, not another arrow pointing out
of the same
>>> document but with a different color...
>>
>> I fully agree...
>>
>>>
>>> I mean (ascii art: see it with a monospaced font):
>>>
>>> Export:
>>>
>>> ||
>>> |        | |\
>>> |      |---| \
>>> |      |      \
>>> |      |      /
>>> |      |---| /
>>> |        | |/
>>> ||
>>>
>>> Import:
>>>
>>>  ||
>>>  | |\     |
>>> |---| \    |
>>> |      \   |
>>> |      /   |
>>> |---| /    |
>>>  | |/     |
>>>  ||
>>>
>>>
>>> I think this is much clearer...
>>>
>>> --
>>>
>>>
>>> Marco Ciampa
>>
>>
>> --
>> Jean-Pierre CHARRAS
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers

>> Post to     : kicad-developers@lists.launchpad.net

>> Unsubscribe : https://launchpad.net/~kicad-developers

>> More help   : https://help.launchpad.net/ListHelp

>
> --
>
>
> Marco Ciampa
>
> I know a joke about UDP, but you might not get it.
>
> 
>
> GNU/Linux User #78271
> FSFE fellow #364
>
> 
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers

> Post to     : kicad-developers@lists.launchpad.net

Re: [Kicad-developers] Libedit and Modedit Icons

[Jeff Young]

I think the in/out axis is more important than the left/right axis.  So your 
suggestion would be an improvement.

> On 16 Jan 2018, at 11:40, Oliver Walters  
> wrote:
> 
> I think you are all correct. During my revamp of the icons I tried to achieve 
> two things:
> 
> 1. Differentiate between import and export based on arrow direction 
> (generally import arrows are right to left, and export are left to right)
> 2. Place import icons on the left, and export on the right (following the 
> "flow" outlined in 1)
> 
> However this means that both arrows are effectively flowing "out of" the 
> document.
> 
> I think that if the import icons are moved to the right hand side, then they 
> will then look like they are flowing "into" the document.
> 
> Thoughts?
> 
> On Tue, Jan 16, 2018 at 9:10 PM, Jeff Young  > wrote:
> FWIW, I also agree that the current import arrow is backwards.
> 
> > On 16 Jan 2018, at 07:11, Marco Ciampa  > > wrote:
> >
> > Hi Oliver, your thoughts?
> >
> > On Mon, Jan 15, 2018 at 09:09:48AM +0100, jp charras wrote:
> >> Le 15/01/2018 à 08:51, Marco Ciampa a écrit :
> >>> Hi Oliver,
> >>> about the bikeshedding thing I am not even a developer and I have the
> >>> audacity to say my thoughts about the icons!!!
> >>>
> >>> Follows my 0.002 euro cents
> >>>
> >>> My very humble opinion is that the import icon is not that clear and can
> >>> be improved alot in this way: just change the direction and position of
> >>> the arrow, the colour could stay as it is, it doesn't matter.
> >>>
> >>> I mean that the export icon is (almost) ok since it represent what I
> >>> expect in an "export" icon: the "out" direction is clear: just describe
> >>> an arrow that points _out_ of a document.
> >>>
> >>> Similarly the import icon should represent the "in" direction: and arrow
> >>> that point _into_ a document, not another arrow pointing out of the same
> >>> document but with a different color...
> >>
> >> I fully agree...
> >>
> >>>
> >>> I mean (ascii art: see it with a monospaced font):
> >>>
> >>> Export:
> >>>
> >>> ||
> >>> || |\
> >>> |  |---| \
> >>> |  |  \
> >>> |  |  /
> >>> |  |---| /
> >>> || |/
> >>> ||
> >>>
> >>> Import:
> >>>
> >>>  ||
> >>>  | |\ |
> >>> |---| \|
> >>> |  \   |
> >>> |  /   |
> >>> |---| /|
> >>>  | |/ |
> >>>  ||
> >>>
> >>>
> >>> I think this is much clearer...
> >>>
> >>> --
> >>>
> >>>
> >>> Marco Ciampa
> >>
> >>
> >> --
> >> Jean-Pierre CHARRAS
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers 
> >> 
> >> Post to : kicad-developers@lists.launchpad.net 
> >> 
> >> Unsubscribe : https://launchpad.net/~kicad-developers 
> >> 
> >> More help   : https://help.launchpad.net/ListHelp 
> >> 
> >
> > --
> >
> >
> > Marco Ciampa
> >
> > I know a joke about UDP, but you might not get it.
> >
> > 
> >
> > GNU/Linux User #78271
> > FSFE fellow #364
> >
> > 
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers 
> > 
> > Post to : kicad-developers@lists.launchpad.net 
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers 
> > 
> > More help   : https://help.launchpad.net/ListHelp 
> > 
> 
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Introduction

[Jeff Young]

Babar’s intro made me realise I had never introduced myself to the developers 
list.

I’m a software engineer/architect by trade, although I did digital hardware 
design back in the 1980’s, and worked on the particle accelerator at BNL.  

I’ve done a considerable amount of UI design, including FullPaint, FullWrite 
Professional, FrameMaker, Adobe Designer, and contributions to Photoshop, 
InDesign and CQ.  

However, most of my work was internal, including FrameMaker’s formatter, PDF 
architecture, and CQ’s commerce integration architecture.  I have 21 software 
patents.

I’m now retired, and do analog audio design as a hobby.

Cheers,
Jeff.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Libedit and Modedit Icons

[Oliver Walters]

I think you are all correct. During my revamp of the icons I tried to
achieve two things:

1. Differentiate between import and export based on arrow direction
(generally import arrows are right to left, and export are left to right)
2. Place import icons on the left, and export on the right (following the
"flow" outlined in 1)

However this means that both arrows are effectively flowing "out of" the
document.

I think that if the import icons are moved to the right hand side, then
they will then look like they are flowing "into" the document.

Thoughts?

On Tue, Jan 16, 2018 at 9:10 PM, Jeff Young  wrote:

> FWIW, I also agree that the current import arrow is backwards.
>
> > On 16 Jan 2018, at 07:11, Marco Ciampa  wrote:
> >
> > Hi Oliver, your thoughts?
> >
> > On Mon, Jan 15, 2018 at 09:09:48AM +0100, jp charras wrote:
> >> Le 15/01/2018 à 08:51, Marco Ciampa a écrit :
> >>> Hi Oliver,
> >>> about the bikeshedding thing I am not even a developer and I have the
> >>> audacity to say my thoughts about the icons!!!
> >>>
> >>> Follows my 0.002 euro cents
> >>>
> >>> My very humble opinion is that the import icon is not that clear and
> can
> >>> be improved alot in this way: just change the direction and position of
> >>> the arrow, the colour could stay as it is, it doesn't matter.
> >>>
> >>> I mean that the export icon is (almost) ok since it represent what I
> >>> expect in an "export" icon: the "out" direction is clear: just describe
> >>> an arrow that points _out_ of a document.
> >>>
> >>> Similarly the import icon should represent the "in" direction: and
> arrow
> >>> that point _into_ a document, not another arrow pointing out of the
> same
> >>> document but with a different color...
> >>
> >> I fully agree...
> >>
> >>>
> >>> I mean (ascii art: see it with a monospaced font):
> >>>
> >>> Export:
> >>>
> >>> ||
> >>> || |\
> >>> |  |---| \
> >>> |  |  \
> >>> |  |  /
> >>> |  |---| /
> >>> || |/
> >>> ||
> >>>
> >>> Import:
> >>>
> >>>  ||
> >>>  | |\ |
> >>> |---| \|
> >>> |  \   |
> >>> |  /   |
> >>> |---| /|
> >>>  | |/ |
> >>>  ||
> >>>
> >>>
> >>> I think this is much clearer...
> >>>
> >>> --
> >>>
> >>>
> >>> Marco Ciampa
> >>
> >>
> >> --
> >> Jean-Pierre CHARRAS
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >
> > --
> >
> >
> > Marco Ciampa
> >
> > I know a joke about UDP, but you might not get it.
> >
> > 
> >
> > GNU/Linux User #78271
> > FSFE fellow #364
> >
> > 
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Libedit and Modedit Icons

[Jörg Hermann]

A majority of participants on the ML found the new icons a step forward and we 
have a commit.
We won’t ever reach a point where we can satisfy everybody, so we must live 
with the democratic majority.
All concerns and inputs raised after the commit are sound, valid and wise and 
should be considered for V6.

Again I ask, no beg, everybody to get V5 out of the door and not be distracted 
by minuscule details like icon design.

Don’t get me wrong: UI design is IMPORTANT, icon design is ART and KNOWLEDGE, 
but in the bigger picture of the pile of work that represents the Kicad project 
as a whole, it is a rather minor feature. I feel this because Kicad is used by 
technical driven people, who usually don't care that much about aesthetics, as 
long as the knob gets the job done.

My 2 ct.
Jörg


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Libedit and Modedit Icons

[Fabrizio Tappero]

The attached image shows a comparison between a poorly designed icons
and a well
designed icon .

thank you
Fabrizio



On Sat, Jan 13, 2018 at 2:19 AM, Nick Østergaard  wrote:

> IMHO the new icon collection looks awful. They are not pixel aligned and
> renders quite fuzzy in many details.
>
> http://storage4.static.itmages.com/i/18/0113/h_
> 1515804843_8735496_c1a004f249.png
>
> Looking at the the new ones are part of the red circles and renders fuzzy,
> while the green one looks more like the old one and renders more sharply.
>
> Some of the simplification made are an improvement, but the icons are not
> ready.
>
> In addition to that a white boarder has been added to overlay icons even
> when there is already a black border. I think only one of those should be
> there, and probably not a black and white. Usually a darker color of the
> same color as the overlay icon makes a better apperance when we are talking
> these sizes of icons. But this is really dependent on the icon composition.
> Some of the old icons with arrows also had this white boarder, but not the
> black one. When removing the white boarder it looked better.
>
> I don't like that so many icons are change without specific justification.
> or example the reload.svg was changed. The direction of the arrows changed
> and the color. Why? See attached image.
> The export STEP icon, you can't even read the P in STP.
>
> 2018-01-12 20:11 GMT+01:00 Wayne Stambaugh :
>
>> Oliver,
>>
>> The new icons look great.  They are far more coherent than what we had.
>> I merged your patch into the development branch.  Thank you for
>> contribution to KiCad.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 01/11/2018 02:54 AM, Oliver Walters wrote:
>> > Wayne,
>> >
>> > I have taken further suggestions and final icon set is shown below:
>> >
>> > Inline image 1
>> >
>> > The attached patch incorporates all of the icon changes thus far
>> > implemented.
>> >
>> > Thanks,
>> > Oliver
>> >
>> > On Thu, Jan 11, 2018 at 1:58 AM, Wayne Stambaugh > > > wrote:
>> >
>> > I see scope creep happening here.  I thought the original goal was
>> to
>> > make some minor tweaks to our existing icons not wholesale
>> replacement
>> > of the them.  I don't like the camera either.  I'm not a big fan of
>> the
>> > calculator icon.  Both of these icons looks completely out of place
>> with
>> > our other icons.  Please keep the scope of these changes in check.
>> If
>> > we want to discuss an entirely new icon theme for v6, that's fine
>> at the
>> > appropriate time but not for v5.
>> >
>> > On 1/10/2018 9:42 AM, Jeff Young wrote:
>> > > Splendid!
>> > >
>> > > Although I agree with Kristoffer that the new bitmap2component
>> icon
>> > > isn’t much help.  Import/Export is the one area where we’ve kept
>> the
>> > > arrows (which I think is fine).  Given that, the pixelated “a”
>> with an
>> > > import arrow would be perfect.
>> > >
>> > > FWIW, this is one area where I disagree with Nick.  I did user
>> interface
>> > > design and software architecture for Adobe for 25 years and in my
>> > > professional opinion, these icons are a HUGE improvement.
>> > >
>> > > Cheers,
>> > > Jeff
>> > >
>> > >
>> > >> On 10 Jan 2018, at 14:28, Oliver Walters
>> > >> > mail.com>
>> > >> > > >> wrote:
>> > >>
>> > >> Also, would it be too much to ask for getting the arrows, the
>> > >> diskette and the folder in the repo with the patch,
>> basically if
>> > >> someone wants to create future icons. They could use the same
>> > >> arrows for any kind of export, import, save, inspect or view.
>> > >>
>> > >>
>> > >> I have created a set of "common icons" for exactly this purpose
>> :)
>> > >>
>> > >>
>> > >> On Thu, Jan 11, 2018 at 1:27 AM, Kristoffer Ödmark
>> > >> > > 
>> > > > >>
>> > >> wrote:
>> > >>
>> > >> Wow, really nice! Although, the icon for the bitmap2component
>> > >> basically looks like a screenshot symbol to me, or something
>> > >> related to a webcam.
>> > >>
>> > >> The old one isnt as polished, but I think it fits better.
>> > >>
>> > >> Also, would it be too much to ask for getting the arrows, the
>> > >> diskette and the folder in the repo with the patch,
>> basically if
>> > >> someone wants to create future icons. They could use the same
>> > >> arrows for any kind of export, import, save, inspect or view.

Re: [Kicad-developers] Libedit and Modedit Icons

[Fabrizio Tappero]

Hi,
I do not mean to offend anybody but, for years, there have been people
working very hard on the look of KiCad UI (see credits for details).

I have designed, and mediated with, the looks of KiCad for several years
and I am afraid the icons that have been submitted are not a step forward.
When it is about icons, everybody has an opinion and, in general, that is a
good thing.

Kicad Icons are 26pix for 26pix, if you want to adventure in designing an
icon for KiCad I suggest to open Inkscape with a 26X26 preview and try to
put stuff in it and see how it looks. Additionally, generally speaking,
colors cannot be too poppy and edges cannot be too sharp. In 2018 it is not
recommendable to write things in a 26pX26p icon nor overlay one image on
top of an other. Edges should be highlighter with an additional negative
edge. All this is just common sense (not even knowledge) in the practice of
designing icons.

Not to offend anybody but to an mildly trained eye, all the icons that you
submitted are not even close to the quality of what, for instance,
Konsantin has posted few mails up.

An other thing is documentation, Kicad looks cannot be changed in one go
but changes must happen slowly so that documentation does not stay out of
sync.

There are many icons that I know are not so good but I also know that now
there are really a lot of icons that are not so good.

My humble opinion, but it is just my humble opinion is to reverse all this
icon changes and if there is anybody interested in adventuring into icon
design and submit new icons, please go ahead and submit these icons to
myself and/or Konstantin so that we review them. Once again, this is just
my opinion.

I know that all these icons you submitted in the last 7 days seem better
and pop out more and are more meaningful to you. I think they are not.

I hope I have not offended anybody with the rant.


Cheers
Fabrizio










On Fri, Jan 12, 2018 at 6:46 PM, Michael Kavanagh <
mich...@michaelkavanagh.me> wrote:

> Can I suggest after v5 UI/graphic design is split off into a separate
> group with a suitably qualified person in charge (e.g. like the lib/docs
> maintainers)? With a core team and a UI policy it might make for a more
> cohesive look and feel rather than several people having a crack at
> different bits in different applications.
>
> Just a thought.
>
> On 12 January 2018 at 12:46, Константин Барановский <
> baranovskiykonstan...@gmail.com> wrote:
>
>> Forgot to attach the source of bitmap2component icon.
>>
>> 2018-01-12 14:39 GMT+02:00 Jeff Young :
>>
>>> Agreed.  Your bitmap2component idea is excellent.
>>>
>>> > On 12 Jan 2018, at 12:37, jp charras  wrote:
>>> >
>>> > Le 12/01/2018 à 13:27, Константин Барановский a écrit :
>>> >> Thanks for your answers. What are you think about this icon for
>>> bitmap2component?
>>> >
>>> > I do like the pcb calculator and the bitmap2component icons.
>>> >
>>> >>
>>> >> 2018-01-12 13:00 GMT+02:00 Simon Wells > swel...@gmail.com>>:
>>> >>
>>> >>I agree with Jeff, Not a fan of the pcbnew/modedit/gerbview icons,
>>> I don’t mind the eeschema
>>> >>icon, but also not a fan of the bmp2cmp icon, the only way i can
>>> see bmp2cmp being better would
>>> >>be a (well known) bitmap looking square with an arrow pointing to
>>> a footprint and/or symbol
>>> >>
>>> >>Simon
>>> >>
>>> >>
>>> >>>On 12/01/2018, at 11:47 PM, Jeff Young > j...@rokeby.ie>> wrote:
>>> >>>
>>> >>>I like the more subdued colours in Oliver’s, although I do like
>>> your calculator icon (perhaps
>>> >>>with Oliver’s pcb colouring in the background).
>>> >>>
>>> >>>Cheers,
>>> >>>Jeff.
>>> >>>
>>> >>>
>>> On 12 Jan 2018, at 10:22, Константин Барановский <
>>> baranovskiykonstan...@gmail.com
>>> > wrote:
>>> 
>>> Hi Everybody!
>>> As you know (or not) I'm work on new icons for KiCad for a long
>>> time:
>>> https://code.launchpad.net/~baranovskiykonstantin/kicad/+git
>>> /kicad/+ref/new_icons_rebased
>>> >> git/kicad/+ref/new_icons_rebased>
>>> 
>>> And inspired by changes in app icons I made my variant.
>>> Please, leave feedback.
>>> 
>>> 2018-01-12 5:28 GMT+02:00 Andrey Kuznetsov >> >:
>>> 
>>> Awesome, thanks!
>>> 
>>> Looks good.
>>> 
>>> On Thu, Jan 11, 2018 at 7:27 PM Oliver Walters <
>>> oliver.henry.walt...@gmail.com
>>> > wrote:
>>> 
>>> Andrey,
>>> 
>>> Here's all I can provide currently (at work!)
>>> 
>>> 
>>> 
>>> I have sent the entire patch to Wayne and JP privately
>>> so the merging is now in their
>>>    

Re: [Kicad-developers] Libedit and Modedit Icons

[Jeff Young]

FWIW, I also agree that the current import arrow is backwards.

> On 16 Jan 2018, at 07:11, Marco Ciampa  wrote:
> 
> Hi Oliver, your thoughts?
> 
> On Mon, Jan 15, 2018 at 09:09:48AM +0100, jp charras wrote:
>> Le 15/01/2018 à 08:51, Marco Ciampa a écrit :
>>> Hi Oliver,
>>> about the bikeshedding thing I am not even a developer and I have the
>>> audacity to say my thoughts about the icons!!!
>>> 
>>> Follows my 0.002 euro cents
>>> 
>>> My very humble opinion is that the import icon is not that clear and can
>>> be improved alot in this way: just change the direction and position of
>>> the arrow, the colour could stay as it is, it doesn't matter.
>>> 
>>> I mean that the export icon is (almost) ok since it represent what I
>>> expect in an "export" icon: the "out" direction is clear: just describe
>>> an arrow that points _out_ of a document.
>>> 
>>> Similarly the import icon should represent the "in" direction: and arrow
>>> that point _into_ a document, not another arrow pointing out of the same
>>> document but with a different color...
>> 
>> I fully agree...
>> 
>>> 
>>> I mean (ascii art: see it with a monospaced font):
>>> 
>>> Export:
>>> 
>>> ||
>>> || |\
>>> |  |---| \
>>> |  |  \
>>> |  |  /
>>> |  |---| /
>>> || |/
>>> ||
>>> 
>>> Import:
>>> 
>>>  ||
>>>  | |\ |
>>> |---| \|
>>> |  \   |
>>> |  /   |
>>> |---| /|
>>>  | |/ |
>>>  ||
>>> 
>>> 
>>> I think this is much clearer...
>>> 
>>> --
>>> 
>>> 
>>> Marco Ciampa
>> 
>> 
>> -- 
>> Jean-Pierre CHARRAS
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> -- 
> 
> 
> Marco Ciampa
> 
> I know a joke about UDP, but you might not get it.
> 
> 
> 
> GNU/Linux User #78271
> FSFE fellow #364
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Implement primitive icon scaling for high DPI

[Fabrizio Tappero]

Hi Thomas,
thanks for the pics. All icons seem out of focus to me. I however
understand that if you need bigger icons you need bigger incons

 It might make sense to chose a 200% magnification only. In this case
sharpness is preserved.

I shall also say that if your monitor has a higher enough DPI sharpness due
to icon magnification should not be visible.

Cheers
Fabrizio

On Mon, Jan 15, 2018 at 4:51 PM, Thomas Figueroa 
wrote:

> I’ve attached scaling at 150%, 225%, and 250% (W10, 4k screen with DPI
> around 280 like Chris). The icons all look fine at all of these scalings.
> Before Chris’s patch, I manually created bitmaps from the SVGs at higher
> resolution (2.25x) and they not only scaled very well, they looked very
> nice. So based on these two experiences, the icons are very capable of
> scaling appropriately.
>
>
>
>
> --
> *From:* Kicad-developers  hotmail@lists.launchpad.net> on behalf of Fabrizio Tappero <
> fabrizio.tapp...@gmail.com>
> *Sent:* Monday, January 15, 2018 3:52:32 AM
> *To:* Chris Pavlina
> *Cc:* KiCad Developers
> *Subject:* Re: [Kicad-developers] [PATCH] Implement primitive icon
> scaling for high DPI
>
> Hi,
> Can anybody with a high DPI monitor post some pics at different scaling
> setting please.
>
> An enormous effort was put in making this icons look good in they actual
> fixed resolution. I am curious how a >250DPI monitor can display icons well
> regardless of this effort.
>
> Cheers
> Fabrizio
>
>
> On Thu, Jan 11, 2018 at 6:06 PM, Chris Pavlina 
> wrote:
>
>> Yup. For reference my own display is around 280 DPI.
>>
>> On Thu, Jan 11, 2018 at 10:35:15AM +, Jeff Young wrote:
>> > 2560x1440 @ 24” is only 122 DPI.
>> >
>> > Apple’s Retina displays are 220 or 227, and the Surface Book in the
>> original bug report is 267 DPI.
>> >
>> > > On 11 Jan 2018, at 09:54, kristoffer Ödmark <
>> kristofferodmar...@gmail.com> wrote:
>> > >
>> > > I have 2560x1440, 24" screens, I think those qualifies as high DPI?
>> > >
>> > > The slider value is at 100, and the diag value is at 23. The icons
>> are ish 5mm large.
>> > >
>> > > But i guess that is uneccesary since It seems the scaling works as
>> intended, I was just doing it wrong, so no errors, sorry :)
>> > >
>> > > The scaling seems correct as well, 100 = 5mm, 150 = 7.5, 200 = 11,
>> measured with a tape measure, so variance in size is expected.
>> > >
>> > >
>> > > Application: kicad
>> > > Version: (2018-01-11 revision a5b3d8e57)-master, debug build
>> > > Libraries:
>> > > wxWidgets 3.0.3
>> > > libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4
>> libpsl/0.19.1 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0
>> > > Platform: Linux 4.9.74-2-MANJARO x86_64, 64 bit, Little endian, wxGTK
>> > > Build Info:
>> > > wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+
>> 2.24
>> > > Boost: 1.65.1
>> > > Curl: 7.57.0
>> > > Compiler: GCC 7.2.1 with C++ ABI 1011
>> > >
>> > > Build settings:
>> > > USE_WX_GRAPHICS_CONTEXT=OFF
>> > > USE_WX_OVERLAY=OFF
>> > > KICAD_SCRIPTING=ON
>> > > KICAD_SCRIPTING_MODULES=ON
>> > > KICAD_SCRIPTING_WXPYTHON=ON
>> > > KICAD_SCRIPTING_ACTION_MENU=OFF
>> > > BUILD_GITHUB_PLUGIN=ON
>> > > KICAD_USE_OCE=ON
>> > > KICAD_SPICE=ON
>> > >
>> > >
>> > > On 2018-01-11 01:13, Chris Pavlina wrote:
>> > >> If your system DPI is already within a certain range it won't do
>> > >> anything. Are you using a high DPI display? If it's not scaled
>> > >> correctly, would you please share with me the diagnostic number
>> reported
>> > >> by the scale slider in eeschema prefs as well as a rough indication
>> of
>> > >> the icons' physical size? Thanks.
>> > >>
>> > >> On Wed, Jan 10, 2018 at 11:16:46PM +, kristoffer Ödmark wrote:
>> > >>> Tried the patch, didnt really notice anything different though, I
>> guess you
>> > >>> need to add some custom scaling for this to take effect?
>> > >>>
>> > >>>
>> > >>> On 2018-01-10 22:23, Chris Pavlina wrote:
>> >  Sure, assign me to it. I should have time to work on it tonight or
>> >  tomorrow.
>> > 
>> >  On Wed, Jan 10, 2018 at 04:20:21PM -0500, Wayne Stambaugh wrote:
>> > > FYI, the edit footprint dialog in Pcbnew is not sized properly
>> (at least
>> > > on windows) which I'm pretty sure is related to your recent HiDPI
>> work.
>> > > Do you want me to file a bug report for it?
>> > >
>> > > On 1/10/2018 2:01 PM, Chris Pavlina wrote:
>> > >> By the way, I'm going to go ahead and push this tonight-ish if
>> nobody
>> > >> objects. I know it's on the big side, but due to my limited
>> number of
>> > >> machines to test on I really want time for user feedback. I'll
>> be around
>> > >> to put out any fires.
>> > >>
>> > >> On Wed, Jan 10, 2018 at 11:07:49AM -0700, Chris Pavlina wrote:
>> > >>> Rebased patch 

Re: [Kicad-developers] KiCad And Quces

[Maciej Sumiński]

On 01/16/2018 09:38 AM, Christian Gagneraud wrote:
> CC Qucs's maintainer, please feel free to extend.
> 
> On 16 January 2018 at 21:14, Babar Malik  wrote:
>> I am much more interested to integrate Kicad and Qucs,  and the first step
>> towards this would be to study the source code of Kicad from scratch. Can
>> you please help me regarding to this ? Please guide me from where I should
>> take first step?
>> your help will be highly appreciated.
> 
> Hi Babar, (Please keep mailing list(s) posted)
> 
> Integrating KiCAD and Qucs can be done at several levels.
> Both projects are written in C++, but one uses WxWidgets, while the
> other is using Qt (3, 4, but not 5).
> So maybe a possible approach would be to try to integrate qucsator
> (the core simulation engine) with KiCAD's GUI.
> That is: do not try to merge/join them at C++ level, but at process level.
> Please also note that Qucs has some friendly forks that attempts to
> consolidate alternative simulation engines (ngspice, xyce, gnucap,
> spice opus, ...)

I think you are right about the approach. It would be even more
convenient if one could interface qucs(ator) via a shared library, as we
currently do with ngspice. Obviously, calling qucs from command line is
likely to work as well, but probably would require some text processing
to make simulation results available to KiCad.

Interesting parts of KiCad source code to study:
https://github.com/KiCad/kicad-source-mirror/tree/master/eeschema/sim

Regards,
Orson

> See eg.: https://qucs-help.readthedocs.io/en/spice4qucs/BasSim.html
> 
> I have no authority in any of the aforementioned projects, but may I
> suggest to contact the developer mailing of each project.
> Have a look at each project git repo, and don't hesitate to ask
> question on respective mailing lists.
> 
> Some starting points:
> https://github.com/Qucs
> https://ra3xdh.github.io/
> https://github.com/KiCad
> https://savannah.gnu.org/git/?group=gnucap
> https://github.com/Qucs/gnucsator
> 
> As I said, if you want to integrate qucs and KiCAD, you might want to
> focus on using qucsator/gnucsator as simulation backend(s) in KiCAD
> 
> Don't feel overwhelmed, dive in and ask! ;)
> 
> What's your background? What are your skills and experience? It might
> be useful to present yourself so that community members can understand
> where you're coming from and how to help you to achieve your goals.
> 
> Chris
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Ensure DrawRectangle() stroke outline will always be visible

[Maciej Sumiński]

Hi Jon,

On 01/16/2018 05:09 AM, Jon Evans wrote:
> SELECTION_AREA::ViewDraw() doesn't set the line width.  I thought about
> fixing it by adding a call to set some kind of arbitrary width, but decided
> to do it a different way to be more generally applicable.  Despite my
> saying that, this is still more of a workaround than a real fix.

Many thanks for the patch. I added one more to fix another aspect of the
bug and pushed both changes to the master branch.

> Note that this is probably a topic that wants future thought after V5:
> There is currently no easy way to draw things in screen space rather than
> world space.  Maybe I will think about how to add an easy-to-use mechanism
> to the GAL to accomplish this.  Sometimes you really just want a line that
> is 1px wide ;-)

I agree. Some time ago Oliver has sent a patch to enable selecting line
width in screen units, but it would not work for items cached in the
video memory. Then I developed a new shader to fix this issue as well,
but I was still getting some visual artifacts. If you are interested,
work in progress code is in my launchpad repository [1].

Cheers,
Orson

1. https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+ref/gal_fixed_line

> Fixes: https://bugs.launchpad.net/kicad/+bug/1743242
> 
> -Jon
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad And Quces

[Christian Gagneraud]

On 16 January 2018 at 20:10, José Ignacio  wrote:
> In case you didn't get to try it yet, the development version of kicad
> already includes integration with a very good simulator, ngspice. That may
> already do everything you need.

Qucs is way more than (ng)spice, integrating the qucsator simulator
engine would benefits KiCAD.
This would allow to simulate PCB layout and open the door to
parameterised layout. AFAIK, one of the main Qucs focus is RF
simulation.

A tighter KiCAD/Qucs/GnuCAP would be highly beneficial to the community.

Maybe you're planning to talk about that at FOSDEM .

My 2 cents,
Chris

CC qucs-devel, but I doubt the cross-posting will work for everyone.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp