Rodegast
Вот за это надо руки отрывать. И пользуйся дизайнером, интерфейсы в ручную набирать не нужно.

Ser5+
На счет интерфейса по мне так вручную проще.

Да, сомнительно что всегда надо в дизайнере делать. Вот недавно редактор конфигурационных файлов делали. Внешний вид определялся шаблоном конфигурационного файла, написанном на специальном языке описания шаблонов конфигурации. Там из элементов которые в дизайнере можно набрать помоему только статусбар был. Остальное все на ходу лепилось.

Иногда когда две кнопки да менюшка из двух пунктов дизайнер полезен. В последних 5 наших мини проектах помоему ни разу не было чтобы интерфейс делали в дизайнере. Наверное это сильно зависит от задачек и от привычек разработчиков.

Rodegast
Вот за это надо руки отрывать. И пользуйся дизайнером, интерфейсы в ручную набирать не нужно.

тоже не соглашусь, дизайнер хорош для сатичных интерфейсов один раз и нвсегда прибитых гвоздями, а ежели что посложнее то тут приходиться только ручками…

> Мне кажется нет смысла использовать везде классы. Я обычно класс использую один раз и только для главного окна. Если нужны события в каких-то других окнах,то да обертываю в класс.

Поделие под названием TkInter в тебе ощущаю я…

> На счет интерфейса по мне так вручную проще…

Ну это уже много раз обсуждалось http://python.su/forum/topic/25622/?page=1#post-136978

> Внешний вид определялся шаблоном конфигурационного файла, написанном на специальном языке описания шаблонов конфигурации.

ИХМО автогененрация форм это совсем другая задача, для её решения дизайнер как раз не нужен.

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

Как раз на сложных интерфейсах дизайнер наиболее эффективен.

Rodegast
И пользуйся дизайнером, интерфейсы в ручную набирать не нужно.

Использую дизайнер для создания .ui файлов. Это когда делаю программы на Python/Qt и на C++/Qt. Но я и не скрываю, что после создания ui-файла я могу к нему применить ещё ряд своих скриптов, которые его переделают дальше до неузнаваемости либо возьмут что-то из него и вытащат наружу.

PEHDOM
а ежели что посложнее то тут приходиться только ручками

Когда у тебя десяток программ, ты уже и не помнишь, что там за дизайн в каждой. А уж как он там устроен и как его менять дальше - тем более. Фактически заново каждый раз приходится собственную программу изучать по своим же мануалам.

py.user.next
Когда у тебя десяток программ, ты уже и не помнишь, что там за дизайн в каждой. А уж как он там устроен и как его менять дальше - тем более. Фактически заново каждый раз приходится собственную программу изучать по своим же мануалам.

Имелось ввиду под “сложным” не колличество элементов, а динамичность, тоесть когда интерфейс меняеться в зависимости от задачи, или генерируеться на лету, примерно как писал doza_and “Внешний вид определялся шаблоном конфигурационного файла, написанном на специальном языке описания шаблонов конфигурации”

PEHDOM
тоесть когда интерфейс меняеться в зависимости от задачи, или генерируеться на лету

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

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

PEHDOM
интерфейс меняеться

PEHDOM
или генерируеться

Заходи на https://tsya.ru/ , проходи микрокурс.

> Имелось ввиду под “сложным” не колличество элементов, а динамичность, тоесть когда интерфейс меняеться в зависимости от задачи

Вообще не проблема. Ставишь штакет и переключаешь его.

> или генерируеться на лету

В этом случае дизайнер не нужен, но и в ручную форму ты тоже не набираешь.