OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 14:03

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу Пред.  1, 2
Автор Сообщение
СообщениеДобавлено: Воскресенье, 08 Январь, 2023 17:51 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Иван Денисов писал(а):
Ну давайте пока решим имеющимися средствами, пусть там и будет некая сложность в коде, но не будем менять API.
я так и сделал, но проблема в том, что мне это не нравится. it smells. поэтому и тему создал.

Иван Денисов писал(а):
У меня ещё был вопрос про удаление папок. Так как если не такую папку создал, то её надо удалить прямо из файлового браузера.
честно говоря, мне не очень нравится эта идея. по одной простой причине: как средствами BBCB сделать модальный диалог? насколько я помню — это невозможно без кривохаков. а модальные диалоги нужны для всяческих срочных вопросов. системные мне категорически не нравятся, это выглядит ужасно. я могу, конечно, нарисовать оверлей с вопросом поверх окна браузера (наподобие того, как менюшки сделаны), но с таким хаком идея мне нравится ещё меньше.

вообще, какая была идея, как быть с модальными диалогами-вопросами? в смысле, как предполагается это решать?

Иван Денисов писал(а):
В Linux папка как файл удаляется обычным удалением для файлов, а в Windows нет.
в GNU/Linux тоже нет. в общем случае надо `unlink 2` для файлов, и `rmdir 2` для каталогов.

хотя я не вижу, почему бы просто не научить `Files.dir.Delete()` автоматически применять нужный апи. технически каталог — это тоже файл, так пусть и удаляется файловым API.

Иван Денисов писал(а):
Мне тут товарищи на форуме посоветовали сделать небольшое API конкретно для этой задачи с файловым менеджером, и его загружать в зависимости от операционки. И я вот думаю, что может быть это и правильно. Туда и ваши запросы все мы бы добавили. Сделайте StdFilesBrowserLin StdFilesBrowserWin и там эти вещи для парсинга путей и т.п. И там же сделаем удаление директорий.

а вот это, я считаю, категорически неправильно. почему именно там? в смысле, мы получаем ещё один хук для работы с путями, но совершенно в другом модуле, и его расположение (тоже) абсолютно нелогично. это типичный ad-hoc дизайн. ввести новый апи просто, сложно сделать это правильно. мы же потом убрать его уже не сможем: обязательно кто-то будет использовать, и придётся, краснея от стыда, тащить с собой вечно, чтобы не ломать совместимость на пустом месте.

я бы без проблем и сам выделил нужное для браузера в отдельные системо-зависимые модули с хуками. но я вижу и по опыту, и даже уже по своему коду, что этот апи может понадобиться не только браузеру. поэтому и предложил один раз коллективно сдизайнить его если и не совсем хорошо, то хотя бы так, чтобы потом не очень стыдно было, и положить в более-менее общее место. отсюда весь мой флейм в этой теме: мне хочется не только решить конкретную проблему, но сделать это по возможности красиво. то есть, я спорю не ради спора, у меня болит про красоту системы. иначе я бы просто накоекакил и всё: «ачотакова, работаит жы!»

вот вы говорите, что предложеный мной API не нужен — и тут же предлагаете именно его и сделать. то есть, он нужен. да, не каждый день, но нужен. давайте вместе придумаем его так, чтобы не было мучительно стыдно, и положим в какое-нибудь более-менее логичное место!

простите, что опять простыня получилась, но мне хочется, чтобы меня понимали, это ведь не спор ради развлечения. я не очень хорошо умею пояснять, поэтому приходится катать простыни.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 08 Январь, 2023 17:55 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
SovietPony писал(а):
опять предположение о реализации файлов. может не быть никаких "..", а понятие "локатор уровнем выше" при этом быть может.
а одно такое уже есть в среде: разделение путей через "/". прямо в документации, ты же сам цитировал. значит, можно докинуть и ещё одно: «creating a new locator with the path specified as ".." (two dots) returns either a valid locator pointing to the parent directory, or sets `.res` to error code N (забыл код, invalid path там)».

проблему с коротким именем текущего каталога это не решает, впрочем.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 10 Январь, 2023 22:48 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
помимо прочего выяснилось, что даже один несчастный существующий хук — и то нельзя обернуть своим. хотя бы сделайте все глобалы хуков в Dialog r/o, пожалуйста! у меня вот Dvcs делает файловую систему для гит-репозитория, там необходимо создавать свой локатор (потому что у стандартного метод `.This()` не подходит), и всё: без перекрытия хука FilesBrowser не в состоянии с ним работать. а если хук перекрыть — то в состоянии.

