Board.KolibriOS.org

Official KolibriOS board
It is currently Sun Dec 08, 2019 10:52 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 40 posts ]  Go to page 1 2 3 Next
Author Message
PostPosted: Fri Jun 18, 2010 2:31 pm 
Мне требуется сделать библиотеку для вызова OpenDialog. Однако создавать отдельную библиотеку для одной только программы не эффективно. Я думаю вполне логично создать процедурную библиотеку, куда и будут помещаться всевозможные процедуры для обработки промежуточных данных. Формат вызова будет подобен Box_Lib, который уже доказал свою состоятельность. Со временем в этой библиотеке можно разместить процедуры работы с сервером буфера обмена и много еще чего разного и нужного.


Top
   
PostPosted: Fri Jun 18, 2010 2:40 pm 
Offline
User avatar

Joined: Wed Jan 27, 2010 10:59 am
Posts: 269
ИМХО идея отличная. Можно будет ее сделать как аналог kernel32l/ntdll/user32.dll

_________________
ушёл...


Top
   
PostPosted: Fri Jun 18, 2010 2:44 pm 
Offline
User avatar

Joined: Fri Jun 27, 2008 3:22 pm
Posts: 988
А нельзя функции в *.mac файлах просто реализовать в самой box_lib.obj, добавив их в таблицу экспорта? В библиотеке при этом будут присутствовать и низкоуровневые и высокоуровневые функции.


Top
   
PostPosted: Fri Jun 18, 2010 2:55 pm 
Offline
User avatar

Joined: Wed Jan 27, 2010 10:59 am
Posts: 269
Asper wrote:
А нельзя функции в *.mac файлах просто реализовать в самой box_lib.obj, добавив их в таблицу экспорта? В библиотеке при этом будут присутствовать и низкоуровневые и высокоуровневые функции.

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

_________________
ушёл...


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


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


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


Top
   
PostPosted: Tue Oct 05, 2010 3:42 pm 
Offline
Mentor
User avatar

Joined: Mon Oct 19, 2009 10:58 am
Posts: 441
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) пока нет :wink:

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


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

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

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


Top
   
PostPosted: Tue Oct 05, 2010 4:32 pm 
Offline
Mentor
User avatar

Joined: Mon Oct 19, 2009 10:58 am
Posts: 441
Mario wrote:
Было бы замечательно если вместе с реализацией ты приложил еще и примеры использования.
Когда всё станет более-менее определённо и можно будет начинать прикручивать, залью на svn вместе с примерами.
Mario wrote:
Вот тут я несколько не понял - какая разница для каких целей ассоциация? По идее нужен просто список ассоциаций показать пользователю, а он уж сам выберет и решит для чего ему это нужно.
Можно, конечно, показать весь список, а можно только два пункта: посмотреть, изменить. А на двойной клик (действие по умолчанию) искать сначала в view, а потом только в edit. Хотя, без целей даже проще. Посмотрим, что ещё скажут.
Mario wrote:
Т.е. размер буфера должно выделить и передать указатель само приложение? Не лучше ли будет библиотеке самой выделять память?
Я делал по аналогии с функцией 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


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

p.s. UFO - Unified File Open functions

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


Top
   
PostPosted: Tue Oct 05, 2010 8:30 pm 
Offline
Mentor
User avatar

Joined: Mon Oct 19, 2009 10:58 am
Posts: 441
Какая максимальная длина имени файла с полным путём?

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


Top
   
PostPosted: Tue Oct 05, 2010 8:41 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Если это путь к программе то 1024 символа включая ноль.


Top
   
PostPosted: Tue Oct 05, 2010 8:48 pm 
dunkaist wrote:
Какая максимальная длина имени файла с полным путём?

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

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

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

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

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


Top
   
PostPosted: Tue Oct 05, 2010 9:31 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Mario

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


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