Давай рассмотрим интерфейс как некоторый язык. Элементы управления это символы в алфавите данного языка (причём, скажем, ComboBox это сразу столько символов, сколько в нем элементов).
Есть некоторые сообщения (создать документ, ввести букву, записать документ в файл)
Задача: создать такой интерфейс, чтобы Его алфавит был коротким
Часто употребляемые сообщения кодировались более короткими последовательностями символов и вообще все кодировались максимально коротко
Требования конфликтующие.
Короче свести задачу создания интерфейса к теории шифров (знакое так получилось)
Здравствуйте, adontz, Вы писали:
A>Давай рассмотрим интерфейс как некоторый язык. Элементы управления это символы в алфавите данного языка (причём, скажем, ComboBox это сразу столько символов, сколько в нем элементов).
A>Есть некоторые сообщения (создать документ, ввести букву, записать документ в файл)
A>Задача: создать такой интерфейс, чтобы A> A> Его алфавит был коротким A> Часто употребляемые сообщения кодировались более короткими последовательностями символов и вообще все кодировались максимально коротко A>A>Требования конфликтующие.
A>Короче свести задачу создания интерфейса к теории шифров (знакое так получилось)
A>Вот такой вот бред сидит у меня в голове
! Идея хороша и требует тщательного обдумывания. Попробуем что-нибудь накрутить из этого.
2модератор: можно откусить эту ветку? (начиная с предыдущего сообщения)
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>! Идея хороша и требует тщательного обдумывания. Попробуем что-нибудь накрутить из этого.
Из этого можно накрутить систему количественной оценки интерфейса. Скажем
[Сумма по ( [Длина последовательности для сообщения]*[Вероятность сообщения] )] * [Длина алфавита]
// наверху не понятно что, вот кодfloat sum = 0;
foreach (message in messages)
{
sum += message.length*message.probablity;
}
float result = sum*alphabet.length;
Тогда 1 checkbox и 2 radiobutton или combobox с 2 элементами будут иметь одну оценку, что логично.
Вот создавать интерфейс на основе этой идеи вряд ли получится.
ЗХ>2adontz: ты последнее письмо получил?
Последнее что я полуил начиналось с Ну, фик с ним. Есть что — перепошли (resend)
P.S. pochta.ru не ахти какая почта у меня самого она жутко тормозила и я её бросил, Gmail рулез форева (инвайты кажется остались)
Здравствуйте, adontz, Вы писали:
A>Вот такой вот бред сидит у меня в голове
Цель — найти, принять, реализовать и выгодно использовать удобный способ описания/кодирования пользовательского интерфейса.
Если наши интересы совпадают, то двинемся дальше.
Встаёт вопрос: как лаконично описать элементы пользовательского интерфейса и маршрутизацию сообщений между ними, как основную задачу разработки GUI.
Анализ существующих подходов:
Если нужна простота и скорость разработки — конструктор форм (диалогов), редактор HTML.
Если нужна мощь и гибкость — нужен язык программирования.
Ещё один вопрос — можно ли объединить простоту и удобство конструктора (для начального проектирования), с мощью и гибкостью языка?
Если наши выводы близки, то двинемся дальше.
А что если нам взглянуть на задачу реализации GUI не с точки зрения создания автономных контролов (кои плодятся и им нет числа), а с точки зрения управления графическими примитивами?
Что если набор неких свойств и действий (делегатов), будет реализовывать определённый аспект поведения — способности. Как то — нажимаемость, выбираемость, подсвечиваемость, перемещаемость.
Можно ли, имея небольшую библиотеку таких способностей покрыть существенно большой класс задач? А новые потребности решать, расширяя библиотеку способностей?
WR>Встаёт вопрос: как лаконично описать элементы пользовательского интерфейса и маршрутизацию сообщений между ними, как основную задачу разработки GUI.
WR>Анализ существующих подходов: WR>Если нужна простота и скорость разработки — конструктор форм (диалогов), редактор HTML. WR>Если нужна мощь и гибкость — нужен язык программирования.
WR>Ещё один вопрос — можно ли объединить простоту и удобство конструктора (для начального проектирования), с мощью и гибкостью языка?
Здравствуйте, WoldemaR, Вы писали:
WR>Встаёт вопрос: как лаконично описать элементы пользовательского интерфейса и маршрутизацию сообщений между ними, как основную задачу разработки GUI.
Нет, вот тут я другого мнения. Маршрутизация сообщений не между элементами интерфейса. Интерфейс, если уж обощать это некоторый конечный автомат. Я хочу, чтобы конечный автомат принял все необходимые мне состояния за минимум переходов, при максимально бедном входном алфавите. Больше ничего не хочу. Как этот конечный автомат работает меня не особо волнует.
Здравствуйте, WoldemaR, Вы писали:
WR>Можно ли, имея небольшую библиотеку таких способностей покрыть существенно большой класс задач? А новые потребности решать, расширяя библиотеку способностей?
Это чем-то напоминает два подхода в японском языке. С одной стороны присутствуют иероглифы, описывающие конкретные идеомы и которых очень много, а с другой стороны присутствует слоговая азбука, состоящая из очень ограниченного набора слогов (букв), коими можно что угодно написать.
Таким образом, если провести указанную аналогию, то возникает вопрос — сколько комбинированных способностей потребуется, чтобы покрыть существенно большой класс задач? И целесообразно ли введение таких наборов способностей, если они получатся достаточно уникальны и использовать их все сможет только очень высококлассный разработчик?
Вообще-то, мне кажется, что если я правильно понимаю ваше понятие способностей, то в текущий момент, например, контрол, позволяющий вводить дату через календарь, как раз является ярким представителем накого набора способностей...
В дополнение хотел бы добавить, что в рамках, например, создания некоего программного продукта ещё можно ограничить необходимые и наиболее часто встречающиеся наборы способностей и реализовать для них специфические повторноиспользуемые элементы интерфейса (что обычно и делается написанием собственных контролов на основании простых, например). А вот если задумываться над выделением наиболее важных интерфейсных элементов на уровне языка, а точнее библиотеки, то боюсь, что удастся выделить только календари и т.п. уже существующие элементы.
(инвайты кажется остались)
