Qt Project жив!

Гномокапец.

То есть они изобрели по сути html-виджет. Как результат, теперь в Qt 2 технологии, делающие одно и то же.

Какая гнилая отмаза, аж жуть.

> могу ли я выпустить закрытый софт на Qt и продавать его, без открытия исходных кодов??

Да, при условии что он не является производным от Qt и не вносит изменений в саму Qt. man LGPL.

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

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

GUI всегда делают разработчики, ибо запускать грязные руки дизайнеров в код - себе дороже. Другое дело, что общую концепцию вариантов использования и внешний вид UI действительно лучше разрабатывать специалистам по useability и дизайну, а потом уже ставить задачу программистам.

Где 5.0? А где 4.8? Подохло оно, это же очевидно.

Нет, html-виджет там тоже есть, qml больше похож на пайтон по простоте и на yaml по своим целям. И, в любом случае, чем больше возможностей по-разному выполнить одно и то же действие в соответствии с привычками разработчика, тем лучше.

Не совсем понимаю смысл критики: qt м.б. только компилируемым? нет, можно и со скриптовыми языками работать. Можно со скриптовыми? Значит, с qt 2 ничего не сдвинулось!

Или qt плохой, просто потому что это qt?

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

Исправление мелких багов чаще всего изменяет пару строк, что в итоге приводит к необходимости перекомпиляции одной или нескольких единиц трансляции, что происходит очень быстро (конечно если была произведена хорошая объектная/модульная декомпозиция). Даже если производится изменение в заголовочном файле, это не всегда влечет за собой пересборку большей части проекта. А серьезные баги, которые вызваны чуть ли не ошибкой на стадии проектирования лечатся только перепроектированием с последующим рефакторингом - тут уж ССЗБ.

>Разве быстрее изобрести свой велосипед, чем изучить интерфейс готового решения?

А что, мы говорим про быстроту разработки? Или про удобство интерфейса? Быстрота - это вообще консоль. Там вообще ничего делать не надо.

В случае с велосипедом надо как минимум изучить предметную область до уровня эксперта

А разве это плохо - изучить предметную область достаточно глубоко, а не клепать готовые интерфейсы 20-летней давности?

Другое дело, что общую концепцию вариантов использования и внешний вид UI

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

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

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

Да, нету левых больших букв.

Есть такая вещь - копропротивный стиль кодирования. Хороший он или плохой - но его требуется использовать.

А можно вообще ничего не писать, кроме запроса «Хачу праграму на кампутере которая бы видио играло, и да, на qt, потому шо там есть даные и ерархии»

Т.е. нормальных контраргументов по данному вопросу не имеется?

>Нет, html-виджет там тоже есть, qml больше похож на пайтон по простоте и на yaml по своим целям. И, в любом случае, чем больше возможностей по-разному выполнить одно и то же действие в соответствии с привычками разработчика, тем лучше.

Я говорю про возможности. И стандартный тулкит, и html-виджет - это по сути компоновка стандартных виджетов. Да, разный синтаксис и несколько разный внешний вид, внутреннее устройство, но суть одна. В Qt html-виджет - это webkit. А GUI - это то ядро, которое и было. Две разные реализации почти похожих технологий.

Или qt плохой, просто потому что это qt?

Qt - это пушка. Которую используют для стрельбы по воробьям. Для пользователя что тот же fltk, что qt - всё одно. За исключением эстетики. То есть, для пользователя Qt - это сложный инструмент, вся сложность которого создавалась ради гламура, и только. Вот за это " и только" и критикую. Нет в нём ничего такого, что улучшает GUI в плане использования. Только в плане красоты. Ну и да, программисты радуются, что любимые формочки проще делать.

>Вот и приводит всё это к тому, что GUI к программам делают прогеры, а не дизайнеры. И поэтому интерфейсы такие убогие.

Да линух чуть ли не везде такой, но от этого ведь не хуже, правда? Как по мне - дак пусти дизайнеров ГУЙки крутить, так потом все будет такое миленькое и красивенькое, переливаться/прозрачниться, будет супермегакрутой необычный интерфейс от юдашкина к каждой программе, никакого стандартного управления. Иной раз под оффтопиком в какой-нибудь утилитке пока крестик закрытия найдешь разозлиться успеешь.

На работе приходится пырить в дисплей с Шindows 7, после этих дизайнерских десктопов на xfce глаза отдыхают. И разум.

И вообще, разве не православно писать программу без гуя вообще, но продумав текстовый интерфейс так, чтоб потом было легко надстроить хоть GTKшный, хоть Qtшный, хоть веб, хоть черта_лысого_еще_какой интерфейс?

Вообще-то 4.8.0rc давно уже есть.

>А серьезные баги, которые вызваны чуть ли не ошибкой на стадии проектирования лечатся только перепроектированием с последующим рефакторингом - тут уж ССЗБ.

А что, теория безошибочного проектирования уже создана? Или создано ПО для моделирования архитектуры другого ПО?

>Да линух чуть ли не везде такой, но от этого ведь не хуже, правда?

Такие почти все любительские программы под любой ОС.

Как по мне - дак пусти дизайнеров ГУЙки крутить, так потом все будет такое миленькое и красивенькое, переливаться/прозрачниться, будет супермегакрутой необычный интерфейс от юдашкина к каждой программе, никакого стандартного управления. Иной раз под оффтопиком в какой-нибудь утилитке пока крестик закрытия найдешь разозлиться успеешь.

Не путайте дизайнеров и художников.

И вообще, разве не православно писать программу без гуя вообще, но продумав текстовый интерфейс так, чтоб потом было легко надстроить хоть GTKшный, хоть Qtшный, хоть веб, хоть черта_лысого_еще_какой интерфейс?

Практика показала, что это не работает. Ибо парсить текст много сложнее, тем более православными регекспами, чем просто передать распарсенные параметры в скриптовом языке.

> А что, теория безошибочного проектирования уже создана?

Ну не совсем чтоб, но Технологию программирования студентам щас читают стрелянные старые кодеры.

> А что, мы говорим про быстроту разработки? Или про удобство интерфейса? Быстрота - это вообще консоль. Там вообще ничего делать не надо.
Да, мы говорим про быстроту разработки и удобство интерфейса, я твой же комментарий процитировал. Если ты другой ананимус, то хоть следи за нитью разговора, комментируешь сам не знаешь что.

А разве это плохо - изучить предметную область достаточно глубоко, а не клепать готовые интерфейсы 20-летней давности?

Если решение 20-летней давности удовлетворяет современным требованиям - смысла повторной реализации нет. Но повторюсь - чтобы реализовать свое решение, ты должен знать предметную область на хорошем уровне, иначе сделаешь узкоспециализированный велосипед для некоторого частного случая. Возьмем к примеру простую задачу: извлечь информацию из XML-файла. Если ты изучишь интерфейс готового решения из QtXml (например QDomDocument / QDomElement), то на решение задачи у тебя уйдет совсем немного времени. Если ты будешь создавать свой велосипед на гусенично-весельном ходу, то ты положишь на него уйму времени и до решения собственно самой задачи у тебя даже руки не дойдут.

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

Ты дурак или просто троллишь? Концепция вариантов использования GUI - это как раз и есть твои тысячи мелочей, которые прорабатываются специалистом по useability. Выше я НЕ утверждал, что программист компетентен в таких вопросах.

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

Развернутое определение компилируемого интерфейса в студию!

>Нет в нём ничего такого, что улучшает GUI в плане использования

А где есть? По сравнению с виндовыми виджетами сразу вспоминается возможность прокрутки значений по колесу, которой тогда в windows не было, не знаю, как сейчас. Или имеется в виду что-нибудь вроде подгонки под тачскрины?

>Технологию программирования

Это авторские курсы или учебники?

> Вообще-то 4.8.0_rc_ давно уже есть.

Нутыпонел. Жду релиза и обещаного сверхкороткого цикла обновлений QtWebkit, и черта с два дождусь.

> Number Five Is Alive.

Это который Джонни? :)

