Бывает необходимость в вашем приложении отобразить ту или иную стандартную системную иконку, типа значка диска CD-ROM. Можно, конечно, создавать свой ресурсный файл и ложить иконки туда, но это будет выглядеть несуразно, особенно при смене различных тем оформления. Задаёмся резонным вопросом: а как бы использовать то, что уже есть в Qt и/или системе?

Вариант 1: стандартные ресурсы Qt4

Про это написано тут: http://www.qtcentre.org/wiki/index.php?title=Embedded_resources

Помимо списка, приведён и код, которым можно получить список самостоятельно. Так же показан пример, как создавать изображение из ресурса:

QPixmap pixmap(":/trolltech/styles/commonstyle/images/up-128.png");
QIcon   icon(":/trolltech/styles/commonstyle/images/up-128.png");

Вариант 2: стандартные иконки при помощи QStyle

Сылки по теме:

1. http://doc.trolltech.com/latest/qstyle.html#standardIcon
2. http://doc.trolltech.com/latest/qstyle.html#StandardPixmap-enum

Собственно что нам нужно, это метод класса QStyle:

QIcon QStyle::standardIcon ( StandardPixmap standardIcon, const QStyleOption * option = 0, const QWidget * widget = 0 ) const

Иконки опеределяются перечислением StandardPixmap

Вариант 3: использование иконок темы оформления

Тут, скорее всего, всё будет очень сильно зависеть от платформы. Но в общем случае, нам нужен такой вызов:

QIcon icon(QIcon::fromTheme(QString::fromUtf8("icon-name")));

icon-name имя иконки, возможные значения, стандартные, для Linux можно узнать тут: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html

На выходных готовил растровую карту для похода на Кодар, с последующей конвертацией оной в JNX.

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

В результате, подумал и написал за выходные две программы: ozi2map и geocrop

ozi2map

Данная утилита более не актуальна. Версия GDAL (>=1.10), входящая во все популярные дистрибутивы, уже умеет сама обрабатывать такие MAP файлы.

Первая, как можно понять из названия, предназначена для конвертации карты с привязкой OZI (сама карта в JPEG или GIF или другом распространённом растровом формате, который поддерживает OZI, но не OZFX/OZFX2/OZFX3, для них преобразования можно сделать средствами самого gdal (в прошлых статьях писал про это)).

Для чтения точек привязки и параметров проекции используется функция из недр GDAL: GDALReadOziMapFile(...), что, в отличии от питоновского ozi2geotiff.py, даёт корректные параметры проекции. Далее, не стал особо заморачиваться и подсовывая нужные параметры gdal_translate/gdalwarp вызываю их через system().

Я вообще не стал лезть в разбор map файла, поэтому файла растра автоматически не определяется и его нужно указывать самому: ./ozi2map O-50-103.map O-50-103.jpg ./ozi2map O-50-103.map O-50-103.jpg O-50-103.tif

Если имя выходного файла не задано, имя будет сформировано из имени растра с заменой расширения на .tif.

Всё, пользоваться программой должно быть проще простого. Найти исходники (GPLv2) можно тут:

https://git.gitorious.org/h4tr3d-utils/ozi2map.git

Собирать просто: make

Полученный бинарник можно запускать от куда угодно.

geocrop

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

Т.е. по сути, программе на вход нужен только масштаб листа (в виде 1M, 500k, 200k, 100k, 50k, 25k, 10k, 5k, 2k) и сам лист карты в формате, поддерживаемом GDAL с корректной привязкой.

Когда расчёты по привязке будут выполнены, вызывается gdalwarp через system(). Полигон для обрезки формируется в координатах листа (не в точках растра), для всех листов, кроме 1M, это 4х угольник (на будущее будет более качественно сделано, но и текущего результата хватит в 99.99% случаев).

Пользоваться программой не сложнее чем ozi2map: ./geocrop -s 100k O-50-103.tif O-50-103-crop.tif

Первым аргументом - стилизованное обозначение масштаба:

