Unreal Commander

Это получилось при простом переключении кнопкой диска

Qwertiy писал(а):

Copiing not allowed.png

Мне он такое окно никогда не показывает. Мелькает прогрессбарчик "Calculating task size..." - и всё.

maXmo писал(а):Скукоживаются имена файлов при переименовании.

Мне почему-то не удается получить такой же результат. Если для конкретного каталога (при конкретных файлах) переименование конкретного файла в 100% случаев приводит к такому результату, то пришлите мне список имен файлов этого каталога (также вероятно имеет значение параметр сортировки, факт включенности сортировки для каталогов, факт включенности групп сортировки).

maXmo писал(а):Это получилось при простом переключении кнопкой диска

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

Mitay писал(а):Для проверки: В развернутом командере жмем "вернуть значение по умолчанию", потом сворачиваем, разворачиваем и видим, что имя становится шире панели (если не вылезло - можно еще пару раз свернуть/развернуть).

Это будет поправлено? в прошлый раз ответа не дождался.

Не желает такая проблема проявляться, похоже без скринвидео не обойтись... запишите ролик (например с помощью UVScreenCamera) и пришлите через личное сообщение (или как вложение к общественному сообщению) или на email.

Max Diesel писал(а): Не желает такая проблема проявляться, похоже без скринвидео не обойтись

Ролик большой получается около 7мб, сюда не влезает. Кстати, после снятия видео поведение изменилось (возможно куда то ткнул в ходе экспериментов - не вспомню).
Теперь частично воспроизводится так:
Разворачиваем командер, раздвигаем имя так, чтобы "изменен" был у самой границы.
Ставим "Зафиксировать на этой позиции", сворачиваем командер в окно, чтобы окно было меньше ширины имени файла, снимаем галку "зафиксировать", разворачиваем командер: имя уходит за границу.
Раньше галка "зафиксировать" не стояла и глюк воспроизводился всегда, теперь же только если ее поставить, свернуть, снять и развернуть.

p.s. первый раз глюк заметил после нескольких смен разрешения экрана с 1650х1050 (моник) на 1366х768(ноут) и обратно

Mitay писал(а):Теперь частично воспроизводится так:
Разворачиваем командер, раздвигаем имя так, чтобы "изменен" был у самой границы.
Ставим "Зафиксировать на этой позиции", сворачиваем командер в окно, чтобы окно было меньше ширины имени файла, снимаем галку "зафиксировать", разворачиваем командер: имя уходит за границу.
Раньше галка "зафиксировать" не стояла и глюк воспроизводился всегда, теперь же только если ее поставить, свернуть, снять и развернуть.

Хм... занятный подход. При установленном флаге "фиксировать на этой позиции" изменение ширины окна не приводит к изменению ширины столбца "Имя" (в этом смысл флага), при неустановленном флаге изменение ширины окна приводит к пропорциональному изменению ширины столбца "Имя", при котором остальные столбцы (относительно правой границы панели) остаются недвижимыми. Соответственно приведенная последовательность действий манипулирования флагом "фиксрования" и изменением ширины окна (при максимизации окна зачастую производится именно изменение ширины окна) не приводит ни к каким неожиданным результатам, так и должно получаться.

Max Diesel писал(а): Хм... занятный подход... так и должно получаться.

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

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

Да-да, бывает такое. Особенно интересен случай когда после удаления папки она остается, и при попытке войти в нее предлагается войти под другой учетной записью.

ironx писал(а):Особенно интересен случай когда после удаления папки она остается, и при попытке войти в нее предлагается войти под другой учетной записью.

Ага, и такое случается...

Самопроизвольно включилась функция "Эффект затемнения фонового окна", причем, самостоятельно выбрав Custom-цвет. (b773)

Еще по поводу обновления: замечено, что если вставить ctrl-X + ctrl-V файл с десктопа, то файл копируется, но панель не обновляется. Если из панели на панель - все нормально.

При поиске файлов после двойного клика на файле открывается каталог с ним и очень часто начинается переименование этого файла в панели.

Alexey12 писал(а):Самопроизвольно включилась функция "Эффект затемнения фонового окна", причем, самостоятельно выбрав Custom-цвет. (b773)

Этот баг уже исправлен, в следующем билде будет корректно (надеюсь). Ситуация такая происходит после отображения окна замены файла.

razor писал(а):Еще по поводу обновления: замечено, что если вставить ctrl-X + ctrl-V файл с десктопа, то файл копируется, но панель не обновляется. Если из панели на панель - все нормально.

