|
API для "двухстраничного" интерфейса
| |
| Gudleifr | Дата: Вторник, 12 Мая 2015, 11:44 | Сообщение # 1 |
почти ветеран
Сейчас нет на сайте
| Постоянно сталкиваюсь с тем, что "одной страницы" не хватает - в одном окне нужно расположить два информационных объекта.
1. Например, на HTML странице размещаю два фрейма и меняю содержимое одного по результатам выбора в другом.
2. В играх обычно имеем окошко с игровым полем, окруженное рамкой-пультом.
3. В визуальных IDE двумя главными окнами являются окно дизайна "кнопочек" и окно их свойств (когда активно писал под Windows, всегда ставил два монитора).
...
Причем, анализ показывает, что двух "страниц" обычно хватает (информация важная и информация текущая). Остальные вполне могут "всплывать диалогами" по по необходимости или располагаться во вкладках.
Конечно, любой визуальный IDE содержит кучу механизмов для управления связями Controls и для размещения рисунков/органов управления "многослойно". Но существуют ли "редакторы"/библиотеки, позволяющие разбить все чем нужно управлять на два множества и отслеживать сообщения именно между ними, а не отдельными Controls? (Например, в HTML фреймы обмениваются информацией в целом, один не может адресовать конкретный фрагмент другого). Возможность создать Active-X контейнер на группу Controls, это уже перебор. Интересует именно обмен информацией между "страницами", а не способ табулирования и ресайзинга Controls внутри "страницы".
Другой вопрос: очевидно, что самым очевидным представлением будут "две страницы книги" (см. выше фреймы). В Windows мы такое видим, обычно, только в виде честного рисования (две страницы книги в Акробате) или жуткого вида Splitter-ами. Есть какие-нибудь идеи, позволяющие соизмерять порции информации на двух половинках окна? (В принципе, эта проблема существует и в HTML, где, если не хочешь возится с фреймами, нужно брать таблицу на две клетки и рассчитывать, что поместится в зависимости от разрешения экрана).
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
|
|
|
| |
| Snake174 | Дата: Среда, 13 Мая 2015, 09:08 | Сообщение # 2 |
участник
Сейчас нет на сайте
| Немного непонятно что хочешь сделать и на чём.
Если делать на C++/Qt, можно добавить "докуемое" окно, использовать сигналы/слоты для взаимодействия.
http://snake174.github.io/html/programs/pipmak_assistant.html
Посмотри здесь на скриншотах. Слева два "докуемых" окна (одно со списком проектов, второе - содержимое папки проекта). Соответственно, при выборе из первого окна содержимое второго меняется. В правой части "основное окно".
Не следует обманывать инспектора
Pipmak Assistant
Love2D Exporter
Love2D-Helpers
 Old Consoles Games
