Quest Navigator для Windows

evp,

Если случайно организовать бесконечный цикл

Постарайся не организовывать бесконечные циклы.

Что касается зависших процессов, я посмотрю, что можно с этим сделать, когда вернусь к разработке.

Навигатор не поддерживает Модель Flexible Box.
…
почему так?

Навигатору всё равно на “Flexible Box” и прочие браузерные фишки. Навигатор просто использует готовый браузерный движок.

В версии Навигатора для Windows, используется движок Awesomium.

Если какая-то чисто браузерная фича не работает в Навигаторе, значит, скорее всего, она в принципе не работает в используемом браузерном движке. Обратись к авторам движка за разъяснениями.

У нас “внутри” Навигатора, кажется, 18-я версия Chrome.

Неправильно. Chrome - это браузер. Awesomium - это браузерный движок, у которого, вроде бы, есть некие родственные связи с Chrome.

Сказать, что “в Навигаторе есть Chrome”, это примерно то же, что сказать “Android сделан из Ubuntu, ведь они оба на основе Linux”. Они родственники, но не одно и то же.

Я немного упростил, но суть от этого не меняется.

Ок. Скажем так: Хром версии 18 (кстати, от 28 марта 2012(!) года) и Авесомиум нынешний используют одну и ту же версию AppleWebKit/535.19.

Actually Awesomium is not directly dependent on Chromium only; it’s a subset of Chromium - WebKit.

Что примерно означает: Авесомиум не зависит напрямую только от Хромиума; он - подмножество Chromium - WebKit.

С этим разобрались.

Но вопрос все равно остается без ответа. Не значит ли это, что поддержка flex должна присутствовать в Авесомиуме? Ведь мы все знаем, что она есть в этой версии ВебКит.

И это вовсе не “браузерная фича” - это одно из значений свойства display, наряду с такими значениями как display: none | block | inline | inline-block и т.д. Flex поддерживают всебраузеры. И отсутствие его поддержки сильно затруднит авторам создание нормальных мобильных интерфейсов. У нас ведь игры пишут не профи web-дизайнеры.

UPD: Я вот почему к Хрому 18 привязался, до сих пор все совпадало - все что поддерживает Хром 18 и особенности этой поддержки, баги и глюки. И это не удивительно, учитывая общий WebKit. А вот сейчас впервые я увидел, что то, что поддерживает Хром 18 не работает в Навигаторе. Если есть несоответствия браузеру - я сообщаю. Мне же неизвестно, где собака порылась - в Вебките или в Авесомиуме, а может в Навигаторе.

Мне же неизвестно, где собака порылась - в Вебките или в Авесомиуме, а может в Навигаторе.

Надеюсь, этот вопрос я разъяснил: Навигатор никак не влияет на поддержку CSS-свойств.

А что влияет? Шаблон влияет?
Пример:
CSS

.fixed-block {
position: fixed;
bottom: 30px; right: 50px;
}

QSP

USEHTML = 1 
*nl'<div class="fixed-block">Я не двигаюсь!</div>'
*nl'<img src="img/pic200x1500.jpg">'

Как будет вести себя fixed-block при прокрутке окна основного описания?

Согласно логике, блок будет изъят из основного потока и будет позиционирован относительно окна браузера. Предположение: окно браузера у нас соответствует окну Навигатора. Вывод: блок будет неподвижен относительно окна навигатора и на его положении не будет сказываться прокрутка контента в окне основного описания.

Практика: блок прокручивается вместе с основным описанием так, как если бы в его свойствах было записано position: absolute.

Однако, это не глюк Навигатора, так как, если мы вынесем блок “fixed-block” за пределы <div id=“qsp-wrapper-main”> и <div id=“qsp-scroller-main”> в gameAwesomium.html, то все станет на свои места - блок зафиксируется.

Что я могу из этого опыта вынести для себя? То, что по неизвестной мне причине я не могу использовать position: fixed в оформлении игры.

Может быть по сходной причине я не могу использовать и flex-box?

UPD: Вот нашел подтверждение (от 25/04/2013), что flex box поддерживается со старым синтаксисом в Awesomium. Почему это не работает у меня в Навигаторе?

evp,

А что влияет?

Влияет только сам движок Awesomium. Каким его сделали разработчики, так он и будет рендерить.

Как будет вести себя fixed-block при прокрутке окна основного описания?

