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

Environmental variable "QT_PLUGIN_PATH" conflict for RStudio 1.2 on Win10 #4694

Closed
madlogos opened this issue Apr 24, 2019 · 7 comments
Closed
Labels
enhancement stale Issues which have been closed automatically due to inactivitiy.

Comments

@madlogos
Copy link

@madlogos madlogos commented Apr 24, 2019

System details

RStudio Edition : Desktop (Open source)
RStudio Version : 1.2.1335 stable
OS Version      : Windows 10 x64
R Version       : 3.5.3

Steps to reproduce the problem

  1. You have some applications (e.g., Anaconda) that registered the variable QT_PLUGIN_PATH in environment beforehand.
  2. Install RStudio 1.2, either unzipping the tarball or installing the .exe.
  3. The RStudio.exe won't launch and pops an error "This application failed to start because no Qt platform plugin could be initialized".

Describe the problem in detail

Refer to this thread on RStudio Community.

Describe the behavior you expected

It is now mitigated by resetting the environmental variable. But I expect a more elegant solution to minimize the impacts to other softwares.

@jmcphers
Copy link
Member

@jmcphers jmcphers commented Apr 30, 2019

Thanks for filing this! I'm removing the bug label because I think respecting QT_PLUGIN_PATH is, technically the right thing for RStudio to do -- it is expected behavior for Qt based applications. Not respecting this variable will break some usage, even if it fixes the usage described above.

Do you have a proposal for a more elegant approach? (One I thought of was trying to rename this variable for our use, e.g. RSTUDIO_QT_PLUGIN_PATH, so it would still be possible to point at a different Qt plugin path for RStudio even if we stopped respecting the standard env var.)

@jmcphers jmcphers added enhancement and removed bug labels Apr 30, 2019
@madlogos
Copy link
Author

@madlogos madlogos commented Apr 30, 2019

I tried appending RStudio plugin directory to QT_PLUGIN_PATH but it did not work. Only putting it as the first entry could make RStudio run. But in Win 10, by design, multiple entries for env var is allowed anyway.

I don't know how QT_PLUGIN_PATH typically works. Is it possible for RStudio to accept multiple entries in the var and automatically recognize the correct match? If this brings in new issues, perhaps a new var is a better choice.

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented May 20, 2019

IMHO setting QT_PLUGIN_PATH globally as you have is a bit of an anti-pattern, as it means all applications on your system will now look in that path for Qt plugins (regardless of what version of Qt that particular application is using). I can understand it's a required workaround for some cases, but if possible I'd recommend only setting that environment variable as required and not globally.

If required, you could create your own shortcut / batch script that launched RStudio with QT_PLUGIN_PATH set, e.g.

https://superuser.com/questions/424001/launch-windows-program-with-custom-environment-variable

@stale
Copy link

@stale stale bot commented Feb 6, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs, per https://github.com/rstudio/rstudio/wiki/Issue-Grooming. Thank you for your contributions.

@stale stale bot added the stale Issues which have been closed automatically due to inactivitiy. label Feb 6, 2021
@stale
Copy link

@stale stale bot commented Feb 20, 2021

This issue has been automatically closed due to inactivity.

@stale stale bot closed this as completed Feb 20, 2021
@Ghostkeeper
Copy link

@Ghostkeeper Ghostkeeper commented Aug 9, 2021

It's a bit of a security issue too, isn't it? Running into the same problem with an application I'm developing...

@munkey01
Copy link

@munkey01 munkey01 commented Aug 18, 2021

This issue should be reopened as it is unresolved. Currently, I am dealing with the same issue; is it possible to implement @jmcphers suggestion of using a less generic env variable name? That way we can avoid conflicts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement stale Issues which have been closed automatically due to inactivitiy.
Projects
None yet
Development

No branches or pull requests

6 participants