Программирование

Продолжаю биться головой о стену DNG SDK .

Вот, к примеру, объявление функции

void dng_negative::SetStage1Image (AutoPtr<dng_image> &image);

Вот как я обычно делаю:

// MyClass.h class dng_image; // Никаких include "dng_.....h", просто forward declaration class MyClass { private: dng_image *image; };

И только там, где у меня implemetation для MyClass - там будет включено "dng_image.h" и мы, наконец, разберемся, что же это такое (а указатель... ну указатель, 4/8 байт, нечего про него знать, private)

Но если интерфейс у dng_negative требует AutoPtr<>,...

Мы продолжаем наш репортаж про Qt и OpenGL.

В Qt, если кто не знает, есть приятные врапперы для OpenGL. QOpenGLShaderProgram для шейдеров, QOpenGLBuffer для буферов ну и так далее. Я ими пользуюсь, потому что удобно, сахарок вкусный типа QOpenGLVertexArrayObject::Binder, опять же деструкторы все удалят и так далее.

И есть QOpenGLTexture, любовь с ней в FRV у меня не задалась (делаю все руками в результате), а тут в рамках HelloWorld-2017 решил вернуться к ней.

И получился (почти)...

Вот значит написал программу, которая ничего (почти) не делает:

$ cat *.cpp *.h *.pro *.frag *.vert *.qrc | wc -l 3584

Нельзя сказать, что совсем уж ничего:

• Окошко есть
  • в окошко выводит OpenGL (или OpenGL ES 3 поверх DX11). Разноцветный треугольник, что еще можно выводить.
  • и конечно с шейдерами, их компиляцией, сохранением/загрузкой бинарного представления и т.п.
  • и сolor management есть (и сохранение/чтение device link LUT, чтобы каждый раз не пересчитывать таблицу)
  • настройки есть, их чтение, сохранение, редактирование (втч.
...

After Qt 5.3’s introduction of QQuickWidget, Qt 5.4 adds QOpenGLWidget, the long-awaited replacement for the legacy QGLWidget.

Писали нам в Qt Weekly три года назад.

Я тогда попробовал, но Qt 5.4 глючила на маке (уже не помню даже в каком месте), держать две ветки кода было не с руки, так и используем legacy QGLWidget в FRV.

Прошло три года и руки дошли попробовать еще раз, уже в Qt 5.6. Такой вот бутерброд (если вкратце):

QGraphicsView...

А вот вы знали, что Adobe XMP SDK может в некоторых случаях при записи XMP модифицировать еще и EXIF у файла?

И я не знал.

А поскольку случаи - некоторые, то в наших тестах оно как-то не вылезло (дальше нецензурно).

Разборки показали, что это, смешно сказать, рекомендованное поведение:

When the file format supports both Exif and XMP, a Changer SHOULD update both forms of a value. If only

...

Волею судеб тут пришлось делать следующие упражнения:

• Собрать некую библиотеку (C++) с помощью Visual Studio 2013 тулсетом для XP (Platform toolset: v120_xp) и использовать ее потом из Visual Studio 2010.
• Собрать некую библиотеку (C++) с помощью Clang (clang-cl, версия 4.0.1) и использовать (вызывать) ее потом из кода, собираемого Visual Studio (в данном случае 2015, но думаю проделать то же с 2010 и 2013). А из clang-собранной библиотеки зовется еще одна, собранная 2015-й студией.

Причина была одна и та же, первая "некая библиотека" не собирается 2010й студией, ибо используемый C++ новее, аналогично и со второй (сходу только Clang/gcc, под MSVC надо править, но очень уж не хотелось).

На удивление, оба варианта проканали вообще без каких-то проблем (я опасался, что придется тянуть всякие чужие C/C++ рантаймы, но нет). Про Clang известно, что над совместимостью по name mangling и подобному там все еще ведутся улучшения, но базовые вещи работают уже.

Еще более на удивление, с clang-cl работают базовые вещи у отладчика VisualStudio (небазовые не пробовал).

Итого: вот просто берешь и используешь (в случае Clang - запускаешь еще батник для интеграции с VS).

Вот что не работает с раздачи, так это cmake, которому указано что используется clang-овский toolset. Оно каким-то чудом узнает, что вот работает clang (хоть и -cl) и пытается совать туда clang-овские же свитчи командной строки, а clang-cl их не понимает. Надо править бы, но я этот ad-hoc язык не знаю и очень не хочу узнавать.

А вот возьмем OS X Sierra. Есть один (то есть единственный) пользователь, на компьютере которого не работает такой вот код:

QString xmpfile = ....; // вычислить имя XMP из имени raw
QFile xmpw(xmpfile);
if (!xmpw.open(QIODevice::WriteOnly)) -> тут обрабатываем ошибку

И ошибка - EACCESS, прав нету

А вот такой вот код работает:

QString xmpfile = ....; // вычислить имя XMP из имени raw
int fd = open(xmpfile.toUtf8().data(), O_WRONLY | O_CREAT | O_TRUNC, 0664);

То есть открывается дескриптор...

А вот, значит, еще про Qt.

Допустим, у нас есть QListView (с кастомными элементами, но это в данном случае несущественно). В нем мелко показаны фигульки.

Хотим: при клике на фигульку спрятать QListView и на его месте показать фигульку крупно (в QGraphicsView, хотя это тоже не так и важно).

Первые грабли зарыты в "спрятать-показать". Если запихнуть их, скажем, в один QLayout и делать  QListView->hide(); QGraphicsView->show(), то оно может валится. Не всегда. При некоторых размерах окна. Ну ладно, сначала show/hide, а потом...

Вот есть такой Qt. А в нем полноценный Model-View: QAbstractItemModel (и потомки), QAbstractItemView (и потомки) ну и "контроллер", то есть делегат.

И вот допустим мы отображаем некий список (произведя его из QListItemModel) в некоем вью (произведя его из QListView). Стандартные средства - хороши, пока их хватает. Иконка, подпись, чекбокс, все есть. Раскраска - стайлшитом.

Идем дальше, стандартных средств не хватает, хотим нарисовать полоску/иконку/хреновинку. Ну отлично, QStyledItemDelegate, базовый класс нарисует основу, мы потом разукрасим.

Правда выясняется, что оформление...