Re: [Kicad-developers] [PATCH] Fix some performance issues

[Wayne Stambaugh]

Camille,

I merged your patches into the kicad development branch.  Everything
seemed to work fine although I didn't notice much a performance gain.
That being said, thanks for fixing all of the places where we should
have been passing values by reference instead of push the entire object
on the stack.

Cheers,

Wayne

On 01/09/2018 03:41 PM, Camille 019 wrote:
> Hi,
> 
> 
> As promised, here are the patches up to date.
> 
> 
> Regards,
> 
> Camille
> 
> 
> *De :* Camille 
> *Envoyé :* mardi 26 septembre 2017 21:56:07
> *À :* Wayne Stambaugh
> *Cc :* kicad-developers@lists.launchpad.net
> *Objet :* Re: [Kicad-developers] [PATCH] Fix some performance issues
>  
> Hi,
> 
> Ok, I'll keep the patchset synchronized with the master branch, for
> future inclusion. When will the feature freeze take effect ?
> 
> I agree my patchset has no real impact on the performance. I mainly
> wanted to test clang-tidy on a consistent source code base. I also think
> that keeping automated checks empty of warning can help to improve the
> overall code quality.
> 
> Regards,
> 
> --
> Camille
> 
> 
> Le lun. 25 sept. 2017 à 16:21, Wayne Stambaugh  a
> écrit :
>> On 9/25/2017 4:07 AM, Maciej Sumiński wrote:
>>
>> Hi Camille, I think the attached patches are sensible, even though
>> I hope most compilers apply optimizations to avoid performance
>> penalties whenever possible. 
>>
>> I agree although I'm not sure about the compiler optimization. A quick
>> look at the patches and I'm not sure the performance gains will be
>> that noticeable. Most of the changes are in code that is called once
>> on demand in response to a user request as opposed to the drawing or
>> drc code where large numbers of calls happen frequently. That being
>> said, we really should be doing a better job of not passing entire
>> objects on the stack unless there is a good reason to do so.
>>
>> If the attached patches are autogenerated, then I would kindly ask
>> you to generate them when we reach the feature freeze stage. There
>> are a few branches that await to be merged and I am not sure
>> whether your patches would not create too many conflicts. During
>> the feature freeze we anticipate the code changes will not be as
>> disruptive as they are now. 
>>
>> I second this. There are quite a few outstanding patches that will
>> likely have enough conflicts so I would rather not pile more on top of
>> that.
>>
>> Regards, Orson On 09/23/2017 12:17 PM, Camille 019 wrote:
>>
>> Hi all, I recently play with clang-tidy on the KiCad source
>> code. Here is a set of 2 patch which fix the
>> 
>> unnecessary-copy-initialization
>> and
>> 
>> unnecessary-value-param
>> checks. I will run more performance checks in the future. The
>> next two: -
>> 
>> for-range-copy
>> -
>> 
>> type-promotion-in-math-fn
>> Best regards, -- Camille
>> ___ 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
> 
> 
> ___
> 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] Kicad from scratch: pcbnew: cannot use ~/ for home directory for KISYS3DMOD path?

[Mark Roszko]

https://github.com/KiCad/kicad-source-mirror/blob/610ff7485ff8659cec69568a734e059429aca151/common/pgm_base.cpp


You have to look at KISYSMOD and then KISYS3DMOD which appends to the path
made for KISYSMOD



On Tue, Jan 9, 2018 at 6:01 PM, Clemens Koller  wrote:

> Hi, Joerg!
>
> On 2018-01-09 18:49, Jörg Hermann wrote:
> > Is this behaviour somehow related to https://bugs.launchpad.net/
> kicad/+bug/1677545
>
> Maybe... remotely.
> KISYS3DMOD's default path, as well as it's handling, seems to be off a bit.
>
> My question is: Is Kicad supposed to work with ~/... in general or - for
> some very good reason - needs the expanded (absolute) /home//... ?
> If ~/... is an acceptable pathname, then there is a bug to hunt in the
> latest git.
>
> In other words: Where is the code where file + pathnames are abstracted to
> make it work across all platforms in this case?
> kicad.git/common/env_paths.cpp ?
>
> Regards,
>
> Clemens
>
>
> >
> >> On 9. Jan 2018, at 15:38, Nick Østergaard  oe.n...@gmail.com>> wrote:
> >>
> >> If you really want to start from scratch then you may also want to
> remove the ~/.cache/kicad  (or there about, I am not on linux right now).
> But it is not as important, it only contains the scene graph model cache.
> (Or what ever it is really called)
> >>
> >> 2018-01-09 14:55 GMT+01:00 Clemens Koller  c...@embeon.de>>:
> >>
> >> Hi!
> >>
> >> I am testing latest-git on Linux, collecting some UX issues when
> starting Kicad from scratch (*):
> >>
> >> On a new installation, I cannot execute 3D Shape Downloader out of
> the box. KISYS3DMOD points to ~/SW/share/kicad/modules/packages3d after
> installation to ~/SW/share/kicad/bin.
> >>
> >> This folder doesn't exist yet at this point, but could be created
> by Kicad.
> >> (The behaviour is still the same even when 
> >> ~/SW/share/kicad/modules/packages3d
> was created in advance.)
> >>
> >> The 3D Shape Downloader then tells me:
> >> "It's not possible to write in the selected directory. Please
> choose anothe one."
> >>
> >> When I press "Default 3D Path", I would expect that it resets the
> path to a default working one,
> >> but an message tells me that "KISYS3DMOD path not defined , or not
> existing".
> >>
> >> Anyway it's possible to hit the Next-> button just to realize than
> after an hour of downloading, the download is going to fail -> Duh!
> >> When I replace the ~/ with /home/admin/ everything seems to work.
> >> Is there a reason that the ~ cannot be used from within Kicad?
> >>
> >> Regards,
> >>
> >> Clemens
> >>
> >> (*) Kicad rebuilt from src and started from scratch after rm
> ~/.config/kicad
> >>
> >>
> >> ---
> >> Application: kicad
> >> Version: (2018-01-08  revision
> 0e9c8a423)-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.12-1-ARCH 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
> >
> >
> >
> > ___
> > 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
>



-- 
Mark
___
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]

>
> +1 to the Google icon overlays.
>

I'll have a look into that

On Wed, Jan 10, 2018 at 8:40 AM, Jeff Young  wrote:

> +1 to the Google icon overlays.
>
> On 9 Jan 2018, at 21:15, Jon Evans  wrote:
>
> Inspiration from Google's material design icons? (permissively-licensed) .
> These could be overlaid in the bottom right quarter maybe?
> 
> 
> 
>
> On Tue, Jan 9, 2018 at 4:09 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> Ok, that's good to hear. I will take another look at the Gerber icons and
>> otherwise see if anyone can suggest some simple clean replacements for the
>> arrows. If not, I'll push a patch.
>>
>> On Wed, Jan 10, 2018 at 8:05 AM, Wayne Stambaugh 
>> wrote:
>>
>>> One good thing about bitmaps is they are low risk (other than the
>>> complaining that will surely ensue) so we can merge them just about any
>>> time.  I don't want to wait too long so our doc images can be updated to
>>> reflect the changes so if we cannot come up with better alternatives to
>>> replace the arrows, I'm OK with leaving them as is and pushing it off
>>> until v6.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 1/9/2018 3:31 PM, Jeff Young wrote:
>>> > I think the changes are absolutely good in general, and I’d very much
>>> > like to see them get merged.  Not that I have any control over that. ;)
>>> >
>>> > As for the arrows, I’d still really like to see them go away.  The
>>> > colour isn’t the problem, it’s the arrows themselves. ANY of the
>>> > alternatives discussed (that don’t include arrows) would be better.
>>> >
>>> > Cheers,
>>> > Jeff.
>>> >
>>> >
>>> >> On 9 Jan 2018, at 20:13, Oliver Walters
>>> >> >> >> > wrote:
>>> >>
>>> >> The coloured arrows were already in place, all I have done is made
>>> >> them all the same "style". In fact, previously concepts like "save"
>>> >> and "load" were conveyed both with a downward pointing arrow, and the
>>> >> arrow colour was the only point of difference.
>>> >>
>>> >> I thought I had made an improvement on what was already existing. My
>>> >> intent was not to necessarily do a sweeping redesign.
>>> >>
>>> >> If this is now an additional requirement I can make these not arrows,
>>> >> but I'd like some direction on what to do instead. It will be hard to
>>> >> fit a more detailed icon.
>>> >>
>>> >> Other than this, what are your thoughts overall? Is it worth my time
>>> >> pursuing this further? Are these changes good in general and can you
>>> >> see them being merged?
>>> >>
>>> >> On 10 Jan 2018 04:44, "Wayne Stambaugh" >> >> > wrote:
>>> >>
>>> >> On 1/9/2018 12:05 PM, Rene Pöschl wrote:
>>> >> > On 09/01/18 16:50, Wayne Stambaugh wrote:
>>> >> >> I'm with Jose on the arrows.  If we are going to use them,
>>> >> please don't
>>> >> >> make the all different colors.  I don't see how a blue left
>>> >> arrow versus
>>> >> >> a magenta right arrow conveys any meaning to the user.
>>> >> >>
>>> >> >
>>> >> > I like the idea of coloring them differently. For me this will
>>> >> give an
>>> >> > additional way to distinguish the buttons. (Some of them have
>>> >> only the
>>> >> > direction of the arrow as a difference. Which is easily
>>> >> overlooked.) I
>>> >> > hope having different colors will make it easier for my brain to
>>> >> > remember which button does what. (I can't tell you how often i
>>> >> clicked
>>> >> > load symbol instead of update symbol while working on the
>>> >> reorganization
>>> >> > of the official lib.)
>>> >>
>>> >> What information does the different color arrow convey?  If you
>>> are
>>> >> using different colors for contrast, that is one thing but just
>>> making
>>> >> them different colors for informational purposes doesn't make any
>>> >> sense
>>> >> to me.  If you are trying convey information with different color
>>> >> buttons, what is the impact on users who are color blind.
>>> >>
>>> >> >
>>> >> > Maybe there is a better way to communicate differences but if
>>> >> buttons
>>> >> > look as similar as a lot of them currently do, adding
>>> >> differentiating
>>> >> > colors might help.
>>> >> >
>>> >> > ___
>>> >> > 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
>>> >> 
>>>

Re: [Kicad-developers] Kicad from scratch: pcbnew: cannot use ~/ for home directory for KISYS3DMOD path?

[Clemens Koller]

Hi, Joerg!

On 2018-01-09 18:49, Jörg Hermann wrote:
> Is this behaviour somehow related to 
> https://bugs.launchpad.net/kicad/+bug/1677545

Maybe... remotely.
KISYS3DMOD's default path, as well as it's handling, seems to be off a bit.

My question is: Is Kicad supposed to work with ~/... in general or - for some 
very good reason - needs the expanded (absolute) /home//... ?
If ~/... is an acceptable pathname, then there is a bug to hunt in the latest 
git.

In other words: Where is the code where file + pathnames are abstracted to make 
it work across all platforms in this case?
kicad.git/common/env_paths.cpp ?

Regards,

Clemens


> 
>> On 9. Jan 2018, at 15:38, Nick Østergaard > > wrote:
>>
>> If you really want to start from scratch then you may also want to remove 
>> the ~/.cache/kicad  (or there about, I am not on linux right now). But it is 
>> not as important, it only contains the scene graph model cache. (Or what 
>> ever it is really called)
>>
>> 2018-01-09 14:55 GMT+01:00 Clemens Koller > >:
>>
>> Hi!
>>
>> I am testing latest-git on Linux, collecting some UX issues when 
>> starting Kicad from scratch (*):
>>
>> On a new installation, I cannot execute 3D Shape Downloader out of the 
>> box. KISYS3DMOD points to ~/SW/share/kicad/modules/packages3d after 
>> installation to ~/SW/share/kicad/bin.
>>
>> This folder doesn't exist yet at this point, but could be created by 
>> Kicad.
>> (The behaviour is still the same even when 
>> ~/SW/share/kicad/modules/packages3d was created in advance.)
>>
>> The 3D Shape Downloader then tells me:
>> "It's not possible to write in the selected directory. Please choose 
>> anothe one."
>>
>> When I press "Default 3D Path", I would expect that it resets the path 
>> to a default working one,
>> but an message tells me that "KISYS3DMOD path not defined , or not 
>> existing".
>>
>> Anyway it's possible to hit the Next-> button just to realize than after 
>> an hour of downloading, the download is going to fail -> Duh!
>> When I replace the ~/ with /home/admin/ everything seems to work.
>> Is there a reason that the ~ cannot be used from within Kicad?
>>
>> Regards,
>>
>> Clemens
>>
>> (*) Kicad rebuilt from src and started from scratch after rm 
>> ~/.config/kicad
>>
>>
>> ---
>> Application: kicad
>> Version: (2018-01-08  revision 0e9c8a423)-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.12-1-ARCH 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
> 
> 
> 
> ___
> 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

[Jeff Young]

+1 to the Google icon overlays.

> On 9 Jan 2018, at 21:15, Jon Evans  wrote:
> 
> Inspiration from Google's material design icons? (permissively-licensed) . 
> These could be overlaid in the bottom right quarter maybe?
> 
> 
> 
> 
> On Tue, Jan 9, 2018 at 4:09 PM, Oliver Walters 
> mailto:oliver.henry.walt...@gmail.com>> 
> wrote:
> Ok, that's good to hear. I will take another look at the Gerber icons and 
> otherwise see if anyone can suggest some simple clean replacements for the 
> arrows. If not, I'll push a patch.
> 
> On Wed, Jan 10, 2018 at 8:05 AM, Wayne Stambaugh  > wrote:
> One good thing about bitmaps is they are low risk (other than the
> complaining that will surely ensue) so we can merge them just about any
> time.  I don't want to wait too long so our doc images can be updated to
> reflect the changes so if we cannot come up with better alternatives to
> replace the arrows, I'm OK with leaving them as is and pushing it off
> until v6.
> 
> Cheers,
> 
> Wayne
> 
> On 1/9/2018 3:31 PM, Jeff Young wrote:
> > I think the changes are absolutely good in general, and I’d very much
> > like to see them get merged.  Not that I have any control over that. ;)
> >
> > As for the arrows, I’d still really like to see them go away.  The
> > colour isn’t the problem, it’s the arrows themselves. ANY of the
> > alternatives discussed (that don’t include arrows) would be better.
> >
> > Cheers,
> > Jeff.
> >
> >
> >> On 9 Jan 2018, at 20:13, Oliver Walters
> >> mailto:oliver.henry.walt...@gmail.com>
> >>  >> >> wrote:
> >>
> >> The coloured arrows were already in place, all I have done is made
> >> them all the same "style". In fact, previously concepts like "save"
> >> and "load" were conveyed both with a downward pointing arrow, and the
> >> arrow colour was the only point of difference. 
> >>
> >> I thought I had made an improvement on what was already existing. My
> >> intent was not to necessarily do a sweeping redesign. 
> >>
> >> If this is now an additional requirement I can make these not arrows,
> >> but I'd like some direction on what to do instead. It will be hard to
> >> fit a more detailed icon. 
> >>
> >> Other than this, what are your thoughts overall? Is it worth my time
> >> pursuing this further? Are these changes good in general and can you
> >> see them being merged? 
> >>
> >> On 10 Jan 2018 04:44, "Wayne Stambaugh"  >> 
> >> >> wrote:
> >>
> >> On 1/9/2018 12:05 PM, Rene Pöschl wrote:
> >> > On 09/01/18 16:50, Wayne Stambaugh wrote:
> >> >> I'm with Jose on the arrows.  If we are going to use them,
> >> please don't
> >> >> make the all different colors.  I don't see how a blue left
> >> arrow versus
> >> >> a magenta right arrow conveys any meaning to the user.
> >> >>
> >> >
> >> > I like the idea of coloring them differently. For me this will
> >> give an
> >> > additional way to distinguish the buttons. (Some of them have
> >> only the
> >> > direction of the arrow as a difference. Which is easily
> >> overlooked.) I
> >> > hope having different colors will make it easier for my brain to
> >> > remember which button does what. (I can't tell you how often i
> >> clicked
> >> > load symbol instead of update symbol while working on the
> >> reorganization
> >> > of the official lib.)
> >>
> >> What information does the different color arrow convey?  If you are
> >> using different colors for contrast, that is one thing but just making
> >> them different colors for informational purposes doesn't make any
> >> sense
> >> to me.  If you are trying convey information with different color
> >> buttons, what is the impact on users who are color blind.
> >>
> >> >
> >> > Maybe there is a better way to communicate differences but if
> >> buttons
> >> > look as similar as a lot of them currently do, adding
> >> differentiating
> >> > colors might help.
> >> >
> >> > ___
> >> > 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] [4.0.7] Bug report: Cannot open a project called noname.pro

[Heiko Rosemann]

Hi Nick,

thanks, than I guess someone caught this before and fixed it :) Whenever
5.0 hits Slackware, I'll give it another try and cry out again if not.

