nana icon indicating copy to clipboard operation
nana copied to clipboard

Thank you to contributors

Open cnjinhao opened this issue 4 years ago • 20 comments

Thank you to each person who contributed. Today I merged the changes of pull requests for hotfix-1.7.4 into branch develop-1.8, I encountered many conflicts and fixed these conflicts manually, now I am not sure if the changes will be OK. I wonder if you all(@qPCR4vir @besh81 @ErrorFlynn ) could try the develop-1.8 to check if these changes works.

cnjinhao avatar Aug 24 '20 13:08 cnjinhao

hotfix-1.7.4 seems to be ok (cmake-minwg-gcc and VS2019 preview, windows7).

develop-1.8 compile and run, but place works badly.

qPCR4vir avatar Aug 24 '20 22:08 qPCR4vir

Hi, @qPCR4vir What is the display scaling settings on your Windows? I tried the example https://github.com/qPCR4vir/nana-demo/tree/master/Examples/group.cpp. It works well when size of text is setting to 100%. When the scaling factor is 125%, the buttons 4,5and 6 are squished. Because the scaling factor of place is enlarged, depending on DPI, but the form's size is not enlarged. Is it the same problem you encountered?

cnjinhao avatar Aug 25 '20 09:08 cnjinhao

I understand I have 100% in my two monitors. I didn change anything. Please, see my comments on #544

Links: hotfix-1.7.4 right: develop-1.8 image image

qPCR4vir avatar Aug 25 '20 22:08 qPCR4vir

I have tested two of my small projects, and the example https://github.com/qPCR4vir/nana-demo/tree/master/Examples/group.cpp (on Windows, using the default scaling factor of 100%). My projects had an empty window (no widgets visible at all), and the example looked like qPCR4vir's screenshot. It's hard to evaluate if anything else is broken, until this issue is fixed.

ErrorFlynn avatar Aug 26 '20 06:08 ErrorFlynn

Thanks for you feedbacks, I found the problem caused by some of DPI APIs are not provided by Win7.

cnjinhao avatar Aug 26 '20 06:08 cnjinhao

ahh... you main here: https://github.com/cnjinhao/nana/blob/develop-1.8/source/detail/platform_abstraction.cpp#L1118 ? IF you find a solution for windows 7 - OK. But if this is hard just return 96 which seems to be the default. Anyway, windows 7 is "deprecated".

qPCR4vir avatar Aug 26 '20 10:08 qPCR4vir

A fix has been checked into the develop-1.8 branch.

cnjinhao avatar Aug 26 '20 13:08 cnjinhao

Great!! Thank you. Tested:


C:\Prog\ExtLib\cmake-nana-demo-build-release>"C:\Program Files\CMake\bin\ctest.exe" --verbose
UpdateCTestConfiguration  from :C:/Prog/ExtLib/cmake-nana-demo-build-release/DartConfiguration.tcl
UpdateCTestConfiguration  from :C:/Prog/ExtLib/cmake-nana-demo-build-release/DartConfiguration.tcl
Test project C:/Prog/ExtLib/cmake-nana-demo-build-release
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 1
      Start  1: calculator

1: Test command: C:\Prog\ExtLib\cmake-nana-demo-build-release\calculator.exe
1: Test timeout computed to be: 10000000
1:

...

100% tests passed, 0 tests failed out of 53

Total Test time (real) = 113.72 sec


qPCR4vir avatar Aug 26 '20 20:08 qPCR4vir

