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.1 alpha
2020.1 alpha [message #53123] Wed, 04 March 2020 12:23 Go to next message
mirek is currently offline  mirek
Messages: 12565
Registered: November 2005
Ultimate Member
I have mostly run to the end of my ToDo list for 2020.1, so I call current nightly build 2020.1 alpha. Hopefully, we will have final release in April.

Here are the new features for the 2020.1 (please tell me if I have missed something; I expect Koldo to add some points about ScatterCtrl):

Release highlights
* gtk3 replaces gtk2 as default linux backend
* Visual look&feel refactored in Linux and MacOS, improved dark theme support
* In Win32, PDB debugger now displays various U++ and standard library containers nicely
* Win32 release now ships with CLANG with llvm-mingw toolchain

Core
* SshExec improvements
* ConditionVariable and Semapthore now have Wait variant with timeout
* IsDoubleWidth function to detect double-width UNICODE glyphs
* MacOS is now using fast U++ heap when possible (not for new/delete)

CtrlCore
* Ctrl::GetAscendant utility method to get parent based on its type
* Dark mode is now enabled by default, CtrlLib: classic skin improvements
* MacOS multimonitor support and other fixes

CtrlLib
* Modernized widgets look in layout designer
* Added some less often used widgets like ColorPusher, TreeCtrl or ColumnList that were not previously directly supported in layout designer
* FileSel support of .lnk files in Win32
* Host native file selecteor, FileSelector, is now renamed to FileSelNative and is now available in MacOS too (in addition to Win32 and gtk3)
* GLCtrl in OpenGL/X11 refactored

Ide
* umk now implements use target directory flag (thanks Novo)
* Context goto (Alt+J) now able to detect files / links (and open the file / link in browser)
* Gdb frontend now can better handle executables without debug info
* Icon designer now can show synthetised UHD/Dark images
* New Insert file/clipboard as.. function allows insertion of clipboard or files directly to the text in various formats (C string, Base64 encode, raw byte values, compressed byte values using LZ4 or Zlib or LZMA).
* Move/Copy package function
* Find in files now has 3 output panes

Painter
* GetSVGPathBoundingBox function that gets bounding box of SVG path
* Xform2D::Map function creates matrix for affinity triangle->triangle mapping

SQL
* PGSQL got now can escape ? as ?? or use NoQuestionParams method to avoid interpreting ? as parameter holder
* SQL_RENAME .sch 'command' can be used to have different name of column in DB and code.

uppsrc
* In POSIX, external library dependencies are now refactored with pkg-config
Re: 2020.1 alpha [message #53131 is a reply to message #53123] Fri, 06 March 2020 06:06 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1046
Registered: December 2006
Experienced Contributor
Problem with linking on Mac.
Undefined symbols for architecture x86_64:
  "Upp::CocoBeep()", referenced from:
      Upp::BeepInformation() in Core$blitz.o
      Upp::BeepExclamation() in Core$blitz.o
      Upp::BeepError() in Core$blitz.o
      Upp::BeepQuestion() in Core$blitz.o
ld: symbol(s) not found for architecture x86_64

Tested against reference/Value


Regards,
Novo
Re: 2020.1 alpha [message #53132 is a reply to message #53131] Fri, 06 March 2020 10:26 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12565
Registered: November 2005
Ultimate Member
Novo wrote on Fri, 06 March 2020 06:06
Problem with linking on Mac.
Undefined symbols for architecture x86_64:
  "Upp::CocoBeep()", referenced from:
      Upp::BeepInformation() in Core$blitz.o
      Upp::BeepExclamation() in Core$blitz.o
      Upp::BeepError() in Core$blitz.o
      Upp::BeepQuestion() in Core$blitz.o
ld: symbol(s) not found for architecture x86_64

Tested against reference/Value


Thanks, should be now fixed.
Re: 2020.1 alpha [message #53134 is a reply to message #53132] Fri, 06 March 2020 11:59 Go to previous messageGo to next message
omari is currently offline  omari
Messages: 220
Registered: March 2010
Experienced Member
MacOS multimonitor issue, appear in the second monitor, when the monitors have different sizes. (the screenshot is from the second monitor)

i noticed that "Ctrl::GetPrimaryScreenArea()" return always the first screen.
Rect Ctrl::GetPrimaryScreenArea()
{
	for (NSScreen *screen in [NSScreen screens])
		return MakeScreenRect(screen, [screen frame]);
	return Rect(0, 0, 0, 0);
}


returning the screen that has the mouse pointer resolve the issue.

Rect Ctrl::GetPrimaryScreenArea()
{
	NSPoint mouseLoc = [NSEvent mouseLocation];
	NSEnumerator *screenEnum = [[NSScreen screens] objectEnumerator];
	NSScreen *screen;
	while ((screen = [screenEnum nextObject]) && !NSMouseInRect(mouseLoc, [screen frame], NO));
	                                                           
	if(screen)
		return MakeScreenRect(screen, [screen frame]);
	return Rect(0, 0, 1024, 768);
}


index.php?t=getfile&id=6002&private=0


regards
omari.
Re: 2020.1 alpha [message #53140 is a reply to message #53134] Sat, 07 March 2020 17:21 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12565
Registered: November 2005
Ultimate Member
omari wrote on Fri, 06 March 2020 11:59

Rect Ctrl::GetPrimaryScreenArea()
{
	NSPoint mouseLoc = [NSEvent mouseLocation];
	NSEnumerator *screenEnum = [[NSScreen screens] objectEnumerator];
	NSScreen *screen;
	while ((screen = [screenEnum nextObject]) && !NSMouseInRect(mouseLoc, [screen frame], NO));
	                                                           
	if(screen)
		return MakeScreenRect(screen, [screen frame]);
	return Rect(0, 0, 1024, 768);
}


index.php?t=getfile&id=6002&private=0


Thanks for catching this.

Well, GetPrimaryScreenArea definitely is not supposed to depend on the mouse, moreover it must rather depend on window's position than on mouse pos.

That said, the correct fix is quite similar - new method GetScreenArea(Point), now in trunk...

Mirek
Re: 2020.1 alpha [message #53171 is a reply to message #53140] Wed, 11 March 2020 23:26 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 685
Registered: August 2007
Contributor
Hello Mirek,

U++ applications fail to have window borders & actions, and have incorrect mouse input on Gnone 3 Wayland session (running on xwayland).

This was not the case with gtk2.

Here is a screenshot of TheIDE on Gnome wayland session (neither borders, window events, nor mouse or key events are correctly recognized):

index.php?t=getfile&id=6006&private=0


Here are the debug messages logged on terminal:

(theide:62665): Gdk-CRITICAL **: 01:16:06.150: gdk_monitor_get_workarea: assertion 'GDK_IS_MONITOR (monitor)' failed

(theide:62665): Gdk-CRITICAL **: 01:16:06.190: gdk_monitor_get_workarea: assertion 'GDK_IS_MONITOR (monitor)' failed

(theide:62665): Gdk-WARNING **: 01:16:06.289: Couldn't map as window 0x56455c0c0450 as popup because it doesn't have a parent

(theide:62665): GLib-GObject-WARNING **: 01:16:07.151: instance with invalid (NULL) class pointer

(theide:62665): GLib-GObject-CRITICAL **: 01:16:07.151: g_signal_emit_by_name: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(theide:62665): GLib-GObject-CRITICAL **: 01:16:07.151: g_object_get: assertion 'G_IS_OBJECT (object)' failed



Best regards,
Oblivion


[Updated on: Wed, 11 March 2020 23:29]

Report message to a moderator

Re: 2020.1 alpha [message #53174 is a reply to message #53171] Thu, 12 March 2020 09:31 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12565
Registered: November 2005
Ultimate Member
Oblivion wrote on Wed, 11 March 2020 23:26
Hello Mirek,

U++ applications fail to have window borders & actions, and have incorrect mouse input on Gnone 3 Wayland session (running on xwayland).


Sad

I really would appreciate help with this one - I have troubles to get any wayland desktop to work....

Is it even possible to run wayland in VirtualBox?
Re: 2020.1 alpha [message #53176 is a reply to message #53174] Thu, 12 March 2020 16:49 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 685
Registered: August 2007
Contributor
Hello Mirek,

Today I've looked into the issue more closely:

Good news:

Using the gdk_set_allowed_backends() function does the trick in a proper way.
It can be used to force a GTK3 app to use the x11 (xwayland) backend:

Excerpt from https://developer.gnome.org/gdk3/stable/gdk3-General.html
void
gdk_set_allowed_backends (const gchar *backends);

Sets a list of backends that GDK should try to use.

This can be be useful if your application does not work with certain GDK backends.

By default, GDK tries all included backends.

This call must happen prior to gdk_display_open(), gtk_init(), gtk_init_with_args() or gtk_init_check() in order to take effect.


So I've tried:

gdk_set_allowed_backends ("x11");


I'd suggest putting it into an INIT block.

Now the U++ apps, including TheIDE, are running smooth and fine on wayland. Smile

Quote:

Is it even possible to run wayland in VirtualBox?


Well, I tried Fedora 31 on VirtualBox. It uses wayland by default and runs just fine here. (No special setup)

I decided to move one of my PCs to Gnome (3.36) wayland backend (I'm using it for nearly two weeks and I'd say it is fantastic!)
Also my laptop (Gnome 3.34) runs wayland too (while wayland on 3.34 has some annoying problems. yet it works.)

What's common for my setups is that my machines don't have NVIDIA gfx cards. Do you use NVidia cards on your machine? Because wayland is known to be very buggy on NVIDIA's drivers.


Best regards,
Oblivion


[Updated on: Thu, 12 March 2020 16:57]

Report message to a moderator

Re: 2020.1 alpha [message #53177 is a reply to message #53176] Thu, 12 March 2020 17:19 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12565
Registered: November 2005
Ultimate Member
Perfect. I have tried to put it into InitGtkApp, can you please test unmodified trunk?

Mirek
Re: 2020.1 alpha [message #53178 is a reply to message #53177] Thu, 12 March 2020 17:58 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 685
Registered: August 2007
Contributor
Quote:
Perfect. I have tried to put it into InitGtkApp, can you please test unmodified trunk?


Done.
I've recompiled TheIDE and some U++ examples with GTK3 backend on Gnome (3.34).
Now they all work fine on both native X11, and xwayland backends.

Thanks!


I will give you feedback if I encounter any further problem or glitches on wayland...

Best regards,
Oblivion


Re: 2020.1 alpha [message #53181 is a reply to message #53123] Sat, 14 March 2020 03:20 Go to previous messageGo to next message
xue38495 is currently offline  xue38495
Messages: 2
Registered: March 2020
Junior Member
can you make a 32-bit version.
Re: 2020.1 alpha [message #53186 is a reply to message #53181] Sun, 15 March 2020 21:03 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12565
Registered: November 2005
Ultimate Member
We can. Do we want to?
Re: 2020.1 alpha [message #53188 is a reply to message #53186] Mon, 16 March 2020 22:24 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 660
Registered: September 2012
Location: Poland, Kraków
Contributor
Hello Mirek,

Can you look at following dark theme issues. I think there should be relativly easy to fix:
- https://www.ultimatepp.org/redmine/issues/2020
- https://www.ultimatepp.org/redmine/issues/2021

All reports came from Manjaro KDE Edition.

______________________________________
xue38495 - can you provied more information why you want 32-bit version of TheIDE? Also, please tell us what is your operating system?

Sincerely,
Klugier


Ultimate++ - one framework to rule them all.

[Updated on: Mon, 16 March 2020 22:26]

Report message to a moderator

Re: 2020.1 alpha [message #53193 is a reply to message #53188] Tue, 17 March 2020 10:16 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12565
Registered: November 2005
Ultimate Member
Providing info about the Manjaro theme active would be really helpfull... Smile
Re: 2020.1 alpha [message #53195 is a reply to message #53193] Tue, 17 March 2020 12:27 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 685
Registered: August 2007
Contributor
Hello Mirek,


Same problem for CodeEditor here with the adwaita-dark theme (gnome's default dark theme).

Also there is one other minor annoyance with the overall dark themes:

index.php?t=getfile&id=6010&private=0

As you can see the parameter/return types, qualifiers etc. are very hard to read on the navigator (and on other places as well), due to their color. That color (purple?) is particulary hard to read on dark backgrounds. IMO a different and lighter color would be great.

Best regards,
Oblivion


[Updated on: Tue, 17 March 2020 12:30]

Report message to a moderator

Re: 2020.1 alpha [message #53196 is a reply to message #53195] Tue, 17 March 2020 13:44 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 660
Registered: September 2012
Location: Poland, Kraków
Contributor
Hello Mirek,

I use "Breeth Dark" for Manjaro KDE. The code editor problem is universal for all dark theme. It is even observe on mac os basing on screenshot provieded by omari. The problem here is that editor bar is not dark theme griendly. It uses exactly the same colors for light/dark theme. Line numbers color should also be improved.

Sincerely,
Klugier


Ultimate++ - one framework to rule them all.
Re: 2020.1 alpha [message #53197 is a reply to message #53196] Tue, 17 March 2020 14:04 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12565
Registered: November 2005
Ultimate Member
Klugier wrote on Tue, 17 March 2020 13:44
Hello Mirek,

I use "Breeth Dark" for Manjaro KDE. The code editor problem is universal for all dark theme. It is even observe on mac os basing on screenshot provieded by omari. The problem here is that editor bar is not dark theme griendly. It uses exactly the same colors for light/dark theme. Line numbers color should also be improved.

Sincerely,
Klugier


Bar is already fixed, that was easy one. Placeholders are the problem Smile
Re: 2020.1 alpha [message #53198 is a reply to message #53197] Tue, 17 March 2020 15:37 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12565
Registered: November 2005
Ultimate Member
gtk3 / dark theme issues should be now fixed. Please check
Re: 2020.1 alpha [message #53199 is a reply to message #53198] Tue, 17 March 2020 15:57 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 685
Registered: August 2007
Contributor
Thanks!

It's much easier on the eyes now:


index.php?t=getfile&id=6011&private=0

Best regards,
Oblivion


Re: 2020.1 alpha [message #53204 is a reply to message #53123] Wed, 18 March 2020 18:50 Go to previous messageGo to previous message
Klugier is currently offline  Klugier
Messages: 660
Registered: September 2012
Location: Poland, Kraków
Contributor
Hello Mirek,

Small warning on macOS:
/../Applications/TheIDE.app/Contents/SharedSupport/uppsrc/ide/Browser/ItemDisplay.cpp (7): warning: unused variable 'dark' [-Wunused-variable]
 (): bool dark = IsDarkTheme();


Fix on trunk.

Sincerely,
Klugier


Ultimate++ - one framework to rule them all.

[Updated on: Wed, 18 March 2020 20:06]

Report message to a moderator

Previous Topic: U++/Win32 is now using CLANG toolchain
Next Topic: svn/github now has auto-generated Makefile
Goto Forum:
  


Current Time: Thu Jul 02 15:10:00 CEST 2020

Total time taken to generate the page: 0.01174 seconds