.
Тем не менее, есть желание подытожить, что ли (уверен — я не одинок).
Итак, на чем лучше всего делать GUI для Windows-программы ?
Интересуют именно профессиональные инструменты и библиотеки, позволяющие, помимо
серых форм с двумя кнопками и чекбоксом, программировать по-настоящему качественные и
продвинутые UI, желательно поддерживающие какие-то модели или мастера, упрощающие и
автоматизирующие процесс. И вообще супер, если они выполнены с жесточайшим соблюдением
принципа "code behind" (полумеры все портят), то есть — дизайн отдельно, логика отдельно.
Язык, в принципе, не важен, но .NET и Java-рантаймы по определенным причинам отпадают.
Кроссплатформенность не интересует, софт исключительно для Windows.
Грубо говоря, процесс создания пользовательского интерфейса в моем понимании выглядит так:
Дизайнеры, специалисты по эргономике и юзабилити проектируют интерфейс и исполняют его в
виде набора макетов (PSD, JPEG, PNG, BMP или вообще HTML+CSS — как угодно).
Затем программист в некой IDE создает формы определенного размера, размещает на них
сами контролы и "одевает" это все в подготовленные дизайнерами "одежки".
Возможно, это даже лишнее — сделанные дизайнерами формы уже можно открывать, тыкать по
кнопкам, менять стили и так далее. Очень важно, чтобы на этом этапе "игры в Барби" все
визуальные аспекты поведения форм и контролов были запрограммированы — то есть,
программисту позже не придется вручную делать всякие затухания кнопок или анимацию меню.
Следующий этап — программирование того, что я называю GUI Finite State Machine.
Это всевозможные комбинации состояний контролов и их реакций на всякие события.
Например, кнопка "Применить" подсвечивается только если список не пуст, а полоса
прокрутки появляется когда таблица не вмещает все элементы. Ну и так далее.
Возможно, этот этап не менее важен, чем первый, и он в какой-то степени должен
быть удобен, чтобы, скажем, отключение кнопки достигалось одним-двумя вызовами
функций или свойств соответствующего контрола.
Третий этап очевиден. К готовой модели GUI просто подключается бизнес-логика,
сконцентрированная в других модулях (dll, например).
Кстати, здесь есть маленькая, но важная деталь. Хорошо, если библиотека/фреймворк
поддерживает сборку под x64. Зачем нужен x64 ? — спросите. А затем, что все
равно придется как-то связывать модули программы один с другим и, вероятно,
передавать какие-то данные, а тут и различия в размерах типов, и выравнивание, и
невозможность загрузки dll одной разрядности в exe другой, и прочее.
Теперь из этого прекрасного мира спустимся на землю и обозрим имеющиеся тулзы и либы.
И рассмотрим, почему именно они ну никак не могут претендовать на высшие почетные звания.
Начнем с диких и необузданных тварей, постепенно продвигаясь к более цивилизованным особям.
1. Win32 API.
Гордый и старый одинокий мустанг, полные сведения можно найти только в энциклопедиях MSDN.
Оседлать его могут только такие же брутальные создания, как и он сам.
На оседлание тратятся недели и месяцы непрерывных скачек, приветствуются частые
забеги на водопои вроде Codeproject. Последний раз его видели где-то в 2005-2006 году.
Ходят слухи, что отдельным мастерам Win32 API Kung-Fu удавалось слепить приличный GUI,
не слезая с седла.
2. MFC (My Fucking Code).
Породистая кобыла, внучатый племянник Win32 API (родство легко выявляется даже неспециалистами).
От своего норовистого предка отличается разве что многочисленными упряжками да позолотой.
Родилась в эпоху лихих девяностых, впитала весь бандитский дух того времени, который
сохранила до сих пор. За годы жизни была изрядно покоцана конкурентами, да и внешне может
показаться не совсем презентабельной, но, что удивительно, — еще многих в состоянии обскакать.
3. WTL (По одноименной песне "WhaT is Love").
Мелкий и задиристый жеребец. По слухам — сын Win32 API и MFC.
Долгое время не знал, куда девать свою силу, поэтому юность и зрелось прошли практически в забвении.
Несколько лет назад его заприметили заезжие циркачи, и с тех пор имя WTL можно увидеть в ряде вакансий.
Лепить жеребец умеет так же хорошо/плохо, как его родители.
По части шаблонов ушел далеко вперед, но, так как яблоко от яблони падает недалеко,
ни в чем выдающемся пока замечен не был.
4. ATL.
Сводный брат WTL, буква "A" исключительно для удобства различия.
Собственно, лепить формы (из песка) никогда не умел и не любил.
Юность провел в каталогизации GUID-ов на фабрике классов, затем был
импортирован в другой апартмент, но по ошибке маршаллинга вернулся без HRESULT-а.
Затем устроился в библиотеку импорта и в течение многих лет его труды были
оазисом для тех, кто испытывал проблемы "Dll Hell", совместимости компонентов и
удаленного взаимодействия. К GUI не имеет почти никакого отношения, хотя редкий
извращенец обойдет стороной идею сделать GUI с помощью ATL.
5. wxWidgets.
Хитрый верблюд, имя которого расшифровывается примерно как "выбери меня,
если хочешь чтобы тебя поимели". Исключительно доброе и открытое существо,
лишенное всяких "комплексов победителя". Проблема же в том, что перед
отправкой в дорогу оно сознательно обо многом умалчивает.
Вам придется испытывать жажду и питаться колючками, причем сам wx
делает это с удовольствием, демонстрируя превосходство над земными.
Узнать о нем больше, увы, не удается — даже в официальных документах
весьма скудные сведения и нам лишь остается довольствоваться редкими
рассказами очевидцев.
6. Delphi/Builder/RAD Studio и другие.
Семейство зверьков непонятной породы. Один из членов семейства многие годы прикрывался
добрым именем Бледа Паскаля, успев за это время несколько раз продаться и перепродаться.
"Из Бормана в кардеры" — так, вроде, гласит старинная пословица.
Значительное время группировка доминировала в бухгалтерии и банковской сфере, а
также была связана с бандами базами данных, но репутацию заработала так себе, в
первую очередь из-за своих кочевнических замашек. Несколько лет семъя прожила в
нищете и страшном забвении, но совсем недавно дело начало сдвигаться с мертвой точки.
Имеет богатую коллекцию компонентов, разбросанных по форумам всего света, и
армию поклонников, как правило молодых и не очень грамотных.
Подкупает своей видимой простотой.
7. HTMLayout.
Молодая и энергичная обезъянка, не упускающая случая похвастаться:
"Эх, а вот у нас там в вебе"... Бегает шустро, и никогда не разлучается со
своими друзьями — HTML и CSS. Красуется на обложках Alawar и Norton.
В связях, порочащих ее (Win32, MFC, ...) замечена не была.
Из огромных плюсов — умеет дружить как с программистами, так и с дизайнерами.
Впрочем, не лишена пары "детских болезней", хотя постоянно тренируется и
очень скоро собирается победить ближайших конкурентов. Все благодаря
стараниям отца (c-smile), который вразумляет ее и учит как надо.
8. Qt.
Слон. Амбициозен, грациозен, статен. Передвигается медленно.
Никакое кунг-фу против него не поможет. Если Qt что-то не понравится в вашей манере
разговаривать с ним, вы будете медленно раздавлены, не успев подать сигнал или даже слот.
Имеет богатый выбор всяких седушек, тесемок и бахромы (стырено у хозяев-индусов).
Ходят нелепые слухи, что некто Nokia собиралась задействовать слона Qt в своих
мобильных подразделениях, но то ли ввиду гарбаритов, то ли еще чего-то, отказалась.
В отличие от большинства представителей, описанных ранее, Qt умеет пересекать границы, и
делает это с большим успехом, собирая повсюду толпы восторженных поклонников.
Однако взобраться на слона довольно непросто, и еще непросто потом понять
свой успех и повторить/закрепить его. Туториалы общедоступны, однако главы "как взобраться
на Qt" в них нету.
Вот.
Описал "зоопарк", с почти всеми представителями которого приходилось либо
плотно работать, либо по крайней мере взаимодейтствовать.
Удовлетворения от использования данных инструментов не испытывал, почти все из
перечисленного не имеет нормальной IDE, либо плохо интегрируется в существующий код,
либо сильно "завязано" на каких-то специфических вещах, с которыми приходится
мириться, либо требует изрядного "допиливания" для решения нужных задач.
При описании старался чувств не задевать, все написанное — плод фантазии,
возможно, не совсем здоровой (зато трезвой и откровенной).
По теме: обрати внимание, как за эти годы все эти технологии появлялись и отмирали (сам многое попробовал, только время потратил), а "лоховские" HTML/CSS/JavaScript прекрасно себя чувствуют. Сколько еще GUI-библиотек будет создано и сколько из них подохнет (да все, собственно). А веб-троица всех переживет.
Ни к чему не призываю, просто пища для размышлений.
Я лично нынче выбираю HTMLayout (& Sciter). Штука эта отлично позволяет отодрать код от данных и сделать ну очень гламурный интерфейс. Причем быстро.
А насчет ide.. ну чем студия не угодила? Хорошо html & css & js редактирует. Самое то. Особенно если запустить на втором мониторе разрабатываемую прогу с обновлением содержимого раз в 300 мс.
А вообще так уже вопрос замусолили... делайте на чем модите сделать его хорошо. И все будет сдорово. И я кстати не совсем понимаю это увлечение нестандартными интерфейсами (хотя и сам не брузгую ).
Здравствуйте, okman, Вы писали:
O>Всем доброго дня.
O>Теперь из этого прекрасного мира спустимся на землю и обозрим имеющиеся тулзы и либы.
Судя по всему, вы хотели понтануться своим литературным стилем. Получилось. Забавно.
Рассматривать программирование под Винд, отсекая .NET и Джава в текущем веке выглядит также забавно. Можно написать текст в духе выше вашего. Тем более что всё остальное вы упомянули.
. O>Тем не менее, есть желание подытожить, что ли (уверен — я не одинок).
O>Итак, на чем лучше всего делать GUI для Windows-программы ? O>Интересуют именно профессиональные инструменты и библиотеки, позволяющие, помимо O>серых форм с двумя кнопками и чекбоксом, программировать по-настоящему качественные и O>продвинутые UI, желательно поддерживающие какие-то модели или мастера, упрощающие и O>автоматизирующие процесс. И вообще супер, если они выполнены с жесточайшим соблюдением O>принципа "code behind" (полумеры все портят), то есть — дизайн отдельно, логика отдельно.
O>Язык, в принципе, не важен, но .NET и Java-рантаймы по определенным причинам отпадают. O>Кроссплатформенность не интересует, софт исключительно для Windows.
O>Грубо говоря, процесс создания пользовательского интерфейса в моем понимании выглядит так: O>Дизайнеры, специалисты по эргономике и юзабилити проектируют интерфейс и исполняют его в O>виде набора макетов (PSD, JPEG, PNG, BMP или вообще HTML+CSS — как угодно). O>Затем программист в некой IDE создает формы определенного размера, размещает на них O>сами контролы и "одевает" это все в подготовленные дизайнерами "одежки". O>Возможно, это даже лишнее — сделанные дизайнерами формы уже можно открывать, тыкать по O>кнопкам, менять стили и так далее. Очень важно, чтобы на этом этапе "игры в Барби" все O>визуальные аспекты поведения форм и контролов были запрограммированы — то есть, O>программисту позже не придется вручную делать всякие затухания кнопок или анимацию меню.
O>Следующий этап — программирование того, что я называю GUI Finite State Machine. O>Это всевозможные комбинации состояний контролов и их реакций на всякие события. O>Например, кнопка "Применить" подсвечивается только если список не пуст, а полоса O>прокрутки появляется когда таблица не вмещает все элементы. Ну и так далее. O>Возможно, этот этап не менее важен, чем первый, и он в какой-то степени должен O>быть удобен, чтобы, скажем, отключение кнопки достигалось одним-двумя вызовами O>функций или свойств соответствующего контрола.
O>Третий этап очевиден. К готовой модели GUI просто подключается бизнес-логика, O>сконцентрированная в других модулях (dll, например). O>Кстати, здесь есть маленькая, но важная деталь. Хорошо, если библиотека/фреймворк O>поддерживает сборку под x64. Зачем нужен x64 ? — спросите. А затем, что все O>равно придется как-то связывать модули программы один с другим и, вероятно, O>передавать какие-то данные, а тут и различия в размерах типов, и выравнивание, и O>невозможность загрузки dll одной разрядности в exe другой, и прочее.
O>Теперь из этого прекрасного мира спустимся на землю и обозрим имеющиеся тулзы и либы. O>И рассмотрим, почему именно они ну никак не могут претендовать на высшие почетные звания. O>Начнем с диких и необузданных тварей, постепенно продвигаясь к более цивилизованным особям.
O>1. Win32 API.
O>Гордый и старый одинокий мустанг, полные сведения можно найти только в энциклопедиях MSDN. O>Оседлать его могут только такие же брутальные создания, как и он сам. O>На оседлание тратятся недели и месяцы непрерывных скачек, приветствуются частые O>забеги на водопои вроде Codeproject. Последний раз его видели где-то в 2005-2006 году. O>Ходят слухи, что отдельным мастерам Win32 API Kung-Fu удавалось слепить приличный GUI, O>не слезая с седла.
O>2. MFC (My Fucking Code).
O>Породистая кобыла, внучатый племянник Win32 API (родство легко выявляется даже неспециалистами). O>От своего норовистого предка отличается разве что многочисленными упряжками да позолотой. O>Родилась в эпоху лихих девяностых, впитала весь бандитский дух того времени, который O>сохранила до сих пор. За годы жизни была изрядно покоцана конкурентами, да и внешне может O>показаться не совсем презентабельной, но, что удивительно, — еще многих в состоянии обскакать.
O>3. WTL (По одноименной песне "WhaT is Love").
O>Мелкий и задиристый жеребец. По слухам — сын Win32 API и MFC. O>Долгое время не знал, куда девать свою силу, поэтому юность и зрелось прошли практически в забвении. O>Несколько лет назад его заприметили заезжие циркачи, и с тех пор имя WTL можно увидеть в ряде вакансий. O>Лепить жеребец умеет так же хорошо/плохо, как его родители. O>По части шаблонов ушел далеко вперед, но, так как яблоко от яблони падает недалеко, O>ни в чем выдающемся пока замечен не был.
O>4. ATL.
O>Сводный брат WTL, буква "A" исключительно для удобства различия. O>Собственно, лепить формы (из песка) никогда не умел и не любил. O>Юность провел в каталогизации GUID-ов на фабрике классов, затем был O>импортирован в другой апартмент, но по ошибке маршаллинга вернулся без HRESULT-а. O>Затем устроился в библиотеку импорта и в течение многих лет его труды были O>оазисом для тех, кто испытывал проблемы "Dll Hell", совместимости компонентов и O>удаленного взаимодействия. К GUI не имеет почти никакого отношения, хотя редкий O>извращенец обойдет стороной идею сделать GUI с помощью ATL.
O>5. wxWidgets.
O>Хитрый верблюд, имя которого расшифровывается примерно как "выбери меня, O>если хочешь чтобы тебя поимели". Исключительно доброе и открытое существо, O>лишенное всяких "комплексов победителя". Проблема же в том, что перед O>отправкой в дорогу оно сознательно обо многом умалчивает. O>Вам придется испытывать жажду и питаться колючками, причем сам wx O>делает это с удовольствием, демонстрируя превосходство над земными. O>Узнать о нем больше, увы, не удается — даже в официальных документах O>весьма скудные сведения и нам лишь остается довольствоваться редкими O>рассказами очевидцев.
O>6. Delphi/Builder/RAD Studio и другие.
O>Семейство зверьков непонятной породы. Один из членов семейства многие годы прикрывался O>добрым именем Бледа Паскаля, успев за это время несколько раз продаться и перепродаться. O>"Из Бормана в кардеры" — так, вроде, гласит старинная пословица. O>Значительное время группировка доминировала в бухгалтерии и банковской сфере, а O>также была связана с бандами базами данных, но репутацию заработала так себе, в O>первую очередь из-за своих кочевнических замашек. Несколько лет семъя прожила в O>нищете и страшном забвении, но совсем недавно дело начало сдвигаться с мертвой точки. O>Имеет богатую коллекцию компонентов, разбросанных по форумам всего света, и O>армию поклонников, как правило молодых и не очень грамотных. O>Подкупает своей видимой простотой.
O>7. HTMLayout.
O>Молодая и энергичная обезъянка, не упускающая случая похвастаться: O>"Эх, а вот у нас там в вебе"... Бегает шустро, и никогда не разлучается со O>своими друзьями — HTML и CSS. Красуется на обложках Alawar и Norton. O>В связях, порочащих ее (Win32, MFC, ...) замечена не была. O>Из огромных плюсов — умеет дружить как с программистами, так и с дизайнерами. O>Впрочем, не лишена пары "детских болезней", хотя постоянно тренируется и O>очень скоро собирается победить ближайших конкурентов. Все благодаря O>стараниям отца (c-smile), который вразумляет ее и учит как надо.
O>8. Qt.
O>Слон. Амбициозен, грациозен, статен. Передвигается медленно. O>Никакое кунг-фу против него не поможет. Если Qt что-то не понравится в вашей манере O>разговаривать с ним, вы будете медленно раздавлены, не успев подать сигнал или даже слот. O>Имеет богатый выбор всяких седушек, тесемок и бахромы (стырено у хозяев-индусов). O>Ходят нелепые слухи, что некто Nokia собиралась задействовать слона Qt в своих O>мобильных подразделениях, но то ли ввиду гарбаритов, то ли еще чего-то, отказалась. O>В отличие от большинства представителей, описанных ранее, Qt умеет пересекать границы, и O>делает это с большим успехом, собирая повсюду толпы восторженных поклонников. O>Однако взобраться на слона довольно непросто, и еще непросто потом понять O>свой успех и повторить/закрепить его. Туториалы общедоступны, однако главы "как взобраться O>на Qt" в них нету.
O>Вот. O>Описал "зоопарк", с почти всеми представителями которого приходилось либо O>плотно работать, либо по крайней мере взаимодейтствовать. O>Удовлетворения от использования данных инструментов не испытывал, почти все из O>перечисленного не имеет нормальной IDE, либо плохо интегрируется в существующий код, O>либо сильно "завязано" на каких-то специфических вещах, с которыми приходится O>мириться, либо требует изрядного "допиливания" для решения нужных задач.
O>При описании старался чувств не задевать, все написанное — плод фантазии, O>возможно, не совсем здоровой (зато трезвой и откровенной).
O>Прошу в тему.
Здравствуйте, 11molniev, Вы писали:
1>А вообще так уже вопрос замусолили... делайте на чем модите сделать его хорошо. И все будет сдорово. И я кстати не совсем понимаю это увлечение нестандартными интерфейсами (хотя и сам не брузгую ).
Я тоже не понимаю. Но заказчикам нужно, ради этого они готовы оплачивать любые IDE, и
лицензии на любое количество рабочих мест, лишь бы их софт выглядел как конфетка.
Здравствуйте, okman, Вы писали:
O>2. MFC (My Fucking Code).
O>Породистая кобыла, внучатый племянник Win32 API (родство легко выявляется даже неспециалистами). O>От своего норовистого предка отличается разве что многочисленными упряжками да позолотой. O>Родилась в эпоху лихих девяностых, впитала весь бандитский дух того времени, который O>сохранила до сих пор. За годы жизни была изрядно покоцана конкурентами, да и внешне может O>показаться не совсем презентабельной, но, что удивительно, — еще многих в состоянии обскакать.
Как много людей берется обскакать MFC, не понимая, в чем ее фишка. Да, как библиотека контролов MFC — тоненькая обертка над Win API и не поддерживает ничего сверх того. Языков разметки, утилизации трехмерного ускорителя и так далее. Как у инструмента создания SDI- и MDI-приложений, у этой библиотеки нет конкуретнов, а если есть — я хочу их знать! Просто очень много людей создает bells and whistles software, и очень мало — software для созидания. Последнее, разумеется, почти (?) полностью состоит из SDI- и MDI-приложений.
Разумеется, классы Doc/View не бог весть какая трудоемая задача, и их можно прикрутить хоть к Qt, хоть к HTMLayout, но это надо делать (и потому нет стандарта де-факто и де-юре). Между тем, к MFC существуют расширители. Наборы классов для создания визиоподобных приложений, например. Сейчас все это подыхает, как и созидательный софт вообще, а когда-то так цвело пышным цветом. Стингрей, Дундас и кто там еще. Не говоря про внутренние библиотеки-деривативы, которые были вполне interchangeable. Можно было с одного грамотно написанного проекта взять представление документа и встроить в любой другой грамотно написанный проект за пару дней. Грамотно написанных проектов только почти не было. Какой-нибудь неграмотный мудак с полным непониманием ООП и MVC обычно брал View и втыкал в нее все данные, операции, сериализацию и т.д.
Кроме того, поддержка DI со стороны IDE тоже значила многое.
Классы контролов, OLE и прочего функционала добавлялись, чтоб программистам "креативного" софта по два раза не вставать. Сейчас этот аспект MFC улучшен сторонними производителями: BCG, CodeJock и сотнями энтузиастов с CodeProject'а, но не настолько, чтобы конкурировать с Qt/HTMLayout и компанией. Последнее и устаревший язык библиотеки, конечно, губят ее и почти уже погубили.
Здравствуйте, SV., Вы писали:
SV.>Как много людей берется обскакать MFC, не понимая, в чем ее фишка. Да, как библиотека контролов MFC — тоненькая обертка над Win API и не поддерживает ничего сверх того. Языков разметки, утилизации трехмерного ускорителя и так далее. Как у инструмента создания SDI- и MDI-приложений, у этой библиотеки нет конкуретнов, а если есть — я хочу их знать! Просто очень много людей создает bells and whistles software, и очень мало — software для созидания. Последнее, разумеется, почти (?) полностью состоит из SDI- и MDI-приложений.
Я несколько лет использовал (и использую) MFC в проектах разного уровня и плана.
Обычно сперва очень быстро накидываются формы, затем делаются кое-какие коррекции и
вся эта система интегрируется с worker-кодом, после чего проект тестируется и выпускается в продакшн.
Как правило, довольно быстро и без срывов. Лично у меня к MFC нет и никогда не было больших претензий.
Но сейчас, к счастью или к сожалению — не знаю, времена изменились.
"Голый" функционал не всегда устраивает заказчиков ПО, а кроме того, идет сильная интеграция
десктопа и веб-приложений, баз данных, прочих сервисов — для UI выдвигаются новые требования,
за которыми старый инструментарий и библиотеки не поспевают.
Да Вы это, понятное дело, знаете и без меня.
Если мы решаем не совсем стандартную задачу (например, пишем сетевой экран), нам несомненно
понадобятся нестандартные компоненты. Например, визуализировать сетевую активность в виде
графиков, или сделать какой-нибудь alert в трее, который бы ясно показывал юзеру, что идет
сканирование портов, не отвлекая его при этом от работы. Проблема, во-первых, в том, что в
MFC нет таких компонентов (потому что их нет в Windows), а во-вторых в том, что в любом
случае их придется дизайнить вместе с кодом, потому что это неотъемлемая часть архитектуры MFC.
Меня, если честно, этот факт напрягает гораздо больше всего остального, потому что
приходится проектировать системы ну очень аккуратно, с разделением ответственностей,
и все равно доля этого ненормального дизайна всегда остается.
Ну да, можно начинать рыться на codeproject и всяких сайтах с либами для MFC,
беря на себя ответственность за их качество. Впрочем, второй проблемы это не отменяет.
SV.>Разумеется, классы Doc/View не бог весть какая трудоемая задача, и их можно прикрутить хоть к Qt, хоть к HTMLayout, но это надо делать (и потому нет стандарта де-факто и де-юре). Между тем, к MFC существуют расширители. Наборы классов для создания визиоподобных приложений, например. Сейчас все это подыхает, как и созидательный софт вообще, а когда-то так цвело пышным цветом. Стингрей, Дундас и кто там еще. Не говоря про внутренние библиотеки-деривативы, которые были вполне interchangeable. Можно было с одного грамотно написанного проекта взять представление документа и встроить в любой другой грамотно написанный проект за пару дней. Грамотно написанных проектов только почти не было. Какой-нибудь неграмотный мудак с полным непониманием ООП и MVC обычно брал View и втыкал в нее все данные, операции, сериализацию и т.д.
К сожалению, MFC и ее визарды никак не препятствуют такому подходу.
SV.>Кроме того, поддержка DI со стороны IDE тоже значила многое.
О каком DI вы говорите, не совсем понял ?
SV.>Классы контролов, OLE и прочего функционала добавлялись, чтоб программистам "креативного" софта по два раза не вставать. Сейчас этот аспект MFC улучшен сторонними производителями: BCG, CodeJock и сотнями энтузиастов с CodeProject'а, но не настолько, чтобы конкурировать с Qt/HTMLayout и компанией. Последнее и устаревший язык библиотеки, конечно, губят ее и почти уже погубили.
Ну, я бы так не сказал.
Скорее всего, MFC просто ушла из мэйнстрима во всякий там корпоративный софт, где во главе
стоит функционал, а не дизайн. Не думаю, что за ближайшие несколько лет положение сильно
поменяется, если только ее вместе с Delphi не вытеснят всякие там .NET-ы и Java.
Здравствуйте, okman, Вы писали: O>Грубо говоря, процесс создания пользовательского интерфейса в моем понимании выглядит так: O>Дизайнеры, специалисты по эргономике и юзабилити проектируют интерфейс и исполняют его в O>виде набора макетов (PSD, JPEG, PNG, BMP или вообще HTML+CSS — как угодно).
Неа. Вы ограничиваете дизайнеров только созданием внешнего вида, забывая про поведение — самую важную часть в дизайне UI. Задача дизайнера — не "сделать красиво" и не впихнуть максимум кнопочек в минимум площади. Его основная обязанность — спроектировать UI, которым было бы приятно пользоваться. Это в принципе невозможно при описываемом вами подходе.
Если мы хотим создать нормальный UI, нужно сосредоточиться на сценариях использования, на поведении ПО, а не на отдельных возможностях. UI — не объект абстрактного искусства, это средство для упрощения и автоматизации повседневной работы пользователя. Отсюда — необходимость разработки микроитерациями и отказ от жёсткого разделения "подготовка макетов — кодинг по макетам".
Следущее — UI не должен пугать пользователя фичастостью аки эксгибиционист ночью в тёмном парке *(сорри, но вы первый ударились в литературу.) Наоборот, мы заинтересованы в уменьшении количества элементов управления — так мы сможем группировать их, наглядно отражая типовые действия и порядок их выполнения.
Третье — не менее важное (и, для меня, самое сложное). С одной стороны, UI должен оставаться привычным — нестандартные цветовые схемы, ползающие кнопки и панели "ой, а куда это она?" раздражают не меньше тулбара в стиле "игровое поле сапёра". С другой — интерфейс желательно подстраивать под текущий контекст, выдвигая на самое видное место полезные фичи и скрывая ненужные. Удержать баланс, рисуя эскизы невозможно, поведение в принципе не проектируется в статике — приходится стоять за плечом и высматривать "WTF moments". И (для меня это до сих пор остаётся чернейшей магией) минимальными изменениями в интерфейсе перемещать раздражающие контролы туда, где им и положено быть.
Все остальные моменты — не прятать необратимые действия, не перехватывать управление и не вести за собой пользователя, не навязывать свои концепции, не страдать NIH, не падать без восстановления — общеизвестны и уживаются с любым подходом к проектированию UI. Три выше — никак, их либо использовать вместе, либо отказываться.
Чтобы не описывать неописуемое — пример из этой темы
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, okman, Вы писали:
O>>Грубо говоря, процесс создания пользовательского интерфейса в моем понимании выглядит так: O>>Дизайнеры, специалисты по эргономике и юзабилити проектируют интерфейс и исполняют его в O>>виде набора макетов (PSD, JPEG, PNG, BMP или вообще HTML+CSS — как угодно).
S>Неа. Вы ограничиваете дизайнеров только созданием внешнего вида, забывая про поведение — самую важную часть в дизайне UI. Задача дизайнера — не "сделать красиво" и не впихнуть максимум кнопочек в минимум площади. Его основная обязанность — спроектировать UI, которым было бы приятно пользоваться. Это в принципе невозможно при описываемом вами подходе.
Понимаю. Но есть ли инструменты, обеспечивающий настолько высокий уровень абстрагирования UI от бизнес-логики ?
S>Если мы хотим создать нормальный UI, нужно сосредоточиться на сценариях использования, на поведении ПО, а не на отдельных возможностях. UI — не объект абстрактного искусства, это средство для упрощения и автоматизации повседневной работы пользователя. Отсюда — необходимость разработки микроитерациями и отказ от жёсткого разделения "подготовка макетов — кодинг по макетам".
Пожалуй, верно.
Но в этом случае мы не должны сталкиваться с обозначенными выше проблемами при каждой итерации.
Иначе разработка софта превратится в кошмар: "тут поправили, там обвалилось", и т.п.
Я когда писал самое первое сообщение в этой теме, по-настоящему вдруг понял, насколько сильно мне мешает именно эта
архитектурная составляющая тех GUI-библиотек, с которыми приходится работать.
S>Следущее — UI не должен пугать пользователя фичастостью аки эксгибиционист ночью в тёмном парке *(сорри, но вы первый ударились в литературу.) Наоборот, мы заинтересованы в уменьшении количества элементов управления — так мы сможем группировать их, наглядно отражая типовые действия и порядок их выполнения.
S>Третье — не менее важное (и, для меня, самое сложное). С одной стороны, UI должен оставаться привычным — нестандартные цветовые схемы, ползающие кнопки и панели "ой, а куда это она?" раздражают не меньше тулбара в стиле "игровое поле сапёра". С другой — интерфейс желательно подстраивать под текущий контекст, выдвигая на самое видное место полезные фичи и скрывая ненужные. Удержать баланс, рисуя эскизы невозможно, поведение в принципе не проектируется в статике — приходится стоять за плечом и высматривать "WTF moments". И (для меня это до сих пор остаётся чернейшей магией) минимальными изменениями в интерфейсе перемещать раздражающие контролы туда, где им и положено быть.
Вот тут можно поспорить: "что значит — должен или не должен UI пугать пользователя" ?
В той конторе, которая меня нанимает, вопросами GUI занимаются даже не столько дизайнеры, сколько маркетологи.
То есть, грубо говоря, специально привлеченные люди из с неким чувством и знанием рынка решают,
какие "плюшки" стоит прикручивать, а какие нет, что будет позитивно действовать на потенциальных
покупателей, а что отталкивать. Вплоть до цвета логотипов, цвета бэкграунда, шрифтов и других деталей.
И это не первый продукт, который они выводят на рынок, так что я склонен им доверять в этом отношении.
А "винить" можно, кстати, и юзеров, которые больше западают на цветастые поделки, чем на
скромные, но многофункциональные серости.
--------------
21 век на дворе, десктопный софт под винду принятно превращать в разноцветные какашки — Вы разве не в курсе ?
--------------
S>Все остальные моменты — не прятать необратимые действия, не перехватывать управление и не вести за собой пользователя, не навязывать свои концепции, не страдать NIH, не падать без восстановления — общеизвестны и уживаются с любым подходом к проектированию UI. Три выше — никак, их либо использовать вместе, либо отказываться.
S>Чтобы не описывать неописуемое — пример...
MP3Tag хорошо оформлена, спору нет.
Это пример наверняка тщательно спроектированного и вылизанного дизайна, где нету
ничего лишнего, все главное на виду и под рукой. Но вот там использован Rebar Control,
List Control, property-панель, тулбар со значками...
Я представляю, сколько это нужно кодить, чтобы такое реализовать на должном уровне.
О чем, собственно, и шла речь.
Здравствуйте, okman, Вы писали:
SV.>>Как много людей берется обскакать MFC, не понимая, в чем ее фишка. Да, как библиотека контролов MFC — тоненькая обертка над Win API и не поддерживает ничего сверх того. Языков разметки, утилизации трехмерного ускорителя и так далее. Как у инструмента создания SDI- и MDI-приложений, у этой библиотеки нет конкуретнов, а если есть — я хочу их знать! Просто очень много людей создает bells and whistles software, и очень мало — software для созидания. Последнее, разумеется, почти (?) полностью состоит из SDI- и MDI-приложений.
O>Я несколько лет использовал (и использую) MFC в проектах разного уровня и плана. O>Обычно сперва очень быстро накидываются формы, затем делаются кое-какие коррекции и O>вся эта система интегрируется с worker-кодом, после чего проект тестируется и выпускается в продакшн. O>Как правило, довольно быстро и без срывов. Лично у меня к MFC нет и никогда не было больших претензий.
Я не знаю насчет проектов разного уровня и плана, но для тех проектов, про которые говорил я, такой формо-центрический подход абсолютно неверен. Начинать надо с типа документа, думать над его представлениями и пр. Возьмите "созидательный" софт от Notepad'а и Paint'а до Word'а и Photoshop'а. Много там форм? Есть кое-где, но как гарнир к DI.
Что касается форм, то хоть MFC и предлагала Dialog-based скелет, она никогда не была для этого достаточно хороша. Всегда было лучше взять Delphi или VB, а если уж требовался глубокий контроль над таким приложением, то и голый WinAPI.
O>Но сейчас, к счастью или к сожалению — не знаю, времена изменились. O>"Голый" функционал не всегда устраивает заказчиков ПО, а кроме того, идет сильная интеграция O>десктопа и веб-приложений, баз данных, прочих сервисов — для UI выдвигаются новые требования, O>за которыми старый инструментарий и библиотеки не поспевают. O>Да Вы это, понятное дело, знаете и без меня.
Времена изменились, да. Раньше созидательный софт был в центре внимания, сейчас в центре внимания приложение, которое издает неприличные звуки под огрызок. Соответственно, и фокус внимания программистов сместился на инструменты, которые позволяют быстро создавать такое.
O>Если мы решаем не совсем стандартную задачу (например, пишем сетевой экран), нам несомненно O>понадобятся нестандартные компоненты. Например, визуализировать сетевую активность в виде O>графиков, или сделать какой-нибудь alert в трее, который бы ясно показывал юзеру, что идет O>сканирование портов, не отвлекая его при этом от работы. Проблема, во-первых, в том, что в O>MFC нет таких компонентов (потому что их нет в Windows), а во-вторых в том, что в любом O>случае их придется дизайнить вместе с кодом, потому что это неотъемлемая часть архитектуры MFC. O>Меня, если честно, этот факт напрягает гораздо больше всего остального, потому что O>приходится проектировать системы ну очень аккуратно, с разделением ответственностей, O>и все равно доля этого ненормального дизайна всегда остается. O>Ну да, можно начинать рыться на codeproject и всяких сайтах с либами для MFC, O>беря на себя ответственность за их качество. Впрочем, второй проблемы это не отменяет.
Я очень сильно извиняюсь, но это и есть bells and whistles. Свистелки-перделки. Например, сетевая активность в виде графика. Обоснование для таких графиков может быть одно — реальное время слежения. Но для реального времени нужен простейший график, который программируется за час. Все графические навороты вокруг рисования графика (зуминги, риски на осях, сопоставления нескольких графиков, наложение фонов) в реальном времени не нужны — вы просто не успеете с ними управляться. Соответственно, все, что нужно для работы с графиками со стороны сетевого экрана для НАСТОЯЩЕЙ аналитики — сохранение логов в CSV/XML, откуда можно их загрузить в любой аналитический софт. Соответственно, вы пишете или сетевой экран с экспортом, простейшей менюшкой с командами типа "Открыть папку с логами" и простейшим графиком реального времени, или аналитический софт с загрузкой/сохранением, но тогда вам НЕ НУЖНЫ контролы (aka компоненты), а нужно, в первую очередь, поддержать документ с данными и его многочисленные представления: табличное, графическое и пр.
Такой подход с нынешним юзером не работает. Он, ленивая скотина, хочет чувствовать себя защищенным, но ни хрена не хочет анализировать и вообще работать с данными, хочет чувствовать ситуацию под контролем, но не пытаясь разобраться в "контролируемом" предмете. Для таких и нужны навороченные графики реального времени и вообще GUI к задачам, которые традиционно были демонами.
Мой поинт в том, что вы рассматриваете исключительно свистелки и сравниваете библиотеки для их создания, включая в список MFC, которая, вообще-то, предназначалась не для этого, а для создания полезного софта, которому действительно нужен GUI. В дивном новом мире айфонов она, бедолага, конечно, оказывается неконкурентоспособной.
Еще раз: возьмите десктопное приложение под большую винду (это ваше изначальное ограничение), ценность GUI для которого неоспорима. То есть, не сетевой экран со свистом. Что это будет? В доброй половине случаев — приложение с документом в центре. То есть, приложение, для которого контролы/компоненты оказываются на сугубо вспомогательных ролях, как и библиотеки, построенные вокруг компонентно-контрольных форм.
SV.>>Разумеется, классы Doc/View не бог весть какая трудоемая задача, и их можно прикрутить хоть к Qt, хоть к HTMLayout, но это надо делать (и потому нет стандарта де-факто и де-юре). Между тем, к MFC существуют расширители. Наборы классов для создания визиоподобных приложений, например. Сейчас все это подыхает, как и созидательный софт вообще, а когда-то так цвело пышным цветом. Стингрей, Дундас и кто там еще. Не говоря про внутренние библиотеки-деривативы, которые были вполне interchangeable. Можно было с одного грамотно написанного проекта взять представление документа и встроить в любой другой грамотно написанный проект за пару дней. Грамотно написанных проектов только почти не было. Какой-нибудь неграмотный мудак с полным непониманием ООП и MVC обычно брал View и втыкал в нее все данные, операции, сериализацию и т.д.
O>К сожалению, MFC и ее визарды никак не препятствуют такому подходу.
Не могу не согласиться. В точности это же я думал, когда писал.
SV.>>Кроме того, поддержка DI со стороны IDE тоже значила многое.
O>О каком DI вы говорите, не совсем понял ?
Для (S,M)DI примером такой поддержки будет, например, обработка команд из документа или представления на выбор. Я заранее соглашусь, что в продвинутой реализации MVC применительно к документам это, скорее, не надо, чем надо, но в примитивной эмэфсевой реализации DocView самое то. В других же библиотеках нет и такого, что я и имел в виду, написав "поддержка DI со стороны IDE тоже значила многое".
Здравствуйте, okman, Вы писали: O>Понимаю. Но есть ли инструменты, обеспечивающий настолько высокий уровень абстрагирования UI от бизнес-логики ?
Для managed — wpf, для unmanaged — это к специалистам. При минимуме желания можно отделять мух от котлет и в WinForms и в Asp.Net (с unmanaged боевого опыта нет, но препятствий сделать вот так
я не вижу). O>Пожалуй, верно. O>Но в этом случае мы не должны сталкиваться с обозначенными выше проблемами при каждой итерации.
Да, но это вопрос в первую очередь культуры разработки. При разделении UI на отдельные области и прятании костылей в самописных контролах проблемы возникают очень редко. По крайней мере у нас O>Я когда писал самое первое сообщение в этой теме, по-настоящему вдруг понял, насколько сильно мне мешает именно эта архитектурная составляющая тех GUI-библиотек, с которыми приходится работать.
Есть такое, частично решается детальным изучением матчасти. Зачем бороться, когда можно использовать? O>Вот тут можно поспорить: "что значит — должен или не должен UI пугать пользователя" ?
А вот это — как раз та область, которой должны заниматься спецы по юзабилити. Что получается, когда UI отдают на откуп программистам и прочим гениям дизайна видно на скриншотах выше
O>То есть, грубо говоря, специально привлеченные люди из с неким чувством и знанием рынка решают, какие "плюшки" стоит прикручивать, а какие нет, что будет позитивно действовать на потенциальных покупателей, а что отталкивать.
Мракетологов надо безжалостно осаживать на этапах формализации требований. Если человек по факту ещё и программист/художник — велкам, но учениям о великих 16 квадратах, зонах внимания и цветовому SEO и прочей ереси в дизайне не место.
Задача дизайна — не привлечь пользователя вау-фактором, для этого куда действеннее рекламные материалы и вирусные ролики. Наоборот, хороший UI выполняет ровно одну функцию: он не раздражает. O>А "винить" можно, кстати, и юзеров, которые больше западают на цветастые поделки, чем на O>скромные, но многофункциональные серости.
Даже цветастость надо делать со вкусом.
Сравните QIP и Mail.Ru Агент
Комментарии нужны?
O>21 век на дворе, десктопный софт под винду принятно превращать в разноцветные какашки — Вы разве не в курсе ?
В курсе. Единственный шикарный продукт с нестандартным интерфейсом, который я сходу назову — это winamp. И то, не как плеер, а как медиабиблиотека. Всё остальное — O>MP3Tag хорошо оформлена, спору нет. O>Это пример наверняка тщательно спроектированного и вылизанного дизайна, где нету O>ничего лишнего, все главное на виду и под рукой. ... O>Я представляю, сколько это нужно кодить, чтобы такое реализовать на должном уровне.
Да-да-да, спасибо, что подчеркнули Хороший UI — это офигенно много работы и обязательно участие талантливого спеца по юзабилити (пусть он даже сам себя спецом не считает). Иначе никак
Здравствуйте, SV., Вы писали:
SV.>Времена изменились, да. Раньше созидательный софт был в центре внимания, сейчас в центре внимания приложение, которое издает неприличные звуки под огрызок. Соответственно, и фокус внимания программистов сместился на инструменты, которые позволяют быстро создавать такое.
Это так.
SV.>Я очень сильно извиняюсь, но это и есть bells and whistles. Свистелки-перделки. Например, сетевая активность в виде графика. Обоснование для таких графиков может быть одно — реальное время слежения. Но для реального времени нужен простейший график, который программируется за час. Все графические навороты вокруг рисования графика (зуминги, риски на осях, сопоставления нескольких графиков, наложение фонов) в реальном времени не нужны — вы просто не успеете с ними управляться. Соответственно, все, что нужно для работы с графиками со стороны сетевого экрана для НАСТОЯЩЕЙ аналитики — сохранение логов в CSV/XML, откуда можно их загрузить в любой аналитический софт. Соответственно, вы пишете или сетевой экран с экспортом, простейшей менюшкой с командами типа "Открыть папку с логами" и простейшим графиком реального времени, или аналитический софт с загрузкой/сохранением, но тогда вам НЕ НУЖНЫ контролы (aka компоненты), а нужно, в первую очередь, поддержать документ с данными и его многочисленные представления: табличное, графическое и пр.
SV.>Такой подход с нынешним юзером не работает. Он, ленивая скотина, хочет чувствовать себя защищенным, но ни хрена не хочет анализировать и вообще работать с данными, хочет чувствовать ситуацию под контролем, но не пытаясь разобраться в "контролируемом" предмете. Для таких и нужны навороченные графики реального времени и вообще GUI к задачам, которые традиционно были демонами.
Не будем так уж сильно сгущать краски — есть и нормальные юзеры, и качественный дизайн, не выходящий за рамки.
Кстати, когда разговор заходит о хорошем GUI, я почему-то всегда вспоминаю вот этот:
Не могу доподлинно знать, как и какими усилиями делается такой GUI, но хочу уметь
делать нечто подобное. Обратите внимание — большинство элементов нестандартные, но они
естественно вписываются в "панель управления" и чувствуют себя вполне комфортно.
Понятно, что на вкус и цвет товарищей нет, но вот данный конкретный образец я ну никак не
могу назвать свистелкой или перделкой.
SV.>Мой поинт в том, что вы рассматриваете исключительно свистелки и сравниваете библиотеки для их создания, включая в список MFC, которая, вообще-то, предназначалась не для этого, а для создания полезного софта, которому действительно нужен GUI. В дивном новом мире айфонов она, бедолага, конечно, оказывается неконкурентоспособной.
Таков рынок. Либо мы играем по его правилам, либо уступаем дорогу более "пробивным".
Либо сами придумываем правила и заставляем других играть по ним, но это уже к теме не относится.
Повторю — я сам не любитель свистелок, но таковы реалии. Если я занимаюсь системным программингом,
но при этом не умею воплотить определенные пожелания заказчиков по интерфейсу, это значит,
что я становлюсь для заказчика в каком-то отношении нерентабельным и он просто найдет замену.
SV.>Еще раз: возьмите десктопное приложение под большую винду (это ваше изначальное ограничение), ценность GUI для которого неоспорима. То есть, не сетевой экран со свистом. Что это будет? В доброй половине случаев — приложение с документом в центре. То есть, приложение, для которого контролы/компоненты оказываются на сугубо вспомогательных ролях, как и библиотеки, построенные вокруг компонентно-контрольных форм.
Если копнуть глубже, то вопрос даже не в количестве, разнообразии и разноцветности "свистулек",
которые предлагают или не предлагают современные или не очень средства разработки и библиотеки.
Просто нужных компонентов иногда просто нет, их приходится делать ручками, да еще увязывать это с
не всегда архитектурно чистой моделью того фреймворка, в котором делается GUI.
Это временные и прочие затраты, особенно когда понимаешь, что ты не дизайнер и
делаешь не свою работу.
Пример из практики, было пару лет назад. Заказ — софт для системы видеонаблюдения.
Ядро писалось на плюсах, модель интерфейса — MDI с документом на каждую камеру.
Требовалось еще несколько простых, но специфичных для задачи контролов — timeline,
которая должна была уметь переключаться в режим раскадровки, тулбар на каждую
камеру (их, вроде, было 16), плюс все это должно было поддерживать drag-n-drop.
Если откровенно, мы просто заколебались делать все это на MFC, потом нашелся один
дотнетчик с неплохими дизайнерскими скиллами и за неделю с какой-то либой переделал
весь дизайн до неузнаваемого уровня, причем все работало в соответствии с задумкой.
Причем дизайн во главе не ставился — нужна была именно юзабельность системы и ее
интуитивная понятность для пользователя (т.к. за терминалами будут сидеть далеко не
программисты, а обычные юзеры, и им должно быть понятно где и что расположено).
Здравствуйте, okman, Вы писали:
O>Не будем так уж сильно сгущать краски — есть и нормальные юзеры, и качественный дизайн, не выходящий за рамки. O>Кстати, когда разговор заходит о хорошем GUI, я почему-то всегда вспоминаю вот этот: O>[--img]http://files.rsdn.ru/90691/kis.PNG[/img]
Не бывает хороших или плохих GUI и вообще ничего абстрактно хорошего или плохого, пока вы не верите в Бога и Дьявола. Хорошим или плохим GUI может быть применительно к какой-то цели и с чьей-то точки зрения. С вашей точки зрения это хороший интерфейс? Тогда для каких задач он хорош? С моей точки зрения, это хороший интерфейс для свистельного софта. Стандартный прогресс-бар заменили каким-то ушлёпищем с вебдванольным бликом, но при этом 27 угроз у них складываются из 0+0+0+0+10. Типичный такой софт для изиота. Тефаль, ты думаешь о нас.
Мне лень писать по два раза, можно, я просто дам ссылку на себя?
1 2 3
O>Не могу доподлинно знать, как и какими усилиями делается такой GUI, но хочу уметь O>делать нечто подобное. Обратите внимание — большинство элементов нестандартные, но они O>естественно вписываются в "панель управления" и чувствуют себя вполне комфортно.
Мое скромное мнение: если хотеть уметь делать подобное, то надо понимать, что это за тип софта. У меня есть свое понимание, изложенное по ссылкам. Возможно, оно неправильное местами или целиком. Но это понимание позволяет мне отделять касперыча и сетевой экран с навороченным графиком реального времени от Экселя, а их обоих — от SAP'а. На уровне библиотек это будет, соответственно, HTMLayout (тоже антивирусник, обратили внимание? NAV, насколько я знаю) с Qt, WPF'ом и остальными, MFC и огромная самопальная библиотека.
O>Понятно, что на вкус и цвет товарищей нет, но вот данный конкретный образец я ну никак не O>могу назвать свистелкой или перделкой.
А что же это? Смотрите сами. Большая красная полоска извещает, что базы сильно устарели, но нигде ни полслова нет про дату последнего обновления. Сильно — это сколько? В граммах? Разумеется, это громкий свист, чтобы новые базы через год покупали. "Система и программы" под защитой — это что такое вообще? Да ну нафиг, это даже не смешно. Назначение этого интерфейса — чтобы тетя Мотя увидела, что все под защитой и, когда прилично будет снова просить, заплатила денег, чтобы оно и дальше было под защитой. При этом неважно, что там происходит под капотом. Ловит или не ловит, или вообще заражает. Художественный свист на первом месте.
Не надо только думать, что свистки и пердки — что-то абстрактно плохое. В данном конкретном случае с моей точки зрения тут все очень хорошо придумано. Просто не надо иметь свой собственный вкус. Я имею в виду, лично быть вовлеченным. Для тех, кому вообще нужны антивирусы, это отличный интерфейс. С другим интерфейсом антивирусам сейчас не выжить. Касперские тоже, наверное, счастливы.
SV.>>Мой поинт в том, что вы рассматриваете исключительно свистелки и сравниваете библиотеки для их создания, включая в список MFC, которая, вообще-то, предназначалась не для этого, а для создания полезного софта, которому действительно нужен GUI. В дивном новом мире айфонов она, бедолага, конечно, оказывается неконкурентоспособной.
O>Таков рынок. Либо мы играем по его правилам, либо уступаем дорогу более "пробивным". O>Либо сами придумываем правила и заставляем других играть по ним, но это уже к теме не относится. O>Повторю — я сам не любитель свистелок, но таковы реалии. Если я занимаюсь системным программингом, O>но при этом не умею воплотить определенные пожелания заказчиков по интерфейсу, это значит, O>что я становлюсь для заказчика в каком-то отношении нерентабельным и он просто найдет замену.
Дивный новый мир айфонов (включая сюда антивирусы и Windows 8) — это один из многих рынков, не эквивалентный рынку софта в целом. К тому же, у него есть своя динамика. Двадцать лет назад он был куда меньше (относительно остального софта), еще через 20 он может сгинуть бесследно, вместе с бигмачными и сигаретами. Я и говорю, вы за его пределами не видите других рынков, потому и валите в одну кучу MFC и HTMLayout. Не мое дело, но если вы хотите преуспеть на этом рынке хомячьего свиста, надо стараться видеть всю картину в целом.
SV.>>Еще раз: возьмите десктопное приложение под большую винду (это ваше изначальное ограничение), ценность GUI для которого неоспорима. То есть, не сетевой экран со свистом. Что это будет? В доброй половине случаев — приложение с документом в центре. То есть, приложение, для которого контролы/компоненты оказываются на сугубо вспомогательных ролях, как и библиотеки, построенные вокруг компонентно-контрольных форм.
O>Если копнуть глубже, то вопрос даже не в количестве, разнообразии и разноцветности "свистулек", O>которые предлагают или не предлагают современные или не очень средства разработки и библиотеки. O>Просто нужных компонентов иногда просто нет, их приходится делать ручками, да еще увязывать это с O>не всегда архитектурно чистой моделью того фреймворка, в котором делается GUI. O>Это временные и прочие затраты, особенно когда понимаешь, что ты не дизайнер и O>делаешь не свою работу.
Я сразу написал, что не согласен и еще раз повторюсь: не согласен. Компоненты, они же контролы, не нужны для разработки приложений с DI. Откуда они возьмутся в DI-приложении? MFC предназначалась для DI-разработки, неудивительно, что там швах по части компонентов.
O>Пример из практики, было пару лет назад. Заказ — софт для системы видеонаблюдения. O>Ядро писалось на плюсах, модель интерфейса — MDI с документом на каждую камеру. O>Требовалось еще несколько простых, но специфичных для задачи контролов — timeline, O>которая должна была уметь переключаться в режим раскадровки, тулбар на каждую O>камеру (их, вроде, было 16), плюс все это должно было поддерживать drag-n-drop. O>Если откровенно, мы просто заколебались делать все это на MFC, потом нашелся один O>дотнетчик с неплохими дизайнерскими скиллами и за неделю с какой-то либой переделал O>весь дизайн до неузнаваемого уровня, причем все работало в соответствии с задумкой.
А пример чего это? Вы выбрали неверную модель приложения "документ на каждую камеру" и, разумеется, заколебались. Камера разве документ или хотя бы похожа на документ?
O>Причем дизайн во главе не ставился — нужна была именно юзабельность системы и ее O>интуитивная понятность для пользователя (т.к. за терминалами будут сидеть далеко не O>программисты, а обычные юзеры, и им должно быть понятно где и что расположено).
Здравствуйте, SV., Вы писали:
SV.>Не бывает хороших или плохих GUI и вообще ничего абстрактно хорошего или плохого, пока вы не верите в Бога и Дьявола. Хорошим или плохим GUI может быть применительно к какой-то цели и с чьей-то точки зрения. С вашей точки зрения это хороший интерфейс? Тогда для каких задач он хорош? С моей точки зрения, это хороший интерфейс для свистельного софта. Стандартный прогресс-бар заменили каким-то ушлёпищем с вебдванольным бликом, но при этом 27 угроз у них складываются из 0+0+0+0+10. Типичный такой софт для изиота. Тефаль, ты думаешь о нас.
SV.>Мне лень писать по два раза, можно, я просто дам ссылку на себя?
SV.>1 SV.>2 SV.>3
Прочел от и до. В целом — понравилось, написано почти остросюжетно.
Но про Бога и Дъявола Вы тут слишком перегнули палку, по-моему.
Собственно, я расписал простыни про то, что под Windows весьма непросто найти
инструменты для программирования интерфейсов, таких чтобы они были четко выделены в
отдельный слой инфраструктуры и полностью, или насколько это вообще возможно,
абстрагировали разработчика от аспектов дизайна.
Под что конкретно заточены эти инструменты и как они исполнены — это даже второстепенно.
Мне эта ситуация напоминает то, что было в компьютерной сфере лет 25 назад.
Компьютеры представляли собой логически монолитные аппаратные устройства.
Чтобы, скажем, добавить память или подключить другой по техпоказателям монитор, нужно было
снимать крышку и перепаивать что-то на плате.
Аналогичное происходит, к примеру, в C++ при подключении новой библиотеки.
Увы, чаще всего это не интеграция, а имплантация. То есть, принудительное вживление
инородного тела, снабжаемое всякими спецлекарствами и средствами, обеспечивающими неотторжение.
Что ни проект — то std::string вперемешку с BSTR/XChar, там же разные аллокаторы и
компонентные модели, наборы wrapper-ов разного уровня абстракции и разные подходы к
контролю жизненного цикла объектов. Зоопарк, проще говоря.
С программированием GUI примерно то же самое. Компонентов много, а компонентности нет.
SV.>Дивный новый мир айфонов (включая сюда антивирусы и Windows 8) — это один из многих рынков, не эквивалентный рынку софта в целом. К тому же, у него есть своя динамика. Двадцать лет назад он был куда меньше (относительно остального софта), еще через 20 он может сгинуть бесследно, вместе с бигмачными и сигаретами. Я и говорю, вы за его пределами не видите других рынков, потому и валите в одну кучу MFC и HTMLayout. Не мое дело, но если вы хотите преуспеть на этом рынке хомячьего свиста, надо стараться видеть всю картину в целом.
Наверное, я многого не вижу, но все же не настолько, чтобы не замечать различия между такими вещами.
А вообще, обсуждаемый вопрос не ставился так тонко, как Вы его трактуете.
Это всего лишь очередная попытка найти хороший инструментарий под свои задачи, не более.
O>>Пример из практики, было пару лет назад. Заказ — софт для системы видеонаблюдения. O>>Ядро писалось на плюсах, модель интерфейса — MDI с документом на каждую камеру. O>>Требовалось еще несколько простых, но специфичных для задачи контролов — timeline, O>>которая должна была уметь переключаться в режим раскадровки, тулбар на каждую O>>камеру (их, вроде, было 16), плюс все это должно было поддерживать drag-n-drop. O>>Если откровенно, мы просто заколебались делать все это на MFC, потом нашелся один O>>дотнетчик с неплохими дизайнерскими скиллами и за неделю с какой-то либой переделал O>>весь дизайн до неузнаваемого уровня, причем все работало в соответствии с задумкой.
SV.>А пример чего это? Вы выбрали неверную модель приложения "документ на каждую камеру" и, разумеется, заколебались. Камера разве документ или хотя бы похожа на документ?
Погодите.
MDI-приложение на базе MFC, на каждую камеру свой объект Document со своими параметрами.
Что тут может быть противоречивого ? Камеры объединяются в блок 4x4, каждую из них можно
настраивать и просматривать отдельно, разворачивая на весь экран.
Снизу — раскадровка плюс специфичные для той системы элементы навигации и поиска.
Если эта модель была ошибочной, какую тогда следовало бы выбрать ?
Здравствуйте, okman, Вы писали:
SV.>>А пример чего это? Вы выбрали неверную модель приложения "документ на каждую камеру" и, разумеется, заколебались. Камера разве документ или хотя бы похожа на документ?
O>Погодите. O>MDI-приложение на базе MFC, на каждую камеру свой объект Document со своими параметрами. O>Что тут может быть противоречивого ? Камеры объединяются в блок 4x4, каждую из них можно O>настраивать и просматривать отдельно, разворачивая на весь экран. O>Снизу — раскадровка плюс специфичные для той системы элементы навигации и поиска. O>Если эта модель была ошибочной, какую тогда следовало бы выбрать ?
Не MDI. Извините за лапидарность. То, что у вас есть дочерние окна и они разворачиваются-сворачиваются и их можно выстроить кандибобриком — все это вторично-половые признаки.
Что касается первично-половых, то у документа есть усредненный жизненный цикл (ЖЦ):
1. Создание. С нуля или путем откачки данных из БД или иного источника.
|->2. Редактирование. Cut/Copy/Paste/Delete плюс какое-то внесение данных.
| 3. Сохранение. Выбор места, куда будет происходить сериализация.
<--4. Открытие. Выбор места, откуда будет происходить десериализация.
Опционально добавляются такие этапы:
5. Печать. Выбор фрагмента для печати, предварителньый просмотр.
6. Публикация. Расшаривание по почте/в системе документооборота/etc.
Создаете ли вы документ? Нет. Открываете окошко камеры. Редактируете его? Нет. Максимум, меняете представление потока данных. Сохраняете документ со всеми его данными? Открываете? С чего вдруг после всех этих "нет" у вас будет MDI?
Оверкво́тинг (англ. overquoting) — избыток цитат в тексте на форуме, в e-mail, новостной группе или эхоконференции. Критерием обычно считается превышение объёма цитируемого материала над оригинальным текстом самого автора сообщения. Оверквотингом также считается бессмысленное цитирование сообщения, расположенного непосредственно перед ответом, или же многократное вложенное цитирование.
Избыток цитат в тексте затрудняет нахождение и понимание собственной, высказываемой в данный момент, мысли автора. Запрещён во многих эхоконференциях и форумах.
В Фидо первоначальная строгость в отношении оверквотинга была обусловлена тем, что он сильно увеличивает трафик, и это было особенно болезненно во времена модемной связи. Теперь, когда почта в Фидо передаётся по высокоскоростным каналам, это не так актуально, но в сети уже сложилась определённая культура цитирования. Умелое цитирование позволяет удерживать нить беседы и всегда легко продолжить её, даже если прошло длительное время.
Невыполнение этих правил повлечёт за собой удаление либо перемещение топика модератором, а также (при достижении критической массы) включение отдельных личностей в так называемый бан-лист.
...
3. Запрещается излишнее цитирование (overquoting). Если вы отвечаете на письмо, цитируйте из него только те отрывки, которые действительно необходимы для понимания, о чём идёт речь.
...
Здравствуйте, SV., Вы писали:
SV.>А что же это? Смотрите сами. Большая красная полоска извещает, что базы сильно устарели, но нигде ни полслова нет про дату последнего обновления. Сильно — это сколько?
Очевидно, что отношение локальной базы к базе источника обновлений. Так что дата последнего обновление с показателем устарелости не сильно связана. А дополнительная информация типа "Появилось 6785 новых сигнатур" пользователю мало что скажет.
Как по мне КАВ пример красивого, простого и понятного интерфейса.
).
Хороший UI — это офигенно много работы и обязательно участие талантливого спеца по юзабилити (пусть он даже сам себя спецом не считает). Иначе никак
