Через что лучше реализовать кликабельные области внутри drawing area? Можно, конечно, отсчитывать координаты клика и по ним принимать решение то делать дальше (так я и делаю в лабвьюшном прототипе), но это будет дичайший оверхед по памяти и/или лагам (в лабвьюшном прототипе работать можно, но тяжело).

Словом, как цеплять асинхронные функции на клик и прочие события к рисуемым элементам? Как прямоугольным, так и треугольничкам всяким.

Через что лучше реализовать кликабельные области внутри drawing area? Можно, конечно, отсчитывать координаты клика и по ним принимать решение то делать дальше (так я и делаю в лабвьюшном прототипе), но это будет дичайший оверхед по памяти и/или лагам (в лабвьюшном прототипе работать можно, но тяжело).

Квадродерево прикрути.

Через что лучше реализовать кликабельные области внутри drawing area?

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

А сигнал для клика реализовать можно через https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget-button-press... там нужно проверить нажата ли кнопка мыши, а получить координаты мышки относительно drawingarea можно через функцию https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-get-pointer

Звучит мощно, квадродерево... Поддерживаю! Ну или что там лучше будет.

Что это такое? Из области садоводства? Или опять цирковая труппа «анонимусы»?

Это оптимизация! Без чего у тебя все будет логать с вероятностью 101%! https://ru.wikipedia.org/wiki/Дерево_квадрантов

Что это такое? Из области садоводства? Или опять цирковая труппа «анонимусы»?

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

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

Плюсцую!

Все же хочется ловить события именно по конкретным областям диаграммы. Серьезно упростило бы код. Годится ли https://developer.gnome.org/gtk3/stable/GtkEventBox.html ?

Все же хочется ловить события именно по конкретным областям диаграммы.

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

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

Тогда у него проблемы со стрелками начнутся...

Ну так виджеты будут лежать на DrawingArea, на ней будут стрелки, а виджеты плавать вверху... Я так себе представляю.

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

Человек написал бы

int draw(GtkWidget *widget, cairo_t *cairo)

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

long int metaprog_function_2469240337746743297(struct {
struct {
struct {
struct {
unsigned long int element0;
} *  element0;
} element0;
unsigned long int element1;
struct {
} *  element2;
} element0;
struct {
} *  element1;
} *  metaprog_control_7903717836365520897, struct {
} *  metaprog_control_7449404335046373377)
//заголовок функции, дальше будет тело
{
char metaprog_array_pointer_1857582507329130497[] = {82,111,98,111,116,111,0};
long int metaprog_variable_8322152501286299649 = 0;
long int metaprog_variable_7906735272139472897 = 0;
cairo_select_font_face(metaprog_control_7449404335046373377,metaprog_array_pointer_1857582507329130497,metaprog_variable_8322152501286299649,metaprog_variable_7906735272139472897);
double metaprog_variable_4021015105573855233 = 10;
cairo_set_font_size(metaprog_control_7449404335046373377,metaprog_variable_4021015105573855233);
double metaprog_variable_2588254559186329601 = 20;
double metaprog_variable_8904919235974726657 = 50;
cairo_move_to(metaprog_control_7449404335046373377,metaprog_variable_2588254559186329601,metaprog_variable_8904919235974726657);
char metaprog_array_pointer_2581353591599017985[] = {77,101,116,97,112,114,111,103,32,116,101,115,116,0};
cairo_show_text(metaprog_control_7449404335046373377,metaprog_array_pointer_2581353591599017985);
long int metaprog_variable_7939909526350786561 = 0;
return metaprog_variable_7939909526350786561;

}

В картинке функция выглядит вот так: https://i.postimg.cc/PxhKWcNL/image.png

Тип структуры cairo_t (терминал с «хвостиком», означающим, что это параметр функции) мне отлично виден в графике и я могу с ним удобно оперировать на графических диаграммах. Я так вызываю функции, работающие с cairo (нарисовать текст например). А на то, что будет декларироваться анонимная структура, компилятору по барабану, только предупреждения кидает, мол, что ты мне кидаешь, это же анонимная структура вместо общепринятого сокращения cairo_t.

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

Си так прост, что все это чудо компилируется и, о чудо, еще и правильно работает!

Надо чтобы каждая нужная область была виджетом, верно? То есть, рисовалась отдельно, по-своему реагировала на клики и прочие события. Как бы это сделать попроще да по-быстрому, не углубляясь в нюансы ООП?

А еще линии, которые тоже должны по-своему реагировать на приближение мышки, клик мышкой итп.

Каждая диаграмма будет виджетом, внутри этого виджета будут другие виджеты, текст, картинки итд. Сделай просто функцию которая конструирует диаграмму.... Я не могу тебе сказать как что сделать прямо, надо знать твой код, мне тогда проще свой метапрог сделать, так что разберись с такими низами лучше сам!

Ладно, попытаюсь поэкспериментировать.

Кстати, я заметил, что в твоем примере

static gboolean drawrrr(GtkWidget *widget, cairo_t *cairo, gpointer data)

есть gpointer data - тот самый указатель для передачи данных в коллбек, верно? Но в найденных мной заголовках функций нет gpointer data. Оно типа необязательное, можно с ним и без него?

есть gpointer data - тот самый указатель для передачи данных в коллбек, верно?

Да

Но в найденных мной заголовках функций нет gpointer data.

Очень странно.

Оно типа необязательное, можно с ним и без него?

Обязательное.

https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget-draw

Там прослеживается, что указатель на начало массива из 14 байтов передается как аргумент функции gtk_label_new. Которая принимает массив (нуль-терминированную строку). Из этих 14 байтов 13 «Metaprog test» и один нулевой.

Мне просто лень делать отображение массива как строки, сделаю это уже после переноса кода Метапрога «сам на себя».

Еще раз, пользуясь случаем, скажу, что нуль-терминированные массивы/строки - самое ужасное, что есть в стандартных сишных функциях. Лучше бы все было как в функциях типа write, fwrite - просто передача длины масива как еще одного аргумента и не заморачиваться с ноликом в конце массива.

А вот нихрена не обязательное. Сделал твой же пример без gpointer data в коллбэках - и работает, компилируется. Это ли не чудо?

#include <cairo.h>
#include <gtk/gtk.h>

static void destroy(GtkWidget *widget)//, gpointer data)
{
	gtk_main_quit();
}

static gboolean draw(GtkWidget *widget, cairo_t *cairo)//, gpointer data)
{
	cairo_set_source_rgb(cairo, 0, 1, 0);
	cairo_rectangle(cairo, 20, 20, 200, 200);
	cairo_fill(cairo);
	
	cairo_set_source_rgb(cairo, 0, 0, 1);
	cairo_rectangle(cairo, 150, 150, 200, 200);
	cairo_fill(cairo);
	
	cairo_set_source_rgb(cairo, 0, 0, 0);
	cairo_select_font_face(
		cairo, 
		"DejaVu Sans",
		CAIRO_FONT_SLANT_NORMAL,
		CAIRO_FONT_WEIGHT_BOLD
	);
	
	cairo_set_font_size(cairo, 30);
	cairo_move_to(cairo, 300, 30);
	cairo_show_text(cairo, "Hello World!");
	cairo_fill(cairo);
	
	return FALSE;
}

int main(int argc, char **argv)
{
	GtkWidget *window;
	GtkWidget *drawing_area;
	
	gtk_init(&argc, &argv);

	window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
	g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(destroy), NULL);
	
	drawing_area = gtk_drawing_area_new();
	gtk_widget_set_size_request(drawing_area, 640, 480);
	g_signal_connect(G_OBJECT(drawing_area), "draw", G_CALLBACK(draw), NULL);
	
	gtk_container_add(GTK_CONTAINER(window), drawing_area);
	gtk_widget_show_all(window);
	gtk_main();
}

Не взлетит...

...по причине, перпендикулярной программированию.

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

Т.е., в тексте программы #include <../f_3/slave_100.h>

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

Не надо путать лёгкость рисования на бумажке рукой с рисованием на компе даже в специализированных программах. Чертёжик, который первоклассник срисует за 5 минут в тетрадь, профессиональный дизайнер в ФотоЖопе будет ваять минут 10 минимум.

Можете сравнить сложность набора математических функций средствами M$ Word и в LO методом int from a to b {sin^2 x} over x dx — выделить, нажать «Вставить формулу».

А если вам придётся ПРАВИТЬ формулы в MS Word, вы проклянёте всех скопом.

А ведь и в вашем GI IDE надо будет править программы.

Тут мне вспоминается всеми давно забытый ДримВивер, в версии 2 которого я когда-то работал. Так вот наваять первоначальный дизайн в нём было удобно, а для внесения правок много удобнее было править уже html- css- коды руками напрямую, благо он позволял.

И, как вишенка, полноценное освоение современных IDE зачастую столь же трудоёмкий процесс, как и изучение ЯП на базовом уровне. Т.е. для того, чтобы научиться программировать в вашей среде челу придётся (а) выучить С; (б) выучить вашу среду, которая более ни для чего не пригодна.

Именно поэтому столь много «ретроградов», которые при наличии многих «удобных» IDE предпочитают связку vim+gcc с окне терминала.

А вот нихрена не обязательное.

Ну да, как и этот код:

int *i = NULL;
*i = 10;

Но у тебя просто чудом не вылетает программа, но рано или поздно в ней сломается стек все равно.

Но у тебя просто чудом не вылетает программа

На 32 битах вылетит уверен кста.

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

Будет управление с клавиатуры.

Можете сравнить сложность набора математических функций средствами M$ Word и в LO методом int from a to b {sin^2 x} over x dx — выделить, нажать «Вставить формулу». А если вам придётся ПРАВИТЬ формулы в MS Word, вы проклянёте всех скопом.

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

чтобы научиться программировать в вашей среде челу придётся (а) выучить С; (б) выучить вашу среду

Си учить будет вовсе необязательно. Вы путаете прототип (который сейчас, собственно, обсуждается и находится в активной разработке) с готовым IDE. Для работы на низком уровне, может, придется с указателями играться, но, опять же, в графике. Оперировать текстовым Си - только в самых особых случаях.

static void destroy()//GtkWidget *widget)//, gpointer data)
{
	gtk_main_quit();
}

Убрал все аргументы из этого коллбэка (ни один из них не используется) - все равно компилится и работает. И gcc даже не вякает что неправильный коллбэк!

Все же, чем это грозит? Кто-нибудь из знающих Си может сказать?

Все же, чем это грозит? Кто-нибудь из знающих Си может сказать?

Выше уже сказано чем. Падением при вызове колбэка. Или порчей стека и падением где-нибудь в совсем другом месте (удачной отладки).

И gcc даже не вякает что неправильный коллбэк!

Потому что ты преобразуешь тип в G_CALLBACK, ну и выше аноним написал.

Будет управление с клавиатуры.

Полагаете, учить новые аккорды а-ля Емакс, менее трудоёмкий процесс? А ещё не путаться в ^C+k M и ^C+K m.

Emacs для макаронных монстров с 10 макаронинами, нужно продумать нормальное управление.

Работает потому что на x86_64 аргументы передаются через регистры, переменные затираются конечно, но не вылетает сразу, как на 32 битах, и других архитектурах.

В Лабвью я и создаю программы, и правлю их по 100 раз.

Нечто столь же примитивное, что в выложенных примерах?

Си учить будет вовсе необязательно.

Не получится. Даже примитивный html оказался проще в правке руками, чем ВИСИВИГ-редакторами.

Даже в моём примере много проще переправить

#include <../f_3/slave_100.h>

на

#include <../f_2/slave_100.h>

чем возить туда сюда мышкой.

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

Представляете, каких размеров получится программа, созданная вашим методом в противовес реализованной напрямую?

А BolgenOS на новый лад не пробовали переделать?

Да это все мелочи по сравнению с натягиванием сабжевой совы на глобус систем контроля версий.

Контроль версия для слабаков. У тру графических разрабов все работает сразу и версионность не нужна.

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

https://i.redd.it/c6k2uy1vevj21.jpg

Контроль версия для слабаков. У тру графических разрабов все работает сразу и версионность не нужна.

Автор уже рассказывал, как у него будут схемы редактировать одновременно куча юзеров одновременно, как в игрушке.

Вопросы такие: 1) как потестить свой отредактированный код, если код редактируют и другие (и он тупо не соберётся)?

2) как постепенно вводить новые фишки и поддерживать несколько веток?

3) как быть с разработчиками в других часовых поясах?

Ничего не знаю, я на Лабвью делаю весьма сложные программы. И уж скидки ваши посчитать или еще что - плевое дело.

Все реализуется напрямую. Вот лишь маленький кусочек моих лабвьюшных исходников:

https://postimg.cc/xqbqZWBN

Конкретно эта функция находит проводки на диаграмме на заданном расстоянии в пикселях и если нашлись - рисует квадратики, от которых можно вести провод по клику.

Все реализуется напрямую. Вот лишь маленький кусочек моих лабвьюшных исходников: https://postimg.cc/xqbqZWBN

Это тут уже было раза три-четыре. Поэтому, будем считать, что на картинке самый сложный кусок, которым гордится автор.

1) как потестить свой отредактированный код, если код редактируют и другие (и он тупо не соберётся)?

2) как постепенно вводить новые фишки и поддерживать несколько веток?

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

3) как быть с разработчиками в других часовых поясах?

Договариваться можно. Или работать неодновременно, или ночью будут работать, жизнь-то ночью не останавливается.

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

Как по мне, хорошо написанный код рассказывает что он делает, а схема не всегда. Она может описывать процесс, но если уточнять её до мелочей, получится каша, хуже, чем на приведённых ссылках.

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

Договариваться можно. Или работать неодновременно, или ночью будут работать, жизнь-то ночью не останавливается.

Люди в текстовых языках, используя VCS, работают, когда хотят и как хотят, а тут какие-то ограничения вырисовываются. Несвобода.

Нет. Этот кусок, на котором видна вся сложность и при этом он еще и помещается на экран. Не буду ж я скроллить и клеить скрины в один.

Вы с Лабвью, небось, не сталкивались.

Вы с текстовым программированием тоже, как выяснилось, не сталкивались.

В Лабвью я и создаю программы, и правлю их по 100 раз

Не путайте хелловорлды с промышленным софтом на 1M LOC (ну или тысячу экранов диаграмм в вашем случае)

Люди в текстовых языках, используя VCS, работают, когда хотят и как хотят

Что помешает работать так же в визуальной среде? Добавление возможности работать одновременно не убьет возможность работать неодновременно.

Все же, чем это грозит?

В общем случае несоответствие аргументов грозит UB.

В данном случае ты объявил функцию, принимающую произвольное число аргументов. Если ты сам будешь вызывать такую функцию, то допустимо передавать в неё любое количество аргументов. Главное, чтобы объявление функции было в том же модуле трансляции. Если функция будет вызываться из другого модуля трансляции, то UB.

В емаксе можно перебиндить всё на привычные аккорды, кстати.

Не буду ж я скроллить и клеить скрины в один.

Уменьши до размера экрана и выложи. Надписи потеряются, но сложность можно оценить будет.

Пока выглядит так, будто у тебя ничего нет, а те несколько выложенных картинок дискредитируют идею графического программирования, потому что совершенно не читаются и при этом делают что-то не сложнее 2-3 строк на нормальном языке.

Было б очень странно если нельзя!