Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Пн май 29, 2017 12:38 pm

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




Начать новую тему  Ответить на тему  [ 40 сообщений ]  На страницу 1 2 3 След.
Автор Сообщение
 Заголовок сообщения: Proc_Lib.obj - процедурная библиотека
СообщениеДобавлено: Пт июн 18, 2010 2:31 pm 
Мне требуется сделать библиотеку для вызова OpenDialog. Однако создавать отдельную библиотеку для одной только программы не эффективно. Я думаю вполне логично создать процедурную библиотеку, куда и будут помещаться всевозможные процедуры для обработки промежуточных данных. Формат вызова будет подобен Box_Lib, который уже доказал свою состоятельность. Со временем в этой библиотеке можно разместить процедуры работы с сервером буфера обмена и много еще чего разного и нужного.


Вернуться к началу
   
СообщениеДобавлено: Пт июн 18, 2010 2:40 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Ср янв 27, 2010 10:59 am
Сообщения: 269
ИМХО идея отличная. Можно будет ее сделать как аналог kernel32l/ntdll/user32.dll

_________________
ушёл...


Вернуться к началу
СообщениеДобавлено: Пт июн 18, 2010 2:44 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Пт июн 27, 2008 3:22 pm
Сообщения: 971
А нельзя функции в *.mac файлах просто реализовать в самой box_lib.obj, добавив их в таблицу экспорта? В библиотеке при этом будут присутствовать и низкоуровневые и высокоуровневые функции.


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

Зарегистрирован: Ср янв 27, 2010 10:59 am
Сообщения: 269
Asper писал(а):
А нельзя функции в *.mac файлах просто реализовать в самой box_lib.obj, добавив их в таблицу экспорта? В библиотеке при этом будут присутствовать и низкоуровневые и высокоуровневые функции.

Я думаю, что Mario хотел сказать, что пора делать библиотеку, в которой будут процедуры для программ, избавляющие их от создания лисипедов. Например, надо перекодировать текст cp886 в cp1251, программе надо будет просто вызвать oem2ansi(str1, str2) и все. Это моё IMHO, конечно.

_________________
ушёл...


Вернуться к началу
СообщениеДобавлено: Пт июн 18, 2010 3:35 pm 
Asper
Box_Lib это все-таки библиотека графических компонентов. Не во всех программах они используются, а тут будут именно общие процедуры. В общем логическое разделение. Ну, и Nasarus правильно сформулировал.
В противном случае опять будем иметь одну большую библиотеку вместо ядра - от этого ведь и уходим постепенно.


Вернуться к началу
   
СообщениеДобавлено: Чт июл 01, 2010 10:39 am 
SVN r. 1509 - загрузил код библиотеки. Пока в нем только процедуры для вызова OpenDialog. Работоспособность проверил на zSea. Позже прикручу к другим приложениям.


Вернуться к началу
   
СообщениеДобавлено: Вт авг 24, 2010 12:13 pm 
SVN r. 1581 - доработана библиотека для поддержки сохранения размеров OpenDialog и центрирование его относительно текущего окна.


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

Зарегистрирован: Пн окт 19, 2009 10:58 am
Сообщения: 328
Mario писал(а):
Мне требуется сделать библиотеку для вызова 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) пока нет :wink:

Обсуждаем, предлагаем)


Вернуться к началу
СообщениеДобавлено: Вт окт 05, 2010 4:01 pm 
dunkaist
Было бы замечательно если вместе с реализацией ты приложил еще и примеры использования.
Цитата:
2.1. Мне на ум пришли две цели открытия: view и edit. Хотя извлечение архива, вроде, ни к одной из них не относится... В общем, здесь особо жду предложений

Вот тут я несколько не понял - какая разница для каких целей ассоциация? По идее нужен просто список ассоциаций показать пользователю, а он уж сам выберет и решит для чего ему это нужно.
Цитата:
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-строки ассоциаций

Т.е. размер буфера должно выделить и передать указатель само приложение? Не лучше ли будет библиотеке самой выделять память?


Вернуться к началу
   
СообщениеДобавлено: Вт окт 05, 2010 4:32 pm 
Не в сети
Mentor
Аватара пользователя

Зарегистрирован: Пн окт 19, 2009 10:58 am
Сообщения: 328
Mario писал(а):
Было бы замечательно если вместе с реализацией ты приложил еще и примеры использования.
Когда всё станет более-менее определённо и можно будет начинать прикручивать, залью на svn вместе с примерами.
Mario писал(а):
Вот тут я несколько не понял - какая разница для каких целей ассоциация? По идее нужен просто список ассоциаций показать пользователю, а он уж сам выберет и решит для чего ему это нужно.
Можно, конечно, показать весь список, а можно только два пункта: посмотреть, изменить. А на двойной клик (действие по умолчанию) искать сначала в view, а потом только в edit. Хотя, без целей даже проще. Посмотрим, что ещё скажут.
Mario писал(а):
Т.е. размер буфера должно выделить и передать указатель само приложение? Не лучше ли будет библиотеке самой выделять память?
Я делал по аналогии с функцией 70.1, а там "+16 = +0x10: dword: указатель на буфер, куда будут записаны данные, размер буфера должен быть не меньше 32 + [+12]*560 байт ". Если выделять, то надо не забыть освободить. А так написал "assotiations_buffer rb ****" и всё в порядке. Опять-таки, посмотрим...

Кстати, я подключаю libini из функции UFO.init, так так остальной части библиотеки libini не нужна. Может, перенести это в главную init-функцию? Тогда не придётся вызывать UFO.init.

p.s. UFO - Unified File Open functions


Вернуться к началу
СообщениеДобавлено: Вт окт 05, 2010 5:11 pm 
dunkaist писал(а):
Кстати, я подключаю libini из функции UFO.init, так так остальной части библиотеки libini не нужна. Может, перенести это в главную init-функцию? Тогда не придётся вызывать UFO.init.

p.s. UFO - Unified File Open functions

Это смотри сам - кода не вижу ничего не могу сказать конкретно.


Вернуться к началу
   
СообщениеДобавлено: Вт окт 05, 2010 8:30 pm 
Не в сети
Mentor
Аватара пользователя

Зарегистрирован: Пн окт 19, 2009 10:58 am
Сообщения: 328
Какая максимальная длина имени файла с полным путём?

Как лучше поступить: сразу выделить память под [__number_to_read] строк наибольшей длины, а потом сделать realloc или добавлять realloc'ом памяти до строки наибольшей длины перед чтением каждой следующей строки? В первом случае будет выделено MAX_NAME_LENGTH*[__number_to_read] байт на строки и ещё [__number_to_read]*4 на указатели. Во втором куча реаллоков.


Вернуться к началу
СообщениеДобавлено: Вт окт 05, 2010 8:41 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
Если это путь к программе то 1024 символа включая ноль.


Вернуться к началу
СообщениеДобавлено: Вт окт 05, 2010 8:48 pm 
dunkaist писал(а):
Какая максимальная длина имени файла с полным путём?

Serge писал(а):
Если это путь к программе то 1024 символа включая ноль.

Для 1024 байт имеется ввиду собственный путь к бинарнику. Размер же пути в 70-й функции теоретически не ограничен.

Serge ты так и не ответил, когда было введено ограничение и почему. Если это сделал не ты, то можно так и сказать.

dunkaist писал(а):
Как лучше поступить: сразу выделить память под [__number_to_read] строк наибольшей длины, а потом сделать realloc или добавлять realloc'ом памяти до строки наибольшей длины перед чтением каждой следующей строки? В первом случае будет выделено MAX_NAME_LENGTH*[__number_to_read] байт на строки и ещё [__number_to_read]*4 на указатели. Во втором куча реаллоков.

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


Вернуться к началу
   
СообщениеДобавлено: Вт окт 05, 2010 9:31 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
Mario

Ограничение появилось когда стали записывать путь к исполняемому файлу. svn #91 fs_execute. Это то, что нашел я. Может было что-то раньше.


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

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


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

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


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

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