(been waiting for your eMail to hit the mailing list, didn't happen, so
I'm responding to both now)

Best Regards,
Heiko

On 01/08/2018 10:17 PM, Nick Østergaard wrote:
> I cannot reproduce this on linux with:
> Application: kicad
> Version: (2018-01-08 revision 3fb60f770)-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.28.0
> Platform: Linux 4.14.8-1-ARCH 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=OFF
>     KICAD_SCRIPTING_MODULES=OFF
>     KICAD_SCRIPTING_WXPYTHON=OFF
>     KICAD_SCRIPTING_ACTION_MENU=OFF
>     BUILD_GITHUB_PLUGIN=ON
>     KICAD_USE_OCE=ON
>     KICAD_SPICE=ON
> 
> 
> 2018-01-08 20:05 GMT+01:00 Heiko Rosemann  >:
> 
> Hi everyone,
> 
> I've been reading on this list for quite a while, but quietly...
> 
> Today this changes - I stumbled across a bug in 4.0.7 stable, and since
> I don't have a launchpad ID, I'm reporting it here. I don't seem to
> recall this being addressed recently though if it's fixed in master I'll
> happily wait for 5.0 to hit stable :) and a quick filter through my
> kicad emails doesn't find anything for noname.pro
> , so here you go:
> 
> When I save a project under the name noname.pro ,
> I can't reopen it.
> 
> Steps to reproduce:
> 1) Start kicad
> 2) Select "File->New Project->New Project" from the menu
> 3) Choose "noname.pro " as name (folder does not
> seem to matter)
> 4) Open a different project
> 5a) Select "File->Open Project" from the menu and navigate to find
> noname.pro  created in Step 3 or
> 5b) Select "File->Open Recent->noname.pro " from
> the menu
> 
> Expected results:
> Open project created in Step 3 above
> 
> Actual results:
> Project opened in Step 4 above stays open, Icons grey out and the
> message area says "To proceed, you can use the File menu to start a new
> project."
> 
> Kicad version info:
> Application: kicad
> Version: 4.0.7 release build
> wxWidgets: Version 3.0.3 (debug,wchar_t,compiler with C++ ABI 1009,GCC
> 5.3.0,wx containers,compatible with 2.8)
> Platform: Linux 4.4.88 x86_64, 64 bit, Little endian, wxGTK
> Boost version: 1.59.0
> Curl version: libcurl/7.57.0 OpenSSL/1.0.2n zlib/1.2.8 libssh2/1.7.0
>          USE_WX_GRAPHICS_CONTEXT=OFF
>          USE_WX_OVERLAY=OFF
>          KICAD_SCRIPTING=ON
>          KICAD_SCRIPTING_MODULES=ON
>          KICAD_SCRIPTING_WXPYTHON=ON
>          USE_FP_LIB_TABLE=HARD_CODED_ON
>          BUILD_GITHUB_PLUGIN=ON
> 
> (Slackware Linux built from the SlackBuild at:
> https://slackbuilds.org/repository/14.2/development/kicad/
> )
> 
> If you need any more info, go ahead and ask (and as for: "Why do you
> name a project noname.pro ?" - that's because I
> needed a quick throwaway
> name for a "panelizing project" to create fabrication outputs for a
> panel from two different PCBs - no data lost there)
> 
> Best Regards and Thanks for this amazing piece of software,
> Heiko
> 
> --
> Mein PGP-Key zur Verifizierung: http://pgp.mit.edu
> 
> 
> 
> ___
> 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
> 
> 
> 


-- 
eMails verschlüsseln mit PGP - privacy is your right!
Mein PGP-Key zur Verifizierung: http://pgp.mit.edu




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] Fix some performance issues

[Chris Pavlina]

Don't wait for my changes, I just wanted to feel out whether you'd be
willing to accept them soon. I'm not sure if or when I'll get to them.

On Tue, Jan 09, 2018 at 04:01:53PM -0500, Wayne Stambaugh wrote:
> Camille,
> 
> Although I didn't look over all of it, I'm OK with most of this since it
> is low risk but I wish you would have broken it into smaller patches.
> Reviewing a 124K patch is not my idea of fun.  I'm waiting on some file
> renaming work from Chris which I am sure is going to clash with your
> patch set.  As soon as Chris merges his changes, I will start merging
> your patches and ask you to rebase them as required.
> 
> Cheers,
> 
> Wayne
> 
> On 1/9/2018 3:41 PM, Camille 019 wrote:
> > Hi,
> > 
> > 
> > As promised, here are the patches up to date.
> > 
> > 
> > Regards,
> > 
> > Camille
> > 
> > 
> > *De :* Camille 
> > *Envoyé :* mardi 26 septembre 2017 21:56:07
> > *À :* Wayne Stambaugh
> > *Cc :* kicad-developers@lists.launchpad.net
> > *Objet :* Re: [Kicad-developers] [PATCH] Fix some performance issues
> >  
> > Hi,
> > 
> > Ok, I'll keep the patchset synchronized with the master branch, for
> > future inclusion. When will the feature freeze take effect ?
> > 
> > I agree my patchset has no real impact on the performance. I mainly
> > wanted to test clang-tidy on a consistent source code base. I also think
> > that keeping automated checks empty of warning can help to improve the
> > overall code quality.
> > 
> > Regards,
> > 
> > --
> > Camille
> > 
> > 
> > Le lun. 25 sept. 2017 à 16:21, Wayne Stambaugh  a
> > écrit :
> >> On 9/25/2017 4:07 AM, Maciej Sumiński wrote:
> >>
> >> Hi Camille, I think the attached patches are sensible, even though
> >> I hope most compilers apply optimizations to avoid performance
> >> penalties whenever possible. 
> >>
> >> I agree although I'm not sure about the compiler optimization. A quick
> >> look at the patches and I'm not sure the performance gains will be
> >> that noticeable. Most of the changes are in code that is called once
> >> on demand in response to a user request as opposed to the drawing or
> >> drc code where large numbers of calls happen frequently. That being
> >> said, we really should be doing a better job of not passing entire
> >> objects on the stack unless there is a good reason to do so.
> >>
> >> If the attached patches are autogenerated, then I would kindly ask
> >> you to generate them when we reach the feature freeze stage. There
> >> are a few branches that await to be merged and I am not sure
> >> whether your patches would not create too many conflicts. During
> >> the feature freeze we anticipate the code changes will not be as
> >> disruptive as they are now. 
> >>
> >> I second this. There are quite a few outstanding patches that will
> >> likely have enough conflicts so I would rather not pile more on top of
> >> that.
> >>
> >> Regards, Orson On 09/23/2017 12:17 PM, Camille 019 wrote:
> >>
> >> Hi all, I recently play with clang-tidy on the KiCad source
> >> code. Here is a set of 2 patch which fix the
> >> 
> >> unnecessary-copy-initialization
> >> and
> >> 
> >> unnecessary-value-param
> >> checks. I will run more performance checks in the future. The
> >> next two: -
> >> 
> >> for-range-copy
> >> -
> >> 
> >> type-promotion-in-math-fn
> >> Best regards, -- Camille
> >> ___ 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] Libedit and Modedit Icons

[Jon Evans]

Inspiration from Google's material design icons? (permissively-licensed) .
These could be overlaid in the bottom right quarter maybe?
[image: Inline image 3]
[image: Inline image 1]
[image: Inline image 2]

On Tue, Jan 9, 2018 at 4:09 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Ok, that's good to hear. I will take another look at the Gerber icons and
> otherwise see if anyone can suggest some simple clean replacements for the
> arrows. If not, I'll push a patch.
>
> On Wed, Jan 10, 2018 at 8:05 AM, Wayne Stambaugh 
> wrote:
>
>> One good thing about bitmaps is they are low risk (other than the
>> complaining that will surely ensue) so we can merge them just about any
>> time.  I don't want to wait too long so our doc images can be updated to
>> reflect the changes so if we cannot come up with better alternatives to
>> replace the arrows, I'm OK with leaving them as is and pushing it off
>> until v6.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 1/9/2018 3:31 PM, Jeff Young wrote:
>> > I think the changes are absolutely good in general, and I’d very much
>> > like to see them get merged.  Not that I have any control over that. ;)
>> >
>> > As for the arrows, I’d still really like to see them go away.  The
>> > colour isn’t the problem, it’s the arrows themselves. ANY of the
>> > alternatives discussed (that don’t include arrows) would be better.
>> >
>> > Cheers,
>> > Jeff.
>> >
>> >
>> >> On 9 Jan 2018, at 20:13, Oliver Walters
>> >> > >> > wrote:
>> >>
>> >> The coloured arrows were already in place, all I have done is made
>> >> them all the same "style". In fact, previously concepts like "save"
>> >> and "load" were conveyed both with a downward pointing arrow, and the
>> >> arrow colour was the only point of difference.
>> >>
>> >> I thought I had made an improvement on what was already existing. My
>> >> intent was not to necessarily do a sweeping redesign.
>> >>
>> >> If this is now an additional requirement I can make these not arrows,
>> >> but I'd like some direction on what to do instead. It will be hard to
>> >> fit a more detailed icon.
>> >>
>> >> Other than this, what are your thoughts overall? Is it worth my time
>> >> pursuing this further? Are these changes good in general and can you
>> >> see them being merged?
>> >>
>> >> On 10 Jan 2018 04:44, "Wayne Stambaugh" > >> > wrote:
>> >>
>> >> On 1/9/2018 12:05 PM, Rene Pöschl wrote:
>> >> > On 09/01/18 16:50, Wayne Stambaugh wrote:
>> >> >> I'm with Jose on the arrows.  If we are going to use them,
>> >> please don't
>> >> >> make the all different colors.  I don't see how a blue left
>> >> arrow versus
>> >> >> a magenta right arrow conveys any meaning to the user.
>> >> >>
>> >> >
>> >> > I like the idea of coloring them differently. For me this will
>> >> give an
>> >> > additional way to distinguish the buttons. (Some of them have
>> >> only the
>> >> > direction of the arrow as a difference. Which is easily
>> >> overlooked.) I
>> >> > hope having different colors will make it easier for my brain to
>> >> > remember which button does what. (I can't tell you how often i
>> >> clicked
>> >> > load symbol instead of update symbol while working on the
>> >> reorganization
>> >> > of the official lib.)
>> >>
>> >> What information does the different color arrow convey?  If you are
>> >> using different colors for contrast, that is one thing but just
>> making
>> >> them different colors for informational purposes doesn't make any
>> >> sense
>> >> to me.  If you are trying convey information with different color
>> >> buttons, what is the impact on users who are color blind.
>> >>
>> >> >
>> >> > Maybe there is a better way to communicate differences but if
>> >> buttons
>> >> > look as similar as a lot of them currently do, adding
>> >> differentiating
>> >> > colors might help.
>> >> >
>> >> > ___
>> >> > 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   : htt

Re: [Kicad-developers] Libedit and Modedit Icons

[Oliver Walters]

Ok, that's good to hear. I will take another look at the Gerber icons and
otherwise see if anyone can suggest some simple clean replacements for the
arrows. If not, I'll push a patch.

On Wed, Jan 10, 2018 at 8:05 AM, Wayne Stambaugh 
wrote:

> One good thing about bitmaps is they are low risk (other than the
> complaining that will surely ensue) so we can merge them just about any
> time.  I don't want to wait too long so our doc images can be updated to
> reflect the changes so if we cannot come up with better alternatives to
> replace the arrows, I'm OK with leaving them as is and pushing it off
> until v6.
>
> Cheers,
>
> Wayne
>
> On 1/9/2018 3:31 PM, Jeff Young wrote:
> > I think the changes are absolutely good in general, and I’d very much
> > like to see them get merged.  Not that I have any control over that. ;)
> >
> > As for the arrows, I’d still really like to see them go away.  The
> > colour isn’t the problem, it’s the arrows themselves. ANY of the
> > alternatives discussed (that don’t include arrows) would be better.
> >
> > Cheers,
> > Jeff.
> >
> >
> >> On 9 Jan 2018, at 20:13, Oliver Walters
> >>  >> > wrote:
> >>
> >> The coloured arrows were already in place, all I have done is made
> >> them all the same "style". In fact, previously concepts like "save"
> >> and "load" were conveyed both with a downward pointing arrow, and the
> >> arrow colour was the only point of difference.
> >>
> >> I thought I had made an improvement on what was already existing. My
> >> intent was not to necessarily do a sweeping redesign.
> >>
> >> If this is now an additional requirement I can make these not arrows,
> >> but I'd like some direction on what to do instead. It will be hard to
> >> fit a more detailed icon.
> >>
> >> Other than this, what are your thoughts overall? Is it worth my time
> >> pursuing this further? Are these changes good in general and can you
> >> see them being merged?
> >>
> >> On 10 Jan 2018 04:44, "Wayne Stambaugh"  >> > wrote:
> >>
> >> On 1/9/2018 12:05 PM, Rene Pöschl wrote:
> >> > On 09/01/18 16:50, Wayne Stambaugh wrote:
> >> >> I'm with Jose on the arrows.  If we are going to use them,
> >> please don't
> >> >> make the all different colors.  I don't see how a blue left
> >> arrow versus
> >> >> a magenta right arrow conveys any meaning to the user.
> >> >>
> >> >
> >> > I like the idea of coloring them differently. For me this will
> >> give an
> >> > additional way to distinguish the buttons. (Some of them have
> >> only the
> >> > direction of the arrow as a difference. Which is easily
> >> overlooked.) I
> >> > hope having different colors will make it easier for my brain to
> >> > remember which button does what. (I can't tell you how often i
> >> clicked
> >> > load symbol instead of update symbol while working on the
> >> reorganization
> >> > of the official lib.)
> >>
> >> What information does the different color arrow convey?  If you are
> >> using different colors for contrast, that is one thing but just
> making
> >> them different colors for informational purposes doesn't make any
> >> sense
> >> to me.  If you are trying convey information with different color
> >> buttons, what is the impact on users who are color blind.
> >>
> >> >
> >> > Maybe there is a better way to communicate differences but if
> >> buttons
> >> > look as similar as a lot of them currently do, adding
> >> differentiating
> >> > colors might help.
> >> >
> >> > ___
> >> > 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/

Re: [Kicad-developers] Libedit and Modedit Icons

[Wayne Stambaugh]

One good thing about bitmaps is they are low risk (other than the
complaining that will surely ensue) so we can merge them just about any
time.  I don't want to wait too long so our doc images can be updated to
reflect the changes so if we cannot come up with better alternatives to
replace the arrows, I'm OK with leaving them as is and pushing it off
until v6.

Cheers,

Wayne

On 1/9/2018 3:31 PM, Jeff Young wrote:
> I think the changes are absolutely good in general, and I’d very much
> like to see them get merged.  Not that I have any control over that. ;)
> 
> As for the arrows, I’d still really like to see them go away.  The
> colour isn’t the problem, it’s the arrows themselves. ANY of the
> alternatives discussed (that don’t include arrows) would be better.
> 
> Cheers,
> Jeff.
> 
> 
>> On 9 Jan 2018, at 20:13, Oliver Walters
>> > > wrote:
>>
>> The coloured arrows were already in place, all I have done is made
>> them all the same "style". In fact, previously concepts like "save"
>> and "load" were conveyed both with a downward pointing arrow, and the
>> arrow colour was the only point of difference. 
>>
>> I thought I had made an improvement on what was already existing. My
>> intent was not to necessarily do a sweeping redesign. 
>>
>> If this is now an additional requirement I can make these not arrows,
>> but I'd like some direction on what to do instead. It will be hard to
>> fit a more detailed icon. 
>>
>> Other than this, what are your thoughts overall? Is it worth my time
>> pursuing this further? Are these changes good in general and can you
>> see them being merged? 
>>
>> On 10 Jan 2018 04:44, "Wayne Stambaugh" > > wrote:
>>
>> On 1/9/2018 12:05 PM, Rene Pöschl wrote:
>> > On 09/01/18 16:50, Wayne Stambaugh wrote:
>> >> I'm with Jose on the arrows.  If we are going to use them,
>> please don't
>> >> make the all different colors.  I don't see how a blue left
>> arrow versus
>> >> a magenta right arrow conveys any meaning to the user.
>> >>
>> >
>> > I like the idea of coloring them differently. For me this will
>> give an
>> > additional way to distinguish the buttons. (Some of them have
>> only the
>> > direction of the arrow as a difference. Which is easily
>> overlooked.) I
>> > hope having different colors will make it easier for my brain to
>> > remember which button does what. (I can't tell you how often i
>> clicked
>> > load symbol instead of update symbol while working on the
>> reorganization
>> > of the official lib.)
>>
>> What information does the different color arrow convey?  If you are
>> using different colors for contrast, that is one thing but just making
>> them different colors for informational purposes doesn't make any
>> sense
>> to me.  If you are trying convey information with different color
>> buttons, what is the impact on users who are color blind.
>>
>> >
>> > Maybe there is a better way to communicate differences but if
>> buttons
>> > look as similar as a lot of them currently do, adding
>> differentiating
>> > colors might help.
>> >
>> > ___
>> > 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
> 

___
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] Fix some performance issues

[Wayne Stambaugh]

Camille,

Although I didn't look over all of it, I'm OK with most of this since it
is low risk but I wish you would have broken it into smaller patches.
Reviewing a 124K patch is not my idea of fun.  I'm waiting on some file
renaming work from Chris which I am sure is going to clash with your
patch set.  As soon as Chris merges his changes, I will start merging
your patches and ask you to rebase them as required.

Cheers,

Wayne

