You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From PR #6322, in regards to void ShipCustomWarpDialog::rejectHandler():
This seems like a common enough pattern that it should be in the superclass or in a utility function somewhere, though maybe that's beyond the scope of this PR.
And also in regards to void ShipCustomWarpDialog::startSoundChanged():
The string wrangling should definitely be in a utility function. If you want to do that in a different PR that's fine; but if string wrangling is necessary, then there should be qtFRED-wide utility functions for converting from Qstring to std::string and vice versa.
More generally, it would be useful to reuse code as much as possible in qtFRED, since a lot of the dialogs involve a lot of boilerplate. Templates and pointers-to-members could help here, so for example a simple get/set of an attribute could use templated logic that applies for all such simple fields in the dialog.
The text was updated successfully, but these errors were encountered:
Goober5000
added
qtfred
A feature or issue related to qtFred.
refactor
A cleanup/restructure of a feature for speed, simplicity, and/or maintainability
labels
Dec 12, 2024
From PR #6322, in regards to
void ShipCustomWarpDialog::rejectHandler()
:And also in regards to
void ShipCustomWarpDialog::startSoundChanged()
:More generally, it would be useful to reuse code as much as possible in qtFRED, since a lot of the dialogs involve a lot of boilerplate. Templates and pointers-to-members could help here, so for example a simple get/set of an attribute could use templated logic that applies for all such simple fields in the dialog.
The text was updated successfully, but these errors were encountered: