Board.KolibriOS.org

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

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

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

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

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

Просто не бывает. Твое предложение имеет существенное ограничение - оно не выполняет условие:

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

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

Не будет ли это излишне расточительно для такой шустрой Колибри? И есть ли вообще нужна по 10 бальной шкале в этой функциональности?

На первый вопрос - нет не будет. Панель сейчас подобным образом использует функцию 9.
На второй вопрос - не я требовал этот функционал. Спрашивай у тех кто требовал в теме панели задач.

А почему нельзя передавать эту информацию (выводимую текстовую информацию, вместо теперешней) штатными средствами 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" потому, что хорошо было бы, чтобы данную разделяемую память создавало ядро операционной системы.

1) IPC медленный, не так существенно, но все же.
2) Твоя концепция требует большого количества лишних действий.
3) Панели и так есть чем заняться, вместо того чтобы быть сервером.

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

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

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

Так я и не собирался к ф.9 привязывать. Это я ее как пример привел. Отдельная функция с двумя подфункциями как ты и озвучил - так и задумывал. Может слишком размыто в первом посте написал, но я описывал внутреннюю реализацию, а не интерфейс.

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

640k

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

Цитата: "2) Твоя концепция требует большого количества лишних действий."

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

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

P.S.

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

P.S.2.

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