On 1/9/2018 3:41 PM, Camille 019 wrote:
> Hi,
> 
> 
> As promised, here are the patches up to date.
> 
> 
> Regards,
> 
> Camille
> 
> 
> *De :* Camille 
> *Envoyé :* mardi 26 septembre 2017 21:56:07
> *À :* Wayne Stambaugh
> *Cc :* kicad-developers@lists.launchpad.net
> *Objet :* Re: [Kicad-developers] [PATCH] Fix some performance issues
>  
> Hi,
> 
> Ok, I'll keep the patchset synchronized with the master branch, for
> future inclusion. When will the feature freeze take effect ?
> 
> I agree my patchset has no real impact on the performance. I mainly
> wanted to test clang-tidy on a consistent source code base. I also think
> that keeping automated checks empty of warning can help to improve the
> overall code quality.
> 
> Regards,
> 
> --
> Camille
> 
> 
> Le lun. 25 sept. 2017 à 16:21, Wayne Stambaugh  a
> écrit :
>> On 9/25/2017 4:07 AM, Maciej Sumiński wrote:
>>
>> Hi Camille, I think the attached patches are sensible, even though
>> I hope most compilers apply optimizations to avoid performance
>> penalties whenever possible. 
>>
>> I agree although I'm not sure about the compiler optimization. A quick
>> look at the patches and I'm not sure the performance gains will be
>> that noticeable. Most of the changes are in code that is called once
>> on demand in response to a user request as opposed to the drawing or
>> drc code where large numbers of calls happen frequently. That being
>> said, we really should be doing a better job of not passing entire
>> objects on the stack unless there is a good reason to do so.
>>
>> If the attached patches are autogenerated, then I would kindly ask
>> you to generate them when we reach the feature freeze stage. There
>> are a few branches that await to be merged and I am not sure
>> whether your patches would not create too many conflicts. During
>> the feature freeze we anticipate the code changes will not be as
>> disruptive as they are now. 
>>
>> I second this. There are quite a few outstanding patches that will
>> likely have enough conflicts so I would rather not pile more on top of
>> that.
>>
>> Regards, Orson On 09/23/2017 12:17 PM, Camille 019 wrote:
>>
>> Hi all, I recently play with clang-tidy on the KiCad source
>> code. Here is a set of 2 patch which fix the
>> 
>> unnecessary-copy-initialization
>> and
>> 
>> unnecessary-value-param
>> checks. I will run more performance checks in the future. The
>> next two: -
>> 
>> for-range-copy
>> -
>> 
>> type-promotion-in-math-fn
>> Best regards, -- Camille
>> ___ 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
> 
> 
> ___
> 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-develope

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

[Wayne Stambaugh]

Tom and Orson,

You are far more familiar with this code that I am.  I'm going to defer
to you for input and approval on this.  It's presently looking more
involved than I am comfortable with during a feature freeze.  Please let
me know what you think when you get a chance to review and test it.

Thanks.

Wayne

On 1/9/2018 3:29 PM, Jeff Young wrote:
> Hi Seth,
> 
> Yeah, I did try some of those other methods first.  But they all let
> implementation details bleed into the wrong places (COLLECORS_GUIDE
> instead of SELECTION_TOOL, but the info still doesn’t belong outside of
> the router).
> 
> You are correct that some of the changes in selectPoint are just cleanup
> and are not required.  I almost removed the Wait(TOOL_EVENT) thing
> entirely as selectPoint is never called with aOnDrag = true.  But that
> seemed like perhaps too much cleanup. ;)
> 
> However, it’s not true that Wait will get called under different
> circumstances as the heuristics part isn’t a filter per se, and won’t
> ever remove everything.
> 
> Cheers,
> Jeff.
> 
> 
>> On 9 Jan 2018, at 20:09, Seth Hillbrand > > wrote:
>>
>> Jeff-
>>
>> I get your reasoning.  However, it seems like you could accomplish the
>> same goal (preventing disambiguation) by using the existing
>> GENERAL_COLLECTOR::Modules[] for your footprint disambiguation and
>> maybe modifying the COLLECTORS_GUIDE or Inspect() to get the track
>> disambiguation.  This would reduce the impact of your patch and not
>> create duplicate functionality.
>>
>> In other aspects, the changes to selectPoint do not seem required
>> (correct me if I'm wrong) and they introduce a subtle bug by
>> triggering a Wait(TOOL_EVENT) even if the heuristics have removed all
>> items from the collector.
>>
>> Overall, I like the idea.  It makes sense to have a post-filter.  But
>> I would worry that this is more invasive than is needed to resolve the
>> issue during feature-freeze.
>>
>> -S
>>
>> 2018-01-09 11:36 GMT-08:00 Jeff Young > >:
>>
>> Hi Seth,
>>
>> The test_window creates a  SELECTION_TOOL without the rest of
>> kicad behind it.  Since I added methods which SELECTION_TOOL
>> calls, I had to mock them in the test files.
>>
>> GENERAL_COLLECTOR::Modules[] can’t be used because the creator of
>> the collector (SELECTION_TOOL) shouldn’t know anything about the
>> semantics of the filter (only the specific action implementation
>> knows that).  In the FootprintFilter case it’s simply enough that
>> you’d nearly be willing to overlook that, but the other filters
>> are more complicated and required things like ROUTER_TOOL
>> knowledge, which definitely shouldn’t be leaking into SELECTION_TOOL.
>>
>> Cheers,
>> Jeff.
>>
>>
>>> On 9 Jan 2018, at 19:26, Seth Hillbrand >> > wrote:
>>>
>>> Same here.  Same errors.  Yes, cmaked.
>>>
>>> I don't understand why you are changing the test_window link
>>> libraries in this patch.
>>>
>>> Also, why did you decide to write a "FootprintFilter" routine
>>> instead of using the GENERAL_COLLECTOR::Modules[]?
>>>
>>> -S
>>>
>>> 2018-01-09 11:05 GMT-08:00 Jeff Young >> >:
>>>
>>> Did you do a CMake?  There’s a change in the CMake files….
>>>
>>> > On 9 Jan 2018, at 18:59, kristoffer Ödmark
>>> >> > wrote:
>>> >
>>> > Hmm, cannot compile, get a lot of undefiner references.
>>> Even after nuking the build dir.
>>> >
>>> >
>>> > ../../common/libpcbcommon.a(class_pad.cpp.o): In function
>>> `D_PAD::HitTest(EDA_RECT const&, bool, int) const':
>>> > kicad/pcbnew/class_pad.cpp:982: undefined reference to
>>> `TestPointInsidePolygon(wxPoint const*, int, wxPoint const&)'
>>> > ../../common/libpcbcommon.a(class_zone.cpp.o): In function
>>> `ZONE_CONTAINER::Hatch()':
>>> > kicad/pcbnew/class_zone.cpp:1219: undefined reference to
>>> `FindLineSegmentIntersection(double, double, int, int, int,
>>> int, double*, double*, double*, double*, double*)'
>>> > ../../common/libcommon.a(shape_poly_set.cpp.o): In function
>>> `SHAPE_POLY_SET::convertToClipper(SHAPE_LINE_CHAIN const&,
>>> bool)':
>>> > kicad/common/geometry/shape_poly_set.cpp:466: undefined
>>> reference to
>>> `ClipperLib::Orientation(std::vector>> std::allocator > const&)'
>>> > kicad/common/geometry/shape_poly_set.cpp:467: undefined
>>> reference to
>>> `ClipperLib::ReversePath(std::vector>> std::allocator >&)'
>>> > ../../common/libcommon.a(shape_poly_set.cpp.o): In function
>>> `SHAPE_POLY_SET::booleanOp(ClipperLib::ClipType,
>>> SHAPE_POLY_SET const&, SHAPE_POLY_SET::POLYGON_MODE)':
>>> > kicad/common/geometry/sha

Re: [Kicad-developers] Libedit and Modedit Icons

[Jeff Young]

I think the changes are absolutely good in general, and I’d very much like to 
see them get merged.  Not that I have any control over that. ;)

As for the arrows, I’d still really like to see them go away.  The colour isn’t 
the problem, it’s the arrows themselves. ANY of the alternatives discussed 
(that don’t include arrows) would be better.

Cheers,
Jeff.


> On 9 Jan 2018, at 20:13, Oliver Walters  
> wrote:
> 
> The coloured arrows were already in place, all I have done is made them all 
> the same "style". In fact, previously concepts like "save" and "load" were 
> conveyed both with a downward pointing arrow, and the arrow colour was the 
> only point of difference. 
> 
> I thought I had made an improvement on what was already existing. My intent 
> was not to necessarily do a sweeping redesign. 
> 
> If this is now an additional requirement I can make these not arrows, but I'd 
> like some direction on what to do instead. It will be hard to fit a more 
> detailed icon. 
> 
> Other than this, what are your thoughts overall? Is it worth my time pursuing 
> this further? Are these changes good in general and can you see them being 
> merged? 
> 
> On 10 Jan 2018 04:44, "Wayne Stambaugh"  > wrote:
> On 1/9/2018 12:05 PM, Rene Pöschl wrote:
> > On 09/01/18 16:50, Wayne Stambaugh wrote:
> >> I'm with Jose on the arrows.  If we are going to use them, please don't
> >> make the all different colors.  I don't see how a blue left arrow versus
> >> a magenta right arrow conveys any meaning to the user.
> >>
> >
> > I like the idea of coloring them differently. For me this will give an
> > additional way to distinguish the buttons. (Some of them have only the
> > direction of the arrow as a difference. Which is easily overlooked.) I
> > hope having different colors will make it easier for my brain to
> > remember which button does what. (I can't tell you how often i clicked
> > load symbol instead of update symbol while working on the reorganization
> > of the official lib.)
> 
> What information does the different color arrow convey?  If you are
> using different colors for contrast, that is one thing but just making
> them different colors for informational purposes doesn't make any sense
> to me.  If you are trying convey information with different color
> buttons, what is the impact on users who are color blind.
> 
> >
> > Maybe there is a better way to communicate differences but if buttons
> > look as similar as a lot of them currently do, adding differentiating
> > colors might help.
> >
> > ___
> > 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

___
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,

Yeah, I did try some of those other methods first.  But they all let 
implementation details bleed into the wrong places (COLLECORS_GUIDE instead of 
SELECTION_TOOL, but the info still doesn’t belong outside of the router).

You are correct that some of the changes in selectPoint are just cleanup and 
are not required.  I almost removed the Wait(TOOL_EVENT) thing entirely as 
selectPoint is never called with aOnDrag = true.  But that seemed like perhaps 
too much cleanup. ;)

However, it’s not true that Wait will get called under different circumstances 
as the heuristics part isn’t a filter per se, and won’t ever remove everything.

Cheers,
Jeff.


