User forums > Nightly builds

The 10 June 2019 build (11730) is out.

<< < (4/8) > >>

stahta01:
Untested patch


--- Code: ---From 2aeec896382ffafad6a57e08e1adf66b0e4017ad Mon Sep 17 00:00:00 2001
From: Tim Stahlhut <stahta01@gmail.com>
Date: Tue, 11 Jun 2019 08:39:53 -0400
Subject: Change wxCHECK_VERSION guard to 3.1.2

---
 src/sdk/globals.cpp | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/sdk/globals.cpp b/src/sdk/globals.cpp
index 5f9198e83..9083cf456 100644
--- a/src/sdk/globals.cpp
+++ b/src/sdk/globals.cpp
@@ -1174,11 +1174,11 @@ double cbGetContentScaleFactor(wxWindow &window)
 // For other platforms the value returned by GetContentScalingFactor seems adequate.
 double cbGetActualContentScaleFactor(wxWindow &window)
 {
-#if wxCHECK_VERSION(3, 1, 0)
+#if wxCHECK_VERSION(3, 1, 2)
     wxDisplay display(wxDisplay::GetFromWindow(&window));
     const wxSize ppi = display.GetPPI();
     return ppi.y / 96.0;
-#else // wxCHECK_VERSION(3, 1, 0)
+#else // wxCHECK_VERSION(3, 1, 2)
     // This code is the simplest version which works in the most common case.
     // If people complain that multi-monitor setups behave strangely, this should be revised with
     // direct calls to GTK/GDK functions.
@@ -1195,7 +1195,7 @@ double cbGetActualContentScaleFactor(wxWindow &window)
     // My guess is that smaller scaling factor would look better. Probably it has effect only in
     // multi monitor setups where there are monitors with different dpi.
     return std::min(ppiX / 96.0, ppiY /96.0);
-#endif // wxCHECK_VERSION(3, 1, 0)
+#endif // wxCHECK_VERSION(3, 1, 2)
 }
 #else // __WXGTK__
 double cbGetActualContentScaleFactor(wxWindow &window)
--

--- End code ---

Tim S.

trivia21:

--- Quote from: Miguel Gimenez on June 11, 2019, 02:40:44 pm ---Did you apply the change to the guard in globals.cpp before compilation with wx3.1.1?. If yes, can you post the error message?

--- End quote ---
Sorry, I mean compilation was successful, but I still can't modify key bindings.

killerbot:

--- Quote from: oBFusCATed on June 10, 2019, 08:10:42 pm ---
--- Quote from: Miguel Gimenez on June 10, 2019, 02:40:00 pm ---
--- Quote from: killerbot on June 10, 2019, 09:21:32 am ---the size has doubled of the zip file, I did not check why.

--- End quote ---

Because commit 11729 "moved all generated static libs to devel* folders" and update.bat copies them to the output folder. The zip has a lot of *.a files that shouldn't be there.

--- End quote ---
This is 100% deliberate decision.
The libs must be in the zip file. This would make it possible for third parties to build plugins for cb night builds without the need to build incompatible version of CB. This is the first step. Next steps would be to copy the includes and after that all the stuff related to wxwidgets also needs to be copied.

If some windows dev is interested to do the work I'd be happy to help.
If the size increase is too much we could probably make two separate zip files, but I don't 24mb is unbearable in 2019.

Also if someone wants to move bzip2 in a separate project I'd be happy to help with reviewing. I'm a bit tired of these cbp changes.

--- End quote ---

indeed, 24 MB , who cares these days.
But on the other hand is there a public out there for this use case ?

oBFusCATed:
I don't know if there are really people which want to do this, but other editors thrive around plugins. C::B is pretty poor in this regard.

There are some plugins which would become easier to build/ship if we're providing proper sdk. Like python plugins, cbsystemview, the fortran stuff could be removed from svn-external and be built easily separately.
Also this would be a preparation for shipping working sdk with the next release.

Xaviou:
Hi.

Linux build has been repaired and is working fine with wx-3.0

Rev 11738 for Debian Stretch (32 and 64 bits) can be installed from my repo.

Regards
Xav'

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version