-
-
Notifications
You must be signed in to change notification settings - Fork 310
Modernize copy/move XAML dialog #751
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Dongle <29563098+dongle-the-gadget@users.noreply.github.com>
Signed-off-by: Dongle <29563098+dongle-the-gadget@users.noreply.github.com>
Signed-off-by: Dongle <29563098+dongle-the-gadget@users.noreply.github.com>
Signed-off-by: Dongle <29563098+dongle-the-gadget@users.noreply.github.com>
We should make all NanaZip.Modern things exported only by K7Modern C wrappers. It's necessary for modernization work like NanaZip.Universal. Kenji Mouri |
|
Note: The one of goals for NanaZip modernization is keeping the usage of Windows Runtime interfaces only in NanaZip.Modern module. Kenji Mouri |
|
I don't believe that exposing a lot of K7Modern getter and setter properties for all WinRT properties is the best API choice. |
|
We should only expose necessary properties which actually used. Also, I suggest that wrapping XAML Islands based UI more to Win32 HWND controls will make easier to integrate with inherited 7-Zip mainline historic things, which the modification marks will be more compact. Some interesting notes: If you have read https://x.com/driver1998/status/1968255362647417251, you will know that I had an idea about a homemade ComCtl v10 where every control is an XAML island hosted by Mile.Xaml. This is actual the plan B of NanaZip modernization work, if I have not met your previous contributions before, the plan B may be started, lol. Kenji Mouri |
|
Can't we make shim classes in that case? Since with mainline all controls are behind wrapper classes anyway, we can replace them with our own classes and still get to use WinRT that way. |
|
For Windows, the only ABI can cross compiler/language is C style. COM is actually C style, only coincidencely uses the same structure of vtable. Note: I need to make a similar wrapper for implementing the NanaZip Classic flavor UI. Ideally, I even hope we can use the same C interface (function prototype definition hope to be same, function name can be different because it's OK for LoadLibrary dynamically) between NanaZip.Modern.dll and NanaZip.Classic.dll. It can much simplify the NanaZip.Universal's implementation. It can help simplify the future maintenance work. K7Modern interface is the beginning of that work. (Although it's not the final definition.) I also hope that work can help me to split non UX but cross-platform part from inherited 7-Zip source code. That not only helpful to make a much modernized UX part implementation, but also helpful for making cross-platform implementations. (Although NanaZip only supports Windows in the foreseeable future. But I don't know whether something like Windows 10X would come out.) Kenji Mouri |
|
I thought the non-UX parts are generally in Core already except the CLI, but that's not as big of a hassle to port. I think the converging to flat-C only makes sense if we were to completely rewrite the entire UI stack instead of a gradual port, since that would need an insane amount of internal details being interop-ed. In addition, are we actually having the two UIs in one executable? |
The non-SFX CLI has moved to NanaZip.Universal because it's important to make CLI and GUI use the same codebase version to reduce some differences.
In the current stage, I hope we can rewrite the UI stack gradually.
This is one of the goals because it's important to reduce multiple inherited 7-Zip source code instances. (Currently we have NanaZip.Core NanaZip.Universal NanaZip.UI.Modern NanaZip.UI.Classic) Kenji Mouri |
|
Couldn’t we have the projects reference a shared folder for the common ones and then split as needed? I don’t think we can get much code shared either way. |
|
We should also reduce the compile time, at least by using the static library. But for multiple UX modules, they should be dynamic library. Kenji Mouri |
|
(unrelated) Could we have this PR merged for now since it's going to Modern? |
|
I hope we can use the C-style K7Modern prefix API to wrap. Kenji Mouri |
I copied code over the K7Modern wrappers, not sure whether I should do it like that or make the underlying methods public. Could probably be utilized for future modernization.