Mario wrote:Мне требуется сделать библиотеку для вызова OpenDialog. Однако создавать отдельную библиотеку для одной только программы не эффективно. Я думаю вполне логично создать процедурную библиотеку, куда и будут помещаться всевозможные процедуры для обработки промежуточных данных. Формат вызова будет подобен Box_Lib, который уже доказал свою состоятельность. Со временем в этой библиотеке можно разместить процедуры работы с сервером буфера обмена и много еще чего разного и нужного.
В настоящее время КолибриОС может работать с множеством форматов файлов. Пусть это не всегда полноценная реализация потенциальных возможностей. Тем не менее, уже сейчас существует выбор: какой программой просматривать изображения, каким редактором открывать текстовые файлы. Думаю, в будущем этот список расширится. У каждого человека свои предпочтения, это касается и используемых программ.
Сегодня в КолибриОС есть больше одного файлового менеджера. Каждый из них использует собственный конфигурационный файл, из которого узнаёт какое приложение соответствует определённому типу файлов. Пользователь, желающий работать с *.??? файлами в программе B, вынужден редактировать конфиги всех ФМ и заменять стандартное приложение A на B. К тому же, в случае появления новой версии ФМ с, например, несовместимым конфигом, придётся в новом конфиге проделать все замены повторно. То же и в случае появления другого ФМ. В целом, этот вопрос актуален для многих программ, работающих с файлами, а файловые менеджеры просто наглядный пример.
Суть.
Предлагаю создать единую базу(файл) ассоциаций, к которой следовало бы "прислушиваться" выше очерченному кругу приложений. Один файл, задающий ассоциации, для всех приложений (в т.ч. для тех, которые ещё даже не появились в системе). Таким образом, будет достаточно один раз высказать свои предпочтения - и все программы сами "прислушаются". В дальнейшем, в базе можно будет хранить и пути к иконкам для определённых типов файлов. Для удобной работы с такой базой я берусь написать функции к Proc_Lib (кое-что уже есть).
Дальше идёт моё представление и вопросы о структуре файла и функциях.
Структура.
1. *.ini файл
Считаю, что это наилучший вариант, т.к. в библиотеке libini уже есть много нужных функций и она хорошо себя зарекомендовала
2. Секции вида [расширение.параметр]
Под "расширение" понимается, как обычно, 'txt', 'png' и так далее без кавычек. "Параметр" определяет цель открытия файла. Поясню: изображение можно просмотреть (view), а можно отредактировать (edit). Например, GIMP прекрасно работает с изображениями, но было бы странно пользоваться им для просмотра. Логично хранить такие ассоциации в разных секциях.
2.1. Мне на ум пришли две цели открытия: view и edit. Хотя извлечение архива, вроде, ни к одной из них не относится... В общем, здесь особо жду предложений
3. Ключи в секциях имеют вид 00, 01, 02, .., 99. Таким образом, количество ассоциаций на один тип файла на одну цель открытия ограничено числом 100. Этого, думаю, достаточно. Да и с такими строками/числами удобно работать прямо в 4-байтных регистрах.
Функции.
1. .get_keys_number - возвращает количество ключей(ассоциаций) в секции
2. .get_sections_number - возвращает количество секций во всём файле
3. .get_associations __section, __from, __number_to_read, __buffer - собственно, основная функция (уже написана). Возвращает в eax кол-во реально прочитанных ассоциаций. Записывает [__number_to_read] ассоциаций для секции [__section], начиная с номера [__from], в буфер [__buffer] в следующем виде:
3.1. Первые 4*[__number_to_read] байт отведены под указатели на прочитанные ассоциации. Далее идут ASCIIZ-строки ассоциаций
4. .set_associations - сохраняет ассоциации. пока в планах
5. .get_first __where_to_search - возвращает первую найденную ассоциацию при заданном порядке поиска. Обозначает "открыть хоть как-нибудь". Может быть полезна при работе с текстовыми файлами, т.к. уже есть редакторы, а просмотрщиков (типа юниксового less) пока нет
Обсуждаем, предлагаем)