Qt + QObject + template...

Зачем тебе все это? Задача какая стоит?

Делаем класс QObjMyClass, вносим все что надо от moc'а. Помним, что moc работает только со статикой (не каких шаблонов)

Делаем наш MyTemplClass, наследую его от QObjMyClass

Профит

Все можно сделать и в одном файле.

Это если тебе надо добавить QMetaInfo

Если нет (то есть нет макроса Q_OBJECT, Signal/slots) - то можешь делать что хочешь

Локализация работает по поиску строку tr, trUtf8, QT_TR, и не как от шаблонов не зависит

Не хочу плодить три одинаковые модели для немного похожих классов, которые имеют схожий интерфейс (функции name() и clone()) но на этом сходство заканчивается и идейно они никак не связаны и общего предка иметь не должны, а модели для них одинаковы как две капли воды вот только хранят они QList<someclass*> и использут someclass->name() кое где, так что хранить что-то отличное от QList<someclass*> (ну там void* или QVariant не выход). Хочется забубуенить шаблон для этой модели и забыть про неё навсегда.

НО смущает тока то что я в классе производном от QObject не использую Q_OBJECT и не ействую на него MOCом. С другой стороны я в этом классе метаобъектный функционал не трогаю, но не факт что Qt не пользует его для моей модели в собственных нуждах. Тут я не до конца догоняю будет Qt выдеть мою модеть как QAbstractItemModel или вообще никак видеть не будет и развалиться.

чет такое я вообщето и сотворяю, но не уверен что будет работать.

ЗЫ: про локализацию: та самая tr, trUtf8 и пр tr.. и определяется в Q_OBJECT если че. Я как раз имел ввиду что никаких запчастей от этого велосипеда (Q_OBJECT) не пользую.

любой предок является Q_Object'ом Значит тебе доступен tr. Хотя надо эксперементировать

Не надо экспериментировать, см qobjectdefs.h и правда tr в public секции объевлен, так что доступен. С lupdate правда будет трабла так как контекст переводмых строк она определит неправильно если пользовать tr родительских классов.

по моему и контекст он правильно определит. именно это я и имел в виду

Неа, контекст определяет lupdate по тому что стоит перед последним :: в функции где встретился tr, а tr родительского класса забивает в QApplication::translate контекст на основании метаинформации родительского класса.

Не хочу плодить три одинаковые модели для немного похожих классов, которые имеют схожий интерфейс (функции name() и clone()) но на этом сходство заканчивается и идейно они никак не связаны и общего предка иметь не должны, а модели для них одинаковы как две капли воды вот только хранят они QList<someclass*> и использут someclass->name() кое где, так что хранить что-то отличное от QList<someclass*> (ну там void* или QVariant не выход).

когда такие штуки происходят, чаще всего это свидетельство плохого дизайна, так что начинайте прямо с консерватории