Re: automatically hiding after Gtk::Dialog::run()



Thanks for that. That comes from the GTK+ documentation, so I think we
will keep it like it is. I thought that GTK+ intended to hide() it
immediately.

On Thu, 2005-01-06 at 19:53 +0100, B.Hakvoort wrote:
> Hi,
> 
> I've noticed this behaviour a couple of times. It looks like a bug to
> me, but according to the API it isn't :
> 
> "After Gtk::Dialog::run() returns, you are responsible for hiding or
> destroying the dialog if you wish to do
> so." (http://www.gtkmm.org/docs/gtkmm-2.4/docs/reference/html/classGtk_1_1Dialog.html#a14 )
> 
> Personally i think the dialog should hide() immediatly after run()
> returns.
> 
> My 2 eurocents :)
> 
> Bart
> 
> On Thu, 2005-01-06 at 13:44 -0500, Carl Nygard wrote:
> > On Thu, 2005-01-06 at 18:35 +0100, Murray Cumming wrote:
> > > After Gtk::Dialog::run() returns, you must explicitly call hide(),
> > > instead of the dialog being hidden automatically. I think this is a bug.
> > > 
> > > Can anyone think of any problems that would be caused by fixing this
> > > bug?
> > > 
> > 
> > I don't know if this makes a difference, but Gtk2-perl requires the
> > explicit hide() after run() as well.  At least the docs state the
> > requirements clearly.
> > 
> > Perhaps add API: 
> > 
> > int Dialog::run_and_hide()
> > {
> >   int result = run();
> >   hide();
> >   return result;
> > }
> > 
> > Usage:
> > 
> > Dialog better;
> > int you = better->run_and_hide();  // cause I'm gonna git you sucka
> > 
> > 
> > Ok, I admit it.  That was just an excuse for a joke.  But I still think
> > it's better to add API than "fix" the bug.  What's the consensus in
> > other bindings?
> > 
> > Regards,
> > Carl
> > 
> > 
> > _______________________________________________
> > gtkmm-list mailing list
> > gtkmm-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gtkmm-list
-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]