Seth,
I'm fine with this approach. I like your idea of deriving a new
UNIT_BINDER object so that it doesn't impact the other frames that do
not use ORIGIN_TRANSFORMS.
Cheers,
Wayne
On 5/26/19 4:15 PM, Seth Hillbrand wrote:
> Hi All-
>
> If Reece can separate this so that it doesn't affect
Jon,
I've asked Reece to make Seth's recommended change to lower the merge
impact so it will probably be a while until thus is completed. Go ahead
and cherry-pick the backlog from 5.1.
Thanks,
Wayne
On 5/26/19 3:54 PM, Jon Evans wrote:
> Hi Reece, Wayne, Seth,
>
> Can you clarify the path
Hi Bernhard,
I had to update CLion because the debugger had started hanging on assert()s.
The CLion upgrade gave me a “use settings from previous version”, but it
doesn’t appear to be 100%. I found a couple of paths that were different so
I’ve reset them, done a clean, and am starting a full
The “sub-apps” shouldn’t have a Frameworks folder, but use the one from the
“parent” Kicad.app (otherwise all the libs would be duplicated).
Did you maybe issue a “make install” in your build folder?
After that (I guess due to rewriting the paths, including all the dependencies,
and all what
Hi All-
If Reece can separate this so that it doesn't affect eeschema, cvpcb,
pagelayout_editor, gerbview or libedit, I'm fine with merging as is and
refactoring more later. If we merge this as is, it become much more
difficult to fix it later.
Since these are all GetMsgPanelInfo() calls,
I can no longer run pl_editor.
It pukes trying to open dlls in
bin/Kicad.app/Contents/Applications/pl_editor.app/Contents/Frameworks/.
If I copy Frameworks/ from bin/Kicad.app/Contents/Frameworks/ then it works
fine (but nukes it the next time I build).
The other apps don’t have a Frameworks/
Hi Reece, Wayne, Seth,
Can you clarify the path forward here? Are we going to merge the second
patchset and then do follow-ons to take care of the issues Seth raised, or
will there be another full patchset coming?
I have a backlog of things to cherry-pick from 5.1 to master that I've been
So _now_ it occurs to me that what I should have done was create classes
derived from UNIT_BINDER that handle the different types of data (X-abs,
Y-abs, X-rel, Y-rel) and instantiated those, rather than adding a
parameter to the UNIT_BINDER class.
However, that would have also required
- On May 26, 2019, at 10:53 AM, Seth Hillbrand wrote:
> Hi Reece-
> Apologies for the double-tap here. I see I miss-read your intention in
> a couple of places! Sorry about that. I'll try to clean up my comments
> below.
> I also noticed a few other bits and knobs that would be good to
On 2019-05-26 11:01, Reece Pollack wrote:
Trust me, I'm not excited about passing the ORIGIN_TRANSFORMS
reference as a parameter. The patch files that do nothing except add
this parameter to the GetMsgPanelInfo() and GetSelectMenuText()
methods are the two biggest in the set, at 1673 and 1488
The PageLayout Editor is a different beast entirely. Items have either one
point (text, image) or two (line, rectangle). Each point can be anchored to
one of the four margin corners (or the page top-left). Each point is
interpreted as a vector *toward* the centre of the page.
So to draw a
Hi all,
This question is particularly for JP since you have written the relevant
code.
Why is SCH_VIEW initialized to such a small size compared to the area that
is accessible if you zoom out?
You can see in my screenshot that the view boundary is initialized to the
pink rectangle, but it is
> Hi Reece-
> I've had a chance to test this a bit. It works really nicely. Thanks
> for the good idea here.
Thanks! Just a classic case of "This annoys me so much that I'm going to fix
it".
> I only noticed one spot where it wasn't transformed so far: the
> Measurement tool. When used, it
Hi Reece-
Apologies for the double-tap here. I see I miss-read your intention in
a couple of places! Sorry about that. I'll try to clean up my comments
below.
I also noticed a few other bits and knobs that would be good to clean in
the final patchset. Let me know if you'd like a hand
14 matches
Mail list logo
