Re: Так на чем же, все-таки, делать GUI ? - Пользовательский интерфейс: проектирование, usability

Здравствуйте, okman, Вы писали:

O>Итак, на чем лучше всего делать GUI для Windows-программы ?

Постановка вопроса неверна. Какой именно GUI? ибо GUI size matters.
В том смысле что есть разные задачи решаемые этим самым GUI.

Кстати я не считаю что MFC и WTL в чистом виде это GUI. Это сборка из кубиков инетрфейса (UI) известного как
CUA (1985 год). Если набор кубиков устраивает задачу —
— скажем в пишите редактор типа Word,Excel, Visio — то это самое то что нужно и все счастливы. Как только требуется что-то
именно графическое в UI — получаются MFC уродцы (если и не визуально то внутри точно).
По всяко разным причинам включая технические, типа отсутствие прозрачности у окон и пр.

Инструмент дожен быть адекватен задаче. Избитая истина но тем не менее.

Скажем что-то в стиле Metro UI можно написать только
в windowless среде. И все такое прочее.

И еще один аспект. Про приложения "одной большой кнопки". Есть целый класс оных.
Это те приложения UI которых нужен либо один раз в месяц либо один раз вообще. Там UI должен быть "самочитаемым" сиречь очевидным ибо юзер знакомится с ним каждый раз когда открывает.

Один знакомый UI идеолог в области серьёзной shareware мне сказал что у него в среднем есть 50 секунд на то чтобы юзер сказал берет он программу или нет.
Т.е. от download до появления окна и по начальному содержимому окна в течении первых сколько там секунд основная масса юзверей принимает решение про оно им нравится или нет. Тоже вот критерий для UI.

Это что касается картинки на экране.

Под капотом UI лежит слой кода как правило очень странной структуры: "по нажатию на кнопку тут запустить анимацию там и за 10 процентов от её окончания показать вот здесь сбоку изображение дули". Я считаю что JavaScript, а особенно мой TIScript в Sciter, для этой задачи подходят идеально. First class functions вельми рулят в этом смысле. Вообще скрипт как средство выражения нативных функций приложения в предсталение на экране представляется way to go.
Ну и HTML/CSS/DOM как средство динамически генерировать/склеивать UI ... Уже сказано много про это.

Короче — есть разные задачи и разные инструменты для их решения.
Без описания задачи вопрос "на чем делать GUI ?" смысла особо не имеет как мне кажется...

Здравствуйте, c-smile, Вы писали:

CS>Здравствуйте, okman, Вы писали:

O>>Итак, на чем лучше всего делать GUI для Windows-программы ?

CS>Постановка вопроса неверна. Какой именно GUI? ибо GUI size matters.
CS>В том смысле что есть разные задачи решаемые этим самым GUI.

Назначение многих программных инструментов — предоставить API для решения некой задачи,
не погружая клиента, насколько это возможно, в детали реализации.
Взять, к примеру, сценарии инсталляции. Есть инструменты, где такие сценарии от и до
описываются специальным DSL, диалоги рисуются и "подтюниваются" в редакторе форм, а
поведение задается с помощью набора Custom Actions, причем делать все это вполне
может человек, ни разу не слышавший до этого про MSI-таблицы, Property и т.д.
Для программирования элементов или видов, отличных от имеющихся в базовом наборе,
предоставляется SDK. Это есть пример правильной библиотеки.

Проблема почти всех GUI-фреймворков, с которыми мне приходилось работать, в том, что
помимо форм, приходится писать код, решающий задачи "по нажатию на кнопку тут запустить
анимацию там и за 10 процентов от её окончания показать вот здесь сбоку изображение дули".
Этим не может заниматься дизайнер, так как не умеет программировать на таком-то языке, и
это не под силу программисту, так как нужно дружить с чувством стиля, иметь вкус, и т.д.
Получается не GUI, а ерунда. Очень встречающаяся ситуация, по-моему.

Кроме того, если нужно запрограммировать контрол с нестандартным поведением или видом (что
необязательно является данью моде на всякие "плюшки" — бывает, что реально нужно, а нету),
это превращается в трудоемкую задачу.

Я не могу сказать, что такая-то библиотека "плохая" или "хорошая" — просто программировать
интерфейсы на ней, пусть даже это простые диалоги со стандартными контролами, неудобно.
Как только появляется необходимость что-то перекроить, это вызывает "рези" в разных местах "организма".

CS>Инструмент дожен быть адекватен задаче. Избитая истина но тем не менее.
CS>Я считаю что JavaScript, а особенно мой TIScript в Sciter, для этой задачи подходят идеально. First class functions вельми рулят в этом смысле. Вообще скрипт как средство выражения нативных функций приложения в предсталение на экране представляется way to go.
CS>Ну и HTML/CSS/DOM как средство динамически генерировать/склеивать UI ... Уже сказано много про это.

Не могу с этим не согласиться.
Только такой подход я пока видел только в Qt и HTMLayout, а остальные вроде идут проторенной дорогой...

Здравствуйте, okman, Вы писали:

S>>Рассматривать программирование под Винд, отсекая .NET и Джава в текущем веке выглядит также забавно.

O>В системном софте GUI на .NET или Java считается хорошим тоном только в исключительных случаях.

А как быть с GUI "системного софта" на HTMLayout? Тон лучше?

Здравствуйте, Аноним, Вы писали:

O>>В системном софте GUI на .NET или Java считается хорошим тоном только в исключительных случаях.

А>А как быть с GUI "системного софта" на HTMLayout? Тон лучше?

При прочих равных условиях я склоняюсь в пользу HTMLayout.
Очень легкая библиотека (~1 Мб), не имеет проблем с версионностью и не требует установки
всяких рантаймов. Это значит, что программы, построенные на HTMLayout, элементарно
развертываются на любом клиентском компьютере, что, к примеру, для массового коммерческого
софта вообще критично.

Да-да, Вы не ослышались — .NET имеет проблемы версионности (из-за всяких Service Pack-ов, в
первую очередь, которые нарушают принципы версионности .NET), а если не верите, попробуйте, к
примеру, установить WDK 6000 поверх Visual Studio 2008. Кроме того, фреймворк предустановлен
не на всех машинах (на XP — отсутствует, на Vista — .NET 2.0, на Seven — 3.0, если не ошибаюсь,
на Server 2008 — требует установки через Roles/Features).

Кроме этого, в нативных приложениях взаимодействие с системным API часто более естественное.
Например, драйвер, через shared memory отображающий некоторые системные параметры.
На чем будет проще и естественнее организовать визуальное представление этих параметров ?
Лично для меня ответ на этот вопрос очевиден.

Здравствуйте, okman, Вы писали:

O>Проблема почти всех GUI-фреймворков, с которыми мне приходилось работать, в том, что
O>помимо форм, приходится писать код, решающий задачи "по нажатию на кнопку тут запустить
O>анимацию там и за 10 процентов от её окончания показать вот здесь сбоку изображение дули".
O>Этим не может заниматься дизайнер, так как не умеет программировать на таком-то языке, и
O>это не под силу программисту, так как нужно дружить с чувством стиля, иметь вкус, и т.д.
O>Получается не GUI, а ерунда. Очень встречающаяся ситуация, по-моему.

Да, собсвенно для этого и сделаны declarative transitions/animations в CSS:

button { color:red; }
button:hover 
{
  color:blue;
  transition: color(linear,400ms);
}

CS>>Инструмент дожен быть адекватен задаче. Избитая истина но тем не менее.
CS>>Я считаю что JavaScript, а особенно мой TIScript в Sciter, для этой задачи подходят идеально. First class functions вельми рулят в этом смысле. Вообще скрипт как средство выражения нативных функций приложения в предсталение на экране представляется way to go.
CS>>Ну и HTML/CSS/DOM как средство динамически генерировать/склеивать UI ... Уже сказано много про это.

O>Не могу с этим не согласиться.
O>Только такой подход я пока видел только в Qt и HTMLayout, а остальные вроде идут проторенной дорогой...

Ну не только Qt и HTMLayout... весь web использует такой подход. А это много.

На самом деле разница между архитектурой традиционного UI и web UI состоит в том что последний оперирует набором униформных блоков со сквозным и декларативным стилированием (CSS) оных. Плюс к тому jQuery & friends как фактически язык запросов (CSS selectors) к UI и манипуляций c оным.

Здравствуйте, okman, Вы писали:

O>Не могу доподлинно знать, как и какими усилиями делается такой GUI, но хочу уметь
O>делать нечто подобное.

Это сделано на QT.

Здравствуйте, Hexxx, Вы писали:

H>Здравствуйте, okman, Вы писали:

O>>Не могу доподлинно знать, как и какими усилиями делается такой GUI, но хочу уметь
O>>делать нечто подобное.

H>Это сделано на QT.

Неправда. KIS2010 и Qt никак не связаны.

Здравствуйте, okman, Вы писали:

O>8. Qt.

9. Ultimate++ (http://www.ultimatepp.org/)

Посмотри, может понравится. Этот фреймворк почти что много платформенный (пока что виндовс и линукс), прост в использовании почти как C#, включает в себя много всякой полезности включая рендерер векторной графики, текстовый редактор, свою IDE. Не использует родных контролов. Все рисуется самостоятелько. Размер прог сильно меньше чем при использовании Qt. Отпугивающим фактором может быть весьма не ортодоксальный дизайн как самой библиотеки так и IDE, но это уже дело вкуса каждого конкретного человека.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Hexxx, Вы писали:

H>>Здравствуйте, okman, Вы писали:

O>>>Не могу доподлинно знать, как и какими усилиями делается такой GUI, но хочу уметь
O>>>делать нечто подобное.

H>>Это сделано на QT.

А>Неправда. KIS2010 и Qt никак не связаны.
2010 может и нет, а 2012 — да. Там qt-шные DLL лежат в корне.

Здравствуйте, okman, Вы писали:

O>Всем доброго дня.

O>Следующий этап — программирование того, что я называю GUI Finite State Machine.
O>Это всевозможные комбинации состояний контролов и их реакций на всякие события.
O>Например, кнопка "Применить" подсвечивается только если список не пуст, а полоса
O>прокрутки появляется когда таблица не вмещает все элементы. Ну и так далее.
O>Возможно, этот этап не менее важен, чем первый, и он в какой-то степени должен
O>быть удобен, чтобы, скажем, отключение кнопки достигалось одним-двумя вызовами
O>функций или свойств соответствующего контрола.
...
O>Прошу в тему.
Может не совсем в тему, но по одному описанному пункту.
Мне больше нравится для реализации описанного этапа — событийный подход.
Для начала нам необходимы команды которые можно связывать с контролами. Та же команда "применить" может быть связана как с кнопкой "применить" на тулбаре так и с меню "применить". Команды имеют начальное состояние и могут "слушать" информацию о событиях. В данном примере, команда "применить" будет реагировать на два события "список не пуст", "список пуст".

Cообщение написано в << RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461>>

Здравствуйте, Hexxx, Вы писали:

H>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, Hexxx, Вы писали:

H>>>Здравствуйте, okman, Вы писали:

O>>>>Не могу доподлинно знать, как и какими усилиями делается такой GUI, но хочу уметь
O>>>>делать нечто подобное.

H>>>Это сделано на QT.

А>>Неправда. KIS2010 и Qt никак не связаны.
H>2010 может и нет, а 2012 — да. Там qt-шные DLL лежат в корне.

2010 сделан на собственном внутреннем движке, 2012 на QML

Здравствуйте, okman.

Хотелось бы узнать вот о чём.

O>Следующий этап — программирование того, что я называю GUI Finite State Machine.
O>Это всевозможные комбинации состояний контролов и их реакций на всякие события.
O>Например, кнопка "Применить" подсвечивается только если список не пуст, а полоса
O>прокрутки появляется когда таблица не вмещает все элементы. Ну и так далее.
O>Возможно, этот этап не менее важен, чем первый, и он в какой-то степени должен
O>быть удобен, чтобы, скажем, отключение кнопки достигалось одним-двумя вызовами
O>функций или свойств соответствующего контрола.

Как Вы "проектируете" GUI Finite State Machine. Какие средства для этого используете,
или всё на бумажке рисуете?
Просто мне до сих пор приходилось всё с карандашом на листке, но это не очень удобно.
Например, при написании даже простенького текстового редактора это вряд ли хороший выбор,
так как результат нажатия клавиши может быть различным, и этих вариантов немало.

Здравствуйте, korzhik, Вы писали:

K>2010 сделан на собственном внутреннем движке, 2012 на QML

Кто б еще объяснил, что там символизирует срез колбасы сверху? Она получилась из той мерзко визжащей свиньи? Хотя, судя по излишней симметрии, это все-таки не колбаса...

Здравствуйте, stdcout, Вы писали:

S>Как Вы "проектируете" GUI Finite State Machine. Какие средства для этого используете,
S>или всё на бумажке рисуете?
S>Просто мне до сих пор приходилось всё с карандашом на листке, но это не очень удобно.
S>Например, при написании даже простенького текстового редактора это вряд ли хороший выбор,
S>так как результат нажатия клавиши может быть различным, и этих вариантов немало.

Я пишу код заполнения таблицы состояний и переходов (transition table) для таким образом,
чтобы он сам был похож на таблицу:

//              State      |  Event     |  New State   | Function
//---------------------------------------------------------------------
add_record(   editing      | new_user   | editing      | add_new_user    );
add_record(   editing      | del_user   | editing      | delete_user     );
add_record(   editing      | close      | on_save_dlg  | none            );
//---------------------------------------------------------------------
add_record(   on_save_dlg  | yes        | empty        | save_document   );
add_record(   on_save_dlg  | no         | editing      | none            );
//---------------------------------------------------------------------
//...

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

От:	c-smile	http://terrainformatica.com
Дата:	18.09.11 17:22
Оценка:	21 (5) +1

От:	okman	https://searchinform.ru/
Дата:	19.09.11 06:45
Оценка:

	От:	Аноним
	Дата:	23.09.11 04:35
	Оценка:

От:	okman	https://searchinform.ru/
Дата:	23.09.11 05:41
Оценка:

От:	c-smile	http://terrainformatica.com
Дата:	25.09.11 16:42
Оценка:

	От:	Тот кто сидит в пруду
	Дата:	26.10.11 09:46
	Оценка:

От:	jazzer	Skype: enerjazzer
Дата:	26.10.11 10:01
Оценка:	16 (2)

	От:	Hexxx
	Дата:	05.10.11 07:33
	Оценка:

	От:	ssg01
	Дата:	07.10.11 04:36
	Оценка:	12 (1)

	От:	Hexxx
	Дата:	11.10.11 06:47
	Оценка:

	От:	AlexNek
	Дата:	15.10.11 17:09
	Оценка: