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

VeSTige opens correct folder #3550

Merged
merged 4 commits into from May 31, 2017

Conversation

Projects
None yet
3 participants
@karmux
Contributor

karmux commented May 10, 2017

This pull request fixes opening correct VST folder in previously saved projects with existing VeSTige instruments. Project has to be saved using code in this PR. After next project load VST folders open correctly. Copied logic from SF2 and GIG Players.

@karmux karmux changed the title from VeSTige opens correct folder when nothing loaded yet. to VeSTige opens correct folder May 10, 2017

@tresf tresf added this to In Progress in Release 1.2.0 RC3 May 11, 2017

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf May 13, 2017

Member

@karmux thanks.

First, what happens if the VST does not exist at the given path? Does it know to fallback to the VST directory?

Second, have you considered consolidating this into the FileDialog constructor or a FileDialog helper? This seems like it's only going to be more useful as time goes on and it will cleanup the codebase. If we're worried about changing too many files on stable-1.2, this could be a follow-up task for master.

Reason being... we already have areas where the existing constructor could simplify the code since the existing constructor supports FileDialog::FileDialog( QWidget *parent, const QString &caption, const QString &directory, const QString &filter ) however I feel we can make the constructor even better by taking a file path and resolving its parent using your logic with a fallback path if it's black or not found.

Member

tresf commented May 13, 2017

@karmux thanks.

First, what happens if the VST does not exist at the given path? Does it know to fallback to the VST directory?

Second, have you considered consolidating this into the FileDialog constructor or a FileDialog helper? This seems like it's only going to be more useful as time goes on and it will cleanup the codebase. If we're worried about changing too many files on stable-1.2, this could be a follow-up task for master.

Reason being... we already have areas where the existing constructor could simplify the code since the existing constructor supports FileDialog::FileDialog( QWidget *parent, const QString &caption, const QString &directory, const QString &filter ) however I feel we can make the constructor even better by taking a file path and resolving its parent using your logic with a fallback path if it's black or not found.

@karmux

This comment has been minimized.

Show comment
Hide comment
@karmux

karmux May 13, 2017

Contributor

@tresf Good that you asked that. It didn't default to configured VST plugin directory if the VST plugin did not exist at the given path. SF2 and GIG players seemed to default to plugins directory defined in config. I fixed this in similar way to GIG Player.

I was thinking about some general helper functionality for all these instrument plugins but that would be safer to implement for next version after 1.2 I think.

Contributor

karmux commented May 13, 2017

@tresf Good that you asked that. It didn't default to configured VST plugin directory if the VST plugin did not exist at the given path. SF2 and GIG players seemed to default to plugins directory defined in config. I fixed this in similar way to GIG Player.

I was thinking about some general helper functionality for all these instrument plugins but that would be safer to implement for next version after 1.2 I think.

@Umcaruje Umcaruje added this to the 1.2.0 milestone May 14, 2017

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf May 31, 2017

Member

The only concern I have is with the way we display the error message with this PR.

Previously, if a vst was in foo/bar/instrument.dll, you'd see the full or partial path whereas this new PR removes the folder name, which seems to offer less information than before.

Member

tresf commented May 31, 2017

The only concern I have is with the way we display the error message with this PR.

Previously, if a vst was in foo/bar/instrument.dll, you'd see the full or partial path whereas this new PR removes the folder name, which seems to offer less information than before.

@Umcaruje Umcaruje removed this from In Progress in Release 1.2.0 RC3 May 31, 2017

@tresf tresf merged commit 635b50b into LMMS:stable-1.2 May 31, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf May 31, 2017

Member

@karmux thanks!

Member

tresf commented May 31, 2017

@karmux thanks!

@karmux karmux deleted the karmux:vestige_open_correct_dir branch Jun 6, 2017

PhysSong added a commit to PhysSong/lmms that referenced this pull request Jul 8, 2017

VeSTige opens correct folder (#3550)
Open correct VST folder in previously saved projects with existing VeSTige instruments.

PhysSong added a commit to PhysSong/lmms that referenced this pull request Jul 8, 2017

VeSTige opens correct folder (#3550)
Open correct VST folder in previously saved projects with existing VeSTige instruments.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment