LINUX.ORG.RU

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

 


0

1

В общем и целом вопрос таков — каким образом отслеживать перемещение окна?
Класс кона унаследован или не унаследован от Gtk::window.

т.е. не могу найти эвент отслеживающий перемещение окна.
может что то недосмотрел, но вроде все эвенты проверил по офф докам и ничего не нашел — так ли енто?

★★

Ответ на: комментарий от eternal_sorrow

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

safocl ★★ ()
Ответ на: комментарий от safocl

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

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

safocl ★★ ()
Ответ на: комментарий от safocl

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

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;
}

окно становится черным, хатя элементы нормального цвета.

скрин с таким обработчиком

скрин с закоментированным этим обработчиком

safocl ★★ ()
Ответ на: комментарий от safocl

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

anonymous ()
Ответ на: комментарий от anonymous

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

safocl ★★ ()
Ответ на: комментарий от hobbit

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

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

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

anonymous ()
Ответ на: комментарий от safocl

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

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

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

anonymous ()
Ответ на: комментарий от safocl

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

safocl ★★ ()
Ответ на: комментарий от anonymous

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

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

safocl ★★ ()
Ответ на: комментарий от hobbit

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

eternal_sorrow ★★★★★ ()
Ответ на: комментарий от eternal_sorrow

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

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

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

safocl ★★ ()
Последнее исправление: safocl (всего исправлений: 1)
Ответ на: комментарий от safocl

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

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

anonymous ()
Ответ на: комментарий от safocl

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

safocl ★★ ()
Последнее исправление: safocl (всего исправлений: 1)