хорошо, а как в новых Qt решается вопрос гонок, которые я описал? никак?

очень, очень убедительно — особенно тем, что никаких намеков на ход и смысл этих funny games не дается

все очень просто - иксы асинхронные, отсюда и проблемы со своевременным обновлением

хорошо, а как в новых Qt решается вопрос гонок, которые я описал? никак?

а Qt и не должна это решать, а насчет самой задачи - если пользователь жмакает в момент появления кнопки, то отрисовка за мгновение до этого ему ничем не поможет

все очень просто - иксы асинхронные, отсюда и проблемы со своевременным обновлением

но эта асинхронность сразу исчезает, как только Qt начинает в те же самые иксы гонять не положения контролов, а целые графические картинки, так?

но эта асинхронность сразу исчезает, как только Qt начинает в те же самые иксы гонять не положения контролов, а целые графические образы, так?

да, т.к. все размеры вычисляются и применяются за один «такт»

как и отрисовка, кстати

а Qt и не должна это решать, а насчет самой задачи - если пользователь жмакает в момент появления кнопки, то отрисовка за мгновение до этого ему ничем не поможет

пользователь жамкнул ДО появления изображения кнопки — читай внимательно

даже на нормальной сети пинг до америки 0.2 сек (если для кого-то это мгновение — то я приношу этому слоупоку искренние соболезнования), не говоря уже о том, что отдельные пакеты имеют право пропасть и быть пересланными через секунду скажем

а на gprs у меня бывают паузы по 24 секунды несколько раз в сутки (причем без потерь пакетов), но ведь архитекторов Супертулкита это не касается, так ведь?

пользовател жамкнул ДО появлния изображения кнопки — читай внимательно

а неважно, он может и во время - от дурака защиты нет

не говоря уже о том, что отдельные пакеты имеют право пропасть и быть пересланными через секунду скажем

миллионы людей регулярно используют teamviewer и т.п., и это в том числе «гуманитарии», раз у них проблем нет, то данный пример очевидно сильно притянут за уши

пользовател жамкнул ДО появлния изображения кнопки — читай внимательно

а неважно, он может и во время - от дурака защиты нет

а давай ты все-таки не будешь путать нормального, вменяемого пользователя и дурака?

миллионы людей регулярно используют teamviewer и т.п., и это в том числе «гуманитарии», раз у них проблем нет, то данный пример очевидно сильно притянут за уши

значит ты предлагаешь нормальным пользователям, в т.ч. мне, опуститься до уровня этих хомячков?

я не согласен

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

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

на самом деле я *реально* попадал не на такие, но на похожие гонки с неприятными последствиями

а давай ты все-таки не будешь путать нормального, вменяемого пользователя и дурака?

у «нормального, вменяемого пользователя» нет желания кликать где попало

значит ты предлагаешь нормальным пользователям, в т.ч. мне, опуститься до уровня этих хомячков?

им, в т.ч.тебе, очевидно есть чему научится у хомяков

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

есть кнопка «старт», в какой-то момент она становится «стоп», но кнопка одна и та же, чем тебе помогут иксы?

у «нормального, вменяемого пользователя» нет желания кликать где попало

а еще «сегодня в колбасе потребности нет!»

им, в т.ч.тебе, очевидно есть чему научится у хомяков

ну да, конечно, у них я могу научиться идиоме «жри что дают!»

есть кнопка «старт», в какой-то момент она становится «стоп», но кнопка одна и та же, чем тебе помогут иксы?

это не очень хороший стиль построения гуя, но и даже и в этом случае кнопка существует всегда, а не появляется внезапно

это не очень хороший стиль построения гуя

как и внезапное появление кнопок

но и даже и в этом случае кнопка существует всегда, а не появляется внезапно

это безусловно утешит пользователя, оборвавшего какой-либо процесс

это безусловно утешит пользователя, оборвавшего какой-либо процесс

я не знаю иксов и не могу сказать, передается ли вместе с эвентом инфа о той надписи, что была на кнопке *в момент клика*

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

1. уничтожить кнопку со старой надписью
2. создать кнопку с новой надписью на том же месте

(за исключением тех случаев, когда программер явно попросит именно менять надпись — тогда чморить можно и нужно будет именно его)

