Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Сб окт 20, 2018 3:23 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 16 сообщений ]  На страницу 1 2 След.
Автор Сообщение
СообщениеДобавлено: Пт ноя 24, 2006 4:42 pm 
Не в сети
Site Founder
Аватара пользователя

Зарегистрирован: Вс авг 08, 2004 8:55 am
Сообщения: 689
Увидел, что в теме про ANIMAGE зашёл разговор про то, что нужно десктоповое окно, и решил вставить свои 5 копеек, без оффтопа. Просто дело в том, что я уже обдумывал подобные изменения, и даже начинал их реализовывать.

Моё предложение заключается во введении пяти "уровней" для окон. Эти уровни будут определять положение окон относительно друг друга и поведение окон при их активации. Уровни такие:
  1. WLEVEL_BELOWALL [-2] - окна, всегда находяшиеся под всеми другими окнами; используется для программы десктопа, и только для неё
  2. WLEVEL_BOTTOMMOST [-1] - окна, всегда находяшиеся под обычными окнами и всеми их перекрывающими; используется для десктоповых виджетов
  3. WLEVEL_NORMAL [0] - обычные окна; используется для создания обычных окон в текущем их состоянии
  4. WLEVEL_TOPMOST [+1] - окна, всегда находяшиеся над обычными окнами и всеми ими перекрываемыми; используется для создания окон, которые всегда на виду (не придумал, каких, но я думаю всем ясно, для чего нужен этот уровень)
  5. WLEVEL_ABOVEALL [+2] - окна, всегда находяшиеся над всеми другими окнами; используется для создания панели задач, всплывающих меню и подсказок, хранителей экрана
Окна нижнего уровня не могут перекрывать окна более высокого уровня, что учитывается при создании, активации и перемещении окон. Инача говоря, окно может перекрывать другое окно только если оно находится на более высоком или на том же уровне что и другое окно.

Есть, однако же, и некоторые проблемы. Оконная подсистема требует более глубокой, если не полной, переработки. Данные об окнах и процессах нужно разделить и группировать в отдельных структурах, не смешивая. Предусмотреть возможность создания более одного окна в пределах одного потока, создание дочерних окон, соответствующие изменения в событийной системе (ещё одна моя идея - реализовать очередь событий и возвращать при вызове функций 10, 11, 23 не только идентификатор события в EAX, но заодно и дополнительные данные события в ECX, EDX, EBX; связано это с предпложением, что при вызове упомянутых функций регистры общего назначения не используются ни в одной программе, однако при описанном подходе мы уменьшаем количество системных вызовов при возникновении события, убирая те, которые получают дополнительную информацию; также этот подход позволяет лучше гарантировать, что данные с момента возникновения события и до его обработки не изменятся на стороне ядра).

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

_________________
in code we trust


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пт ноя 24, 2006 5:26 pm 
Интересно как в эту модель укладываются полноэкранные приложения - например, игры...


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Пт ноя 24, 2006 6:04 pm 
Не в сети
Site Founder
Аватара пользователя

Зарегистрирован: Вс авг 08, 2004 8:55 am
Сообщения: 689
Вероятно, что или они выбирают уровень WLEVEL_ABOVEALL, или в ядре (драйвере) появляются функции, с использованием которых все графические функции выключаются для остальных приложений и оставляются только для текущего, а само окно помещается и висит всё время на переднем плане. В принципе, в Windows драйвер воспринимает OpenGL/DirectX окно, развёрнутое на весь экран, как отдельный случай и что-то там изменяет для ускорения отрисовки.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пт ноя 24, 2006 9:01 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3951
mike.dld
События лучше делать в виде структур. Это упростит программирование на C. И на асме если занять 4 регистра придётся ставить pushad что не улучшает код.
По событиям у меня уже есть наработки, хотел занятся ими после курсоров.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн ноя 27, 2006 4:56 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
Цитата:
1. WLEVEL_BELOWALL [-2] - окна, всегда находяшиеся под всеми другими окнами; используется для программы десктопа, и только для неё
2. WLEVEL_BOTTOMMOST [-1] - окна, всегда находяшиеся под обычными окнами и всеми их перекрывающими; используется для десктоповых виджетов

