Последние несколько дней я пытался найти библиотеку, которая бы позволила мне писать на C++ программы с GUI. Мои требования были довольно просты:
• Достаточно только поддержки Windows
• Разрешено коммерческое использование
• Простая стилизация, в том числе и тёмный режим
• Результатом должен быть единый файл .exe размером меньше 40 МБ без или с минимальным количеством зависимостей
• Написание части программы с GUI не должно занимать больше времени, чем сама функциональность
Казалось бы, сколько их уже есть, зачем еще один? Но случилось совпадение многих вещей - у меня было свободное время, желание что-то сделать, неудовлетворенность работой официального клиента и нежелание изучать существующие альтернативные версии и перечень их отличий. В результате я реализовал свой Луна-парк, с нужными мне фичами. Подробнее под катом.
Было консольное Python приложение, в котором пишутся логи через стандартный модуль logging. Затем прикрутил GUI на PyQt6, конечно, хочется продублировать логи в какой-нибудь виджет в уголочке. Категорически не хочется ничего менять в консольной части, и спокойно использовать дальше стандартный logging.
В этом посте будет рассмотрено два примера. Простой - виджет, который дублировал бы вывод стандартного Python логгера. Усложнение - имеется несколько потоков, они тоже пишут логи. Нужно их логи тоже увидеть на виджете, но он в родительской части, а потоки не могут напрямую в него писать - получим сегфолт.
В данной статье я опишу свои самые свежие и яркие впечатления от многопоточного программирования. Это мои впечатления, мой опыт и я буду рад, если он будет полезен другим программистам.
В крайней статье я утверждал, что более серьезные проблемы их поджидают в случае взаимодействующих потоков. Но одно эти проблемы предполагать или даже предсказывать, а другое - столкнуться с ними непосредственно.
Предсказанное сбылось, как говорится, по полной программе. Думаю, что озвученные далее проблемы для кого-то не станут новостью, но будут и те, кто о них не подозревает, как не подозревал и я. А потому захотелось их зафиксировать и поделиться, с чем пришлось столкнуться. Ну, и рассказать, как я выкрутился, попав в не совсем привычные для меня ситуации (в автоматном программировании, подчеркну, они не возникли бы в принципе).
Итак, создав ранее тест потоков (о нем подробнее см. [1]), гоняя его многократно и в разных режимах, я заметил, что пусть редко, но выскакивают некорректные результаты. В подобных случаях я грешу обычно на себя. А в данном случае тем более, т.к., что там скрывать, имею весьма небольшой опыт использования потоков.
Но в процессе экспериментов обнажились проблемы, которые сложно списать на недостаток опыты. Что-то при этом удалось преодолеть сразу, с чем-то пришлось повозиться, но были и те проблемы, которые не удалось поправить, даже при наличии достаточно большого опыте в программировании вообще. О последнем, не об опыте, конечно, а о проблемах, и пойдет далее речь... И даже не о проблемах, а о довольно нежданных и негаданных "засадах", возникших на пути освоения многопоточности.
Всех приветствую. Сегодня хочу поделиться опытом создания своего первого проекта на Python. Мой проект — это простой аудиоплеер, и я хочу рассказать, как я его создавал, с какими сложностями столкнулся и что из этого вышло.
Disclaimer. Данная работа не повлияла на мои взгляды на программирование, но повлекла достаточно радикальные изменения в подходах к проектированию автоматных объектов. Теперь, если процесс автономен и/или не предъявляет требований к синхронизации, он может использовать другие механизмы параллелизма, не переставая при этом быть автоматным по сути. А почему так случилось, что этому предшествовало и что это за изменения, вы прочтете далее.
Это не самая большая моя статья (так я думал, начиная ее), над которой я работал, пожалуй, дольше и больше, чем над другими. Но это точно первая моя статья, в которой автоматы и ВКПа не будут главной темой. Тема потоков для меня достаточно необычна, т.к. я совсем не фанат многопоточного программирования. Но, тем не менее, занимаясь параллельным программированием, время от времени возвращаюсь к теме многопоточности. И вот, чтобы добыть какие-то аргументы для критики и одновременно попробовать найти практическое применение потокам, я решил в этот очередной раз более плотно заняться потоками. А что из этого получилось, читайте далее.
Возникла необходимость сделать настройку гроубокса максимально комфортной -- удалённо, без программирования. Все исходные коды доступны по ссылкам в конце статьи. В статье будет упор на программную часть: прошивка гроубокса, графический интерфейс (GUI) для компьютера.
Как-то пару лет назад youtube начал мне подсовывать шахматные видео. Смотрел их, и спустя какое-то время начал играть. Сначала против компа на телефоне, затем на lichess. В какой-то прекрасный вечер мне надоело проигрывать и задался вопросом как бы не проигрывать или после отыгрываться. В итоге игра превратилась в написание чита.
Мы продолжаем изучать PySide6/PyQt6 и сейчас мы с Вами познакомимся с виджетами, компоновкой и Qt Designer
Ссылка на 1 урок с установкой PySide6 и создания первого приложения.
PySide6 включают в себя довольно большое количество встроенных виджетов. Вы можете найти более подробную информацию в официальной документации PySide6.
Сегодня мы с Вами рассмотрим прекрасную библиотеку PySide6, которая является оберткой для взаимодействия с Qt при помощи языка Python, которые позволяет вам использовать Python для написания desktop-приложений Qt.
Итак хочу поделится большой радостью ибо наконец-то сделал универсальное всплывающее окно (на Qt) для индикации (логгирования) хода выполнения каких-то долгих команд.
Основная идея универсальности в вызове у об'екта слота по наименованию , передача параметров через QVariant (до 10шт.), возврат результата тоже через QVariant.
Все это реализуется без проблем через вызов метода invokeMethod.
Через параметры QVariant мы можем передавать и возвращать все , что угодно - какие-то свои классы, главное не забыть в конце определения таких классов добавлять макрос Q_DECLARE_METATYPE(имя вашего класса)
В 1978 году вышел третий том монографии Дональда Кнута «Искусство программирования», где автор рассматривает алгоритмы сортировки и поиска. Помимо самих алгоритмов описаны аппаратные характеристики компьютера и их влияние на производительность при работе с алгоритмами.
В 2024 году мы с вами возьмём классические алгоритмы сортировки и посмотрим, как работает современный многоядерный процессор при сортировке нескольких массивов на одном и нескольких логических ядрах. Мы напишем приложение с графическим интерфейсом (GUI) на фреймворке Qt, обойдем глобальную блокировку интерпретатора (GIL), воспользуемся несколькими потоками, на один из которых переложим выполнение асинхронного цикла событий, и распараллелим этот поток для реализации параллельных вычислений.
Возникла необходимость встроить MLKit в приложение айос. Началось с того, что по каким-то причинам используемые в приложении (андроид и айос) zbar и zxing (работали параллельно для улучшения результатов на обоих ОС) стали плохо работать. В чём проблема я так и не понял, потому-что решил попробовать MLKit – тем более, что они обещали поддержку как для андроида, так и для айос. А ещё потому, что клиенты давно просят добавить распознавание текста – совсем я их разбаловал сканами штрихкодов, VIN (приложение для СТО) и т.п. А тут ещё добавляем новый складской функционал, где для инвентаризации и приёмки нужно много вводить текста, и это на мобильном девайсе. В общем, решено было выбросить zbar/zxing связку и воспользоваться возможностями Google MLKit.
Пошаговая инструкция по созданию отрисовываемого Qt-виджета с возможностью зума и навигации для начинающих.
Как-то так странно получилось, что у нас уже почти год как существует и поддерживается плагин PVS-Studio для Qt Creator. И при этом мы до сих пор не выпустили хорошей статьи с проверкой самой IDE. Исправляем сие недоразумение и предлагаем вам посмотреть, чем живёт недавно переродившаяся среда для разработки.
Всем привет! Начну с небольшой предыстории. Заранее прошу прощения, если эта история вызовет у кого-то скуку или негатив. Здесь будет описываться опыт программирования человеком, который абсолютный ноль в этом. Надеюсь, кого-то это даже позабавит.
Искали статеечку с жалобами джуна о несправедливости IT? Так вот же она!
Открытая к интерпретации история собеседования.
Доброго времени года, уважаемые хабровчане! Я занимаюсь разработкой десктоп‑приложений с 2008 года. Наша компания делает специализированные продукты из области ЦОС (DSP), и GUI выглядит как нечто среднее между AutoCAD, Total Commander и Visual Studio. Не для домохозяек. Без видеоуроков и прочих туториалов особо не попользуешься.
В какой‑то момент мы пришли к необходимости полностью переработать меню наших приложений. Стало очевидно, что классическое меню в связке с панелью инструментов — это не лучшее решение. Когда количество уникальных функций (команд уровня меню) перевалило за сотню, то количество переросло в качество: пользователям стало все сложнее находить для себя требуемый, минимально достаточный work set. Особенно тяжко было новым пользователям. Хоть мы в исправности поставляли и видео‑уроки, и прочие туториалы, это не сильно помогало, поскольку далеко не каждый пользователь был согласен в них залезать. В общем, мы поставили себе задачу понизить порог входа в мир наших продуктов за счет изменения концепции меню.
И тут оказалось (внезапно), что развитие GUI в мире десктопа фактически стоит на паузе. Никто ничего нового особо не предлагает. Я пытался найти в окружающем мире какие‑то интересные gui‑шаблоны. Искал в литературе, искал в дистрибутивах известных desktop‑продуктов, поглядывал и на мобилки. Но нигде не нашел. Весь мир был слишком занят мобильной и веб‑разработкой. А гиганты десктопа (Adobe, Microsoft) были слишком связаны принципом «не трогай, если работает» (ну, или просто погрязли в собственном спагетти‑коде). Наконец, я перестал кого‑то ждать и сам сел за решение. И я его придумал и внедрил в нашу продуктовую линейку. И теперь хочу поделиться им с вами.
Чтобы мое решение было проще понять, я не буду его описывать на примере наших, узкоспециализированных программных продуктов ЦОС. Я просто покажу, как будет выглядеть всем известная среда разработки Microsoft Visual Studio, если применить к ней мой принцип формирования меню приложения.
Привет, хабр! Сегодня мы создадим свой собственный терминал на языке программирования C++. Я являюсь фанатом Linux, и пользуюсь минималистичными терминальными программами - от Vim как IDE до чатов. Есть множество терминалов, у каждого из них есть плюсы и минусы. Наш терминал не будет претендовать на место серьезного проекта, но если вы хотите улучшить код, который мы сегодня напишем - то вы молодцы, можете без проблем развить наш терминал.
Это будет небольшой, минималистичный терминал для Linux. Он будет на основе фреймворка Qt 5 и библиотеки qtermwidget5.
И эта будет не одна статья, а целая серия статей!
Периодически встречающаяся проблемами кода на С и C++ являются утечки памяти и неопределенное поведение. Даже если вы используете умные указатели, то от ошибок в библиотеках сторонних разработчиков вы не застрахованы. Для поиска ошибок в коде существуют специальные инструменты: санитайзеры и valgrind. Однако, не вся информация об ошибках имеет для нас ценность, рассмотрим методы её фильтрации.