• 1M - 1:1 000 000 (это масштаб используется, если мнемоника не распознана)
• 500k - 1:500 000 (“пятикилометровка”)
• 200k - 1:200 000 (“двухкилометровка”)
• 100k - 1:100 000 (“километровка”)
• 50k - 1:50 000 (“полукилометровка” или “пятисотметровка”)
• 25k - 1:25 000 (“двухсотпятидесятиметровка”)
• 10k - 1:10 000 (“стометровка”, пока не реализовано)
• 5k - 1:5000 (“пятидесятиметровка”, пока не реализовано)
• 2k - 2:2000 (“двадцатиметровка”, пока не реализовано) Если этот параметр пропущен, используется масштаб 100k.

Вторым аргрументом - входной файл, поддерживаемый GDAL.

Третий аргумент - выходной, кропнутый файл. По умолчанию - GeoTiff, но можно переопределить опцией “-f FORMAT”, где FORMAT - любой поддерживаемый GDAL.

Если хотите обрезанные карты потом склеивать при помощи gdal_merge.py, и получить вразумительные результат, входной файл должен быть в цветовой палитре RGB, узнать это можно при помощи утилиты gdalinfo, если в выводе есть такое:

Band 1 Block=4096x1 Type=Byte, ColorInterp=Red
Band 2 Block=4096x1 Type=Byte, ColorInterp=Green
Band 3 Block=4096x1 Type=Byte, ColorInterp=Blue

значит всё хорошо, если нет (выводится палитра из 255 цветов), то палитра индексированная, нужно преобразовать в RGB при помощи утилиты pct2rgb.py из комплекта GDAL.

Собирать просто: mkdir build cd build cmake .. make

Если на стадии cmake будут какие-то проблемы, стоит поставить dev-пакеты для GDAL и PROJ.4

Исходники можно взять тут (GPLv2):

https://github.com/h4tr3d/geocrop

