Исправление www_linux_org_ru, (текущая версия) :
Например если мы изменяем ширину окошка, приложение может рисовать скролбары или переносить текст в более узком окошке. Если мы хотим обрабатывать изменения размеров на дисплее, получается что скролбары должны целиком рисоваться на дисплее (проблемы когда они должны выглядеть кастомно) а текст весь отправлятся дисплею, чтобы тот его сам умещал в имеющемся окне c переносами строк.
вовсе не обязательно
дисплей может разумно реагировать даже в том случае, если он до конца не знает, что за виджеты лежат там у него
вот, скажем, юзер уменьшает размер формы; тогда дисплей
1. пока возможно, стесняет виджеты ближе друг к другу
2. когда это стало невозможно, пытается переформатировать те виджеты, которые он может (ну скажем обычный текстовый виджет)
3. когда это невозможно (скажем, в текстовом виджете используется охрененая система умной расстановки переносов), то дисплей тупо пририсовывает полосы прокрутки к форме (и прокручивает ее в случае, если юзеру это надо)
кстати, охрененая система умной расстановки переносов тоже может и должна работать *поверх* тупой системы расстановки переносов (которую можно вынести на дисплей), чтобы не тормозить на файлах по 10МБ
получается что скролбары должны целиком рисоваться на дисплее (проблемы когда они должны выглядеть кастомно)
кастомно *выглядящие* скроллбары — это тупой выпендреж, а вот скроллбары с некой доп. инфой можно перерисовывать в несколько этапов — т.е. на дисплее они перерисовываются просто, а потом уже аппликуха дорисовывает полезную инфу
_*и именно так в правильно написанном приложении происходит даже локально*_, когда приложению требуется куча времени, чтобы сгенерить доп. инфу, но можно быстро сгенерить обычные скроллбары
вот близкий пример: если многомегабайтный файл загрузить в правильный браузер, а потом отресайзить окно, то в начале он тупо покажет полосы прокрутки и даст прокручивать, а потом уже через десяток-другой секунд сделает рефлоу под новую ширину экрана и переделает полосы прокрутки
Исправление www_linux_org_ru, :
Например если мы изменяем ширину окошка, приложение может рисовать скролбары или переносить текст в более узком окошке. Если мы хотим обрабатывать изменения размеров на дисплее, получается что скролбары должны целиком рисоваться на дисплее (проблемы когда они должны выглядеть кастомно) а текст весь отправлятся дисплею, чтобы тот его сам умещал в имеющемся окне c переносами строк.
вовсе не обязательно
дисплей может разумно реагировать даже в том случае, если он до конца не знает, что за виджеты лежат там у него
вот, скажем, юзер уменьшает размер формы; тогда дисплей
1. пока возможно, стесняет виджеты ближе друг к другу
2. когда это стало невозможно, пытается переформатировать те виджеты, которые он может (ну скажем обычный текстовый виджет)
3. когда это невозможно (скажем, в текстовом виджете используется охрененая система умной расстановки переносов), то дисплей тупо пририсовывает полосы прокрутки к форме (и прокручивает ее в случае, если юзеру это надо)
кстати, охрененая система умной расстановки переносов тоже может и должна работать *поверх* тупой системы расстановки переносов (которую можно вынести на дисплей), чтобы не тормозить на файлах по 10МБ
получается что скролбары должны целиком рисоваться на дисплее (проблемы когда они должны выглядеть кастомно)
кастомно *выглядящие* скроллбары — это тупой выпендреж, а вот скроллбары с некой доп. инфой можно перерисовывать в несколько этапов — т.е. на дисплее они перерисовываются просто, а потом уже аппликуха дорисовывает полезную инфу
_*и именно так в правльно написанном приложении происходит даже локально*_, когда приложению требуется куча времени, чтобы сгенерить доп. инфу, но можно быстро сгенерить обычные скроллбары
Исходная версия www_linux_org_ru, :
Например если мы изменяем ширину окошка, приложение может рисовать скролбары или переносить текст в более узком окошке. Если мы хотим обрабатывать изменения размеров на дисплее, получается что скролбары должны целиком рисоваться на дисплее (проблемы когда они должны выглядеть кастомно) а текст весь отправлятся дисплею, чтобы тот его сам умещал в имеющемся окне c переносами строк.
вовсе не обязательно
дисплей может разумно реагировать даже в том случае, если он нифига не знает, что за виджеты лежат там у него
вот, скажем, юзер уменьшает размер формы; тогда дисплей
1. пока возможно, стесняет виджеты ближе друг к другу
2. когда это стало невозможно, пытается переформатировать те виджеты, которые он может (ну скажем обычный текстовый виджет)
3. когда это невозможно (скажем, в текстовом виджете используется охрененая система умной расстановки переносов), то дисплей тупо пририсовывает полосы прокрутки к форме (и прокручивает ее в случае, если юзеру это надо)
кстати, охрененая система умной расстановки переносов тоже может и должна работать *поверх* тупой системы расстановки переносов (которую можно вынести на дисплей), чтобы не тормозить на файлах по 10МБ
получается что скролбары должны целиком рисоваться на дисплее (проблемы когда они должны выглядеть кастомно)
кастомно *выглядящие* скроллбары — это тупой выпендреж, а вот скроллбары с некой доп. инфой можно перерисовывать в несколько этапов — т.е. на дисплее они перерисовываются просто, а потом уже аппликуха дорисовывает полезную инфу
_*и именно так в правльно написанном приложении происходит даже локально*_, когда приложению требуется куча времени, чтобы сгенерить доп. инфу, но можно быстро сгенерить обычные скроллбары