OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 01 Июнь, 2023 18:35

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




Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Суббота, 07 Январь, 2023 19:12 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 834
предлагаю добавить ещё одно апи для путей:
Код:
   PROCEDURE Dialog.GetLocPathLen* (loc: Files.Locator): INTEGER;

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

и ещё бы апей типа:
Код:
   PROCEDURE Dialog.IsPathSeparator* (ch: CHAR): BOOLEAN;
   PROCEDURE Dialog.AbsolutePathPartLen* (IN path: ARRAY OF CHAR): INTEGER;

первое очевидно, зачем, думаю. `AbsolutePathPartLen()` возвращает 0, или количество символов, которые надо пропустить в `path` чтобы превратить абсолютный путь в относительный.
т.е. на винде:
Код:
AbsolutePathPartLen("c:\wtf") → 3
AbsolutePathPartLen("\\machine\wtf") → 10
AbsolutePathPartLen("\wtf") → 1
AbsolutePathPartLen("wtf") → 0
AbsolutePathPartLen("c:wtf") → 2 (тут своеобразно, но пусть будет так)

и на GNU/Linux:
Код:
AbsolutePathPartLen("/wtf") → 1
AbsolutePathPartLen("wtf") → 0


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3693
Добавить то много что можно, но мы пытаемся сохранить минимальный достаточный набор
GetLocPathLen реализуется кросс-платформенно трехстрочной функцией
Код:
VAR path: ARRAY 256 OF CHAR;
BEGIN
Dialog.GetLocPath(loc, path);
RETURN LEN(path$)

Поэтому добавлять отдельную функцию нецелесообразно. Такие действия придут в разрастанию API без особой на то нужды.

Сама возможность того, что path теперь может стать частью кросс-платформенного кода уже вызывала опасения у коллег.


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

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 834
Иван Денисов писал(а):
Добавить то много что можно, но мы пытаемся сохранить минимальный достаточный набор
GetLocPathLen реализуется кросс-платформенно трехстрочной функцией
Код:
VAR path: ARRAY 256 OF CHAR;
BEGIN
Dialog.GetLocPath(loc, path);
RETURN LEN(path$)
увы, не реализуется. 256 — это не общая для всех систем константа. в том же GNU/Linux путь может быть длиной около 4 кб. а в windows с использованием UNC, промеждупрочим, вообще 32 килобайта. вот это вот частое 256, которое я вижу в исходниках — оно меня весьма пугает. 255 символов — это частое ограничение на имя файла, а не на общую длину пути.

Иван Денисов писал(а):
Сама возможность того, что path теперь может стать частью кросс-платформенного кода уже вызывала опасения у коллег.
так она и не стала, увы. более того: BBCB для GNU/Linux, например, имеет массу ошибок в обработке путей. потому что во многих местах проверка на разделитель частей пути считает, что это может быть и слэш, и обратный слэш. однако в GNU/Linux обратный слэш позволено использовать в именах файлов, и он разделителем пути не является.

тут варианта ровно два: или мы внутри Locator всегда приводим все пути к «каноничному» виду (а какому? в винде есть буквы дисков, в GNU/Linux нет; какой вариант принимать за каноничный, как их совместить вообще?), или обеспечиваем набор API для работы с путями, отвязаный от платформы. на самом деле в API надо ещё добавить как минимум процедуры для разбора пути на кусочки и сбора обратно (или хотя бы для пристыковывания к пути разделителя, который в общем случае неизвестен и платформозависим), но хотя бы то, что я предлагаю — уже позволит писать более-менее независимый от платформы код.

более того: если вдруг в будущем Locator начнёт пути внутри себя «канонизировать», то код, написаный с использованием кроссплатформенного API, продолжит работать как ни в чём не бывало; а вот код, который уверен, что он точно в курсе, как представляются пути — может сломаться.


Последний раз редактировалось arisu Суббота, 07 Январь, 2023 22:09, всего редактировалось 1 раз.

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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3693
Про то и речь, что понятие локатора оторвано от пути. Никто не должен в программах ББ разбирать пути, как вы сейчас предлагаете. Оно так не планировалось разработчиками каркаса. Однако такая процедура GetLocPath была добавлена, чтобы убрать лишние импорты HostFiles, который импортировали ради редких случаев, когда этот самый путь для чего-то вдруг понадобился.

"BBCB для GNU/Linux, например, имеет массу ошибок в обработке путей"
вот это надо поправить


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

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 834
Иван Денисов писал(а):
Про то и речь, что понятие локатора оторвано от пути. Никто не должен в программах ББ разбирать пути, как вы сейчас предлагаете. Оно так не планировалось разработчиками каркаса.

тем не менее, это необходимо для организации взаимодействия с внешним миром. более того: даже создать внутри среды путь кроссплатформенно — невозможно. мне писать "Mysubsys/Xtra/MyDir" или "Mysubsys\Xtra\MyDir"?

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

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

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

Иван Денисов писал(а):
"BBCB для GNU/Linux, например, имеет массу ошибок в обработке путей"
вот это надо поправить
а это сейчас невозможно поправить, оно живёт в куче мест — в коде, который системно-независим. никак невозможно это починить, не имея системно-независимого API для работы с текстовым представлением путей. именно необходимость починки такого кода и мотивировала меня предложить расширение API. без него — никак.


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

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 101
Откуда: Equestria
апи для сепараторов точно не нужны. мне трудно представить зачем оно надо. и GetLocPath мне не нравится (что делать если никаких сепараторов нет вообще, а пути описываются какими-нибудь объектами? эмулировать пути? но зачем?)

раз уж есть GetLocPath, то лучше бы добавить делилку платформо-зависимого пути на то что можно вкинуть в Locator.This() и имя файла, пригодное для Files.Directory.Old()/Register(), можно читалку Files.Locator обратно на строки. остальное ненужно.


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

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 101
Откуда: Equestria
arisu писал(а):
Иван Денисов писал(а):
Про то и речь, что понятие локатора оторвано от пути. Никто не должен в программах ББ разбирать пути, как вы сейчас предлагаете. Оно так не планировалось разработчиками каркаса.

тем не менее, это необходимо для организации взаимодействия с внешним миром. более того: даже создать внутри среды путь кроссплатформенно — невозможно. мне писать "Mysubsys/Xtra/MyDir" или "Mysubsys\Xtra\MyDir"?
если не ошибаюсь, где-то в доках было написано что / -- именно портабельный вариант внутри ящика. но это не точно, надо поискать.


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

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 101
Откуда: Equestria
Form/Docu/User-Man.odc писал(а):
These OpenAuxDialog/OpenToolDialog commands accept portable path names as input. A portable path name is a string which denotes a file in a machine-independent way. It uses the "/" character as separator, i.e. like in Unix or the World-Wide Web.


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

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 834
SovietPony писал(а):
раз уж есть GetLocPath, то лучше бы добавить делилку платформо-зависимого пути на то что можно вкинуть в Locator.This() и имя файла, пригодное для Files.Directory.Old()/Register(), можно читалку Files.Locator обратно на строки. остальное ненужно.
и мы сразу влетаем в проблему реализации FilesBrowser: как там попасть на уровень выше? сейчас там откусывается последняя часть пути и сепаратор, и вид сепараторов/формат путей прибиты гвоздями к коду (и это, кстати, неправильно работает на винде с UNC-путями, например; да и с буквами дисков тоже не особо верно). а в остальном FilesBrowser платформо-независимый. я пытался обойтись малой болью, и расширить апи минимально.

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

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

SovietPony писал(а):
Form/Docu/User-Man.odc писал(а):
These OpenAuxDialog/OpenToolDialog commands accept portable path names as input. A portable path name is a string which denotes a file in a machine-independent way. It uses the "/" character as separator, i.e. like in Unix or the World-Wide Web.
увы, это не отвечает на вопрос, как мне указать виндовый путь типа "D:\mydir\otherdir\filename" машинно-независимо.


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3693
Если нет ни "/" ни "\", то никак и не попасть на уровень выше... В локаторах Блэкбокса нет такой возможности. А эта возможность очень частный случай. Так что файловый браузер тут получается работает над частными случами локаторов, у которых вот так удобно представляются текстовые пути.

Я думаю, что там в коде можно смело писать хаки на уровне
Код:
IF Dialog.platform = Dialog.linux THEN ...


Так как сам по себе этот файловый браузер предполагает использование в рамках вполне определённых правил нескольких распространённых ОС, а не всей супер-абстрактной концепции локаторов.


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

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 101
Откуда: Equestria
arisu писал(а):
SovietPony писал(а):
раз уж есть GetLocPath, то лучше бы добавить делилку платформо-зависимого пути на то что можно вкинуть в Locator.This() и имя файла, пригодное для Files.Directory.Old()/Register(), можно читалку Files.Locator обратно на строки. остальное ненужно.
и мы сразу влетаем в проблему реализации FilesBrowser: как там попасть на уровень выше? сейчас там откусывается последняя часть пути и сепаратор, и вид сепараторов/формат путей прибиты гвоздями к коду (и это, кстати, неправильно работает на винде с UNC-путями, например; да и с буквами дисков тоже не особо верно). а в остальном FilesBrowser платформо-независимый. я пытался обойтись малой болью, и расширить апи минимально.
ну вот была бы читалка локаторов взад на строки - решилось бы. передали в файл-браузер loc := Files.dir.This("D:\mydir\dir"), в самом браузере делаем loc.NewRider и читаем, обратно сама же хост-реализция распарcила локатор на "D:", "mydir", "dir" и вообще ничего про сепараторы не надо знать. эти распарсеные строки можно обратно собрать в идентичный локатор. и функция которая распарсит "D:\mydir\dir\filename.txt" в локатор "D:\mydir\dir" и имя "filename.txt". всё это можно затолкать в Files и решить раз и навсегда проблему с путями. если надо делать больше - в Dialog есть способы узнать на каком хосте мы работаем.
arisu писал(а):
SovietPony писал(а):
Form/Docu/User-Man.odc писал(а):
These OpenAuxDialog/OpenToolDialog commands accept portable path names as input. A portable path name is a string which denotes a file in a machine-independent way. It uses the "/" character as separator, i.e. like in Unix or the World-Wide Web.
увы, это не отвечает на вопрос, как мне указать виндовый путь типа "D:\mydir\otherdir\filename" машинно-независимо.
не имеет смысла делать машинно-независимо то что машинно-зависимо. нету на линуксе никакого D:, и нету на маке никаких / и \.


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

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 101
Откуда: Equestria
Иван Денисов писал(а):
Если нет ни "/" ни "\", то никак и не попасть на уровень выше... В локаторах Блэкбокса нет такой возможности. А эта возможность очень частный случай. Так что файловый браузер тут получается работает над частными случами локаторов, у которых вот так удобно представляются текстовые пути.

Я думаю, что там в коде можно смело писать хаки на уровне
Код:
IF Dialog.platform = Dialog.linux THEN ...


Так как сам по себе этот файловый браузер предполагает использование в рамках вполне определённых правил нескольких распространённых ОС, а не всей супер-абстрактной концепции локаторов.
Обощенный файлбраузер можно сделать полностью и честно портабельным, если разрешить парсить локатор обратно на строки. Это так же очень много кода позволит делать портабельным, а не таскать повсуюду парсилки путей что бы вытянуть локатор и имя файла. подумайте над тем что бы запилить пару фич, которые решат 99% проблем связанных с путями.


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

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 834
Иван Денисов писал(а):
Я думаю, что там в коде можно смело писать хаки на уровне
Код:
IF Dialog.platform = Dialog.linux THEN ...
я и делаю. и мне это активно не нравится: я перестаю понимать, к какой части системы относится FilesBrowser. если он системно-зависимый, то почему он в Std, а не в Lin/Win/Obsd/etc? а если системно-независимый, то почему в него встроено знание о поддерживаемых ОС?

SovietPony писал(а):
передали в файл-браузер loc := Files.dir.This("D:\mydir\dir"), в самом браузере делаем loc.NewRider и читаем, обратно сама же хост-реализция распарcила локатор на "D:", "mydir", "dir"
а если "D:mydir"?

SovietPony писал(а):
не имеет смысла делать машинно-независимо то что машинно-зависимо. нету на линуксе никакого D:, и нету на маке никаких / и \.
а я вот предлагаю способ сделать машинно-независимую реализацию. на всех современных ОС есть понятие «корень файловой иерархии» и «разделитель имен подкаталогов». если система плоская — это будет пустая строка и 0X. иначе API как раз позволяет узнать корень, и побить строку на имена. используя этот API можно построить системно-независимую парзилку путей из локаторов, и оформить модулем.

два единственных варианта, где это не будет работать:
1. ОС, в которой пути задаются «задом наперёд» (т.е. "filename/dir/root/"), и
2. ОС, в которой разделители имён состоят более чем из одного символа/варируются по некоторому условию.

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


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

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 101
Откуда: Equestria
arisu писал(а):
SovietPony писал(а):
передали в файл-браузер loc := Files.dir.This("D:\mydir\dir"), в самом браузере делаем loc.NewRider и читаем, обратно сама же хост-реализция распарcила локатор на "D:", "mydir", "dir"
а если "D:mydir"?
раз пользователь где-то так ввёл, значит так и вернуть "D:mydir". ну или как посчитает нужным реализация. для всяких гуёв будет отлично работать (ведь пользователь сможет если что ввести путь сам?).


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

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 834
я к тому, что если использовать гипотетическое апи для чтения пути из локатора по частям, то невозможно отличить "D:wtf" от "D:\wtf", потому что сепаратор потерялся.


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

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 101
Откуда: Equestria
arisu писал(а):
а я вот предлагаю способ сделать машинно-независимую реализацию. на всех современных ОС есть понятие «корень файловой иерархии» и «разделитель имен подкаталогов». если система плоская — это будет пустая строка и 0X. иначе API как раз позволяет узнать корень, и побить строку на имена. используя этот API можно построить системно-независимую парзилку путей из локаторов, и оформить модулем.
смысл искать корень какими-то ненадежными методами если лучше спроить ящик напрямую? %) можно сделать спец апи для получения локатора-корня (и вообще разного рода полезные локаторы типа домашней директории, текущей директории, директории приложения, место куда можно сгружать конфиги, загруженные файлы, шаблоны и т.д., подобные вещи есть например в апи на макос). Отлично зайдёт в Dialog.
сепаратор тоже туда можно сунуть. одна CHAR переменная никому не помешает. но какие варианты если нет никаких сепараторов или они специфические? нужна тогда какая-то функция что бы получить локатор уровнем выше (ящик все равно предполагает наличие концепта директорий или чегото подобного и оно повсюду активно используется как цепочка наподобии Files.dir.This("Dev").This("Mod").) парсить ручками неизвестно что должно быть самым последним делом (а лучше вовсе без этого).


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

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 101
Откуда: Equestria
arisu писал(а):
я к тому, что если использовать гипотетическое апи для чтения пути из локатора по частям, то невозможно отличить "D:wtf" от "D:\wtf", потому что сепаратор потерялся.
как не получилось если получилось? %) в винде не бывает директорий с двоеточием в имени, хост об этом знает, всё однозначно. твой пример "директория mydir в текщей директории на диске D". это уже не "корень диска" и не "директория", а нечто третье особенное "текущая директория на диске". а Locator.This() делит именно директории. всё логично получается.


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

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 834
SovietPony писал(а):
смысл искать корень какими-то ненадежными методами если лучше спроить ящик напрямую?
с этим есть забавная проблема (уже сейчас): пути, которых не существует на FS. в документации написано:
Цитата:
PROCEDURE (d: Directory) This (IN path: ARRAY OF CHAR): Locator
NEW, ABSTRACT
blah-blah… This does not check if the specified path exists.
и вот тут мы имеем проблему: ящик не знает, во что развернуть "X:mydir", если диска "X:" не существует вообще. и по документации — он не имеет права выяснять, существует ли такой диск. он умеет разворачивать или абсолютные пути, или относительно положения бинарника.

это я к тому, что `Files.dir.This()` всегда разворачивает пути в полный дисковый вариант, а здесь это невозможно. ломать такой разворот — значит, поломать кучу кода, которая полагается на такое поведение. а распарзить такой несуществующий путь без системно-зависимого кода и без локатора нельзя.

да, такое возможно только на винде, и проблема очень экзотическая. но если мы введём платформо-независимый API для парзинга путей в текстовом виде, то это будет стимулировать людей писать переносимый код даже для такой редкой ерунды, а не прибивать гвоздями проверки ОС. и если вдруг появится ещё одна ОС, где может быть подобное — то «правильный» код будет Просто Работать, а код с прибитыми проверками придётся чинить. «Defence-In-Depth», однако.

SovietPony писал(а):
сепаратор тоже туда можно сунуть. одна CHAR переменная никому не помешает.
и не поможет, потому что у винды, например, два равноправных сепаратора, а не один. именно затем и нужна функция.

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

SovietPony писал(а):
нужна тогда какая-то функция что бы получить локатор уровнем выше
тогда пусть `loc.This("..")` работает как это вот самое. тем не менее, проблемы с FilesBrowser всё ещё есть: мне нужно короткое имя каталога локатора (только последняя часть), чтобы спозиционировать на него курсор по выходу на уровень выше (потому что LocInfo возвращает список локальных имён). опять надо парзить путь ручками, знать про сепараторы, и прочая-прочая. ну, или городить адский ад, создавая по локатору на каждое короткое имя в списке, и сравнивая их.

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


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3693
arisu писал(а):
SovietPony писал(а):
нужна тогда какая-то функция что бы получить локатор уровнем выше
тогда пусть `loc.This("..")` работает как это вот самое. тем не менее, проблемы с FilesBrowser всё ещё есть: мне нужно короткое имя каталога локатора (только последняя часть), чтобы спозиционировать на него курсор по выходу на уровень выше (потому что LocInfo возвращает список локальных имён). опять надо парзить путь ручками, знать про сепараторы, и прочая-прочая. ну, или городить адский ад, создавая по локатору на каждое короткое имя в списке, и сравнивая их.

Ну давайте пока решим имеющимися средствами, пусть там и будет некая сложность в коде, но не будем менять API. У меня ещё был вопрос про удаление папок. Так как если не такую папку создал, то её надо удалить прямо из файлового браузера. А в Блэкбоксе нет средств для удаления папок вообще. Только для файлов. В Linux папка как файл удаляется обычным удалением для файлов, а в Windows нет. Мне тут товарищи на форуме посоветовали сделать небольшое API конкретно для этой задачи с файловым менеджером, и его загружать в зависимости от операционки. И я вот думаю, что может быть это и правильно. Туда и ваши запросы все мы бы добавили. Сделайте StdFilesBrowserLin StdFilesBrowserWin и там эти вещи для парсинга путей и т.п. И там же сделаем удаление директорий.


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

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 101
Откуда: Equestria
arisu писал(а):
с этим есть забавная проблема (уже сейчас): пути, которых не существует на FS. в документации написано:
для корня сохранять флажок в локаторе или типа того (если оно никак не представимо в пути). это проблемы хоста как именно оно реализует особые локаторы. в общем случае всякие GetLocPath годятся разве что для визуального представления путя в портабельной программе, но для конвертирания обратно в локатор может не сработать как ожидается.
arisu писал(а):
и вот тут мы имеем проблему: ящик не знает, во что развернуть "X:mydir", если диска "X:" не существует вообще. и по документации — он не имеет права выяснять, существует ли такой диск. он умеет разворачивать или абсолютные пути, или относительно положения бинарника.
не разворачивать. не вижу никакой проблемы. может для совместимости в доке к Files напрямую написать "This принимает только windows-пути, все остальные обязаны их эмулировать"? :)
arisu писал(а):
и не поможет, потому что у винды, например, два равноправных сепаратора, а не один. именно затем и нужна функция.
не нужно пытаться парсить неизвестно что. либо мы знам на какой ос работаем = знаем как устроены пути, либо не знаем и не трогаем ничего без спроса портабельного апи, которое делает конкретную операцию над локаторами.
arisu писал(а):
забить. если сепараторов нет, значит у нас плоская фс. если они меняются по правилам драконего покера — значит, мы такое сумасшествие игнорируем, и пусть с ним играется тот, у кого оно зачем-то завалялось.
неправда. у меня есть bare metal blackbox, который работает поверх железа. там нет смысла внутре конвертировать пути в текстовое представление а потом каждый раз распарсивать обратно. локаторы - нативное представление путей. сепараторов нет, но и фс не плоская. и во всяких кастомных виртальных Files.Directory тоже было бы проще оперировать локаторами без сепараторов
SovietPony писал(а):
тогда пусть `loc.This("..")` работает как это вот самое.
опять предположение о реализации файлов. может не быть никаких "..", а понятие "локатор уровнем выше" при этом быть может.


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

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


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

Сейчас этот форум просматривают: Иван Денисов и гости: 1


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

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