Board.KolibriOS.org

Official KolibriOS board
It is currently Fri Dec 13, 2019 10:44 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 20 posts ]  Go to page 1 2 Next
Author Message
PostPosted: Wed Apr 18, 2012 2:32 pm 
Неоднократно была высказана потребность в выводе произвольного текста, вместо названия исполняемого файла, в панели задач на кнопке отвечающей за приложение.

Идея:
Вводится новая функция ядра и по умолчанию есть область памяти с указателями - 256 указателей по 4 байта, итого 1024 байт. Если указатель нулевой, то приложение не устанавливало для себя текстовую информацию (да-да, придется допиливать приложения - свистоперделки они знаете ли такие еще свистоперделки). Если есть указатель, значит приложение вызывало функцию и передало нужную текстовую информацию. Сам поток ядра эти данные обрабатывать не будет - они ему не нужны. При завершении приложения обнуляется указатель с уничтожением собственно самой области текста текущего потока. Такой подход позволит уменьшить затраты на необходимую память. Я думаю для одного приложения достаточно 4 Кб - (минимальный размер страницы выделяемой менеджером памяти, меньше нельзя). В процессе работы приложение может менять текст в произвольный момент времени. Панель задач будет при каждом выводе запрашивать текст заново.

Единственно я не уверен в оптимальности таких запросов - может есть более эффективная схема. Может имеет смысл ввести счетчик для каждого указателя, в котором будет номер - сколько раз обновлялся текст. С другой стороны хранить по 4 Кб на каждый поток, еще и в самой панели, слишком затратно - это удваивает количество необходимой для реализации памяти, вообще в системе (да, я жмот!).

З.Ы. Функция может послужить прообразом функции ядерного буфера обмена, но это так рассуждения вслух.


Top
   
PostPosted: Wed Apr 18, 2012 2:55 pm 
Offline
Moderator

Joined: Thu Apr 08, 2010 8:11 pm
Posts: 269
Может просто ввести в заголовок файла ещё одно поле с именем которое будет отображаться на панеле задач? Если этого поля нет выводить имя файла, если есть то его..и тогда старые программы переписывать не придётся...


Top
   
PostPosted: Wed Apr 18, 2012 3:03 pm 
Просто не бывает. Твое предложение имеет существенное ограничение - оно не выполняет условие:
Quote:
В процессе работы приложение может менять текст в произвольный момент времени. Панель задач будет при каждом выводе запрашивать текст заново.

Такие приложения как текстовые редакторы, файловые менеджеры, мультимеди плееры, просмотрщики графики - могут менять текст заголовка.

В моем варианте переписывать приложения не нуждающиеся в функции также не нужно - панель задач будет показывать имя запущенного файла (11 символов).


Top
   
PostPosted: Wed Apr 18, 2012 3:52 pm 
Offline
Moderator

Joined: Thu Apr 08, 2010 8:11 pm
Posts: 269
Не будет ли это излишне расточительно для такой шустрой Колибри? И есть ли вообще нужна по 10 бальной шкале в этой функциональности?


Top
   
PostPosted: Wed Apr 18, 2012 4:10 pm 
На первый вопрос - нет не будет. Панель сейчас подобным образом использует функцию 9.
На второй вопрос - не я требовал этот функционал. Спрашивай у тех кто требовал в теме панели задач.


Top
   
PostPosted: Thu Apr 19, 2012 12:16 pm 
Offline

Joined: Wed Sep 15, 2010 7:22 pm
Posts: 101
А почему нельзя передавать эту информацию (выводимую текстовую информацию, вместо теперешней) штатными средствами IPC :
- выделить общесистемную разделяемую память для помещения PID процессов, обслуживающих некоторые системные нужды посредством IPC, по стандартным местам (например имя "OS_IDLE"; размер - 4096байт (одна страница) );
- сервер @panel при загрузке (а оно загружается всегда) создаёт или использует уже существующую разделяемую память "OS_IDLE" и помещает (например, по [&OS_IDLE + @panel_pid_slot_in_os_idle_shm*4]) свой PID;
- приложение (если хочет изменить отображаемую текстовую информацию) один раз открывает разделяемую память (желательно её по завершению закрывать) и каждый раз читает PID @panel (например, по [&OS_IDLE + @panel_pid_slot_in_os_idle_shm*4]) и посылает IPC по этому PID стандартного вида.

@panel всю работу по содержанию таблицы указателей и динамического текстового буфера берёт на себя ...

P.S.

Я назвал разделяемую память "OS_IDLE" потому, что хорошо было бы, чтобы данную разделяемую память создавало ядро операционной системы.


Top
   
PostPosted: Thu Apr 19, 2012 12:55 pm 
1) IPC медленный, не так существенно, но все же.
2) Твоя концепция требует большого количества лишних действий.
3) Панели и так есть чем заняться, вместо того чтобы быть сервером.


Top
   
PostPosted: Thu Apr 19, 2012 1:19 pm 
Offline
Mentor
User avatar

Joined: Tue Jan 15, 2008 11:27 am
Posts: 752
Мои соображения по данному вопросу следующие:
1) Добавить в возвращаемый буфер ещё одно поле, в котором будет хранится смещение в буфере, начиная с которого идут данные для обмена (например, нуль-завершающаяся строка). Если значение 0 - буфера нет.
2) Чтобы создать буфер, нужно вызвать подфункцию. Если буфер есть, информация перезаписывается. При вызове 9-й функции копируется всё с буфером. Так как в документации ясно написано, что программа должна обеспечить буфер для приёма информации не менее 1 кбайта, то:
а) под буфер для обмена сообщений можно зарезервировать, например, 128 или 256 байт;
б) учитывая пункт "а" и так как в новодобавленном поле будет хранится смещение, то легко будет добавить и другие поля (я, например, не отказался бы от поля с pid родителя процесса).


Top
   
PostPosted: Thu Apr 19, 2012 1:57 pm 
Albom
Собственно я не понял соображения к моей идее или к тому что предложил FireWall?
В моем случае используется номер слота, а главный список приложению недоступен. Возвращается только текст.


Top
   
PostPosted: Thu Apr 19, 2012 2:43 pm 
Offline
Mentor
User avatar

Joined: Tue Jan 15, 2008 11:27 am
Posts: 752
Mario
Соображения к твоей идее. То, что предложил FireWall мне не понравилось. Слишком сложно в работе. Твоя идея намного лучше. Но тогда может не нужно привязываться к ф.9? Просто будет ещё одна функция с двумя подфункциями - записать буфер для слота и считать буфер для слота. Но если нужно только для панели (аналог caption окна) - то, думаю, лучше сделать как-то так, как я предлагаю (установка - ф.71.1).


Top
   
PostPosted: Thu Apr 19, 2012 2:48 pm 
Так я и не собирался к ф.9 привязывать. Это я ее как пример привел. Отдельная функция с двумя подфункциями как ты и озвучил - так и задумывал. Может слишком размыто в первом посте написал, но я описывал внутреннюю реализацию, а не интерфейс.


Top
   
PostPosted: Thu Apr 19, 2012 3:56 pm 
Offline
Mentor
User avatar

Joined: Tue Jan 15, 2008 11:27 am
Posts: 752
Значит, я тогда неправильно понял. Но теперь до меня дошло.
Кстати, 4к не много ли? Может, просто несколько страниц выделить для хранения буферов для всех слотов? Нужно определить, где ещё эта функция будет использоваться. Для хранения заголовка окна вряд ли 4к нужно. Может хватит 128 или 256 байт?


Top
   
PostPosted: Thu Apr 19, 2012 4:19 pm 
Offline

Joined: Fri Feb 18, 2011 3:13 pm
Posts: 201
Quote:
Может хватит 128 или 256 байт


640k :D


Top
   
PostPosted: Thu Apr 19, 2012 4:51 pm 
Albom wrote:
Кстати, 4к не много ли? Может, просто несколько страниц выделить для хранения буферов для всех слотов? Нужно определить, где ещё эта функция будет использоваться. Для хранения заголовка окна вряд ли 4к нужно. Может хватит 128 или 256 байт?

4 Кб не так уж и много. Можно еще чего нибудь передавать. Зато выделять и удалять просто. Есть места где имеет смысл экономить, но имхо не тот случай. К тому же если поток не пользовался функцией ни разу, то он и не потратит память под буфер.


Top
   
PostPosted: Thu Apr 19, 2012 9:12 pm 
Offline

Joined: Wed Sep 15, 2010 7:22 pm
Posts: 101
Цитата: "2) Твоя концепция требует большого количества лишних действий."

Возможно ... Основная проблема в том, как произвольное приложение может узнать PID @panel. Если бы для него ядром зарезервировать определённый PID - одной проблемой было бы меньше (по крайней мере никакой разделяемой памяти больше не надо было бы).

Что касается всего остального, то "лишние действия" всё равно будут. В Вашем. Mario, случае их будет выполнять ядро операционной системы. В предлагаемом мной варианте - все сложности переносятся в @panel, а также в библиотеку, (ибо открытие и опрос разделяемой памяти а также формирование сообщения будут весьма стандартными действиями).

P.S.

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

P.S.2.

На самом деле упираемся в недостатки IPC. Вот если бы владелец буфера IPC создавал его не безымянным, а именным (как это имеет место в разделяемой памяти), а произвольное приложение посылало сообщение не по PID, а по данному имени ...


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 20 posts ]  Go to page 1 2 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