Skip to content
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

Unable to open files from drive other than drive of current working directory #17

Closed
BigRoy opened this issue Mar 30, 2020 · 6 comments · Fixed by #22
Closed

Unable to open files from drive other than drive of current working directory #17

BigRoy opened this issue Mar 30, 2020 · 6 comments · Fixed by #22
Assignees
Labels
bug Something isn't working windows Windows operating system issues

Comments

@BigRoy
Copy link

BigRoy commented Mar 30, 2020

Issue

It seems I'm unable to open USD files correctly with USD Manager that are not under the same drive letter on Windows as the current working directory.

This is what I'm doing, say my cwd is C:/foo/bar and I start usdmanager in Python:

import usdmanager
usdmanager.run()

Whenever I open a file that is on C:/ it works "fine"*. However when I open a file from D:/foo/bar or P:/projects it seems USD Manager tries to still prepend the original current working directory drive letter, getting me paths like:

D:C:/foo/bar/file.usd

It's not really prepending it. It seems the first character is the drive letter of the USD file, then it inserts the drive letter of the current working directory and then it continues the file path.

The same happens when clicking on a reference link inside the .usd file that refers to a USD file on another drive letter.

*Note that I'm saying opening a file on the same drive letter works "fine" however it also seems to insert the current working directory drive letter: C:C:/foo/bar but somehow reads the file just fine.

I am not sure where this is coming from. I also tried to get the debug logger running but it didn't seem to output any messages whatsoever.

# no output printed somehow...
import logging
import usdmanager
usdmanager.logger.setLevel(logging.DEBUG)
usdmanager.run()

Windows 10
usdmanager 0.9.0
USD 19.11
PySide
@BigRoy
Copy link
Author

BigRoy commented Mar 30, 2020

This seems to be something with QtCore.QUrl

url = QtCore.QUrl("E:/test/asset.usd")
print url.path()
# /test/asset.usd

url = QtCore.QUrl("file:E:/test/asset.usd")
print url.path()
#  E:/test/asset.usd

It seems here the value is still good, e.g. C:/Users/Roy/Desktop/usdAsset.usd but then here the path is wrong: C:C:/Users/Roy/Desktop/usdAsset.usd.

@mds-dwa mds-dwa added bug Something isn't working windows Windows operating system issues labels Mar 30, 2020
@mds-dwa
Copy link
Contributor

mds-dwa commented Mar 30, 2020

I'm not on a computer where I can test this right now, but I wonder what happens if we change line 2672 from link.setPath(fileStr) to link.setPath(QtCore.QUrl.fromLocalFile(fileStr).toString())? That's a little ugly, but there's a chance that would keep the QUrl extras we want like query strings, while converting E:/... to file:///E:/... so that it is properly found. It will probably take some more work in other places the current QUrl objects are used, but it might be a place to start!

@mds-dwa mds-dwa self-assigned this Apr 3, 2020
@mds-dwa
Copy link
Contributor

mds-dwa commented Apr 3, 2020

I've made a slight tweak to how the logger is initialized so that your method of launching will work. Previously, it was always getting set back to logging.WARNING as a default unless you launched from the command line and gave flags for argparse to use. If you need something short-term, just delete the logger.setLevel(logging.WARNING) line in the _set_log_level method in __init__.py.

I've also got a probable fix for the file:// situation (definitely more involved than my initial one-line suggestion), but I won't be able to test it on a Windows machine until next week.

mds-dwa added a commit that referenced this issue Apr 6, 2020
Add missing icon for closing the find search bar on Mac and Windows
General maintenance

Signed-off-by: mds-dwa <[email protected]>
mds-dwa added a commit that referenced this issue Apr 6, 2020
#17)

[ENH] Monitor for changes on file system

Signed-off-by: mds-dwa <[email protected]>
@mds-dwa
Copy link
Contributor

mds-dwa commented Apr 6, 2020

Release version 0.10.0 addresses the logging note and some other minor maintenance. The Windows file path issue is much more involved and may not be fully resolved yet. I have an alpha version you can test here: https://github.com/dreamworksanimation/usdmanager/tree/issue/17. Feedback and dev contributions are very welcome.

@agelosc
Copy link

agelosc commented Feb 4, 2021

I'm leaving a small workaround here for this issue in case it helps someone.

you can create a windows batch file for usdmanager that changes the directory to the usd file path before loading the usdmanager python file with something like this:

cd /D %~dp1
py -2.7 usdmanager %~1

I'm under the impression that if a usdmanager.cmd file exists in the same scripts folder, windows will automatically pick that instead of the one without an extension when a usdmanager command is issued. I think Pixar has done something similar to this for its USD/bin folder.

Here's the complete batch file that worked for me:

@echo off
setlocal ENABLEDELAYEDEXPANSION
set USD_MANAGER_ROOT=C:/path/to/usdmanager/root
set USD_INSTALL_ROOT=C:/path/to/usd/root
set PYTHONPATH=%PYTHONPATH%;%USD_INSTALL_ROOT%\lib\python
set PATH=%PATH%;%USD_INSTALL_ROOT%\bin;%USD_INSTALL_ROOT%\lib;%USD_MANAGER_ROOT%\build\lib

cd /D %~dp1
py -2.7 %USD_MANAGER_ROOT%\scripts\usdmanager %~1
endlocal

@mds-dwa mds-dwa linked a pull request Feb 22, 2021 that will close this issue
@mds-dwa
Copy link
Contributor

mds-dwa commented Feb 22, 2021

I think the original issue here should be resolved by version 0.11.0 if you want to give it a try. (dev branch)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working windows Windows operating system issues
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants