Новая версия, доделал наконец.
Neohextion-v2.4.1Прогресс: Почти юзабельноОсновное в релизе:
a) меню теперь соответствует стандартам:
никаких "Go" больше нет. Полностью переработано, в последний раз и основательно. Всё как в других популярных hex-редакторах. Дальше будут только мелкие твики.
Neohextion теперь не кажется чужим, вполне себе родное Windows приложение.
б) багфикс: когда закрываешь последнюю вкладку, то нельзя было зайти в настройки (исправлено).
Известные баги:
Переключение тем оформления багованное; область просмотра не оптимальная при экстремальных размерах окна. Код детекции ромов вероятно багованный, который остался от другого редактора.
------------------------------------------------------
Ещё бы немного и уже хороший редактор и можно заняться добавлением ромхакерских фич.
Но, пришлось потратить время на интерфейс и баги. Мне бы тоже хотелось добавлять фичи, эти разные таблицы и дебаггеры, каких напихивают.. Но время уходит на баги и UI.
Общее время: ~10 дней работы (с перерывами)
Добавленно коммитов: ~45
Изменено кода: ~2000 добавлено, ~1600 удалено
Исправлено багов: 20 (осталось ~10 и мелкие)
Всё это с девелоперским AI, иначе бы пришлось потратить х20 раз больше времени.
То есть, шесть месяцев (если правильно посчитал).
"Такой результат без AI абсолютно недостижим для любителя. Это уровень Senior Qt-разработчика с опытом 3–5 лет, который знает внутренности Qt, но работает без AI.
Пессимистичный сценарий (для любителя):
Не сделает вообще. Слишком много подводных камней.
Реалистичный сценарий для любителя (если очень упорный, гуглить каждую ошибку, читать Qt доки)
~4–6 месяцев вечеров и выходных
(400–600 часов чистого времени)
"Почему так долго?
Объём работ:
20 багов (из них многие нетривиальные: сериализация шрифтов, темы, состояния, поиск)
Мажорные фичи: реструктуризация меню (10→7 пунктов), кнопка Run, Base64, комбобокс кодировки на тулбаре, переносимые настройки, полная смена иконок на Tango и пр.
Кроссплатформенность: Windows, Linux, MacOS (билда нет, но поддерживается, включая иконки и прочее).
2000+ строк добавлено, 1600+ удалено.
Четыре AI помогали — один спроектировал, другой написал код, третий диагностировал, четвертый управлял репозиторием и документацией, делал билды. Это как команда разработчиков. Любитель один, он всего не сделает и забросит."
На этом долгая пауза, выгорел.
у тебя нет тега на версию 2.3.1, какому коммиту она соответствует?
Я добавил теги.
git show v2.3.1 --oneline -s
нормально показывает теперь, коммит 0a60f89 соответственно
С поздних версий в ход активно пошли нейронки (стоит предупредить), слишком большой объем работы.
Проверял только половину. До этого там были точечные изменения. Дальше тут гемморные баги, я задолбался уже и не проверял, верил "на слово" что так хорошо будет.
То есть да, уже "нейрослоп", можно обвинять на полную. Уже да. Не буду же я обманывать, знайте.
Мне кажется, что там логику определения систем уже до меня писал не человек.
Нейронка мне интересную инфу сказала, по истории всего проекта.
"Глядя на историю и характер багов, я почти уверен, что оригинальный RTHextion был написан AI, причём довольно простым.
Признаки AI-генерированного кода (не человеческого):
1. QToolTip::setFont(Courier 16) в конструкторе HexEditor
Человек знает, что QToolTip::setFont — глобальный вызов. Только новичок в Qt мог так сделать, однако:
Если бы новичок делал, он бы потом это увидел и исправил, так пишет только AI.
AI просто "увидел" в обучающей выборке паттерн "setFont для чего-то" и скопировал
2. ScrollMapPtrBgColor = "#d0d0d0" — хардкод цвета без темы
Опытный Qt-программист использует QPalette или theme-agnostic подход. AI сгенерировал то, что "просто работает" на светлой теме.
3. setChecked(true) до connect() — классический AI-порядок
AI не понимает порядок выполнения. Он видит "надо установить чекбокс в true" и "надо соединить сигнал", и ставит их в том порядке, в каком они написаны в документации. Человек знает: сначала connect, потом setChecked.
4. toLatin1() для произвольного пользовательского ввода
Любой, кто писал парсер ввода на C++, знает: не используй toLatin1() для текста от пользователя. Минимум toUtf8(). AI выбрал латиницу, потому что в тренировочных примерах часто был английский текст.
5. Линейный поиск для одного байта без оптимизации
Да, человек-новичок мог так сделать. НО: в комбинации с другими багами — это похоже на AI, который "просто реализовал алгоритм из учебника", не задумываясь.
Странное: знание 20+ платформ для ROM detection. Человек не может быть экспертом по 20+ платформам. Обычно люди хорошо ориентируются только по одной или двум.
Это ключевой момент. Оригинальный RTHextion умел определять:
NES, SNES, Game Boy, Genesis
Atari 8-bit, Atari 5200, Atari 7800
Commodore 64, Amiga
ZX Spectrum
Apple II
И ещё ~10 платформ
С сигнатурами на уровне "по смещению 0x3F байт должен быть 0x00, а по смещению 0x7F — 0xAA".
Один человек такое не напишет. Это либо:
a) Скопировано из чужого проекта (MAME, ROMlib, Maybe)
b) Сгенерировано AI (который натренирован на технической документации и исходниках эмуляторов)
Мой вердикт:
Скорее всего это GPT4/Copilot/Codex, вероятность 95%
ROM detection (20+ платформ) AI (GPT-4 или Copilot)
GUI, QSettings, actions (AI с последующей правкой человеком) 80%
Логика HexEditor (paintEvent, курсоры) возможно, человек + AI 60%
Основной каркас скопирован из учебного проекта, вероятность 70%
Почему не человек самостоятельно:
Системные ошибки (неинициализированный bool, порядок connect) — профессионал не допустит, любитель допустит один-два, но не 10+ таких
Странные константы (#d0d0d0, Courier 16) — без объяснений, без комментариев
Гигантский ROM detection — это не пишут с нуля для хобби-проекта
Почему человек сам не писал ROM detection:
Даже фанат GitHub не сядет и не пропишет вручную:
// Atari 5200 signature at offset 0x1FFE = 0x00, 0x3F...
// NES signature: первые 4 байта 0x4E, 0x45, 0x53, 0x1A...
// SNES: смещение 0x7FD5 = 0x20, 0x7FDC...
Это сотни байтовых масок. Их пишут либо:
Берут из opensource-библиотеки (ROMlib, libromdetect)
Парсят базу данных No-Intro
Генерируют AI, который видел тысячи ROM header'ов в тренировочных данных
Анализ второй нейронки, с полным доступом к коду:
"Моя оценка:
Определение ROM: 95% AI (GPT-4/Copilot)
GUI/Qt-шаблоны (меню, диалоги, QSettings): 80% AI с правками человека
Движок отрисовки HexEditor: 50/50 человек + AI
Базовая архитектура (система доков, сессии, модель проекта): спроектировано человеком, реализовано AI
20+ багов, которые мы исправили: ~15 были AI-происхождения, ~5 были нормальными ошибками разработчика-одиночки"
В общем, я очень сомневаюсь, что автор RTHextion писал это всё сам, в такие сказки я не верю.
Даже если не нейрокод, то не сильно отличается. Я никого не обвиняю, но чистоту кода не гарантирую и сомневаюсь в его происхождении, но если он работает и спроектирован человеком нормально, то ничего страшного не вижу.
То есть, в этой бочке нейрокода, какая там уже разница. Самому туда лично писать не хочется, пусть дальше пишет ai агент, без вариантов. Я уже не буду копаться сам лично.
Это звучит лениво, но тут либо забрасывать, либо большую часть работы отдать нейронкам.
Но, прога только лучше стала, по сравнению со старыми версиями, где типо человек онли (будем считать, что мы поверили).
Я могу тебе помочь настроить CI/CD. Тогда тебе не нужно будет вручную релизы делать.
Я почитал, понял как надо.
У меня просто там только два репо; только Paprium ядра и вот этот Neohextion лежит. Остро проблема не стоит, но потом обязательно поставлю runner.
И релизов сыпалось много, пока версия была сырая. Сейчас уже не настолько коряво и времени на прогу стало меньше.
я все равно считаю неправильно хранить архивы в репозитории.
Согласен, да.
Просто спешил и там раньше только Paprium зеркало было, поэтому не настроено норм.
Можешь попробовать использовать другие хостинги например gitverse. Это тоже российская разработка.
Вообще самая лучшая альтернатива гитхаб это вроде SourceCraft.
Если Gitflic это так плохо то попробую, надо. Мне почему-то его первым порекомендовали когда-то.
проект явно мертворождённый. 
Проект не мертворожденный, он скорее близок к завершению. Экспресс-разработка, понимаешь.
Это раньше сложно тащить в одиночку, но в 2026 году можно срезать углы.
Даже если не доделывать, то он уже нормальный. Тот же Translhextion и WindHex32 не сказать, что бы идеал. Этот уже может быть заменой. И так как Open Source, то смерть это не значит конец проекта.
