LINUX.ORG.RU

История изменений

Исправление www_linux_org_ru, (текущая версия) :

Вообще говоря текущие API создают такого рода «css», например в офтопике вызываем CreateBrush() и получившийся хэндл используем для отрисовки разного рода объектов. Вроде в иксах аналогично, парамтеры графических операций определяется в GC.

это не css — это даже жалким огрызком css назвать нельзя

css-ом это стало бы, если бы API для рисования знало, что вот сейчас наш CreateBrush/GC используется для рисования поля ввода — и пусть используется, а вот миллисекундой позже он же используется для рисования кнопки, поэтому надо его подменить на заданный юзером

Лайоут предполагает что определение фактических координат элементов будет происходить сервере?

да, на дисплее (это слово удобнее, чем сервер)

Сейчас это вроде бы всегда делают на клиенте (зная размер экрана/окна клиент сам расчитывает расположение).

афайк да

Чтобы не моргало нужно что-то другое использовать (flush, дисплей списки, буферизацию, итд).

соглашусь наверно с любым вариантом, особенно выделив двойную буферизацию... (тяжелый вздох) но ведь это уход еще дальше от хтмл

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

Исправление www_linux_org_ru, :

Вообще говоря текущие API создают такого рода «css», например в офтопике вызываем CreateBrush() и получившийся хэндл используем для отрисовки разного рода объектов. Вроде в иксах аналогично, парамтеры графических операций определяется в GC.

это не css — это даже жалким огрызком css назвать нельзя

css-ом это стало бы, если бы API для рисования знало, что вот сейчас наш CreateBrush/GC используется для рисования поля ввода — и пусть используется, а вот миллисекундой позже он же используется для рисования кнопки, поэтому надо его подменить на заданный юзером

Лайоут предполагает что определение фактических координат элементов будет происходить сервере?

да, на дисплее (это слово удобнее, чем сервер)

Сейчас это вроде бы всегда делают на клиенте (зная размер экрана/окна клиент сам расчитывает расположение).

афайк да

Чтобы не моргало нужно что-то другое использовать (flush, дисплей списки, буферизацию, итд).

соглашусь наверно с любым вариантом, особенно выделив двойную буферизацию... (тяжелый вздох) но ведь это уход еще дальше от хтмл

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

Исправление www_linux_org_ru, :

Вообще говоря текущие API создают такого рода «css», например в офтопике вызываем CreateBrush() и получившийся хэндл используем для отрисовки разного рода объектов. Вроде в иксах аналогично, парамтеры графических операций определяется в GC.

это не css — это даже жалким огрызком css назвать нельзя

css-ом это стало бы, если бы API для рисования знало, что вот сейчас наш CreateBrush/GC используется для рисования поля ввода — и пусть используется, а вот миллисекундой позже он же используется для рисования кнопки, поэтому надо его подменить на заданный юзером

Лайоут предполагает что определение фактических координат элементов будет происходить сервере?

да, на дисплее (это слово удобнее, чем сервер)

Сейчас это вроде бы всегда делают на клиенте (зная размер экрана/окна клиент сам расчитывает расположение).

афайк да

Чтобы не моргало нужно что-то другое использовать (flush, дисплей списки, буферизацию, итд).

соглашусь наверно с любым вариантом, особенно выделив двойную буферизацию (тяжелый вздох) но ведь это уход еще дальше от хтмл

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

Исходная версия www_linux_org_ru, :

Вообще говоря текущие API создают такого рода «css», например в офтопике вызываем CreateBrush() и получившийся хэндл используем для отрисовки разного рода объектов. Вроде в иксах аналогично, парамтеры графических операций определяется в GC.

это не css — это даже жалким огрызком css назвать нельзя

css-ом это стало бы, если бы API для рисования знало, что вот сейчас наш CreateBrush/GC используется для рисования поля ввода — и пусть используется, а вот миллисекундой позже он же используется для рисования кнопки, поэтому надо его подменить на заданный юзером

Лайоут предполагает что определение фактических координат элементов будет происходить сервере?

да, на дисплее (это слово удобнее, чем сервер)

Сейчас это вроде бы всегда делают на клиенте (зная размер экрана/окна клиент сам расчитывает расположение).

афайк да

Чтобы не моргало нужно что-то другое использовать (flush, дисплей списки, буферизацию, итд).

соглашусь наверно с любым вариантом, особенно выделив двойную буферизацию

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