Если интересно, могу сказать, что происходит с десктопом в винде. Есть собственно окно десктопа, его оконный цикл находится в недрах ядра (для NT-семейства - win32k.sys). Есть окно Explorer'а, оно находится внизу всех окон и при активации не перекрывает остальные окна, потому что Explorer вызвал специальную функцию SetShellWindow из user32.dll. Наконец, иконки и контекстное меню рабочего стола представляют собой часть десктопа и управляются тем же потоком от explorer.exe.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн ноя 27, 2006 5:06 pm 
Не в сети
Site Founder
Аватара пользователя

Зарегистрирован: Вс авг 08, 2004 8:55 am
Сообщения: 689
В принципе, часть из того что ты написал я знал, но даже если бы я знал всё - не стал бы оглядываться на Windows. Мы и так уже пытаемся всеми силами сделать из Менуета Колибри, зачем теперь делать из Колибри Виндовс? Формулировка, возможно, несколько неправильная, но в принципе релизация предложенная мной возможно является даже более широкой, чем в Windows. В любом случае, это лишь предложение для обсуждения. И при твоём подходе в виде функции, и при моём без этой дополнительной функции (точнее, функция будет но она просто будет устанавливать уровень) возможность создания одинаково функционального десктопа никуда не пропадает.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн ноя 27, 2006 5:07 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
А я не предлагаю подход как в Windows. Я просто информирую, как это сделано там.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн ноя 27, 2006 5:12 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Пт янв 27, 2006 3:06 pm
Сообщения: 1071
Мне интересно, а панель и меню будут входить в десктоп? Просто уже пару дней над ними бьюсь, а тут такой разговор возник... ;)


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн ноя 27, 2006 5:24 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Чт май 19, 2005 4:43 pm
Сообщения: 896
>Мне интересно, а панель и меню будут входить в десктоп? Просто уже пару дней над ними бьюсь, а тут такой разговор возник...

Я вот тоже думаю над тем,как реализовать панели в Колибри. Ведь панель должна работать и в окне, и за его пределами(если размер меню превышает размер окна или вложенные меню выходят за предел окна).Причём, чтобы небыло миганий,необходимо перерисовывать не окно,а только подменю панели(стрирать старое и рисовать новое в новом месте).
Как реализовать рисование тиких меню пока не совсем понятно.То,что с приоритетами надо всё связать - это понятно. А вот как сделать рисование меню - через прямой доступ к графике или как-то по другому.Пока не понятно как.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн ноя 27, 2006 5:49 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3951
andrew_programmer
Меню придётся рисовать напрямую. Сохранять экран как для курсоров а потом востанавливать.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн ноя 27, 2006 6:01 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Чт май 19, 2005 4:43 pm
Сообщения: 896
>Меню придётся рисовать напрямую

Всмысле через селектор gs реализовать доступ к экрану ?

>Сохранять экран как для курсоров а потом востанавливать.

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


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн ноя 27, 2006 7:25 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3951
Если рисовать меню только в окне то можно и через gs. Но если меню должно выходить за рамку окна то надо менять display_data иначе другие программы будут затирать меню. Так что без ядра не обойтись.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн ноя 27, 2006 7:39 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3951
Если получится сделать такую систему окон то меню будет особым типом окна. Программа создает меню. Система сохраняет эркан и display_data и модифицирует display_data под меню. Когда программа закрывает меню система востанавливает display_data и экран. Похоже на классы окон со стилем CS_SAVEBITS в Win.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Вт ноя 28, 2006 10:44 am 
Мда, чем дальше в лес, тем толще партизаны - это же надо до такой степени усложнить систему...


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Вт ноя 28, 2006 12:00 pm 
Не в сети

Зарегистрирован: Пн май 01, 2006 10:12 pm
Сообщения: 349
иначе система никак... не усложнишь здесь, в другом месте вылезет боком


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 16 сообщений ]  На страницу 1 2 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB