FastRawViewer 1.3.7 release candidate

Ну и парой к диггеру, FastRawViewer 1.3.7 с теми же 12-ю добавленными камерами и мелкими исправлениями:

Ссылки для скачивания

Релиз вышел, берите на официальном сайте

Поддержка камер

  • Canon EOS M5
  • Hasselblad X1D, True Zoom
  • Google Pixel, Pixel XL
  • Olympus E-M1 Mark II
  • Panasonic DMС-FZ2500/2000/FZH1, DMC-LX9/10/15
  • Samsung Galaxy S7/S7 Edge
  • Sony ILCA-99M2 (A99-II), a6500

Улучшения

  • Обновлены цветовые данные для камер Olympus, Panasonic, Sony
  • В панели EXIF можно включить индикацию Baseline Exposure ("скрытой экспопоправки Adobe")
  • Capture One v10 добавлена к списку известных программ (распознаваемых при первом старте)

Исправлены проблемы

  • Дополнительные проверки на "битость" превьюшек
  • Улучшена обработка DNG-файлов в которых уровень черного задан и в данных Makernotes
  • Улучшена обработка DNG-файлов преобразованных из файлов с сенсоров Fuji SuperCCD
  • Кнопка Preferences - Reset to Defaults не сбрасывает настройки   'Use System Open File/Folder dialogs' и  'Use built-in icons' settings
  • Кнопка Preferences - Reset to Defaults не сбрасывает скрытые настройки TryJpegAsRaw, WheelScrollLines, DragPanCursorWOZoom
  • Добавлена новая скрытая настройка  AlternateXMPWrite, используйте если у вас есть проблемы с записью XMP (проблема отмечена пока у единственного пользователя).
  • Несуществующие пути, записанные в список Favorite Folders (например, пути на отключенный сетевой сервер) теперь не замедляют запуск программы.
  • Панель EXIF: нижний скроллбар показывается теперь только если реально нужен.

Прочее

  • Из документации удалено упоминание скрытой настройки GlobalAlternateHandler - эта настройка удалена пару версий назад.

Если вы вдруг будете анонсировать эту версию в каких-то англоязычных сообществах, используйте пожалуйста вот эту вот ссылку: FastRawViewer 1.3.7 release candidate

Comments

Я тут вашим форумом (FRV'шным) воспользовался (багрепорт!) и там АДЪ и ИЗРАИЛЪ. Превью поста в текст-онли режиме переводит его в HTML с эскейпами и дальше редактировать жутко неудобно. Плюс при превью вот такое показало мне в красной табличке:

Notice: Undefined property: stdClass::$disable_breadcrumb in disable_breadcrumbs_node_view() (line 157 of /home/export/group/rawdigger/sites/all/modules/disable_breadcrumbs/disable_breadcrumbs.module).
Notice: Undefined property: stdClass::$disable_breadcrumb in disable_breadcrumbs_node_view() (line 157 of /home/export/group/rawdigger/sites/all/modules/disable_breadcrumbs/disable_breadcrumbs.module).

Плюс подпись не прикрепилась плюс форматирование из плейн-текста таки, кажется, съехало.

комментария вашего в том форуме - не вижу.

Ой, а что вдруг на вы? :)

http://www.fastrawviewer.com/node/339

Кстати, я там аттачил скриншот, и если я РЕДАКТИРУЮ пост, то аттач есть. А если просто читаю — то нигде найти не могу аттача.

вот теперь - вижу

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

И Del удаляет (ну, помещает в _Rejected) не помеченное а текущее! Ну, если что-то из помеченного — текущее, то его, конечно, но я выбрал серию ненужную, нажал Del и у меня «удалился» 1 файл, а не 10! Это вот прямо неожиданно. И неудобно.

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

Вообще, я пока мануал не прочёл ещё, только открыл, но мне кажется что в обоих случаях нарушен POLA в полный рост.

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

У нас идея группы, которая не пропадает при Accidental click (каковой клик сносит любовно выстроенное выделение).

Все остальное следует из этой идеи

Эту идею я понял, а вот перехода к последствиям — ну как у Ландау-Лифшица, промежуточные шаги рассуждения для меня потеряны. Особенно логику шифт-клика в случае, когда вотпрямощас никакой группы нет вовсе (и я уже забыл что выделял и РАЗвыделял картинку в другом конце фильмстрайпа 10 минут назад). Про Del я могу домыслить.

Логика шифт-клика в explorer - ровно та же. Попробуйте.

Если вы сняли выделение где-то в хвосте, то shift-click выберет группу ровно до того места, где было снято выделение

В Windows Explorer? Попробовал. Нет, привычная логика. От текущего до места клика. Место клика не становится текщуим.

Вот это и проблема — потому что ТО выделение которого уже НЕТ (снято) ни имеет никакого отношения к моим текущим действиям. Вот я смотрю файл. Вижу, что я серией снял 5 кадров говносюжета, всё в корзину. Я шифт-кликаю на 4-ый файл от текущего, что бы выделить все 5 и удалить, а оно вспоминает, что я когда-то выделял что-то другое, что сейчас не выделено. Я не вижу в этом НИКАКОЙ логики. Вообще. Как и от первого файла (если истории выделений нет). Это абсолютный и нелогичный произвол на мой взгляд.

Потому что "текущий" - всегда в группе.

Поставь выделение (и потом сними его!) /ниже есть дублирующий чуть более подробный комментарий/

Переучиваться же надо (можно) именно по той причине, что стандартное поведение признано негодным.

