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

Shaders / docs path parameters #177

Open
Peter7645946 opened this issue Oct 28, 2017 · 2 comments
Open

Shaders / docs path parameters #177

Peter7645946 opened this issue Oct 28, 2017 · 2 comments

Comments

@Peter7645946
Copy link

Shaders are stored at INSTALL_DIR\shaders (INSTALL_DIR\doc)

It can be improved using new command line arguments -shadersDir and -docsDir:

  • If they are not used then the program should behave as before.
  • If they are used with relative path then the path should be relative exe file of the program.
  • if they are used with absolute path then this path should be used without changes.

The arguments can be useful in the following scenarios:

  • To use new shaders without re-instaling the program, and without write permissions to the shaders path
  • When the Displaz is being developed in Visual Studio (see project properties->Debugging->Command Arguments).

Before this change INSTALL_DIR was the path where binary is installed minus its last four symbols. This path was created using QCoreApplication::applicationDirPath(). It did not work when Displaz was started from Visual Studio IDE. In this case this function returns something like

C:\repos\displaz\build\bin\Debug

The last four symbols of the path were not "/bin", and as a result loading shaders and documents failed and there is no good way to make the program to use another path.

There was one one more small issue there, which also was fixed. There was a misleading error message. If INSTALL_DIR did not finish with "/bin" then the program wrote a message that shaders cannot be loaded. But in fact in that case shaders AND documentation cannot be loaded.

Note: this change was written and tested on Window. It would be good to make sure that it also work on Linux.

@c42f
Copy link
Owner

c42f commented Nov 5, 2017

Good idea, I think the problems you've pointed out (ie, allow user-editable persistent shaders, and running during development, without installing) are annoying and are worth solving. I'm not quite sure command line arguments are the best way to address them though, because I think this is more a developer-level feature than something that should be in the main user interface.

Here's how I'd unpack the several needs related to this change:

  1. Users should be able to save their custom shaders somewhere conveniently accessible
  2. Users should be able to override the default shader
  3. Developers should be able to run displaz from their IDE (I assume this is primarily what prompted these changes?)
  4. Developers of scripts which use the displaz command line interface should be able to set shaders as required.

Some ways to address these:

  • Environment variables - good for running displaz during development, as they're somewhat persistent and don't interfere with the normal command line. Also useful for advanced users I suppose.
  • Persistent settings at the GUI level (see Make displaz remember settings between runs #1) - good for user-editable shader directories and configurable default shaders.
  • Command line arguments - I feel this solution is a little too non-persistent.
  • Detection the build environment in code - would solve the IDE problem, but probably a bit too magical and doesn't generalize.
  • The existing -shader option works for scripts, but has some caveats

Out of the options, I think it's probably best to use environment variables to address use case (3). I think use case (1) might be best addressed in a different way, probably via a persistent GUI setting.

@c42f
Copy link
Owner

c42f commented Nov 5, 2017

So how about we have a environment variable DISPLAZ_SHADER_DIR or some such, under which we expect the shaders to reside? On balance I'd be happy to ignore the docs for now - a working install with docs should be accessible via make install or the equivalent on windows (in development, I usually install into a build subdirectory to keep things contained).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants