Rodegast
Там в подсистему CRM входит только 29 справочников, если речь идёт не об универсальном, а о самописном решении ориентированном на конкретную задачу, то справочников должно быть меньше. Откуда их у вас 50шт. взялось я с трудом представляю.

Взялись они из ТЗ, их количество вообще не играет роли, особенно учитывая, что всё их различие в присвоение таблицы и имен хидеров таблицы, да и клепается справочник из готового виджета за пару минут. Это к вопросу о “чистый код + наследование vs ручная отрисовка в дизайнере”.

Rodegast
Разве я где-то писал что у меня с этим есть сложности? Я постоянно использую кучу виджетов написанных в ручную, но это не отменяет дизайнер.

Ок. То есть описанных выше Вами сложностей уже нет.
“Ручной код” дизайнер ни в коем случае не отменяет, здесь я с Вами полностью согласен, вопрос в том что удобнее, так вот моё мнение, что удобство напрямую зависит от практики, чем её больше тем меньше потребность в автоматизированных средствах генерации кода, точно также как и html-страницы, человек мало знакомый с web будет делать в каких нибудь MS FronPage, Adobe Dreamviewer и даже, “о ужас” экспортом из MS Word, а профессионалу достаточно обычного редактора кода.

А велика ли разница между наследованием от самописного и сгенеренного pyuic классов?

> их количество вообще не играет роли, особенно учитывая, что всё их различие в присвоение таблицы и имен хидеров таблицы

Ой! Кажется количество используемых форм сократилось на 49 штук. Со всем остальным скорее всего будет тоже самое. Так что ваша распальцовка со 120-ю формами оказалась не убедительной.

> Ок. То есть описанных выше Вами сложностей уже нет.

Всё что я выше писал относится к созданию форм. А “Ручной код” используется в основном для виджетов.

> так вот моё мнение, …., точно также как и html-страницы, человек мало знакомый с web будет делать в каких нибудь MS FronPage, …. а профессионалу достаточно обычного редактора кода.

Где это вы видели что-бы сейчас html-страницы в редакторах набирали? Всю работу делают шаблонизаторы, которые как ни странно являются “автоматизированными средствами генерации кода”. Так что и тут вы не правы.

> А велика ли разница между наследованием от самописного и сгенеренного pyuic классов?

Разницы почти нет.

Metallikus
А велика ли разница между наследованием от самописного и сгенеренного pyuic классов?

Сгененрированный все равно переписывать, после каждого малейшего изменения.

Rodegast
Ой! Кажется количество используемых форм сократилось на 49 штук.

С чего бы сократилось? Каждая форма уникальна, но все наследуются от всего нескольких виджетов. Я про что талдычу в какой уже раз?

Rodegast
Так что ваша распальцовка со 120-ю формами оказалась не убедительной.

Ух ты, количество классов в проекте у на вашем жаргоне называется “распальцовка”? Может тебе тогда на Java перебраться, будешь весь распальцованный.

Rodegast
Где это вы видели что-бы сейчас html-страницы в редакторах набирали? Всю работу делают шаблонизаторы, которые как ни странно являются “автоматизированными средствами генерации кода”. Так что и тут вы не правы.

А всё понял. Мне стало кристально ясно с кем я общаюсь. До свидания.

Alen
Сгененрированный все равно переписывать, после каждого малейшего изменения.

А что если создать новый модуль, описать в нём наследованный от сгенереного окна класс, и переписывать уже класс-наследник? Тогда ведь все изменения останутся даже после изменения окна в Qt-Designer.

А есть ещё вариант подключения к проекту непосредственно .ui файлов без их конвертирования, что на этот счёт?

> Каждая форма уникальна, но все наследуются от всего нескольких виджетов. Я про что талдычу в какой уже раз?

Сначала вы талдычили про 120 форм, потом про 50 справочников, потом вы пишите что форма у вас 1 но виджет разный, теперь “все наследуются от всего нескольких виджетов”. Со стороны создаётся впечатление что вы просто занимайтесь каким-то дешёвым пиаром, как раз его я и назвал “распальцовкой” (а не класс как вам показалось). Если у вас выработан свой подход в построении GUI, то опишите его подробнее, приведите диаграмму классов. Иначе ничего кроме троллинга не получится.

> А всё понял. Мне стало кристально ясно с кем я общаюсь. До свидания.

Пример с шаблонизатором был не совсем удачным, но я только пытался ответить в предложенном вами контексте html-страниц. А смысл был в том что побеждает более эффективный подход, так что вы и тут всё не так поняли.

> А есть ещё вариант подключения к проекту непосредственно .ui файлов без их конвертирования, что на этот счёт?

Есть. Но я бы не рекомендовал, будет дополнительная задержка при запуске к тому же если код будет закрытым, то этот вариант совсем не подходит.

Metallikus
А что если создать новый модуль, описать в нём наследованный от сгенереного окна класс, и переписывать уже класс-наследник?

Ну, к примеру, собрал ты такое окно, а потом обнаружил, что надо его растягивать в зависимости от разрешения экрана. Все эти замеры надо прямо в окно встраивать, а у тебя там автоматический код. Результат - нужно городить.

> Все эти замеры надо прямо в окно встраивать, а у тебя там автоматический код. Результат - нужно городить.

УЧИ МАТЧАСТЬ
http://welinux.ru/post/7471/

Так что ль? С тем же успехом это можно реализовать и в наследнике генерируемого класса имхо.

Rodegast
УЧИ МАТЧАСТЬ
http://welinux.ru/post/7471/

И что там? Как ты добавишь в окно новый функционал, относящийся к нему?

Metallikus
Так что ль?

if соотношение_сторон == широкоэкраннное:
    рисуем блок с кнопками в правой части окна
    задаём ему vboxlayout
else:

Ты предлагаешь, чтобы окно сначала настраивалось, а потом перенастраивалось? Или ты предлагаешь переопределить метод?