Merge PTZListModel and PTZPresetModel

[glikely]

Removes the split-model design to clean up the separation between backend drivers and frontend UI

[EdueskaWeiz]

The Windows job is red on a single narrowing conversion that -Werror promotes:

src/ptz-device.cpp(523,34): warning C4267: 'return': conversion from 'size_t' to 'int', possible loss of data
error C2220: the following warning is treated as an error

m_presetsDisplayOrder is a QList<size_t>, so presetAtDisplayRow() returns a size_t out of an int function. The function already uses -1 as its not-found sentinel, so an explicit cast preserves the current contract:

 int PTZDevice::presetAtDisplayRow(int row) const
 {
 	if (row < 0 || row >= presetCount())
 		return -1;
-	return m_presetsDisplayOrder[row];
+	return static_cast<int>(m_presetsDisplayOrder[row]);
 }

The other four jobs are already green, so that should be all that is left.

One heads-up for merge order: this PR moves the preset data into PTZDevice, which overlaps with the preset_max clamp in #323. Whichever lands second will need a rebase.

[EdueskaWeiz]

Re-read the series against current main now that it is rebased. Two things.

Thanks for taking the narrowing fix — (int)m_presetsDisplayOrder[row] in presetAtDisplayRow() is what the Windows build was tripping over.

PTZListModel::insertRows() guards the wrong quantity

if (row < 0 || count <= 0 || row > ptz->presetCount() || row + count >= (int)ptz->maxPresets())

row is an insertion position, not a count, and the comparison needs to be against the resulting size. Two consequences:

One preset goes missing. on_actionPresetAdd_triggered() always appends, so row == presetCount(). With preset_max = 16 and 15 presets already there, row + count == 16 >= 16 and the "+" button silently stops working — 16 presets are configured, 15 are reachable. PTZPresetListModel::insertRows() allowed exactly 16 before this series, so this is a behaviour change inside a refactor.

A latent model/view desync. Inserting anywhere other than at the end while the list is full passes the guard: insertRows(0, 1, …) with 16 presets gives 0 + 1 >= 16 → false. beginInsertRows() is emitted, newPreset() then returns -1 because every id is taken, m_presetsDisplayOrder does not grow, and endInsertRows() announces a row the model does not have. Not reachable today since the only caller appends, but the old code structurally could not get into this state — it reserved the ids before beginInsertRows().

Suggested:

if (row < 0 || count <= 0 || row > ptz->presetCount() ||
    ptz->presetCount() + count > (int)ptz->maxPresets())
	return false;

and checking newPreset()'s return value inside the loop, to close the second one for good.

Small note in passing

The old PTZPresetListModel::insertRows() called beginInsertRows(parent, row, count), where the third argument should be the last row, row + count - 1. Your version has it right. That is a genuine fix rather than a move, so it may be worth a line in the commit message.

I have not run this build yet — the findings are from reading the diff. If it would help I can build the branch on Windows and exercise the preset list against OBS 32.2.1, same setup I used for #324.

[glikely]

PTZListModel::insertRows() guards the wrong quantity

if (row < 0 || count <= 0 || row > ptz->presetCount() || row + count >= (int)ptz->maxPresets())

row is an insertion position, not a count, and the comparison needs to be against the resulting size. Two consequences:

Good catch, thanks.