apianti Posted March 7, 2020 Share Posted March 7, 2020 (edited) You would just create predefined widgets, like label, button, textbox, image, panel, etc. Then your menu information would just be the properties of these widgets, like <key>Menu</key> <array> <key>Panel</key> <dict> <key>Properties</key> <whatever /> <key>Children</key> <array> <key>Label</key> <dict> <key>X</key> <integer>0</integer> <key>WidthPercent</key> <integer>100</integer> <key>Text</key> <string>Hello World!</string> </dict> <key>Image</key> <dict> <key>Align</key> <string>Center</string> <key>Data</key> <data>...</data> </dict> </array> </dict> </array> Etc. EDIT: Obviously, the best thing to use would be HTML, JS, and SVG. But it doesn't have to be that complicated... Edited March 7, 2020 by apianti Link to comment Share on other sites More sharing options...
Slice Posted March 7, 2020 Share Posted March 7, 2020 The message is 12:072 2:196 XArray::ElementAt(xsize) const -> Operator [] : index > m_len when I pressed SPACE on Mojave icon. 1 Link to comment Share on other sites More sharing options...
Slice Posted March 7, 2020 Share Posted March 7, 2020 13 hours ago, Slice said: The message is 12:072 2:196 XArray::ElementAt(xsize) const -> Operator [] : index > m_len when I pressed SPACE on Mojave icon. The operator is Entries[ScrollState.CurrentSelection] Probably Entries.size() is less then index. In C version there was EntryCount which calculated as maximum index. Link to comment Share on other sites More sharing options...
Slice Posted March 8, 2020 Share Posted March 8, 2020 You said Title should be CONST CHAR16* but I see for example this line AboutMenu.Entries[AboutMenu.EntryCount-2]->Title = PoolPrint(L" Screen Output: %s", egScreenDescription()); This is not const as a pointer nor as a value. Link to comment Share on other sites More sharing options...
Slice Posted March 8, 2020 Share Posted March 8, 2020 13 hours ago, apianti said: You would just create predefined widgets, like label, button, textbox, image, panel, etc. Then your menu information would just be the properties of these widgets, like <key>Menu</key> <array> <key>Panel</key> <dict> <key>Properties</key> <whatever /> <key>Children</key> <array> <key>Label</key> <dict> <key>X</key> <integer>0</integer> <key>WidthPercent</key> <integer>100</integer> <key>Text</key> <string>Hello World!</string> </dict> <key>Image</key> <dict> <key>Align</key> <string>Center</string> <key>Data</key> <data>...</data> </dict> </array> </dict> </array> Etc. EDIT: Obviously, the best thing to use would be HTML, JS, and SVG. But it doesn't have to be that complicated... We have 120 input parameters we want set by menu. There is a little problem to write menu.plist(.svg) for this parameters as it will be thousands lines. Link to comment Share on other sites More sharing options...
Jief_Machak Posted March 8, 2020 Author Share Posted March 8, 2020 2 hours ago, Slice said: You said Title should be CONST CHAR16* but I see for example this line AboutMenu.Entries[AboutMenu.EntryCount-2]->Title = PoolPrint(L" Screen Output: %s", egScreenDescription()); This is not const as a pointer nor as a value. CONST CHAR16* means the pointer points to something const. But the pointer can still change value. Which what’s happening here. Mas we said, let’s replace this by XStringW. Link to comment Share on other sites More sharing options...
apianti Posted March 8, 2020 Share Posted March 8, 2020 (edited) 9 hours ago, Slice said: We have 120 input parameters we want set by menu. There is a little problem to write menu.plist(.svg) for this parameters as it will be thousands lines. Nah, you can easily just bind a variable by name to a widget by adding a binding key to it's properties and storing the configuration by key/value pairs or like a registry. It will be the same amount of data either way but the way that it is maintained is different. It won't be hardcoded, it will all be located in one place, and it will be easier to understand the hierarchy. In fact you could have entire sections generated by the type of value they have. I just don't see the point in doing all this effort for c++ when it literally is only bloating the code and providing no plausible improvement over using c, and not fixing the actual problem, that the GUI is absolutely terrible and has become unwieldy.... EDIT: Also there is no reason you can't have separate files. You can easily have includes to other files. Edited March 8, 2020 by apianti Link to comment Share on other sites More sharing options...
Jief_Machak Posted March 8, 2020 Author Share Posted March 8, 2020 @apianti We know you don't like C++ but that's done. We're not bloating the code and I know I'll prove you wrong one day as I did before. Please stop criticise it, it doesn't help. Propositions about a new menu system are interesting and welcomed. Link to comment Share on other sites More sharing options...
apianti Posted March 8, 2020 Share Posted March 8, 2020 (edited) I do like c++, a lot. I just don't think it is the correct language to use and there are reasons why EDK2 does not use it. You are bloating the binary. I can see it just in the building. Look back at the previous releases and see that the size has been increasing as you add more support for c++. There is no way that you are going to get a smaller binary with c++, because c++ has much more overhead, you are having to deal with it. Constructors, destructors, new, etc, all of this is overhead that wasn't there before, they are all function calls, calling functions is more expensive than you think. There are entire architectures designed to remove the overhead of function calling with overlapping register windows that have massive amounts of registers and they operate significantly better than the same architecture without. EDIT: Also, when exactly do you think you have proved me wrong? Edited March 8, 2020 by apianti Link to comment Share on other sites More sharing options...
Jief_Machak Posted March 8, 2020 Author Share Posted March 8, 2020 @apianti Please, just stop on that subject. Link to comment Share on other sites More sharing options...
apianti Posted March 8, 2020 Share Posted March 8, 2020 Seriously? I put years of work into this. So you can stop. I am pointing out facts. FACTS. You are in denial if you think I am not. If what you are doing can't stand up to me criticizing it, then it's probably not worth doing. So far all you've done is deflect and tell me I'm wrong without providing any evidence that I am. When I have provided evidence that I am correct. The binary is growing in size, period. Link to comment Share on other sites More sharing options...
Jief_Machak Posted March 8, 2020 Author Share Posted March 8, 2020 You also had evidence that C++ couldn't work for Clover, some time ago... Please stop on that subject. Link to comment Share on other sites More sharing options...
apianti Posted March 8, 2020 Share Posted March 8, 2020 Where did I say that? I told you that it was not worth it because I had already done it.... WHAT ARE YOU TALKING ABOUT? Link to comment Share on other sites More sharing options...
Jief_Machak Posted March 8, 2020 Author Share Posted March 8, 2020 Please stop. Link to comment Share on other sites More sharing options...
apianti Posted March 8, 2020 Share Posted March 8, 2020 I will stop when you look at the evidence scientifically, and not because you want to do something. Link to comment Share on other sites More sharing options...
Jief_Machak Posted March 8, 2020 Author Share Posted March 8, 2020 I uncommented the support for ICNS. Support for BMP seems still commented out. I don't if BMP was ever supported. Link to comment Share on other sites More sharing options...
Slice Posted March 8, 2020 Share Posted March 8, 2020 I agree that menu shouldn't be hardcoded. It will be better to use common interpreting system and menu definition in separate plist file (or may be svg). The real problem is to make final result. Now we make old system in new language. c++ is better then c because it more strict for catching bugs. Then it provide common libraries for same operations. Code size is growing? But we added new code not erasing old codes. When I exclude all EG_IMAGE operations code size will fall down. Link to comment Share on other sites More sharing options...
apianti Posted March 8, 2020 Share Posted March 8, 2020 (edited) I understand the code base is growing because there is new stuff but I'm saying that literally just allocating something with new became three function calls when it was one before (or two if a zero allocate but this also adds one to the previous if done as well), i.e. calling allocation went from alloc() to new() -> alloc() -> ctor(). Same thing with delete, operators, etc. There is more overhead with everything that c++ does, and as you add more, the same functionality will consume more space for handling object oriented behavior. UEFI is not object oriented and should be small and fast, c does these same things perfectly if used correctly, it's why pretty much every other language is written in c. You can't use any of the c++ libraries because they are platform dependent, also UEFI has basically all of this functionality but in c with less overhead so I am just confused as to why there is such a push to change to c++. I have yet to hear one good reason why c++ is a better choice than c besides it's easier because it has many more subtle rules that you guys are running into problems with that would never have happened in c, the overhead is higher, and the performance is lower, just by the nature of the languages... EDIT: I forgot about alloc() vs new[]() -> alloc() -> for n items do { ctor() }... Very much worse performance. Edited March 8, 2020 by apianti Link to comment Share on other sites More sharing options...
Slice Posted March 9, 2020 Share Posted March 9, 2020 Tiano don't want C++ because they create sources which must be compilable on all platform and on all compilers. The universality is a obstruction for optimisation. EDK2 is full of unused codes, checks and asserts because of this. C is very bad language while it is universal and easy to compile. Clover sources has huge amount of checks and type casting and anyway it still has bugs origin from bad programming style inflicted by C language. Rewriting codes to C++ causes more compact codes with more internal proofs. If I'll loose 20% performance it is nothing compared to different computers performance. Let it be more reliable. Link to comment Share on other sites More sharing options...
apianti Posted March 9, 2020 Share Posted March 9, 2020 (edited) I think you two have a fundamental misunderstanding of the differences between the two languages, c++ is a superset of c. It is not more reliable. It contains nothing more than object oriented behavior on top of c, the creator bjorn stroustrup named it "c with classes". The only things that it does contain that would be useful is runtime typing, exceptions, and templates, which you can't even use those because they are platform and compiler dependent unless you decide to use only one version of one compiler, and rewrite all the support.... So effectively the only feature, is object oriented behavior, which has increased overhead to the same c program, and relies on the exact same code as before underneath, lol. There is also another reason why you don't see as many issues as you should with c, you use gcc or clang, and did not disable the compiler specific extensions and use c90 with all warnings. If you compile with VS, suddenly there are many more mistakes that get caught... EDIT: I forgot, unused names can be stripped so having code that is unused from a library does not matter, it can be removed from the final binary when it is determined not to be used. It is a compiler optimization. Edited March 9, 2020 by apianti Link to comment Share on other sites More sharing options...
Jief_Machak Posted March 9, 2020 Author Share Posted March 9, 2020 28 minutes ago, apianti said: The only things that it does contain that would be useful is runtime typing, exceptions, and templates. Why can't we use templates ? Link to comment Share on other sites More sharing options...
apianti Posted March 9, 2020 Share Posted March 9, 2020 You may be able to but it probably won't be reliable across compilers depending on the standard they conform with, I assume most conform somewhat to c++17 by now. Usually if you disable typing, it disables templates because c++17 type deduction allows you to not specify the types anymore and have them automatically determined from type information... Link to comment Share on other sites More sharing options...
Jief_Machak Posted March 9, 2020 Author Share Posted March 9, 2020 yeeah ! We switch from "you can't even use" at "we may". That's good, because we already do use templates :-) Link to comment Share on other sites More sharing options...
apianti Posted March 9, 2020 Share Posted March 9, 2020 I did not change my reason, please re-read my previous statements, i just reworded it so you could understand better what i was saying. Link to comment Share on other sites More sharing options...
Jief_Machak Posted March 9, 2020 Author Share Posted March 9, 2020 @Slice Could you send me the command line to start Qemu with the EFI bios. When I do it, I have no display : QEMU window is there, but stays black. Link to comment Share on other sites More sharing options...
Recommended Posts