AndreyDmitriev30 янв в 15:45

Делаем приложение на Расте с GUI нестандартным способом

Простой

15 мин

Rust * Программирование * Ненормальное программирование * C * Windows *

Кейс

Комментарии 24

JerryI 30 янв в 16:47

Очень красиво и просто!
А как там с кроссплатформой?

sqooph 30 янв в 16:51

Приоткройте глаза и читайте по буквам LabWindows/CVI

JerryI 31 янв в 09:44

Я надеялся что NI уже сделали порт за столько лет. Но видимо во всех лабораториях так и останется лок на Win

JerryI 31 янв в 09:45

Согласно Вики есть надежда
Windows 11/10/8.1/7 SP1Linux run-time support and Pharlap real-time run-time support

AndreyDmitriev 31 янв в 10:03

Не, тут чуть другое. У NI есть такие железки как cRIO, это такие контроллеры реального времени, иногда с FPGA на борту, часть на Linux, а часть на Pharlap, и CVI можно использовать, но это как эмбеддед. Так то среды разработки под Линукс я не видел, а вот рантайм где-то попадался, но у меня есть сомнения, что там интерфейсная часть присутствует. На досуге гляну.

iferrrnil 30 янв в 17:34

это с кроссплатформенное решение?

AndreyDmitriev 30 янв в 17:51

Нет, только под Windows, сейчас тег и хаб добавлю, хотя в тексте там это есть.

includedlibrary 30 янв в 18:46

На самом деле выглядит, как довольно удобная штука. Жаль платная, под винду и без highdpi. Я сколько гуй не пытался делать, это почти всегда было до жути больно и неудобно, что на го, что на си, что на си++. С теплотой вспоминаю время, когда школьником писал гуй на visual basic. Судя по тому, что я у вас увидел, LabWindows/CVI очень похож на windows forms, только с большим количеством виджетов

Siemargl 31 янв в 19:49

Очень странные проблемы, гтк по логике похож на винформс.

Конечно, по документированию опенсорс обычно отстаёт от коммерческих тулз.

includedlibrary 31 янв в 20:09

В основном как раз в доках и возникала проблема. Из недавнего - я пытался в Glade добавить контекстное меню. Добавил, а вот как добавить туда пункты не понятно было от слова совсем, а оказывается, надо не добавлять виджеты в меню, а нажать на edit и там добавлять. С комбобоксом ещё веселее, надо отдельно создать GtkListStore, в него добавить нужные пункты, а потом уже в комбобоксе выбрать этот самый liststore. Сам по себе Glade - тот ещё набор глюков. Хочу я сделать liststore с редаиктируемым полем, через код - пожалуйста, Glade же при выборе GtkCellRendererMode, после указания, что он редактируемый, крашится. Ещё весело было с многопоточкой, оказалось (что логично, не спорю), что просто так взять и обновить текст из другого потока нельзя, а чтобы это сделать, внимание, надо использовать функцию вообще из glib, а именно g_idle_add. После всего этого ужаса стало плюс-минус нормально работать, да и благо, у меня не так много проектов с GUI запланированно, но всё равно, этл один из ужаснейших опытов в работе с чем-либо.

Siemargl 17 часов назад

Так основные проблемы в Glade, а он устарел, его официальная замена Cambalache.

Плюс есть ещё GNOME Builder (ex.Anjuta) которые для gtk4

Собственно сам не тыкал, меня только связка с шарпом интересовала.

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

AndreyDmitriev 15 часов назад

То что гуй должен быть в одном потоке,

Да, здесь в случае с CVI так оно и работает, при старте рантайма создаётся отдельный поток под GUI, и если я пишу в элементы неважно откуда, то происходит переключение в этот поток (когда я вызываю SetCtrlVal), мне об этом заботиться не надо.

Вот смотрите, допустим я из Раста запущу два вот таких потока:

fn run_thread(thread_num: u32, counter: Arc<AtomicU32>) {
	loop {
		let call_num = counter.fetch_add(1, Ordering::Relaxed) + 1;

		// Build the string: "Thread num, Call num"
		let s = format!("Thread {}, Call {}", thread_num, call_num);
		if thread_num == 1 {
			set_ctrl_val_str(PANEL, PANEL_STRING_1, &s);
		}
		if thread_num == 2 {
			set_ctrl_val_str(PANEL, PANEL_STRING_2, &s);
		}
		set_ctrl_val_str(PANEL, PANEL_STRING_C, &s);

		// Random sleep 250-750 ms
		let mut rng = rand::rng();
		let delay_ms = rng.random_range(250..=750);
		thread::sleep(Duration::from_millis(delay_ms));
	}
}

Какждый из них будет писать в свой индикатор, и оба вместе в один "Общий". До кучи я ещё и CVI таймер добавлю и буду в этот общий индикатор писать из коллбека, который раз в секунду срабатывает:

#[unsafe(no_mangle)]
pub extern "C" fn OnTimer(
	panel: c_int,
	_control: c_int,
	_event: c_int,
	_callback_data: *mut c_void,
	_event_data1: c_int,
	_event_data2: c_int,
) -> c_int {
	println!("OnTimer");
	set_ctrl_val_str(panel, PANEL_STRING_C, "ON TIMER EVENT");
	0
}

Ну и вот, всё работает, ничего не крешится. В "общий" индикатор тоже пишется, но тут "кто первый встал, того и тапки":

Как-то так.

includedlibrary 12 часов назад

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

Это я понимаю, но вот найти, как правильно обновлять состояние гуя из другого потока было сложно. Да и вообще странно немного, что у нас gtk, а функция для этого из glib.

Так основные проблемы в Glade, а он устарел, его официальная замена Cambalache.

Да, тут мой прокол.

Jijiki 30 янв в 19:33

смотрите, вы это сделали потомучто 'по работе'(maya тоже дорогая), показали dll mesa - вывод, современная обработка видео подросла, теперь есть TextureArray - в симбиозе с 256х256 атласом - где каждый тайл 16х16, это работает ничуть не хуже по интерфейсу, потом тут хорошо кладутся центровки, в итоге вам просто нужно будет решение для разметки, и получается что, вы можете паралельно написать своё на расте с sdl2 + gl например, кросплатформенность не проверял - на С++ она есть если нужна точно

есть tiled например программа, гимп может сохранять формат картинок(тоесть есть не только нуклеар, а есть библиотека статическая интерфейса на С 200кб около того) в виде бинарника, получается вы можете сделать свой интерфейс минималистичный - переносной 8 битный, и такой же интерфейс для редактора сделать

includedlibrary 30 янв в 20:08

Да, только надо учитывать, что это будет сопряжено с куда большим количеством кода и колоссальным количеством боли. Immediate mode GUI хороши для чего-то более-менее простого, если свой GUI писать, то кода и боли станет ещё больше, а в итоге вы так проект и не закончите. Я больше всего использовал gtk, и я ненавижу gtk, но даже с gtk работать лучше, чем делать свою реализация или использовать immediate mode для чего-то более-менее нетривиального.

Jijiki 30 янв в 23:42

есть хитрость, у нас есть отрисовка glMultiDrawElementsIndirect, для неё подобно Вулкану - по-сути младший собрат, нам надо собрать командный буффер, так вот суть в том, что ваш слой, который вы пропишите офсетом в мультидрауЕлементсИндирект, будет забинден как в базе данных, по-сути вам ничего не будет стоить забить матрицы координатами 1 слоя и его отрисовать, вот такая ситуация, а с текстурным атласом ситуация сводится к отцентровкам

там надо подрубить gl_DrawID - #extension GL_ARB_shader_draw_parameters : enable

тоесть слой панелька например наверно, слой еще какой-то я сейчас пытаюсь тоже понять как это переварить в быструю отрисовку послойно UI, у меня правда итак весь УИ замапан, но с этой командой в разы удобнее поидее, но с этой командой действительно проще, например у нас может быть если не база данных, то хэш мапа форм например и тут как раз эта команда удобная

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

includedlibrary 31 янв в 07:31

Причём тут графические API? Обычно UI тулкиты типа QT, GTK и того же Windows Forms куда более высокоуровневые, а сложности возникают всё равно. Если перейти на более низкий уровень в задаче создания GUI, проще не станет, станет только сложнее. Суть в том, что проблемы с тулкитами возникают не в части отрисовки, а в части заставить виджеты делать то, что вам нужно.

Jijiki 31 янв в 12:20

тогда вам не нужен mesa.dll например есть Direct2D, с точки зрения вашей позиции что в библиотеке зависимость меса уже промах, в сабже как раз есть эта зависимость, и она не отрабатывает как могла бы сегодня - тоесть эффективность страдает, её можно - эффективность обновить, тогда программа уже будет не легаси, как майнкрафт 2010 года например, а чуть более эффективная, по средней так сказать пропорции интерфейс/производительность

тогда мы так же можем получается до сих пор ставить стол GNUStep или mwm, когда GNUStep не такой как макОС и свифт - это кстати укладывается в логику легаси, где макОС обновлённый - допиленный функционал

includedlibrary 31 янв в 12:27

Да причём тут mesa.dll вообще? Я вам говорю, писать свой GUI - гиблая идея, потому что вы скатитесь от решения изначальной задачи в ещё более громоздкую задачу написания GUI, и тут уже не важно, на OpenGL у вас рендеринг, на vulkan, на DirectX или вообще софтверный. Immediate mode GUI не подходят для сложных интерфейсов, например, для блендера или САПРа какого-нибудь. В таких случаях всегда надо брать существующий UI тулкит, типа, wxWidgets, GTK, Windows Forms, QT. Но и с ними работать бывает очень не приятно (я могу только за GTK говорить) из-за отсутствия нормальной документации и неочевидного поведения, что-там и как рендерится и от чего оно зависит - дело десятое.

Jijiki 31 янв в 21:47

да вы правы, есть еще свинг, тоже удобный

Jijiki 31 янв в 23:20

Скрытый текст

ну вот тест -успешный, сделал - стало интересно и самому было нужно, XML-Lua-Rust, работает приятно и да это велосипед

с lua мне понравилось регистрируешь скрипт, и другие функции чисто уже привязаны, потомучто файл грузится и исполняется, улётно вообще, а XML даёт разметку

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

что там лучше js,python,lua,свой язык, я не вникал покачто, и не хочу со стеком бороться для передачи zero-cost аргументов и диспатчингом, чтобы не терять операции на виртуальность

HemulGM 31 янв в 08:19

До Делфи как до Луны пешком. При чем я вижу даже многие болячки времен 2005 года, например, мерцанием элементов.
Координаты элементов визуально нет смысла смотреть, потому что всегда и везде нужно использовать выравнивание, а не статичное расположение элементов управления.
У контролов должно быть множество событий, а не одно "главное".

Кстати, интересно посмотреть на синхронизацию многопоточного кода.

Этому проекту ещё десяток лет развиваться до удобоваримого состояния.

AndreyDmitriev 31 янв в 14:38

Эх, я уж четверть века не писал на Дельфи, где-то между пятой и шестой пересел на LabVIEW.

Но я не поленился и сегодня поставил 13.

В целом норм, прогресс на месте не стоит, всё аккуратненько так. Кстати, выравнивание контролов в CVI даже чуть лучше сделано с иконками, а тут просто список, вот в этом месте:

У контролов CVI и есть множественные события, можно на перемещение мыши срабатывать, нажатие кнопок, перетаскивание, потерю фокуса и т.д. вот смотрите:

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

HemulGM 31 янв в 14:51

Попробуйте Multi Device Application создать . Ну и выравнивание делать лучше через Align делать всегда. Без использования якорей

Зарегистрируйтесь на Хабре, чтобы оставить комментарий