|
|
|
| |
| Gudleifr | Дата: Среда, 13 Мая 2015, 10:19 | Сообщение # 3 |
|
почти ветеран
Сейчас нет на сайте
| Имеется в виду следующее.
между двумя интерфейсами:
и
есть смысловая тождественность, восходящая к обычной книге
Что вполне очевидно.
Однако, есть две неприятности:
1. Синхронизация "страниц" обычно реализуется не как обмен между "половинками" (как во фреймах HTML), а как жуткие макароны связей между отдельными Controls.
2. Нормальная синхронизация размеров информационнных кусков возможна, пожалуй, только при ручной отрисовке страниц. Проблема масштабирования, как и в Акробате, нерешаема в принципе (фиг посмотришь на маленьком экране).
"На чем?" Пока требуются принципиальные решения. Например, примерные свойства объекта "страница", примерные параметры операции "синхронизация".
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Сообщение отредактировал Gudleifr - Среда, 13 Мая 2015, 10:20 |
|
|
| |
| Snake174 | Дата: Среда, 13 Мая 2015, 10:45 | Сообщение # 4 |
|
участник
Сейчас нет на сайте
| 1) Создаёшь объект "Страница"
2) Добавляешь к этому объекту несколько дочерних и делаешь им "слушатели определённых событий"
3) Создаёшь объект "Controls"
4) Добавляешь к нему всякие кнопки, списки и т.д.
5) Делаешь "слежение" объекта "Control" за изменением своих дочерних объектов
6) При изменении объектов посылаешь сигнал в объект "Страница"
7) "Страница" уже определяет какому объекту был послан сигнал и что с ним делать
Не знаю, как-то так, наверно  Наверняка кто-нибудь подскажет что-то более стоящее.
Не следует обманывать инспектора
Pipmak Assistant
Love2D Exporter
Love2D-Helpers
Old Consoles Games
|
|
|
| |
| Gudleifr | Дата: Среда, 13 Мая 2015, 10:59 | Сообщение # 5 |
|
почти ветеран
Сейчас нет на сайте
| Snake174, пардон, это у Вас "издержки визуального образования": мол, не знаем, что нам надо запрограммировать, но если начать рисовать окна, может, что и получится. Какие "сообщения" должна получать "страница"? Как реагировать на "отслеженное" событие "не влазит"? Как менять один набор Controls на другой при смене типа "страницы"? Ваше "решение" - это, по-сути, отсутствие решения: мол, берем, чего надо, и рисуем. А вопрос ставился, скорее, как: "А что нам может быть надо в принципе?" Существуют ли интерфейсы, заведомо не сводимые к двум страницам? Частью какой страницы считать Win-рамку с "обычными панелями"? Как можно избавиться от Controls прокрутки и перелистывания?
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
|
|
|
| |
| YellowAfterlife | Дата: Среда, 13 Мая 2015, 13:08 | Сообщение # 6 |
Сейчас нет на сайте
| Цитата Gudleifr (  ) (Например, в HTML фреймы обмениваются информацией в целом, один не может адресовать конкретный фрагмент другого)
Не совсем. В JS разрешается управлять содержимым iframe в документе если он находится на том же домене, в том числе и адресовать document/window iframe'а. Следовательно, при загрузке iframe можно просто присвоить ссылку на "внешний" документ в одну из переменных, и из iframe можно будет через эту переменную работать с содержащим его документом. А далее - дело техники - разработать набор функций, что позволят достаточно удобно находить нужный элемент в том или ином фрейме.
Чтобы не разбрасываться пустыми словами, сделал пример, в котором ссылка в каждом из двух фреймов меняет содержимое отдельного элемента в другом.
|
|
|
| |
| Gudleifr | Дата: Среда, 13 Мая 2015, 13:17 | Сообщение # 7 |
|
почти ветеран
Сейчас нет на сайте
| YellowAfterlife, спасибо. Но в контексте вопроса, невозможность "управления в деталях" как раз плюс.
Например, в примере выше (второй рисунок - "Лунолет") параметры нажатой ссылки в левом фрейме честно передавались как параметры вызова CGI-калькулятора в правом. Откуда, в общем-то и родилась идея свести обмен между страницами к некоторому виду "синхронизации".
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
|
|
|
| |
| Snake174 | Дата: Среда, 13 Мая 2015, 13:29 | Сообщение # 8 |
|
участник
Сейчас нет на сайте
| Цитата "издержки визуального образования"
Это как?
Ты на HTML что-то хочешь сделать или что? А то собрал всё в кучу: HTML, Windows, IDE, страница, синхронизация, Acrobat, ...
Я тебе на примере С++/Qt объяснил как можно сделать.
Не следует обманывать инспектора
Pipmak Assistant
Love2D Exporter
Love2D-Helpers
Old Consoles Games
|
|
|
| |
| Gudleifr | Дата: Среда, 13 Мая 2015, 14:53 | Сообщение # 9 |
|
почти ветеран
Сейчас нет на сайте
| Snake174, именно - "или что". Я ищу общие закономерности такого рода интерфейсов. Поэтому и собрал "все в одну кучу". Т.к. все это вещи родственные и одинаково мне неподходящие...
А так, как Вы предложили - это, повторю, извините, способ сделать все, что угодно, но "визуально". Надо доказать Большую Теорему Ферма?- Создаем окно "Большая Теорема Ферма", вставляем кнопочку "Доказать", добавляем красивый MessageBox "Что и требоовалось доказать!", стальное - по ходу дела...
Цитата Snake174 ( ) Я тебе на примере С++/Qt
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
|
|
|
| |
| maker-rus | Дата: Среда, 13 Мая 2015, 17:29 | Сообщение # 10 |
Гений
Сейчас нет на сайте
| Цитата Gudleifr ( ) Например, в примере выше (второй рисунок - "Лунолет") параметры нажатой ссылки в левом фрейме честно передавались как параметры вызова CGI-калькулятора в правом. Откуда, в общем-то и родилась идея свести обмен между страницами к некоторому виду "синхронизации".
На примере двух web страниц, "синхронизиющихся" между собой, почему бы не сделать через сокет? И просто получать состояние одной страницы в другой или наоборот. По поводу "читалки", там реализация намного проще, просто вместо последовательного показа листов, показывается склейка. То есть просто меняют расположение листа, следующий лист теперь не на новой строке, а на той же, что находится и предыдущая страница. По поводу соизмерения и iframe, вы наверно отстали от технологий, раз до сих пор предлагаете табличную верстку. Использовать в 2015 году iframe, считаю бесчеловечным. Для этого, всего, давно придумали шаблонизаторы, которые позволяют подключать другие странички в шаблон. Про адаптивную верстку вы, наверно, так же не слышали.
Цитата Gudleifr ( ) но не нечто полезное для измышления новых интерфейсов.
ios - диалоги в вк, в две страницы, не не слышал такие "уникальные" интерфейсы, делящие область на две части давно существуют и давно применяются. Примеров масса, начиная от web-ide, заканчивая онлайн - web-читалками и блогами (ghost - nodejs редактирование в левой части, в правой готовое отображение в realtime).
|
|
|
| |
| Gudleifr | Дата: Среда, 13 Мая 2015, 17:36 | Сообщение # 11 |
|
почти ветеран
Сейчас нет на сайте
| maker-rus, и...?! Все давно известно и пройдено... Так почему не пересчитать на пальцах "основные моменты"? Как эти Ваши "замечательные фичи" и прочие "шаблонизаторы" обеспечивают "адаптивную верстку"? И нафига нам последняя?
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Сообщение отредактировал Gudleifr - Среда, 13 Мая 2015, 17:37 |
|
|
| |
| maker-rus | Дата: Среда, 13 Мая 2015, 18:11 | Сообщение # 12 |
|
Гений
Сейчас нет на сайте
| Цитата Gudleifr ( ) maker-rus, и...?! Все давно известно и пройдено... Так почему не пересчитать на пальцах "основные моменты"? Как эти Ваши "замечательные фичи" и прочие "шаблонизаторы" обеспечивают "адаптивную верстку"? И нафига нам последняя?
основные моменты? Поищите термины в Интернете, о которых я написал и почитайте внимательно, что каждая из них делает, ну если вам лень и весело собирать свой велосипед, то можно показать и на пальцах.
Начнем с терминов. Все термины по возможности взяты из открытых источников.
Адаптивный веб-дизайн (англ. Adaptive Web Design) — дизайн веб-страниц, обеспечивающий корректное отображение сайта на различных устройствах, подключённых к интернету и динамически подстраивающийся под заданные размеры окна браузера (с)Wikipedia.
Что это за монстр и как он нам пригодится? При создании адаптивного дизайна, подразумевают, что страница будет одинакова на всех устройствах (в примере сайтов), рабочих окнах (программ). А то есть соизмерением можно заняться в виде: "это сторона будет 40% процентов от экрана, а эта 60%". Эта избавляет от проблем вроде вашей: "как мне померить экран, я хочу что бы у всех это было одинаково удобно".
Что такое шаблонизатор и с чем его едят?
Шаблонизатор (в web) — это программное обеспечение, позволяющее использовать html-шаблоны для генерации конечных html-страниц. Основная цель использования шаблонизаторов — это отделение представления данных от исполняемого кода. Часто это необходимо для обеспечения возможности параллельной работы программиста и дизайнера-верстальщика. Использование шаблонизаторов часто улучшает читаемость кода и внесение изменений во внешний вид, когда проект целиком выполняет один человек. (с)Wikipedia.
Что можно и нужно с ним делать? Пройдемся по шагам, что бы была понятна эта "фича".
1. Код и отображения - порознь. То есть не нужно быть программистом, что бы подправить макет приложения, сайта.
2. Подключение сторонних страниц, файлов. В одной страничке может содержаться несколько страниц (2,3 и более), так же, они (страницы), называются блоками. Эта "фича" избавляет от добавления в код доисторического iframe и ему подобных. Потому что весь код шаблона может генерироваться на лету.
Ну наверно перейдем к самой модной "фиче", это - Node.js и сокетам.
Что же это за страшные слова и что они умеют?
Node.JS - Node.js® is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices. ©офф. сайт (кстати, гугл переводчик, занимается тем же "уникальным интерфейсом", при переводе).
Что же умеет этот зверь?
Начну с того, что этот зверь работает в режиме real-time. То есть весь код выполняется на лету. Он создает подключение между браузером и собой(сервером) за которым постоянно следит. Любое действие, которое вы отправите ему будет обработано сразу же. Начали вводить имя пользователя, он уже может оповестить, есть ли пользователь, с таким же именем.
Хорошо. Немного разобрались с терминами, как же это применить, что бы получить свою "неповторимую книжечку с мега-уникальным интерфейсом"?
Тут все намного проще чем кажется, поэтому распишу по шагам.
1. Создаем страничку с двумя блоками (два <div> тега), для наших двух страниц.
2. Подключаем это все к node.js
3. Пишем код, для отображения текста в два блока. (например берем большой текст и разбиваем его на две части и как вы смогли догадаться вставляем его в наши блоки (div'ы)).
Возникнет прихоть: " я хочу делать так, как в примере с лунолётом-1, хочу везде тыкать и вбивать циферки, что бы они выводились в левой части экрана." Тогда продолжим пункты.
4. Создаем в правом блоке, формочку в которой мы будем следить (конечно же с помощью моднейшей "фичей" сокетов) за состоянием поля ввода.
5. Как только вы начнете туда что то вводите, левая страничка будет об этом знать и сразу же начнет на это реагировать
(Всё это без перезагрузки страницы и лишних запросов к серверу).
Если возникнут вопросы или дополнения - пишите 
Сообщение отредактировал maker-rus - Среда, 13 Мая 2015, 18:16 |
|
|
| |
| Gudleifr | Дата: Пятница, 15 Мая 2015, 12:00 | Сообщение # 13 |
|
почти ветеран
Сейчас нет на сайте
| maker-rus, боюсь, все это не по теме. Вы, как и коллега Snake174 утверждаете, что обладая некоторой эрудицией, можно решить частную задачу. Это хорошо. Но в теме поднимается вопрос "общего решения". Т.е. какими свойствами, например, должны обладать "шаблонизаторы" (дались они Вам!), чтобы обеспечить "двустраничную синронизацию"? Кроме, конечно, "они должны обеспечивать двустраничную синронизацию". Насколько они должны быть "информационно замкнуты"? Возможно ли создание единого "интерфейсного элемента", или "синхронизация" должна включать в себя несколько "интерфейсных каналов"? Наконец, тупо, что удобнее: "обрезание по размеру", "масштабирование" или "прокрутка"? Можно ли их совмещать?
P.S. Короче, кто-нибудь задавался мыслью, что две страницы были бы удобнее, чем набор "супер навороченных адаптивно верстаемых всплывающих-выпадающих фигулек"? Чего для сиюминутной реализации этого не хватало?Добавлено (15 мая 2015, 12:00)
---------------------------------------------
Кстати, обсуждение оказалось не совсем бесполезным.
Я понял, что информация, представляемая на страницах должна быть организована иерархически, что позволит обойтись без прокрутки:
1) обрезание "по окну" можно реализовать с точностью до "узла дерева"
2) масштабирование - свертывание/разворачивание "поддеревьев"
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Сообщение отредактировал Gudleifr - Среда, 13 Мая 2015, 19:04 |
|
|
| |
| maker-rus | Дата: Вторник, 26 Мая 2015, 14:33 | Сообщение # 14 |
|
Гений
Сейчас нет на сайте
| Цитата Gudleifr (  ) maker-rus, боюсь, все это не по теме. Вы, как и коллега Snake174 утверждаете, что обладая некоторой эрудицией, можно решить частную задачу. Это хорошо. Но в теме поднимается вопрос "общего решения". Т.е. какими свойствами, например, должны обладать "шаблонизаторы" (дались они Вам!), чтобы обеспечить "двустраничную синронизацию"? Кроме, конечно, "они должны обеспечивать двустраничную синронизацию". Насколько они должны быть "информационно замкнуты"? Возможно ли создание единого "интерфейсного элемента", или "синхронизация" должна включать в себя несколько "интерфейсных каналов"? Наконец, тупо, что удобнее: "обрезание по размеру", "масштабирование" или "прокрутка"? Можно ли их совмещать?
P.S. Короче, кто-нибудь задавался мыслью, что две страницы были бы удобнее, чем набор "супер навороченных адаптивно верстаемых всплывающих-выпадающих фигулек"? Чего для сиюминутной реализации этого не хватало?
Добавлено (15 мая 2015, 12:00)
---------------------------------------------
Кстати, обсуждение оказалось не совсем бесполезным.
Я понял, что информация, представляемая на страницах должна быть организована иерархически, что позволит обойтись без прокрутки:
1) обрезание "по окну" можно реализовать с точностью до "узла дерева"
2) масштабирование - свертывание/разворачивание "поддеревьев"
Либо слишком толсто, либо Вы разучились читать. Объясню на картинках.
1. HTML страничка, в которой реализовано (о чудо, что за магия) две страницы, как в книге (поразительно правда?). (пришло время раскрыть сей фокус) Реализуется эта страничка следующим образом, берется 3 тэга <div>. Первый из них - контейнер. Два остальных - левая и правая страничка, которые находятся в контейнере. Как они стали страничками? Очень просто, правый <div> обтекает левый, обе эти странички выравниваются с помощью js или css, под размер экрана пользователя. (это и называется адаптивный дизайн). Все это отображение осуществлено (не догадались?) шаблонизатором.
2. Это правая страничка, на ней кнопки управления, другой страничкой. Написали в поле ввода, что-то, оно отобразилось на соседней страничке.
3. Это левая страничка, на ней текст или что-то еще, чем можно управлять с правой странички (п.2).
(воистину чудеса, вы так не думаете?)
4. Взаимосвязь элементов. Сервер одновременно и считывает информацию из базы данных (которая отображается на левой страничке) и отправляет ее в базу (с правой странички), это называется асинхронность, так же это реализуется с помощью (черной магии и орков) такой технологии как socket. После обработки запросов, сервер отдает информацию шаблонизатору, которую потом мы без лишних усилий отображаем на страничке, в режиме реального времени (то есть прямо на глазах, без перезагрузки).
Дополнительные элементы, вроде того, что бы вернуться к оглавлению или перейти на следующую страничку сугубо индивидуальны и размещаются, как будет удобно.
На этом (школа колдовства и чародейства заканчивается) я думаю закончим. Потому что, либо вы не можете выразить свою мысль, поэтому вас не устраивают предложенные варианты. Либо вы читаете между строк, либо вообще не читаете посты других людей, а это лишает смысла дальнейшее общения с вами.
ps. Вся эта реализация может быть помещена в один плагин.
Сообщение отредактировал maker-rus - Вторник, 26 Мая 2015, 14:36 |
|
|
| |
| Gudleifr | Дата: Вторник, 26 Мая 2015, 15:08 | Сообщение # 15 |
|
почти ветеран
Сейчас нет на сайте
| Цитата maker-rus ( ) Дополнительные элементы, вроде того, что бы вернуться к оглавлению или перейти на следующую страничку сугубо индивидуальны и размещаются, как будет удобно.
Как бы изначально это и не устраивает, ни "индивидуальность", ни "как будет удобнее", что на практике означает "заведомо неудобно". Других проблем в теме почти нет (кроме двух: как в случае заранее неизвестного количества информации ее резать? и как в одних и тех же терминах описать "процесс" для разных сред - html, Tk, Win?).
Реализовать любое "деление" - проблем нет, важно понять, "как делить". Как убрать эту самую "индивидуальность"?
Усложнить себе жизнь: "Тут надо две страницы и мы идем рожать шаблонизатор",- очень просто. А, вот, можно ли ее упростить: "А, так тут две страницы, значит и думать не над чем!"? (Как мы до этого говорили: "Так это стандартный CUA с его рамкой и менюшками!". Или как Раскин говорил: "Все есть доска объявлений!".
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Сообщение отредактировал Gudleifr - Вторник, 26 Мая 2015, 15:25 |
|
|
| |
| maker-rus | Дата: Среда, 27 Мая 2015, 01:50 | Сообщение # 16 |
|
Гений
Сейчас нет на сайте
| Цитата Gudleifr ( ) Как бы изначально это и не устраивает, ни "индивидуальность", ни "как будет удобнее", что на практике означает "заведомо неудобно". Других проблем в теме почти нет (кроме двух: как в случае заранее неизвестного количества информации ее резать? и как в одних и тех же терминах описать "процесс" для разных сред - html, Tk, Win?).
Не вопрос, есть система Drag and Drop. С помощью которой можно дать пользователю кнопочки, а он сам решит, что и куда он поместит. Резать по формату страницы, как в книгах. Я не знаю тонкостей прикладного программирования ( в т.ч c++, c#, winApi и тд.), потому что их надо учитывать, при прототипировании реализации.
Цитата Gudleifr ( ) Реализовать любое "деление" - проблем нет, важно понять, "как делить". Как убрать эту самую "индивидуальность"?
Реализация направляющих, с помощью которых можно делить: хоть вертикально, хоть горизонтально, хоть совмещать.
Цитата Gudleifr ( ) Усложнить себе жизнь: "Тут надо две страницы и мы идем рожать шаблонизатор",- очень просто.
Шаблонизатор не обязательный, а вспомогательный инструмент, который избавить страницу от говнокода. И без него можно реализовать всё то, что я описал.
Цитата Gudleifr ( ) А, вот, можно ли ее упростить: "А, так тут две страницы, значит и думать не над чем!"? (Как мы до этого говорили: "Так это стандартный CUA с его рамкой и менюшками!". Или как Раскин говорил: "Все есть доска объявлений!".
Как бы, реализаций данного велосипеда много, взять любую читалку или интерфейс приложения основанного на слоях. Поэтому придумывать новый велосипед в принципе не рационально.
|
|
|
| |
| Gudleifr | Дата: Среда, 27 Мая 2015, 02:30 | Сообщение # 17 |
|
почти ветеран
Сейчас нет на сайте
| Цитата maker-rus ( ) Шаблонизатор не обязательный, а вспомогательный инструмент, который избавить страницу от говнокода.
Если Вам проще в терминах шаблонизатора, то примерно так.
Допустим есть идеальный двухстраничный шаблонизатор и, тоже допустим, есть компьютерная программа (любая), которую можно заставить "быть сервером". Никакой связи между ними нет - допустим, их писали два разных человека, ничего не зная о целях и задачах друг друга.
Интересует:
1) Во-первых, хватит ли двух страниц для интерфейса любой разумно организованной программы?
2) Во-вторых, если на первый вопрос ответ положительный, то как организовать автоматическое приведение ввода/вывода любой программы в двухстраничный вид?
3) В-третьих, какими свойствами должен обладать язык обмена информацией между страницами? Достаточно ли одной-единственной операции "вызови вторую страницу с параметрами ..."?
4) В четвертых, если выкинуть наш шаблонизатор и оставить только два этих языка (приведения и обмена), то смогут ли они быть настолько полными, чтобы определить автоматическое создание любого другого шаблонизатора "хоть вертикального, хоть горизонтального, хоть совмещенного"?
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Сообщение отредактировал Gudleifr - Среда, 27 Мая 2015, 02:31 |
|
|
| |
| maker-rus | Дата: Четверг, 28 Мая 2015, 00:33 | Сообщение # 18 |
|
Гений
Сейчас нет на сайте
| Цитата Gudleifr ( ) Если Вам проще в терминах шаблонизатора, то примерно так.
Допустим есть идеальный двухстраничный шаблонизатор и, тоже допустим, есть компьютерная программа (любая), которую можно заставить "быть сервером". Никакой связи между ними нет - допустим, их писали два разных человека, ничего не зная о целях и задачах друг друга.
Интересует:
1) Во-первых, хватит ли двух страниц для интерфейса любой разумно организованной программы?
2) Во-вторых, если на первый вопрос ответ положительный, то как организовать автоматическое приведение ввода/вывода любой программы в двухстраничный вид?
3) В-третьих, какими свойствами должен обладать язык обмена информацией между страницами? Достаточно ли одной-единственной операции "вызови вторую страницу с параметрами ..."?
4) В четвертых, если выкинуть наш шаблонизатор и оставить только два этих языка (приведения и обмена), то смогут ли они быть настолько полными, чтобы определить автоматическое создание любого другого шаблонизатора "хоть вертикального, хоть горизонтального, хоть совмещенного"?
На сколько я понял, вас интересует вариант использования любой сторонней программы, интерфейс которой можно будет вывести на двух страничную форму, с помощью какого-то ореентированного, под эти цели api, если да, то вы изначально не верно описали свою идею и моя реализация просто не подходит сюда, за счет того, что она реализует другую цель.
По поводу того, что я понял, могу сказать так, если разработчики программ согласятся выработать какой-то стандартный api, что бы реализовать свой интерфейс, то с помощью этого api можно будет реализовать инструмент, который позволит делать интерфейс таким, каким вам захочется. Ну а пока, это можно обсуждать только в теории, без каких либо практических выводов.
Сообщение отредактировал maker-rus - Четверг, 28 Мая 2015, 00:34 |
|
|
| |
| Gudleifr | Дата: Четверг, 28 Мая 2015, 11:10 | Сообщение # 19 |
|
почти ветеран
Сейчас нет на сайте
| maker-rus, у Вас как-то все две крайности: либо теория, либо рисуем нужные кнопочки. Есть и промежуточный слой: программно-независимая концепция кнопочек. Например тот же CUA...
Цитата Как-то так:
Программа - организм. Смысловая часть - генотип. Принятые в твоей конторе оформительские соглашения - ограничения фенотипа. Зародыш развивается, заполняя своей биомассой структуру оконных форм (может - консоль, может - MDI). Гены лишь определяют ветвление в судьбоносные для зародыша моменты. Фенотип может быть представлен таблицей всех параметров всех окон, может списком отклонений стиля каждого окна от стандартного, может описанием совсем уж аппаратно-независимого дисплея.
Главное - минимум универсальности и максимум удобства.
Рассмотрим исторический пример: когда-то решили, что программам достаточно "write" и "read". И начали писать под это операционки с консолями/телетайпами. И хватало, ведь. Даже некоторый запас оставался: для рисования на экране картинки путем вывода большого количества строчек (ROGUE, STAR TREK) и даже для кусочка реалтайма путем оценки времени между началом и завершением "read" (OREGON TRAIL).
Потом "стандарт поплыл" - придумали "ввод без ожидания", управляющие консолью символы и т.д. Каждый писал свои резиденты и драйвера. Тогда XEROX и IBM придумали CUA - оконный интерфейс, базирующийся на окнах и сообщениях. И этого опять всем хватало: одна программа - одно окно, типовые менюшки, стандартные help-ы...
Пока не появился MS Excell, содержащий в себе не одно окно, а целую оконную систему...
Я не претендую на изобретение мирового стандарта. Просто, написав очередную FORTH-систему под Windows, я уперся в следующее:
Цитата Очевидно, что, кроме огромного запаса API-функций, -структур, -сообщений и -констант, программист вынужден выучить еще и некие API-парадигмы, малейший отход от которых приведет к немедленному краху интерфейса проекта. Попыток как-то упорядочить эти самые парадигмы не перечесть, но, грубо говоря, есть всего три варианта.
1. Попытка систематизировать все эти API-кубики "как есть", разрешив программисту самому собрать из них что-то полезное. В примерах применялся именно этот подход. Результат - плачевный. Всем понятно, что достигнуть тут хоть какой-то обозримости можно только за счет грубого упрощения - сведения всех (часто) используемых параметров в списки propertie-сов и event-ов.
2. "Игровой подход" - отрисовать красивый экран самому, классифицировать все области пространства на экране и "перемножить" на все возможные действия мышкой (клики, Dbl- и Right-клики, Move, Drag&Drop-ы...) и клавиатуры (по крайней мере, Shift, Alt и Ctrl), привязав к каждой клетке получившейся таблицы осмысленные API-парадигмы.
3. Подход, предложенный в "Комнатной модели",- привязать парадигмы к "желаниям" и "ожиданиям" пользователя, плюнув на "универсальность", вроде бы постулируемую Биллом.
Поиграв во все три подхода, я прикинул, что "две страницы" (разновидность третьего) дадут одновременно и "очевидный интерфейс", и "универсальность". Мне интересно, кто-нибудь доходил до чего-то подобного? Т.е. не "может нарисовать две страницы, если припрет", а замечал, что все его программы на экране в чем-то получаются схожими и это сходство заключается не в том, что рисовал один дизайнер, а в том, что из раза в раз, он делит информацию на какие-то фрагменты и отображает их на экране схожим способом (идет ли речь о текстовой консоли, ЭЛТ, Tk, HTML, CUA...), организуя из раза в раз одни и те же каналы обмена...
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
|
|
|
| |
| maker-rus | Дата: Четверг, 28 Мая 2015, 23:04 | Сообщение # 20 |
|
Гений
Сейчас нет на сайте
| Цитата Gudleifr ( ) maker-rus, у Вас как-то все две крайности: либо теория, либо рисуем нужные кнопочки. Есть и промежуточный слой: программно-независимая концепция кнопочек. Например тот же CUA...
По моему, это кажется только вам. Потому что всем мои примеры - практические, просто , мне пришлось в виду, огромного расстояния ваших знаний и новых технологий объяснять, что же я там написал. Вы начали возмущаться, а вдруг "мне не удобны навязанные автором кнопочки, "я же не такой как все"". Я и написал про Drag and Drop, что дать панельку пользователю, со всеми кнопочками и пускай он сам решит, что и куда он поставит. Cua, я так понял стандарт взаимодействия пользователя с программой. А вы устав от диктаторства Билли, решили сделать свой стандарт расположения окон, а так же их прототипирование и реализацию, причем на бестиповом языке программирования. Сейчас я все ближе и ближе, к тому, что бы понять о чем вы говорите. То есть вас интересует именно интерфейс, не как конкретный объект, а интерфейс как собственная реализация, стандарт. Свой стандарт, реализация взаимодействия пользователя с программой. Если я все же подобрался, к тому, что вы имели ввиду, то у меня есть несколько предложений по этому поводу. И по поводу двух страничной реализации интерфейса.
Как я это вижу это?
1.В структуру программ добавить некоторую панель, на которой будут находится все элементы управления, которые можно будет перетаскивать, назначать им горячие клавиши. А две страницы выдать под два глобальных и значимых объекта (например текст). Как их обрезать? По высоте экрана, а внизу вкладку окон. (прим. Одно окно включает в себя две страницы).
2. Как связать эти страницы? Ну например, установить какой-то прослушивающий объект и следить за состоянием каждой из страниц, как только страница меняется, объект сразу же об этом узнает и что то делает или передает.
ps. По поводу прикладного программирования, мне особо нечего сказать, если обсуждать теорию работы, таких приложений со "своенравным" стандартом взаимодействия, то всегда пожалуйста, но в реализации таковых на практике, увы.
|
|
|
| |
|