понятно, что еще лучше расдизейблить кнопку «стоп», или вполне допустимо создать ее, а не менять надпись

и еще, по старой памяти, при сабмите хтмл формы раньше среди параметров передавалась *также* и та надпись, что была на нажатой кнопке — но сейчас я попробовал и не вижу этого

Передаётся и сейчас.

глянул, не впечатлило. с таким быстродействием его надо в окна, там ему самое место.

Какой же ужос... Это же неюзабельное нечто! И они этим хвастаются?

Ты не понял, тут суть в названии дистрибутива и It's FRIDAY, FRIDAY!

Так еще не релиз же, вроде.

Ты не поверишь, но Wayland 1.0 давно вышел. Даже 1.1 вышел. :-)

Это просто по архитектуре говно, его сколько не допиливай, конфетки не будет.

Иксы - говно мамонта. Вяленый взлетит, сейчас он во вполне работоспособном состоянии, не хватает только драйверов. Будут драйверы - иксы можно будет выметать в /dev/null поганой метлой.

вы пишете какую-то ерунду. начнем с того, что никакие кнопки уже давно не рисуются в иксах.

А я вот согласен...

... с уважаемым www_linux_org_ru. Дело в том, что сходные проблемы, о которых говорит наш уважаемый коллега, описаны например в документе «Why X is not our ideal window system» by Hania Gajewska сотоварищи. Эти проблемв потенциально возможны на любом виджете - кнопке, меню, ... не важно. И да, на медленных линиях типа мопеда видел это воочию.

Это можно бы было решить timestampами - к отрисованному окну присобачивается timestamp, и все события приходят с timestampом последнего показанного окна.

только wayland проще поменять будет чем Х на мой взгляд .

Пену вытри, захлебнёшься скоро. Ты бы хоть почитал, почему мы имеем то, что имеем. Почему иксы сейчас это костыль на костыле, подпираемый костылями. Почему они так хорошо, что написали вторые «иксы» и запихали их в WM'а с композиторами.

В wayland?...

... Нет. Не проще. Можно долго (и нудно) объяснять почему, но проще было сделано в старых (до MacOS X) маках и оффтопе. Там небыло «виджетов» в общем и целом. Всё-таки «ресурсы», так или иначе линкованные с кодом, для локалхоста хороши. Но с ними, увы и ах, можно обломаться с бездисковыми терминалами и по сети расшарить приложение довольно гиморно.

Получается, что польза от wayland сомнительна, а вот вред уже сейчас очевиден.

Оггада...

... напейсали... запихнули... Ну да, ну да...

Были уже такие пейсателе-запихиватели. Проект назывался то ли микроиксервер, толи наноиксервер, не помню уже за давностью лет. Его тоже сгоряча да неподумав напейсали. И даже попытались запихнуть в... ядро.

Сейчас вот ядро 3.9.4 вижу, а энтого сервера там нет. И с чего бы это?

но мне все же бы хотелось услышать, как это решают в винде и вейланде

очевидно, никакой сети там нет, и вопроса гонок тоже нет. кнопки отрисовываются тоже сообщениями, которые никак не могут обогнать сообщения мыши. Принцип причинности соблюдается: сначала приходит сообщение с кликом, и юзер кликает по пусто, ПОТОМ уже приходит сообщение с кнопкой, которая рисуется там, где юзер кликнул. По этой(и не только) причине я и называю WinNT «однопользовательской».

Иксы - говно мамонта. Вяленый взлетит, сейчас он во вполне работоспособном состоянии, не хватает только драйверов. Будут драйверы - иксы можно будет выметать в /dev/null поганой метлой.

вот когда взлетит, тогда и посмотрим.

Пену вытри, захлебнёшься скоро.

бугага

я пока что весело и ненапрягаясь резвлюсь

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

одно другому не мешает, давай где почитать

Почему они так хорошо, что написали вторые «иксы» и запихали их в WM'а с композиторами.

ага, прямо зашибись как хорошо поиметь разобщенность графических серверов в добавок с говноархитектурой! а кстати, что мешает произойти вышеописанным мной гонкам во вторых иксах?

между тем, я придумал еще один, более реалистичный вариант этих гонок

Это можно бы было решить timestampами - к отрисованному окну присобачивается timestamp, и все события приходят с timestampом последнего показанного окна.

ну наконец-то до тебя дошло, что мой вопрос был не про то, кто отрисовывает градиентики на кнопочках (пусть это будет хоть Святой GDI Дух через libastral), а про event dispatch

только wayland проще поменять будет чем Х на мой взгляд .

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

2. возможно (хотя я точно не знаю), что Х вообще не нужно менять, т.к. там event dispatch предположительно идет через окна — и если тулкит не говно, он этим будет пользоваться

Принцип причинности соблюдается: сначала приходит сообщение с кликом, и юзер кликает по пусто, ПОТОМ уже приходит сообщение с кнопкой, которая рисуется там, где юзер кликнул.

ммм... это же вроде как раз несоблюдение принципа причинности с точки зрения юзера?

в документе «Why X is not our ideal window system» by Hania Gajewska

отличный док ( http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.8.2723&rep=rep1&... ), буду читать

еще раз убеждаюсь, что зачастую именно анонимусы на лор-е дают решающую инфу

судя по всему, оно было напечатано в Software—Practice & Experience - The X Window system archive, Volume 20 Issue S2, Oct. 20, 1990

т.е. нынешние пейсатели-архитекторы wayland-а должны были быть с ним знакомы — как-никак, 20 лет у них было на ознакомление

и что же, интересно, эти пейсатели-архитекторы придумали, дабы не повторять старых ошибок?

там тоже можно сделать подобное. ибо message pump thread не обязан делать торкать swapchain.

по мне так все решаемо timestampами. но в иксах это починить сложнее ибо протокол уже зафикирован.

btw, DRI2 это по сути делает то же самое, что и wayland в плане графики.

Принцип причинности соблюдается: сначала приходит сообщение с кликом, и юзер кликает по пусто, ПОТОМ уже приходит сообщение с кнопкой, которая рисуется там, где юзер кликнул.

ммм... это же вроде как раз несоблюдение принципа причинности с точки зрения юзера?

наоборот:

1. юзер кликает по пустому месту

2. юзер сдвигает окно

3. обрабатывается клик по пустому

4. окно сдвигается.

причина → следствие

1→3

2→4

проблема возникает, когда сообщение 1→3 обгоняет 2→4. Тогда юзер кликает в пустоту, но там ВНЕЗАПНО получается кнопка.

В случае монолитного KVM это можно легко обойти, но вот в случае сетевого и многопользовательского Xorg — возможны варианты. Также возможна и _принципиально_ неустранимая неоднозначность.

Да, всё верно...

...

нынешние пейсатели-архитекторы wayland-а должны были быть с ним знакомы — как-никак, 20 лет у них было на ознакомление

По этой причине я и не писал что этот материал был опубликован. :))) Своего рода скрытая издёвка.

и что же, интересно, эти пейсатели-архитекторы придумали, дабы не повторять старых ошибок?

Ничего. Тут либо отходить от виджетов и переходить на «идеи» из офтопа (и за это сразу закопают авторы всех без исключения наборов библиотек под Х — от Athena Project и до Qt, GTK+ и далее), либо... Всё как есть. Единственное что они ускоряют — локальный вывод. Ну и что? А ни чего. Остаётся только надеяться что при локальных вызовах и локальной же обработке (отрисовке), состояния гонок не будет. Нам же тут рассказывают что «сетевая прозрачность» суть сущность избыточная... :))) Так что, следующий шаг — использование локальных, прилинкованных к коду, «ресурсов приложения». :)))

Так что, следующий шаг — использование локальных, прилинкованных к коду, «ресурсов приложения».

правильно сделанные «ресурсы приложения» это скорее такой аналог html, который (при условии рендеринга графическим сервером) гонки устраняет

и вообще, я вижу правильный графический сервер именно в виде поправленного html (первый кандидат на исправление — это то, что html не обеспечивает окон бесконечной длины; ну и избыточную сложность надо убрать, а че-то типа css оставить)

Не-а... :D

по мне так все решаемо timestampами.

Одновременно рисуется 10 окон с 5-20 виджетами в каждом. Какие временные метки с каким окном и каким виджетом связаны? Или ещё веселее — а откуда считать момент, к которому привязать временную метку? Момент, когда виджет передан на отрисовку? Виджет это программный код, я напоминаю. Или когда он реально отрисовался? А как сервер узнает о том, что виджет отрисовался на экране?

Нет. Дело тут совсем не в том, что

протокол уже зафикирован.

Патчи к протоколам выпускались не раз и не два. Приложения старого типа могли бы использовать старую версию протокола, нового — нового типа. Не проблема — Х'ы расширяются (правда, отдельные, особо одарённые, называют это «костылями»). Проблема в том, что при существующем положении вещей, архитектуру Х'ов переплюнуть мудрёно больно. Не просто оно вот уже около 30 лет вот так живёт.

Тут либо отходить от виджетов и переходить на «идеи» из офтопа

это я не понял

(и за это сразу закопают авторы всех без исключения наборов библиотек под Х — от Athena Project и до Qt, GTK+ и далее),

и это тоже

Да...

... здесь я согласен полностью:

правильно сделанные «ресурсы приложения» это скорее такой аналог html, который (при условии рендеринга графическим сервером) гонки устраняет

Собственно, не зря многие тулкиты приходят по-маленьку, по-тихоньку к html. Могу сказать за Gnome (т.к. им пользуюсь), это здорово облегчает жизнь. По сути дела.

Здесь я имел ввиду...

... «ресурсы приложения». Т.е., не идеологию виджетов (программного кода, реализующего те или иные элементы интерфейса), а как это в виндах сделано. Там, помнится, какой-то «редактор ресурсов» был, «компилятор ресурсов». Зато всё шустренько рисовалось.

/* Эта идея, про приход к реализациям как в оффтопе, своего рода, полу-вброс. */

Одновременно рисуется 10 окон с 5-20 виджетами в каждом. Какие временные метки с каким окном и каким виджетом связаны?

там, по-моему, вполне реально этот вопрос решить, только конечно не timestamp-ами, а sequence point-ами

т.е. с каждой прямоугольной областью (выделенной аппликухой) связан свой sequence point, по умолчанию 0

когда аппликуха апдейтит область, она может sequence point не обновлять (это например подсветка при наведении мыши), либо обновить

теперь когда юзер и графический сервер генерируют эвент, к нему добавляются поля с sequence point-ами всех тех областей, к которым он принадлежит (sequence point берется естественно с точки зрения граф. сервера и значит юзера, а не тот, что выплюнут аппликухой и застрял где-то в сети)

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

фактически эти «прямоугольные области, выделенные аппликухой» это виджеты

но опять же, Великие Архитекторы Вейланда похоже срали на это

Там, помнится, какой-то «редактор ресурсов» был, «компилятор ресурсов».

я это все видел только краем глаза, но там че-то вроде типа html было — и если не совру, оно интерпретировалось виндой, а не прогой

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

и кстати, на хтмл некоторые даже делают бесконечные окна (тот же вконтакте.ру, скажем, раньше всякие поиски с результатом в 10 000 айтемов показывал именно так — ты окно крутишь вниз, и к нему подгружаются айтемы), но, понятно, делают это кто как сможет, а не стандартизированно

По своей идеологии...

... _почти_ да.

я это все видел только краем глаза, но там че-то вроде типа html было — и если не совру, оно интерпретировалось виндой, а не прогой

Там было своё описание ресурсов в текстовом виде. Т.е., каждому ресурсу (например, элементу меню), назначался свой уникальный для приложения ID.

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

Да. Такая линковка была последним шагом в сборке программы.

Для нашего (юниксового) случая...

... такой подход был бы лучше. Если учесть что html может быть передаваем на машинку пользователя по сети. Движок WebKit спокойно может быть используем в GTK+/Gnome приложениях (сам так его использую ибо удобно). Ну а приложение будет уже отображать не столько «ресурсы», сколько html. Ну и обрабатывать его (формы там, менюхи, скрипты, etc). Как-то так...

В винде нет RDP.

RDP есть только в некоторых версиях. Так что не универсально => неюзабельно.

У меня обратный личный опыт. Тут объективная оценка нужна.