таки я склоняюсь к тому, что Поняш был прав: этими методами надо расширять сам интерфейс локатора. ну да, омики пытались спрятать пути. у них всё равно не вышло — так давайте уже стандартизуем тот факт, что у ЛЮБОГО локатора есть некое текстовое представление содержащегося в нём маршрута. оно не обязано совпадать с системным, но обязано быть, и как минимум локатор обязан:
1. уметь его парзить (хотя это дело дериктории, в принципе, но здесь неважно);
2. уметь его возвращать (также нужны функции для получения максимальной длины пути, и текущей длины, я пояснял тут зачем);
3. гарантировать, что элементы в пути разделены "/" (это требование уже есть в документации);
4. гарантировать, что префикс пути или не содержит двоеточия — и тогда отделяется от остального пути символом "/", или всегда отделяется от остальной части символами ":/". пустой префикс ("/" и ":/") — валиден. путь типа "PFX:path/to" — может приниматься локатором на вход, но на выходе локатор обязан тогда вернуть канонизированое "PFX:/path.to". короче, локатор обязан всегда возвращать полную каноническую форму пути. финальный разделитель обязан присутствовать только для путей к корню.

опциональные методы для удобства можно уже кросс-платформенно реализовать поверх этих. трансляцию в системные пути (если надо) — скорее всего, лучше делать в соответствующих системно-зависимых модулях.

префиксы нужны для installable fs. они уже используются для получения относительных путей к USE и прочим — пусть так и дальше будет. я вот для гита сделал префикс "GIT:", например.

предлагаемый интерфейс:
Код:
PROCEDURE (l: Locator) This* (IN path: ARRAY OF CHAR): Locator, NEW, ABSTRACT;
PROCEDURE (l: Locator) MaxPathLen* (): INTEGER, NEW, ABSTRACT;
PROCEDURE (l: Locator) PathLen* (): INTEGER, NEW, ABSTRACT;
PROCEDURE (l: Locator) Path* (OUT path: ARRAY OF CHAR), NEW, ABSTRACT;

я не понял, зачем нужна `Dialog.CheckHostLoc()`: она используется ровно в одном месте, в самом модуле LinDialog — который системно-зависим, и может попросить соответствующий апи у другого системного модуля Lin напрямую.

процедура `This()` при ошибке возвращает локатор с неопределённым (но заведомо некорректным) путём и ненулевым res (НЕ допускается возвращать `l`, т.е. самого себя).

процедура `Path()` при нехватке места в `path` устанавливает поле `l.res` или в 80 (not enough memory), или в новый специальный код, но НЕ ПАДАЕТ С ТРАПОМ out-of-bounds!

недостатки решения:
1. признаём тот факт, что текстовые пути в системе есть. я не уверен, что это недостаток, впрочем, и считаю скорее достоинством.
2. старый код, реализующий свои локаторы (т.е. какие-нибудь installable FS) сломается. но его не так много, и он всё равно сломается, потому что там наверняка используется Host. так что при переносе заодно и это починят.

достоинства решения:
1. форма текстовых пути в системе стандартизована.
2. упрощается реализация installable FS, убирается один хук (который всё равно реализуется в каждом системно-зависимом модуле конкретно для его локаторов).
3. благодаря п.1 вспомогательные инструменты типа FilesBrowser и подобные могут не заниматься больше определением Host OS.


Последний раз редактировалось arisu Вторник, 10 Январь, 2023 23:30, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 10 Январь, 2023 23:21 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
дополнение к документации по интерфейсу может выглядеть как-то так:
Код:
PROCEDURE (l: Locator) MaxPathLen (): INTEGER
NEW, ABSTRACT
MaxPathLen returns maximum allowed textual path length for this locator. It can be used to allocate big enough buffer for Path method.

Post
(result > 0) & (result < 65536)
l.res = 0   no error
l.res # 0   illegal locator

PROCEDURE (l: Locator) PathLen (): INTEGER
NEW, ABSTRACT
PathLen returns the length of the curren textual path for this locator. It can be used to allocate sufficiently enough buffer for Path method.

Post
(result > 0) & (result < 65536)
l.res = 0   no error
l.res # 0   illegal locator

PROCEDURE (l: Locator) Path (OUT path: ARRAY OF CHAR)
NEW, ABSTRACT
Path returns textual path representation for this locator.

