-
Notifications
You must be signed in to change notification settings - Fork 345
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
Fix bugs and add support for UNC paths on Windows. #901
Fix bugs and add support for UNC paths on Windows. #901
Conversation
b87a400
to
fc4298a
Compare
fc4298a
to
e12e38d
Compare
- Added helper functions to reduce redundant code, improve readability, and help clarify intent. - Added getSplitPath() and cleanPath() to FileSystemModel to make it easier to test and extend this functionality. - Added unit tests for some FileSystemModel functions to document existing behavior and make it easier to see how behavior changes with bug fixes. - Deleted unused code.
- Added code to detect network share paths on Windows and treat make them behave like drives. - Fixed a bug where paths typed in with lower case drive letters would cause an upper case drive AND a lower case drive entry to appear in the "My Computer" view. A similar thing would happen for network share hostnames. Added logic to upper case the drive letter and hostnames as part of the "path cleanup" logic. This causes the paths to map to single entries in the "My Computer" view. - Fixed an infinite loop during directory restore when a non-existant network share was specified in a previous Open File dialog instance. - Fixed "up" button so that it behaves more consistently and properly handles network share paths. - Fixed invalid memory access for files that start with a '.' - Fixed a few places where code was using a URL path instead of converting the URL to a local path string like the vast majority of the code. This made it possible to properly view the root directory of network shares. - Updated unit tests to reflect changes in path handling behaviour.
e12e38d
to
238eacd
Compare
Does it fix some or all of the following: Can another windows developer review this? @rodlie ? This looks OK to me |
@acolwell I now have a windows 11 laptop with enough disk space to try things out. Can you confirm that the instructions using MSYS2 from https://github.com/NatronGitHub/Natron/blob/RB-2.5/INSTALL_WINDOWS.md are the way to go? Do you have any plans to do a VS build? Can you please check if the instructions look ok?
|
I installed msys2 using |
So that page could probably use an update. My "from scratch" workflow roughly matches the windows installer build GitHub action.
Once I have this fully built install, my incremental workflow is the following:
Ultimately I'd like to get to a place where I don't need to do a full installer build. Downloading prebuilt test plugin zips like the Natron CI action does is probably the way forward, but I haven't done that yet. I'd also like to get to a place where we aren't using qmake for the installer and cmake for my incrementals. I've just found that the cmake/ninja combo seems faster than the qmake path when doing development. I start with the installer build because that seemed like the "official" way to build releases, but the cmake path seems close enough at this point that I can rely on it for dev purposes. I have not tried to do a VS build yet especially since we have to build Natron specific versions of certain libraries and at least right now that is easier to do/maintain via pacman packages. Long term, I think it might be possible & easier if we eventual migrated to something like Conan (https://conan.io/center) to build all the things. Over the last few months I have tinkered with that and have almost built all of the plugin repos on all platforms with Conan. At some point I'd like to try getting Natron to build as well, but I just don't have the time/energy to tackle that one yet. For now I've just been focusing on trying to get the existing build system working, repeatable, and a little easier to maintain. I hope this helps. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, please close the corresponding bug(s)
Thanks for the reviews. :) |
hello @acolwell, is your build process here still working or has there been changes? |
Yes. This is still the way I work today. The only difference is that the current branch is RB-2.6 and not RB-2.5 |
Gotcha. Thank you! |
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request. Additionally, make sure you've done all of these things:
PR Description
What type of PR is this? (Check one of the boxes below)
What does this pull request do?
This pull request fixes a variety of issues with network share paths on Windows in the file dialogs. (#896 )
The change is split into 2 pieces. The first commit mainly just cleans up the code a little bit by introducing some helper functions, removing duplicate code, and introducing unit tests for key FileSystemModel functionality related to paths. No major behavior changes are in this commit. It is mainly just moving stuff around and trying to make the code a little more consistent and readable.
The second commit contains the bug fixes and new logic to support network paths on Windows. It fixes the major issues with navigating network shares and should address all the issues mentioned in (#896).
Have you tested your changes (if applicable)? If so, how?
Yes. I created unit tests to verify the key path manipulation functionality in FileSystemModel. I also built a Windows version of Natron locally and did a bunch of manual tests on the file dialog with network shares. The behavior is MUCH better than it was and the network shares essentially behave just like drives.