Суть проблемы: при отработке утилит вроде ozi2geotiff получался geotiff который потом не читался в том же QLandkarteGT и утилитами самого gdal (типа того же gdalwarp). Самое печальное, что это коснулось и файлов привязок для карт с росгисцентра (в формате .pgw + .prj (первый - привязка в формате ESRI World file, второй - описание проекции в формате WKT((Well Known Text))), картами и привязками можно разжиться тут или на http://rutracker.org поиском по слову ggc).

Печально потому, что если положить рядом файл карты в .png, файл привязки .pgw и описание проекции .prj (имя файла без расширения при этом должно быть одинаковым), то получить geotiff становится проще простого: gdal_translate -of GTiff -a_srs O-50-103-D.prj O-50-103-D.png O-50-103-D.tiff

Файл .pgw подхватывается автоматически, дополнительно его указывать не нужно (об этом же говорится в официальной документации про поддержку PNG: http://www.gdal.org/frmt_various.html).

В печали я написал в список рассылки разработчиков gdal, к утру получил ответ от Frank Warmerdam, с уведомлнем, что он попытался на последне версии gdal и проблемы не наблюдает. Попытался собрать и тоже проблема самоустранилась, при этом, gdalinfo выдал корректную информацию для файлов сгенерированных старым gdal_translate, эти же карты после обновления открылись и в QLandkarteGT. Так что, у кого стоит gdal 1.9.0, нужно срочно обновляться (вроде как проблемы нет уже в 1.9.1, но не проверял)

Полезные ссылки:

• http://geotiff.maptools.org/faq.html#WorldFile2
• What are the .TFW, .JGW or .PGW files?
• gdal-svn в AUR для ArchLinux

В интернетах уже есть заметки по этой тематике, например ссылки приводил в post/2009-03-15_11.42_paru_zametok_o_qlandkartegt, но что бы было под рукой. Опускаться до того, в какой пункт меню заходить не буду, приведу чисто технические моменты.

Исходные данные: лист километровки О-50-103.tiff

На первом шаге нужно указать проекцию карты, для нашего родного генштаба проекция будет примерно такого вида:

+proj=tmerc +lat_0=0 +lon_0=117 +k=1 +x_0=20500000 +y_0=0 +ellps=krass +units=m +no_defs

+proj=tmerc +lat_0=0 +lon_0=117 +k=1 +x_0=20500000 +y_0=0 +ellps=krass +towgs84=23.9,-141.3,-80.9,0,-0.37,-0.85,-0.12 +units=m +no_defs

(параметр towgs84, определяет параметры перехода к датуму wgs84, который используется в том же GPS, этот параметр автоматом добавится, если в мастере настройки проекции выбрать датум Pulkovo 1942)

собственно для каждого листа миллионки она будет своя, жирным выделено то, что будет меняться от листа к листу. Теперь пояснения:

• lon_0 - центральный меридиан
• x_0 - мнимый восток (false easting)

В статье post/2011-06-26_14.58_gotovim_rastrovuju_kartu_dlja_navigatora_garmin_gpsmap_62s я уже показывал как рассчитывать эти параметры, продублирую и здесь:

lon_0 = Nз * 6 - 3            # центральный меридиан по известной зоне
x_0   = Nз * 1000000 + 500000 # мнимый восток (false easting)
Nз    = floor(lon / 6) + 1    # номер зоны по любому значению долготы на листе, floor - взятие целой части от деления
Nз    = (lon_0 + 3) / 6       # номер зоны по центральному меридиану (частный случай)

Как видно, оба параметра зависят от номер зоны, что бы не заморачиваться, есть ещё один очень простой способ определения её: по номеру листа, вычитая из него 30. Т.е. лист у нас O-50, значит его номер - 50, тогда:```scilab Nз = 50 - 30 = 20

Тогда значения центрального меридиана и мнимого востока:```scilab
lon_0 = 20 * 6 - 3 = 117
x_0   = 20 * 1000000 + 500000 = 20500000

Так же, для простоты, можно принять, что мнимый восток это: 500000 перед которым написан номер зоны, как он есть, т.е. как результат объединения двух строк (в программировании):``` “20” + “500000” = “20500000”

Давно пользуюсь услугами cppcheck, но решил поглядеть что есть ещё (как оказалось, лучше, по сути, ничего и нету). Наткнулся на статью по теме на хабре: http://habrahabr.ru/post/75123

Тезисно:

• Педантичные ключи для gcc (сам автор отсылает за подробностями: http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html), особо хочется отметить неизвестный мне ключ -Weffc++, включает проверку на соответствие рекомендациям Скотта Майерса. Результат сборки моего последнего проекта поверг в уныние: будет ещё работы по вычистке.
• cppcheck (в арчике есть в стандартных репах)
• vera++ (есть в AUR)
• rats (есть в AUR)
• проверялки для чистого Си (как оказалось(( http://www.cert.org/secure-coding/tools.html и http://www.cs.cmu.edu/~aldrich/courses/654/tools/index.html)) их значительно больше, нежели для C++)

Далее, Анализ утилит статического анализа C++ кода, автор рассматривает следующие анализаторы:

• rats (выше писал)
• cppcheck (аналогично)
• Graudit (есть в AUR)

причём рассматривает проблемы, которые они не выявляют.

Список статических анализаторов можно поглядеть на страничке в википедии: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis, причём не только для C/C++

Для интереса можно почитать перевод статьи Джона Кармака о статическом анализе: http://habrahabr.ru/post/135234/((Оригинал статьи: altdevblogaday.com/2011/12/24/static-code-analysis/)), где кратко излагается, какими инструментами ему довелось воспользоваться, и какие впечатления остались после них.

И на последок серия из четырёх заметок камрада Andrey2008((Один из разработчиков PVS-Studio, поэтому малость пропускаем его отсылы к этому продукту)) “Как уменьшить вероятность ошибки на этапе написания кода”:

• Заметка №1:
  1. Избегайте функции memset, memcpy, ZeroMemory и им аналогичные
  2. Внимательно следите, работаете вы со знаковым или беззнаковым типом
  3. Избегайте большого количества вычислений в одной строке
  4. Выравнивайте в коде всё, что возможно
  5. Не размножайте строку более, чем один раз
  6. Выставляйте высокий уровень предупреждений у компилятора и используйте статические анализаторы
• Заметка №2
  1. Не используйте тернарную операцию ‘?:’ в составных выражениях
  2. Не стесняйтесь использовать скобки
• Заметка №3 - на примерах ошибок в Qt4
  1. Обрабатывайте переменные в той же последовательности, как они объявлены
  2. Табличные методы — это хорошо
  3. Разное интересное (про разные и интересные ошибки в Qt4)
• Заметка №4 - на примерах ошибок в Firefox

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

Error: in bind call: /home/user/.config/luakit/webview.lua:341: attempt to perform arithmetic on local 'p' (a nil value)

Решение проблемы нашёл тут: https://github.com/mason-larobina/luakit/issues/68, нормальный рабочий вариант получается этот: https://github.com/mason-larobina/luakit/issues/68#issuecomment-5528890

На правах заметки: цикл статей о многопоточности в C++.

В цикле рассматриваются создание обёртки над pthreads((ссылки по теме:

1. POSIX_Threads
   
   
2. POSIX Threads Programming
   
   
3. Краткое описание pthread (threads))), использование boost::thread, а так же использование идиомы RAII|RAII (Захват ресурса есть инициализация) в контексте потоков.

• Multithreaded C++: Part 1: Pthreads
• Multithreaded C++: Part 2: Boost Threads
• Multithreaded C++: Part 3: RAII And Threads

Вообще, блог Empty Crate крайне рекомендую к ознакомлению - интересные заметки по программированию на C++.

Так же в тему многопоточности concurency в C++0x (но всё это можно переложить, с небольшими оговорками и на boost::thread) серия статей в блоге Just Software Solution:

• Multithreading in C++0x part 1: Starting Threads
• Multithreading in C++0x part 2: Starting Threads with Function Objects and Arguments
• Multithreading in C++0x part 3: Starting Threads with Member Functions and Reference Arguments
• Multithreading in C++0x part 4: Protecting Shared Data
• Multithreading in C++0x Part 5: Flexible locking with std::unique_lock<>
• Multithreading in C++0x part 6: Lazy initialization and double-checked locking with atomics
• Multithreading in C++0x part 7: Locking multiple mutexes without deadlock
• Multithreading in C++0x part 8: Futures, Promises and Asynchronous Function Calls

Достаточно запустить: dia –integrated

теперь вполне можно пользоваться.

Ну и чуть ярости: ну какого чёрта не вынести это в настройки!?

Первый тестовый пост после обновления PHP с 5.3.10 на 5.4.3 и отказа BlogTNG.

Причина: BlogTNG использует SQLite2, который выкинули из PHP 5.4.0.

Не всё делается одинаково во всех компиляторах, не на всех платформах, приходится временами городить хитрые конструкции из #if/#elif/#endif. Случайно наткнулся на шпаргалку, в которой описано, какие директивы препроцессора предопределяют конкретные компиляторы: http://sourceforge.net/p/predef/wiki/Compilers/

С того же ресурса:

• для операционных систем: http://sourceforge.net/p/predef/wiki/OperatingSystems/
  • версии Windows: https://msdn.microsoft.com/en-us/library/6sehtctf.aspx
    • в рантайме:
      • https://msdn.microsoft.com/en-us/library/windows/desktop/ms724439(v=vs.85).aspx (устарела)
      • https://msdn.microsoft.com/en-us/library/windows/desktop/dn424972(v=vs.85).aspx
• для стандартов языка: http://sourceforge.net/p/predef/wiki/Standards/
• для стандартных библиотек (реализаций) C и C++: http://sourceforge.net/p/predef/wiki/Libraries/
• для архитектур: http://sourceforge.net/p/predef/wiki/Architectures/

А так же определение порядка байтов: http://sourceforge.net/p/predef/wiki/Endianness/

Другие ссылки на эту тематику:

• C/C++ tip: How to detect the compiler name and version using compiler predefined macros