Thank you, the fix works well on Win8.1 with 100% scaling (I haven't tested other scaling factors on that OS).

I have also tested on Win10 in a VM, and everything is fine except for a small issue with the labels for the group captions.

Switching from 100% to 150% while the example is running has this effect: 100 to 150

Starting the example while the scaling is 150% causes the width of the group labels to be larger than the caption text, and also the form size doesn't scale up: 150

ErrorFlynn avatar Aug 26 '20 20:08 ErrorFlynn

Form size doesn't scale up is intended behavior. The DPI-aware scaling is a feature of place, not a feature of scaling window's coordinate system. Because scaling window's coordinate system are too complicated and it will brings many breaking changes. To resolve this problem, I think we can add some new weight types, like px and em. These new weight types are tools for tunning for high-DPI display.

cnjinhao avatar Aug 26 '20 22:08 cnjinhao

Hi @cnjinhao

both versions (hotfix-1.7.4 and develop-1.8) seems to be ok for me (VS2019 & win10). Tested on nana-creator and few other projects.

besh81 avatar Sep 07 '20 13:09 besh81

msvc compile error:

[  1%] Building CXX object CMakeFiles/nana.dir/source/system/split_string.cpp.obj
split_string.cpp
E:\3rdParty\gui\nana\source\system\split_string.cpp(21): error C2146: 语法错误: 缺少“)”(在标识符“and”的前面)
E:\3rdParty\gui\nana\source\system\split_string.cpp(21): error C2065: “and”: 未声明的标识符
E:\3rdParty\gui\nana\source\system\split_string.cpp(21): error C2146: 语法错误: 缺少“;”(在标识符“sep”的前面)
E:\3rdParty\gui\nana\source\system\split_string.cpp(21): error C2059: 语法错误:“)”
E:\3rdParty\gui\nana\source\system\split_string.cpp(22): error C2059: 语法错误:“;”
E:\3rdParty\gui\nana\source\system\split_string.cpp(25): error C2065: “start”: 未声明的标识符
E:\3rdParty\gui\nana\source\system\split_string.cpp(25): error C2065: “end”: 未声明的标识符
E:\3rdParty\gui\nana\source\system\split_string.cpp(25): error C2065: “start”: 未声明的标识符
E:\3rdParty\gui\nana\source\system\split_string.cpp(28): error C2059: 语法错误:“return”
E:\3rdParty\gui\nana\source\system\split_string.cpp(32): error C2059: 语法错误:“}”
E:\3rdParty\gui\nana\source\system\split_string.cpp(32): error C2143: 语法错误: 缺少“;”(在“}”的前面)
NMAKE : fatal error U1077: “D:\Develop\msvc2019\VC\Tools\MSVC\14.27.29110\bin\Hostx86\x86\cl.exe”: 返回代码“0x2”

https://github.com/cnjinhao/nana/blob/554c4fe87fc31b8ee104228e9117d545d34855b5/source/system/split_string.cpp#L21

and keyword msvc need /Za

ref: https://stackoverflow.com/questions/24414124/why-does-vs-not-define-the-alternative-tokens-for-logical-operators

bstaint avatar Sep 12 '20 10:09 bstaint

@bstaint Fixed! Thanks for your feedback.

@qPCR4vir @ErrorFlynn @besh81 , new units px and em introduced into develop-1.8

int main()
{
	using namespace nana;

	form fm;
	button btn1{ fm }, btn2{ fm }, btn3{ fm };

	fm.div("A arrange=[20, 20px, 1em] gap=5");
	fm["A"] << btn1 << btn2 << btn3;

	fm.collocate();
	fm.show();
	exec();
}

If scaling factor is 100%, the width of btn1 and btn2 are same. If scaling factor is larger than 100%, the width of btn1 is larger than btn2's

cnjinhao avatar Sep 23 '20 07:09 cnjinhao

Just compiled and tested (MSVC19 - Win10) ... here the result of your sample code: Cattura

I think the expected layout should be: Cattura2

So if I correctly understand:

  • px : is a fixed unit measure
  • % : is the same as before
  • em : is relative to the font size
  • (nothing) : is relative to the scaling factor ???

It seems a little confusing to me.

besh81 avatar Sep 23 '20 16:09 besh81

@besh81 Fixed, thanks for your feedback.

cnjinhao avatar Sep 23 '20 22:09 cnjinhao

Hi guys,

@cnjinhao : I'm wondering if you could release the 1.7.4 hotfix I think is time to a small step ahead.

And I can use the new toolbar interface ;-) Ciao

besh81 avatar Nov 25 '20 08:11 besh81

@besh81 , there will not be a release of 1.7.x. I recommend develop-1.8, it contains all changes of hotfix-1.7.4, if you encounter any new bugs which not occur in 1.7.4, please let me know.

cnjinhao avatar Nov 28 '20 06:11 cnjinhao

Hi @cnjinhao working on nana-creator to use high-dpi screen I found a bug on place scaling factor where the last field isn't properly scaled (or variable field not correctly calculated).

int main()
{
	using namespace nana;

	form fm;
	button btn1{ fm }, btn2{ fm }, btn3{ fm };


	fm.div("A arrange=[20, variable, 20] gap=5");
	fm["A"] << btn1 << btn2 << btn3;

	fm.collocate();
	fm.show();
	exec();

	return 1;
}

Win10 100% nana100

Win10 150% nana150

besh81 avatar Jun 18 '21 13:06 besh81

Another weird behaviour is displayed using the following:

fm.div("A arrange=[1em, variable, 1em] gap=5");

besh81 avatar Jun 18 '21 13:06 besh81

@besh81 Thank you alot for reporting this bug. A fix has been checked into the branch-1.8

cnjinhao avatar Jun 25 '21 17:06 cnjinhao