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

Responsive "Effects chain" & "User controller" LEDs #4297

Merged
merged 6 commits into from
Apr 24, 2018
Merged

Responsive "Effects chain" & "User controller" LEDs #4297

merged 6 commits into from
Apr 24, 2018

Conversation

Sawuare
Copy link
Member

@Sawuare Sawuare commented Apr 15, 2018

  • Turn off the effects chain LED when its chain is empty.
  • Turn on the user controller LED when a controller is selected.

Also, removed an unused function: setEnabled()

Closes #3620.

if( m_effectViews.size() == 0 )
{
fxChain()->m_enabledModel.setValue( false );
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since EffectChain::clear already have the same functionality, I think you can implement this in EffectChain::removeEffect instead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in d3e65ca

@Wallacoloo
Copy link
Member

Using (or even having) a dataUnchanged() signal on a model smells a bit fishy. LMMS mostly uses a model-view-controller-like paradigm (MVC), and usually the model emits signals to notify the views that the model's changed.

But in this case, the dataUnchanged() signal is being used to notify the view that the controller attempted to do something - not that the model has been updated. If we wanted to hook into something the controller's doing (I think LMMS mostly merges the controller role into the view), the signal should be placed right at the source - on the controller.

I don't think I'm capable of giving a more coherent explanation of why I think dataUnchanged() is a bad thing to have or use, but it feels like a leaky abstraction - like we're losing the main advantage of MVC in that the model and view are no longer decoupled. If you can see a way to achieve this work without using dataUnchanged, I'd recommend that. I'm unfortunately not familiar enough with LMMS to present such a solution (and if you don't see a better way of doing it, that's okay - I'm still happy to see you implement this feature & I'm not going to hold up the PR over something like that).

@PhysSong
Copy link
Member

Something more about dataUnchanged... We have two use cases: one in BBTrackContainer's constructor, and the other in Song's constructor. However, I guess they doesn't do anything. What I can see about BBTrackContainer is 00d2d4a, but I don't know why we still have this.

Using (or even having) a dataUnchanged() signal on a model smells a bit fishy.

I think the intention was notify that user interacted with a controller when the value isn't changed(ex. select current item in combo box). However, I think we can cover such cases on controller's side(ComboBox in this case).

If you can see a way to achieve this work without using dataUnchanged, I'd recommend that.

and if you don't see a better way of doing it, that's okay

I think so. 👍

@Sawuare
Copy link
Member Author

Sawuare commented Apr 19, 2018

Thanks for your input, @Wallacoloo and @PhysSong.

I think the intention was notify that user interacted with a controller when the value isn't changed(ex. select current item in combo box).

Exactly. I don't know a way to achieve this without using dataUnchanged().

@Sawuare Sawuare merged commit f7a0553 into LMMS:master Apr 24, 2018
@Sawuare Sawuare deleted the LEDS branch April 24, 2018 08:26
sdasda7777 pushed a commit to sdasda7777/lmms that referenced this pull request Jun 28, 2022
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

Successfully merging this pull request may close these issues.

3 participants