In D16663#367765, @asemke wrote:

• QSharedPointer has additional overhead for reference counting which we don't need in this case. Can we use std::unique_ptr here?

Whenever LiveDataSourcce::setFilter(currentFileFilter()) is called, we cannot know whether the filter object will exist, when it's used in a LiveDataSource.
For example, in MainWin::newLiveDataSourceActionTriggered() a filter is set by ImportFileWidget, which then is deleted as a child of ImportFileDialog:

	...
	else {
		LiveDataSource* dataSource = new LiveDataSource(i18n("Live data source%1", 1), false);
		dlg->importToLiveDataSource(dataSource, statusBar());
		this->addAspectToProject(dataSource);
	}
}
delete dlg;

So for the code as it is, I think reference counting is required. But sure, its use can be limited.

In D16663#369911, @croick wrote:

In D16663#367765, @asemke wrote:

• QSharedPointer has additional overhead for reference counting which we don't need in this case. Can we use std::unique_ptr here?

Whenever LiveDataSourcce::setFilter(currentFileFilter()) is called, we cannot know whether the filter object will exist, when it's used in a LiveDataSource.

Usually there is always a filter which is created for the preview of the selected file. And when we call LiveDataSource::setFilter(currentFileFilter()) we create a new filter in currentFileFilter() anyway if no filter is available yet. So, there will always be an filter object when we close the dialog with Ok.

My point here is, there is actually never a moment where we have more than one reference to this filter - we either use it in ImportFileDialog or later in LiveDataSource. With this we can transfer the ownership when we close the import dialog/widget (use the raw point as "usuall" in LabPlot or make it more explicit via unique_ptr) and there is actually no need for ref-counting. But you have a valid point with the destruction of ImportFileWidget. When destroying this widget we cannot know whether the created filter is going to be used (Ok button clicked vs. Cancel button clicked) without adding additional logic. You propose to use the shared pointer to implement this logic. This is ok, I think. The only not so nice thing about this is that we "pollute" LiveDataSource and MQTTClient because of some internal details of ImportFileWidget... So, if you don't have any other ideas here, submitt your patch. Please also check my minor comment in the code.

Thanks for looking into this!
I think you have a point about consistency with raw pointers. If we make sure that any use of setFilter(filter) is followed by releasing ownership of the filter, then that should be fine.
I will add a line in the function documentation to make it clear.

Changes to MQTT I will submit in a separate commit and remove some whitespace-only changes that I just discovered.

Would you be fine with this solution?