Предположительно в такой ситуации обновление панели происходит, но через секунду после вставки файла. Вероятно в такой ситуации программе приходят два события об изменении каталога и она в течение секунды ожидает новых файлов, а потом (то есть не дождавшись) производит обновление панели.

ironx писал(а):При поиске файлов после двойного клика на файле открывается каталог с ним и очень часто начинается переименование этого файла в панели.

Хм... обычно в такой ситуации включался drag n drop, здесь какой-то новый вид той же проблемы. Впрочем по части drag n drop произведены изменения и в следующем билде предположительно такой ситуации не появляться. Полагаю что к переименованию это тоже относится.

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

Ещё хотелось бы немного избирательности при переносах файлов и папок. Если перенос производится в пределах одного раздела (то есть без фактического переноса информации), тогда желательно эту операцию помещать в новую очередь, ведь она практически не занимает времени и ресурсов, для её запуска необязательно ждать завершения других действий. Оптимально будет, если в настройках появится опция "По умолчанию перенос в пределах раздела в новую очередь" рядом с аналогичной настройкой про удаление. Можно и вообще перенос в пределах одного раздела рассматривать на правах удаления. По ресурсоёмкости они одинаковы, если удаление без стирания.

И ещё на кучу. Если переносишь файлы в пределах одной буквы диска, но разных физически разделов, программа этого понимает. Она отображает диалог со всеми надлежащими прогресбарами, ведь идёт длительный процесс - физическое перемещение информации. Но иногда этот алгоритм сбоит, и я получаю либо физический перенос данных в пределах одного раздела (да, копирование и удаление вместо переноса), или диалог переноса с прогрессбаром, который висит на 100% пока файл физически переносится между разделами.
1. Диск D, папка test1. В неё подключён другой раздел. В ней есть подпапка test2.
2. Перенос из корня D в test1 проходит долго и с надлежащей индикацией, ведь идёт физический перенос файлов. Здесь всё верно.
3. Перенос из корня D в test2 показывает прогрессбар, который висит на 100% для каждого файла, пока тот физически переносится. То же самое в обратном направлении. Неверный прогрессбар.
3. Перенос из test2 в test1 проходит долго и с физическим копированием, хотя обе папки находятся на одном разделе. Обратный перенос происходит мгновенно, как и должно быть.

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

Обычно для отмены drag n drop нужно нажать Esc, а возможность бросить файл на свободное место его же панели предполагает что вдруг пользователю таким извращенным способом захочется сделать копию файла...

Fuhrer писал(а):Ещё хотелось бы немного избирательности при переносах файлов и папок. Если перенос производится в пределах одного раздела (то есть без фактического переноса информации), тогда желательно эту операцию помещать в новую очередь, ведь она практически не занимает времени и ресурсов, для её запуска необязательно ждать завершения других действий. Оптимально будет, если в настройках появится опция "По умолчанию перенос в пределах раздела в новую очередь" рядом с аналогичной настройкой про удаление. Можно и вообще перенос в пределах одного раздела рассматривать на правах удаления. По ресурсоёмкости они одинаковы, если удаление без стирания.

К сожалению зачастую до начала переноса файла/каталога нет возможности определить (или же я ее не знаю), даст ли система этот файл/каталог переместить в пределах этого же диска или же заупрямится. Попробуйте переместить в подкаталог каталог "Windows" и увидите что некоторые каталоги держит система...

Fuhrer писал(а):И ещё на кучу. Если переносишь файлы в пределах одной буквы диска, но разных физически разделов, программа этого понимает. Она отображает диалог со всеми надлежащими прогресбарами, ведь идёт длительный процесс - физическое перемещение информации. Но иногда этот алгоритм сбоит, и я получаю либо физический перенос данных в пределах одного раздела (да, копирование и удаление вместо переноса), или диалог переноса с прогрессбаром, который висит на 100% пока файл физически переносится между разделами.
1. Диск D, папка test1. В неё подключён другой раздел. В ней есть подпапка test2.
2. Перенос из корня D в test1 проходит долго и с надлежащей индикацией, ведь идёт физический перенос файлов. Здесь всё верно.
3. Перенос из корня D в test2 показывает прогрессбар, который висит на 100% для каждого файла, пока тот физически переносится. То же самое в обратном направлении. Неверный прогрессбар.
3. Перенос из test2 в test1 проходит долго и с физическим копированием, хотя обе папки находятся на одном разделе. Обратный перенос происходит мгновенно, как и должно быть.

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