В скине по умолчанию используется яваскриптовый скроллер, который привязывается к блокам “qsp-scroller-…”. Этот скроллер, естественно, влияет на вёрстку скроллящегося внутри него содержимого. Вызов сколлера осуществляется на уровне JS-API.

По-хорошему, фиксированные блоки не должны выводиться в окно описания, а должны быть размещены в HTML-файле шаблона.

Но если хочется вывести в окно основного описания, и скроллер в этом мешает, то убери скроллер - просто закомментируй открывающие и закрывающие теги блока с id “qsp-scroller-main”.

по неизвестной мне причине я не могу использовать

В Навигаторе практически нет документации. Он ещё даже не дошёл до релиза. Потому тебе и неизвестно, что там и как. Потому я и написал, что использовать только на свой страх и риск.

Огромное спасибо!

Могу только добавить, что таким образом мы лишимся возможности прокрутки вообще. :)

Решая эту проблему, я изменил

<div id="qsp-wrapper-main">

на

<div id="qsp-wrapper-main" style="overflow-x: hidden; overflow-y: auto;">

Теперь все в порядке. Но, по уже устоявшейся традиции, почти в порядке.
Чудес не бывает и Авесомиум в своем репертуаре: свойство overflow-x: hidden не работает. :)
Так что окончательный вариант:

<div id="qsp-wrapper-main" style="overflow: auto;">

пока что устраивает. Все почти как со скроллером, разве что вид полосы прокрутки другой, но это кажется просто решается стилями. Непонятно зачем вам понадобился скроллер?

evp,
чтобы делать скроллящиеся блоки.

Это очевидно. :)
Если добавляется прокрутка на JS, значит для этого есть причины. Чем не устраивает системная прокрутка?
Например, такая?
1.

Nex:

убери скроллер - просто закомментируй открывающие и закрывающие теги блока с id “qsp-scroller-main”.

2. CSS:

#qsp-wrapper-main { 
	overflow-y: auto;
	overflow-x: hidden; 
}
/* Скроллер (и полоса прокрутки) в главном окне описания */
#qsp-wrapper-main::-webkit-scrollbar {
    width: 4px;
}
 /* Полоса прокрутки */
/* #qsp-wrapper-main::-webkit-scrollbar-track {
    -webkit-box-shadow: inset 0 0 6px hsla(0,0%,50%,0.3); 
    -webkit-border-radius: 2px;
    border-radius: 2px;
} */
/* Движок-индикатор */
#qsp-wrapper-main::-webkit-scrollbar-thumb {
    -webkit-border-radius: 2px;
    border-radius: 2px;
    background: hsla(0,0%,50%,0.5); 
    -webkit-box-shadow: inset 0 0 2px hsla(0,0%,0%,0.3); 
}
#qsp-wrapper-main::-webkit-scrollbar-thumb:window-inactive {
	background: hsla(0,0%,50%,0.3);

evp,
инерция есть при прокрутке на мобильниках? Android, iOS, WP8?

Чтобы ответить на этот вопрос, надо, как минимум, иметь Навигатор для этих платформ.

evp,
я имел в виду твой вариант скроллера.

Nex,
я, кажется, чего-то не понимаю. Это не мой “вариант скроллера”. Это системный скроллер. Обычный скроллер Windows (для этого Навигатора, а для других платформ - их скроллеры с их обычным системным оформлением и свойствами, присущими платформе).

Может смутил его внешний вид а-ля MAC или мобильные платформы? Так это стало возможным только потому, что Авсесомиум использует WebKit. А в WebKit есть возможность определять внешний вид скроллера через CSS.

Поэтому, я полагаю, что если платформа подразумевает инерцию при скроллинге, то она должна быть. Наверное :)

“Настольный” Windows (с мышкой) такой инерции не подразумевает. Поэтому я и ответил, что для ответа на ваш вопрос надо бы иметь Навигатор для платформ, о которых вы спрашивали. :)

Вот внешний вид скроллера без CSS-оформления:

evp,
без инерции на тач-устройствах неудобно. Поэтому был использован яваскриптовый скроллер.

Где-то её не было, видимо на Андроиде, сейчас уже и не вспомню.

Каждое архитектурное решение диктовалось жизненной необходимостью на тот момент. Возможно, в настоящее время это уже можно сделать по-другому. А может, и нельзя.

Nex,
проверил на ноутбуке с тачпадом - инерция есть. Уж не знаю чья это заслуга, системы или драйвера тачпада.

Дайте версию Навигатора для WP8 :rolleyes: Проверю на нем.

evp,
её нет.