GTKmm и отслеживание перемещения окна

configure-event в классе виджета.

Есть подозрение, что такого не существует. А если и существует, то deprecated. Потому что на wayland это работать не будет by design.

Есть подозрение, что такого не существует. А если и существует, то deprecated. Потому что на wayland это работать не будет by design.

Стыд-то какой, для вяленого нет события configure.

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

Потому что на wayland это работать не будет by design.

А почему, кстати?

дошло — короче ентот тип эвента подставляется автоматически при вызове сигнала...
все роббит

просто переопределить обработчик virtual bool on_configure_event (GdkEventConfigure* configure_event) для нужных действий и все.

п.с. — только почему то при такой обработке:

bool MainWindow::on_configure_event( GdkEventConfigure * configure_event ) {
    this->set_title( "    wx" + std::to_string( configure_event->x ) + ", wy" + std::to_string( configure_event->y ) );
    return configure_event->send_event;
}

Этот ивент там не для красоты был, надо вызывать реализацию суперкласса. Вообще проще не наследовать это, а ловить сигналы. В сишке это был бы g_signal_connect_after(window, “configure-event”, callback, ...).

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

В композитных wm, и вяленом тоже, целые двумерные координаты окна это вещь синтетическая. Что если прога запущена на десктопе, который умеет отдалять/приближать окна в 3д? Что если десктоп постоянно работает в режиме по типу macos compose? Нет общего вида никакого.

Да и в обычных иксах клиентское окно всегда заключено в парент-окно wm-а. Именно последнее рисует оконную тему, включая рамки, заголовок, крестик, меняет курсор мыши на ресайз при наведении. В отличие от винды, где рамка окна это просто WM_NCPAINT. В теории можно написать wm, который сможет спаривать окна в одной рамке через сплитбар. Какие координаты будут у первого, второго? Если возвращать координаты клиентской части, то это будет беспонтово для юзера, ведь он мыслит рамкой. Если оконной части, то в спаренном режиме это потеряет смысл для правого/нижнего окна, ведь оно не ожидает «заголовок» или «левую рамку» в 600px.

В общем, это сомнилово то еще, и задача ерунда по сути.

В гтк есть понятие сигнала. Он в одном месте эмитится, а в целевом объекте вызывается как основная реализация, ~~~типа виртуальный метод. Помимо этого вызываются все, кто законнектился before/after, как написано выше. Независимо друг от друга.

В крестах, судя по всему, основной обработчик замапили как виртуальный, и наследовать его не надо. Надо найти чо-то типа window->connect_after() или window->signal_connect_after() и вешать туда колбэк с твоим кодом, не портя класс виртуал оверрайдом.

Я ковыряться в крестовых недообертках не люблю, гугл gtkmm signal connect after

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

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

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

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

и да — оверхед от виртуальной карты уже присутствует по умолчанию в данных классах, т.к. в них уже присутствуют виртуальноые методы, — по данной причине никакой порчи не происходит, а енто нормальная обычная практика в плюсах, ибо зачем не использовать фичи языка (наследование)?

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

или ты имееш ввиду, что внутри переопределенного обработчика сигнала надо вызывать изначальный обработчик сигнала из класса Widget и передавать ему параметры?

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

протокол вейланда не даёт приложению управлять местоположением окна.

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

и основное отличие вяленого в отношении окон енто то — чо приложения сами занимаются отрисовкой, в отличии от иксового варианта архитектуры

имееш ввиду, что внутри переопределенного обработчика сигнала надо вызывать изначальный обработчик сигнала из класса Widget и передавать ему параметры?

Енто. Окно черное, потому что ты отнял у него обработку configure-ивента оверрайдом. Из-за ентого не запускается цикл прорисовки бэкграунда. Странно что виджеты говоришь на месте.

спс — ага как ты сказал сделать все вернуло в норм работу — поставил в ретурн результат вызова родного обработчика и все заработало:

скрин

Вот, зацени что делает окно по ивенту конфигуре, и чего теперь не происходит в результате GTKmm и отслеживание перемещения окна (комментарий)

https://code.woboq.org/gtk/gtk/gtk/gtkwindow.c.html#gtk_window_configure_event

Если тебе кажется, что окно подпольными путями узнает о move/resize и само у себя вызывает виртуал, чтобы тебе удобно было, то это НЕ так. Это не для вас написано, молодой человек. В этот виртуал метод самому окну gdk-слой впервые сообщает о том, что сам только что услышал от иксов. Ты это перехватил и выкинул по сути, испортив свой класс окна и все его механики.

ну я понял, думаю как я сделал теперь (указал в предыдущем посте) будет норм работать, — урок усвоен — если переопределяю обработчик, то надо вызывать при ретурне изначальный.

Да, так норм.

и еще — я вот не пойму, почему ентих обработчиков не могу найти в исходниках?
тут (gnome.org)