On 03/20/2017 02:36 PM, Wayne Stambaugh wrote:
> On 3/18/2017 10:18 AM, Maciej Suminski wrote:
>> In order to remove the hardcoded values from WORKSHEET_VIEWITEM, I
>> started moving code that used to be compiled multiple times to separate
>> units. This is also a basic way to solve the internal un
Hi JP,
ah OK thanks for the reply.
Removing swig2 does not really solve the problem.
fabrizio@ln1 /opt/kicad-source-mirror/build/release $ sudo apt-get remove
swig2.0
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'swig2.0' is not installed, so
When did you successfully build on 14.04? IIRC we only support 16.04+ now.
Den 22/03/2017 09.44 skrev "Fabrizio Tappero" :
> Hi JP,
> ah OK thanks for the reply.
>
> Removing swig2 does not really solve the problem.
>
>
>
> fabrizio@ln1 /opt/kicad-source-mirror/build/release $ sudo apt-get remov
Hi Fabrizio,
Have you cleared out (i.e. deleted) your build tree since removing
swig 2 and run CMake from fresh? CMake probably may not pick up the
change otherwise, as it could have cached the result of the original
FindSWIG. Deleting the build tree is drastic but leaves no doubt as
what gets use
Hi Nick,
by turing off scriping stuff I did build kicad yesterday.
good to know.
cheers
Fabrizio
On Wed, Mar 22, 2017 at 9:49 AM, Nick Østergaard wrote:
> When did you successfully build on 14.04? IIRC we only support 16.04+ now.
>
> Den 22/03/2017 09.44 skrev "Fabrizio Tappero" >:
>
>> Hi
See apt-get output:
<<<
...
Package 'swig2.0' is not installed, so not removed
...
So, it didn't remove anything, but /usr/bin/swig2.0 seems still to be
there.
Manually installed?
Setup somehow screwed up?
Regards,
Bernhard
On 22.03.2017 09:49, Nick Østergaard wrote:
When did you successf
Hi,
apologies for bringing this up. It was just a Cmake cache issue. deleting
the build folder and running cmake again fixed the problem.
thank you
fabrizio
On Wed, Mar 22, 2017 at 10:19 AM, Bernhard Stegmaier <
stegma...@sw-systems.de> wrote:
> See apt-get output:
> <<<
> ...
> Package 'swig2.
Hi John,
Thank you for fixing the issue. I have just committed your patches, well
done!
Cheers,
Orson
On 03/20/2017 04:19 PM, John Beard wrote:
> Hi,
>
> Here's a patch set to allow always-on cursors in GAL, which some
> people like for checking alignment and so on. Fixes lp:1673633.
>
> The n
I noticed that the option (introduced recently) to avoid showing menu icons
does work but it does not seem to work for the contextual menu of cvpcb.
See attachment
[image: Inline image 1]
cheers
Fabrizio
On Thu, Mar 2, 2017 at 12:11 AM, Kevin Cozens wrote:
> On 2017-03-01 02:45 PM, Julius Sc
Hi John,
Nice, I have just pushed the patch. Thank you for your contribution!
Cheers,
Orson
On 03/20/2017 06:44 PM, John Beard wrote:
> HI,
>
> Here's a small patch building on the two-point geometry manager to
> allow use of that manager's angle snapping function.
>
> This was mentioned as a
Hi Wayne,
Just an update: the tidy_ups branch [1] has been rebased and a small
number of conflicts resolved (mostly includes being added in the same
places).
Thanks,
John
[1] https://code.launchpad.net/~john-j-beard/kicad/+git/kicad/+ref/tidy_ups
On Thu, Feb 9, 2017 at 10:08 PM, John Beard wr
Hi,
I agree clicking with the middle mouse button is not particularly easy
but doable. I would not mind assigning a function to the button, but we
need choose carefully, since it is likely to stay for a long time. I am
sure that changing the behavior later will cause a rage coming from
users that
I have briefly tested the patch, no issues found. I have no objections
to the changes, but I will leave the final decision to Wayne.
Regards,
Orson
On 03/22/2017 03:51 AM, Jon Evans wrote:
> Hi Wayne, new patch attached.
>
> Thanks,
> Jon
>
> On Tue, Mar 21, 2017 at 9:28 AM, Wayne Stambaugh
>
Hi John,
I have just pushed your patch, thank you very much!
Cheers,
Orson
On 03/21/2017 05:30 PM, John Beard wrote:
> Hi,
>
> After editing zone properties in any canvas, the zone is not refilled,
> leading to stale display of the zone if a geometric property like the
> anti-pad clearance is c
Robbert,
Please disregard this comment. I was confusing the drill/place file
origin with the cursor offset (user) origin. This does raise two
issues. The term "User Origin" is a bit misleading. You might want to
use "Cursor Offset Origin" or at least provide a tool tip to clarify the
"User Ori
Hi,
please don't assign anything vital to middle button.
All native Apple HW doesn't have a middle button and also no
key-modifier
that simulates a middle button.
I can remember that some functions were moved away from middle button
for just this reason.
Regards,
Bernhard
On 22.03.2017 11:3
Hi,
Here's a patch set to add the final pieces of the GAL zone tool: close
outline and delete last corner.
This takes the form of a major re-cast of the drawZone event loop,
which now uses a preview item to show the zone in progress and a
geometry manager to decouple the construction from the the
On 3/22/2017 5:32 AM, Fabrizio Tappero wrote:
> hi guys,
> I am looking at some new icons that were introduced in kicad by the
> people who made the related functionalities and at the user experience
> in general. If any of you guys has any feedback about possible
> (aesthetic) UI improvements I wo
On Wed, Mar 22, 2017 at 09:06:33AM -0400, Wayne Stambaugh wrote:
> On 3/22/2017 5:32 AM, Fabrizio Tappero wrote:
> > hi guys,
> > I am looking at some new icons that were introduced in kicad by the
> > people who made the related functionalities and at the user experience
> > in general. If any of
On 3/22/2017 9:20 AM, Chris Pavlina wrote:
> On Wed, Mar 22, 2017 at 09:06:33AM -0400, Wayne Stambaugh wrote:
>> On 3/22/2017 5:32 AM, Fabrizio Tappero wrote:
>>> hi guys,
>>> I am looking at some new icons that were introduced in kicad by the
>>> people who made the related functionalities and at
On Wed, Mar 22, 2017 at 09:19:21AM -0400, Wayne Stambaugh wrote:
> On 3/22/2017 9:20 AM, Chris Pavlina wrote:
> > On Wed, Mar 22, 2017 at 09:06:33AM -0400, Wayne Stambaugh wrote:
> >> On 3/22/2017 5:32 AM, Fabrizio Tappero wrote:
> >>> hi guys,
> >>> I am looking at some new icons that were introdu
On 3/22/2017 4:41 AM, Maciej Sumiński wrote:
> On 03/20/2017 02:36 PM, Wayne Stambaugh wrote:
>> On 3/18/2017 10:18 AM, Maciej Suminski wrote:
>>> In order to remove the hardcoded values from WORKSHEET_VIEWITEM, I
>>> started moving code that used to be compiled multiple times to separate
>>> units
Since zoom to fit is already defined as the home key, using the middle
mouse button as an alternate shortcut shouldn't be objectionable. I do
agree with Bernhard that we should hard code any short cuts to keys or
mouse events that can not be either emulated or assigned to a different
key so OSX us
On 22.03.2017 14:34, Wayne Stambaugh wrote:
> I took a quick look at this and for the most part it seems OK. I'm not
> terribly thrilled with the global variables used for the internal units
> objects. I would much rather see a singleton or static objects. I also
> didn't see any changes to the
Hey John,
I'm assuming that the common.h tidy ups are from commit
cb2ef9ea5e4ee449295c41573beefa2fc0935b84 forward. If you don't mind, it
would make my life a bit easier if you would send the patches. They
look like they are all stand alone changes so it shouldn't be an issue
to push them one at
Hi Wayne,
They are pretty much all independent in scope, but there might be
(very minor) conflicts if you apply a subset or out of order.
Here are the patches.
Cheers,
John
On Wed, Mar 22, 2017 at 10:03 PM, Wayne Stambaugh wrote:
> Hey John,
>
> I'm assuming that the common.h tidy ups are fro
Hello,
like in the picture below the following patch is an improvement of the
following icons:
highlight nets
display local ratsnest
click to highlight net
nowadays having the mouse pointer in the icon is really not needed.
Regards
Fabrizio
[image: Inline image 1]
[image: Inline image 2]
diff
"[PATCH] 3 better icons" made me think of this:
Every once in a while we get patches from people redesigning a bunch of
icons. I think we should probably have some clear policy on icons so we
can have some consistency - it makes a bit of a mess when someone
redesigns half the icons every once in a
Hi Chris,
I'm still sitting on that complete set of icons from Konstantin that
I'm planning to start submitting.
Cheers,
John
On Wed, Mar 22, 2017 at 11:30 PM, Chris Pavlina wrote:
> "[PATCH] 3 better icons" made me think of this:
>
> Every once in a while we get patches from people redesignin
Hi all and mostly Wayne,
I notice that a lot of our older documentation comments redundantly list
the name of the function they document:
/**
* Function IsVoid
* @return true if the field value is void (no text in this field)
*/
bool IsVoid() const
I don't see any purpose
This patch is an importuned version of the measurement icon (caliper)
thanks
Fabrzio
diff --git a/bitmaps_png/cpp_26/measurement.cpp b/bitmaps_png/cpp_26/measurement.cpp
index 8031f1f..023e0a0 100644
--- a/bitmaps_png/cpp_26/measurement.cpp
+++ b/bitmaps_png/cpp_26/measurement.cpp
@@ -7,16 +7,31
Thanks for the feedback Wayne.
In your test, did you explicitly set the user origin by pressing the space bar?
The user origin is set to ( 0,0 ) by default, so if you haven't explicitly set
the user origin to something else, it actually is "correct" behavior to move
relative to the sheet origin
Robbert,
To make life easier for both of us, I'm going to commit this patch as is
as long as you are willing to create another patch with the following
changes:
Rename "User origin" to something more descriptive or add a tool tip to
prevent confusion.
Add a fifth option to move relative the to d
Hi Chris,
I agree with this and would also suggest that there are more Doxygen tags
we can use if desired.
In fact, I use a plugin for my editor that generates Doxygen templates
automatically if I type "/**" above a line of code:
/**
* @brief [brief description]
* @details [long description]
*
I think these are useless - the function name is right there anyway
unless the comment is absolutely enormous. These are just places for
doc-rot to creep if the function name changes.
I sometimes add them, but usually just to maintain consistency in a file.
Over 400 classes have a similar "* Clas
I really hate @brief and @details. Doxygen can do that automatically,
making the brief docstring the first sentence and the details one the
whole text. It makes for a doc comment that is much more readable in the
header itself, which is honestly how I read them most of the time.
On Wed, Mar 22, 20
Yes I agree with you here, I need to figure out how to update my template
because I always end up deleting those.
On Wed, Mar 22, 2017 at 11:14 AM, Chris Pavlina
wrote:
> I really hate @brief and @details. Doxygen can do that automatically,
> making the brief docstring the first sentence and the
Hi John,
I am very grateful for the patches. It is a well-thought refactor, I
like the introduced changes. Your patches have just been committed,
thanks again!
Cheers,
Orson
On 03/22/2017 02:05 PM, John Beard wrote:
> Hi,
>
> Here's a patch set to add the final pieces of the GAL zone tool: clos
On 3/22/2017 9:57 AM, Tomasz Wlostowski wrote:
> On 22.03.2017 14:34, Wayne Stambaugh wrote:
>> I took a quick look at this and for the most part it seems OK. I'm not
>> terribly thrilled with the global variables used for the internal units
>> objects. I would much rather see a singleton or stat
I'm open to suggestion on this. Image files are not my forte. My main
concerns are that we keep images reasonably consistent and try not make
life too difficult for the devs who have to merge the changes.
On 3/22/2017 11:30 AM, Chris Pavlina wrote:
> "[PATCH] 3 better icons" made me think of thi
A lot of this is a product of habit and copy & paste. It's not uncommon
for derived classes to have the same header doc comments as the base
class even though this is not necessary either. I'm OK with changing
this as we update headers. I would rather avoid the one giant commit
with all of the d
I'm going to side with Chris on this issue. Using a first sentence for
the brief description, followed by an empty line, and then an optional
detailed paragraph is certainly much more readable than using the
doxygen keywords.
On 3/22/2017 12:14 PM, Chris Pavlina wrote:
> I really hate @brief and
On Wed, Mar 22, 2017 at 01:05:48PM -0400, Wayne Stambaugh wrote:
> A lot of this is a product of habit and copy & paste. It's not uncommon
> for derived classes to have the same header doc comments as the base
> class even though this is not necessary either. I'm OK with changing
> this as we upd
On 2017-03-22 09:24 AM, Chris Pavlina wrote:
On Wed, Mar 22, 2017 at 09:19:21AM -0400, Wayne Stambaugh wrote:
On 3/22/2017 9:20 AM, Chris Pavlina wrote:
Minor nitpick, but "library component name". One is a library of
components, one is a component in such a library :)
"Name of Component in L
On 3/22/2017 1:14 PM, Chris Pavlina wrote:
> On Wed, Mar 22, 2017 at 01:05:48PM -0400, Wayne Stambaugh wrote:
>> A lot of this is a product of habit and copy & paste. It's not uncommon
>> for derived classes to have the same header doc comments as the base
>> class even though this is not necessar
On Wed, Mar 22, 2017 at 04:08:40PM -0400, Wayne Stambaugh wrote:
> On 3/22/2017 1:14 PM, Chris Pavlina wrote:
> > On Wed, Mar 22, 2017 at 01:05:48PM -0400, Wayne Stambaugh wrote:
> >> A lot of this is a product of habit and copy & paste. It's not uncommon
> >> for derived classes to have the same
Hi,
These patches add the "Select Layer and Add (Through|Blind) Via"
actions to the GAL: https://bugs.launchpad.net/kicad/+bug/1675195
I think I have done the calls to AddLayerPair() sensibly, but perhaps
the GAL wizards could double check, as the router is new territory for
me!
It's actually a
Hello, Fabrizio!
The horizontal + vertical justify radio buttons could possibly be improved by
showing the alignment visually as it's done in [1] by using a 3 x 3 radio
button matrix. It can also reduce the number of clicks to 1 to adjust hor +
vert simultaneously.
The timestamp is not human r
On Wed, Mar 22, 2017 at 11:53:40PM +0100, Clemens Koller wrote:
> Hello, Fabrizio!
>
> The horizontal + vertical justify radio buttons could possibly be improved by
> showing the alignment visually as it's done in [1] by using a 3 x 3 radio
> button matrix. It can also reduce the number of click
Hi,
I know I mainly lurk, however occasionally I feel the need to
make a suggestion or two. :-/
As a very long time user of KiCad I understand Chris's reluctance
to merge in every Icon set change.
Changing the "look" of icons can slow down productivity if you
just a slight segue is it not better to refer to symbols rather
than components? as with the footprints being seperated from the
symbols i don't see the justification for calling it a component (will
also require renaming other stuff)
On 23 March 2017 at 12:12, Chris Pavlina wrote:
> On Wed,
Are we calling them "symbols" now? Internally they are called with
"components" or "parts" depending on whether they are on a schematic...
On Thu, Mar 23, 2017 at 03:25:03PM +1300, Simon Wells wrote:
> just a slight segue is it not better to refer to symbols rather
> than components? as with t
No matter what they are called, it should be *one* thing. Currently there
seems to be a few options.
Schematic items - symbol / chip / component
PCB item - footprint / module / package
On Thu, Mar 23, 2017 at 1:30 PM, Chris Pavlina
wrote:
> Are we calling them "symbols" now? Internally they are
53 matches
Mail list logo
