Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » U++ community news and announcements » 2020.2rc1
Re: 2020.2rc1 [message #55181 is a reply to message #55069] Fri, 16 October 2020 00:41 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 1091
Registered: August 2007
Senior Contributor
Hi,

There seems to be a problem with linking the latest freetype2 library (2.10.3) on Upp with GCC: 10.2.0, CLANG: 10.0.1, GNU ld: 2.35.

/usr/bin/ld: /home/maldoror/.cache/upp.out/Playground/Draw/GCC.Gui.Shared/Draw.a(FontFc.o): in function `Upp::GetFontInfoSys(Upp::Font)':
FontFc.cpp:(.text._ZN3Upp14GetFontInfoSysENS_4FontE+0x11a): undefined reference to `FT_Get_X11_Font_Format(FT_FaceRec_*)'



This can be fixed in FontFc.cpp, by putting the mentioned function into a C block:

extern "C" {
FT_EXPORT( const char* ) FT_Get_X11_Font_Format( FT_Face  face ); // Put here to avoid include path issues...
}


As a side note FT_Get_X11_Font_Format function name seems to be deprecated with v2.10.

Best regards,
Oblivion


[Updated on: Fri, 16 October 2020 00:49]

Report message to a moderator

Re: 2020.2rc1 [message #55185 is a reply to message #55180] Fri, 16 October 2020 09:40 Go to previous messageGo to next message
coolman is currently offline  coolman
Messages: 114
Registered: April 2006
Location: Czech Republic
Experienced Member
Klugier wrote on Fri, 16 October 2020 00:30
The idea is that someday we become mainstream Smile Beside that we could introduce some mainstream things still offering our uniqueness. In such case I do not think this big change in the philosophy or simplicity. I still think that we should keep with the best standards and practices for C/C++ if applicable. So moving in some areas towards mainstream solution is not something that we should afraid of. This will give us broader horizons

Also, we have some mismatch between templates - Tutrlte is using different namespace notaiton to that present in CtrlLib. We should unify this.

In the case of namespace agnostic we should give people choice (by simply checkbox in template). Anyway more and more people people are using this approach. Example is available here.

Anyway, the decision is always yours - you are the boss Smile


Hi, I'm pleased with the example you have given. But at the same time, I must say that there is a small problem Assist++ and using namespace.

BR, Radek
Re: 2020.2rc1 [message #55186 is a reply to message #55180] Fri, 16 October 2020 09:55 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Klugier wrote on Fri, 16 October 2020 00:30
The idea is that someday we become mainstream Smile Beside that we could introduce some mainstream things still offering our uniqueness. In such case I do not think this big change in the philosophy or simplicity. I still think that we should keep with the best standards and practices for C/C++ if applicable. So moving in some areas towards mainstream solution is not something that we should afraid of. This will give us broader horizons


If we become mainstream, maybe so will become "using namespace" Smile

Realistically, I agree with most things in "mainstream", but there are several dogmas that seem out of context. This is one of them...

Think about what you gain / loose by having / not having using namespace Upp in the header....

In practical terms, with using namespace, you can use U++ types without qualification at the risk of nameclash with either your own code or some other namespace that you have are "using". In the case of nameclash, you have to explicitly qualify namespace. Note that there also is no chance for error: nameclash is reported at compile time.

Without "using namespace", you have to qualify everything. Does not seem like a win option to me...

BTW, now thinking about it, I really dislike

namespace Upp {
#define LAYOUTFILE <Rajce/Rajce.lay>
#include <CtrlCore/lay.h>
} // namespace Upp


- that is something we should fix in the next release. This should work without Upp... I think the most correct fix is in the Layout designer - add namespace setting to .usc file and make layout designer to use it / insert into .lay....

Mirek

[Updated on: Fri, 16 October 2020 10:03]

Report message to a moderator

Re: 2020.2rc1 [message #55189 is a reply to message #55181] Fri, 16 October 2020 11:26 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Oblivion wrote on Fri, 16 October 2020 00:41
Hi,

There seems to be a problem with linking the latest freetype2 library (2.10.3) on Upp with GCC: 10.2.0, CLANG: 10.0.1, GNU ld: 2.35.

/usr/bin/ld: /home/maldoror/.cache/upp.out/Playground/Draw/GCC.Gui.Shared/Draw.a(FontFc.o): in function `Upp::GetFontInfoSys(Upp::Font)':
FontFc.cpp:(.text._ZN3Upp14GetFontInfoSysENS_4FontE+0x11a): undefined reference to `FT_Get_X11_Font_Format(FT_FaceRec_*)'



This can be fixed in FontFc.cpp, by putting the mentioned function into a C block:

extern "C" {
FT_EXPORT( const char* ) FT_Get_X11_Font_Format( FT_Face  face ); // Put here to avoid include path issues...
}


As a side note FT_Get_X11_Font_Format function name seems to be deprecated with v2.10.

Best regards,
Oblivion


FT_Get_X11_Font_Format now removed: the info that it provides is not much relevant anyway (we used it to check that font is truetype - scaleable, but today all fonts are and U++ unconditionally expects that anyway) and I have replaced the test with testing the font path extension.

I hope this was the last one for 2020.2 Smile

Mirek
Re: 2020.2rc1 [message #55190 is a reply to message #55189] Fri, 16 October 2020 11:49 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1075
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
Hello Mirek,

I just noticed on macOS (latest nightly and macOS 10.15 catalina) that when opnion from menubar open new window the highlight in global menu stays. Screenshot below:
index.php?t=getfile&id=6262&private=0

I remembered we had similari ssue in the past and it seems like the regression...

Klugier


U++ - one framework to rule them all.
Re: 2020.2rc1 [message #55191 is a reply to message #55190] Fri, 16 October 2020 14:13 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Klugier wrote on Fri, 16 October 2020 11:49
Hello Mirek,

I just noticed on macOS


Just stop it Smile

OK, I am going to consider this more of cosmetics issue. I will file it in RM; if there are no more issues, this is not blocker, if there are, I will fix it in next rc3...

Mirek
Re: 2020.2rc1 [message #55221 is a reply to message #55191] Tue, 20 October 2020 09:40 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
In case it was missed, there is now rc2 on the sf.net....

As there no complaints so far, I am thinking about releasing soon...

Re: 2020.2rc1 [message #55224 is a reply to message #55221] Tue, 20 October 2020 21:03 Go to previous message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
Hi Mirek,

Not missed! I have been working with this since day one it was released and have no complaints so far.

Thanks and best regards,

Tom

EDIT: Well not this, but the RC2 of course!

[Updated on: Tue, 20 October 2020 21:04]

Report message to a moderator

Previous Topic: clang windows -FPIC not supported
Next Topic: 2020.2rc2
Goto Forum:
  


Current Time: Thu Mar 28 15:47:12 CET 2024

Total time taken to generate the page: 0.01049 seconds