Board.KolibriOS.org

Official KolibriOS board
It is currently Tue Apr 23, 2019 9:54 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 69 posts ]  Go to page Previous 1 2 3 4 5 Next
Author Message
PostPosted: Mon Aug 08, 2011 9:20 pm 
johnfound wrote:
А можно заменить ядро на Линукс и использовать X сервер как нормальные люди. ;) :D

Можно, но это будет не Колибри, а Линукс.


Top
   
PostPosted: Mon Aug 08, 2011 9:43 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1304
Serge
  • произвольное количество окон-- давно пора. 255 - слишком много, надо работать с хэндлами в списке, а не в массиве. Причем резать придется по живому; задача гораздо легче решается именно "внутри" ядра, чем "снаружи".
  • отрисовка элементов GUI в user-mode-- это еще зачем? юзер должен только сформировать и отправить ядру GUI-запрос (лучше - готовую очередь запросов), остальное не его дело.
  • отрисовка в битмап-- а сейчас с этим какие-то проблемы? если да - то чем модульность поможет?
  • использование акселерации-- тут без плотной работы с ресурсами ядра точно не обойтись. Только внутри, однозначно.
  • тайловая архитектура-- лучше чем пиксельная, согласен. И что? Если уж переходим на новую архитектуру - так все вместе. Иначе нужно будет разрабатывать 2 совершенно разных и несовместимых графических подсистемы.
  • композитный менеджер-- ?

johnfound wrote:
А можно заменить ядро на Линукс и использовать X сервер как нормальные люди. ;) :D

Вот-вот, именно к этому и придём.


Top
   
PostPosted: Mon Aug 08, 2011 10:00 pm 
Максим плодовит на офтопы. К сожалению это все на что он плодовит. :twisted: Потому пришлось снова выдрать кусок из оригинальной темы Масштабируемые шрифты


Top
   
PostPosted: Mon Aug 08, 2011 11:01 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
art_zh
GUI отлично рисуется в user-mode. Ещё лучше делать это в битмап. Вопрос стоит так: зачем делать в режиме ядра то, что можно сделать в приложении ? Перетаскивание и изменение размеров окна тоже реально делать в user-mode. Менять размер в самом приложении можно и сейчас. С перетаскиванием проблема - мешает обработчик в ядре. В этом случае нельзя сделать нестандартное окно с холдером справа/слева/снизу/в центре. В итоге имеем в ядре код, без которого легко обойтись -
  • изменение размеров, сворачивание в заголовок и перетаскивание окон мышкой
  • поддержка разных стилей окон, учёт размеров клиентской области
  • отрисовка окон
  • отрисовка и обработка кнопок.


Top
   
PostPosted: Tue Aug 09, 2011 1:37 am 
Offline

Joined: Tue Jul 26, 2011 11:03 pm
Posts: 62
art_zh wrote:
отрисовка элементов GUI в user-mode-- это еще зачем? юзер должен только сформировать и отправить ядру GUI-запрос (лучше - готовую очередь запросов), остальное не его дело.
Serge wrote:
GUI отлично рисуется в user-mode. Ещё лучше делать это в битмап. Вопрос стоит так: зачем делать в режиме ядра то, что можно сделать в приложении ?

Рисовать надо либо в драйвере видеокатрты либо на CPU(user mode прекрасно подходит) либо на любом другом подходящем устройстве которое в данный момент присутствует и поддержка которого тоже есть.

Вы одно не понимаете, самое главное - надо дать програмисту Стабильный API чтобы програмисту не пришлось ничего переписовать пару десятилетий. А то прям ничего писать нехочется зная что придётся переписывать частично, полностью или забрасывать kolibri.

Art_zh правильно предложил делать список, а какому устройству этот список скармливать зависит от того какая железка список лучше обработает. Вызываються API функции и делают новые записи в списке (потом даже, можно запросы на разные процессоры послать для отрисовки)

А если времени нету возиться со списками запросов и оптимизацией то хотябы "заверните" системные вызовы в user-mode функции как например call dword [Rectangle] call dword [LineTo] ...


Top
   
PostPosted: Tue Aug 09, 2011 2:39 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1304
ilya
я хочу реализовать GUI-буфер в динамической памяти приложения в виде односвязного списка с известной ядру точкой входа (возможно, с дополнительными перекрестными связями для перехода между отдельными элементами управления по клавише Tab).

Serge
Совершенно не представляю себе, как можно замутить такую штуку в 3-м круге. У ядра-то есть доступ к памяти приложения; а как будет твой менеджер отрабатывать, скажем, 50-ю функцию (чтоб ей, кстати, провалиться)?
Через буфер обмена?
Или будет хранить локальные фреймбуферы (битмапы) всех окон в себе?
Quote:
С перетаскиванием проблема - мешает обработчик в ядре.
Который плотно склеен не только с перебором стека, но и с чисто ядерными службами - списком переключения задач и очередью событий. И само собой - с HID-драйверами.


