Re: gtk_statusbar_push_markup()

[Michael Natterer <mitch gimp org>]

Hi Owen,

(your change wouldn't be an issue for the GIMP, but you asked
for users of the signals :)

GIMP uses these signals when deriving GimpStatusbar.

gimp/app/display/gimpstatusbar.[ch]

We pack a progess bar in there, override "text_pushed" and
"text_popped" and display the message in the progress bar.

My impression was that the virtual functions are there to enable
doing this (providing an own method for text display).

I don't think this change would meet the binary compatibility
requirement of GTK2.2. GimpStatusbar will continue to work correctly
because we simply hide GtkStatusbar's own label, but widgets which
change the text before upchaining (which is IMHO perfectly valid usage
of the current API) will b0rk.

ciao,
--mitch


Owen Taylor <otaylor redhat com> writes:

> I figured that #90286 - "Addition of function gtk_statusbar_push_with_markup()"
> would be a quick fix.
> 
> Turned out to be a little more complex than this because GtkStatusBar
> has two signals:
> 
>   void	(*text_pushed)	(GtkStatusbar	*statusbar,
> 			 guint		 context_id,
> 			 const gchar	*text);
>   void	(*text_popped)	(GtkStatusbar	*statusbar,
> 			 guint		 context_id,
> 			 const gchar	*text);
> 
> That are called when stuff is pushed or popped, and currently
> the text in the statusbar is updated out of the default handler
> based on the ::text property.
> 
> So, theoretically, someone could override text_pushed/text_popped,
> and then chain up with a different value for *text.
> 
> But, I really couldn't imagine any valid reason for this (well,
> actually, I can't imagine any reason for having these signals
> in the first place), so what I did was changed the signals
> to be pure notification and have an empty default handler,
> then made the code do:
> 
>   gtk_statusbar_update (statusbar);
>   gtk_signal_emit (GTK_OBJECT (statusbar),
> 		   statusbar_signals[SIGNAL_TEXT_PUSHED],
> 		   msg->context_id,
> 		   msg->text);
> 
> Where msg->text is the text of the statusbar with any markup 
> stripped out. If someone was setting statusbar->label
> in their signal handler, it will still work, because the
> update that the widget does is done first.
> 
> Patch attached.
> 
> Opinions? Anybody ever use these signals? Anybody have any
> idea why they are there?
> 
> Thanks,
>                                         Owen