Эта ненужная программа не позволяет сделать pull. Пишет refusing to merge unrelated histories. Больше не буду пытаться. Мне времени жалко.
Updated: добавлена возможность. Можно удалять выделенное, как один меш, так и несколько. Проверял десять минут подряд, багов не выявил.
Virtual_Light
> Как пользователь будет писать плагин без SDK?
Ему нужно заголовочные файлы и статические библиотеки движка. Всё. Больше ничего не надо.
А ты зачем то отделяешь части движка в отдельный проект.
Virtual_Light
> Зачем? Shell его никак не использует. Плагины загружает движок, чтобы получить
> прямой доступ к их механике. Shell это посредник.
Значит его тоже в include движка. Пусть там лежит. Поменьше ненужных проекто плоди.
Virtual_Light
> Эта ненужная программа не позволяет сделать pull. Пишет refusing to merge unrelated histories. Больше не буду пытаться. Мне времени жалко.
С ее помощью ты сэкономишь больше времени. Просто научись пользоваться нормальными инструментами.
Там можно делать пользовательские действия.
Добавь новоей действие которое исполняет команду:
git pull --allow-unrelated-histories
И вызови ее через кнтекстное меню.
DDR3
> Ему нужно заголовочные файлы и статические библиотеки движка. Всё. Больше
> ничего не надо.
> А ты зачем то отделяешь части движка в отдельный проект.
Что должно лежать в статической библиотеке и при этом не быть частью движка?
git pull DREAMS2 master --allow-unrelated-histories
Результат:
The following untracked working tree files would be overwritter by merge:
<два vcxproj файла>
Please move or remove them before you merge.
DDR3
> А ты зачем то отделяешь части движка в отдельный проект.
Понятно. Я сделаю отдельный класс zPublicMesh, который будет находиться только в плагинах. Научу движок с ним работать. В плагинах и SDK не будет частей движка.
DDR3
> Ему нужно заголовочные файлы и статические библиотеки движка.
Значит, движка всё-таки. Не SDK. То есть плагин будут писать, опираясь прямо на движок. На какую-нибудь папку из комплекта с нужными компонентами.
Virtual_Light
> В плагинах и SDK не будет частей движка.
Тебе надо чтобы юзер работал с теми же классами с которыми работает движок и редактор.
Не нужно ввделять как то sdk отдельно. В твоем случае это условное понятие. То есть часть заголовочных файлов проекта и есть sdk. Их не нужно в отдельный проект выделять.
В общем сделаю форк твоего проекта и оргагизую как следует и потом кину ссылку.
DDR3
я удалил SDK, файлы распределил по другим проектам. Переименовал проекты: Dream_Shell в Dreams_Editor, Dreams_Engine оставил.
Разобрался с git. Можно коммитить чаще.
Virtual_Light файлы реализации undo, это нормально что на каждый параметр свой класс?
DDR3
Нормально. Каждый параметр - это команда, наследованная от QUndoCommand.
http://doc.qt.io/qt-5/qundocommand.html
Эти команды создаются в момент изменения параметра и кладутся в стек. Стек вызывает их по команде из меню(это стандартная механика Qt).
А можно как нибудь сделать так чтобы команды относящиеся к одному объекту были в одном файле(h, cpp)?
DDR3
можно. Просто положить несколько классов в один файл.
Virtual_Light я просто думал что они автогенерируемые.
DDR3
> думал что они автогенерируемые.
Это не так, и в этом тонкость. QUndoCommand не наследуется от QObject, не имеет свойств и не работает с сигналами/слотами. Всё сделано для простоты и большого количества. Поэтому их нельзя создавать мастером классов Qt, встроенным в VisualStudio. Можно, но придётся много править. Они все сделаны по одному шаблону копипастом. Поэтому они уже написаны.
Добавлены возможности.
Тема в архиве.