Войти
ФлеймФорумПрограммирование

Пример новой (для меня) задачи (по просьбам трудящихся)

Страницы: 1 2 3 4 Следующая »
#0
19:22, 5 авг 2017

"Новой" - в смысле, я до сих пор не знаю готового решения.

Например, есть рисунок "X-Fighter" с пояснениями. Как его отобразить? Возможны варианты:

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

Это все "фенотипы". А "генотип"? В последнее время прихожу к выводу, что нужна КНИГА - текст на одной странице, рисунок - на другой (или наоборот, или оба текста, или оба рисунка). Важно только то, что выделению некоего слова-якоря на странице "слева" соответствует вывод новой страницы "справа"... Как вывести эти "страницы": рядом, одну поверх другой, одну скрыть...- дело конкретного фенотипа. В примере выше на одной странице пояснения, на другой - рисунок.
***

А как быть, если речь идет о некой форме/диалоге со многими полями? Никакой множественной связи "якорь слева - контрол справа"! Каждому якорю соответствует всегда новая страница! А то, что несколько страниц лишь представляют разные виды на одну и ту же форму, это "левую" страницу не волнует...
***

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

    Система КОМНАТ и интерфейс Раскина - "одностраничные".
    Интерфейс игры TransArctica, которую я привел, как пример КОМНАТНОЙ модели, явно двухстраничный.
    Также двухстраничный интерфейс применяется в игре Critical Path - см. в начале этой статьи.
    По сравнению с одностраничным интерфейсом, выигрыш очевиден - активная информация естественно делится на "важную" и "сиюминутную". Последнюю можно "перелистывать", не "забывая" первой (не переупаковывая данные).
    "Двухстраничность" многих оконных приложений является не плюсом, а минусом, например, требуя избыточных переключений с мышки на клавиатуру и обратно (тут Раскин был безусловно прав). Это потому, что там редактируемая информация оказалась на одной странице, а органы управления - на другой.

Где еще двухстраничная организация смотрится естественно?

    Текст с иллюстрациями/пояснениями.
    Наоборот, ведение заметок по мере чтения текста.
    Редактирование связи таблиц многие-ко-многим Базы Данных.
    Навигация в Базе Данных в стиле "список-объект" и/или "объект-атрибуты". (Контрпример: в редакторе Базы Данных Smalltalk использовалось аж пять "страниц").

Первые наметки к реализации:

    Всегда рассматривать общий случай - "страницы равноправны" - или отдельно различать более простые - "ведущая - ведомая"? Думаю, первое.
    Опыт HTML-реализации дал вид ссылки на страницу: "имя страницы-значения параметров", что позволяет вызывать одну и ту же страницу "по-разному". "Значения параметров" представляются в виде пар "параметр значение" и служат для настройки конкретного вида страницы, вода значений по умолчанию и/или настройки обратной связи.
    Опыт Баз Данных: это очень похоже на концепцию смены точки зрения. Т.е. текущее представление (страница) - выглядит как список кортежей БД (выдранных из одной или нескольких связанных таблиц), "видимых из некоторой точки", один из кортежей считается текущим. Возможны два вида смены точки зрения: выбор текущего кортежа "для более подробного рассмотрения" (например, переход от списка сотрудников к личной карточке), либо переход к связанной точке зрения (например к списку подчиненных этого сотрудника). В этом случае переходы первого рода естественно смотряться как обновление второй страницы. Однако, описанный выше пример с преподавателями-студентами, показывает, что все не так однозначно: там возникает смена точки зрения, связанная с перемещением фокуса между первой и второй страницами.
***

Итак, требуется именно теоретико-множественная модель, никак не зависящая от способа визуализации. Поэтому ответы: "Берем требуемую экранную форму и правим по месту",- не принимаются. Как показало обсуждение там - https://gcup.ru/forum/7-44320-1 , задача объяснить, что нужно, визуальному программисту еще сложнее исходной.

#1
19:49, 5 авг 2017

  Для начала было бы неплохо определиться с тем для чего это нужно.

#2
20:07, 5 авг 2017

Угу, нужно начинать сначала, актуальность - хренбы с ней, какая проблема решается?
Что нужно получить в итоге? Общее решение, алгоритм, программу, устройство?

#3
20:09, 5 авг 2017

равен
> Для начала было бы неплохо определиться с тем для чего это нужно.
Началось с выбора наиболее удобного HTML-представления игры М.Пухова "Лунолет". Это была такая книга-игра, к каждой главе которой была приложена простенькая программка для программируемого калькулятора. Сначала все было просто: в левом фрейме книга, в правом - CGI-калькулятор. Постепенно стало усложняться - книга-то большая, захотелось фиксироваться на отдельных страницах, иметь специальные страницы под содержание, блок-схемы, заметки, включать другие подобные книги... Т.е. понадобился некий язык для описания страниц и переходов между ними. По мере его написания подумалось, а нельзя ли сделать этот язык независящим от конкретного представления страниц. Например простым "переключателем вида" без изменения ссылок перейти от двух фреймов к фону-аппликации:
Изображение
Т.к. попутно рядом валялась еще пара проектов, которые на удивление легко перевелись в двухстраничный формат, возникла идея сделать его универсальным для всех проектов.

exchg
> Что нужно получить в итоге?
>> Теоретико-множественную модель.

#4
20:35, 5 авг 2017

gudleifr
> Т.к. попутно рядом валялась еще пара проектов, которые на удивление легко
> перевелись в двухстраничный формат, возникла идея сделать его универсальным для
> всех проектов.
  То есть это среда для удобного представления проектов?

#5
20:52, 5 авг 2017

равен
> То есть это среда для удобного представления проектов?
Интерфейсов проектов.
Зависит от проектов. Вполне допускаю, что существуют проекты, интерфейсы которых заведомо требуют более, чем двух страниц.
Вспомнилась игра Metal Marines. Там, кроме "страниц", присутствовали летающие между ними объекты.
Выше уже писал про 5-страничный стандартный интерфейс Smalltalk.

#6
21:48, 5 авг 2017

gudleifr
  Я вижу что ты уже давно этой темой занимаешься,
чего ты достиг за два года?

#7
22:02, 5 авг 2017

равен
> Я вижу что ты уже давно этой темой занимаешься,
> чего ты достиг за два года?
Сейчас не до этого. Единственная связь этой задачи с злободневным проектом (восстановлением моей интернет странички) - размещение якорей и ответных частей в разных местах моей базы данных для синхронизации внешних ссылок и коррекции исправлений. Ну, еще осталась, пара-другая имеющих двухстраничную организацию стареньких просмотрщиков/редакторов базы. Вернусь к этой задаче, когда буду воскрешать "Лунолет"...

#8
12:55, 6 авг 2017

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

#9
13:00, 6 авг 2017

kipar
Вы можете предложить решение? Или просто опять увидели много знакомых слов?

kipar
> есть много решений, для разных языков и задач
Мне нужно одно решение - на подавляющее большинство языков и задач разом!

#10
14:47, 6 авг 2017

gudleifr
> Мне нужно одно решение - на подавляющее большинство языков и задач разом!
И при этом своё. Поэтому предлагать свои не вижу смысла, они вам не подойдут.
gudleifr
> Или просто опять увидели много знакомых слов?
Именно. Так все-таки, какой смысл решать задачу для равноправных окон, если почти все случаи испльзования сводятся или к ведущий-ведомый или к независимым окнам?

#11
14:56, 6 авг 2017

kipar
> И при этом своё.
Не обязательно. Согласен и на готовое.

kipar
> какой смысл решать задачу для равноправных окон, если почти все случаи
> испльзования сводятся или к ведущий-ведомый или к независимым окнам?
Мне так нужно. Т.к. общего решения для системы "ведущий-ведомый" так же не существует, то не вижу смысла себя ограничивать.
Или Вы можете доказать. что модель с равноправными окнами в общем случае более сложна, чем с неравноправными? Не имея ни той, ни той.

#12
10:46, 7 авг 2017

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

1. некоторая база данных (БД), в т.ч. со всеми необходимыми пометками для представления отдельных информационных фрагментов, здесь хранящихся (что-то вроде HTML-тегов - ссылки, блоки, контейнеры... заранее формализовать не будем)
2. некий управлятор экрана/окна (УЭ), умеющий отображать то, что просит программа, и информировать ее о свойствах полей для рисования и происходящих событиях.

Изображение

Допустим, речь идет об игре Duna. Здесь 1-я страница - "комната" с персонажами, 2-я - полоска с органами управления и всплывающими (как рисунке) окнами разговора.

Как происходит работа? Допустим, Управлятор 2-й-страницы (У2) хочет выполнить запрос на перелистывание (вызванный сигналом, пришедшим от 1-й страницы). Он анализирует требуемый фрагмент информации и запрашивает  у УЭ подходящие области, например, для вывода реплики леди Джессики. УЭ информирует о размерах доступной области. У2 вырезает из фрагмента нужный кусок и посылает УЭ. Аналогично, остальные части фрагмента. В т.ч. куски, которые будут порождать новые перелистывания (переходы игрока в другие комнаты). Информация для некоторых полей 2-й страницы может остаться старой (например, план дома), но она, все равно, считается частью текущего фрагмента (наследуется им).

Т.к. я настаиваю именно на двухстраничном интерфейсе, то очевидно наличие некоторого общего управлятора обоими страницами (УС). Он должен хранить информацию в т.ч. о типах страниц, допустимых способах перелистывания и способах/возможностях выполнения других запросов.

Т.о. получаем цепочку БД-У1/2-УС-УЭ. Теперь нужно решить какого рода запросы могут передаваться между узлами и какими путями/циклами их следует ограничить... Ни конкретный язык, ни способ хранения фрагментов, ни конкретный GUI к решению задачи отношения не имеют.

#13
12:22, 7 авг 2017

По описанию похоже на MVC, но в Дюну не играл, так что примера не понял.
То что понял выглядит как независимые окна - отдельно органы управления (отображаемые всегда, по клику вызывающие смену режима или модальные окна), отдельно реплики (отображаемые если игра в режиме диалога, по клику вызывающие соответствующую реакцию на реплику заданную скриптом\хардкодом), отдельно - главный экран, который тоже как-то рисуется на основании состояния игры.

#14
12:31, 7 авг 2017

kipar
Пожалуйста, перестаньте искать знакомые слова. Речь не о том, что любая визуальная обезьяна может написать обработчик onClick или нарисовать BitBtn. Протокол HTTP видели? Вот, надо изобрести от 3 до 7 таких же для общения между 4-мя перечисленными компонентами.

Страницы: 1 2 3 4 Следующая »
ФлеймФорумПрограммирование

Тема в архиве.