|
|
Home » Community » U++ community news and announcements » Gearing up for 2022.1 release...
Gearing up for 2022.1 release... [message #58145] |
Thu, 03 March 2022 09:29  |
 |
mirek
Messages: 14255 Registered: November 2005
|
Ultimate Member |
|
|
IME support took longer than expected, but with that done, I think it is time for another release.
Current list of major changes:
- sizeof(wchar) is changed to 4 (32 bits) to support non BMP unicode characters
This might bring some incompatibilities in the code that expects wchar to be 16 bit, which
escpecially involves dealing with Win32 (and to lesser extend MacOS) APIs, so if your application
is doing that, please check all instances of WCHAR (UniChar on MacOS) or even wchar
especially type casts.
To support host APIs, char16 is introduced (but there is no 16-bit String varian).
Use ToSystemCharsetW, FromSystemCharsetW to convert texts to Win32 API.
- Support of drawing non-BMP characters in GUI
- Vastly improved character font replacement code (when drawing characters missing with requested font, replacement font is used)
- Last instances of Win32 ANSI calls (those ending with A) are removed
- UTF handling routines are refactored and their's naming is unified
- RTF is now being able to handle non-BMP characters (RTF is used as clipboard format for RichText)
- Improved input method (aka preedit in Linux, aka marked text in MacOS) support
Other minor changes:
- fixed TryRealloc issue
- improved MemoryCheck
- Removed MemoryAlloc48/MemoryFree48
- In theide Background parsing should less often cause delays in the main thread
Win32 release:
- updated clang to actual version (llvm14)
- zlib updated to 1.2.12
- openssl updated to 1.1.1n
- jpeg updated to 9e
If you have any issue to fix before the release, please post it here.
[Updated on: Tue, 05 April 2022 17:53] Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Gearing up for 2022.1 release... [message #58181 is a reply to message #58173] |
Wed, 09 March 2022 10:18   |
pvictor
Messages: 75 Registered: December 2015
|
Member |
|
|
pvictor wrote on Mon, 07 March 2022 18:08mirek wrote on Sun, 06 March 2022 20:13
OK, not too much happy about this late new feature, but done... Pls check.
I've checked it on Linux.
It works OK.
Thank you.
Victor
FileSelNative works fine both in Linux and Windows.
However the public interfaces aren't the same:
Windows Linux
void Serialize(Stream& s);
void New();
bool IsNew() const;
bool Execute(bool open, const char *title = NULL); bool Execute(bool open, const char *title = NULL);
bool ExecuteOpen(const char *title = NULL); bool ExecuteOpen(const char *title = NULL);
bool ExecuteSaveAs(const char *title = NULL); bool ExecuteSaveAs(const char *title = NULL);
bool ExecuteSelectDir(const char *title = NULL); bool ExecuteSelectDir(const char *title = NULL);
String Get() const; String Get() const;
void Set(const String& s); void Set(const String& s);
operator String() const; operator String() const;
void operator=(const String& s); void operator=(const String& s);
String operator~() const; String operator~() const;
void operator<<=(const String& s); void operator<<=(const String& s);
int GetCount() const; int GetCount() const;
const String& operator[](int i) const; const String& operator[](int i) const;
bool GetReadOnly() const;
String GetActiveDir() const;
FileSelNative& Type(const char *name, const char *ext); FileSelNative& Type(const char *name, const char *ext);
FileSelNative& AllFilesType(); FileSelNative& AllFilesType();
FileSelNative& ActiveDir(const String& dir); FileSelNative& ActiveDir(const String& dir);
FileSelNative& ActiveType(int i); FileSelNative& ActiveType(int i);
FileSelNative& DefaultExt(const char *ext);
FileSelNative& Multi(bool b = true); FileSelNative& Multi(bool b = true);
FileSelNative& ReadOnlyOption(bool b = true);
FileSelNative& Asking(bool b = true); FileSelNative& Asking(bool b = true);
FileSelNative& NoAsking(); FileSelNative& NoAsking();
FileSelNative& ShowHidden(bool b = true);
Best regards,
Victor
|
|
|
Re: Gearing up for 2022.1 release... [message #58182 is a reply to message #58145] |
Fri, 11 March 2022 12:35   |
Tom1
Messages: 1301 Registered: March 2007
|
Ultimate Contributor |
|
|
Hi,
I just tried to do a fresh install of the current nightly on a clean Raspberry Pi 4 system. I cannot seem to get the dependencies right. First it was package 'fontconfig' but I seem to end up in a complicated dependency mess that cannot be solved.
The OS is the latest Raspbian OS (11 bullseye) updated to date.
Does anybody have a similar setup to test this and possibly solve the issue.
Thanks and best regards,
Tom
|
|
|
Re: Gearing up for 2022.1 release... [message #58183 is a reply to message #58182] |
Fri, 11 March 2022 12:42   |
Tom1
Messages: 1301 Registered: March 2007
|
Ultimate Contributor |
|
|
Hi,
Under Windows, compiling with 'MSBT22x64 Release' I get:
C:\upp-git\upp.src\uppsrc\Draw\FontCR.cpp(440): warning C4244: 'argument': conversion from 'T' to 'int', possible loss of data
with
[
T=double
]
Best regards,
Tom
|
|
|
|
|
|
|
Re: Gearing up for 2022.1 release... [message #58199 is a reply to message #58198] |
Sat, 19 March 2022 17:52   |
Tom1
Messages: 1301 Registered: March 2007
|
Ultimate Contributor |
|
|
Hi Mirek,
Now I'm on the freshly installed Raspberry OS 64-bit, the same as I linked for you. Here the ./install works for setting up the dependencies and starts compilation as expected.
However, the compilation fails with error:
./uppsrc/Core/Ops.h: In function 'Upp::byte Upp::addc64(Upp::uint64&, const uint64&, Upp::byte)':
./uppsrc/Core/Ops.h:223:9: error: '_addcarry_u64' was not declared in this scope
223 | return _addcarry_u64(carry, result, value, &result);
I do not know if there are more issues as the compilation stops to this error.
Best regards,
Tom
|
|
|
Re: Gearing up for 2022.1 release... [message #58200 is a reply to message #58199] |
Sat, 19 March 2022 18:42   |
 |
Klugier
Messages: 1099 Registered: September 2012 Location: Poland, Kraków
|
Senior Contributor |
|
|
Hello Tom,
I have the same problem on M1 Mac when compiling application for native executable. _addcarry_u64 is not compatible with ARM architecture, so I think there must be a problem with #ifdefs.
Klugier
U++ - one framework to rule them all.
[Updated on: Sat, 19 March 2022 18:42] Report message to a moderator
|
|
|
Goto Forum:
Current Time: Fri Apr 25 20:36:57 CEST 2025
Total time taken to generate the page: 0.01182 seconds
|
|
|