Board.KolibriOS.org

Official KolibriOS board
It is currently Thu Jan 23, 2020 11:31 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 445 posts ]  Go to page Previous 1 2 3 4 530 Next
Author Message
PostPosted: Wed Sep 15, 2010 1:52 pm 
art_zh
Ты путаешь иконки с панелью, которую действительно надо выводить поверх всего - иконки же наоборот никогда не должны быть поверх.
Quote:
Хотя лично мне идея отрисовки иконок из отдельного приложения не нравится.
Этим должно заниматься ядро, а "менеджер иконок" мог бы лишь менять дефолтные настройки посредством редактирования системной базы данных

Не согласен, как раз приложение и должно этим заниматься. Это не ядерное дело. Все подряд тащить в ядро - мы уже отказались от таких замашек давно.

Serge
Все это конечно замечательно, и я уже не раз думал об этом, но нужно разбираться с работой с оконного стека.


Top
   
PostPosted: Wed Sep 15, 2010 4:34 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1380
Mario,
ничего я не путаю.

SysFn09 в сочетании с GS-графикой в принципе позволяют реализовать полноценный десктоп-менеджер в обычном пользовательском приложении.

и это плохо.

Mario wrote:
Не согласен, как раз приложение и должно этим заниматься. Это не ядерное дело. Все подряд тащить в ядро - мы уже отказались от таких замашек давно.

"тащить все подряд" здесь означает любое (в т.ч. вполне разумное) расширение системного сервиса?

Если таки-да, то похоже что не все "отказались от таких замашек": новые системные вызовы, предложенные Serge'м, фактически подразумевают внос "иконного" :wink: сервиса в ядро.

так лучше.

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Top
   
PostPosted: Wed Sep 15, 2010 6:02 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
art_zh wrote:
новые системные вызовы, предложенные Serge'м, фактически подразумевают внос "иконного" :wink: сервиса в ядро.


Нет, это скорее расширениe графических возможностей.

1. Регистр GS уже давно не нужен. Видеопамять мапится по адресу 0xFE000000. Я не вижу большого криминала в возможости для приложения рисовать по всему экрану, хотя это усложняет работу композитного менеджера. Но у нас нет композитного менеджера.

Mario

С оконным стеком это слабо связано. Больше с отрисовкой фонового рисунка. Если реализовать моё первое предложение то отрисовка позади всех окон будет конфликтовать с отрисовкой фонового рисунка. Гарантировать что Icon отрисуется после обновления фона сложно, значит на экране будут возникать артефакты. Поэтому лучший вариант совсем убрать из ядра отрисовку фонового рисунка в её нынешнем виде. Существующий сейчас код выполяет ресемплинг картинки при каждой отрисовке, что не очень оптимально, особенно если работаешь в Боше.

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


Top
   
PostPosted: Wed Sep 15, 2010 6:15 pm 
Serge
Я конечно уважаю твое мнение и заинтересованность, но давай вспомним как мы почти год назад обсуждали буфер обмена и где сейчас поезд? :lol:
Больной кстати по прежнему лежит и ждет - какую ногу ему отрежут...

У меня есть свои идеи и я готов реализовывать свои идеи. Да, на взгляд стороннего наблюдателя они могут быть не самыми оптимальными - но это мои идеи и я для начала хотя бы представляю как это реализовать.

Между тем мне очередной раз предлагается реализовать чьи-то идеи. Реализацию которых еще предстоит значительное время осмысливать - потому что это не крутилось в моей голове. А чужие мысли не так то просто уложить в свой поток рассуждений.

Учитывая что работаю я исключительно для своего удовольствия (Just for fun), то удовольствия от этого я не получу никакого. А значит моя заинтересованность стремится к нулю.

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

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


Top
   
PostPosted: Wed Sep 15, 2010 6:35 pm 
Offline
Kernel Developer

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

Я предлагал сделать буфер обмена в ядре, потому что это самый простой и надёжный способ. Но другим хотелось расшареной памяти.

В данном сучае предлагается освободить ядро от необязательного для него кода. Причём это не требует переделки оконной системы.


Top
   
PostPosted: Wed Sep 15, 2010 6:37 pm 
Еще раз для понимания - если ты готов сделать эту работу для ядра, то я могу воспользоваться. В противном случае я буду делать по своему, либо как вариант при значительном недовольстве других - опять ничего не буду делать.


Top
   
PostPosted: Wed Sep 15, 2010 7:22 pm 
Offline
Kernel Developer

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

Легко. Только надо с API определиться.

Для доступа к фону есть ф15.6 и 15.7.

Для вывода картинки использовать ф.65 с модификацией. В старшей половине esi указывать флаги отрисовки или номер слота для проверки.

Для проверки принадлежности пикселя функция, возвращающая значение из WinMapAddress для данной точки.

EDIT.

Есть другой вариант.

calculatescreen заполняет карту WinMap значениями для фонового рисунка.

Code:
;------------------------------------------------------------------------------
calculatescreen: ;/////////////////////////////////////////////////////////////
;------------------------------------------------------------------------------
;? Scan all windows from bottom to top, calling `setscreen` for each one
;? intersecting given screen area
;------------------------------------------------------------------------------
;> eax = left
;> ebx = top
;> ecx = right
;> edx = bottom
;------------------------------------------------------------------------------
        push    esi
        pushfd
        cli

        mov     esi, 1
        call    window._.set_screen
Если записать в esi не 1, а номер интересуещого нас слота, этот поток сможет рисовать на месте фоной картинки, что нам и требуется. Поток должен получать от ядра сообщения о необходимости перерисовать фон и сообщение об изменении фона. Для этого можно задействовать get_event, правда придётся работать в отдельном потоке (только отрисовка фона и обработка изменения фона. Никаких окон и пользовательского ввода).


Last edited by Serge on Wed Sep 15, 2010 7:43 pm, edited 1 time in total.

Top
   
PostPosted: Wed Sep 15, 2010 7:38 pm 
Serge
Quote:
Для доступа к фону есть ф15.6 и 15.7.

А как насчет того, что это будет жрать тем больше памяти, чем больше разрешение.
Например на современных мониторах вполне себе уже стоит разрешение 1920*1080? Это ведь 1920*1080*4=7,91 Мб. Ладно на современных компьютерах не жалко, но допустим на старом компьютере с объемом памяти в 8-12 Мб в текущем ядре можно отвести всего 4 Кб на фоновую картинку. А в новой системе получится 640*480 от 0,8 до 1,2 Мб (в зависимости от глубины цвета) не слишком ли большая жертва?
К тому же использование 15 функции не отменяет твоего-же тезиса о:
Quote:
Существующий сейчас код выполяет ресемплинг картинки при каждой отрисовке, что не очень оптимально, особенно если работаешь в Боше.

А для вот этого
Quote:
Для вывода картинки использовать ф.65 с модификацией. В старшей половине esi указывать флаги отрисовки или номер слота для проверки.

теперь еще и придется все программы перетрясти на предмет установки ESI полностью. Может стоит просто задействовать новый номер функции?
Quote:
Для проверки принадлежности пикселя функция, возвращающая значение из WinMapAddress для данной точки.

И это тоже поместить в новую функцию.


Top
   
PostPosted: Wed Sep 15, 2010 7:51 pm 
Offline
Kernel Developer

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

Если модифицировать calculatescreen (см. выше) то
нет необходимости в изменении ф65, хотя такой вызов и не помешал бы. Да и перерасхода памяти не будет. Полный доступ, рисуй как хочу.


Top
   
PostPosted: Wed Sep 15, 2010 8:00 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Итого получаются два новых вызова
set_background_thread() - делает текущий поток ответственным за отрисовку фоновой картинки.
Этот поток получает сообщения если надо перерисовать фоновую картинку.
get_thread_pos(x,y) - возвращает номер слота потока, которому принадлежит верхняя точка экрана с координатами x,y.


Top
   
PostPosted: Wed Sep 15, 2010 8:23 pm 
Quote:
set_background_thread() - делает текущий поток ответственным за отрисовку фоновой картинки.

Т.е. просто переносится код ядра в приложение?
Quote:
Этот поток получает сообщения если надо перерисовать фоновую картинку.

Как?
Quote:
get_thread_pos(x,y) - возвращает номер слота потока, которому принадлежит верхняя точка экрана с координатами x,y.

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


Top
   
PostPosted: Wed Sep 15, 2010 10:30 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
1) Да, весь код отрисовки фоновой картинки.
2) Поток выполняет обычный оконный цикл и получает сообщения о перерисовке. Или более перспективный вариант с получением событий через 68.14. Потребуется некоторый допил ядра, зато можно сообщать об изменении фоновой картинки другим приложением.
3)Сейчас все приложения, те же потоки Icon, самостоятельно определяют факт клика и ничего, работают. Ядро здесь совсем не причём.


Top
   
PostPosted: Thu Sep 16, 2010 10:08 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1380
Еще раз проIMHUю, что менеджеру иконок - место в нулевом круге, а не в третьем.
Вынос его в юзерспейс прорубит еще одну дыру в системной защите.

Но если уж вы так решили, то надо по крайней мере

1) повысить его в звании до десктоп-менеджера, и

2) присвоить ему статус специального процесса (незакрываемого, неперезапускаемого и недуплицируемого).

Иначе будет бардак.


Top
   
PostPosted: Thu Sep 16, 2010 10:11 am 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
art_zh wrote:
) присвоить ему статус специального процесса (незакрываемого, неперезапускаемого и недуплицируемого)

А если он упадет?

Одна хотелка по теме, если вдруг будет желание ее реализовать: подписи под иконками сделать длиннее, чем они могут быть сейчас. Длинные имена система поддерживает, а длинные названия программ - пока что нет :)


Top
   
PostPosted: Thu Sep 16, 2010 10:20 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1380
Sorcerer wrote:
art_zh wrote:
) присвоить ему статус специального процесса (незакрываемого, неперезапускаемого и недуплицируемого)

А если он упадет?


А если его сдуру закроют? :shock:

Или повесят второй (третий, десятый) ?


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 445 posts ]  Go to page Previous 1 2 3 4 530 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


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