Доброго времени года, уважаемые хабровчане! Я занимаюсь разработкой десктоп‑приложений с 2008 года. Наша компания делает специализированные продукты из области ЦОС (DSP), и GUI выглядит как нечто среднее между AutoCAD, Total Commander и Visual Studio. Не для домохозяек. Без видеоуроков и прочих туториалов особо не попользуешься.

В какой‑то момент мы пришли к необходимости полностью переработать меню наших приложений. Стало очевидно, что классическое меню в связке с панелью инструментов — это не лучшее решение. Когда количество уникальных функций (команд уровня меню) перевалило за сотню, то количество переросло в качество: пользователям стало все сложнее находить для себя требуемый, минимально достаточный work set. Особенно тяжко было новым пользователям. Хоть мы в исправности поставляли и видео‑уроки, и прочие туториалы, это не сильно помогало, поскольку далеко не каждый пользователь был согласен в них залезать. В общем, мы поставили себе задачу понизить порог входа в мир наших продуктов за счет изменения концепции меню.

И тут оказалось (внезапно), что развитие GUI в мире десктопа фактически стоит на паузе. Никто ничего нового особо не предлагает. Я пытался найти в окружающем мире какие‑то интересные gui‑шаблоны. Искал в литературе, искал в дистрибутивах известных desktop‑продуктов, поглядывал и на мобилки. Но нигде не нашел. Весь мир был слишком занят мобильной и веб‑разработкой. А гиганты десктопа (Adobe, Microsoft) были слишком связаны принципом «не трогай, если работает» (ну, или просто погрязли в собственном спагетти‑коде). Наконец, я перестал кого‑то ждать и сам сел за решение. И я его придумал и внедрил в нашу продуктовую линейку. И теперь хочу поделиться им с вами.

Чтобы мое решение было проще понять, я не буду его описывать на примере наших, узкоспециализированных программных продуктов ЦОС. Я просто покажу, как будет выглядеть всем известная среда разработки Microsoft Visual Studio, если применить к ней мой принцип формирования меню приложения.

Как правило, при создании desktop-приложений на платформе Qt не возникает проблем, связанных с медленностью работы GUI. Qt – платформа достаточно надежная, неплохо вылизанная по всем параметрам, в том числе и по скорости работы. Однако всё же иногда бывают ситуации, когда из-за обилия виджетов графический интерфейс немного притормаживает, и это печально). В этой статье я приведу один частный пример простого графического интерфейса и покажу, как за два шага можно сначала ускорить его в 11 раз, а потом и в целых 34 раза. Вдобавок к этому, я постараюсь немного осветить механизм принятия решения для таких оптимизационных задач, постараюсь показать направление мыслей для правильного решения. Поехали!

В прошлой статье мы начали рассказ о рецептах, посвященных переводу Qt-приложений на рельсы High DPI, то есть адаптации этих приложений к мониторам высокой четкости.

Суть в том, что в ОС Windows давно есть такие настройки, как масштабирование шрифта и изображений (масштаб экрана), которые применяются для увеличения слишком малых элементов GUI на мониторах с высокой чёткостью (High DPI). Однако не каждое приложение, написанное на Qt, способно адекватно учитывать, применять этот самый масштаб экрана. Частая ситуация – приложение хорошо выглядит на Full HD (1920x1080), но стоит поставить монитор 4K (3840x2160) и увеличить масштаб экрана, то появляются многочисленные артефакты.

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

В связи с техническим прогрессом рынок мониторов постоянно обновляется моделями с повышенным разрешением, плотностью пикселей и/или размером экрана. Году в 2010 стандартным монитором можно было считать экземпляр 19’’ c разрешением WXGA++ (1600*900) и фактической плотностью пикселей 97 DPI (dots per inch). Сейчас (2021 год) стандартным монитором, думаю, можно признать экземпляр 24’’ c разрешением Full HD (1920*1080) и плотностью пикселей 92 DPI. Под «стандартным» я понимаю тот монитор, который стоит на рабочем месте у большинства работающего люда: инженеры, бухгалтеры, переводчики и т.д. (при этом, конечно, «стандартность» — это субъективная и приблизительная оценка). Относительно новые и отчасти нишевые модели (для фотографов, видеографов, геймеров) имеют характеристики: 4K UHD (3840*2160) и 28’’ (157 DPI) или UWQHD (3440x1440) и 34" (109 DPI) или QHD (2560x1440) и 27" (109 DPI) или UWHD (2560x1080) и 29" (96 DPI). Таким образом, наблюдается рост в связанных группах признаков: разрешение+размер экрана, или разрешение+плотность пикселей, или даже разрешение+плотность пикселей+размер экрана. На рынке ноутбуков в плане экранов похожая ситуация – растет разрешение+плотность пикселей.

К сожалению, не всегда программное обеспечение поспевает за ростом характеристик мониторов. Нередко оно выглядит немного коряво и неухоженно, что расстраивает пользователя. Действительно, на дворе 21 век, а зачастую приходится видеть размытые шрифты, а иногда и микроскопические иконки.

Что касается высокой чёткости (большой плотности пикселей), то в ОС Windows давно есть такие настройки, как масштабирование шрифта и изображений (масштаб экрана), которые применяются для увеличения слишком малых элементов GUI на мониторах с высокой чёткостью (High DPI). Также есть поддержка в платформе Qt (с нюансами, об этом далее). Однако способно ли Ваше, конкретное ПО их адекватно учитывать, применять?

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

Эта статья посвящена разным инструментам, которые можно с той или иной степенью успешности применять для отлова утечек памяти в С++/Qt приложениях (desktop). Инструменты будут рассмотрены в связке с IDE Visual Studio 2019. В статье будут рассмотрены не все возможные инструменты, а лишь наиболее популярные и эффективные.

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

• Отрисовка классического «офисного» GUI типа кнопок, прогресс-баров, виджетов, анимации.
• Отрисовка любой нестандартной графики типа непрерывно движущихся графиков из миллионов точек.
• Работа с базами данных
• Работа с сетью
• Работа с реестром операционной системы
• Работа с принтером
• Быстрое (в том числе параллельное) выполнение сложных вычислительных задач.
• И многое, многое другое.