Hi Tom,
I pushed changes to
https://git.launchpad.net/~jeyjey/kicad/log/?h=tom-eeschema-gal-aug27.
This includes converting the Choose Symbol dialog to GAL, moving the
GAL_DISPLAY_OPTIONS to common, and support for multi-unit parts.
I’ll go on to the Symbol Viewer next
Cheers,
Jeff.
PS:
Hi Devs-
A heads up that I pushed a change to our GAL display layers. This fixes a
issue where the selected item would cover the overlay items such as mouse
tips and measurement tool.
This commit adds a LAYER_SELECT_OVERLAY GAL layer that is rendered under
the NETNAMES layers. I put highlight
On 28/08/18 23:57, Andrey Kuznetsov wrote:
> Remember about OpenGL and
> MacOS:
> https://appleinsider.com/articles/18/06/04/opengl-opencl-deprecated-in-favor-of-metal-2-in-macos-1014-mojave
Deprecated doesn't mean it will disappear anytime soon.
Metal/Vulkan/Mantle/DX12 are cool for games
Remember about OpenGL and MacOS:
https://appleinsider.com/articles/18/06/04/opengl-opencl-deprecated-in-favor-of-metal-2-in-macos-1014-mojave
On Tue, Aug 28, 2018 at 2:40 PM, Jeff Young wrote:
> >> My solution would be to stick to OpenGL with hardware antialiasing.
>
> To my knowledge none of
>> My solution would be to stick to OpenGL with hardware antialiasing.
To my knowledge none of the Mac graphics cards have an issue with OpenGL, so
this is also my plan.
Cheers,
Jeff.
> On 28 Aug 2018, at 22:32, Tomasz Wlostowski wrote:
>
> On 28/08/18 19:55, Seth Hillbrand wrote:
>> OK.
On 28/08/18 19:55, Seth Hillbrand wrote:
> OK. Then, you should be able to scale the cairo context by 0.5 and draw
> individual pixels instead of 2x2 blocks.
It doesn't work this way on OSX. If you want smooth graphics, you either
have to request a full resolution framebuffer (see
On 28/08/18 15:30, Jeff Young wrote:
> I tried to push my changes so you could review them before I get too far, but
> I don’t appear to have write privileges on your repo.
Jeff, you don't need any privileges in my repo. Push this branch to any
of your repos and send me the link :)
Tom
Recently during the manual layout of a board with many
differential pairs I noticed that there was no button to add
a diff-pair the way there is a button for regular tracks.
Rather, adding diff-pairs is currently accomplished using
a menu entry.
This patch adds a button to the draw toolbar (just
I've been mulling this over and the majority of developers seem to
prefer wxFormbuilder so I will continue to allow it to be used for
creating dialogs. However, I am relaxing the policy so new dialog can
be created by hand at the preference of the developer. The only
restriction I am placing is
On 8/28/2018 2:03 PM, Jeff Young wrote:
> Got it: OPENGL_ANTIALIASING_MODE::SUPERSAMPLING_X4.
>
> (We weren’t picking this up because it’s saved in the Pcbnew section.
> We probably want to move it to Common. There isn’t any reason you’d
> want a different setting for Pcbnew and Eeschema is
Just to be sure i will ask the other librarians how strict they where
with our policy. (Sadly on the symbol side git is not of much help so i
really need to rely on their word. I will also make some manual checks.)
For the future we might think about getting check scripts developed that
check
Got it: OPENGL_ANTIALIASING_MODE::SUPERSAMPLING_X4.
(We weren’t picking this up because it’s saved in the Pcbnew section. We
probably want to move it to Common. There isn’t any reason you’d want a
different setting for Pcbnew and Eeschema is there?)
> On 28 Aug 2018, at 18:21, Wayne
OK. Then, you should be able to scale the cairo context by 0.5 and draw
individual pixels instead of 2x2 blocks.
-S
Am Di., 28. Aug. 2018 um 10:35 Uhr schrieb Jeff Young :
> Scratch that last comment; I got myself tied in knots.
>
> It is Cairo that renders blocky.
>
>
> On 28 Aug 2018, at
On 8/28/2018 12:48 PM, Rene Pöschl wrote:
> Right now we have no changes made that would break projects. (That is
> what i meant with "backwards compatibility" I know it is not quite the
> right term)
>
> Also i thought the cache lib plus rescue dialog should take care of
> minor changes to
Do we need to write a macos GAL object that uses the native macos device
context? This seems redundant to me because isn't that the purpose of
wxDC and it's derivatives?
On 8/28/2018 1:11 PM, Jeff Young wrote:
> Hi Seth,
>
> The scaling comes out correct, it’s just blocky.
>
> Is there some
Interesting. It’s not Cairo.
We currently have EDA_DRAW_PANEL_GAL hard-coded to OpenGL, so it’s actually
OpenGL that’s rendering blocky….
> On 28 Aug 2018, at 18:11, Jeff Young wrote:
>
> Hi Seth,
>
> The scaling comes out correct, it’s just blocky.
>
> Is there some way to adjust what
Scratch that last comment; I got myself tied in knots.
It is Cairo that renders blocky.
> On 28 Aug 2018, at 18:29, Jeff Young wrote:
>
> Interesting. It’s not Cairo.
>
> We currently have EDA_DRAW_PANEL_GAL hard-coded to OpenGL, so it’s actually
> OpenGL that’s rendering blocky….
>
>
>>
Hi Seth,
The scaling comes out correct, it’s just blocky.
Is there some way to adjust what Cairo thinks the screen resolution is and then
re-scale the canvas so that everything comes out the same again? I don’t know.
Cheers,
Jeff.
> On 28 Aug 2018, at 18:06, Seth Hillbrand wrote:
>
> Can
Can we just use cairo_scale to adjust the axes for Mac retina?
-S
Am Di., 28. Aug. 2018 um 09:59 Uhr schrieb Jeff Young :
> JP made the Footprint Wizard Cairo-only recently, and I planned to do the
> same for the Eeschema dialog previews.
>
> However, I’ve just discovered that Cairo doesn’t
JP made the Footprint Wizard Cairo-only recently, and I planned to do the same
for the Eeschema dialog previews.
However, I’ve just discovered that Cairo doesn’t handle Retina displays on Mac.
(It essentially draws blocks of 2x2 pixels instead of individual ones.)
Anyone know if this is
Right now we have no changes made that would break projects. (That is
what i meant with "backwards compatibility" I know it is not quite the
right term)
Also i thought the cache lib plus rescue dialog should take care of
minor changes to symbols if the user does not want to update a symbol
I would be careful with any library improvements during stable bug fix
releases, particularly for symbol and 3d model libraries which are
linked rather than embedded. My preference would be to just use the
same libraries tagged for the 5.0.0 release to keep changes to user
designs to a minimum.
Is it planned to include a new version of the libraries as well?
Right now we ensure that the library is relatively stable so i think the
improvements made since the v5 release can easily be included.
(We do not allow major changes that would break backward compatibility.
My plan is to use this
Kevin, that is partly correct. But it is casued because the master
branch on Tom's repo is very old. This should not be needed anymore,
if it was not removed completely. There should not be any need for bzr
anymore.
On Tue, 28 Aug 2018 at 16:46, Kevin Cozens wrote:
>
> On 2018-08-27 03:43 PM,
On 2018-08-27 03:43 PM, Jeff Young wrote:
But when I do a make install I’m getting:
[ 1%] creating 'boost scratch repo' specifically for boost to track boost
patches
make[2]: bzr: No such file or directory
make[2]: ***
I created SCH_PREVIEW_PANEL which inherits from EDA_DRAW_PANEL_GAL but *not*
EDA_DRAW_PANEL.
It is pretty light-weight, just including the non-event-related stuff from
SCH_DRAW_PANEL.
Works a treat.
I tried to push my changes so you could review them before I get too far, but I
don’t appear
Hi Tom,
Thanks for the overview.
The trouble I’m running into is that in the meantime when I instantiate a
SCH_DRAW_PANEL, it inherits from legacy_gal/EDA_DRAW_PANEL, which presumes
inclusion in a EDA_DRAW_FRAME.
If I drop down to EDA_DRAW_PANEL_GAL, then I’m missing the SCH-specific stuff.
On 28/08/18 12:12, Jeff Young wrote:
> Another question:
>
> Right now we have SCH_DRAW_PANEL which inherits from EDA_DRAW_PANEL and
> EDA_DRAW_PANEL_GAL. Since EDA_DRAW_PANEL mediates the connection between the
> drawing canvas and the parent EDA_FRAME,
Hi Jeff,
Indeed, EDA_DRAW_PANEL had
On 28/08/18 11:33, Jeff Young wrote:
> Hi Tom,
>
> You mentioned earlier:
>
>> You can make your copy and push your patches there, rebasing on top of
>> current master from time to time.
>
> which I’m not sure I understood. We can’t use rebase on a shared
> branch, right?
>
Hi Jeff,
What I
Another question:
Right now we have SCH_DRAW_PANEL which inherits from EDA_DRAW_PANEL and
EDA_DRAW_PANEL_GAL. Since EDA_DRAW_PANEL mediates the connection between the
drawing canvas and the parent EDA_FRAME, this assumes that all SCH GAL
canvasses will be in frames (which isn’t true for
Hi Tom,
You mentioned earlier:
> You can make your copy and push your patches there, rebasing on top of
> current master from time to time.
which I’m not sure I understood. We can’t use rebase on a shared branch, right?
Does this mean we’ll coordinate so that everyone is fully committed, then
Ah, that is clever.
But I already exposed classes needed to do it in swig
https://github.com/KiCad/kicad-source-mirror/commit/72fcf46430286d62739eacab67bf964ba1ae8d88
On Mon, Aug 27, 2018 at 11:38 PM mitjan696-ubu...@yahoo.co.uk <
mitjan696-ubu...@yahoo.co.uk> wrote:
> I don't know if this is
I don't know if this is exactly what you are looking for, but you should take a
look at how Miles Mccoo clones zones in his python script
https://github.com/mmccoo/kicad_mmccoo/blob/master/replicatelayout/replicatelayout.py
lines 215-224 and 15-20
Regards, Mitja
On Monday, 27 August 2018,
33 matches
Mail list logo