> Такие почти все любительские программы да у нас вся ОСь такая любительская, но я первый брошу камень в того, кто скажет что она не прекрасна (по крайней мере здесь ))))

Не путайте дизайнеров и художников.

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

Практика показала, что это не работает.

Не соглашусь: есть гора программ, которые это умеют. Сложнее, кто спорит, но делать православно оно всегда сложнее. Зато лучше в конечном итоге. Ведь приятно же, когда так сделано, вот ведь всем нравится и всех устраивает. Опенсорс кругом, берем да доделываем (в свободное время и если оно НАМ надо), кто нам запретит?

> А что, теория безошибочного проектирования уже создана? Или создано ПО для моделирования архитектуры другого ПО?

Ты что, постоянно делаешь ошибки исключительно на стадии проектирования, раз на стадии отладки приходится переписывать много кода, что вызывает долгую пересобрку всего проекта?

>Да, мы говорим про быстроту разработки и удобство интерфейса

Я говорил про разработку удобного интерфейса, а не абы какого.

Если решение 20-летней давности удовлетворяет современным требованиям

Не удовлетворяет.

Возьмем к примеру простую задачу: извлечь информацию из XML-файла.

Нет такой задачи у пользователя.

Концепция вариантов использования GUI - это как раз и есть твои тысячи мелочей,

Концепция - это уже не тысячи вариантов. Это основа, а не тонкости. Или вы можете проработать потребности каждого пользователя? Или считаете, что индивидуальная настройка под себя не нужна?

Развернутое определение компилируемого интерфейса в студию!

Интерфейс, который невозможно полностью настраивать в процессе работы.

> Это авторские курсы или учебники?

Авторские, но не будь я Карлос Санчос, столько всего полезного узнал, от стольких ошибок уберегли в зародыше. Да че рассказывать, все (из тех, у кого призвание) когда-то учились программировать сами, костыли изобретали, индусокодили и т. д. А тут стоит перед тобой опытный мужик и рассказывает как делать не надо, а как надо и ПОЧЕМУ так. Расскажет пару примеров из жизни. И вот теперь вродь и несерьезное что-нибудь пишешь, а тонна комментариев с подробынм разъяснением всех моментов, которые сам же не поймешь потом, и микро-справочник по функциям как-то сами собой возникают :)

>но я первый брошу камень в того, кто скажет что она не прекрасна (по крайней мере здесь ))))

Ну бросайте в меня.

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

На практике как раз таки есть грань. Дизайнер делает удобный интерфейс, а художник - только лишь красивый.

Не соглашусь: есть гора программ, которые это умеют.

Покажите.

Ошибки на стадии проектирования наиболее сложно исправляются.

Блин, ссори за подобное оформление.

ПОВТОРЯТЬ (ПОКА НЕ ДОЙДЕТ)

{

я буду пользоваться кнопкой «предпросмотр» пока не привыкну к системе комментов на ЛОРе

}

Что же они, нехорошие люди, учебники-то не пишут?

Не переживай, все по плану: релиз 4.8 до конца года (вчера или позавчера rc3 вышел), 5.0 в первой половине 2012 г.

Повторять. пока не дойдёт: интерфейс лора делали программисты, а не дизайнеры. Вот и результат.

> Нет такой задачи у пользователя.
При чем здесь пользователь, если речь о разработчике?

Или считаете, что индивидуальная настройка под себя не нужна?

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

Интерфейс, который невозможно полностью настраивать в процессе работы.

Возвращаюсь к вопросу:

И чего она стоит в компилируемом gui?

В котором под словом «она» понимается паттерн model/view (см. комментарии выше).
Так вот, model/view не ограничивает возможность настройки интерфейса под себя, а предоставляет программисту чрезвычайно гибкий инструмент для создания удобных, хорошо выглядящих и по необходимости настраиваемых элементов управления (представлений).
Еще раз напоминаю для альтернативно одаренных, кто не в состоянии отследить цепочки ответов на комментарии, что обсуждался следующий вопрос:

Ну и? Что там такого? Особенно того, что используют сложные программы.

> Ну бросайте в меня.

