5

I'm running a timeout function in my program background and I'm trying to emit a delete-event signal from Gtk::Button, this is the code snippet in my constructor:

// Glib::SignalProxy1<bool,GdkEventAny*> m_deleteSlot;
// m_deleteSlot =
signal_delete_event().connect (sigc::mem_fun (*this, &AlarmUI::my_delete_event));
m_timeout_connection = Glib::signal_timeout().connect_seconds(sigc::mem_fun(*this, &AlarmUI::cb_my_tick), 1);`

Now, the method:

bool AlarmUI::my_delete_event (GdkEventAny *event) {
if (m_timeout_connection.connected ()) {
    // show messagebox here
    return true;
} else {
    // bye bye
    return false;
}
}

Now, when the user clicks in the quit button, I want to emit the delete-event signal. Question: How do you emit signals in gtkmmm like in C g_signal_emit or g_signal_emit_by_name?

void AlarmUI::on_button_quit () {
// m_deleteSlot.emit (); ???
}

update1:

Glib::RefPtr<Gtk::Application> app = Gtk::Application::create (argc, argv, PACKAGE);
Glib::RefPtr<Gtk::Builder> refBuilder = Gtk::Builder::create ();
try { 
    refBuilder->add_from_file (UI_PATH);
}
catch (const Glib::FileError& ex) {
    std::cout << "FileError: " << ex.what() << std::endl;
    return 1;
}
catch (const Gtk::BuilderError& ex) {
    std::cout << "BuilderError: " << ex.what() << std::endl;
    return 1;
}
catch(const Glib::MarkupError& ex)
{
    std::cout << "MarkupError: " << ex.what() << std::endl;
    return 1;
}
AlarmUI *ui = 0;
refBuilder->get_widget_derived ("window1", ui);
if (ui) {
    ui->show_all ();
    app->run (); // The window doesn't show
}
delete ui;
Joel
  • 1,805
  • 1
  • 22
  • 22

1 Answers1

0

It's not generally wise to emit widget signals from outside of the widget. That's interfering with the internals of the widget's implementation. If you want to hide the window you can call thewindow.hide() and if you want to destroy it you can delete it. Or you can directly do whatever else you wanted to trigger indirectly by emitting the delete-event signal.

murrayc
  • 2,103
  • 4
  • 17
  • 32
  • hide means destroy..I want to actually hide the window. Also, I'm trying to be more intuitive (right word?) but calling the same event triggered from closing the window from the "X" button (window manager) – Joel Mar 03 '15 at 06:29
  • hide() doesn't mean destroy. Your code would be more intuitive (and safer) if it just hid the window to hide the window. – murrayc Mar 03 '15 at 09:04
  • If I use WindowUI.hide(), the app closes and exits, that's no hiding :( – Joel Mar 03 '15 at 17:44
  • Maybe that's because you are using Gtk::Application::run(window) or Gtk::Main::run(window). They are meant to stop the program when that main window closes, as a convenience. But you can call these run() methods without specifying a window and call Gio::Application::quit() or Gtk::Main::Quit(). – murrayc Mar 04 '15 at 07:51
  • Sorry, yes, Gtk::Application::run() is meant to return if it doesn't have any open windows. And run(window) is the easiest way to add windows to Gtk::Application (without using Gtk::Appication::add_window()). If you want to do something after you have hidden the window, you should do that after run() has returned. The window will not have been destroyed yet. The program will only exit when you let your main() return. – murrayc Mar 04 '15 at 21:04
  • This addresses why emission isn't needed in that scenario, but not the question in the title. I guess the real answer is '_It doesn't have any._' If so, users with a reason to emit such signals (rarely, when doing something unusual or that doesn't have 'better' API) must just call the C functions. Here's an example I think is good as it achieves a useful (albeit wholly cosmetic) result: https://git.gnome.org/browse/recipes/commit/src/gr-cuisine-page.c?id=d912693ad3bab147744770f96497602c477a1c91 I borrowed this as gtkmm doesn't wrap `scroll-child`. mclasen said they might add API for that later – underscore_d Dec 31 '16 at 16:51
  • By interfering with the internal implementation of the widget you are effectively using private and undocumented API. You won't get any sympathy from the GTK+ developers when your application breaks when they change that implementation. – murrayc Mar 15 '17 at 14:58