> On 9 Jan 2018, at 20:09, Seth Hillbrand  wrote:
> 
> Jeff-
> 
> I get your reasoning.  However, it seems like you could accomplish the same 
> goal (preventing disambiguation) by using the existing 
> GENERAL_COLLECTOR::Modules[] for your footprint disambiguation and maybe 
> modifying the COLLECTORS_GUIDE or Inspect() to get the track disambiguation.  
> This would reduce the impact of your patch and not create duplicate 
> functionality.
> 
> In other aspects, the changes to selectPoint do not seem required (correct me 
> if I'm wrong) and they introduce a subtle bug by triggering a 
> Wait(TOOL_EVENT) even if the heuristics have removed all items from the 
> collector.
> 
> Overall, I like the idea.  It makes sense to have a post-filter.  But I would 
> worry that this is more invasive than is needed to resolve the issue during 
> feature-freeze.
> 
> -S
> 
> 2018-01-09 11:36 GMT-08:00 Jeff Young  >:
> Hi Seth,
> 
> The test_window creates a  SELECTION_TOOL without the rest of kicad behind 
> it.  Since I added methods which SELECTION_TOOL calls, I had to mock them in 
> the test files.
> 
> GENERAL_COLLECTOR::Modules[] can’t be used because the creator of the 
> collector (SELECTION_TOOL) shouldn’t know anything about the semantics of the 
> filter (only the specific action implementation knows that).  In the 
> FootprintFilter case it’s simply enough that you’d nearly be willing to 
> overlook that, but the other filters are more complicated and required things 
> like ROUTER_TOOL knowledge, which definitely shouldn’t be leaking into 
> SELECTION_TOOL.
> 
> Cheers,
> Jeff.
> 
> 
>> On 9 Jan 2018, at 19:26, Seth Hillbrand > > wrote:
>> 
>> Same here.  Same errors.  Yes, cmaked.
>> 
>> I don't understand why you are changing the test_window link libraries in 
>> this patch.
>> 
>> Also, why did you decide to write a "FootprintFilter" routine instead of 
>> using the GENERAL_COLLECTOR::Modules[]?
>> 
>> -S
>> 
>> 2018-01-09 11:05 GMT-08:00 Jeff Young > >:
>> Did you do a CMake?  There’s a change in the CMake files….
>> 
>> > On 9 Jan 2018, at 18:59, kristoffer Ödmark > > > wrote:
>> >
>> > Hmm, cannot compile, get a lot of undefiner references. Even after nuking 
>> > the build dir.
>> >
>> >
>> > ../../common/libpcbcommon.a(class_pad.cpp.o): In function 
>> > `D_PAD::HitTest(EDA_RECT const&, bool, int) const':
>> > kicad/pcbnew/class_pad.cpp:982: undefined reference to 
>> > `TestPointInsidePolygon(wxPoint const*, int, wxPoint const&)'
>> > ../../common/libpcbcommon.a(class_zone.cpp.o): In function 
>> > `ZONE_CONTAINER::Hatch()':
>> > kicad/pcbnew/class_zone.cpp:1219: undefined reference to 
>> > `FindLineSegmentIntersection(double, double, int, int, int, int, double*, 
>> > double*, double*, double*, double*)'
>> > ../../common/libcommon.a(shape_poly_set.cpp.o): In function 
>> > `SHAPE_POLY_SET::convertToClipper(SHAPE_LINE_CHAIN const&, bool)':
>> > kicad/common/geometry/shape_poly_set.cpp:466: undefined reference to 
>> > `ClipperLib::Orientation(std::vector> > std::allocator > const&)'
>> > kicad/common/geometry/shape_poly_set.cpp:467: undefined reference to 
>> > `ClipperLib::ReversePath(std::vector> > std::allocator >&)'
>> > ../../common/libcommon.a(shape_poly_set.cpp.o): In function 
>> > `SHAPE_POLY_SET::booleanOp(ClipperLib::ClipType, SHAPE_POLY_SET const&, 
>> > SHAPE_POLY_SET::POLYGON_MODE)':
>> > kicad/common/geometry/shape_poly_set.cpp:489: undefined reference to 
>> > `ClipperLib::Clipper::Clipper(int)'
>> >
>> >
>> > On 2018-01-09 19:22, Wayne Stambaugh wrote:
>> >> Does the patch resolve your issue?
>> >>
>> >> On 1/9/2018 1:21 PM, kristoffer Ödmark wrote:
>> >>> Yes, I can reproduce this with very thick tracks!
>> >>>
>> >>>
>> >>> On 2018-01-09 16:55, Jeff Young wrote:
>>  Hi Kristoffer,
>> 
>>  That’s odd.  Did you try it with your mouse pointer directly over the
>>  corner?  (You may need a reasonably thick track for this to happen.
>>  Try something on the order of 2mm.)
>> 
>>  Without my change the selection disambiguation is run *before* we know
>>  it’s a drag action on a simple corner, so the selection_tool thinks it
>>  needs to know which of the two segments is to be 

Re: [Kicad-developers] Libedit and Modedit Icons

[Oliver Walters]

The coloured arrows were already in place, all I have done is made them all
the same "style". In fact, previously concepts like "save" and "load" were
conveyed both with a downward pointing arrow, and the arrow colour was the
only point of difference.

I thought I had made an improvement on what was already existing. My intent
was not to necessarily do a sweeping redesign.

If this is now an additional requirement I can make these not arrows, but
I'd like some direction on what to do instead. It will be hard to fit a
more detailed icon.

Other than this, what are your thoughts overall? Is it worth my time
pursuing this further? Are these changes good in general and can you see
them being merged?

On 10 Jan 2018 04:44, "Wayne Stambaugh"  wrote:

> On 1/9/2018 12:05 PM, Rene Pöschl wrote:
> > On 09/01/18 16:50, Wayne Stambaugh wrote:
> >> I'm with Jose on the arrows.  If we are going to use them, please don't
> >> make the all different colors.  I don't see how a blue left arrow versus
> >> a magenta right arrow conveys any meaning to the user.
> >>
> >
> > I like the idea of coloring them differently. For me this will give an
> > additional way to distinguish the buttons. (Some of them have only the
> > direction of the arrow as a difference. Which is easily overlooked.) I
> > hope having different colors will make it easier for my brain to
> > remember which button does what. (I can't tell you how often i clicked
> > load symbol instead of update symbol while working on the reorganization
> > of the official lib.)
>
> What information does the different color arrow convey?  If you are
> using different colors for contrast, that is one thing but just making
> them different colors for informational purposes doesn't make any sense
> to me.  If you are trying convey information with different color
> buttons, what is the impact on users who are color blind.
>
> >
> > Maybe there is a better way to communicate differences but if buttons
> > look as similar as a lot of them currently do, adding differentiating
> > colors might help.
> >
> > ___
> > 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] One more quick plug for reducing "Clarify Selection" dialogs

[Seth Hillbrand]

Jeff-

I get your reasoning.  However, it seems like you could accomplish the same
goal (preventing disambiguation) by using the existing
GENERAL_COLLECTOR::Modules[] for your footprint disambiguation and maybe
modifying the COLLECTORS_GUIDE or Inspect() to get the track
disambiguation.  This would reduce the impact of your patch and not create
duplicate functionality.

In other aspects, the changes to selectPoint do not seem required (correct
me if I'm wrong) and they introduce a subtle bug by triggering a
Wait(TOOL_EVENT) even if the heuristics have removed all items from the
collector.

Overall, I like the idea.  It makes sense to have a post-filter.  But I
would worry that this is more invasive than is needed to resolve the issue
during feature-freeze.

-S

2018-01-09 11:36 GMT-08:00 Jeff Young :

> Hi Seth,
>
> The test_window creates a  SELECTION_TOOL without the rest of kicad behind
> it.  Since I added methods which SELECTION_TOOL calls, I had to mock them
> in the test files.
>
> GENERAL_COLLECTOR::Modules[] can’t be used because the creator of the
> collector (SELECTION_TOOL) shouldn’t know anything about the semantics of
> the filter (only the specific action implementation knows that).  In the
> FootprintFilter case it’s simply enough that you’d nearly be willing to
> overlook that, but the other filters are more complicated and required
> things like ROUTER_TOOL knowledge, which definitely shouldn’t be leaking
> into SELECTION_TOOL.
>
> Cheers,
> Jeff.
>
>
> On 9 Jan 2018, at 19:26, Seth Hillbrand  wrote:
>
> Same here.  Same errors.  Yes, cmaked.
>
> I don't understand why you are changing the test_window link libraries in
> this patch.
>
> Also, why did you decide to write a "FootprintFilter" routine instead of
> using the GENERAL_COLLECTOR::Modules[]?
>
> -S
>
> 2018-01-09 11:05 GMT-08:00 Jeff Young :
>
>> Did you do a CMake?  There’s a change in the CMake files….
>>
>> > On 9 Jan 2018, at 18:59, kristoffer Ödmark <
>> kristofferodmar...@gmail.com> wrote:
>> >
>> > Hmm, cannot compile, get a lot of undefiner references. Even after
>> nuking the build dir.
>> >
>> >
>> > ../../common/libpcbcommon.a(class_pad.cpp.o): In function
>> `D_PAD::HitTest(EDA_RECT const&, bool, int) const':
>> > kicad/pcbnew/class_pad.cpp:982: undefined reference to
>> `TestPointInsidePolygon(wxPoint const*, int, wxPoint const&)'
>> > ../../common/libpcbcommon.a(class_zone.cpp.o): In function
>> `ZONE_CONTAINER::Hatch()':
>> > kicad/pcbnew/class_zone.cpp:1219: undefined reference to
>> `FindLineSegmentIntersection(double, double, int, int, int, int,
>> double*, double*, double*, double*, double*)'
>> > ../../common/libcommon.a(shape_poly_set.cpp.o): In function
>> `SHAPE_POLY_SET::convertToClipper(SHAPE_LINE_CHAIN const&, bool)':
>> > kicad/common/geometry/shape_poly_set.cpp:466: undefined reference to
>> `ClipperLib::Orientation(std::vector> std::allocator > const&)'
>> > kicad/common/geometry/shape_poly_set.cpp:467: undefined reference to
>> `ClipperLib::ReversePath(std::vector> std::allocator >&)'
>> > ../../common/libcommon.a(shape_poly_set.cpp.o): In function
>> `SHAPE_POLY_SET::booleanOp(ClipperLib::ClipType, SHAPE_POLY_SET const&,
>> SHAPE_POLY_SET::POLYGON_MODE)':
>> > kicad/common/geometry/shape_poly_set.cpp:489: undefined reference to
>> `ClipperLib::Clipper::Clipper(int)'
>> >
>> >
>> > On 2018-01-09 19:22, Wayne Stambaugh wrote:
>> >> Does the patch resolve your issue?
>> >>
>> >> On 1/9/2018 1:21 PM, kristoffer Ödmark wrote:
>> >>> Yes, I can reproduce this with very thick tracks!
>> >>>
>> >>>
>> >>> On 2018-01-09 16:55, Jeff Young wrote:
>>  Hi Kristoffer,
>> 
>>  That’s odd.  Did you try it with your mouse pointer directly over the
>>  corner?  (You may need a reasonably thick track for this to happen.
>>  Try something on the order of 2mm.)
>> 
>>  Without my change the selection disambiguation is run *before* we
>> know
>>  it’s a drag action on a simple corner, so the selection_tool thinks
>> it
>>  needs to know which of the two segments is to be selected.
>> 
>>  Cheers,
>>  Jeff.
>> 
>> 
>> > On 9 Jan 2018, at 15:37, Kristoffer Ödmark
>> >  wrote:
>> >
>> > If i understand him correctly that would only be when on a corner, I
>> > think it would be the desired behaviour.
>> >
>> > Although, when I try it on my build on my laptop, there is no
>> clarify
>> > selection menu popping up when trying do drag ( 'd' ) or such on
>> > corners. Not in opengl anywas. So I dont know.
>> >
>> > Application: kicad
>> > Version: (2017-12-30 revision b55eb0b5f)-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.12-1-MANJARO x86_64, 64 bit, Little endian,
>> wxGTK
>> > Build Info:
>> > wxWidgets: 3.0.3 (wchar_t,wx 

Re: [Kicad-developers] Libedit and Modedit Icons

[eldar.khayrullin]

Look at icons created with people already for 
impressionshttps://icons8.com/icon/free-pack/files/all
 Исходное сообщение От: Michael Kavanagh 
 Дата: 09.01.18  21:07  (GMT+03:00) Кому: 
kicad-developers@lists.launchpad.net Тема: Re: [Kicad-developers] Libedit and 
Modedit Icons 
Is there a reason why KiCad doesn't use the standard save icon, i.e. a floppy 
disk?I think basically every piece of software I have used has the floppy disk 
save icon and it might help with the arrow situation.
Cheers,Michael
On 9 January 2018 at 17:42, Wayne Stambaugh  wrote:
On 1/9/2018 12:05 PM, Rene Pöschl wrote:

> On 09/01/18 16:50, Wayne Stambaugh wrote:

>> I'm with Jose on the arrows.  If we are going to use them, please don't

>> make the all different colors.  I don't see how a blue left arrow versus

>> a magenta right arrow conveys any meaning to the user.

>>

>

> I like the idea of coloring them differently. For me this will give an

> additional way to distinguish the buttons. (Some of them have only the

> direction of the arrow as a difference. Which is easily overlooked.) I

> hope having different colors will make it easier for my brain to

> remember which button does what. (I can't tell you how often i clicked

> load symbol instead of update symbol while working on the reorganization

> of the official lib.)



What information does the different color arrow convey?  If you are

using different colors for contrast, that is one thing but just making

them different colors for informational purposes doesn't make any sense

to me.  If you are trying convey information with different color

buttons, what is the impact on users who are color blind.



>

> Maybe there is a better way to communicate differences but if buttons

> look as similar as a lot of them currently do, adding differentiating

> colors might help.

>

> ___

> 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] One more quick plug for reducing "Clarify Selection" dialogs

[Jeff Young]

Hi Seth,

The test_window creates a  SELECTION_TOOL without the rest of kicad behind it.  
Since I added methods which SELECTION_TOOL calls, I had to mock them in the 
test files.

GENERAL_COLLECTOR::Modules[] can’t be used because the creator of the collector 
(SELECTION_TOOL) shouldn’t know anything about the semantics of the filter 
(only the specific action implementation knows that).  In the FootprintFilter 
case it’s simply enough that you’d nearly be willing to overlook that, but the 
other filters are more complicated and required things like ROUTER_TOOL 
knowledge, which definitely shouldn’t be leaking into SELECTION_TOOL.

Cheers,
Jeff.


> On 9 Jan 2018, at 19:26, Seth Hillbrand  wrote:
> 
> Same here.  Same errors.  Yes, cmaked.
> 
> I don't understand why you are changing the test_window link libraries in 
> this patch.
> 
> Also, why did you decide to write a "FootprintFilter" routine instead of 
> using the GENERAL_COLLECTOR::Modules[]?
> 
> -S
> 
> 2018-01-09 11:05 GMT-08:00 Jeff Young  >:
> Did you do a CMake?  There’s a change in the CMake files….
> 
> > On 9 Jan 2018, at 18:59, kristoffer Ödmark  > > wrote:
> >
> > Hmm, cannot compile, get a lot of undefiner references. Even after nuking 
> > the build dir.
> >
> >
> > ../../common/libpcbcommon.a(class_pad.cpp.o): In function 
> > `D_PAD::HitTest(EDA_RECT const&, bool, int) const':
> > kicad/pcbnew/class_pad.cpp:982: undefined reference to 
> > `TestPointInsidePolygon(wxPoint const*, int, wxPoint const&)'
> > ../../common/libpcbcommon.a(class_zone.cpp.o): In function 
> > `ZONE_CONTAINER::Hatch()':
> > kicad/pcbnew/class_zone.cpp:1219: undefined reference to 
> > `FindLineSegmentIntersection(double, double, int, int, int, int, double*, 
> > double*, double*, double*, double*)'
> > ../../common/libcommon.a(shape_poly_set.cpp.o): In function 
> > `SHAPE_POLY_SET::convertToClipper(SHAPE_LINE_CHAIN const&, bool)':
> > kicad/common/geometry/shape_poly_set.cpp:466: undefined reference to 
> > `ClipperLib::Orientation(std::vector > std::allocator > const&)'
> > kicad/common/geometry/shape_poly_set.cpp:467: undefined reference to 
> > `ClipperLib::ReversePath(std::vector > std::allocator >&)'
> > ../../common/libcommon.a(shape_poly_set.cpp.o): In function 
> > `SHAPE_POLY_SET::booleanOp(ClipperLib::ClipType, SHAPE_POLY_SET const&, 
> > SHAPE_POLY_SET::POLYGON_MODE)':
> > kicad/common/geometry/shape_poly_set.cpp:489: undefined reference to 
> > `ClipperLib::Clipper::Clipper(int)'
> >
> >
> > On 2018-01-09 19:22, Wayne Stambaugh wrote:
> >> Does the patch resolve your issue?
> >>
> >> On 1/9/2018 1:21 PM, kristoffer Ödmark wrote:
> >>> Yes, I can reproduce this with very thick tracks!
> >>>
> >>>
> >>> On 2018-01-09 16:55, Jeff Young wrote:
>  Hi Kristoffer,
> 
>  That’s odd.  Did you try it with your mouse pointer directly over the
>  corner?  (You may need a reasonably thick track for this to happen.
>  Try something on the order of 2mm.)
> 
>  Without my change the selection disambiguation is run *before* we know
>  it’s a drag action on a simple corner, so the selection_tool thinks it
>  needs to know which of the two segments is to be selected.
> 
>  Cheers,
>  Jeff.
> 
> 
> > On 9 Jan 2018, at 15:37, Kristoffer Ödmark
> > mailto:kristofferodmar...@gmail.com>> 
> > wrote:
> >
> > If i understand him correctly that would only be when on a corner, I
> > think it would be the desired behaviour.
> >
> > Although, when I try it on my build on my laptop, there is no clarify
> > selection menu popping up when trying do drag ( 'd' ) or such on
> > corners. Not in opengl anywas. So I dont know.
> >
> > Application: kicad
> > Version: (2017-12-30 revision b55eb0b5f)-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.12-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.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=ON
> > BUILD_GITHUB_PLUGIN=ON
> > KICAD_USE_OCE=ON
> > KICAD_SPICE=ON
> >
> >
> > -Kristoffer
> >
> > On 01/09/2018 04:27 PM, 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 perso

[Kicad-developers] Daily build for KiCad on Ubuntu (ppa)

[Jean-Samuel Reynaud]

Hi all,

Launchpad build farm is currently disabled due to security issues (Meltdown
and Spectre) [1]. So for the moment new KiCad daily build are disabled.
Existing packages are still available but not new build...
Sorry for this (temporary) bad news.


[1] https://lists.ubuntu.com/archives/launchpad-announce/
2018-January/000103.html
___
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

[Seth Hillbrand]

Same here.  Same errors.  Yes, cmaked.

I don't understand why you are changing the test_window link libraries in
this patch.

Also, why did you decide to write a "FootprintFilter" routine instead of
using the GENERAL_COLLECTOR::Modules[]?

-S

2018-01-09 11:05 GMT-08:00 Jeff Young :

> Did you do a CMake?  There’s a change in the CMake files….
>
> > On 9 Jan 2018, at 18:59, kristoffer Ödmark 
> wrote:
> >
> > Hmm, cannot compile, get a lot of undefiner references. Even after
> nuking the build dir.
> >
> >
> > ../../common/libpcbcommon.a(class_pad.cpp.o): In function
> `D_PAD::HitTest(EDA_RECT const&, bool, int) const':
> > kicad/pcbnew/class_pad.cpp:982: undefined reference to
> `TestPointInsidePolygon(wxPoint const*, int, wxPoint const&)'
> > ../../common/libpcbcommon.a(class_zone.cpp.o): In function
> `ZONE_CONTAINER::Hatch()':
> > kicad/pcbnew/class_zone.cpp:1219: undefined reference to
> `FindLineSegmentIntersection(double, double, int, int, int, int, double*,
> double*, double*, double*, double*)'
> > ../../common/libcommon.a(shape_poly_set.cpp.o): In function
> `SHAPE_POLY_SET::convertToClipper(SHAPE_LINE_CHAIN const&, bool)':
> > kicad/common/geometry/shape_poly_set.cpp:466: undefined reference to
> `ClipperLib::Orientation(std::vector std::allocator > const&)'
> > kicad/common/geometry/shape_poly_set.cpp:467: undefined reference to
> `ClipperLib::ReversePath(std::vector std::allocator >&)'
> > ../../common/libcommon.a(shape_poly_set.cpp.o): In function
> `SHAPE_POLY_SET::booleanOp(ClipperLib::ClipType, SHAPE_POLY_SET const&,
> SHAPE_POLY_SET::POLYGON_MODE)':
> > kicad/common/geometry/shape_poly_set.cpp:489: undefined reference to
> `ClipperLib::Clipper::Clipper(int)'
> >
> >
> > On 2018-01-09 19:22, Wayne Stambaugh wrote:
> >> Does the patch resolve your issue?
> >>
> >> On 1/9/2018 1:21 PM, kristoffer Ödmark wrote:
> >>> Yes, I can reproduce this with very thick tracks!
> >>>
> >>>
> >>> On 2018-01-09 16:55, Jeff Young wrote:
>  Hi Kristoffer,
> 
>  That’s odd.  Did you try it with your mouse pointer directly over the
>  corner?  (You may need a reasonably thick track for this to happen.
>  Try something on the order of 2mm.)
> 
>  Without my change the selection disambiguation is run *before* we know
>  it’s a drag action on a simple corner, so the selection_tool thinks it
>  needs to know which of the two segments is to be selected.
> 
>  Cheers,
>  Jeff.
> 
> 
> > On 9 Jan 2018, at 15:37, Kristoffer Ödmark
> >  wrote:
> >
> > If i understand him correctly that would only be when on a corner, I
> > think it would be the desired behaviour.
> >
> > Although, when I try it on my build on my laptop, there is no clarify
> > selection menu popping up when trying do drag ( 'd' ) or such on
> > corners. Not in opengl anywas. So I dont know.
> >
> > Application: kicad
> > Version: (2017-12-30 revision b55eb0b5f)-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.12-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.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=ON
> > BUILD_GITHUB_PLUGIN=ON
> > KICAD_USE_OCE=ON
> > KICAD_SPICE=ON
> >
> >
> > -Kristoffer
> >
> > On 01/09/2018 04:27 PM, 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 serious

Re: [Kicad-developers] Libedit and Modedit Icons

[eldar.khayrullin]

I agree with Michael.And folder icon for Open/Load action and Blank list icon 
for Create new actions.Current icons very difficult to perception for me and I 
see tooltips periodically for simple operations open/new/save.
 Исходное сообщение От: Michael Kavanagh 
 Дата: 09.01.18  21:07  (GMT+03:00) Кому: 
kicad-developers@lists.launchpad.net Тема: Re: [Kicad-developers] Libedit and 
Modedit Icons 
Is there a reason why KiCad doesn't use the standard save icon, i.e. a floppy 
disk?I think basically every piece of software I have used has the floppy disk 
save icon and it might help with the arrow situation.
Cheers,Michael
On 9 January 2018 at 17:42, Wayne Stambaugh  wrote:
On 1/9/2018 12:05 PM, Rene Pöschl wrote:

> On 09/01/18 16:50, Wayne Stambaugh wrote:

>> I'm with Jose on the arrows.  If we are going to use them, please don't

>> make the all different colors.  I don't see how a blue left arrow versus

>> a magenta right arrow conveys any meaning to the user.

>>

>

> I like the idea of coloring them differently. For me this will give an

> additional way to distinguish the buttons. (Some of them have only the

> direction of the arrow as a difference. Which is easily overlooked.) I

> hope having different colors will make it easier for my brain to

> remember which button does what. (I can't tell you how often i clicked

> load symbol instead of update symbol while working on the reorganization

> of the official lib.)



What information does the different color arrow convey?  If you are

using different colors for contrast, that is one thing but just making

them different colors for informational purposes doesn't make any sense

to me.  If you are trying convey information with different color

buttons, what is the impact on users who are color blind.



>

> Maybe there is a better way to communicate differences but if buttons

> look as similar as a lot of them currently do, adding differentiating

> colors might help.

>

> ___

> 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] One more quick plug for reducing "Clarify Selection" dialogs

[Jeff Young]

Did you do a CMake?  There’s a change in the CMake files….