Это древняя провокация ) мне религия не позволит бросить камень в человека, с которым поспорить приятно, который ведет спор вежливо и, даже (О УЖАС!!!) знаки препинания расставляет. Есть более годные мишени )

Покажите.

Первое что пришло на ум - tar. Все мы его использовали в консоли (текстовый интерфейс), я лично еще использовал Xarchiver в гноме и Squeeze в xfce (GTK), а после минутного гугления выяснил что еще бывают KDat для кед, очевидно на Qt и, даже, GUI Tar для макоси (фиг знает на чем там она :) ИМХО, все счастливы, все довольны. А ведь это один архиватор.

> Ошибки на стадии проектирования наиболее сложно исправляются.

Спасибо за науку, Кэп ;)

> Ошибки на стадии проектирования наиболее сложно исправляются.

Спасибо, кэп!

>Что же они, нехорошие люди, учебники-то не пишут?

Пишут. Конкретно этот мужик методичку годную написал, занимается издательством, годным студентам раздает, опубликовал у себя на сайте. Но ИМХО живая работа с преподавателем в сто рез эффективнее.

> Повторять. пока не дойдёт: интерфейс лора делали программисты, а не дизайнеры. Вот и результат.

ЛОР делают программисты для программистов (ну, грубо говоря), программисты, пилящие ЛОР, понимают, что писать здесь будут, в основном, люди которых не напугаешь таким интерфейсом (кто напугается - при желании обучится или отфильтруется, всем счастье), для программистов же, напротив, такой интерфейс имеет очевидно много плюсов (да хоть бы кусок кода вставить) просто с непривычки иногда забываешь, но это, я думаю, пройдет со временем.

>При чем здесь пользователь, если речь о разработчике? Вы задачу-то поподробнее опишите. Зачем вам вытаскивать данные из XML и какое это имеет отношение к интерфейсу?

Хотя вон огрызки продвигают свое видение удобства интерфейса

Интерфейса чего? Программ? У них чего-то революционного в программах для работы чего-то не видно.

Так вот, model/view не ограничивает возможность настройки интерфейса под себя

Покажите, как можно в этой модели изменять состав меню, например, в том числе добавлять те пункты, которые являются комбинацией вызовов существующих. К примеру, есть пункты A и B, нужно добавить C = A(B), то есть вызов A с параметром B. Можно на любой существующей программе.

А что особого _пользователю_ нужно от tar? Запаковать да распаковать. Для сжатия пользователь zip выберет. Или rar.

> Покажите, как можно в этой модели изменять состав меню

Не мне, но отвечу. Модель model/view предполагает полное формальное разделение логики и интерфейса, настолько полное, что интерфейс может быть доработан или вообще заменен без особых трудностей. (кстати говоря, написание консольной утилитки и отдельно ГУЙки для нее - ИМХО, самая годная реализация этой идеи) Я понимаю что Вы имели в виду не совсем это. Это может сделать программист, но не пользователь мышкой. Однако идея-то именно вот в том, что я написал.

> Вы задачу-то поподробнее опишите.

anonymous:

В том числе, к тормозам разработки (ибо кучу всего изучить надо, чтобы писать хорошо)

я:

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

Под интерфейсом в данном комментарии я понимал API библиотеки, класс, а не GUI. Видимо отсюда и пошло непонимание. Именно поэтому я описываю проблему с точки зрения разработчика и задача про XML - всего лишь пример того, что проще использовать готовое, чем создавать свой XML-парсер и с его помощью решать проблему.

Интерфейса чего? Программ? У них чего-то революционного в программах для работы чего-то не видно.

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

Покажите, как можно в этой модели изменять состав меню...

Model/view работает с виджетами представления, а не всплывающими/главными меню.

Не у всех есть возможность живого общения с преподавателем. Да и не каждому везёт с вузом.

>Под интерфейсом в данном комментарии я понимал API библиотеки, класс, а не GUI. Видимо отсюда и пошло непонимание. Именно поэтому я описываю проблему с точки зрения разработчика и задача про XML - всего лишь пример того, что проще использовать готовое, чем создавать свой XML-парсер и с его помощью решать проблему.

Да, я говорю про удобство GUI для пользователя.

Именно! Тем не менее люди добровольно покупают их игрушки

Так это игрушки, не для работы. Людей, которым комп для работы нужен, сильно меньше.

Model/view работает с виджетами представления, а не всплывающими/главными меню.

Вот в этом-то и проблема. Этот паттерн работает с компоновкой, а не со связями. А в MVC C может быть интерпретируемым.

> А что особого _пользователю_ нужно от tar? Запаковать да распаковать.

истино так. И что это меняет? Факт есть. Нативные интерфейсы к нему есть везде, где только можно, и, если будет нужен еще, напишем (или напишут) еще. Единожды верно разработанная программа еще долго-придолго будет распаковывать/запаковывать на самых разных системах, тулкиты будут расти/делиться/умирать/появляться_новые, а тар, хорошо написанный стопицот лет назад, будет распаковывать/запаковывать как прежде. Ибо великолепно справляется, проверен временем, стабилен, как памятник Ленину, все что можно давно пофиксили и новый запаковщик/распаковщик никто в здравом уме писать не станет.

Это давно-давно придумали, еще отцы Unix'a призывали: «пишите программы с текстовым интерфейсом, ибо это - универсальный интерфейс». Идет время, правота их завета, ИМХО, все виднее и виднее.

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

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

что интерфейс может быть доработан или вообще заменен без особых трудностей.

Только внешний вид.

кстати говоря, написание консольной утилитки и отдельно ГУЙки для нее - ИМХО, самая годная реализация этой идеи

ИМХО, годный вид - это либка и интерфейсы на скриптовом языке. Нормальном, а не bash.

> Не у всех есть возможность живого общения с преподавателем. Да и не каждому везёт с вузом.

Я родом из деревни с населением в 300 чел. Мой отец, хоть и умный мужик, зарабатывает 3500 в месяц на двух работах. Жизнь такая в селе. Неужели ж у кого-то еще меньше стартовых возможностей? )) при желании - найдется возможность.

Мне тоже не шибко повезло с вузом, за те 2.5 года что я там провел, пока не сбежал, возможность поработать с этим вот мужиком - это единственное полезное (на самом деле) что этот вуз дал мне.

Мне тоже не шибко повезло пообщаться с отцами юникса, но мужики придумали возможность довести до парней из российской глубинки свой опыт - они написали книги. Понятное дело не живое общение, но зато в MIT поступать не нужно )

>истино так. И что это меняет?

То, что это простая программа и интерфейс ей особо не нужен. А вот приделайте GUI к smartctl. Или к hdparm. Или wget. Там как раз их не хватает. И для пользователя они много полезнее. Но если к ним чего и делают из gui, то простые формочки, сильно удобнее работу не делающие.

пишите программы с текстовым интерфейсом, ибо это - универсальный интерфейс

Вот только писали они интерфейс, который удобно парсить даже регекспами. Те же коды возврата были. Найдите коды возврата в интерфейсах в современных программах.

И да, в те времена задачи были проще.

> Покажите, как можно в этой модели изменять состав меню, например, в том числе добавлять те пункты, которые являются комбинацией вызовов существующих. К примеру, есть пункты A и B, нужно добавить C = A(B), то есть вызов A с параметром B. Можно на любой существующей программе.

Я не совсем понял что имеется в виду. Можно комбинировать пункт меню с некоторым заранее заданным значеним, например «редактировать(10)» - редактировать элемент с индексом 10 в некотором списке, но передача пункта меню аргументом другому пункту приводит к бессмыслице - «редактировать(удалить)». Тут нужен пример.
В Qt пункты меню / элементы панелей инструментов являются объектами класса QAction, которые никто не мешает в рантайме динамически собирать в нужные группы и даже комбинировать их вместе с некоторыми значениями, как я писал выше. Таким образом если задасться целью, можно легко создать полностью настраиваемое меню.

>Где 5.0? А где 4.8?

У меня собирается с 4.8rc1 (несколько дней как вышло), до него была бета - всё присутствует. :)

>Неужели ж у кого-то еще меньше стартовых возможностей? ))

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