review properly" veto. If we
> want people to be free to exercise that ability in good faith without feeling
> shy about blocking while they check it out, it should be called out as
> allowed and encouraged.
>
> Cheers,
>
> John
>
> On 21 April 2019 20:34:23 BST, T
ad version would read it just fine?
>
> Nick
>
> On Sun, 21 Apr 2019 at 18:46, Jeff Young <mailto:j...@rokeby.ie>> wrote:
> Hi Kevin,
>
> KiCad will read them in either way (quoted or un-quoted).
>
> KiCad has always written them out with quotes if they
Hi Kevin,
KiCad will read them in either way (quoted or un-quoted).
KiCad has always written them out with quotes if they had spaces in them (so
other tools have always needed to handle quotes).
We’re just being more consistent now as there’s no justification for “saving a
few characters” in
In my last few years at Adobe I worked with Day Software in Switzerland which
we had just acquired. They did a lot of open-source stuff with Apache and had
this neat decision-making scheme (which may have originated at Apache — I’m
unaware of its source):
If you need direction on something,
is a big enough change that I’ll need to do that on a
branch.
Cheers,
Jeff.
> On 18 Apr 2019, at 16:31, Tomasz Wlostowski wrote:
>
> On 18/04/2019 17:20, Jeff Young wrote:
>> Hi Tom,
>>
>> They’re in master.
>
> OK, but do I need to activate the
Hi Tom,
They’re in master.
Cheers,
Jeff.
> On 18 Apr 2019, at 15:02, Tomasz Wlostowski wrote:
>
> On 17/04/2019 22:51, Jeff Young wrote:
>> Drawing tools (and zoom-to-selection) moved to modern toolset.
>>
> Hi Jeff,
>
> Ho
Thanks, John!
(I did try a few things, but my CMake foo is pretty weak.)
Cheers,
Jeff.
> On 18 Apr 2019, at 10:16, John Beard wrote:
>
> Hi Jeff,
>
> On Thu, Apr 18, 2019 at 12:02 AM Jeff Young wrote:
>> I wonder if this is because I have OCE turned off so the code
The kicad2step test suite fails to build on my machine. (I’ve turned it off
for now.)
I wonder if this is because I have OCE turned off so the code-under-test isn’t
being built?
___
Mailing list: https://launchpad.net/~kicad-developers
Post to :
Drawing tools (and zoom-to-selection) moved to modern toolset.
> On 16 Apr 2019, at 16:23, Jeff Young wrote:
>
> Click-to-place tools moved to modern toolset.
>
> (Place component, no-connect, junction, wire-to-bus, bus-to-bus, label,
> hierarchical-label, global-lab
Click-to-place tools moved to modern toolset.
(Place component, no-connect, junction, wire-to-bus, bus-to-bus, label,
hierarchical-label, global-label, text and image.)
> On 14 Apr 2019, at 12:13, Jeff Young wrote:
>
> Net highlight tool now moved to modern toolset.
>
>
&g
Yes, this was intentional. It allows users to put things like spaces in layer
names and other user-editable things.
I’ll fix up the STEP exporter….
> On 15 Apr 2019, at 13:56, easyw wrote:
>
> Hi,
> recently I have noticed that both kicad_pcb and kicad_mod seems to have
> changed their
Net highlight tool now moved to modern toolset.
> On 13 Apr 2019, at 18:45, Jeff Young wrote:
>
> I just pushed changes to move Eeschema zoom control, Eeschema grid control
> and Pcbnew grid control to COMMON_TOOLS.
>
> Give a shout if you see anything odd….
&
66:10: fatal
> error: eeschema/tools/sch_actions.h: No such file or directory
> #include
> ^~
>
> Cheers,
>
> Wayne
>
> On 4/13/19 1:45 PM, Jeff Young wrote:
>> I just pushed changes to move Eeschema zoom control, Eeschema gr
I just pushed changes to move Eeschema zoom control, Eeschema grid control and
Pcbnew grid control to COMMON_TOOLS.
Give a shout if you see anything odd….
Cheers,
Jeff.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to :
Cool. I might do a bit to introduce SCH_ACTIONS, etc, but I’ll leave the
hookup until I see your stuff.
> On 12 Apr 2019, at 14:17, Tomasz Wlostowski wrote:
>
> On 12/04/2019 12:17, Jeff Young wrote:
>> Hi Tom,
>>
>> I was going to start laying some of the ground
Hi Tom,
I was going to start laying some of the ground-work for Eeschema’s modern
toolset. Do you already have some of this in a branch that you can share, or
should I go ahead and start with master?
Thanks,
Jeff.
___
Mailing list:
Never mind; I found it.
PCBNew already had two commands sharing the same hotkey (Redraw and Place
Relative). Evidently that’s benign as long as the loser doesn’t have an
action, but produces an assert when it does.
> On 11 Apr 2019, at 23:14, Jeff Young wrote:
>
> I added
I added an action common.Control.zoomRedraw that’s tied to the hotkey
HK_ZOOM_REDRAW. I tried to follow the other examples, but I appear to be
missing something.
It works fine, but on closing the document (PCB_EDIT_FRAME) I get an assert
trying to unregister the action because it doesn’t
Hi Kevin,
It would be reasonably straight-forward to fix that. Log a wishlist bug for
Board setup setting to indicate which edges of board are “up” for “keep
upright”.
Cheers,
Jeff.
> On 8 Apr 2019, at 15:32, Kevin Cozens wrote:
>
> On 2019-04-06 7:06 p.m., Jeff Young wrote:
&g
Thanks for testing, JP. The Update PCB from Schematic issue should be fixed
now.
Cheers,
Jeff.
> On 8 Apr 2019, at 19:12, jp charras wrote:
>
> Le 08/04/2019 à 17:43, Jeff Young a écrit :
>> I’ve just committed a couple of featurettes that could use a test spin if
Yep, seems to have worked. Thanks!
> On 8 Apr 2019, at 20:20, Jon Evans wrote:
>
> Yes, try that. We can probably pull it out of the ctor and just use the
> global until/unless it is refactored away.
>
> On Mon, Apr 8, 2019 at 3:19 PM Jeff Young <mailto:j...@rokeb
I see there are other places where it’s constructed with the global
g_ConnectionGraph. Do I just need to add that?
> On 8 Apr 2019, at 20:18, Jeff Young wrote:
>
> It’s in the cross-probing code. The init looks like this:
>
> NETLIST_OBJECT_LIST* net_atoms = B
etting the pointer to the global
> connection graph object.
>
> -Jon
>
> On Mon, Apr 8, 2019 at 3:07 PM Jeff Young <mailto:j...@rokeby.ie>> wrote:
> Hi Jon,
>
> When we try to build a netlist for Update PCB from Schematic we get an assert
> in NETLIST_EXPO
Hi Jon,
When we try to build a netlist for Update PCB from Schematic we get an assert
in NETLIST_EXPORTER_GENERIC::makeListOfNets() because m_graph is null. Is this
because real-time updating is turned off? Is there a call to build it that we
should be making in the meantime?
Cheers,
Jeff.
I’ve just committed a couple of featurettes that could use a test spin if
anyone has the opportunity.
1) Dry run reporting for Clean Up Tracks and Vias
2) Test Footprints in DRC
3) Support for full character set in labels, netnames, etc.
Cheers,
Jeff.
I just fixed cut/copy/paste symbol (in the Symbol Editor’s library tree) to use
the system clipboard.
Does anyone know of any other areas where we “cheat” and use global variables
for cut/copy/paste instead of the system clipboard?
Cheers,
Jeff.
___
While not directly related, see https://bugs.launchpad.net/kicad/+bug/1562672
for some more background.
> On 8 Apr 2019, at 09:56, John Beard wrote:
>
> Hi,
>
> I'm trying to get the 3d viewer hooked up to the common settings, so I
> can change the DPI scaling.
>
> The 3d viewer frame is a
I have all my stuff that’s destined for 5.1.1 in, so I’m OK with this plan. I
don’t know how much effort it is for our packagers, though.
Cheers,
Jeff.
> On 7 Apr 2019, at 04:31, Seth Hillbrand wrote:
>
> Hi All-
>
> I'd like to suggest spinning out 5.1.1 soon and pushing the existing
Below:
> On 7 Apr 2019, at 04:09, Seth Hillbrand wrote:
>
> Am 2019-04-06 19:06, schrieb Jeff Young:
>> The keep text upright feature works poorly with left- or
>> right-justified text (it flips around the anchor point).
>> This is difficult to fix because it
The keep text upright feature works poorly with left- or right-justified text
(it flips around the anchor point).
This is difficult to fix because it’s done at display time (so if the code is
changed it will change the layout of existing boards).
We could insert a second “keep upright”
I’ve got a couple of moderate-sized changelists:
1) escaping of characters in labels (this was waiting on Jon’s merge so should
be good-to-go?)
2) a re-jiggering of the UpdatePCBFromSchematic Kiway communications to be more
orthogonal (and allow us to reuse the code for footprint checking,
Hi Wayne,
Could you take a look at lines 75:77 in prjconfig.cpp:
// Save the project file for the currently loaded project.
if( m_active_project )
Prj().ConfigLoad( PgmTop().SysSearch(), GeneralGroupName,
s_KicadManagerParams );
If the comment is correct that should be ConfigSave(), not
When picking a new symbol we zoom-to-fit it. However, when picking a different
unit of the symbol being edited we don’t.
A user has complained about this[1]. However, it’s not clear to me on balance
which would be better. If you had a large symbol and were zoomed in on a
particular area and
Do we have a policy on when to use auto?
Personally, I like it when it removes repetition. For instance:
auto pin = new SCH_PIN();
And I like it when it removes stupid template things like std::pair<>:
for( auto it : my_unordered_map )
But I don’t like it in other cases. This
I’ve got a changelist which cleans up the various SCH_ and LIB_ Draw() routines
to remove the interactivity features (since they’re now print-only).
Should I merge it now?
Cheers,
Jeff.
https://git.launchpad.net/~jeyjey/kicad/commit/?id=ef6b71b3335080a5e3c4cd98e70d42f2f8f1132f
SCH_BUS_ENTRY is the only item which prints its dangling flags. (Everything
else only draws them on screen.)
Is this an oversight or intentional?
Thanks,
Jeff.___
Mailing list: https://launchpad.net/~kicad-developers
Post to :
These routines are only used for printing now, correct?
I’ve got a changelist which removes the code supporting interactive features in
them (such as brightening and dragging), but I just want to make sure before I
commit it.
Cheers,
Jeff.
___
Is launchpad’s git instance down? It’s refusing my connection...
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help :
I suspect I have just fixed these. There were a couple of places where we
returned a const-reference to a function result which is no longer
const-reference.
> On 3 Apr 2019, at 18:47, Simon Richter wrote:
>
> Hi,
>
> Jenkins reports failing tests on Linux since commit 5ac96c612 "More
>
Hi Tom,
I’m pretty sure it's any iterator, not just a non-const one. And they’re used
internally for things such as Length() and IsEmpty().
I wonder if you could do the mutex locking inside KiString, though? Or would
that kill performance? (You could avoid it on Length() and IsEmpty() by
a getter/setter
> paradigm and pass the object?
>
> Thoughts?
> -S
>
>
> Am 2019-04-03 09:35, schrieb Jeff Young:
>> Jon is currently fighting another wxString multi-threading issue.
>> Having done quite a few of these myself, I feel for him.
>> A lo
ss we drop support for big-endian platforms, we'll need to handle both
> cases. I needn't tell you what a pain that would be.
>
> Maybe we can just not return wxString references? Enforce a getter/setter
> paradigm and pass the object?
>
> Thoughts?
> -S
>
>
>
eck. What would break if these
> global strings were protected by FCFS locks?
>
> -Brian
>
>> On Apr 3, 2019, at 9:35 AM, Jeff Young wrote:
>>
>> Jon is currently fighting another wxString multi-threading issue. Having
>> done quite a few of these myself, I feel for him.
&
Tom and I were both doing penance for having added one of those arrays, so it
was time to get us out of Purgatory. ;)
> On 3 Apr 2019, at 13:37, Jon Evans wrote:
>
> Thanks Jeff! Changes look good to me.
>
> On Wed, Apr 3, 2019 at 6:28 AM Jeff Young <mailto:j...@rokeby.ie&
Jon is currently fighting another wxString multi-threading issue. Having done
quite a few of these myself, I feel for him.
A lot of them were threaded accesses to globals, so it was easy enough to make
the globals std::strings. However, this one is EDA_TEXT’s m_Text field.
That’s going to
by LIB_PIN*) of SCH_CONNECTION links
Cheers,
Jeff.
> On 2 Apr 2019, at 23:25, Wayne Stambaugh wrote:
>
> Jeff,
>
> This makes sense to me so go ahead an push this to the main repo when
> it's ready.
>
> Wayne
>
> On 4/2/19 11:47 AM, Jeff Young wrote:
>>> ...
> ... I'm assuming SCH_PIN objects will only live inside the SCH_COMPONENT
> object.
Correct.
Cheers,
Jeff.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe :
vans <mailto:j...@craftyjon.com>> wrote:
> OK. I have a hunch that I can fix it in a simpler way, so that you will never
> need to force the sheet. I will check it out and let you know.
>
> On Mon, Apr 1, 2019 at 6:34 PM Jeff Young <mailto:j...@rokeby.ie>> wrote:
>
s stored.
> You want SCH_CONNECTION::Name() to get you the final netname.
>
> On Mon, Apr 1, 2019 at 5:15 PM Jeff Young <mailto:j...@rokeby.ie>> wrote:
> Name() appears to only be on SHEET_PINs though. Or did I misread that?
>
>> On 1 Apr 2019, at 22:08, Jon Evans &g
ome reference code.
> GetDefaultNetName does not include the sheet path as it only returns
> candidate net names for pins, not the final net names used for netlisting.
>
> -Jon
>
> On Mon, Apr 1, 2019 at 5:02 PM Jeff Young <mailto:j...@rokeby.ie>> wrote:
> Hi Jon,
>
&
Hi Jon,
I’m trying to integrate the pin highlighting stuff with your merge. I’ve added
some code to SCH_EDIT_FRAME::SetCurrentSheetHighlightFlags() which attempts to
use the pin’s connection to see if it should be highlighted.
However, I’m having two issues.
1) Is there a way to get the
Hi JP,
I’m afraid I just move the decl (and its comment) from another file. It
appears the author
was Henner Zeller in 3f57fa5d2443a085c9fa243c615d71dc470a0107.
Commit comment was:
Change time_t in the functions that deal with timestamps to a new
typedef timestamp_t (defined as a
een tested to work under this case?
>
> Cheers,
>
> Wayne
>
> On 3/14/2019 10:26 AM, Jeff Young wrote:
>> Hi Wayne,
>>
>> No, it would need to be saved in the file. Think of it as Units for 3D
>> models: for instance you might have 30mm, 35mm and 40mm tall
I’ve never trusted any of the auto-formatters, but that might just be me.
> On 20 Mar 2019, at 16:46, Brian wrote:
>
> I'm trying to get better at not breaking the KiCad style guidelines, but then
> I see the clang-format tool make suggestions like this:
>
> -static LIB_TEXT*
be OSX does
> its own upscale?
>
> Cheers,
>
> John
>
> On 20 March 2019 13:46:07 GMT, Jeff Young wrote:
> Hi John,
>
> Is there something I need to do to turn this on? I applied your patch, but
> the icons look identical to the way they did before.
>
&g
st place rather than doing a bilinear upscale (which will look pretty bad
>> for icons that start out aligned nicely).
>>
>> IIRC the current upscale method was a stop gap for v5.
>>
>> Cheers,
>>
>> John
>>
>> On 19 March 2019 20:14:12 GM
The blurry ones actually look better on a Retina display, but I’m OK with the
others if they look better everywhere else.
Cheers,
Jeff.
> On 19 Mar 2019, at 19:54, Wayne Stambaugh wrote:
>
> Whew! I was starting worry about my vision there for minute :)
>
> On 3/19/2019 3:52 PM, John Beard
> On 19 Mar 2019, at 19:46, Brian wrote:
>
> Hi Jeff,
>
> On 3/19/19 3:10 PM, Jeff Young wrote:
>> Sounds good to me, although I’d also push getting a timestamp from a library
>> path to the bottom level.
> Jeff, when you say "a timestamp," what do yo
Hi Brian,
Sounds good to me, although I’d also push getting a timestamp from a library
path to the bottom level. (Use the longer form of the name, we have plugin
architectures for other things too.)
Cheers,
Jeff.
> On 19 Mar 2019, at 18:41, Brian wrote:
>
> Fellow KiCad developers,
>
> A
I suspect the original intent was to move both to the new one, it just never
got done.
If you want help with it Jon, give a scream. I’ve been in that code a bit.
Cheers,
Jeff.
> On 18 Mar 2019, at 17:37, Jon Evans wrote:
>
> Thanks for the history. I don't want to remove the manual
ould prefer the
> latter if possible. I guess I don't understand the purpose of this.
>
> Cheers,
>
> Wayne
>
> On 3/14/2019 6:44 AM, Jeff Young wrote:
>> @Wayne, this builds on top of my m_Preview addition so I’m happy to
>> review it and merge it after Oliver re-bases
@Wayne, this builds on top of my m_Preview addition so I’m happy to review it
and merge it after Oliver re-bases. But where do we stand on PCBNew file
format changes for 6.0? (There are also some hold-overs I have from 5.1;
namely storing defined diff pair dimensions and the courtyard DRC
Don’t worry; everyone misses at least a few of them the first couple of times.
Cheers,
Jeff.
> On 12 Mar 2019, at 20:18, Brian wrote:
>
>
>>
>> As for patches, it's always a good idea to make commits the smallest
>> required size to implement your changes. Large change sets like the one
>>
> On 11 Mar 2019, at 13:17, Tomasz Wlostowski wrote:
>
> Should we remove the legacy code from pcbnew
> sometime early during V6 cycle?
>
I would certainly be in favour of this. I keep tripping over the duplicate
EDA_DRAW_FRAMEs when trying to debug (or use CLion’s “go to definition” or
wait until the new schematic file format is implemented. I
> don't want to make any changes to either that or the symbol file format
> so the legacy file format parsers can be frozen for all posterity once
> the file formats are implemented.
>
> Wayne
>
> On 2/21/2019 5:13 PM, Jeff Y
I’d like to move the “old” netlist stuff to an Import/Export paradigm (since
the “normal” Kicad method is now Update Board from Schematic).
This entails removing the Read/Write Netlist icons from the toolbar and moving
the menu items from Tools to File > Import and File > Export.
The tools
I’m a fairly slow updater, and even I’m on 10.13.
Both my daughters have already gone to 10.14.
> On 27 Feb 2019, at 19:57, Wayne Stambaugh wrote:
>
> Hey Adam,
>
> I'm guessing the impact of not supporting 10.11 would not be that great
> but I'm not a mac user so I cannot be certain. Are
I just have the net-name-escaping stuff so that all characters can be used in
labels, etc.
(Well, a couple of bug fixes too, but real minor stuff.)
> On 21 Feb 2019, at 13:21, Wayne Stambaugh wrote:
>
> Since we are nearing the 5.1.0 release, I want to get an idea of what
> major merges are
I just pushed this. If someone could make sure that it doesn’t break other
platforms that would be great.
Cheers,
Jeff.
> On 19 Feb 2019, at 16:17, Jeff Young wrote:
>
> Nice call, Bernhard.
>
> That was indeed the issue.
>
> Cheers,
> Jeff.
>
>
>>
>> søn. 17. feb. 2019 23.17 skrev Tomasz Wlostowski > <mailto:tomasz.wlostow...@cern.ch>>:
>> On 17/02/2019 23:04, Wayne Stambaugh wrote:
>> > Looks fine on Linux.
>> >
>> > On 2/17/19 4:50 PM, Jeff Young wrote:
>> >> The 3D viewer on my m
My bad. I misread your comment:
> We could do this as part of a 5.1.1 release which can have it's own
> string freeze. Obviously we would want to keep the 5.1 branch string
> changes to a minimum but I'm guessing most of them would be spelling,
> grammar, and minor formatting issues.
(I seem
Whoo hooo! Looks awesome. Gets rid of the over-bolding at lower zooms too.
(OK, subpixel still looks weird, but that’s just the nature of the beast.
Supersampling looks fantastic.)
Cheers,
Jeff.
> On 15 Feb 2019, at 18:48, Tomasz Wlostowski wrote:
>
> Hi all,
>
> I made some fixes to
>> I'm also not
>> completely sure curved air wires will be necessary once we implement the
>> coloring feature.
I wonder if this is a digital vs. discrete thing? With transistors in
particular, I often find several ratsnest lines going directly over the 3 pins,
and having no idea which one
nce I'm sure his changes are far more significant and then
> you will have to rebase against his changes. Hopefully it wont be too
> painful.
>
> On 2/9/19 1:00 PM, Jeff Young wrote:
>> Most of my 6.0 branch changesets are small. The one that might have
>> conflicts is t
Holes seem different (although perhaps it just a different scrolling offset),
but not fixed:
> On 11 Feb 2019, at 21:02, Seth Hillbrand wrote:
>
> Am 2019-02-11 15:37, schrieb Jeff Young:
>> Will do.
>> BTW, I just finished building your previous patch. Sadly
Yep, your second patch restores un-aliased fallback. (But wow is it horrible
on a Retina display.)
Cheers,
Jeff.
> On 11 Feb 2019, at 20:37, Jeff Young wrote:
>
> Will do.
>
> BTW, I just finished building your previous patch. Sadly it does not solve
> the “holes in g
Will do.
BTW, I just finished building your previous patch. Sadly it does not solve the
“holes in graphics” anomalies.
Cheers,
Jeff.
> On 11 Feb 2019, at 20:34, Seth Hillbrand wrote:
>
>>> On 11 Feb 2019, at 20:11, Jeff Young wrote:
>>> Nightly works as expected (
), but worst text:
> On 11 Feb 2019, at 20:11, Jeff Young wrote:
>
> Nightly works as expected (which is to say the anti-aliasing settings make a
> difference, and turning it off makes the canvas look pretty awful).
>
>
>
>
>
>> On 11 Feb 2019, at 19:44, Seth Hillb
Nightly works as expected (which is to say the anti-aliasing settings make a
difference, and turning it off makes the canvas look pretty awful).
> On 11 Feb 2019, at 19:44, Seth Hillbrand wrote:
>
> Am 2019-02-11 14:33, schrieb Jeff Young:
>> No.
>> I’m running it d
No.
I’m running it directly out of my dev tree, but presumably that won’t make any
difference.
Would something here have changed between High Sierra and Mojave? (I’m still
on High Sierra.)
> On 11 Feb 2019, at 18:46, Seth Hillbrand wrote:
>
> Am 2019-02-11 13:31, schrieb J
Nope. Mine shows anti-aliasing for both (but with chunky 2 x 2 pixels).
> On 11 Feb 2019, at 18:01, Seth Hillbrand wrote:
>
> Am 2019-02-11 12:02, schrieb Jeff Young:
>> Ooops, my bad.
>> But in any case, the various Cairo modes don’t appear to make any
>> difference
I hadn’t played around with PCBNew yet… and sadly it looks uniformly worse with
the changes.
Again, zoomed up to make the differences clearer:
> On 11 Feb 2019, at 17:18, Jeff Young wrote:
>
> I think text looks best with no anti-aliasing. Is it possible to turn it off
> j
Not custom, but from 4.0 library. The hollowness only appears at some zoom
levels.
> On 11 Feb 2019, at 17:42, Seth Hillbrand wrote:
>
> Am 2019-02-11 12:14, schrieb Jeff Young:
>> Hmm, playing around with it some more I’m finding issues at some
>> zoom levels. I’ve blo
I think text looks best with no anti-aliasing. Is it possible to turn it off
just for text? (Or is this a Mac-specific result?)
> On 11 Feb 2019, at 17:14, Jeff Young wrote:
>
> Hmm, playing around with it some more I’m finding issues at some zoom levels.
> I’ve blown this s
-aligned:
> On 11 Feb 2019, at 17:06, Jeff Young wrote:
>
>
>
>> On 11 Feb 2019, at 16:49, Tomasz Wlostowski
>> wrote:
>>
>> On 11/02/2019 02:12, Jeff Young wrote:
>>> This hugely improves Fallback on Mac. Still doesn’t look as good as Open
> On 11 Feb 2019, at 16:49, Tomasz Wlostowski wrote:
>
> On 11/02/2019 02:12, Jeff Young wrote:
>> This hugely improves Fallback on Mac. Still doesn’t look as good as OpenGL
>> (or Legacy), but it’s at least usable.
>
> Hi Jeff,
>
> I don't see any differ
Ooops, my bad.
But in any case, the various Cairo modes don’t appear to make any difference on
Mac.
Cheers,
Jeff.
> On 11 Feb 2019, at 16:43, Seth Hillbrand wrote:
>
> Am 2019-02-11 11:35, schrieb Jeff Young:
>> Hmm… I also just noticed that the misplaced junction dots also
Hmm… I also just noticed that the misplaced junction dots also only appear on
OpenGL supersampling.
> On 11 Feb 2019, at 16:12, Jeff Young wrote:
>
> Hi Tom,
>
> OpenGL, no AA:
>
>
>
> OpenGL, subpixel high:
>
>
>
> OpenGL, 2X supersampling:
&g
This hugely improves Fallback on Mac. Still doesn’t look as good as OpenGL (or
Legacy), but it’s at least usable.
OpenGL 2x Oversampling appears the same, but OpenGL with no antialiasing has
caught up a lot. It’s now almost as good as 2X OS — in fact it would be usable
if you wanted to
Welcome, John! Glad to have you on board.
Cheers,
Jeff.
> On 7 Feb 2019, at 13:52, Javier Serrano
> wrote:
>
> Congratulations John! And thanks for all the great work so far.
>
> Javier
>
> PS. I don't know if somebody already posted this. The video of Wayne's talk
> in FOSDEM is already
^yesterday^earlier today^
(Where’s the old brain gone to?)
> On 30 Jan 2019, at 20:54, Jeff Young wrote:
>
> Rats. I spent 20 minutes yesterday figuring this out and all I had to do was
> read my email.
>
> Anyway, your patch is “effectively” merged. Thanks for
Rats. I spent 20 minutes yesterday figuring this out and all I had to do was
read my email.
Anyway, your patch is “effectively” merged. Thanks for your contribution!
Cheers,
Jeff.
> On 30 Jan 2019, at 11:37, Simon Richter wrote:
>
> ---
> qa/qa_utils/CMakeLists.txt | 3 ++-
> 1 file
Hi Tom,
I’ve only run into this stuff a bit tangentially, but I can provide a few
insights:
The wxDirDialog hack is because the Mac doesn’t have a combined open dialog
that can handle either a file or a directory. I think both GTK and Windows do.
Most of the performance hit in the library
I’m not aware of anything pending.
Cheers,
Jeff.
> On 5 Jan 2019, at 21:21, Wayne Stambaugh wrote:
>
> Is there any reason not to start the 5.1 string freeze? If so, please
> let me know. Otherwise we can officially freeze the strings so our
> translators can start work towards the 5.1
SMD items are likely to be denser and have square pads. Not using shaped
courtyards for them might make sense.
Electrolytic capacitors usually have a least one round pad, so the courtyard
collision time will be less than the pad collision time (which has to check
with many more objects).
We also have a spare license or two for CLion.
Cheers,
Jeff.
> On 19 Dec 2018, at 09:22, Mário Luzeiro wrote:
>
> No need to share project files, its as easy as:
>
> git clone kicad
> mkdir kicad\qtcreator
>
> Now create the build path/files with CMake as you normally do.
>
> QtCreator ->
Hi Adam,
I’d stick it in a function in common.cpp.
Cheers,
Jeff.
> On 18 Dec 2018, at 14:07, Adam Wolf wrote:
>
> Hi folks!
>
> I've been tracking a macOS issue that I thought was a packaging issue, but I
> think needs to be fixed in KiCad.
>
>
> You may want to tread carefully allowing users to accept invalid
> settings. They may cause crashes or other unexpected behavior bugs.
Will do. In most places where it really matters we weren’t trusting the
on-exit-validation anyway, and already have code in TransferDataFromWindow.
could be a way to determine the optimal color. i.e. check on a simple
> threshold either using one of two colors for contrast.
>
>
>
> On Thu, Nov 29, 2018 at 9:32 AM Wayne Stambaugh <mailto:stambau...@gmail.com>> wrote:
> On 11/29/2018 8:47 AM, Maciej Sumiński wrote:
While most UI guidelines suggest validating on field exit, it’s not without
cost. In particular, on GTK we can’t tell the difference between a KillFocus
from clicking the OK button (when validation should be run) and a KillFocus
from clicking Cancel (when it should not).
Needless to say,
501 - 600 of 1638 matches
Mail list logo