> On 9 Jan 2018, at 18:59, kristoffer Ödmark  
> wrote:
> 
> Hmm, cannot compile, get a lot of undefiner references. Even after nuking the 
> build dir.
> 
> 
> ../../common/libpcbcommon.a(class_pad.cpp.o): In function 
> `D_PAD::HitTest(EDA_RECT const&, bool, int) const':
> kicad/pcbnew/class_pad.cpp:982: undefined reference to 
> `TestPointInsidePolygon(wxPoint const*, int, wxPoint const&)'
> ../../common/libpcbcommon.a(class_zone.cpp.o): In function 
> `ZONE_CONTAINER::Hatch()':
> kicad/pcbnew/class_zone.cpp:1219: undefined reference to 
> `FindLineSegmentIntersection(double, double, int, int, int, int, double*, 
> double*, double*, double*, double*)'
> ../../common/libcommon.a(shape_poly_set.cpp.o): In function 
> `SHAPE_POLY_SET::convertToClipper(SHAPE_LINE_CHAIN const&, bool)':
> kicad/common/geometry/shape_poly_set.cpp:466: undefined reference to 
> `ClipperLib::Orientation(std::vector std::allocator > const&)'
> kicad/common/geometry/shape_poly_set.cpp:467: undefined reference to 
> `ClipperLib::ReversePath(std::vector std::allocator >&)'
> ../../common/libcommon.a(shape_poly_set.cpp.o): In function 
> `SHAPE_POLY_SET::booleanOp(ClipperLib::ClipType, SHAPE_POLY_SET const&, 
> SHAPE_POLY_SET::POLYGON_MODE)':
> kicad/common/geometry/shape_poly_set.cpp:489: undefined reference to 
> `ClipperLib::Clipper::Clipper(int)'
> 
> 
> On 2018-01-09 19:22, Wayne Stambaugh wrote:
>> Does the patch resolve your issue?
>> 
>> On 1/9/2018 1:21 PM, kristoffer Ödmark wrote:
>>> Yes, I can reproduce this with very thick tracks!
>>> 
>>> 
>>> On 2018-01-09 16:55, Jeff Young wrote:
 Hi Kristoffer,
 
 That’s odd.  Did you try it with your mouse pointer directly over the
 corner?  (You may need a reasonably thick track for this to happen.
 Try something on the order of 2mm.)
 
 Without my change the selection disambiguation is run *before* we know
 it’s a drag action on a simple corner, so the selection_tool thinks it
 needs to know which of the two segments is to be selected.
 
 Cheers,
 Jeff.
 
 
> On 9 Jan 2018, at 15:37, Kristoffer Ödmark
>  wrote:
> 
> If i understand him correctly that would only be when on a corner, I
> think it would be the desired behaviour.
> 
> Although, when I try it on my build on my laptop, there is no clarify
> selection menu popping up when trying do drag ( 'd' ) or such on
> corners. Not in opengl anywas. So I dont know.
> 
> Application: kicad
> Version: (2017-12-30 revision b55eb0b5f)-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.12-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.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=ON
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCE=ON
> KICAD_SPICE=ON
> 
> 
> -Kristoffer
> 
> On 01/09/2018 04:27 PM, 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
>>> _

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

[kristoffer Ödmark]

Hmm, cannot compile, get a lot of undefiner references. Even after 
nuking the build dir.



../../common/libpcbcommon.a(class_pad.cpp.o): In function 
`D_PAD::HitTest(EDA_RECT const&, bool, int) const':
kicad/pcbnew/class_pad.cpp:982: undefined reference to 
`TestPointInsidePolygon(wxPoint const*, int, wxPoint const&)'
../../common/libpcbcommon.a(class_zone.cpp.o): In function 
`ZONE_CONTAINER::Hatch()':
kicad/pcbnew/class_zone.cpp:1219: undefined reference to 
`FindLineSegmentIntersection(double, double, int, int, int, int, 
double*, double*, double*, double*, double*)'
../../common/libcommon.a(shape_poly_set.cpp.o): In function 
`SHAPE_POLY_SET::convertToClipper(SHAPE_LINE_CHAIN const&, bool)':
kicad/common/geometry/shape_poly_set.cpp:466: undefined reference to 
`ClipperLib::Orientation(std::vectorstd::allocator > const&)'
kicad/common/geometry/shape_poly_set.cpp:467: undefined reference to 
`ClipperLib::ReversePath(std::vectorstd::allocator >&)'
../../common/libcommon.a(shape_poly_set.cpp.o): In function 
`SHAPE_POLY_SET::booleanOp(ClipperLib::ClipType, SHAPE_POLY_SET const&, 
SHAPE_POLY_SET::POLYGON_MODE)':
kicad/common/geometry/shape_poly_set.cpp:489: undefined reference to 
`ClipperLib::Clipper::Clipper(int)'



On 2018-01-09 19:22, Wayne Stambaugh wrote:

Does the patch resolve your issue?

On 1/9/2018 1:21 PM, kristoffer Ödmark wrote:

Yes, I can reproduce this with very thick tracks!


On 2018-01-09 16:55, Jeff Young wrote:

Hi Kristoffer,

That’s odd.  Did you try it with your mouse pointer directly over the
corner?  (You may need a reasonably thick track for this to happen.
Try something on the order of 2mm.)

Without my change the selection disambiguation is run *before* we know
it’s a drag action on a simple corner, so the selection_tool thinks it
needs to know which of the two segments is to be selected.

Cheers,
Jeff.



On 9 Jan 2018, at 15:37, Kristoffer Ödmark
 wrote:

If i understand him correctly that would only be when on a corner, I
think it would be the desired behaviour.

Although, when I try it on my build on my laptop, there is no clarify
selection menu popping up when trying do drag ( 'd' ) or such on
corners. Not in opengl anywas. So I dont know.

Application: kicad
Version: (2017-12-30 revision b55eb0b5f)-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.12-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.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=ON
     BUILD_GITHUB_PLUGIN=ON
     KICAD_USE_OCE=ON
     KICAD_SPICE=ON


-Kristoffer

On 01/09/2018 04:27 PM, 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
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 

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

[kristoffer Ödmark]

I just about to try :) hang on, got some merge conflicts on some local stuff


On 2018-01-09 19:22, Wayne Stambaugh wrote:

Does the patch resolve your issue?

On 1/9/2018 1:21 PM, kristoffer Ödmark wrote:

Yes, I can reproduce this with very thick tracks!


On 2018-01-09 16:55, Jeff Young wrote:

Hi Kristoffer,

That’s odd.  Did you try it with your mouse pointer directly over the
corner?  (You may need a reasonably thick track for this to happen.
Try something on the order of 2mm.)

Without my change the selection disambiguation is run *before* we know
it’s a drag action on a simple corner, so the selection_tool thinks it
needs to know which of the two segments is to be selected.

Cheers,
Jeff.



On 9 Jan 2018, at 15:37, Kristoffer Ödmark
 wrote:

If i understand him correctly that would only be when on a corner, I
think it would be the desired behaviour.

Although, when I try it on my build on my laptop, there is no clarify
selection menu popping up when trying do drag ( 'd' ) or such on
corners. Not in opengl anywas. So I dont know.

Application: kicad
Version: (2017-12-30 revision b55eb0b5f)-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.12-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.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=ON
     BUILD_GITHUB_PLUGIN=ON
     KICAD_USE_OCE=ON
     KICAD_SPICE=ON


-Kristoffer

On 01/09/2018 04:27 PM, 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
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

___
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] One more quick plug for reducing "Clarify Selection" dialogs

[Wayne Stambaugh]

Does the patch resolve your issue?

On 1/9/2018 1:21 PM, kristoffer Ödmark wrote:
> Yes, I can reproduce this with very thick tracks!
> 
> 
> On 2018-01-09 16:55, Jeff Young wrote:
>> Hi Kristoffer,
>>
>> That’s odd.  Did you try it with your mouse pointer directly over the
>> corner?  (You may need a reasonably thick track for this to happen. 
>> Try something on the order of 2mm.)
>>
>> Without my change the selection disambiguation is run *before* we know
>> it’s a drag action on a simple corner, so the selection_tool thinks it
>> needs to know which of the two segments is to be selected.
>>
>> Cheers,
>> Jeff.
>>
>>
>>> On 9 Jan 2018, at 15:37, Kristoffer Ödmark
>>>  wrote:
>>>
>>> If i understand him correctly that would only be when on a corner, I
>>> think it would be the desired behaviour.
>>>
>>> Although, when I try it on my build on my laptop, there is no clarify
>>> selection menu popping up when trying do drag ( 'd' ) or such on
>>> corners. Not in opengl anywas. So I dont know.
>>>
>>> Application: kicad
>>> Version: (2017-12-30 revision b55eb0b5f)-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.12-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.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=ON
>>>     BUILD_GITHUB_PLUGIN=ON
>>>     KICAD_USE_OCE=ON
>>>     KICAD_SPICE=ON
>>>
>>>
>>> -Kristoffer
>>>
>>> On 01/09/2018 04:27 PM, 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
 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

___
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

[kristoffer Ödmark]

Yes, I can reproduce this with very thick tracks!


On 2018-01-09 16:55, Jeff Young wrote:

Hi Kristoffer,

That’s odd.  Did you try it with your mouse pointer directly over the corner?  
(You may need a reasonably thick track for this to happen.  Try something on 
the order of 2mm.)

Without my change the selection disambiguation is run *before* we know it’s a 
drag action on a simple corner, so the selection_tool thinks it needs to know 
which of the two segments is to be selected.

Cheers,
Jeff.



On 9 Jan 2018, at 15:37, Kristoffer Ödmark  wrote:

If i understand him correctly that would only be when on a corner, I think it 
would be the desired behaviour.

Although, when I try it on my build on my laptop, there is no clarify selection 
menu popping up when trying do drag ( 'd' ) or such on corners. Not in opengl 
anywas. So I dont know.

Application: kicad
Version: (2017-12-30 revision b55eb0b5f)-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.12-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.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=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_SPICE=ON


-Kristoffer

On 01/09/2018 04:27 PM, 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
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] Renaming headers?

[Chris Pavlina]

Yeah, most "real IDEs" have no problem jumping through source. I break
out CLion when I need to do battle with the KiCad spaghetti. We
shouldn't _have_ to, though.

On Tue, Jan 09, 2018 at 11:13:08AM -0700, Andy Peters wrote:
> 
> > On Jan 9, 2018, at 10:37 AM, Chris Pavlina  wrote:
> > 
> > There's a plugin for vim called CtrlP that implements fuzzy matching on
> > filenames too, which I use. Still, not even fuzzy matching will tell you
> > PCB_EDIT_FRAME is in wxPcbStruct.h.
> 
> Not that I advocate for its use, Eclipse has its right-click-accessed context 
> menu which includes “Open Declaration.” Select a thing in your source, right 
> click, choose that, and blammo, the relevant file opens and your mouse goes 
> to the declaration of that thing.
> 
> -a
> ___
> 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] Renaming headers?

[Andy Peters]

> On Jan 9, 2018, at 10:37 AM, Chris Pavlina  wrote:
> 
> There's a plugin for vim called CtrlP that implements fuzzy matching on
> filenames too, which I use. Still, not even fuzzy matching will tell you
> PCB_EDIT_FRAME is in wxPcbStruct.h.

Not that I advocate for its use, Eclipse has its right-click-accessed context 
menu which includes “Open Declaration.” Select a thing in your source, right 
click, choose that, and blammo, the relevant file opens and your mouse goes to 
the declaration of that thing.

-a
___
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

[Michael Kavanagh]

Is there a reason why KiCad doesn't use the standard save icon, i.e. a
floppy disk?
I think basically every piece of software I have used has the floppy disk
save icon and it might help with the arrow situation.

Cheers,
Michael

On 9 January 2018 at 17:42, Wayne Stambaugh  wrote:

> On 1/9/2018 12:05 PM, Rene Pöschl wrote:
> > On 09/01/18 16:50, Wayne Stambaugh wrote:
> >> I'm with Jose on the arrows.  If we are going to use them, please don't
> >> make the all different colors.  I don't see how a blue left arrow versus
> >> a magenta right arrow conveys any meaning to the user.
> >>
> >
> > I like the idea of coloring them differently. For me this will give an
> > additional way to distinguish the buttons. (Some of them have only the
> > direction of the arrow as a difference. Which is easily overlooked.) I
> > hope having different colors will make it easier for my brain to
> > remember which button does what. (I can't tell you how often i clicked
> > load symbol instead of update symbol while working on the reorganization
> > of the official lib.)
>
> What information does the different color arrow convey?  If you are
> using different colors for contrast, that is one thing but just making
> them different colors for informational purposes doesn't make any sense
> to me.  If you are trying convey information with different color
> buttons, what is the impact on users who are color blind.
>
> >
> > Maybe there is a better way to communicate differences but if buttons
> > look as similar as a lot of them currently do, adding differentiating
> > colors might help.
> >
> > ___
> > 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] Kicad from scratch: pcbnew: cannot use ~/ for home directory for KISYS3DMOD path?

[Jörg Hermann]

Is this behaviour somehow related to 
https://bugs.launchpad.net/kicad/+bug/1677545

> On 9. Jan 2018, at 15:38, Nick Østergaard  wrote:
> 
> If you really want to start from scratch then you may also want to remove the 
> ~/.cache/kicad  (or there about, I am not on linux right now). But it is not 
> as important, it only contains the scene graph model cache. (Or what ever it 
> is really called)
> 
> 2018-01-09 14:55 GMT+01:00 Clemens Koller  >:
> Hi!
> 
> I am testing latest-git on Linux, collecting some UX issues when starting 
> Kicad from scratch (*):
> 
> On a new installation, I cannot execute 3D Shape Downloader out of the box. 
> KISYS3DMOD points to ~/SW/share/kicad/modules/packages3d after installation 
> to ~/SW/share/kicad/bin.
> 
> This folder doesn't exist yet at this point, but could be created by Kicad.
> (The behaviour is still the same even when 
> ~/SW/share/kicad/modules/packages3d was created in advance.)
> 
> The 3D Shape Downloader then tells me:
> "It's not possible to write in the selected directory. Please choose anothe 
> one."
> 
> When I press "Default 3D Path", I would expect that it resets the path to a 
> default working one,
> but an message tells me that "KISYS3DMOD path not defined , or not existing".
> 
> Anyway it's possible to hit the Next-> button just to realize than after an 
> hour of downloading, the download is going to fail -> Duh!
> When I replace the ~/ with /home/admin/ everything seems to work.
> Is there a reason that the ~ cannot be used from within Kicad?
> 
> Regards,
> 
> Clemens
> 
> (*) Kicad rebuilt from src and started from scratch after rm ~/.config/kicad
> 
> 
> ---
> Application: kicad
> Version: (2018-01-08  revision 0e9c8a423)-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.12-1-ARCH 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

___
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

[Bernhard Stegmaier]

I know… I just wanted to check that it is still OK after your patch.
Jeff already did, so everything fine.

> On 9. Jan 2018, at 18:28, Chris Pavlina  wrote:
> 
> OSX/macOS has built-in scaling for those, other operating systems don't.
> 
> On Tue, Jan 09, 2018 at 02:40:20PM +0100, Bernhard Stegmaier wrote:
>> Hi Chris,
>> 
>> can you show a screenshot what this patch fixes?
>> I have a Retina MacBook and for my taste the toolbar icons are pretty OK 
>> without any patch…
>> 
>> 
>> Regards,
>> Bernhard
>> 
>>> On 9. Jan 2018, at 14:27, Maciej Sumiński  wrote:
>>> 
>>> Hi Chris,
>>> 
>>> The patch does not apply cleanly on the current master, would you rebase
>>> it? Thanks in advance.
>>> 
>>> Cheers,
>>> Orson
>>> 
>>> On 01/09/2018 03:43 AM, Chris Pavlina wrote:
 Hi,
 
 As discussed with Wayne earlier, I've attached a patch which adds simple
 toolbar icon scaling so the toolbars are readable on high-DPI systems.
 
 This is meant as a stopgap for 5.0, with plans to add proper scaled
 icons in the 6.0 cycle. A function KiScaledBitmap() is added, which
 works like KiBitmap() except it scales the bitmap according to the
 calling window's font size. Controls have been added to all the main
 applications to let the user select scaling manually (these were omitted
 from smaller apps that didn't already have a place to put them).
 
 In addition, in eeschema only, the pixel height of the system font is
 shown in the options dialog for diagnostics. This is only for collecting
 feedback before 5.0 release from users with different displays and will
 be removed.
 
 I would like to push this fairly soon, as I want to get as much user
 feedback as possible before release. I have a limited number of systems
 to test this on myself.
 
 
 
 ___
 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] Renaming headers?

[Wayne Stambaugh]

Still waiting for crystal ball matching. :)

On 1/9/2018 12:37 PM, Chris Pavlina wrote:
> There's a plugin for vim called CtrlP that implements fuzzy matching on
> filenames too, which I use. Still, not even fuzzy matching will tell you
> PCB_EDIT_FRAME is in wxPcbStruct.h.
> 
> On Tue, Jan 09, 2018 at 11:39:13AM -0500, Jon Evans wrote:
>> This is a tangent, but for ease of finding files, I highly recommend using
>> a fuzzy matcher so that you can type any part of a filename instead of
>> having to remember how it starts.
>>
>> (This is how Sublime Text works if you use Ctrl+P to open a file)
>>
>> FZF is a great tool for this that can integrate with bash shell:
>> https://github.com/junegunn/fzf
>>
>> If you install it, you can be anywhere on a bash command line and type
>> Ctrl+T (by default) to get fuzzy searching of the current directory and
>> subdirectories.
>>
>>
>>
>> On Tue, Jan 9, 2018 at 11:30 AM, Kristoffer Ödmark <
>> kristofferodmar...@gmail.com> wrote:
>>
>>> Now that you say it, indeed the class prefix is kinda stupid, but at least
>>> it helps when doing ls, since they are grouped in one place, whatever the
>>> name after class_ :)
>>>
>>> Sorting them by function would be the best i guess, I would suggest that
>>> the commit(s) that is exactly where rc1 branches off be the one with these
>>> changes, since there will be major confusion with patches otherwise.
>>>
>>> I would lend support here, but I doubt I would be much help. But I would
>>> very much like to see a sorting/renaming etc here, I think it would help in
>>> attracting new devs as well, I remember getting stuck on the Legacy/GAL
>>> stuff in the very beginning, not finding what was where.
>>>
>>>  -Kristoffer
>>>
>>>
>>> On 01/09/2018 05:02 PM, Tomasz Wlostowski wrote:
>>>
 On 09/01/18 16:21, Kristoffer Ödmark wrote:

