lightroom-cc-on-linux

Воспроизводимый рецепт запуска Adobe Lightroom CC (приложения для работы с фото с облачной синхронизацией, не Classic) на Linux через Wine 11.8 staging. По состоянию на 2026-05-16 десктопное приложение Creative Cloud полностью выполняет вход, модуль Edit в Lightroom отрисовывает все панели (Light, Color, Effects, Detail, Optics, Geometry), а инструмент Remove/Heal работает целиком, включая кисть, маску и применение изменений.

Помимо самого рецепта проект интересен тем, что его полностью исследовал, отладил, пропатчил, проверил по скриншотам и задокументировал Claude Opus 4.7, работавший автономно через Claude Code. Человек (sander110419) лишь поставил задачу - заставить Lightroom работать и выложить воспроизводимый рецепт - и изредка отвечал на уточняющие вопросы. Всё остальное сделал агент.

Шесть неочевидных исправлений

1. Фиктивный swapchain композиции в DXVK, чтобы WebView2 (UI-оболочка Adobe на базе Electron) мог отрисовывать интерфейс.
2. Отключение AdobeGrowthSDK.dll - библиотека A/B-тестирования Adobe вызывает нереализованную функцию SetThreadpoolTimerEx и роняет всё дерево процессов CC.
3. Пропатченная d2d1.dll, регистрирующая встроенный эффект CLSID_D2D1ColorManagement, необходимый для Lightroom. Инструкции по сборке находятся в stubs/sources/.
4. Пропатченная mfplat.dll с форвардером MFCreateSampleCopierMFT, предотвращающим падение инструмента Remove/Heal. Библиотеку нужно положить в два места - в system32/ и в каталог установленного приложения по пути Program Files/Adobe/Adobe Lightroom CC/mfplat.dll, так как Adobe поставляет собственную копию DLL, перекрывающую версию из Wine.
5. Миниатюрные stub-библиотеки для NDFAPI.DLL, wkscli.dll, ext-ms-win-uiacore-l1-1-2.dll.
6. Симлинки в нижнем регистре для поставляемых Adobe DLL, чтобы чувствительный к регистру PE-загрузчик Wine мог их найти.

Рабочий цикл агента

В README задокументировано, как именно работал Claude:

1. Чтение дампов падений, логов Wine, бинарников Adobe (с помощью winedump, objdump и прямого разбора PE на Python).
2. Сравнение таблиц экспорта всех релевантных mfplat.dll (встроенной в Wine, из Proton, поставляемой Adobe) с отложенным импортом (delay-loaded imports) winegstreamer, что позволило локализовать проблему до одной недостающей функции MFCreateSampleCopierMFT.
3. Прямой патчинг бинарника (scripts/patch_mfplat.py): добавление новой секции PE со свежей директорией экспорта, содержащей все исходные экспорты плюс форвардер на mf.MFCreateSampleCopierMFT.
4. Верификация через создание скриншотов с помощью import из ImageMagick, алгоритмический поиск элементов UI с помощью Pillow, управление мышью через xdotool и отслеживание либо всплывающего окна инструмента Remove, либо дампа падения в ~/AppData/LocalLow/Adobe/CRLogs/. Когда клики промахивались на пару пикселей, агент делал новый скриншот, заново запускал распознавание, корректировал координаты и повторял попытку.
5. Обнаружение того, что пропатченная system32/mfplat.dll не загружалась, поскольку порядок поиска DLL в Windows отдаёт приоритет каталогу приложения, а Adobe поставляет свою версию. Агент скопировал пропатченную DLL в каталог установки Adobe, перезапустил приложение и по скриншоту подтвердил, что инструмент Remove теперь работает.
6. Документирование успешных шагов и сохранение заметок в память для следующей сессии, чтобы нюанс со встроенными DLL Adobe можно было учесть при работе с другими приложениями компании.

Документация по методике

Файл history_methodology.md (~1750 строк) содержит хронологическую историю сборки: каждый шаг, тупиковые ветки, diff'ы и верификацию UI по скриншотам за несколько дней отладки. Часть I реконструирует ранние сессии (DXVK, SetThreadpoolTimerEx, сканирование CLSID эффектов D2D, три категории исправлений отсутствующих DLL) на основе записей в журналах, скриншотов и анализа wineprefix - прежние агенты завершили работу, но оставили достаточно следов. Часть II представляет собой отчёт в реальном времени об исправлении Remove/Heal и пайплайне публикации, написанный агентом непосредственно по ходу работы.

Быстрый старт

git clone https://github.com/sander110419/lightroom-cc-on-linux.git
cd lightroom-cc-on-linux
./scripts/setup.sh    # ~30 min, mostly downloads
# Then download ACCCx*.zip from Adobe, drop in installers/
./scripts/install-cc.sh
./scripts/install-lightroom.sh
./scripts/run-lightroom.sh

Требования: 64-битный Linux с ядром 6.x+, Wine 11.8 staging, winetricks 20240105+, видеокарта с поддержкой Vulkan, ~10 ГБ свободного места, mingw-w64, действующая подписка на Adobe Lightroom CC.

Почему это интересно

Здесь интересны сразу две вещи: сам рабочий рецепт запуска Lightroom на Linux и артефакт многодневной автономной бинарной отладки, проведённой агентом от начала и до конца. Пропатченные DLL в stubs/binaries/ побайтово совпадают с теми, работоспособность которых проверил агент: md5-хеши в GUIDE.md сходятся с файлами в репозитории. В сами бинарники не просочились абстрактные рассуждения LLM.

Материал стоит в одном ряду с 1password-agentic-refactoring (опыт 1Password по созданию детерминированных инструментов силами агентов) и building-syntaqlite-ai (vibe coding против дисциплинированного проектирования с ИИ). Все три случая указывают на один сдвиг: полезный продукт работы ИИ-агента - это связка агента с тестовым окружением (verification harness), а не агент, генерирующий текст.

darling использует подход Wine в обратную сторону, запуская бинарники macOS на Linux.

Благодарности

• PhialsBasement - форк Wine, исправляющий проблемы установщика CC с mshtml/msxml3.
• Wine project за исходный код d2d1, mfplat, mf.
• Proton GE за базовую версию mfplat.
• sander110419 - поставил задачу, предоставил подписку Adobe, ведёт репозиторий.
• Claude Opus 4.7 - выполнил отладку, написал патчи, провёл верификацию по скриншотам, создал все файлы.

Репозиторий: github.com/sander110419/lightroom-cc-on-linux - 138 звёзд, MIT