Да, но вообще-то тема была не об этом.  

azesmcar, А если серьезно, то и вправду можно изменить uic. Посмотрел, кода не много. Можно его генератор заточить как хочется, и будет он тебе генерить то, что хочешь.

Лежит в $(QTDIR)/src/tools/uic

Посмотри код асистента, дизайнера.. Простые, но вполне реальные примеры.


Так не стоит. Я считаю, что делить класс на файлы - это зло.


В мире Qt (да ладно, что уж самих себя обманывать - вообще в мире десктоп-гуя) MVC подход в нормальном виде не принят (Model View Framework в Qt - это не MVC).


Функции подсчётов - очевидно, отдельные классы (или просто функции даже). Это ж domain layer (busyness layer).
Отдельный виджет основного поля калькулятора (умеющего отображать состояния ошибки, переключать отображение числа с разной точностью и т. д.).
Отдельный виджет поля кнопок. Опционально - виджеты групп (блок цифр, блок таких-то операций, блок таких-то операций).
Возможно - подгрузка функций через плагины и соответственно абстракция для задания лейаута (в самописном xml-е проще всего) 
Отдельный класс для основного окошка.
И т. д. Это ж только пример  


Потому что композиция лучше, чем наследование. Читаем любую книгу по ОО-дизайну.


Насчёт криэйтора вообщем согласен, но всё-таки preffered way это ассистент с дизайнером (они проще гораздо). А вот последние два - не рекомендую. При том, что там есть хорошие идеи, как идеальный пример - точно не пойдут. Уж извините, но они остаются "оупенсорсными поделками" (проекты сами плохими из-за этого не становятся, я их уважая и пр. - поймите меня правильно).


На qtapps.org когда-то натыкался на "правильную" реализацию генерилки для ui-файлов (когда после переноса одного лейбла не надо рекомпилить всё).  Не тестил 

Где "оно" ?

http://www.qt-apps.org/content/show.php/Sp...I?content=61344

Оказывается, работает как обёртка над uic-ом. Что, впрочем не есть плохо.

Сейчас гляну.


Я тоже не люблю делить, но просочилась идея от partial class -а в C#, студия генерирует функцию инициализации компонентов в отдельном от самого кода файле, думалось реализовать что-то наподобие этого, но...как я сказал мне и самому не нравится.


 Я его применение удачно только для Web -а видел.


В общем-то все также, но сам интерфейс разделен на несколько групп. Ясно. Спасибо.


Потому я и спросил

Ну а вообще-то не всегда. private наследование вполне приемлемо в данной ситуации (если не считать потенциальных проблем, которые я указал выше).

Любитель большое спасибо за содержательный пост.

azesmcar
оО где где а вот в QT помоему не должно быть проблем с оформлением и размещением кода =)

если проект больше чем калькулятор или "блокнот" то лично я делаю:

1) Если интерфейс простой (1 окно, небольшое количество виджетов), большая чатсь программы - логика.
а. То весь интерфейс описываю в своем классе (KipMainWindow, унаследованный от QMainWindow или QDialog);
   в конструкторе класса описываеться интерфйес этого окна (создаються виджеты/лейоуты и т д)
  также этот класс наделяю функциями котоыре онтосяться только к интерфейсу! Никаких функций обрабатывающих логику (т.е назначение этой программы)
 и создаю слоты для влияния на интерфейс из классов логики.

б. Всю логику (Классы/функции назначения программы) заношу в другой класс/классы Наследуемые от QObject. Определяю слоты для сигналов от интерфейса и сигналы для влияния на интерфейс.

в. Связываю слоты и сигналы Обьекта интерфейса с Обьектами Логики =)

2) Если интерфейс большой и накручен множеством элементов управления, то разбиваю его на сегменты (Фреймы, меню, диалоги,) и распределяю их по нескольким классам. Которые позже создаю в том же KipMainWindow ну и дальше как в пункте 1

Добавлено через 5 минут и 45 секунд
В моем идеалистическом взгляде... необходимо отделять интерфейс и логику решающую конкретную задачу.

Любопытно. Как такое возможно без наследования от QObject ?  

Я же сказал, все классы в приложении имеют наследование от QObject. Но темнеменее логика находиться отдельно от интерфейса (в разных классах)

Вообщем кому как удобно, можно хоть всю программу в 1 единственный класс запихнуть при желании =)))

Любопытно, а почему так важен вопрос наследования от QObject? какие еще плюсы дает такой вариант, кроме общей для проекта модели взаимодействия сигнал\слот? 

имхо, при таком подходе логика становится зависимой от конечного user interface и непереносимой.

Без этого сигналы/слоты и много другое не будет работать.

andrew_121, это как раз и понятно. 

korbian, Даёт возможность пользоваться автоматическим разрушением чайлд-объектов (если понятие иерархии применимо к ним), поиском чайлдов, загрузкой объектов из плагинов, пользоваться qobject_cast, etc. Хватит?  

Любитель, хватит.  только мне кажется сомнительным награждать конечный интерфейс бизнес логики такими "ништяками", теряя переносимость. я бы делал еще один промежуточный слой для взаимодействия в концепции модели end-point user interface.

p.s. хотя qt давно уже не фреймворк для ГУИ, а гораздо больше и зависимость от нее может быть требованием проекта.

Во-во.

Вы часто делали десять ГУИ-фронтендов к одной программе (да, бывает - но это исключение, а не правило)?