Никоим образом. Это свойства экрана, на котором программа вынуждена жить.
Свойство экрана - отображать информацию, свойство системы - ее формировать. Поэтому программно должны задаваться (динамические) размеры панелек и всего, что есть на экране.
ЦитатаGudleifr ()
На момент создания "шаблонизатора" число и размер объектов неизвестны - это свойства загружаемой информации.
Почему же неизвестны? Любой "шаблонизатор", который выводит какую то информацию, оперирует значениями или условиями заданными создателем.
ЦитатаGudleifr ()
Совершенно избыточно (за исключением отлова системного сигнала Resize). Зачем слушать, если листание производится явными действиями пользователя?
Явными действиями? А как система определит эти явные действия? Или вы предполагаете, что в системе будет чип, который реализует телепатию? Любое действие, должно прослушиваться, что бы корректно его отработать. Если система не прослушивает, какие то действия, то она не не знает, какие вы там явные действия выполняете. Пример, обычный монитор, сколько по нему пальцем не води, ничего не изменится (только пыль сотрешь), но если в этот монитор добавить сенсорную панель, которая будет прослушивать нажатия, то и система будет реагировать на эти нажатия.
Сообщение отредактировал maker-rus - Пятница, 29 Мая 2015, 22:48
Эти "некоторые панели" и "какие-то объекты", очевидно, должны удовлетворять некоторым требованиям. Независимо от того, "сколько на экране кнопочек". Какими?
Само собой, это размер занимаемой области и позиции, для размещения. (исключение объект для прослушивания, он встроен в программу) То есть некоторые объекты имеют больший размер, а некоторые меньший, но совокупность всех этих кнопочек не должен превышать, какой-то процент от занимаемой области. И само собой это доступность панелей и кнопочек непосредственно как с клавиатуры, так и с мышки, то есть возможность использовать панели клавиатурой, не затрагивая мышь и наоборот. Прослушивающий объект должен соответствовать только одному требованию - слушать (получать состояние страничек).
maker-rus, у Вас как-то все две крайности: либо теория, либо рисуем нужные кнопочки. Есть и промежуточный слой: программно-независимая концепция кнопочек. Например тот же CUA...
По моему, это кажется только вам. Потому что всем мои примеры - практические, просто , мне пришлось в виду, огромного расстояния ваших знаний и новых технологий объяснять, что же я там написал. Вы начали возмущаться, а вдруг "мне не удобны навязанные автором кнопочки, "я же не такой как все"". Я и написал про Drag and Drop, что дать панельку пользователю, со всеми кнопочками и пускай он сам решит, что и куда он поставит. Cua, я так понял стандарт взаимодействия пользователя с программой. А вы устав от диктаторства Билли, решили сделать свой стандарт расположения окон, а так же их прототипирование и реализацию, причем на бестиповом языке программирования. Сейчас я все ближе и ближе, к тому, что бы понять о чем вы говорите. То есть вас интересует именно интерфейс, не как конкретный объект, а интерфейс как собственная реализация, стандарт. Свой стандарт, реализация взаимодействия пользователя с программой. Если я все же подобрался, к тому, что вы имели ввиду, то у меня есть несколько предложений по этому поводу. И по поводу двух страничной реализации интерфейса.
Как я это вижу это? 1.В структуру программ добавить некоторую панель, на которой будут находится все элементы управления, которые можно будет перетаскивать, назначать им горячие клавиши. А две страницы выдать под два глобальных и значимых объекта (например текст). Как их обрезать? По высоте экрана, а внизу вкладку окон. (прим. Одно окно включает в себя две страницы). 2. Как связать эти страницы? Ну например, установить какой-то прослушивающий объект и следить за состоянием каждой из страниц, как только страница меняется, объект сразу же об этом узнает и что то делает или передает.
ps. По поводу прикладного программирования, мне особо нечего сказать, если обсуждать теорию работы, таких приложений со "своенравным" стандартом взаимодействия, то всегда пожалуйста, но в реализации таковых на практике, увы.
Если Вам проще в терминах шаблонизатора, то примерно так. Допустим есть идеальный двухстраничный шаблонизатор и, тоже допустим, есть компьютерная программа (любая), которую можно заставить "быть сервером". Никакой связи между ними нет - допустим, их писали два разных человека, ничего не зная о целях и задачах друг друга. Интересует: 1) Во-первых, хватит ли двух страниц для интерфейса любой разумно организованной программы? 2) Во-вторых, если на первый вопрос ответ положительный, то как организовать автоматическое приведение ввода/вывода любой программы в двухстраничный вид? 3) В-третьих, какими свойствами должен обладать язык обмена информацией между страницами? Достаточно ли одной-единственной операции "вызови вторую страницу с параметрами ..."? 4) В четвертых, если выкинуть наш шаблонизатор и оставить только два этих языка (приведения и обмена), то смогут ли они быть настолько полными, чтобы определить автоматическое создание любого другого шаблонизатора "хоть вертикального, хоть горизонтального, хоть совмещенного"?
На сколько я понял, вас интересует вариант использования любой сторонней программы, интерфейс которой можно будет вывести на двух страничную форму, с помощью какого-то ореентированного, под эти цели api, если да, то вы изначально не верно описали свою идею и моя реализация просто не подходит сюда, за счет того, что она реализует другую цель. По поводу того, что я понял, могу сказать так, если разработчики программ согласятся выработать какой-то стандартный api, что бы реализовать свой интерфейс, то с помощью этого api можно будет реализовать инструмент, который позволит делать интерфейс таким, каким вам захочется. Ну а пока, это можно обсуждать только в теории, без каких либо практических выводов.
Сообщение отредактировал maker-rus - Четверг, 28 Мая 2015, 00:34
Как бы изначально это и не устраивает, ни "индивидуальность", ни "как будет удобнее", что на практике означает "заведомо неудобно". Других проблем в теме почти нет (кроме двух: как в случае заранее неизвестного количества информации ее резать? и как в одних и тех же терминах описать "процесс" для разных сред - html, Tk, Win?).
Не вопрос, есть система Drag and Drop. С помощью которой можно дать пользователю кнопочки, а он сам решит, что и куда он поместит. Резать по формату страницы, как в книгах. Я не знаю тонкостей прикладного программирования ( в т.ч c++, c#, winApi и тд.), потому что их надо учитывать, при прототипировании реализации.
ЦитатаGudleifr ()
Реализовать любое "деление" - проблем нет, важно понять, "как делить". Как убрать эту самую "индивидуальность"?
Реализация направляющих, с помощью которых можно делить: хоть вертикально, хоть горизонтально, хоть совмещать.
ЦитатаGudleifr ()
Усложнить себе жизнь: "Тут надо две страницы и мы идем рожать шаблонизатор",- очень просто.
Шаблонизатор не обязательный, а вспомогательный инструмент, который избавить страницу от говнокода. И без него можно реализовать всё то, что я описал.
ЦитатаGudleifr ()
А, вот, можно ли ее упростить: "А, так тут две страницы, значит и думать не над чем!"? (Как мы до этого говорили: "Так это стандартный CUA с его рамкой и менюшками!". Или как Раскин говорил: "Все есть доска объявлений!".
Как бы, реализаций данного велосипеда много, взять любую читалку или интерфейс приложения основанного на слоях. Поэтому придумывать новый велосипед в принципе не рационально.
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
Tymonr, ничего сверх сложного, сам хотел сделать подобную для игры в GURPS по интернету. Но есть пара НО если собираться с друзьями и играть это очень весело, круто и запоминаемо, если же играть с посторонними то получится такая ситуация (Игрок1: я тебя убиль, Игрок2: нет это я тебя убиль!) Проще говоря maker-rus, будет ли контроль? Кто будет ограничивать действия и выступать в роли рассказчика(ГМа) человек/машина/страус/игроки?
Цитатаmaker-rus ()
Понятно, что свобода не будет безграничной или что не будет никакого контроля, все это будет и это понятно, что бы не появлялись игроки: убиватор3000 или нагибатор2001, с супер-мега способностями, которые они себе придумают. Подразумевается, что будет совет(модераторы), который и будет следить за правилами игры.
ЦитатаTymonr ()
Ordan, об этом я и говорю. Разумеется, технически реализовать чат не сложно. А вот как-то интеллектуально взаимодействовать с живыми людьми - уже забота побольше
Наверно я поэтому здесь и пишу о своей игре, что бы узнать, кто как думает по этому поводу, может у кого будут идеи какие, одному такой проект тяжело тянуть.
ЦитатаЭргалон ()
Идея бесполезна. Это я говорю вам как игрок в подобные игры на протяжении 9 лет. 1) Во первых никто не станет играть. Только если друзья. Т.к найти людей, желающих играть в ролевых чатах попросту нет. Раньше их было много, сейчас их всё меньше и как правило они тусят на форумах. Тебе понадобится лет 5, чтобы в игре ежедневно играло хотя бы человек 10. 2) Чтобы люди играли в ролевом мире, его надо прописать ОТ и ДО, что займет в свою очередь очень много времени, а что самое интересное, едва ли труды будут вознаграждены. Знаю по своему опыту. 3) Такие чат-игры существуют уже давно. Со своими законами и правилами. И что ты думаешь?) Они все пустеют и витают в облаках и до них никому не хочется тянуться. И только некоторые из них пытаются поддерживать онлайн, при этом отдают 50% реального дня. Готов ты уделять ежедневно проекту по 12 часов и это после того, как всё сделаешь и всё распишешь?)
Это хорошо, что здесь отписался опытный игрок. Может быть поделитесь своим опытом, что вам нравилось больше всего в таких играх? 1. Мне стало интересно по этому поводу и я решил раскрыть возможности поисковой системы, можете проверить: ролевые игры форум, я получил список из 506к запросов. Ткнул случайную ссылку, посмотрел когда было написано последнее сообщение: 23 Апр 2015 17:19:01 - ***, всего там было 172 сообщения (в одной теме). Поэтому тут спорный момент. 2. Спорно, что бы люди играли, им нужна цель, нужна мотивация, нужен стимул двигаться и развиваться, нужен интуитивный интерфейс, нужны подарки и плюшки, нужно общение. Историю, как я уже говорил пишут игроки, в результате глобальных событий. 3. Я приводил пример вроде бы похожих, это mud игры и форумные ролевые игры. Первые на сколько я понял вымерли, вторые успешно существуют. Если соберусь реализовывать проект, то я буду уделять проекту столько времени, сколько будет необходимо.
Не забывайте отписываться, делитесь мнениями, вопросами, если есть что написать - пишите, буду очень рад!
Добавлено (26 мая 2015, 13:56) --------------------------------------------- up
Сообщение отредактировал maker-rus - Суббота, 25 Апреля 2015, 01:29
maker-rus, и...?! Все давно известно и пройдено... Так почему не пересчитать на пальцах "основные моменты"? Как эти Ваши "замечательные фичи" и прочие "шаблонизаторы" обеспечивают "адаптивную верстку"? И нафига нам последняя?
Например, в примере выше (второй рисунок - "Лунолет") параметры нажатой ссылки в левом фрейме честно передавались как параметры вызова CGI-калькулятора в правом. Откуда, в общем-то и родилась идея свести обмен между страницами к некоторому виду "синхронизации".
На примере двух web страниц, "синхронизиющихся" между собой, почему бы не сделать через сокет? И просто получать состояние одной страницы в другой или наоборот. По поводу "читалки", там реализация намного проще, просто вместо последовательного показа листов, показывается склейка. То есть просто меняют расположение листа, следующий лист теперь не на новой строке, а на той же, что находится и предыдущая страница. По поводу соизмерения и iframe, вы наверно отстали от технологий, раз до сих пор предлагаете табличную верстку. Использовать в 2015 году iframe, считаю бесчеловечным. Для этого, всего, давно придумали шаблонизаторы, которые позволяют подключать другие странички в шаблон. Про адаптивную верстку вы, наверно, так же не слышали.
ЦитатаGudleifr ()
но не нечто полезное для измышления новых интерфейсов.
ios - диалоги в вк, в две страницы, не не слышал такие "уникальные" интерфейсы, делящие область на две части давно существуют и давно применяются. Примеров масса, начиная от web-ide, заканчивая онлайн - web-читалками и блогами (ghost - nodejs редактирование в левой части, в правой готовое отображение в realtime).
maker-rus, половину из того, что он хочет даже на этих конструкторах не сделать в два клика. А к той же Unity, к примеру, есть куча китов. (Конечно, к конструкторам есть ещё больше таких китов и уроков по ним, но суть в том, что такое можно сделать на очень многих инструментах)
когда вы приходите в магазин и просите булку хлеба, вам предлагают автомобили? Так зачем человеку, который ищет конструктор, предлагать то, что ему не нужно?
PopovD, у нас не средние века, если скачаешь что-то не то, просто удалишь. На костре тебя не сожгут.
сомнительный аргумент
Цитатаharmoxyne ()
Я могу сказать, что на UE4 можно сделать то, чего тебе хочется. Можно на Unity, Game Maker, Scirra, Cocos, Godot, XNA, даже на чистом WinAPI можно умудриться.
тогда, хотя-бы, читать научитесь, потому что человек ищет КОНСТРУКТОР, А НЕ ДВИЖОК! По первому посту видны его знания в этой области и что можно ему посоветовать. PopovD, начни с Game Maker, Scirra - они самые популярные. В них можно задать свои события или использовать уже имеющиеся. На этом сайте есть раздел посвященный конструкторам игр (посмотреть). Загляни туда, посмотри, может что-то придется по душе.
Сообщение отредактировал maker-rus - Четверг, 07 Мая 2015, 20:00
Жанр: Ролевая игра. Какой движок\конструктор собираетесь использовать:? Пространство: 2D Вид: отсутствует. Описание(сюжет): У этой игры нет истории, как таковой. Всю историю пишут игроки, об этом чуть позже я подробно распишу. Начну, пожалуй с того, что это браузерная чат-игра, то есть логично, что действия персонажа будут происходить в браузере. Игра данной реализацией будет похожа на dnd, а если точнее ближе к mud играм. То есть все возможные действия будут вводится посредством текстового поля в чат. После регистрации игрок попадет в игру(чат), где начинает играть, а то есть попадает в комнату для новичков, где бот будет рассказывать о возможностях игры и как играть в общем, после этого его перекинет в один из городов (случайно), где игрок будет развиваться. То есть игрок будет иметь ту рассу, класс и тд, который он укажет, а не заранее придуманный. То есть, есть мир, где множество уникальных героев, проживающих в разных городах, то есть история игры будет зависеть от игроков. Каким образом? Как в жизни, игрок живет, как то самоутверждается, становится популярным и этим самым влияет на историю, сражается против других игроков, или со своими товарищами из клана сражаются против другого клана. Опять же игра полнится слухами, историями об самых известных игроках - это и есть история игры, которую сами игроки и пишут. Понятно, что свобода не будет безграничной или что не будет никакого контроля, все это будет и это понятно, что бы не появлялись игроки: убиватор3000 или нагибатор2001, с супер-мега способностями, которые они себе придумают. Подразумевается, что будет совет(модераторы), который и будет следить за правилами игры. Так же будет реализована страничка, где будет находится история игры. Что на ней будет? Ну например: клан такой то объявил войну такому то клану, или какие то глобальные события. Развитие будет происходить следующим образом: игрок появляется в городе, без ничего. Все остальное развитие будет зависеть от окружающих игроков или от самого игрока. То есть игрок может стать вором, а потом мафиози, если кто то из игроков создаст мафию, может станет рыцарем и зарубит массу драконов. То есть игрок пойдет по тому развитию, на которое у него хватит фантазии. Короткий сюжет: 1. Игра в которой игрок придумывает себе героя полностью, от умений, до истории героя. 2. Развитие определяется самим игроком и сформировавшимся миром. 3. Будут миссии заранее предопределенные, для старта игрока. 4. Глобальные события будут отражаться на странице с историей игры. 5. Все предметы которые можно получить будут предопределены. 6. Игра имеет сходства с dnd и mud играми. Особенности игры: Перечислены в полном и кратком сюжете. Кто требуется в команду: на данный момент никто.
Если есть вопросы, или критика, пишите не стесняйтесь, идея на самом деле сырая, поэтому любые рассуждения приветствуются!
Сообщение отредактировал maker-rus - Четверг, 10 Ноября 2016, 23:14
Я тут не очень всё понял. Ты имеешь в виду что надо передавать файл по 8Кб? P.s Извини за мою тупость Можете мне разъяснить всё по подробнее, или пример какой нибуть дать...
Тебе наверное хотели сказать, что сначала отошли клиенту размер данных, которые отправляешь, а потом отправляй файл кусочками.На стороне клиента проверяй, равен ли текущий объем данных - отправляемому, если нет, то продолжаешь слать данные пока количество принятых данных не станет равно отправленным. Размер кусочков, которые ты можешь отправлять за один раз написали для примера, ты можешь использовать свой(размер).
Сообщение отредактировал maker-rus - Суббота, 14 Марта 2015, 03:08