Post
l.res = 0   no error
l.res # 0   illegal locator; error code for "buffer too small" is 8 (and content of path is undefined).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 10 Январь, 2023 23:38 
Аватара пользователя

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 113
Откуда: Equestria
arisu писал(а):
это требование уже есть в документации
ну это относится к StdApi, а к остальному вопросы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 10 Январь, 2023 23:38 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Если я правильно понял идею Бориса, то CheckHostLoc как раз нужен, чтобы понять, можем ли мы вообще пытаться у локатора запрашивать путь с помощью Dialog.GetLocPath, так как не каждый локатор может нам этот самый путь вернуть. Как минимум разные локаторы в Files над памятью, или над архивом или сетью могут не всегда вернуть путь.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 10 Январь, 2023 23:51 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Иван Денисов писал(а):
Если я правильно понял идею Бориса, то CheckHostLoc как раз нужен, чтобы понять, можем ли мы вообще пытаться у локатора запрашивать путь с помощью Dialog.GetLocPath, так как не каждый локатор может нам этот самый путь вернуть. Как минимум разные локаторы в Files над памятью, или над архивом или сетью могут не всегда вернуть путь.
а. в моём предложении это решается просто возвратом кода ошибки в `l.res` из `Locator.Path()` тогда. соответственно, при ошибке (это надо в документации уточнить) содержимое `path` не определено (или можно потребовать, чтобы там всегда была пустая строка тогда).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 10 Январь, 2023 23:58 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
SovietPony писал(а):
arisu писал(а):
это требование уже есть в документации
ну это относится к StdApi, а к остальному вопросы.
я просто предлагаю его генерализовать, введя понятие «каноническая форма пути».


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 11 Январь, 2023 00:48 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
arisu писал(а):
помимо прочего выяснилось, что даже один несчастный существующий хук — и то нельзя обернуть своим. хотя бы сделайте все глобалы хуков в Dialog r/o, пожалуйста! у меня вот Dvcs делает файловую систему для гит-репозитория, там необходимо создавать свой локатор (потому что у стандартного метод `.This()` не подходит), и всё: без перекрытия хука FilesBrowser не в состоянии с ним работать. а если хук перекрыть — то в состоянии.

Так, я понял, вам надо сделать свой хук для Dialog.HostLocHook, и не потерять совместимость со старым крюком, поэтому надо его включить в свою реализацию. Открыл на чтение переменные крюков. Если кто-то из коллег будет возражать против такого действия, то обсудим. Я пока не вижу потенциальных негативных последствий от такого.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 11 Январь, 2023 00:56 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Иван Денисов писал(а):
Так, я понял, вам надо сделать свой хук для Dialog.HostLocHook, и не потерять совместимость со старым крюком, поэтому надо его включить в свою реализацию.
да, совершенно верно. это надо для любой «оверлейной» FS, в принципе. я себе тоже так пропатчил, и сейчас уже могу спокойно инсталлировать гит-репозиторий как FS, после чего свободно внутри него ходить FilesBrowser'ом, и без проблем открывать оттуда документы.

Иван Денисов писал(а):
Открыл на чтение переменные крюков. Если кто-то из коллег будет возражать против такого действия, то обсудим. Я пока не вижу потенциальных негативных последствий от такого.
спасибо!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Май, 2023 07:53 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
путём опытной эксплуатации было выяснено, что на самом деле достаточно так:

Код:
      Locator = POINTER TO ABSTRACT RECORD
         res: INTEGER;
         (l: Locator) This (IN path: ARRAY OF CHAR): Locator, NEW, ABSTRACT
         (l: Locator) GetPath (OUT path: ARRAY OF CHAR; OUT truncated: BOOLEAN), NEW, ABSTRACT;
         (l: Locator) Path (OUT path: ARRAY OF CHAR), NEW;
      END;

`.Path()` вполне специально невиртуальная и нерасширяемая: всё, что она делает — это вызывает `.GetPath()` и трапается, если `.GetPath()` сказал, что пришлось обсечь строку. и доку:

PROCEDURE (l: Locator) GetPath (OUT path: ARRAY OF CHAR; OUT truncated: BOOLEAN)
NEW, ABSTRACT
GetPath returns textual path representation for this locator. It must be canonical path representation. Canonical representation always has the form "PFX:path". PFX is optional alphanumeric prefix, path elements are delimited with "/". Passing this path back to Files.dir.This should return a new locatior that points to the same place as the locator from which the path was extracted. Note that "path" part may, or may not start with "/". It should never include the trailing slash, except when it is the only char there. I.e. "/", "/abc", "abc" are correct canonical pathes, but "/abc/" and "abc/" are not. Also, no double slashes allowed except at the start (to support Windows UNC names). i.e. "//smth/a" is valid canonical path, but "/abc//def" is not. note that "PFX://path" is not valid (but "PFX:path" is allowed).
truncated indicates if the path was truncated (i.e. there is no room in path to keep the current path). Note that if the string was truncated, path will contain the initial part of it. For Windows, this part may not be canonical.

PROCEDURE (l: Locator) Path (OUT path: ARRAY OF CHAR)
NEW
Calls GetPath, and asserts if there is not enough room in path.


и ещё в `.This()` есть теперь такое требование:

PROCEDURE (l: Locator) This (IN path: ARRAY OF CHAR): Locator
NEW, ABSTRACT
This evaluates a relative path starting from the location specified by l. Each locator must support the special path "..", and return either up-level locator, or the new locator with the same path as the original, and with res set to non-zero. Note that ".." as complex path component (i.e. like "../a") may, or may not have any special meaning. Also note that the resulting path may not exist yet.

всё. хотите работать с текстовыми представлениями путей — извольте научить свои кастомные локаторы мапить их в канонические и обратно, а также переходить на уровень выше через "..". если же у вас какая-то стрёмная FS, которая представляет из себя шизофренический граф, а не просто дерево, и там подобные операции смысла не имеют — то вам вряд ли и локаторы помогут тогда.


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

Часовой пояс: UTC + 3 часа


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

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


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

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB