Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Чт июн 22, 2017 3:00 pm

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




Начать новую тему  Ответить на тему  [ 20 сообщений ]  На страницу 1 2 След.
Автор Сообщение
СообщениеДобавлено: Ср апр 18, 2012 2:32 pm 
Неоднократно была высказана потребность в выводе произвольного текста, вместо названия исполняемого файла, в панели задач на кнопке отвечающей за приложение.

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

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

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


Вернуться к началу
   
СообщениеДобавлено: Ср апр 18, 2012 2:55 pm 
Не в сети
Moderator

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


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

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

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


Вернуться к началу
   
СообщениеДобавлено: Ср апр 18, 2012 3:52 pm 
Не в сети
Moderator

Зарегистрирован: Чт апр 08, 2010 8:11 pm
Сообщения: 264
Не будет ли это излишне расточительно для такой шустрой Колибри? И есть ли вообще нужна по 10 бальной шкале в этой функциональности?


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


Вернуться к началу
   
СообщениеДобавлено: Чт апр 19, 2012 12:16 pm 
Не в сети

Зарегистрирован: Ср сен 15, 2010 7:22 pm
Сообщения: 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" потому, что хорошо было бы, чтобы данную разделяемую память создавало ядро операционной системы.


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


Вернуться к началу
   
СообщениеДобавлено: Чт апр 19, 2012 1:19 pm 
Не в сети
Mentor
Аватара пользователя

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


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


Вернуться к началу
   
СообщениеДобавлено: Чт апр 19, 2012 2:43 pm 
Не в сети
Mentor
Аватара пользователя

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


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


Вернуться к началу
   
СообщениеДобавлено: Чт апр 19, 2012 3:56 pm 
Не в сети
Mentor
Аватара пользователя

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


Вернуться к началу
СообщениеДобавлено: Чт апр 19, 2012 4:19 pm 
Не в сети

Зарегистрирован: Пт фев 18, 2011 3:13 pm
Сообщения: 201
Цитата:
Может хватит 128 или 256 байт


640k :D


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

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


Вернуться к началу
   
СообщениеДобавлено: Чт апр 19, 2012 9:12 pm 
Не в сети

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

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

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

P.S.

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

P.S.2.

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


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

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


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

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


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

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