В Nautilus скоро появится вид списком (column-wise)

>а XSynchronize() на что?

она клиента подмораживает, а не window manager. От моргания не спасёт, да и не нужна толком. Всё равно ты уснёшь, и буфер иксам сплюнешь, когда пойдёшь в XNextEvent

>сейчас за себя. Не вдохновили меня gestures

когда привыкаешь, зело удобно. Я, например, жестами закладки переключаю, когда рука на мыше. И в браузере, и в текстовых редакторах. Метиться в закладку не надо. И окошко закрывать удобно. Мышу вниз, потом вправо. Как будто Ctrl+W нажал. Сообщение в IM тоже часто через жест шлю

>она клиента подмораживает, а не window manager. От моргания не спасёт, да и не нужна толком. Всё равно ты уснёшь, и буфер иксам сплюнешь, когда пойдёшь в XNextEvent

ммм. А как насчет такой схемы:

раз уж "резиновая рамка" находится в ведении WM - организовать задержку именно в WM, т.е.
1. делаем XConfigureWindow (ну или XResizeWindow)
2. ждем обновления
3. goto 1

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

из минусов - ресайз будет отставать от мышки, как в венде
из плюсов - пропадет лишний трафик между клиентом и иксами

т.е проблему иксов решить силами WM + тулкит

>Я, например, жестами закладки переключаю, когда рука на мыше.

кажется, я знаю ответ. У меня рука редко на мыше =)

Нда..., Джо Бишоп, ты зажигаешь как всегда. Гномо-Убунту люб, и поклонник "удобных систем с Гномом", ты наш... :)

Список постов :) :

1. >лучше бы сплит добавили, а не всякую %уету.

=

2. >понятно. Субж из-за этого такой тормозявый?

=

Следующие два поста вообще АПОФЕОЗ любви к Гному, и "удобных систем с оным" :)

3. >в тунаре такого тоже нет. Отсюда вывод - дело в кривизне. Вообще, гтк из себя весь трухлявый и из жопы написанный.

=

4. >>Тунар на ГТК написан

>отлично знаю. Именно поэтому у него тормозит первая отрисовка.

=

А вот так мы, ранее восхвалявшие Гном, его любим :)

5.

>>гтк патчить можно. А вот ты так и помрешь безмозглым =)

>есть ровно такое же (правильное, потому что моё) мнение насчёт тебя, фонатег ;)

=

6. >ага, патч размером с гтк. Если что через жопу написано, то легче не патчить, а писать заново. А так можно пи%деть долго, но изначальную уёб%ищность концепции уже не исправить.

=

А следующие вообще историческое событие: любитель Гнома и "удобных систем с оным", в любители Кед записался (причем, что забавно, в любители еще очень сырой, и довольно глючной версии Кед :) ), а ведь раньше как их хаял, Кеды то... :)

7. >кто бы говорил. Что-то я не припомню твоих аргументов на кде4 тормозит.

=

Или вот. Какая любовь к Гному... :) Какая ненависть к Кедам... :)

8. >нехай ооп на це городить, слишком сложно получается. Излишняя сложность приводит к тому, что программисты отвлекаются от алгоритмов на быдлокодирование. Вот и получается, что кде4 летает, а гном, сцуко, тормозит.

=====================

Джо Бишоп хватит ламеризм свой показывать а (ладно в винде-б только показывал, так ты в Линуксе его во всю кажешь)? Или мы опять "над Геком потешаемся"? :) Если да, то напомню: ГЕК ГНОМЕР, КАК И ТЫ :) , и какаята странная потеха, посему, выходит (гномера над гномером)... :) Я еще бы понял потеху надо мной, кадеешником... :)

>кажется, я знаю ответ. У меня рука редко на мыше =)

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

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

мышью можно работать? O.o

>мышью можно работать? O.o

Представь себе, сейчас нажал на кнопку "обновить", страница взяла и обновилась.. =)

Вы оба дебилы.

>Представь себе, сейчас нажал на кнопку "обновить", страница взяла и обновилась.. =)

это аналог Ctrl+r?

+1

>это аналог Ctrl+r?

Да.

ШО это за гаМно с горизонтальным скроллом? задолбали виндовизировать гном! кому хочется это мегасписок — идите в свой виндоКДЕ.

>раз уж "резиновая рамка" находится в ведении WM - организовать задержку именно в WM, т.е.

>1. делаем XConfigureWindow (ну или XResizeWindow)

>2. ждем обновления

>3. goto 1

В том и проблема, что «2. ждем обновления» реализовать невозможно. Ответа «я перерисовался» нет. События-то однонаправленные. Это только Window Property городить, в которой, например, время последнего обработанного ExposeEvent. Но производительность этой конструкции находится под сомнением ,)

>Ответа «я перерисовался» нет.

ты про ICCM забыл. Причем совершенно =)

>Но производительность этой конструкции находится под сомнением ,)

надо взять и попробовать. Я так думаю =)

> мышью можно работать? O.o

Исчо как :)

>ты про ICCM забыл. Причем совершенно =)

а чего его забывать? Ничего, связанного с перерисовкой, в ICCCM нет. Только фраза о том, что при получении ResizeEvent не надо ничего рисовать, а надо ждать Expose

>а чего его забывать? Ничего, связанного с перерисовкой, в ICCCM нет

можно сообщение послать WM'у. Мол, я готов, отпусти курсор =)

>можно сообщение послать WM'у. Мол, я готов, отпусти курсор =)

ты про resize-redirect чтоли? Так там "я готов" означает "готов ловить Expose и, моргая, перерисовываться" :)

>ты про resize-redirect чтоли?

нет. Я про следующую схему: когда WM захватывает мышь (при ресайзе или перемещении окна) - все вызовы XConfigureWindow() делаются из функции do_grab_event (например)

в настоящий момент при ресайзе XConfigureWindow вызывается на каждое MotionNotify, что вызывает волну пересчетов и перерисовок.

предлагаю следующую схему обработки ресайза в do_grab_event

дано: лист ожидания - список структур вида { Wid window_id; int width, height; }

если окно есть найдено в листе ожидания - устанавливаем курсор мышки на позицию соответствующую координатам из листа ожидания, return

окна нет в листе ожидания - заполняем структуру, запихиваем её в список, вызываем XConfigureWindow

в приложении (точнее в тулките) - при получении ConfigureNotify смотрим - есть ли там ресайз, перерисовываем окно, посылаем WM'у сообщение "готов". WM, получив это сообщение - удаляет окно из листа ожидания

т.е. ресайз производится синхронно. Нет волны событий, волны перерисовок и так далее. Есть замедление ресайза.

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

вероятно, придется сначала просить окно подготовить буфер соответствющего размера, а при получении сообщения "готов" - вызывать XConfigure, а приложение при получении запроса ConfigureNotify - будет просто бросать подготовленный .буфер на окно

в общем всё это - лишь способ избежать рассинхронизации действий между иксами и клиентом при ресайзе. Что вполне возможно даст более комфортную для восприятия картинку процесса =)

Выглядит здраво. На fdo это есть в каком-то виде?

>На fdo это есть в каком-то виде?

не в курсе.

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