Я пользуюсь ещё десятком программ (про фото и не про фото), где старое поведение. И их никто менять не будет.

Ну вот если будет много жалоб - мы вернем, как опцию, стандартное.

Пока типичный паттерн такой
- у вас все криво
- да, это намеренно, потому-то и потому-то
- ага, вы правы, ваше лучше.

То есть при всем уважении к сохранению "стандартных" поведений, это конкретное стандартное НАСТОЛЬКО ДОСТАЛО, что вот принято решение его сломать.

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

В винде - не обязательно расширяет, бывает инвертирует.

давайте вы прочтете мануал таки, мы писали его старались.

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

Ок, пошёл в мануал.

Прочёл про логику шифт-клика в мануале. Я её не понимаю. Почему надо начинать выделение с файла в котором когда-то (может сутки назад, просто программу не перезапускали) СНИМАЛИ выделение (если бы ставили — я бы ещё как-то со скрипом признал такую логику), а не с текущего — мне решительно не ясно. Мануал никакого rationale не даёт.

Вообще, логика Shift-Click в windows explorer - примерно та же.

С той поправкой, что в windows единичный клик (без модификаторов) - меняет выделение, а у нас - не меняет. Поэтому старт группы - вот такой.

А "текущий" - никак не связан с группой.

А нет никакой группы. Вообще. Когда есть хоть что-то выделенное уже — тогда понятно. Но сейчас группы нет, а последний Selection status change был де-селектом файла в другом конце фолдера 5 минут назад и я про это уже забыл.

Explorer:
- Сtrl-Click -> Выделили
- Ctrl-Click туда же -> развыделили, "нет никакой группы"
- Shift-Click куда-то еще
:)

Тоже "не было никакой группы". Win8.1, может на десятке иначе.

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

Ну мы записали что есть наконец один пользователь, которому надо стандартное.

В версии 1.4, может быть, как опцию....

А rawdigger окончательно задвинут (кроме мелких багов и поддержки новых камер) ?

N/A

нет, отнюдь.
Просто в FRV гораздо больше поток коротких запросов, которые, казалось бы, можно исполнить за час (день, два)

Это сдвигает диггера вправо

Ну, кстати, не стандартное-стандартное, а чуть-чуть другое поведение в случае когда это новая группа (нет ничего отмеченного галочкой сейчас). Это мне кажется оптимальным и самым логичным в случае когда случайный клик выделение не теряет.

Ну мы из последних сил старались и эмулировали Explorer.

Можно (скрытой) опцией, да, "если selection нету, то от начала".

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

Чуть другое - какое?

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

Считая что мы должны (как default) сохранить текущее поведение ("второй край выделения: последний ctrl-clicked, а если такого нет - то первый файл в списке), получается что нужно две галочки

а) Считать ли "разотмеченный" - краем выделения (отмеченный - понятно что считать)
б) если "края выделения" нет, то диапазон shift-click
- от первого файла в каталоге
- от текущего /но если shift-click на текущий и края нет - то таки от начала списка/

Так?

Ну, это будет максимальная гибкость, конечно. Т.е. я не знаю, будет ли кто-то пользоваться вариантом "не считать, всегда от начала" и "считать, но если совсем нет — от текущего" :) Многим явно хватает того, что сейчас, мне хватит "не считать, от текущего".

Тут такая тонкость, что мне это поведение нужно еще описать кратким языком плаката  понятными словами в настройках.

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

:) Ну, тут тебе виднее как удобнее сделать :)

Решили делать скрытой настройкой (в Registry/Preferences).

Вот сел программировать описанное ниже, еще не поздно меня остановить и поправить:

* Новая скрытая настройка ShiftClickSelectionMode и скрипты ShiftClickSelectionModeDefault.reg/.sh
Эта настройка модифицирует поведение Shift-Click (выделение диапазона) в Grid и Filmstrip.
Битовое поле из двух бит.

  • Младший бит отвечает за определение второй границы диапазона выделения (первая граница - файл в который сделали Shift-Click):
    • 0 - второй границей диапазона Shift-Click будет last Ctrl-Clicked, независимо от того, была эта установка выделения или снятие
    • 1 - второй границей диапазона будет last Ctrl-Clicked только если это было установкой выделения.
  • Старший бит отвечает за определение второй границы, если last Ctrl-Clicked не нашлось:
    • 0 - вторая граница диапазона - первый файл в текущей папке
    • 1 - вторая граница диапазона - текущий файл (но только если Shift-Click был не на него, а если на него - то опять первый файл в текущей папке)

Соответственно, ShiftClickSelectionMode = 0 - это текущее поведение. 4 (8) скриптов делать не стали, кому надо - ручками поправит и запустит или просто в regedit отрихтует.

Когда/если эта настройка будет востребована (про нее будет много запросов в саппорт) - перенесем ее в гуй (как сделали/делаем с FilmstripSelectedItemContrast в 1.3.8)

С точки зрения логики выглядит ок, текст в ридмишку надо поправить (про младший бит — разнобой вторая / конечная граница, при том что про старший бит всегда второй, путаница).

Ридмишка все едино будет на английском, тогда и поправим

впрочем, везде написал "вторая" и сделал оговорку про первую

тестируйте, жалуйтесь: http://blog.lexa.ru/2017/01/07/fastrawviewer_138_beta.html

> давайте вы прочтете мануал таки, мы писали его старались.

наш человек не для того родился чтобы RTFM !

N/A

Add new comment