> Oh I was not planning on doing this, I am way to new to do a good job of
> sorting the codebase. Just wanted to see if there have been anyone else
> thinking in these lines. Currently in the pcbnew folder, the files seems
> to be grouped by their names, which is also fine. I would just enjoy if
> the files where grouped into folders more. there are currently 200+
> files in the pcbnew root directory.
>
> For example:
>  9 files starting with specctra
>  47 files starting with class
>  29 files starting with pcb
>
>
 Hey,

 I would vote for moving the files into folders grouped by functionality.
 For example:
 - board/ - board model (class_board, track, via, etc) + core algorithms
 (zone filling, connectivity, ratsnest)
 - io/ - all I/O plugins and exporters (in separate subdirectories) +
 plugin management code
 - io/kicad - kicad plugin
 - io/legacy - legacy plgugin
 - io/exporters/specctra - specctra export code
 - io/importers/eagle - eagle import code
 - view/ - GAL display code
 - tools/ - all GAL tools
 - legacy/ - all legacy tools/canvas code
 - ui/ - wx-specific user interface stuff (dialogs, frames, etc.).

 If we go for separate subfolders, I'd also suggest removing the class_
 prefixes from the file names. All of the new code is OOP, so each source
 file contains a class (or more).

 In the long term, we could also eliminate linking dependencies between
 these folders (so that class BOARD has no dependency on the GUI, etc).

 Cheers,
 Tom


>>> ___
>>> 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

[Wayne Stambaugh]

On 1/9/2018 12:05 PM, Rene Pöschl wrote:
> On 09/01/18 16:50, Wayne Stambaugh wrote:
>> I'm with Jose on the arrows.  If we are going to use them, please don't
>> make the all different colors.  I don't see how a blue left arrow versus
>> a magenta right arrow conveys any meaning to the user.
>>
> 
> I like the idea of coloring them differently. For me this will give an
> additional way to distinguish the buttons. (Some of them have only the
> direction of the arrow as a difference. Which is easily overlooked.) I
> hope having different colors will make it easier for my brain to
> remember which button does what. (I can't tell you how often i clicked
> load symbol instead of update symbol while working on the reorganization
> of the official lib.)

What information does the different color arrow convey?  If you are
using different colors for contrast, that is one thing but just making
them different colors for informational purposes doesn't make any sense
to me.  If you are trying convey information with different color
buttons, what is the impact on users who are color blind.

> 
> Maybe there is a better way to communicate differences but if buttons
> look as similar as a lot of them currently do, adding differentiating
> colors might help.
> 
> ___
> 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] Renaming headers?

[Chris Pavlina]

There's a plugin for vim called CtrlP that implements fuzzy matching on
filenames too, which I use. Still, not even fuzzy matching will tell you
PCB_EDIT_FRAME is in wxPcbStruct.h.

On Tue, Jan 09, 2018 at 11:39:13AM -0500, Jon Evans wrote:
> This is a tangent, but for ease of finding files, I highly recommend using
> a fuzzy matcher so that you can type any part of a filename instead of
> having to remember how it starts.
> 
> (This is how Sublime Text works if you use Ctrl+P to open a file)
> 
> FZF is a great tool for this that can integrate with bash shell:
> https://github.com/junegunn/fzf
> 
> If you install it, you can be anywhere on a bash command line and type
> Ctrl+T (by default) to get fuzzy searching of the current directory and
> subdirectories.
> 
> 
> 
> On Tue, Jan 9, 2018 at 11:30 AM, Kristoffer Ödmark <
> kristofferodmar...@gmail.com> wrote:
> 
> > Now that you say it, indeed the class prefix is kinda stupid, but at least
> > it helps when doing ls, since they are grouped in one place, whatever the
> > name after class_ :)
> >
> > Sorting them by function would be the best i guess, I would suggest that
> > the commit(s) that is exactly where rc1 branches off be the one with these
> > changes, since there will be major confusion with patches otherwise.
> >
> > I would lend support here, but I doubt I would be much help. But I would
> > very much like to see a sorting/renaming etc here, I think it would help in
> > attracting new devs as well, I remember getting stuck on the Legacy/GAL
> > stuff in the very beginning, not finding what was where.
> >
> >  -Kristoffer
> >
> >
> > On 01/09/2018 05:02 PM, Tomasz Wlostowski wrote:
> >
> >> On 09/01/18 16:21, Kristoffer Ödmark wrote:
> >>
> >>> Oh I was not planning on doing this, I am way to new to do a good job of
> >>> sorting the codebase. Just wanted to see if there have been anyone else
> >>> thinking in these lines. Currently in the pcbnew folder, the files seems
> >>> to be grouped by their names, which is also fine. I would just enjoy if
> >>> the files where grouped into folders more. there are currently 200+
> >>> files in the pcbnew root directory.
> >>>
> >>> For example:
> >>>  9 files starting with specctra
> >>>  47 files starting with class
> >>>  29 files starting with pcb
> >>>
> >>>
> >> Hey,
> >>
> >> I would vote for moving the files into folders grouped by functionality.
> >> For example:
> >> - board/ - board model (class_board, track, via, etc) + core algorithms
> >> (zone filling, connectivity, ratsnest)
> >> - io/ - all I/O plugins and exporters (in separate subdirectories) +
> >> plugin management code
> >> - io/kicad - kicad plugin
> >> - io/legacy - legacy plgugin
> >> - io/exporters/specctra - specctra export code
> >> - io/importers/eagle - eagle import code
> >> - view/ - GAL display code
> >> - tools/ - all GAL tools
> >> - legacy/ - all legacy tools/canvas code
> >> - ui/ - wx-specific user interface stuff (dialogs, frames, etc.).
> >>
> >> If we go for separate subfolders, I'd also suggest removing the class_
> >> prefixes from the file names. All of the new code is OOP, so each source
> >> file contains a class (or more).
> >>
> >> In the long term, we could also eliminate linking dependencies between
> >> these folders (so that class BOARD has no dependency on the GUI, etc).
> >>
> >> Cheers,
> >> Tom
> >>
> >>
> > ___
> > 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] One more quick plug for reducing "Clarify Selection" dialogs

[Jeff Young]

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 
>>> 
>>> >> >
>>> 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]

It applies cleanly on 87cc3ea44 if you want to test, I won't have a
chance to rebase it until tomorrow most likely. Looks like a lot of
changes.

On Tue, Jan 09, 2018 at 02:27:16PM +0100, Maciej Sumiński wrote:
> Hi Chris,
> 
> The patch does not apply cleanly on the current master, would you rebase
> it? Thanks in advance.
> 
> Cheers,
> Orson
> 
> On 01/09/2018 03:43 AM, Chris Pavlina wrote:
> > Hi,
> > 
> > As discussed with Wayne earlier, I've attached a patch which adds simple
> > toolbar icon scaling so the toolbars are readable on high-DPI systems.
> > 
> > This is meant as a stopgap for 5.0, with plans to add proper scaled
> > icons in the 6.0 cycle. A function KiScaledBitmap() is added, which
> > works like KiBitmap() except it scales the bitmap according to the
> > calling window's font size. Controls have been added to all the main
> > applications to let the user select scaling manually (these were omitted
> > from smaller apps that didn't already have a place to put them).
> > 
> > In addition, in eeschema only, the pixel height of the system font is
> > shown in the options dialog for diagnostics. This is only for collecting
> > feedback before 5.0 release from users with different displays and will
> > be removed.
> > 
> > I would like to push this fairly soon, as I want to get as much user
> > feedback as possible before release. I have a limited number of systems
> > to test this on myself.
> > 
> > 
> > 
> > ___
> > 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]

OSX/macOS has built-in scaling for those, other operating systems don't.

On Tue, Jan 09, 2018 at 02:40:20PM +0100, Bernhard Stegmaier wrote:
> Hi Chris,
> 
> can you show a screenshot what this patch fixes?
> I have a Retina MacBook and for my taste the toolbar icons are pretty OK 
> without any patch…
> 
> 
> Regards,
> Bernhard
> 
> > On 9. Jan 2018, at 14:27, Maciej Sumiński  wrote:
> > 
> > Hi Chris,
> > 
> > The patch does not apply cleanly on the current master, would you rebase
> > it? Thanks in advance.
> > 
> > Cheers,
> > Orson
> > 
> > On 01/09/2018 03:43 AM, Chris Pavlina wrote:
> >> Hi,
> >> 
> >> As discussed with Wayne earlier, I've attached a patch which adds simple
> >> toolbar icon scaling so the toolbars are readable on high-DPI systems.
> >> 
> >> This is meant as a stopgap for 5.0, with plans to add proper scaled
> >> icons in the 6.0 cycle. A function KiScaledBitmap() is added, which
> >> works like KiBitmap() except it scales the bitmap according to the
> >> calling window's font size. Controls have been added to all the main
> >> applications to let the user select scaling manually (these were omitted
> >> from smaller apps that didn't already have a place to put them).
> >> 
> >> In addition, in eeschema only, the pixel height of the system font is
> >> shown in the options dialog for diagnostics. This is only for collecting
> >> feedback before 5.0 release from users with different displays and will
> >> be removed.
> >> 
> >> I would like to push this fairly soon, as I want to get as much user
> >> feedback as possible before release. I have a limited number of systems
> >> to test this on myself.
> >> 
> >> 
> >> 
> >> ___
> >> 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] Libedit and Modedit Icons

[Kevin Cozens]

On 2018-01-09 12:05 PM, Rene Pöschl wrote:
(I can't tell you how often i clicked load symbol instead 
of update symbol while working on the reorganization of the official lib.)


Pop up tooltips when the mouse is over the icons can also help with that 
problem.


--
Cheers!

Kevin.

http://www.ve3syb.ca/   |"Nerds make the shiny things that distract
Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
| powerful!"
#include  | --Chris Hardwick

___
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

[Rene Pöschl]

On 09/01/18 16:50, Wayne Stambaugh wrote:

I'm with Jose on the arrows.  If we are going to use them, please don't
make the all different colors.  I don't see how a blue left arrow versus
a magenta right arrow conveys any meaning to the user.



I like the idea of coloring them differently. For me this will give an 
additional way to distinguish the buttons. (Some of them have only the 
direction of the arrow as a difference. Which is easily overlooked.) I 
hope having different colors will make it easier for my brain to 
remember which button does what. (I can't tell you how often i clicked 
load symbol instead of update symbol while working on the reorganization 
of the official lib.)


Maybe there is a better way to communicate differences but if buttons 
look as similar as a lot of them currently do, adding differentiating 
colors might help.


___
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] Renaming headers?

[Jon Evans]

This is a tangent, but for ease of finding files, I highly recommend using
a fuzzy matcher so that you can type any part of a filename instead of
having to remember how it starts.

(This is how Sublime Text works if you use Ctrl+P to open a file)

FZF is a great tool for this that can integrate with bash shell:
https://github.com/junegunn/fzf

If you install it, you can be anywhere on a bash command line and type
Ctrl+T (by default) to get fuzzy searching of the current directory and
subdirectories.



On Tue, Jan 9, 2018 at 11:30 AM, Kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> Now that you say it, indeed the class prefix is kinda stupid, but at least
> it helps when doing ls, since they are grouped in one place, whatever the
> name after class_ :)
>
> Sorting them by function would be the best i guess, I would suggest that
> the commit(s) that is exactly where rc1 branches off be the one with these
> changes, since there will be major confusion with patches otherwise.
>
> I would lend support here, but I doubt I would be much help. But I would
> very much like to see a sorting/renaming etc here, I think it would help in
> attracting new devs as well, I remember getting stuck on the Legacy/GAL
> stuff in the very beginning, not finding what was where.
>
>  -Kristoffer
>
>
> On 01/09/2018 05:02 PM, Tomasz Wlostowski wrote:
>
>> On 09/01/18 16:21, Kristoffer Ödmark wrote:
>>
>>> Oh I was not planning on doing this, I am way to new to do a good job of
>>> sorting the codebase. Just wanted to see if there have been anyone else
>>> thinking in these lines. Currently in the pcbnew folder, the files seems
>>> to be grouped by their names, which is also fine. I would just enjoy if
>>> the files where grouped into folders more. there are currently 200+
>>> files in the pcbnew root directory.
>>>
>>> For example:
>>>  9 files starting with specctra
>>>  47 files starting with class
>>>  29 files starting with pcb
>>>
>>>
>> Hey,
>>
>> I would vote for moving the files into folders grouped by functionality.
>> For example:
>> - board/ - board model (class_board, track, via, etc) + core algorithms
>> (zone filling, connectivity, ratsnest)
>> - io/ - all I/O plugins and exporters (in separate subdirectories) +
>> plugin management code
>> - io/kicad - kicad plugin
>> - io/legacy - legacy plgugin
>> - io/exporters/specctra - specctra export code
>> - io/importers/eagle - eagle import code
>> - view/ - GAL display code
>> - tools/ - all GAL tools
>> - legacy/ - all legacy tools/canvas code
>> - ui/ - wx-specific user interface stuff (dialogs, frames, etc.).
>>
>> If we go for separate subfolders, I'd also suggest removing the class_
>> prefixes from the file names. All of the new code is OOP, so each source
>> file contains a class (or more).
>>
>> In the long term, we could also eliminate linking dependencies between
>> these folders (so that class BOARD has no dependency on the GUI, etc).
>>
>> Cheers,
>> Tom
>>
>>
> ___
> 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] Renaming headers?

[Kristoffer Ödmark]

Now that you say it, indeed the class prefix is kinda stupid, but at 
least it helps when doing ls, since they are grouped in one place, 
whatever the name after class_ :)


Sorting them by function would be the best i guess, I would suggest that 
the commit(s) that is exactly where rc1 branches off be the one with 
these changes, since there will be major confusion with patches otherwise.


I would lend support here, but I doubt I would be much help. But I would 
very much like to see a sorting/renaming etc here, I think it would help 
in attracting new devs as well, I remember getting stuck on the 
Legacy/GAL stuff in the very beginning, not finding what was where.


 -Kristoffer

On 01/09/2018 05:02 PM, Tomasz Wlostowski wrote:

On 09/01/18 16:21, Kristoffer Ödmark wrote:

Oh I was not planning on doing this, I am way to new to do a good job of
sorting the codebase. Just wanted to see if there have been anyone else
thinking in these lines. Currently in the pcbnew folder, the files seems
to be grouped by their names, which is also fine. I would just enjoy if
the files where grouped into folders more. there are currently 200+
files in the pcbnew root directory.

For example:
 9 files starting with specctra
 47 files starting with class
 29 files starting with pcb



Hey,

I would vote for moving the files into folders grouped by functionality.
For example:
- board/ - board model (class_board, track, via, etc) + core algorithms
(zone filling, connectivity, ratsnest)
- io/ - all I/O plugins and exporters (in separate subdirectories) +
plugin management code
- io/kicad - kicad plugin
- io/legacy - legacy plgugin
- io/exporters/specctra - specctra export code
- io/importers/eagle - eagle import code
- view/ - GAL display code
- tools/ - all GAL tools
- legacy/ - all legacy tools/canvas code
- ui/ - wx-specific user interface stuff (dialogs, frames, etc.).

If we go for separate subfolders, I'd also suggest removing the class_
prefixes from the file names. All of the new code is OOP, so each source
file contains a class (or more).

In the long term, we could also eliminate linking dependencies between
these folders (so that class BOARD has no dependency on the GUI, etc).

Cheers,
Tom



___
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] Renaming headers?

[Wayne Stambaugh]

On 1/9/2018 11:02 AM, Tomasz Wlostowski wrote:
> On 09/01/18 16:21, Kristoffer Ödmark wrote:
>> Oh I was not planning on doing this, I am way to new to do a good job of
>> sorting the codebase. Just wanted to see if there have been anyone else
>> thinking in these lines. Currently in the pcbnew folder, the files seems
>> to be grouped by their names, which is also fine. I would just enjoy if
>> the files where grouped into folders more. there are currently 200+
>> files in the pcbnew root directory.
>>
>> For example:
>> 9 files starting with specctra
>> 47 files starting with class
>> 29 files starting with pcb
>>
> 
> Hey,
> 
> I would vote for moving the files into folders grouped by functionality.
> For example:
> - board/ - board model (class_board, track, via, etc) + core algorithms
> (zone filling, connectivity, ratsnest)
> - io/ - all I/O plugins and exporters (in separate subdirectories) +
> plugin management code
> - io/kicad - kicad plugin
> - io/legacy - legacy plgugin
> - io/exporters/specctra - specctra export code
> - io/importers/eagle - eagle import code

I don't know that we need to be this fined grain.  I would rather not
have a folder with two files in it.

> - view/ - GAL display code
> - tools/ - all GAL tools
> - legacy/ - all legacy tools/canvas code
> - ui/ - wx-specific user interface stuff (dialogs, frames, etc.).

Separating legacy/ from ui/ would be almost impossible give how
intertwined they are.  I would just leave them in the root pcbnew/
folder for the time being and move them once the legacy canvas code has
been removed.

> 
> If we go for separate subfolders, I'd also suggest removing the class_
> prefixes from the file names. All of the new code is OOP, so each source
> file contains a class (or more).
> 
> In the long term, we could also eliminate linking dependencies between
> these folders (so that class BOARD has no dependency on the GUI, etc).
> 
> Cheers,
> Tom
> 
> ___
> 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] One more quick plug for reducing "Clarify Selection" dialogs

[Wayne Stambaugh]

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
>> 
>> 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] Renaming headers?

[Tomasz Wlostowski]

On 09/01/18 16:57, Wayne Stambaugh wrote:
> Prefixing files with class_ was a choice that I do not like and have
> never done.  It make searching file names a pain.  If I want to use the
> bash auto complete feature I have to type class_ just get the point
> where I can start to differentiate the rest of the file name.  Given the
> almost every header file in kicad has a class declaration, prefixing the
> file name with class does not add anything useful.  Please don't prefix
> file names with class_ and use a descriptive but not obnoxiously long
> file name when creating new source files.

I can't agree more :)

T.

___
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] Renaming headers?

[Tomasz Wlostowski]

On 09/01/18 16:21, Kristoffer Ödmark wrote:
> Oh I was not planning on doing this, I am way to new to do a good job of
> sorting the codebase. Just wanted to see if there have been anyone else
> thinking in these lines. Currently in the pcbnew folder, the files seems
> to be grouped by their names, which is also fine. I would just enjoy if
> the files where grouped into folders more. there are currently 200+
> files in the pcbnew root directory.
> 
> For example:
> 9 files starting with specctra
> 47 files starting with class
> 29 files starting with pcb
> 

Hey,

I would vote for moving the files into folders grouped by functionality.
For example:
- board/ - board model (class_board, track, via, etc) + core algorithms
(zone filling, connectivity, ratsnest)
- io/ - all I/O plugins and exporters (in separate subdirectories) +
plugin management code
- io/kicad - kicad plugin
- io/legacy - legacy plgugin
- io/exporters/specctra - specctra export code
- io/importers/eagle - eagle import code
- view/ - GAL display code
- tools/ - all GAL tools
- legacy/ - all legacy tools/canvas code
- ui/ - wx-specific user interface stuff (dialogs, frames, etc.).

If we go for separate subfolders, I'd also suggest removing the class_
prefixes from the file names. All of the new code is OOP, so each source
file contains a class (or more).

In the long term, we could also eliminate linking dependencies between
these folders (so that class BOARD has no dependency on the GUI, etc).

Cheers,
Tom

___
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] Renaming headers?

[Wayne Stambaugh]

On 1/9/2018 10:21 AM, Kristoffer Ödmark wrote:
> Oh I was not planning on doing this, I am way to new to do a good job of
> sorting the codebase. Just wanted to see if there have been anyone else
> thinking in these lines. Currently in the pcbnew folder, the files seems
> to be grouped by their names, which is also fine. I would just enjoy if
> the files where grouped into folders more. there are currently 200+
> files in the pcbnew root directory.
> 
> For example:
> 9 files starting with specctra
> 47 files starting with class

Prefixing files with class_ was a choice that I do not like and have
never done.  It make searching file names a pain.  If I want to use the
bash auto complete feature I have to type class_ just get the point
where I can start to differentiate the rest of the file name.  Given the
almost every header file in kicad has a class declaration, prefixing the
file name with class does not add anything useful.  Please don't prefix
file names with class_ and use a descriptive but not obnoxiously long
file name when creating new source files.

> 29 files starting with pcb
> 
> I know you cant sort directly like that, but it gives a bit of an overview.
> 
> Anyway, I just wanted to see what anyone thought about it, if a renaming
> was to happen, a good time for something like this might be around the
> same time.
> 
>  -Kristoffer
> 
> On 01/09/2018 04:08 PM, Wayne Stambaugh wrote:
>> On 1/9/2018 10:01 AM, Kristoffer Ödmark wrote:
>>> Quite a bit of files under the root directory that could benefit from
>>> some sorting as well :) Would be two patches then, one for renaming, and
>>> one for sorting them somehow, both kinda large.
>>>
>>> Maybe move classes to a folder called classes?
>>
>> Please do not do this unless you are grouping related code such as the
>> swig/ folder in pcbnew/ or the netlist_exporters/ folder in eeschema.
>>
>>>
>>>   -Kristoffer
>>>
>>> On 01/09/2018 02:59 AM, Wayne Stambaugh wrote:
 On 1/8/2018 8:06 PM, Chris Pavlina wrote:
> Hi,
>
> Soonish, I'd like to go through and rename header files to actually
> match the names of the classes they define. It's a bit...unobvious
> that
> PCB_EDIT_FRAME is in wxPcbStruct.h, for instance. Now, because this
> would be a pretty large patch, I'd normally hold on until after 5.0 is
> released, but I think it'd actually be best to get this in BEFORE 5.0,
> because moving that many things around immediately after 5.0 would
> draw
> a line in the history through which bugfix backports onto the 5.0
> series
> become difficult. The very end of the 4.0 series seems like a perfect
> place. Because it's just a (large) rename, I think it has a relatively
> small likelihood of actually breaking anything - either it compiles or
> it doesn't, no change in functionality.
>
> Wayne, would you be okay with this?
>

 Chris,

 I'm OK with this since it's not really a code change.  I agree that it
 makes more sense to do it now rather than to wait and create major
 headaches when back porting bug fixes from the v6 development branch.

 Thanks,

 Wayne

 ___
 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
>>
> 
> ___
> 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] One more quick plug for reducing "Clarify Selection" dialogs

[Jeff Young]

Hi Kristoffer,

That’s odd.  Did you try it with your mouse pointer directly over the corner?  
(You may need a reasonably thick track for this to happen.  Try something on 
the order of 2mm.)

Without my change the selection disambiguation is run *before* we know it’s a 
drag action on a simple corner, so the selection_tool thinks it needs to know 
which of the two segments is to be selected.

Cheers,
Jeff.


> On 9 Jan 2018, at 15:37, Kristoffer Ödmark  
> wrote:
> 
> If i understand him correctly that would only be when on a corner, I think it 
> would be the desired behaviour.
> 
> Although, when I try it on my build on my laptop, there is no clarify 
> selection menu popping up when trying do drag ( 'd' ) or such on corners. Not 
> in opengl anywas. So I dont know.
> 
> Application: kicad
> Version: (2017-12-30 revision b55eb0b5f)-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.12-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.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=ON
>BUILD_GITHUB_PLUGIN=ON
>KICAD_USE_OCE=ON
>KICAD_SPICE=ON
> 
> 
> -Kristoffer
> 
> On 01/09/2018 04:27 PM, 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
>> 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] Libedit and Modedit Icons

[Wayne Stambaugh]

I'm with Jose on the arrows.  If we are going to use them, please don't
make the all different colors.  I don't see how a blue left arrow versus
a magenta right arrow conveys any meaning to the user.

On 1/9/2018 10:01 AM, José Ignacio wrote:
> i dislike the arrows on their own
> too. 
> https://www.google.com/search?q=file+open+icon&tbm=isch&ei=M9hUWtfCEMicjwSc-ovYCg&start=0&sa=N
> looks like a curve arrow in the direction where the book opens, with the
> book partially open would be more recognizable. For the "open
> symbol/footprint from library" icons the best would probably be to have
> the symbol or fp icon come out of an open book.
> 
> On Jan 9, 2018 8:53 AM, "Jeff Young"  > wrote:
> 
> Hi Oliver,
> 
> Looking good.  More comments:
> 
> 1) Go further. ;)  In particular, increase contrast even more by
> removing the fill on the project icons and on the symbol (libedit)
> and footprint (modedit) icons.
> 
> 2) Dark red in schematic icon and symbol icon should match.  (The
> symbol icon is closer to the default colour.)
> 
> 3) The arrows drive me bonkers.  How about a check-mark superimposed
> over icons to show “Set Active ...”, a superimposed folder for “Open
> …”, and a superimposed disk for “Save…”?  Something along the lines of:
> 
> 
> only with more artistic talent. ;)
> 
> (I suppose you could even have arrows coming out of the folder and
> going into the disk, but that might make them overly busy.)
> 
> Cheers,
> Jeff.
> 
>> On 9 Jan 2018, at 14:25, Oliver Walters
>> > > wrote:
>>
>> Thanks for the feedback everyone, I have increased contrast on the
>> "worst icons ever seen" (which for the record I had not yet got
>> around to tweaking, these have been hyperbolically terrible for a
>> while now).
>>
>> Other improvements thus far made:
>>
>> 1. Further simplification of icons, removal of "shadows", "page
>> curls" and other such frivolities
>> 2. Consolidation of icons - e.g. there were about 5 different ways
>> of drawing "module" and "symbol" icons
>> 3. Alignment / color / style issues
>> 4. Further work on "modifier" icons to provide better contrast on
>> all backgrounds (black border + white border, and better color
>> selection)
>>
>> Example from the home-screen:
>>
>> 
>>
>> A larger set of screenshots can be found here -
>> https://imgur.com/a/dm0JQ
>>
>> Cheers,
>>
>>
>> On Tue, Jan 9, 2018 at 10:11 PM, Jeff Young > > wrote:
>>
>> I hadn’t noticed the shadows (there’s one on the modedit icon
>> too), but I’d put them in the same camp as the turned-up
>> corners: adding visual complexity without any cognitive benefit.
>>
>> The *’s are commonly used to mean “new”.  (They should be more
>> of a glint than a star, but that’s difficult in a few pixels.)
>>
>> Cheers,
>> Jeff.
>>
>>
>>> On 9 Jan 2018, at 07:02, Andrey Kuznetsov
>>> mailto:kandre...@gmail.com>> wrote:
>>>
>>> Oliver thanks,
>>>
>>> Here's a couple more comments in addition to Jeff's.
>>>
>>> 1. I agree with Jeff on the Gerber icon, it's not clear which
>>> is which PCB layout vs Gerber.
>>> 2. Why are the books different height??? Make red book same
>>> height as green book.
>>> 3. I don't understand the meaning of the * on the icons.
>>> 4. See if making the red book a little more bright red, makes
>>> it look better, thanks for changing the yellow book to blue.
>>> Try checking if a black shadow around the + sign on the book
>>> icon makes it look better instead of the white. Same thing
>>> for all the arrows.
>>> 5. I agree with Jeff, not sure the complexity of the folded
>>> sheet corner is welcomed.
>>> 6. Anyone else thinks the shadow under the amplifier for the
>>> symbol edit button makes it look weird?
>>>
>>> I LIKE:
>>> 1. The calculator button, I wanted to suggest it, but didn't.
>>> 2. The empty worksheet layout button.
>>>
>>> On Mon, Jan 8, 2018 at 12:36 PM, Oliver
>>> Walters >> > wrote:
>>>
>>> What about something like this?
>>>
>>> 
>>>
>>> I have also gone through the entire icon set and
>>> standardized the "modifier" icons (save / load / import /
>>> export / new / etc) as they all had different style /
>>> shape / color.
>>>
>>> e.g.
>>>
>>> 
>>>
>>> On Mon, Jan 8, 2018 at 7:56 AM, Wayne
>>> Stambaugh >> > wrote:
>>>
>>> I see some poorly stacked books in these images as
>>> well and all of whi

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

[Jeff Young]

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
> 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] One more quick plug for reducing "Clarify Selection" dialogs

[Kristoffer Ödmark]

If i understand him correctly that would only be when on a corner, I 
think it would be the desired behaviour.


Although, when I try it on my build on my laptop, there is no clarify 
selection menu popping up when trying do drag ( 'd' ) or such on 
corners. Not in opengl anywas. So I dont know.


Application: kicad
Version: (2017-12-30 revision b55eb0b5f)-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.12-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.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=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_SPICE=ON


 -Kristoffer

On 01/09/2018 04:27 PM, 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
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] One more quick plug for reducing "Clarify Selection" dialogs

[Wayne Stambaugh]

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
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Renaming headers?

[Kristoffer Ödmark]

Oh I was not planning on doing this, I am way to new to do a good job of 
sorting the codebase. Just wanted to see if there have been anyone else 
thinking in these lines. Currently in the pcbnew folder, the files seems 
to be grouped by their names, which is also fine. I would just enjoy if 
the files where grouped into folders more. there are currently 200+ 
files in the pcbnew root directory.


For example:
9 files starting with specctra
47 files starting with class
29 files starting with pcb

I know you cant sort directly like that, but it gives a bit of an overview.

Anyway, I just wanted to see what anyone thought about it, if a renaming 
was to happen, a good time for something like this might be around the 
same time.


 -Kristoffer

On 01/09/2018 04:08 PM, Wayne Stambaugh wrote:

On 1/9/2018 10:01 AM, Kristoffer Ödmark wrote:

Quite a bit of files under the root directory that could benefit from
some sorting as well :) Would be two patches then, one for renaming, and
one for sorting them somehow, both kinda large.

Maybe move classes to a folder called classes?


Please do not do this unless you are grouping related code such as the
swig/ folder in pcbnew/ or the netlist_exporters/ folder in eeschema.



  -Kristoffer

On 01/09/2018 02:59 AM, Wayne Stambaugh wrote:

On 1/8/2018 8:06 PM, Chris Pavlina wrote:

Hi,

Soonish, I'd like to go through and rename header files to actually
match the names of the classes they define. It's a bit...unobvious that
PCB_EDIT_FRAME is in wxPcbStruct.h, for instance. Now, because this
would be a pretty large patch, I'd normally hold on until after 5.0 is
released, but I think it'd actually be best to get this in BEFORE 5.0,
because moving that many things around immediately after 5.0 would draw
a line in the history through which bugfix backports onto the 5.0 series
become difficult. The very end of the 4.0 series seems like a perfect
place. Because it's just a (large) rename, I think it has a relatively
small likelihood of actually breaking anything - either it compiles or
it doesn't, no change in functionality.

Wayne, would you be okay with this?



Chris,

I'm OK with this since it's not really a code change.  I agree that it
makes more sense to do it now rather than to wait and create major
headaches when back porting bug fixes from the v6 development branch.

Thanks,

Wayne

___
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



___
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] Renaming headers?

[Wayne Stambaugh]

On 1/9/2018 10:01 AM, Kristoffer Ödmark wrote:
> Quite a bit of files under the root directory that could benefit from
> some sorting as well :) Would be two patches then, one for renaming, and
> one for sorting them somehow, both kinda large.
> 
> Maybe move classes to a folder called classes?

Please do not do this unless you are grouping related code such as the
swig/ folder in pcbnew/ or the netlist_exporters/ folder in eeschema.

> 
>  -Kristoffer
> 
> On 01/09/2018 02:59 AM, Wayne Stambaugh wrote:
>> On 1/8/2018 8:06 PM, Chris Pavlina wrote:
>>> Hi,
>>>
>>> Soonish, I'd like to go through and rename header files to actually
>>> match the names of the classes they define. It's a bit...unobvious that
>>> PCB_EDIT_FRAME is in wxPcbStruct.h, for instance. Now, because this
>>> would be a pretty large patch, I'd normally hold on until after 5.0 is
>>> released, but I think it'd actually be best to get this in BEFORE 5.0,
>>> because moving that many things around immediately after 5.0 would draw
>>> a line in the history through which bugfix backports onto the 5.0 series
>>> become difficult. The very end of the 4.0 series seems like a perfect
>>> place. Because it's just a (large) rename, I think it has a relatively
>>> small likelihood of actually breaking anything - either it compiles or
>>> it doesn't, no change in functionality.
>>>
>>> Wayne, would you be okay with this?
>>>
>>
>> Chris,
>>
>> I'm OK with this since it's not really a code change.  I agree that it
>> makes more sense to do it now rather than to wait and create major
>> headaches when back porting bug fixes from the v6 development branch.
>>
>> Thanks,
>>
>> Wayne
>>
>> ___
>> 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] Renaming headers?

[Kristoffer Ödmark]

Quite a bit of files under the root directory that could benefit from 
some sorting as well :) Would be two patches then, one for renaming, and 
one for sorting them somehow, both kinda large.


Maybe move classes to a folder called classes?

 -Kristoffer

On 01/09/2018 02:59 AM, Wayne Stambaugh wrote:

On 1/8/2018 8:06 PM, Chris Pavlina wrote:

Hi,

Soonish, I'd like to go through and rename header files to actually
match the names of the classes they define. It's a bit...unobvious that
PCB_EDIT_FRAME is in wxPcbStruct.h, for instance. Now, because this
would be a pretty large patch, I'd normally hold on until after 5.0 is
released, but I think it'd actually be best to get this in BEFORE 5.0,
because moving that many things around immediately after 5.0 would draw
a line in the history through which bugfix backports onto the 5.0 series
become difficult. The very end of the 4.0 series seems like a perfect
place. Because it's just a (large) rename, I think it has a relatively
small likelihood of actually breaking anything - either it compiles or
it doesn't, no change in functionality.

Wayne, would you be okay with this?



Chris,

I'm OK with this since it's not really a code change.  I agree that it
makes more sense to do it now rather than to wait and create major
headaches when back porting bug fixes from the v6 development branch.

Thanks,

Wayne

___
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

[Kristoffer Ödmark]

Good job! Theese are very clear improvements!

I must say though, I do not really like the Gerbviewer icon much. The 
colors are a bit contrasting to the rest of the icons, and I was 
probably wrong about the GBR thing, I feel that removing the Magnifying 
glass only on the previous one would be much more clear.


The black n white papers reminds me of when I used to etch my own pcbs 
and printed the layout to paper!


The rest of the icons are looking amazing!

 -Kristoffer

On 01/09/2018 03:25 PM, Oliver Walters wrote:

Thanks for the feedback everyone, I have increased contrast on the "worst
icons ever seen" (which for the record I had not yet got around to
tweaking, these have been hyperbolically terrible for a while now).

Other improvements thus far made:

