---
CMakeLists.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index cb06aca24..c9c8784ae 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -639,7 +639,7 @@ include( MinGWResourceCompiler )
# Find GDI+ on windows if wxGraphicsContext is
---
CMakeLists.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index a639fab0f..a17a912cb 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -638,7 +638,7 @@ find_package( Boost 1.54.0 REQUIRED COMPONENTS context
system )
include(
Hi,
On 31.10.2018 14:42, Strontium wrote:
>> The error was 'BadValue (integer parameter out of range for operation)'.
>> (Details: serial 8548 error_code 2 request_code 154 minor_code 24)
The segmentation fault happens because the error handler for X errors
tries to exit the program, and
Hi,
On 26.10.2018 22:18, Maciej Suminski wrote:
> I have not pushed the patch yet, as I still wonder whether adding
> another CMake flag is a good idea. Just now I realized that there are
> just a few extra commands to create the needed files, so perhaps they
> could be executed by the build
Hi,
On 26.10.2018 22:30, Maciej Suminski wrote:
> What about libngspice.so.0 symlink? Which package ships that? Anyway, it
> makes sense to request a particular version of the library in case the
> API changes in the future.
The .so.0 symlink is created from the SONAME field in the library.
Hi,
On 24.10.2018 13:48, John Beard wrote:
> In which case does flipping the CMake add_subdirectory order work
> (attached patch).
It may appear to work.
> If this *does* work, any clues as to why only MSVC cares?
The MSVC build had the qa subdirectory removed completely, because the
mock
Hi,
On 10/23/2018 02:10 PM, Jeff Young wrote:
> I plan to add a IS_NET_TIE flag to graphic items to fix it. (This appears
> compatible with the net tie discussions of yore on the email list.) There
> will be a checkbox in Graphic Item Properties to set it.
I'd like to make these obsolete as
Hi,
On 22.10.2018 16:55, Mark Roszko wrote:
>>I'd rather have the view, tools and core frameworks independent from
>> any UI toolkit.
> Yes! Things change. The world develops as KiCad develops as well.
> Building into QT heavily just like wxWidgets could have the same
> ramifications later
In standard compliant mode, msys2 behaves like msvc and does not define
M_PI et al. without _USE_MATH_DEFINES
---
CMakeLists.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index cf55d49e7b..9c835aaeab 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
The latter is non-standard and not guaranteed to be available
---
3d-viewer/3d_cache/3d_cache.cpp | 2 +-
3d-viewer/3d_cache/3d_plugin_manager.cpp | 2 +-
common/streamwrapper.cpp | 2 +-
include/kicad_curl/kicad_curl.h | 2 +-
include/streamwrapper.h
-msys2-patch/165
Simon Richter (3):
Set _USE_MATH_DEFINES on Windows
Genericize Unicode switch on Windows
Use _WIN32, not WIN32
3d-viewer/3d_cache/3d_cache.cpp | 2 +-
3d-viewer/3d_cache/3d_plugin_manager.cpp | 2 +-
CMakeLists.txt | 16
Both UNICODE and _UNICODE are required, on all Windows compilers.
---
CMakeLists.txt | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 9c835aaeab..5ce1048736 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -182,6 +182,9 @@
Hi,
On 19.10.2018 21:34, Simon Richter wrote:
> In standard compliant mode, msys2 behaves like msvc and does not define
> M_PI et al. without _USE_MATH_DEFINES
There is going to be another version that consolidates the Windows
specific stuff a bit better.
Simon
signature.asc
Descr
In standard compliant mode, msys2 behaves like msvc and does not define
M_PI et al. without _USE_MATH_DEFINES
---
CMakeLists.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index e3bca991fc..2421e024bf 100644
--- a/CMakeLists.txt
+++
Variable length arrays are not in the C++ standard, also it makes our stack
frame size unpredictable.
---
common/utf8.cpp | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/common/utf8.cpp b/common/utf8.cpp
index 1895955806..76c40cef9d 100644
--- a/common/utf8.cpp
+++
This is a gcc/clang extension, not standard C++
---
CMakeLists.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 6dd010b6ae..249566f1e6 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -205,6 +205,13 @@ if( CMAKE_COMPILER_IS_GNUCXX OR
We want to be somewhat standards compliant if we can.
---
CMakeLists.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index bc2a8e9f7e..6dd010b6ae 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -127,6 +127,7 @@ set( CMAKE_POSITION_INDEPENDENT_CODE ON )
Hi,
once again the MSVC build is broken because we have a variable length array:
common\utf8.cpp(207): error C2131: expression did not evaluate to a constant
Would it make sense to add -Werror=vla to avoid using gcc-specific extensions?
Simon
Hi Jeff,
On 10/17/2018 12:01 AM, Jeff Young wrote:
> I think one of the original justifications of dyn_cast<> was that it was
> faster. Do I have that wrong, or do we not believe it to be material?
It probably is faster, as comparing values can be inlined, while
dynamic_cast<> cannot. Whether
Hi,
eeschema/class_libentry.cpp, line 414ff:
if( field.IsVisible() && !aOpts.draw_visible_fields )
continue;
if( !field.IsVisible() && !aOpts.draw_hidden_fields )
continue;
Is this art, or can it be removed?
Simon
Hi,
On 10/16/2018 06:19 PM, Wayne Stambaugh wrote:
>> The “Footprint graphic items” bug was a dyn_cast when a dynamic_cast was
>> needed (dyn_cast doesn’t handle inheritance).
> Do you want me to file a bug report on this or are you going to fix it
> right away?
I have a patch that eliminates
Hi Seth,
On 10/11/2018 07:39 PM, Seth Hillbrand wrote:
> Are you generating symbol files for KiCad on the nightly builds? If so,
> where can I find them in the install?
These should be Release builds, so no debug information.
The toplevel CMakeLists.txt complains if someone tries to build
Hi, Jeff,
On 10/10/2018 12:21 AM, Jeff Young wrote:
> Can you say more about the net ties code? Does it have a properties dialog?
Not during placement, I think, and I hope to get away without any
properties dialog.
The general idea is that net ties exist either standalone or modify a
via or
Hi,
On 10/08/2018 08:59 AM, Maciej Sumiński wrote:
> The only reasonable way to make wxDC and Cairo compatible is via
> wxGraphicsContext, as it uses Cairo underneath.
wxDC also uses Cairo internally when wx is linked against GTK3. :P
Windows binaries for the cairo_printing branch can be found
Hi,
My net ties code no longer gives me a preview item once I select the
tool, which I find annoying. I've traced this to commit c655bffac1,
where placement with IPO_PROPERTIES no longer gives a preview item,
because the first click would open a properties dialog.
Via placement has set this flag
Hi,
> Really guys, this is an amazing bit of work you've put together. From> my
> end, I don't see show stoppers to merging to master.
I have a build failure on MSVC for b487a155f:
eeschema\dialogs\dialog_fields_editor_global.cpp(727): error C2039:
'SetColumnWidth': is not a member of
Hi,
On 26.09.2018 17:21, Wayne Stambaugh wrote:
> Does anyone know why we search for the boost unit test framework library
> in every test sub-folder? I'm guessing it's because we want to be able
> to build tests on an individual basis but it's adds a lot of redundant
> overhead during
Hi,
On 24.09.2018 16:15, Wayne Stambaugh wrote:
> Does this affect the 5.0 branch as well?
No, it's a fixup for Orson's "Refactored logic in Spice model editor
dialog" change, which isn't in the 5.0 branch.
Simon
signature.asc
Description: OpenPGP digital signature
Hi,
patch ping: this is a trivial change, dialog_spice_model.cpp needs
for std::toupper.
Simon
On 22.09.2018 22:32, Simon Richter wrote:
> ---
> eeschema/dialogs/dialog_spice_model.cpp | 2 ++
> 1 file changed, 2 insertions(+)
>
signature.asc
Description: OpenPGP digit
---
eeschema/dialogs/dialog_spice_model.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eeschema/dialogs/dialog_spice_model.cpp b/eeschema/dialogs/dialog_spice_model.cpp
index b0bec2b27..a2549e626 100644
--- a/eeschema/dialogs/dialog_spice_model.cpp
+++
Hi,
On 22.09.2018 02:12, Seth Hillbrand wrote:
>>It will need a way to turn it off.
> Say a command-line switch? e.g --disable-crashreporter
The distro maintainers probably need a compile time option for apport,
I'd prefer that as well because I don't have to remember it when starting.
>
Hi,
On 20.09.2018 11:49, Thomas Pointhuber wrote:
> the current code is more or less a minimal implementation. It would be a
> good idea to add the build parameters like displayed in about_config,
> configuration files, environment variables,... in the future as well.
It will need a way to turn
---
common/tool/tool_manager.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/common/tool/tool_manager.cpp b/common/tool/tool_manager.cpp
index 0fa7214c6..3233d1cbe 100644
--- a/common/tool/tool_manager.cpp
+++ b/common/tool/tool_manager.cpp
@@ -109,7 +109,7 @@ struct
Hi,
On 19.09.2018 18:38, Thomas Pointhuber wrote:
> For now, it uses the glibc backtrace function to print a basic
> stack-trace onto the console, and if possible a crash dump file in the
> current working directory.
Then it needs to at least be made glibc specific.
I'm not fond of these
Hi,
> My language team: Simplified Chinese, name: Liu Guang .
Romanized spelling only for the credits, or should we use Hanzi?
Simon
signature.asc
Description: OpenPGP digital signature
___
Mailing list:
Hi,
On 10.09.2018 01:22, Jeff Young wrote:
> New set of commits pushed.
Built as #135:
http://downloads.kicad-pcb.org/windows/testing/patched/kicad-patched-135-4a57541b7-x86_64.exe
Simon
signature.asc
Description: OpenPGP digital signature
Hi,
in case anyone needs Windows binaries to test,
http://downloads.kicad-pcb.org/windows/testing/patched/kicad-patched-134-d3c82b0b5-x86_64.exe
is the state of the GAL branch of yesterday evening.
The branch also compiles fine on MSVC.
Simon
Hi,
On 28.08.2018 21:56, Anthony Tonizzo wrote:
> 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
Hi,
On 06.08.2018 18:35, Seth Hillbrand wrote:
> What are people's opinions on adding an additional boost dependency?
I would never have thought to say these words out loud, but in general I
prefer not reinventing the wheel.
Another Boost dependency is vastly preferable to having a block of
Hi,
On 04.08.2018 15:23, jp charras wrote:
> The commit f3f814e622b2ed1af0b31c28665811fba15959dc breaks the
> compilation on Windows.
This also fixes MSVC.
Simon
signature.asc
Description: OpenPGP digital signature
___
Mailing list:
Hi,
On 04.08.2018 13:03, Jeff Young wrote:
> - new /experimental/ features get an option?
Yes, if there is a chance it needs to be excised from a release.
Simon
signature.asc
Description: OpenPGP digital signature
___
Mailing list:
Hi,
On 04.08.2018 11:53, Jeff Young wrote:
> I thought Alexis’s strategy for the View Footprints in Symbol Chooser
> experimental feature worked well.
That would mean:
- new features get an option
- the option defaults to ON during development
- options that should not be released are
Hi,
On 03.08.2018 06:06, Adam Wolf wrote:
> It works fine with macOS, and I've already enabled it for nightlies.
It has also been active for Windows nightlies for quite some time, so
people were confused when it was suddenly off in the release version.
So in addition to a decision on the
Hi,
there is a patch submission on the KiCad forum. The submitter doesn't
want to post to the mailing list for fear of spam.
https://forum.kicad.info/t/patch-that-fixes-doxygen-typos-and-any-other-misc-typos-in-general/11804
Looks good to me, does anyone feel like merging it?
Simon
Hi,
On 31.07.2018 20:28, Seth Hillbrand wrote:
> It would be a good idea to update the standard version. The current
> link points to a fork that is not maintained.
>
> I suggest we standardize to 3.8.0
> (https://github.com/wxFormBuilder/wxFormBuilder/releases/tag/v3.8.0)
I've built Debian
Hi,
On 31.07.2018 16:19, Wayne Stambaugh wrote:
>> From Wayne's email of the 7th Feb 2017, "After the next stable
>> release, we should not be using wxFormbuilder for new code."
> This is my personal preference but I'm not the only developer who
> creates dialogs. I would rather have buy in
Hi,
On 27.07.2018 21:57, Adam Wolf wrote:
> Do we think the scripting menu stuff will be mature enough to turn on by
> default soon?
It's enabled in the nightlies, but disabled in the release build. One
user has complained already[1], and I've given them a build with the
action menu enabled and
---
pcbnew/dialogs/dialog_plot.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pcbnew/dialogs/dialog_plot.cpp b/pcbnew/dialogs/dialog_plot.cpp
index 04ad117a7..e43008cc6 100644
--- a/pcbnew/dialogs/dialog_plot.cpp
+++ b/pcbnew/dialogs/dialog_plot.cpp
@@ -495,7 +495,7 @@
Hi,
On 25.07.2018 18:00, Wayne Stambaugh wrote:
> The 5.1 branch will go away. I just haven't gotten around to it.
Even better.
Simon
signature.asc
Description: OpenPGP digital signature
___
Mailing list:
Hi,
On 25.07.2018 18:18, Wayne Stambaugh wrote:
> I guess we will have to wait until Nick returns from vacation to get
> this resolved.
I just pointed Jenkins at my fork, but that's bad style, basically.
Simon
signature.asc
Description: OpenPGP digital signature
Hi,
On 25.07.2018 14:16, Wayne Stambaugh wrote:
> We should have created a release build of the stable version. I'm fine
> with nightly builds having debugging information. Stable releases
> should not have debug info.
These are built as RelWithDebInfo, and the debug information is stripped
Hi,
On 25.07.2018 14:25, Wayne Stambaugh wrote:
> It seems to me that 5.1.0-dev would sort before 5.1.0-rc1 or am I
> missing something?
We already have tricks in place to sort RC before the release (without
suffix), which is annoying as is but an established convention.
IMO, any tag that
Hi,
On 24.07.2018 09:01, Maciej Sumiński wrote:
> At the moment the master branch contains all commits from 5.1 and a few
> more. It might be the right moment to drop 5.1 branch.
As it should be. Well, ideally commits on 5.1 should be cherry-picked
from master by the 5.1 release manager.
Do we
Hi,
On 24.07.2018 09:40, Eeli Kaikkonen wrote:
> The version string which is the visible version information seems to be
> 6.0 something. It has already caused confusion for those who use
> nightlies. I hope this will be fixed permanently. Is there any hope to
> get it changed to something
Hi,
I've started collecting a few ideas on use cases for the new component
format. I suspect others have done the same.
Is there a good place to collect all of these and/or collaboratively
edit them?
Simon
# KiCad Schematic Components: Use Cases
This document tries to capture the use cases
Hi,
On 22.07.2018 23:21, Jeff Young wrote:
> This patch doesn’t apply cleanly on master. Can you rebase it?
I rebased the entire stack onto master before sending. The smaller
reverts in front are needed for the big patch to apply cleanly.
Simon
signature.asc
Description: OpenPGP digital
This reverts commit 2206d51b82ab1353b33e78a18ebc4d6970ff05db.
---
include/system/libcontext.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/system/libcontext.h b/include/system/libcontext.h
index e274e4315..1a94ca2d1 100644
--- a/include/system/libcontext.h
This reverts commit eedf7cb243cf15ab0e7e0da4ae5331473f3df4c5.
---
CMakeLists.txt | 7 +-
common/CMakeLists.txt| 2 -
common/system/libcontext.cpp | 712 ---
include/system/libcontext.h | 95 --
include/tool/coroutine.h |
This reverts commit 679074fdb28c88977cf69847bd9dff38ba636b8e.
---
include/system/libcontext.h | 107 ++--
1 file changed, 53 insertions(+), 54 deletions(-)
diff --git a/include/system/libcontext.h b/include/system/libcontext.h
index a69fd9ef2..b45540fe2
This reverts commit 4b5482eb5a43b061a1aed3726ca067a09f227c98.
---
include/system/libcontext.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/system/libcontext.h b/include/system/libcontext.h
index 1a94ca2d1..a69fd9ef2 100644
--- a/include/system/libcontext.h
+++
This reverts commit 7f9202842d1850f48c609e744cc75acaa20fc20b.
---
include/tool/coroutine.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/tool/coroutine.h b/include/tool/coroutine.h
index 5aedc3ecb..d55e9858f 100644
--- a/include/tool/coroutine.h
+++
Hi,
the MSVC builds have reverted the coroutine patches for quite some time
now, and it seems to work unless you attempt to compile against Boost 1.61.
Here's the current coroutine related stack on the msvc branch. Does this
break anything for anyone?
Simon
signature.asc
Description:
Hi,
On 22.07.2018 18:44, Wayne Stambaugh wrote:
> I just pushed the updated version of the v5 release announcement[1].
> Please let me know if you find any missing features.
The download/source page claims that 5.0.0 can not be compiled against
Boost 1.61 and later because of C++11. I think
Hi,
I've just rebuilt the latest MSYS2 nightly and the rc3 package in
/windows/testing with signing enabled, so these should now install with
fewer complaints.
Simon
signature.asc
Description: OpenPGP digital signature
___
Mailing list:
Hi,
> This will get 3 separate SHA (one for each branch). Or would you prefer
> us to use git merge to keep the original SHA with an additional merge
> commit? I can see arguments for each but wanted to check which is
> preferred.
To make merge commits work, they'd have to be based on the
Hi,
On 07/16/2018 04:24 PM, Tomasz Wlostowski wrote:
> Why do we need any inheritance at all? My only guess is to make Kicad
> even more hackerish and difficult to understand.
It would allow getting rid of the really annoying redundancies in the
library:
- all transistor symbols exist in six
Hi,
On 16.07.2018 11:19, Jeff Young wrote:
> Do we plan on having inheritance replace aliases?
I do, but you might have noticed that with all my other commitments that
isn't worth much.
Do we have a spec document beyond what was discussed on IRC?
> If so, what do we do with old symbols?
Hi,
On 15.07.2018 13:39, Jeff Young wrote:
> I renamed my 6.0 branch to 5.1, since most of what it contains goes there.
What is the difference between 5.1 and 6.0? What goes into which branch?
Simon
signature.asc
Description: OpenPGP digital signature
Hi,
On 11.07.2018 21:51, Wayne Stambaugh wrote:
> This probably should have been done as a cpp string wrapped with the
> translation macro _(). I'm not sure there is anything we can do to make
> this translatable. Anyone else have any ideas?
We could move the entire text to the user
Hi,
On 11.07.2018 19:10, Wayne Stambaugh wrote:
> I just went to http://darine.hogyros.de:8080/job/any-kicad-doc-head/ and
> I cannot load the web page.
Yes, I finally got around to installing an SSL certificate so I could
give out accounts without having unencrypted passwords floating around.
Hi,
On 06/28/2018 09:26 PM, Seth Hillbrand wrote:
> The shared declaration was unintentional, so I've removed it. As an
> aside, does anyone know the right gcc flag to get these warnings? Mine
> is very happy to overlook this but apparently other versions are not.
There is none. I build
Hi,
Commit 0748c118d introduced a line
#pragma omp parallel shared( m_itemList ) ...
MSVC rejects this, as m_itemList is a subobject of this, and sharing
subobjects is not allowed in the OpenMP specification:
A variable that is part of another variable (as an array or structure
Hi Seth,
On 06/28/2018 07:56 PM, Seth Hillbrand wrote:
> Understood. What's the impact of the array assignment now?
MSVC refuses to compile it.
It seems to be an artefact from a gcc extension that allows the result
of a ternary to be an lvalue if both branches are, but I don't think
that
The ternary operator decays array arguments to pointers, so they can no
longer be assigned to array references.
---
common/lib_id.cpp | 64 ++-
1 file changed, 30 insertions(+), 34 deletions(-)
diff --git a/common/lib_id.cpp
Hi,
> I agree that the assignment is non-standard and probably should be
> updated. However, if we're going to re-write this, would you be up for
> doing it with std:: algorithms?
I've thought about this too, but as this function looks at each character
in isolation, we'd end up with a fairly
The ternary operator decays array arguments to pointers, so they can no
longer be assigned to array references.
---
common/lib_id.cpp | 71 ++-
1 file changed, 39 insertions(+), 32 deletions(-)
diff --git a/common/lib_id.cpp
These casts have the same source and destination type, and are therefore
useless.
Also, enable warnings for tautological casts, with an exception for the
SWIG wrapper code.
---
3d-viewer/3d_cache/dialogs/panel_prev_model.cpp| 2 +-
3d-viewer/3d_cache/sg/sg_helpers.h | 4
haps not as
intended.
As with the last big patch, this is just a heads-up; these patches live in
my tree and I plan to carry them forward until accepted or someone tells me
off.
Simon
Simon Richter (1):
Remove tautological casts
3d-viewer/3d_cache/dialogs/panel_prev_model.cpp| 2 +-
3
Hi,
I'm doing a bit of refactoring, and keep stumbling over weird bits that
may be historical, fix an actual problem or both, but where it isn't
immediately obvious what is happening.
For example, the LIB_EDIT_FRAME::copySelectedItems() deselects fields in
order to not copy them -- simply
Hi,
this is for the 6.0 series. No functional changes, but fail at compile time
instead of runtime if an EDA_ITEM descendant doesn't implement Clone().
Simon Richter (1):
Make EDA_ITEM::Clone() abstract
common/base_struct.cpp | 7 ---
eeschema/class_libentry.h
This avoids missing Clone functions in derived classes, at the expense of
six bytes per call site, or so.
---
common/base_struct.cpp | 7 ---
eeschema/class_libentry.h| 12
eeschema/sch_collectors.cpp | 6 ++
Hi,
On 12.06.2018 16:54, Marco Ciampa wrote:
>> I guess that there are some new dependencies that needs to be installed as
>> of https://github.com/KiCad/kicad-doc/issues/588
> Every day it does not work I miss revisions from users...
FWIW, I have a working setup at
---
eeschema/sch_component.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/eeschema/sch_component.cpp b/eeschema/sch_component.cpp
index c7cfd4ae4..018d34545 100644
--- a/eeschema/sch_component.cpp
+++ b/eeschema/sch_component.cpp
@@ -54,6 +54,7 @@
#include
#include
+#include
Hi,
On 01.06.2018 21:18, Steven A. Falco wrote:
> I am starting to look at packaging KiCad 5.0.0 for Fedora. I can download
> source tars from the 4.X series using URLs like:
> https://code.launchpad.net/kicad/4.0/4.0.0-rc2/+download/kicad-4.0.0-rc2.tar.xz
Hi,
On 01.06.2018 06:36, Seth Hillbrand wrote:
> Do people have concerns with the risk exposure for this patch or would
> anyone like some additional time to evaluate?
I think this needs a round of user testing, and doing it this late in
the 5.0 cycle (post rc2) would delay the release.
If
Hi,
On 28.05.2018 15:15, Nick Østergaard wrote:
> I agree with Simon that we are likely to have an rc3. We can just rename
> the milestone if we change our mind. Afterall it does not cost us anything.
To me, a "release candidate" is something we feel could be a release
unless the wider testing
Hi,
it seems we have a translation quality problem for some languages, as
gettext's default behaviour for new strings is to copy a string with a
similar msgid and mark the result as "fuzzy".
This is useful when only small changes occur, but needs a lot of manual
oversight. As an example, in
Hi,
On 26.05.2018 16:40, Wayne Stambaugh wrote:
> Do we really need an rc3? I was going to make 5.0.0 the next milestone.
> I think (hope) most of the bug fixes will be polishing at this point.
If we're not going to release rc2 as it is, then it makes sense to make
an rc3, test it, and retag
Hi,
On 18.05.2018 17:38, Wayne Stambaugh wrote:
> I propose we spend some time immediately after the v5 release
> and fix the gtk3 issues before we start making major changes to the code
> base so that it is not difficult to back port. Anyone else have any
> thoughts on this?
We could make
Hi,
On 15.05.2018 10:40, Nick Østergaard wrote:
> The occ patch makes the build fail on macos when enabling oce. I don't
> understanf why the error message suggest the occ path instead of the occ
> one. Also I don't understand why the defualt would not work as before.
FWIW, it also makes MSVC
Hi Nick,
On 30.04.2018 16:35, Nick Østergaard wrote:
> @Simon, does MAKE_INSTALL_DATADIR work for gnu stow? If so, I guess it
> is safer to use that variable, as we do elsewhere.
The problem I'm addressing with my patch is configure time vs. install
time path resolution -- if you explicitly use
Hi Wayne,
On 30.04.2018 16:45, Wayne Stambaugh wrote:
> I merged your patch. Thanks. Did you look to see if referencing
> CMAKE_INSTALL_PREFIX was used anywhere else? There may be some other
> cases lurking in our cmake files.
I grepped through the source tree to find these, so this should
Hi,
On 30.04.2018 15:45, Wayne Stambaugh wrote:
> I'm not sure GNUInstallDir wont break all other platform installs so I'm
> a bit reluctant to use it this close to v5 release. We certainly take a
> look at it for v6. Is there some way to force GNUInstallDirs at config
> time on the cmake
This is substituted at configuration time, creating an absolute path, which
breaks overriding CMAKE_INSTALL_PREFIX at installation time, breaking the
workflow for installation using GNU stow.
---
CMakeLists.txt | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
Hi,
On 24.04.2018 10:59, Jeff Young wrote:
> I also noticed that the Apple guidelines suggest /not/ putting colons on
> sections. Perhaps most platforms inform screen readers that a section
> label is a section? (Anyone know if wxWidgets has screen-reader-helper
> code?)
Yes, colons indicate
---
common/utf8.cpp | 2 +-
eeschema/cross-probing.cpp| 2 +-
eeschema/dialogs/dialog_edit_components_libid.cpp | 2 +-
eeschema/libarch.cpp | 2 +-
eeschema/sch_component.cpp| 2 +-
There is no need to reassign these.
---
common/trace_helpers.cpp | 20 ++--
include/trace_helpers.h | 20 ++--
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/common/trace_helpers.cpp b/common/trace_helpers.cpp
index bf5244cf9..5379980fc 100644
There was already a string definition that wasn't used, so it's obvious
that was intended.
---
eeschema/lib_pin.cpp | 1 +
eeschema/sch_component.cpp | 2 ++
eeschema/sch_field.cpp | 1 +
eeschema/sch_item_struct.h | 10 --
eeschema/sch_sheet.cpp | 1 +
---
common/trace_helpers.cpp | 544 +++
include/trace_helpers.h | 230 ++--
2 files changed, 387 insertions(+), 387 deletions(-)
diff --git a/common/trace_helpers.cpp b/common/trace_helpers.cpp
index 5379980fc..5b6ea28a5 100644
---
Declaration and definition of trace strings differed in constness.
---
common/trace_helpers.cpp | 2 ++
include/trace_helpers.h | 18 +-
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/common/trace_helpers.cpp b/common/trace_helpers.cpp
index
201 - 300 of 898 matches
Mail list logo
