Софт для исследования UX

Софтина для исследования обязательно должна быть опенсорсной
Исходников софта по большей части нет

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

есть java

А что использует для отображения софт на Java?

Есть Qt, есть Gtk, есть java. Исходников софта по большей части нет

Тяжко будет… Даже не знаю что можно посоветовать

Я бы посоветовал уволиться.

SWT

Если бы были исходники, проблемы бы не было, около каждого вызова кнопки делаешь console.log() или что-то подобное, и ноу проблем.

Я думал, что-то типа подсунуть специально пропатченную Gtk/Qt/SWT, чтобы она тоже делала console.log(), но это ж сколько работы. Вот и думаю, может кто решал уже подобную задачу.

Исходников софта по большей части нет, надо выдирать как-то через strace или через не знаю что. Отсюда, колхозить что-то самостоятельно представляется затратной идеей.

Вот я как раз сомневаюсь, что при таком раскладе будет что-то готовое, что вкорячевается не на этапе исходников.

Я точно знаю, что можно впилиться в свинговые и культевые приложения, т.к. в первые можно подсадить свой код либо напрямую либо через джаваагента, а у вторых общий евентлуп, который и бинаре можно запатчить.

Дальше свалить это в какой-нить Plausible или Matomo.

Это если авторы не старались уберечь код от вмешательства.

Мало делать log, надо еще сами элементы UI как-то идентифицировать.

В gtk программно доступный нейминг элементов дело сугубо добровольное. Обычно его тупо нет.

берёте Windows, к нему spyware (клавиатурно-мышовый шпиён) по вкусу и колхозите анализ его логов в зависимости от фреймворков и приложений. (от того как виджеты соотносятся с window и какие эвенты порождаются)

В SWT может имеет смысл через рефлексию перехватывать вызовы некоторых методов?

Squish?

Оно же проприетарное.

Может быть, я с ним не знаком.

Сомневаюсь что такое есть, первое что пришло в голову. создаём фиктивное и прозрачное окно которое будет приклеено поверх окна основного приложения, в этом фиктивном окне создаём шаблон UI основного интерфейса цель которого считать активность пользователя, а затем пробросить это действие в реальное приложение.

• Плюсы, основная программа просто работает, в неё лазать не надо.

Минусы

• Проблема реализации окна нашлёнки (обход полноэкранный режим)
• Нужно воссоздавать UI приложения тестируемого (но по факту лишь области взаимодействия нужны для детекта факта действия, так что такой шаблон можно сделать просто поверх скриншов UI основного приложения)
• Динамический UI… тлен, У ГТК такое, нереально сложно делать шаблон будет.

Всё остельное будет требовать доступа к коду или требованию создать библиотеку посредника которая будет ловить нужное и пробрасывать в основную ГУИ библиотеку попутно ведя лог.

создать библиотеку посредника которая будет ловить нужное и пробрасывать в основную ГУИ библиотеку попутно ведя лог.

Вот кто-то уже создал? Или я первый буду? )

Походу первый будешь, разве что кто враппер писал для чего-то иного. Но я сомневаюсь… Прикинь взять весь ГТК и зафигачить копию каждой функции чтобыдрыгнуть потом через неё оригинальную.

И ещё момент, что делать с кастомным UI? Ну типа в некоторых приложениях тупо в ГТК окне появляется OpenGL «холст» на котором разработчик зафигуливает свои кнопочки и формочки и прочее. Тогда даже с враппером такое сделать будет просто невозможно. А с исходниками титанически трудно (если такого ПО тележка с прицепом)

Хотя фиг знает может там у вас ПО с тремя кнопками и всё =)))

Можно упоротся и нанять html/js макаку которая в web сделает прям точную копию гуя приложения, пользователь будет работать с ней, а приложение будет опосредством сервера пробрасывать события в основное приложение, но как с него брать данные?

Короче, https://i.ibb.co/SxYRphT/index.jpg спать тебе придётся скоро очень мало =)

И ещё момент, что делать с кастомным UI?

Сильно подозреваю, что там нет кастомного UI, чай не Darktable, а заказной софт.

Короче, https://i.ibb.co/SxYRphT/index.jpg спать тебе придётся скоро очень мало =)

Я понял, проще распознавать окна и менюшки через OpenCV.

проще распознавать окна и менюшки через OpenCV.

Чёбынет. Но пока есть время пофантазируй ещё, порой мысля решения приходит внезапно и внезапная. Я лишь накинул мысли, может ещё кто накинет. А сработает лучше всего их комбинация.

проще распознавать окна и менюшки через OpenCV

И кейлогер добавить: https://github.com/kernc/logkeys. Форкните, пусть пишет сразу в базу sqlite. :)

А логирование событий мыши у автора в планах.

А разве окну/процессу не шлются сообщения при нажатии кнопки или выбора пункта меню? Ну в Винде так было, кажется. И там были кулхакерские приблуды, которые позволяли захватывать сообщения произвольного окна.

Так всё это сводится к «нажатие мышки, координаты в окне …». Если бы все элементы были системные (хоть Win GDI, хоть X), можно было бы что-то осмысленное ловить. А если там Gtk или Java, то разве что меню системным может быть.

В общем, пакет xtrace.

библиотеку посредника которая будет ловить нужное и пробрасывать в основную ГУИ библиотеку попутно ведя лог

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

либо Google analytics настроить «цели».

Либо Вебвизор в Yandex.Metrika

берёте Windows, к нему spyware (клавиатурно-мышовый шпиён) по вкусу и колхозите анализ его логов в зависимости от фреймворков и приложений. (от того как виджеты соотносятся с window и какие эвенты порождаются)

ради интереса посмотрел как там оно в офтопике, штатным spy..фокус не вполне удался :-) Gtk полностью рисуется сам как одно большое GDI Window и windows не в курсе его внутренних виджетов. Максимум - можно разобрать координаты куда тукнулась мышь и клавиатуру

WxWindow частично - можно отчасти разобрать что куда тыкнулось. Tk весь как на ладони. Qt и Java - не знаю, навскидку чего-то ненашлось ни одного приложения, а специально ставить лень.

В Linux (в X-Window) задача смотрится на грани фантастики. То есть очень много кода.

Опять-же в офтопе - на системные окна придётся вешать хук, логировать клавиатуру, перехватывать клики мыши и сохранять картинку области где кликнуто. Потом (или сразу на лету) опознавать текст в этой области. Не то чтобы совсем просто, но понятно как оно может быть сделано, чтобы универсально

PS/ предположим вы это напишите. А как предполагается сам процесс «исследование UX» ?

«Запустите наш шпиён вместе с указанным софтом» ?? :-) и периодически обновляйте..не отключайтесь надолго от сети и не стирайте логи

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

Эхххх.... Не повезло ТС. Работа из разряда - «Пишем код, пока не видят санитары».

Мне вот интересно, как так вышло, что у них софт и на Qt, и на Gtk есть, и на Java. Ну это ладно. Надо ещё выяснить на всякий случай версии gtk и qt, а то может случиться конфуз.

А как предполагается сам процесс «исследование UX» ? «Запустите наш шпиён вместе с указанным софтом» ?? :

Да. Это же рабочий софт на рабочих компьютерах, обновляться он будет централизовано админом. Тут всё как раз решаемо.

Немного связано с моими страданиями.

Как бы потестировать гуёвый софт?

Порекомендованный в комментах LDTP едва живой и не работает с моими Java+Swing, но вдруг что интересного придумаешь.

Это обратная задача. Им не нужно в кнопочки тыкать, им нужно узнать, в какие кнопочки пользователи тыкают чаще, а какие реже.

Да, но для этого нужно узнать, какие вообще контролы на экране есть, и это предлагается костылить через accessibility гнома

О! А там наверное и интроспекция есть какая-нибудь и доступ к ней через js.

Просто как один из вариантов подхода к задаче, я бы особо на это не ставил.

Да. Это же рабочий софт на рабочих компьютерах, обновляться он будет централизовано админом. Тут всё как раз решаемо.

и у всех разные экраны и WM, кто-то шпилет мышью, кто-то тачпадом. Особо продвинутые в key-binding, и в несколько дисплеев а то и удалённо VNC/X/RDP.

где-то wayland где-то X, зоопарк дистрибутивов, несогласованные с вами обновы. Одмины встанут на дыбы про «обязателен запуск этого XXX одновременно с целевым софтом»

вы застрелитесь делать универсальное решение, чтобы работало и не валило сессию, целевой приклад или само. Продать наверное можно, а вот чтобы «как для себя любимого» это жезть

и у всех разные экраны и WM, кто-то шпилет мышью, кто-то тачпадом. Особо продвинутые в key-binding, и в несколько дисплеев а то и удалённо VNC/X/RDP.

где-то wayland где-то X, зоопарк дистрибутивов, несогласованные с вами обновы.

Нет.

Одмины встанут на дыбы про «обязателен запуск этого XXX одновременно с целевым софтом»

В чём проблема-то?

Кстати это может быть хорошей идеей. Обычно приложения интегрируются с виндовым Accessibility API. Если кастомных контролов разработчики приложений не писали, то и GTK, и Qt, и Java должны подхватиться. Можно поставить какой-нибудь скринридер, они должны зачитывать текст на контролах при наведении мышки. Если это работает, то можно будет написать свой псевдоскринридер, который будет только логировать события.

у них софт и на Qt, и на Gtk есть, и на Java

Ну, если заказчик просто хотел софт, то на чем разрабам хотелось, на том и писали, и, может, статически линковали разными версиями qt.

Ещё возможностями рабочих компов поинтересуйтесь, а то здесь советуют скриншоты снимать, а там может коры с 4 гигами ОЗУ.

Ещё возможностями рабочих компов поинтересуйтесь, а то здесь советуют скриншоты снимать, а там может коры с 4 гигами ОЗУ.

Да, конечно.

Но пока что-то картина грустная.

Qt вообще рисуется напрямую как одна картинка, не представляю как ловить такие эвенты извне. Разве что, если оно использует внешние динамические либы, то патчить например Qt-GUI и Qt-core модули и получать из них эти события, они наверняка там проходят мимо

Придётся задействовать натуральные нейросети.

О, я уже делал такую штуку на дельфи, году так в 1999-м. Мне требовалось не только запомнить, но ещё и воспроизвести движения мыши пользователя (в windows api для установки позиции курсора была функция).

«Исходников софта по большей части нет, надо выдирать как-то через strace или через не знаю что.»

event loop нужное тебе слово. И клиентская библиотека иксов, через которую все эти события проходят более-менее единообразно. Так что я бы озаботился тем какой там сервер x11 или wayland.

пока что-то картина грустная

Можно делать «карты» окон вручную и хранить эти метаописания отдельно от приложений. Больше ручной работы - больше денег с заказчика.

О, я уже делал такую штуку на дельфи, году так в 1999-м. Мне требовалось не только запомнить, но ещё и воспроизвести движения мыши пользователя (в windows api для установки позиции курсора была функция).

«Исходников софта по большей части нет, надо выдирать как-то через strace или через не знаю что.»

event loop нужное тебе слово. И клиентская библиотека иксов, через которую все эти события проходят более-менее единообразно. Так что я бы озаботился тем какой там сервер x11 или wayland.

Сережа, обрати внимание на данное сообщение. В винде именно так и делалось. Перехватывались события до того как они попадали в приложения. Там было достаточно инфы, чтобы понять что/где/когда произошло. Если я правильно помню структуру X11 там есть подобное.

Возможно, вот это наведет тебя на начало пути https://russianblogs.com/article/20421655462/

Если я правильно помню структуру X11 там есть подобное.

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

Поэтому и встал вопрос о том, как это перехватить на уровне тулкита, например, подсунуть какую-нибудь хакнутую библиотеку Qt, GTK или SWT.

Возможно, вот это наведет тебя на начало пути https://russianblogs.com/article/20421655462/

Я в курсе, как устроено Qt, я под него писал :-) По ссылке в статье тоже предполагается вылавливать события именно Qt, а не иксов.

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

Просто это был не тот, не правильный заказчик. И он будет выбит с рынка компаниями типа OpenAI, которые таки сделают всё по фэньшую (хотя и с большими капиталовложениями) через кремнекаменные нейросети.

Нуу…. и пусть. А я заработаю себе на домик на природе и машину без крыши.

домик на природе

Который дороже и времязатратнее содержать, чем квартиру с развитыми ЖКУ

и машину без крыши

Которую водить не сможешь, потому что к тому времени зрение сядет

Который дороже и времязатратнее содержать, чем квартиру с развитыми ЖКУ

Вообще-то дешевле.

Которую водить не сможешь, потому что к тому времени зрение сядет

Аэы.

эмм, что-нибудь на подобии rr и анализировать по логам статистику?

Который дороже и времязатратнее содержать, чем квартиру с развитыми ЖКУ

Дешевле вообще ничего не иметь: ни хобби, ни досуга. И, особенно, детей.