1. Further simplification of icons, removal of "shadows", "page curls" and
other such frivolities
2. Consolidation of icons - e.g. there were about 5 different ways of
drawing "module" and "symbol" icons
3. Alignment / color / style issues
4. Further work on "modifier" icons to provide better contrast on all
backgrounds (black border + white border, and better color selection)

Example from the home-screen:

[image: Inline image 1]

A larger set of screenshots can be found here - https://imgur.com/a/dm0JQ

Cheers,


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


I hadn’t noticed the shadows (there’s one on the modedit icon too), but
I’d put them in the same camp as the turned-up corners: adding visual
complexity without any cognitive benefit.

The *’s are commonly used to mean “new”.  (They should be more of a glint
than a star, but that’s difficult in a few pixels.)

Cheers,
Jeff.


On 9 Jan 2018, at 07:02, Andrey Kuznetsov  wrote:

Oliver thanks,

Here's a couple more comments in addition to Jeff's.

1. I agree with Jeff on the Gerber icon, it's not clear which is which PCB
layout vs Gerber.
2. Why are the books different height??? Make red book same height as
green book.
3. I don't understand the meaning of the * on the icons.
4. See if making the red book a little more bright red, makes it look
better, thanks for changing the yellow book to blue. Try checking if a
black shadow around the + sign on the book icon makes it look better
instead of the white. Same thing for all the arrows.
5. I agree with Jeff, not sure the complexity of the folded sheet corner
is welcomed.
6. Anyone else thinks the shadow under the amplifier for the symbol edit
button makes it look weird?

I LIKE:
1. The calculator button, I wanted to suggest it, but didn't.
2. The empty worksheet layout button.

On Mon, Jan 8, 2018 at 12:36 PM, Oliver Walters  wrote:


What about something like this?



I have also gone through the entire icon set and standardized the
"modifier" icons (save / load / import / export / new / etc) as they all
had different style / shape / color.

e.g.



On Mon, Jan 8, 2018 at 7:56 AM, Wayne Stambaugh 
wrote:


I see some poorly stacked books in these images as well and all of which
are way to large to be toolbar and menu icons.  As I said, if you can
pull if off then I'm fine with it.

On 01/07/2018 03:51 PM, Andrey Kuznetsov wrote:

Hi Wayne,

The problem I had with the library icon is that there are only 2 books,
and a ruler, that's what it looks like to me, and the 2 books are
stacked using a weird tilt angle, usually you'd expect the books to be
stacked straight on the left side, and the book on the right to be
tilted into the books on the left. It's the opposite in the current

icon.


Plenty of book icons online to draw inspiration from, or even creative
commons:
https://www.google.com/search?q=library+book+icon
 go to images

On Sun, Jan 7, 2018 at 12:45 PM, Wayne Stambaugh mailto:stambau...@gmail.com>> wrote:

 My project leader hat is getting a workout today.  Here is what I

would

 like to see:

 Revert the libedit and modedit icons without pencils since we are

doing

 away with whole pencil idea.  The original blueprint concept for

these

 icons was clever but they ended up looking a bit busy and didn't

really

 fit in with the rest of our icons.

 Remove the magnifying glass from the appropriate icons since it is

in

 the same vein as the pencil.

 Use the gerber file file extension (gbr) on the gerbview icon if

we must

 use any text.  I'm still not convinced that this is the best

solution

 but I can't think of a better idea off the top of my head.

 Please consider muting the green of the board editor icon.  From

the

 images I've seen the bright green is a bit harsh.  Maybe a slightly
 darker shade of green would be better.  I've looked a hundreds of

green

 PCBs in my career and I don't ever remember any of them hurting my

eyes.


 As for the library icons, I'm fine with those.  If you stack the

books

 neatly, would they still look like books?  I'm guessing they

wouldn't

 but if someone can 

Re: [Kicad-developers] Kicad from scratch: pcbnew: cannot use ~/ for home directory for KISYS3DMOD path?

[Nick Østergaard]

If you really want to start from scratch then you may also want to remove
the ~/.cache/kicad  (or there about, I am not on linux right now). But it
is not as important, it only contains the scene graph model cache. (Or what
ever it is really called)

2018-01-09 14:55 GMT+01:00 Clemens Koller :

> Hi!
>
> I am testing latest-git on Linux, collecting some UX issues when starting
> Kicad from scratch (*):
>
> On a new installation, I cannot execute 3D Shape Downloader out of the
> box. KISYS3DMOD points to ~/SW/share/kicad/modules/packages3d after
> installation to ~/SW/share/kicad/bin.
>
> This folder doesn't exist yet at this point, but could be created by Kicad.
> (The behaviour is still the same even when ~/SW/share/kicad/modules/packages3d
> was created in advance.)
>
> The 3D Shape Downloader then tells me:
> "It's not possible to write in the selected directory. Please choose
> anothe one."
>
> When I press "Default 3D Path", I would expect that it resets the path to
> a default working one,
> but an message tells me that "KISYS3DMOD path not defined , or not
> existing".
>
> Anyway it's possible to hit the Next-> button just to realize than after
> an hour of downloading, the download is going to fail -> Duh!
> When I replace the ~/ with /home/admin/ everything seems to work.
> Is there a reason that the ~ cannot be used from within Kicad?
>
> Regards,
>
> Clemens
>
> (*) Kicad rebuilt from src and started from scratch after rm
> ~/.config/kicad
>
>
> ---
> Application: kicad
> Version: (2018-01-08 revision 0e9c8a423)-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.12-1-ARCH 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
>
>
> ___
> 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] Kicad from scratch: pcbnew: cannot use ~/ for home directory for KISYS3DMOD path?

[Clemens Koller]

Hi!

I am testing latest-git on Linux, collecting some UX issues when starting Kicad 
from scratch (*):

On a new installation, I cannot execute 3D Shape Downloader out of the box. 
KISYS3DMOD points to ~/SW/share/kicad/modules/packages3d after installation to 
~/SW/share/kicad/bin.

This folder doesn't exist yet at this point, but could be created by Kicad.
(The behaviour is still the same even when ~/SW/share/kicad/modules/packages3d 
was created in advance.)

The 3D Shape Downloader then tells me:
"It's not possible to write in the selected directory. Please choose anothe 
one."

When I press "Default 3D Path", I would expect that it resets the path to a 
default working one,
but an message tells me that "KISYS3DMOD path not defined , or not existing".

Anyway it's possible to hit the Next-> button just to realize than after an 
hour of downloading, the download is going to fail -> Duh!
When I replace the ~/ with /home/admin/ everything seems to work.
Is there a reason that the ~ cannot be used from within Kicad?

Regards,

Clemens

(*) Kicad rebuilt from src and started from scratch after rm ~/.config/kicad


---
Application: kicad
Version: (2018-01-08 revision 0e9c8a423)-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.12-1-ARCH 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


___
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

[Jeff Young]

Hi Chris,

Patch looks OK on normal-res Retina MacBook Pro (ie: it didn’t break anything).

Cheers,
Jeff.


> On 9 Jan 2018, at 13:44, Nick Østergaard  wrote:
> 
> I suspect it looks something similar to what is presented in 
> 
> https://bugs.launchpad.net/kicad/+bug/1519581 
> 
> 
> 2018-01-09 14:40 GMT+01:00 Bernhard Stegmaier  >:
> Hi Chris,
> 
> can you show a screenshot what this patch fixes?
> I have a Retina MacBook and for my taste the toolbar icons are pretty OK 
> without any patch…
> 
> 
> Regards,
> Bernhard
> 
> 
>> On 9. Jan 2018, at 14:27, Maciej Sumiński > > wrote:
>> 
>> Hi Chris,
>> 
>> The patch does not apply cleanly on the current master, would you rebase
>> it? Thanks in advance.
>> 
>> Cheers,
>> Orson
>> 
>> On 01/09/2018 03:43 AM, Chris Pavlina wrote:
>>> Hi,
>>> 
>>> As discussed with Wayne earlier, I've attached a patch which adds simple
>>> toolbar icon scaling so the toolbars are readable on high-DPI systems.
>>> 
>>> This is meant as a stopgap for 5.0, with plans to add proper scaled
>>> icons in the 6.0 cycle. A function KiScaledBitmap() is added, which
>>> works like KiBitmap() except it scales the bitmap according to the
>>> calling window's font size. Controls have been added to all the main
>>> applications to let the user select scaling manually (these were omitted
>>> from smaller apps that didn't already have a place to put them).
>>> 
>>> In addition, in eeschema only, the pixel height of the system font is
>>> shown in the options dialog for diagnostics. This is only for collecting
>>> feedback before 5.0 release from users with different displays and will
>>> be removed.
>>> 
>>> I would like to push this fairly soon, as I want to get as much user
>>> feedback as possible before release. I have a limited number of systems
>>> to test this on myself.
>>> 
>>> 
>>> 
>>> ___
>>> 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 
> 
> 
> 
> ___
> 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

[Nick Østergaard]

I suspect it looks something similar to what is presented in

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

2018-01-09 14:40 GMT+01:00 Bernhard Stegmaier :

> Hi Chris,
>
> can you show a screenshot what this patch fixes?
> I have a Retina MacBook and for my taste the toolbar icons are pretty OK
> without any patch…
>
>
> Regards,
> Bernhard
>
>
> On 9. Jan 2018, at 14:27, Maciej Sumiński  wrote:
>
> Hi Chris,
>
> The patch does not apply cleanly on the current master, would you rebase
> it? Thanks in advance.
>
> Cheers,
> Orson
>
> On 01/09/2018 03:43 AM, Chris Pavlina wrote:
>
> Hi,
>
> As discussed with Wayne earlier, I've attached a patch which adds simple
> toolbar icon scaling so the toolbars are readable on high-DPI systems.
>
> This is meant as a stopgap for 5.0, with plans to add proper scaled
> icons in the 6.0 cycle. A function KiScaledBitmap() is added, which
> works like KiBitmap() except it scales the bitmap according to the
> calling window's font size. Controls have been added to all the main
> applications to let the user select scaling manually (these were omitted
> from smaller apps that didn't already have a place to put them).
>
> In addition, in eeschema only, the pixel height of the system font is
> shown in the options dialog for diagnostics. This is only for collecting
> feedback before 5.0 release from users with different displays and will
> be removed.
>
> I would like to push this fairly soon, as I want to get as much user
> feedback as possible before release. I have a limited number of systems
> to test this on myself.
>
>
>
> ___
> 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
>
>
___
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

[Bernhard Stegmaier]

Hi Chris,

can you show a screenshot what this patch fixes?
I have a Retina MacBook and for my taste the toolbar icons are pretty OK 
without any patch…


Regards,
Bernhard

> On 9. Jan 2018, at 14:27, Maciej Sumiński  wrote:
> 
> Hi Chris,
> 
> The patch does not apply cleanly on the current master, would you rebase
> it? Thanks in advance.
> 
> Cheers,
> Orson
> 
> On 01/09/2018 03:43 AM, Chris Pavlina wrote:
>> Hi,
>> 
>> As discussed with Wayne earlier, I've attached a patch which adds simple
>> toolbar icon scaling so the toolbars are readable on high-DPI systems.
>> 
>> This is meant as a stopgap for 5.0, with plans to add proper scaled
>> icons in the 6.0 cycle. A function KiScaledBitmap() is added, which
>> works like KiBitmap() except it scales the bitmap according to the
>> calling window's font size. Controls have been added to all the main
>> applications to let the user select scaling manually (these were omitted
>> from smaller apps that didn't already have a place to put them).
>> 
>> In addition, in eeschema only, the pixel height of the system font is
>> shown in the options dialog for diagnostics. This is only for collecting
>> feedback before 5.0 release from users with different displays and will
>> be removed.
>> 
>> I would like to push this fairly soon, as I want to get as much user
>> feedback as possible before release. I have a limited number of systems
>> to test this on myself.
>> 
>> 
>> 
>> ___
>> 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] [PATCH] Implement primitive icon scaling for high DPI

[Maciej Sumiński]

Hi Chris,

The patch does not apply cleanly on the current master, would you rebase
it? Thanks in advance.

Cheers,
Orson

On 01/09/2018 03:43 AM, Chris Pavlina wrote:
> Hi,
> 
> As discussed with Wayne earlier, I've attached a patch which adds simple
> toolbar icon scaling so the toolbars are readable on high-DPI systems.
> 
> This is meant as a stopgap for 5.0, with plans to add proper scaled
> icons in the 6.0 cycle. A function KiScaledBitmap() is added, which
> works like KiBitmap() except it scales the bitmap according to the
> calling window's font size. Controls have been added to all the main
> applications to let the user select scaling manually (these were omitted
> from smaller apps that didn't already have a place to put them).
> 
> In addition, in eeschema only, the pixel height of the system font is
> shown in the options dialog for diagnostics. This is only for collecting
> feedback before 5.0 release from users with different displays and will
> be removed.
> 
> I would like to push this fairly soon, as I want to get as much user
> feedback as possible before release. I have a limited number of systems
> to test this on myself.
> 
> 
> 
> ___
> 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] pcbnew: Zoom to fit board on screen broken

[Jon Evans]

Thanks Clemens, confirmed and reported here:
https://bugs.launchpad.net/kicad/+bug/1742140

On Tue, Jan 9, 2018 at 6:32 AM, Clemens Koller  wrote:

> Sorry, my mistake:
>
> It happens in Modern (Fallback) mode only. Legacy mode is okay! (The new
> names...)
>
> Regards,
>
> Clemens
>
> On 2018-01-09 12:25, Clemens Koller wrote:
> > Hi, Jon!
> >
> > Its erratic in Legacy mode only, after starting with an empty project.
> Once there were components placed and deleted, the behaviour vanishes, IIRC.
> >
> > Regards,
> >
> > Clemens
> >
> >
> > On 2018-01-09 05:31, Jon Evans wrote:
> >> Can't reproduce this on my Linux system.  I even tried removing my
> config file and still the zoom to fit button works on the first try and I
> don't see any strange zoom behavior.
> >>
> >> On Mon, Jan 8, 2018 at 9:05 PM, Clemens Koller  c...@embeon.de>> wrote:
> >>
> >> Hi!
> >>
> >> The Zoom Button to fit board on screen seems to be broken. It does
> a fit board only on second click and then it's still not centered nicely in
> the drawing area.
> >>
> >> This might be related to: https://bugs.launchpad.net/
> kicad/+bug/1672868 
> >>
> >> Steps to reproduce:
> >> - Restart Kicad from scratch (rm ~/.config/kicad)
> >> - start pcbnew
> >> - play around with zoom buttons.
> >>
> >> Regards,
> >>
> >> Clemens
> >>
> >> ---
> >> Application: kicad
> >> Version: (2018-01-08 revision 0e9c8a423)-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.12-1-ARCH 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
> >>
> >> ---
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers>
> >> Post to : kicad-developers@lists.launchpad.net  kicad-developers@lists.launchpad.net>
> >> Unsubscribe : https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers>
> >> More help   : https://help.launchpad.net/ListHelp <
> 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
>
___
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] pcbnew: Zoom to fit board on screen broken

[Clemens Koller]

Sorry, my mistake:

It happens in Modern (Fallback) mode only. Legacy mode is okay! (The new 
names...)

Regards,

Clemens

On 2018-01-09 12:25, Clemens Koller wrote:
> Hi, Jon!
> 
> Its erratic in Legacy mode only, after starting with an empty project. Once 
> there were components placed and deleted, the behaviour vanishes, IIRC.
> 
> Regards,
> 
> Clemens
> 
> 
> On 2018-01-09 05:31, Jon Evans wrote:
>> Can't reproduce this on my Linux system.  I even tried removing my config 
>> file and still the zoom to fit button works on the first try and I don't see 
>> any strange zoom behavior.
>>
>> On Mon, Jan 8, 2018 at 9:05 PM, Clemens Koller > > wrote:
>>
>> Hi!
>>
>> The Zoom Button to fit board on screen seems to be broken. It does a fit 
>> board only on second click and then it's still not centered nicely in the 
>> drawing area.
>>
>> This might be related to: https://bugs.launchpad.net/kicad/+bug/1672868 
>> 
>>
>> Steps to reproduce:
>> - Restart Kicad from scratch (rm ~/.config/kicad)
>> - start pcbnew
>> - play around with zoom buttons.
>>
>> Regards,
>>
>> Clemens
>>
>> ---
>> Application: kicad
>> Version: (2018-01-08 revision 0e9c8a423)-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.12-1-ARCH 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
>>
>> ---
>>
>> ___
>> 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] pcbnew: Zoom to fit board on screen broken

[Clemens Koller]

Hi, Jon!

Its erratic in Legacy mode only, after starting with an empty project. Once 
there were components placed and deleted, the behaviour vanishes, IIRC.

Regards,

Clemens


On 2018-01-09 05:31, Jon Evans wrote:
> Can't reproduce this on my Linux system.  I even tried removing my config 
> file and still the zoom to fit button works on the first try and I don't see 
> any strange zoom behavior.
> 
> On Mon, Jan 8, 2018 at 9:05 PM, Clemens Koller  > wrote:
> 
> Hi!
> 
> The Zoom Button to fit board on screen seems to be broken. It does a fit 
> board only on second click and then it's still not centered nicely in the 
> drawing area.
> 
> This might be related to: https://bugs.launchpad.net/kicad/+bug/1672868 
> 
> 
> Steps to reproduce:
> - Restart Kicad from scratch (rm ~/.config/kicad)
> - start pcbnew
> - play around with zoom buttons.
> 
> Regards,
> 
> Clemens
> 
> ---
> Application: kicad
> Version: (2018-01-08 revision 0e9c8a423)-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.12-1-ARCH 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
> 
> ---
> 
> ___
> 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