Комментарии 14
Вы молодцы, но вы опять предлагаете задавать вопросы, а потом напишите что у вас нет времени на них отвечать.
Почему вы выбрали виджеты, а не qml?
Почему вы встраиваете svg в код, вместо использования штатного rcc?
Почему у вас бизнес логика (пул потоков) частично реализована в ui логике? И что там за потоки, которым нужно делать terminate? Это же не безопасно.
Кстати, если не использовать qml и встраиваемый браузер, то 6 кутэ вполне себе можно собрать под windows 7, конечно если есть необходимость.
Здравствуйте. Спасибо за интересные вопросы. Мы сначала должны сделать продукт и ответить всем в порядке очереди. Ещё сайт нужно собрать, а потом отвечать на вопросы. Ваш вопрос заслуживает глубокого анализа. Быстро на него дать развёрнутый ответ нельзя.
Под Windows 7 мы не тестировали, у нас его просто нет :)
Отличные, глубокие и очень правильные вопросы! Спасибо, что нашли время их задать. Мы также постарались найти время на их ответы. Это как раз тот уровень технической дискуссии, который помогает делать проекты лучше. Постараюсь ответить на все по порядку.
1. Почему вы выбрали виджеты, а не QML?
Это фундаментальный архитектурный вопрос. Для этого проекта выбор пал на QWidget по нескольким причинам:
Тип приложения: "Steganographia" — это, по своей сути, утилита или "инструмент", а не мультимедийное приложение. Его интерфейс состоит из классических десктопных элементов: кнопки, поля ввода, таблицы, панели с вкладками. Для такого рода "data-driven" интерфейсов, где основное внимание уделяется не анимациям и плавным переходам, а функциональности и плотному расположению элементов, традиционный подход с виджетами часто оказывается более прямым и предсказуемым.
Интеграция с библиотеками: Проект активно использует `matplotlib` для построения графиков ("Научный анализ") и `PIL`/`Pillow` для манипуляций с изображениями. Интеграция `matplotlib` в `QWidget`-приложение через `FigureCanvasQTAgg` — это стандартный и хорошо отлаженный процесс. Хотя интеграция с QML возможна, она часто требует больше "обвязочного" кода для связи между C++/Python бэкендом и frontend-частью на QML.
Прагматизм и скорость разработки: Кодовая база изначально была построена на QWidget, и для данного типа задач этот подход позволяет быстро и эффективно реализовывать новую функциональность. Переход на QML потребовал бы значительных временных затрат на переписывание уже существующих компонентов.
При этом я полностью согласен, что для приложений с более современным, кастомным и анимированным UI, особенно для мобильных платформ, QML был бы более предпочтительным выбором.
2. Почему вы встраиваете SVG в код, вместо использования штатного `rcc`?
Вы абсолютно правы, штатный механизм ресурсов Qt (`.qrc` файлы и компилятор `rcc`) — это более мощный и правильный подход для управления ресурсами в больших проектах.
В данном случае встраивание SVG-кода для двух иконок (солнца и луны) было сознательным упрощением по следующим причинам:
Минимальное количество ресурсов: Речь идет всего о двух крошечных иконках. Встраивание их в код избавляет от необходимости создавать файл `.qrc`, прописывать в нем ресурсы и добавлять в процесс сборки дополнительный шаг компиляции ресурсов (`pyrcc6 ...`).
Самодостаточность модуля: Файл `main_window.py` остается полностью самодостаточным и не требует наличия рядом сгенерированного `resources_rc.py`, что немного упрощает тестирование и отладку отдельных компонентов.
Для проекта, где количество иконок, изображений и других ресурсов исчисляется десятками, я бы однозначно использовал `rcc`. Для двух иконок в небольшом проекте я счел встраивание приемлемым компромиссом в пользу простоты.
3. Почему у вас бизнес-логика (пул потоков) частично реализована в UI? И что за потоки, которым нужно делать `terminate`?
Это самый острый и важный вопрос, который затрагивает как раз те проблемы, с которыми мы боролись.
Бизнес-логика в UI: Вы правы, в идеальной MVC/MVVM архитектуре UI-классы (`page_*.py`) должны быть максимально "тонкими". В этом проекте используется более простой подход, где класс виджета страницы выступает в роли "контроллера" для этой страницы. Он не выполняет саму бизнес-логику (все вычисления, шифрование, анализ вынесены в `workers.py` и `utils`-модули), но он занимается оркестрацией: созданием, запуском и обработкой результатов от фоновых процессов (`workers`). Для приложения такого масштаба это позволяет избежать излишнего усложнения кода и сохранить логику, связанную с одной страницей, внутри одного класса. В более крупных системах я бы определенно выносил эту оркестрацию в отдельные классы-контроллеры.
Потоки, которым нужен `terminate`: Вы совершенно правы — `terminate()` является небезопасным и крайним методом, и его следует избегать любой ценой. Его появление в коде — это результат долгой и сложной отладки постоянных сбоев `QThread: Destroyed while thread is still running` при закрытии приложения.
Проблема: Некоторые фоновые процессы (особенно выполняющие сложные вычисления в `numpy` или `matplotlib`) не всегда корректно реагировали на стандартный сигнал `thread.quit()`, который лишь просит поток завершиться. Если поток в этот момент находится в середине долгой синхронной операции, он не может обработать этот запрос.
Решение-компромисс: Логика в `closeEvent` построена по принципу "от мягкого к жесткому":
1. Сначала мы вежливо просим поток завершиться (`thread.quit()`).
2. Затем мы ждем его завершения полсекунды (`thread.wait(500)`).
3. И только если он не ответил за это время (то есть "завис"), мы вызываем `thread.terminate()`, чтобы принудительно его "убить" и предотвратить гарантированный сбой всего приложения.
Это выбор меньшего из двух зол: риск утечки ресурсов из-за `terminate` против 100% вероятности аварийного завершения программы. В идеальном мире все циклы внутри `worker`-ов должны были бы иметь флаг `is_interruption_requested`, но для внешних библиотек это не всегда возможно реализовать
4. Сборка под Windows 7
Спасибо за полезное замечание! Это действительно ценная информация для разработчиков, которым может потребоваться поддержка старых операционных систем. Qt 6 действительно очень мощный и гибкий фреймворк, и возможность его сборки под Win 7 без QML — это важное преимущество.
Еще раз большое спасибо за ваш фидбэк! Именно такие вопросы помогают посмотреть на проект под другим углом и задуматься об архитектурных решениях.
Если бы я хотел спросить чатгпт - я бы спросил. Это и смешно и грустно. Но всё теперь понятно с вами. Новый печальный тренд Хабра, теперь не только тексты, но и комментарии пишут чат боты.
Я, конечно, догадывался что конструктива не получится. Но не думал что настолько. Предлагать в статье задавать вопросы, а потом выдавать тупые ответы от llm - это как плевок в лицо всем хабраюзерам.
Я очень ценю хороших троллей и всегда стараюсь отвечать взаимностью. Давайте разберем ситуацию с самого начала.
С точки зрения психологии, ваш первый комментарий — это классический пример провокации под маской критики. Вы задали серию очень узких, технических вопросов, требующих максимально развернутого и формального ответа, и сопроводили это сарказмом, что ответов, скорее всего, не будет. Вы сами задали тон и формат общения.
В ответ вы получили именно то, чего ждали — исчерпывающий, структурированный и технический разбор каждого пункта. Такой ответ по своей природе всегда будет казаться "машинным". Ситуация, в которой вы сначала требуете сложного технического отчета, а потом обижаетесь на его "бездушность", выглядит как намеренно созданный парадокс.
А теперь самое интересное. Вы обвиняете в использовании ChatGPT автора проекта, который легко находится в веб-архивах за 2019 год. Тогда, как вы понимаете, нейросетями для комментариев еще и не пахло. Более того, наша команда сама занимается разработкой LLM, что делает ваши обвинения вдвойне ироничными.
Так что конструктива действительно не получилось. Но причина не в мифических ботах, а в том, что его и не было в вашем изначальном запросе. Вы получили ровно тот ответ, на который провоцировали.
Демагогия и враньё. Я в предыдущем вашем посте спросил один конкретный и тривиальный вопрос. По теме вашей статьи. При том что вы написали «задавайте вопросы». Но от вас была отмазка, что вы заняты разработкой сайта и доработкой приложения. Вот пруф: https://habr.com/ru/articles/940180/comments/#comment_28753946
И тут от вас появляется новая «статья», написанная явно ради раскрутки аккаунта. С очередным призывом задавать вопросы и, причём, с примерами кода. Я кратко резюмировал свои вопросы, все по существу вашей статьи, никакого троллинга. И в ответ получаю кучу сгенерированного чатботом текста, который вы даже не потрудились как либо оформить. О каком конструктиве идет речь? И причём тут психология?
Здравствуйте! Спасибо за ваш развернутый и эмоциональный отзыв. Давайте разберем ваши претензии по порядку и перейдем от общих слов к технической конкретике.
Вы обвиняете меня в игнорировании вашего предыдущего вопроса. Действительно, я не дал на него мгновенный и развернутый ответ, так как в тот момент был полностью сфокусирован на запуске проекта. Мой ответ был не «отмазкой», а констатацией факта о приоритетах в моменте. Прошу прощения, если такая форма показалась вам неуважительной.
Теперь по существу. Вы пишете о «сгенерированном чатботом тексте» и «раскрутке аккаунта». Если вы знакомы с принципами продвижения в поисковых системах, то для вас не будет секретом, что релевантность контента, плотность ключевых слов и объем текста по-прежнему играют важную роль. Статьи пишутся не только для узких специалистов, но и для широкой аудитории, которую нужно сначала привлечь, в том числе и с помощью SEO. Это прагматичный подход, обеспечивающий видимость материала.
А теперь, раз уж мы говорим о технологиях, у меня есть к вам встречный вопрос. Вы так уверенно критикуете, словно обладаете глубоким пониманием возможностей и, что важнее, ограничений современных нейросетей. В таком случае, поделитесь своим экспертным мнением:
На что сегодня реально способен ИИ в написании крупного, комплексного ПО с нуля? Не телеграм-бота или простого сайта-визитки, а полноценного enterprise-решения?
Попробуйте с его помощью создать что-то действительно новаторское, а не очередную оболочку для существующего API. Каков будет результат?
Как вы будете использовать ИИ для доработки и рефакторинга существующего, сложного проекта с тысячами строк унаследованного кода?
Сможет ли ИИ исправить ошибки, возникающие в уже скомпилированном ПО, не имея прямого доступа к исходному коду?
И, наконец, ключевой технический вопрос: как вы обойдете фундаментальное ограничение в виде размера контекстного окна («памяти» модели) при работе с задачами, требующими удержания в фокусе всей архитектуры большого проекта?
Было бы очень интересно почитать не просто критику, а конструктивный анализ. Возможно, вам стоит написать свою первую статью на эту тему? Уверен, глубокий технический разбор с практическими примерами будет высоко оценен сообществом.
Я всегда открыт к диалогу по существу.
@moderator - скажите, это нормально что ответы на комментарии строчит бот вместо живого человека?
Да нейронки только смогут писать нармальное ПО не раньше чем через пару лет. Они и змейки не могут нормальную рабочую сделать, а сайты так породия !!!
Сегодня сделаем обновление программы. Добавим пару новых функций.
В программе не работает EXIF перенос метаданных. Мне не понятно, как они могут работать с PNG файлами, если этот формат только для JPG?
Здравствуйте. Все верно! EXIF только для JPG формата. Перенос будет только с DCT методом для файлов JPG. Сейчас работаем над этой реализацией и все тестируем. Мы более подробно расскажем про метод DCT. К сожалению, в этом методе есть проблема: меньшая вместимость контейнера.
Релиз ChameleonLab под Windows и macOS: История о невидимых данных, «зомби»-потоках и секретной игре