Home » Community » U++ community news and announcements » 2020.1 alpha
| Re: 2020.1 alpha [message #53265 is a reply to message #53264] |
Wed, 25 March 2020 14:51   |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Well, it gives a whole bunch of these:
C:\upp-svn\upp.src\uppsrc\Core\InetUtil.cpp(333): warning C4927: illegal conversion; more than one user-defined conversion has been implicitly applied
C:\upp-svn\upp.src\uppsrc\Core\InetUtil.cpp(333): note: while calling the constructor 'Upp::String::String(const char *)'
C:\upp-svn\upp.src\uppsrc\Core\AString.hpp(310): note: see declaration of 'Upp::String::String'
63 warnings in Core...
And Microsoft is still 'Considering' this issue...
Best regards,
Tom
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: 2020.1 alpha [message #53301 is a reply to message #53287] |
Thu, 26 March 2020 23:53 |
Novo
Messages: 1431
Registered: December 2006
|
Ultimate Contributor |
|
|
koldo wrote on Thu, 26 March 2020 08:09koldo wrote on Thu, 26 March 2020 12:48Please review install instructions in https://www.ultimatepp.org/www$uppweb$uppx11$en-us.html as it says to install libgtk2.0-dev. Reviewed for Ubuntu. Please check if it is right for Fedora and other distros.
I always thought that this release is gtk3-based ...
Am I missing something?
What gtk2 is needed for?
Regards,
Novo
|
|
|
|
|
|
| Re: 2020.1 alpha [message #53307 is a reply to message #53306] |
Fri, 27 March 2020 17:19 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
busiek wrote on Fri, 27 March 2020 18:08Tom1 wrote on Wed, 25 March 2020 10:53Hi,
I just noticed that the current version has a visualization issue with the edge rectangle of entryfields, lists, etc. I confirmed all these issues on UWord with current version. This can be seen in e.g. standard FileSel where the file and directory lists and the File entryfield all lack vertical edges. Additionally, if the width of the FileSel is increased by dragging, the horizontal edges do not extend all the way to the right edge of each panel. There are also some other corner effects that look strange on UWord main window.
TheIDE does not show these problems for me possibly because I have 'Dark' theme selected there.
Best regards,
Tom
I have the same problem on Windows with the newest trunk. Just checked 2 hours ago. I am using MSVC 2019 and default theme. Simply edit fields seem to have too narrow painting rectangle.
Jakub
Hi Jakub,
The problem is in the recent version of MSVC2019 / MSBT2019 compiler:
https://developercommunity.visualstudio.com/content/problem/ 912723/recent-version-of-visual-c-compiler-might-have-ove.ht ml
Please try MSVC2017 / MSBT2017 instead. (Or the newly available CLANG-MINGW combo, which is looking promising...) 
Best regards,
Tom
|
|
|
|
| Re: 2020.1 alpha [message #53308 is a reply to message #53306] |
Fri, 27 March 2020 17:21 |
 |
mirek
Messages: 14291
Registered: November 2005
|
Ultimate Member |
|
|
busiek wrote on Fri, 27 March 2020 17:08Tom1 wrote on Wed, 25 March 2020 10:53Hi,
I just noticed that the current version has a visualization issue with the edge rectangle of entryfields, lists, etc. I confirmed all these issues on UWord with current version. This can be seen in e.g. standard FileSel where the file and directory lists and the File entryfield all lack vertical edges. Additionally, if the width of the FileSel is increased by dragging, the horizontal edges do not extend all the way to the right edge of each panel. There are also some other corner effects that look strange on UWord main window.
TheIDE does not show these problems for me possibly because I have 'Dark' theme selected there.
Best regards,
Tom
I have the same problem on Windows with the newest trunk. Just checked 2 hours ago. I am using MSVC 2019 and default theme. Simply edit fields seem to have too narrow painting rectangle.
Jakub
Are you getting these warnings? If yes, you are too victim of broken compiler...
Mirek
|
|
|
|
| Re: 2020.1 alpha [message #53309 is a reply to message #53308] |
Fri, 27 March 2020 17:23 |
busiek
Messages: 71
Registered: February 2011
Location: Poland
|
Member |
|
|
mirek wrote on Fri, 27 March 2020 17:21busiek wrote on Fri, 27 March 2020 17:08Tom1 wrote on Wed, 25 March 2020 10:53Hi,
I just noticed that the current version has a visualization issue with the edge rectangle of entryfields, lists, etc. I confirmed all these issues on UWord with current version. This can be seen in e.g. standard FileSel where the file and directory lists and the File entryfield all lack vertical edges. Additionally, if the width of the FileSel is increased by dragging, the horizontal edges do not extend all the way to the right edge of each panel. There are also some other corner effects that look strange on UWord main window.
TheIDE does not show these problems for me possibly because I have 'Dark' theme selected there.
Best regards,
Tom
I have the same problem on Windows with the newest trunk. Just checked 2 hours ago. I am using MSVC 2019 and default theme. Simply edit fields seem to have too narrow painting rectangle.
Jakub
Are you getting these warnings? If yes, you are too victim of broken compiler...
Mirek
I'll check that the next time I will be under Windows.
|
|
|
|
| Re: 2020.1 alpha [message #53336 is a reply to message #53309] |
Sun, 29 March 2020 22:04 |
Novo
Messages: 1431
Registered: December 2006
|
Ultimate Contributor |
|
|
It would be great to add support of "Use unique output directory per assembly (append assembly name to output directory)" to umk. I tried to do that by myself, but got lost in different variants of SaveVars/LoadVars. I couldn't figure out how to force umk to use assembly name as a folder name. I was always getting a different folder name.
TIA
Regards,
Novo
|
|
|
|
|
|
| Re: 2020.1 alpha [message #53339 is a reply to message #53337] |
Mon, 30 March 2020 01:26 |
Novo
Messages: 1431
Registered: December 2006
|
Ultimate Contributor |
|
|
Sender Ghost wrote on Sun, 29 March 2020 16:55Novo wrote on Sun, 29 March 2020 20:04
I couldn't figure out how to force umk to use assembly name as a folder name. I was always getting a different folder name.
There is a possibility to specify output directory/file for umk. Just need to use absolute path to available output directory or create it before umk usage.
For example:
% mkdir -p out/uppsrc
% ./umk uppsrc ide CLANG -brs +GUI ${PWD}/out/uppsrc/theide
<..>
% ./umk uppsrc ide CLANG -brs +GUI ${PWD}/out/uppsrc
<..>
% ls -1 out/uppsrc
ide
theide
Thanks. I knew that it is possible to pass to umk an absolute path to an output directory.
But it is much more convenient to pass an extra-option and get behavior identical to TheIDE.
Regards,
Novo
|
|
|
|
| Re: 2020.1 alpha [message #53352 is a reply to message #53339] |
Mon, 30 March 2020 13:43 |
 |
amrein
Messages: 278
Registered: August 2008
Location: France
|
Experienced Member |
|
|
It would be great to have an extra umk parameter to specify the configuration folder instead of having to pass the absolute path.
With absolute path, the generated Makefile is static (it uses absolute path within).
[Updated on: Mon, 30 March 2020 13:43] Report message to a moderator |
|
|
|
|
|
|
|
| Re: 2020.1 alpha [message #53367 is a reply to message #53361] |
Tue, 31 March 2020 13:02 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Hi Mirek,
I'm using the wonderful new Xform2D::Map() to render a raster map image over a specific area with specific corner coordinates. This is a great feature, but BufferPainter::Fill(image) suffers from edge effects at the borders of the image fill. The fill leaves narrow gaps between the filled triangles. Both FILL_FAST and FILL_EXACT exhibit this problem. Even a simple BufferPainter::Fill(Blue()) exhibits this issue, although the gap seems slightly narrower then.
At this time I would like to be able to use at least FILL_FAST. Can you take a look at this?
Here's a testcase:
#include <CtrlLib/CtrlLib.h>
using namespace Upp;
class PainterImageMapping : public TopWindow {
public:
typedef PainterImageMapping CLASSNAME;
PainterImageMapping(){
Sizeable();
}
virtual void Paint(Draw &draw){
ImageBuffer ib(GetSize());
{
ImageBuffer imb(500,500);
{
BufferPainter iw(imb);
iw.Clear(Black());
}
Image img(imb);
// image coordinates
Pointf iNW(0,0);
Pointf iNE(img.GetWidth(),0);
Pointf iSW(0,img.GetHeight());
Pointf iSE(img.GetWidth(),img.GetHeight());
BufferPainter w(ib);
w.Clear(White());
dword flags=FILL_FAST;
//dword flags=FILL_EXACT;
{
Pointf nw(100,100);
Pointf ne(700,100);
Pointf sw(100,700);
Pointf se(650,750);
w.Move(nw).Line(ne).Line(se).Fill(img, Xform2D::Map(iNW,iNE,iSE,nw,ne,se), flags);
w.Move(nw).Line(sw).Line(se).Fill(img, Xform2D::Map(iNW,iSW,iSE,nw,sw,se), flags);
}
{
Pointf nw(700,100);
Pointf ne(1400,120);
Pointf sw(650,750);
Pointf se(1300,720);
w.Move(nw).Line(ne).Line(se).Fill(img, Xform2D::Map(iNW,iNE,iSE,nw,ne,se), flags);
w.Move(nw).Line(sw).Line(se).Fill(img, Xform2D::Map(iNW,iSW,iSE,nw,sw,se), flags);
}
{
Pointf nw(100,700);
Pointf ne(650,750);
Pointf sw(100,1200);
Pointf se(650,1350);
w.Move(nw).Line(ne).Line(se).Fill(img, Xform2D::Map(iNW,iNE,iSE,nw,ne,se), flags);
w.Move(nw).Line(sw).Line(se).Fill(img, Xform2D::Map(iNW,iSW,iSE,nw,sw,se), flags);
}
{
Pointf nw(650,750);
Pointf ne(1300,720);
Pointf sw(650,1350);
Pointf se(1300,1220);
w.Move(nw).Line(ne).Line(se).Fill(img, Xform2D::Map(iNW,iNE,iSE,nw,ne,se), flags);
w.Move(nw).Line(sw).Line(se).Fill(img, Xform2D::Map(iNW,iSW,iSE,nw,sw,se), flags);
}
w.Finish();
}
SetSurface(draw,Rect(ib.GetSize()),ib,ib.GetSize(),Point(0,0));
}
};
GUI_APP_MAIN
{
PainterImageMapping().Run();
}
Best regards,
Tom
[EDIT] - Expanded testcase to include another row of tiles. This effectively adds (nearly) horizontal facing edges.
[Updated on: Tue, 31 March 2020 13:23] Report message to a moderator |
|
|
|
|
|
|
|
| Re: 2020.1 alpha [message #53373 is a reply to message #53370] |
Tue, 31 March 2020 15:28 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Hi,
I tried with MODE_NOAA too, but some of the borders still show a 'dashed' gap. It is sharper of course in this case.
Could it be possible to fix those gaps seen in MODE_NOAA rendering and then internally use that mode with FILL_FAST while rest of the rendering is done according to the selected mode?
Or is there any other known way around this issue to clean up the visual appearance?
Best regards,
Tom
|
|
|
|
| Re: 2020.1 alpha [message #53374 is a reply to message #53370] |
Tue, 31 March 2020 15:46 |
|
mirek
Messages: 14291
Registered: November 2005
|
Ultimate Member |
|
|
Ugly quick fix:
#include <CtrlLib/CtrlLib.h>
using namespace Upp;
class PainterImageMapping : public TopWindow {
public:
typedef PainterImageMapping CLASSNAME;
PainterImageMapping(){
Sizeable();
}
virtual void Paint(Draw &draw){
DrawPainter w(draw, GetSize());
Image img = CreateImage(Size(500, 500), Black());
// image coordinates
Pointf iNW(0,0);
Pointf iNE(img.GetWidth(),0);
Pointf iSW(0,img.GetHeight());
Pointf iSE(img.GetWidth(),img.GetHeight());
w.Clear(White());
dword flags=FILL_FAST;
auto Do = [&](const Xform2D xform) {
w.Fill(img, xform, flags).Stroke(2, img, xform, flags);
};
{
Pointf nw(100,100);
Pointf ne(700,100);
Pointf sw(100,700);
Pointf se(650,750);
w.Move(nw).Line(ne).Line(se); Do(Xform2D::Map(iNW,iNE,iSE,nw,ne,se));
w.Move(nw).Line(sw).Line(se); Do(Xform2D::Map(iNW,iSW,iSE,nw,sw,se));
}
{
Pointf nw(700,100);
Pointf ne(1400,120);
Pointf sw(650,750);
Pointf se(1300,720);
w.Move(nw).Line(ne).Line(se); Do(Xform2D::Map(iNW,iNE,iSE,nw,ne,se));
w.Move(nw).Line(sw).Line(se); Do(Xform2D::Map(iNW,iSW,iSE,nw,sw,se));
}
{
Pointf nw(100,700);
Pointf ne(650,750);
Pointf sw(100,1200);
Pointf se(650,1350);
w.Move(nw).Line(ne).Line(se); Do(Xform2D::Map(iNW,iNE,iSE,nw,ne,se));
w.Move(nw).Line(sw).Line(se); Do(Xform2D::Map(iNW,iSW,iSE,nw,sw,se));
}
{
Pointf nw(650,750);
Pointf ne(1300,720);
Pointf sw(650,1350);
Pointf se(1300,1220);
w.Move(nw).Line(ne).Line(se); Do(Xform2D::Map(iNW,iNE,iSE,nw,ne,se));
w.Move(nw).Line(sw).Line(se); Do(Xform2D::Map(iNW,iSW,iSE,nw,sw,se));
}
}
};
GUI_APP_MAIN
{
PainterImageMapping().Run();
}
[Updated on: Tue, 31 March 2020 15:47] Report message to a moderator |
|
|
|
|
|
| Re: 2020.1 alpha [message #53379 is a reply to message #53375] |
Tue, 31 March 2020 19:09 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Hi,
OK, Thanks. It (adding Stroke) does work indeed, but the penalty is 40% increase in execution time.
-
Interestingly, this combo works too:
BufferPainter w(ib,MODE_NOAA);
dword flags=FILL_HREFLECT|FILL_VREFLECT|FILL_FAST;
But of course I do not wish to use MODE_NOAA as it ruins everything else.
Could this observation be used to tweak the same behavior out of BufferPainter using MODE_ANTIALIASED with minor modifications?
IMO, switching internally temporarily to MODE_NOAA while rendering with FILL_FAST is quite OK -- if only possible.
Best regards,
Tom
[Updated on: Tue, 31 March 2020 19:10] Report message to a moderator |
|
|
|
|
|
| Re: 2020.1 alpha [message #53383 is a reply to message #53380] |
Tue, 31 March 2020 22:04 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Hi,
Thanks Mirek! It works just perfectly.
I used the following pattern to sufficiently overlap and expand the triangles:
w.Move(nw+Pointf(-2,-1)).Line(ne+Pointf(1,-1)).Line(se+Pointf(1,1)).Fill(img, Xform2D::Map(iNW,iNE,iSE,nw,ne,se), flags);
w.Move(nw+Pointf(-1,-1)).Line(sw+Pointf(-1,1)).Line(se+Pointf(2,1)).Fill(img, Xform2D::Map(iNW,iSW,iSE,nw,sw,se), flags);
And: No observable slowdown!
Thanks and best regards,
Tom
|
|
|
|
Goto Forum:
Current Time: Sat May 30 04:41:34 GMT+2 2026
Total time taken to generate the page: 0.00870 seconds
|
U++ framework
Search
Help
Members
Register
Login
Home