Top
   
PostPosted: Tue Aug 09, 2011 9:21 am 
Offline
User avatar

Joined: Tue Aug 25, 2009 4:45 pm
Posts: 794
Давайте сделаем блок-схему. Я конечно понимаю, что ни у кого нет желания, и тд и тп, но все понимают что это правильный путь. А потом, после баталий на поле схем и на поле блоков, можно переходить к воплощению.


Top
   
PostPosted: Tue Aug 09, 2011 10:39 am 
Offline

Joined: Fri Feb 18, 2011 3:13 pm
Posts: 201
Шучу, шучу. :) Я Х терпеть не могу!


Top
   
PostPosted: Tue Aug 09, 2011 10:43 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
art_zh

Совсем не понял твою идею GUI буфера. Можно подробнее ?

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

Самый простой вариант без композитного менеджера. Вся отрисовка производится программой в битмап. Функция Blit() немедленно отправляет результат на экран. Если хотим акселерацию, битмап должен создаваться системным вызовом. Оконный менеджер управляет прямоугольными областями на экране. От него требуется
  • создание и удаление окна
  • установка размеров окна
  • управление z-ордером окна и областями отсечения
  • определение событий активации и деактивации окна
  • отслеживание клавиатурного фокуса
  • отслеживание событий мыши
  • захват мыши окном
  • отрисовка курсора

GUI реализуется в DLL и тут каждый может выбрать себе по вкусу. Кому Motif, кому KDE :)


Top
   
PostPosted: Tue Aug 09, 2011 11:10 am 
Offline
User avatar

Joined: Tue Aug 25, 2009 4:45 pm
Posts: 794
Не, по вкусу GUI это хорошо, но Колибри все-таки маленькая система. И надо как-то его унифицировать, имхо.


Top
   
PostPosted: Tue Aug 09, 2011 12:05 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1304
Serge wrote:
art_zh
Совсем не понял твою идею GUI буфера. Можно подробнее ?
Щас нарисую.
Твоя схема вполне понятна. Кстати, ядерные элементы в ней-таки присутствуют :wink:
Один только вопрос:
Serge wrote:
Оконный менеджер управляет прямоугольными областями на экране. От него требуется ... управление z-ордером окна и областями отсечения
это очень важный момент: как думаешь реализовать экранную карту (отсечения)? Надеюсь, не на битовом поле?


Top
   
PostPosted: Tue Aug 09, 2011 12:32 pm 
Offline

Joined: Sun Nov 04, 2007 2:46 am
Posts: 390
art_zh,
Quote:
нужно выстроить генеральную линию
и
Quote:
я не соглашался
не соотносятся между собой. Вы самолично хотели бы выстроить генеральную линию? Тогда я процитирую другое:
Quote:
Каждый может делать свой вариант, а уже потом будет видно у кого лучше и стоит ли овчинка выделки.

Вы можете самолично сделать в своем бранче то, что Вы задумали, также, как я сейчас пилю рабочий стол и иже с ним (когда мне примерно в том же духе сказал mike.dld о том, что если мне хочется - делай и показывай).
Однако генеральную линию в основной ветке Вы сможете пилить только тогда, когда остальные признают, что то, что Вы сделали - лучше чем то, что имеется.
Кстати я лучше форканусь (если, конечно, буду уже что-либо более-менее программировать под КОС), чем соглашусь участвовать в написании жесткого монолитного ядра, собираемого из исходников под каждую конкретную машину (к чем, как я понял из общения с Вами ранее Вы и стремитесь).


Top
   
PostPosted: Tue Aug 09, 2011 1:01 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
art_zh

Текущая байтовая карта подходит для аппаратной акселерации. Так что это не самый плохой вариант. Другой вариант взять из X операции с регионами. У каждого есть свои недостатки и достоинства.

XVilka
Унифицированный API очень хорошо. У нас пока нет ни одной полновесной библиотеки контролов. Нужна одна такая системная.


Top
   
PostPosted: Tue Aug 09, 2011 5:11 pm 
Offline

Joined: Fri Feb 18, 2011 3:13 pm
Posts: 201
Serge wrote:
У нас пока нет ни одной полновесной библиотеки контролов. Нужна одна такая системная.


Кстати, я работаю над FreshLib, которая должна иметь полную библиотеку контролов, причем полностью портируемой. Дело идет медленно, но все-таки идет. Пока есть только порты для Win32 и Линукс, но безусловно будет и версия для Колибри.


Top
   
PostPosted: Tue Aug 09, 2011 5:17 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1304
Сверху - как сейчас.
Снизу - что предлагается.


Attachments:
GUI diagram.png
GUI diagram.png [ 26.24 KiB | Viewed 2587 times ]
Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 69 posts ]  Go to page Previous 1 2 3 4 5 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited