Re: Tooltips progress
On Thu, Jun 01, 2006 at 09:33:48AM -0400, Matthias Clasen wrote: Using x == -1 to indicate a keyboard-triggered tooltip looks a bit odd to me; how about adding a boolean parameter for this ? Good idea, fixed this. Regarding dedicated treeview api, I think we can do without it (at least initially), if we have a good example in the docs. Though lots of people will forget the selection_changed thing for keyboard tooltips... I'll make sure some nice example code will appear in gtk-demo, where we can point people at. Could you enhance your demo with an example of text view tooltips on a tag ? Will do. -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Tooltips progress
Attached is some sample code using the new API. Opinions, comments, suggestions are appreciated. I don't remember too much of the original proposal, so I'll just go by what I see in the examples... What is the relation between the tooltip-markup and has-tooltip properties ? Is has-tooltip automatically set when setting tooltip-markup ? Or do you only need to set has-tooltip if you want to connect to query-tooltip ? Is the tooltip window available as a property too ? (The example uses a dedicated setter for it). The example doesn't show tooltips constructed using the old tooltips api, but I assume those will continue to work as before, right ? Using x == -1 to indicate a keyboard-triggered tooltip looks a bit odd to me; how about adding a boolean parameter for this ? Regarding dedicated treeview api, I think we can do without it (at least initially), if we have a good example in the docs. Though lots of people will forget the selection_changed thing for keyboard tooltips... Could you enhance your demo with an example of text view tooltips on a tag ? Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Tooltips progress
On Wed, 2006-05-31 at 22:08 +0200, Kristian Rietveld wrote: Currently, we are using the following query-tooltips signal: gboolean (*query_tooltip) (GtkWidget *widget, gint x, gint y, GtkTooltip *tooltip); But if a user sets a custom using gtk_widget_set_custom_window(), we don't have to pass a GtkTooltip around. So currently I just set the tooltip field to NULL, so the user knows he has to use his own custom tooltip window (and we assume he has a reference to that). Is this okay or do we want to change this? We could also move the _set_custom_window() functions into GtkTooltip for example. I would very much appreciate if the GtkTooltip object also kept track of the custom window. IMHO it makes no sense to handle this differently. gtk_tooltip_set_markup() vs. gtk_tooltip_set_window() simply feels much better than the asymmetry in gtk_tooltip_set_markup() vs. gtk_widget_set_tooltip_window() The current approach even limits the new tooltip system's use cases, since you have to set the custom window *outside* the callback. There is no way to decide *in* the callback if a standard tooltip is sufficient, or if a custom window is needed. Another problem is the assymetry in getting the relevant data to the callback. With markup, the GtkTooltip can be queried for the markup, if it's a custom window, you have to get it to the callback somehow. In your example code it's passed as user_data, but user_data is often not available since it's needed for other things, so you have to add a GtkWidget *tooltip_window to the other thing. If other thing is e.g. the application toplevel window, which of the sub-widget's tooltips should it keep? All of them? People will in many cases end up attaching the tooltip window to the widget. I also fail to see why the has-tooltip property has to be set to TRUE, even tho a tooltip window was set on the widget. ciao, --mitch ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Tooltips progress
On Thu, 1 Jun 2006, Matthias Clasen wrote:
Attached is some sample code using the new API. Opinions, comments,
suggestions are appreciated.
I don't remember too much of the original proposal, so I'll just go
by what I see in the examples...
What is the relation between the tooltip-markup and has-tooltip
properties ?
setting ::tooltip-markup should automatically set ::has-tooltip=TRUE;
as mentioned in the original proposal:
http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html
Is has-tooltip automatically set when setting tooltip-markup ?
Or do you only need to set has-tooltip if you want to connect to
query-tooltip ?
the idea behind ::has-tooltip is to reduce the number of required signal
emissions to figure a tooltip. e.g. by adding a PRIVATE_GTK_* flag that
indicates if the ::query-tooltips() emission is neccessary.
maybe it'd helpt to rename that property to ::can-tooltip?
Is the tooltip window available as a property too ? (The example uses
a dedicated setter for it).
i don't quite see a need for that. the custom window is only useful if
you implement your own ::query-tooltip() handler anyway and there you
could simply use the getter.
(if you want to argue consistency with other things settable/gettable
on widgets though, then yes, you have a point for also exporting it
as a property)
The example doesn't show tooltips constructed using the old tooltips
api, but I assume those will continue to work as before, right ?
that was the plan, i.e. you'd basically just do:
void
gtk_tooltips_set_tip (GtkTooltips *tooltips,
GtkWidget *widget,
const gchar *tip_text,
const gchar *tip_private)
{
g_object_set (widget, tooltip-markup, tip_text, NULL);
}
Matthias
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Tooltips progress
On Thu, 1 Jun 2006, Michael Natterer wrote:
On Wed, 2006-05-31 at 22:08 +0200, Kristian Rietveld wrote:
Currently, we are using the following query-tooltips signal:
gboolean (*query_tooltip) (GtkWidget *widget,
gint x,
gint y,
GtkTooltip *tooltip);
But if a user sets a custom using gtk_widget_set_custom_window(), we don't
have to pass a GtkTooltip around. So currently I just set the tooltip
field to NULL, so the user knows he has to use his own custom tooltip
window (and we assume he has a reference to that). Is this okay or do
we want to change this? We could also move the _set_custom_window()
functions into GtkTooltip for example.
I would very much appreciate if the GtkTooltip object also kept track
of the custom window. IMHO it makes no sense to handle this differently.
the widget is meant to do that:
voidgtk_widget_set_tooltip_window (GtkWidget *widget,
GtkWindow *custom_window);
GtkWindow* gtk_widget_get_tooltip_window (GtkWidget *widget);
for reasons outlined in a previous reply from me to kris.
gtk_tooltip_set_markup() vs. gtk_tooltip_set_window()
simply feels much better than the asymmetry in
gtk_tooltip_set_markup() vs. gtk_widget_set_tooltip_window()
well, you'd not use GtkTooltip at all if you used
gtk_widget_set_tooltip_window() before. in that way,
the asymmetry simply reflects your usage.
The current approach even limits the new tooltip system's use cases,
since you have to set the custom window *outside* the callback. There
is no way to decide *in* the callback if a standard tooltip is
sufficient, or if a custom window is needed.
i don't think it'd be clear that/if the custom window will be available
in the GtkTooltip object again upon the next ::query-tooltip()
emission. especially since users are not supposed to access GtkTooltip
objects/structures in anyway *outside* of ::query-tooltip(), as outlined
originally:
http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html
also, passing GtkTooltip as NULL is meant to be as a clear indication
that the user has to tinker with gtk_widget_get_tooltip_window()
instead of the tooltip object. this avoids ambiguities like:
static gboolean
query_tooltip (GtkWidget *widget,
gint x,
gint y,
GtkTooltip *tooltip)
{
gtk_tooltip_set_markup (tooltip, See Me?);
g_object_new (GTK_TYPE_BUTTON,
parent, gtk_widget_get_tooltip_window(),
label, Can You Click Me?,
NULL);
gtk_tooltip_set_icon (tooltip, messup_pixbuf);
}
what's the tooltip code supposed to do here?
and yes, the API basically enforces that you decide per widget if
an own tooltip window is needed or not. but i don't think that is
a strong limitation, we have been discussing usage cases quite some
in thise thread and nothing required to defer this decision into
the callback (and no existing tooltip code i know of requires this
either).
so giving the benefits in API (and implementation) this provides,
i think it is a reasonable limitation to make.
Another problem is the assymetry in getting the relevant data to the
callback. With markup, the GtkTooltip can be queried for the markup,
if it's a custom window, you have to get it to the callback somehow.
Kris just forgot the getter for the custom window on the widget,
so signal handler user_data is left alone.
In your example code it's passed as user_data, but user_data is
often not available since it's needed for other things, so you
have to add a GtkWidget *tooltip_window to the other thing.
If other thing is e.g. the application toplevel window, which
of the sub-widget's tooltips should it keep? All of them? People
will in many cases end up attaching the tooltip window to the
widget.
I also fail to see why the has-tooltip property has to be
set to TRUE, even tho a tooltip window was set on the widget.
i think this can be come by if we implement:
- gtk_widget_set_tooltip_window() should automatically set:
GtkWidget::has-tooltip = (custom_window != NULL ||
GtkWidget::tooltip-markup != );
- setting GtkWidget::tooltip-markup should automatically set:
GtkWidget::has-tooltip = (custom_window != NULL ||
GtkWidget::tooltip-markup != );
right?
ciao,
--mitch
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
