Re: Callback based tooltips (Re: New tooltips API, continued)
On Thu, Jun 01, 2006 at 05:16:51PM +0200, Tim Janik wrote: On Wed, 31 May 2006, Kristian Rietveld wrote: On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: I once wrote down how tooltips should behave: I mostly like the behaviour you described below. - Tooltips are too intrusive. The text should be smaller, and not sure if this has been raised already... the font size of the tooltips should be exactly as large as the default font size (module tooltip markup of course) to avoid reducing usability of the tooltips in contrast to normal text (labels). The text for default/simple tooltips using toolip-markup are drawn using the default GTK+ font at this point. FireFox does this too, it seems. -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Callback based tooltips (Re: New tooltips API, continued)
On 6/1/06, Tim Janik [EMAIL PROTECTED] wrote: On Wed, 31 May 2006, Kristian Rietveld wrote: On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: I once wrote down how tooltips should behave: I mostly like the behaviour you described below. - Tooltips are too intrusive. The text should be smaller, and not sure if this has been raised already... the font size of the tooltips should be exactly as large as the default font size (module tooltip markup of course) to avoid reducing usability of the tooltips in contrast to normal text (labels). As long as the font (and other things) are easily themable, the default values are not as important. And as gtk+ doesn't currently have any kind of design for using different font sizes in different contexts, I'd say the default font is a good default. Until someone comes up with a plan that looks at the bigger picture. -- Tommi Komulainen [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Callback based tooltips (Re: New tooltips API, continued)
On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: I once wrote down how tooltips should behave: I mostly like the behaviour you described below. - Tooltips are too intrusive. The text should be smaller, and they should to the right of the cursor, and a little below the cursor's center. |\ ___ | | tooltip | not centered below the cursor. If you want to have the tooltip right of the cursor, a little below the cursor's center, does this also mean you want to have the tooltip follow the mouse pointer? Might make sense else in this case, else the tooltip might end up being positioned statically above the middle of a widget ... regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Callback based tooltips (Re: New tooltips API, continued)
On 4/25/06, Tim Janik [EMAIL PROTECTED] wrote: i don't think there's a point in implementing grouping unless the above question has been answered, i.e. we've gotten a resonable usage scenario. so until that happens, it's probably best to leave groups out of the API spec. Well, one reason would be that it is in our current tooltip support, and we don't just remove features for no reason... The reason for its existance is that it is annoying to have to wait for every other tooltip again when you are moving the mouse over the toolbar to see them all. And of course, putting all tooltips in one group makes the behaviour of tooltips equally annoying, since you then have to hunt for a tooltip-less area to get out of fast-tooltip mode again... Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Callback based tooltips (Re: New tooltips API, continued)
Matthias Clasen [EMAIL PROTECTED] writes: On 4/25/06, Tim Janik [EMAIL PROTECTED] wrote: i don't think there's a point in implementing grouping unless the above question has been answered, i.e. we've gotten a resonable usage scenario. so until that happens, it's probably best to leave groups out of the API spec. Well, one reason would be that it is in our current tooltip support, and we don't just remove features for no reason... The reason for its existance is that it is annoying to have to wait for every other tooltip again when you are moving the mouse over the toolbar to see them all. And of course, putting all tooltips in one group makes the behaviour of tooltips equally annoying, since you then have to hunt for a tooltip-less area to get out of fast-tooltip mode again... That's because that feature simply doesn't work. Moving the mouse to a tooltip-less area does not turn off fast mode as it should, regardless of grouping. I once wrote down how tooltips should behave: Tooltips: - - Tooltips are too intrusive. The text should be smaller, and they should to the right of the cursor, and a little below the cursor's center. |\ ___ | | tooltip | not centered below the cursor. - In normal mode, tooltips should appear after ~1.5 s. - When in browse mmode (tooltips appear immediately), tooltips should not actually appear immediately, but rather after ~75-100 ms of the mouse cursor not moving, so that you can move over a set of objects without getting a ton of tooltips displayed. - After a period of around 500ms without any tooltip being displayed, browse mode should be turned of. (That way you can get rid of tooltips by shaking the mouse a bit). - Browse mode should be turned off when you leave the area of the tooltip group. - They should not appear before we have seen at least one motion event on the widget (ie. stuff that pops up under the mouse should not get a tooltip). (Or possibly an 'enter' that doesn't come from popping up if such a thing can be generated). Soren ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Callback based tooltips (Re: New tooltips API, continued)
On Tue, 25 Apr 2006, Matthias Clasen wrote: On 4/25/06, Tim Janik [EMAIL PROTECTED] wrote: i don't think there's a point in implementing grouping unless the above question has been answered, i.e. we've gotten a resonable usage scenario. so until that happens, it's probably best to leave groups out of the API spec. Well, one reason would be that it is in our current tooltip support, and we don't just remove features for no reason... we indeed deprecate features when there's no good reason for their existance. and re-introducing useless features in new APIs definitely is a bad idea. however, i'm not even saying we can't have that, since it can easily be added onto the API i suggested, i'm just saying we should be sure it's needed and makes reasonable sense. but i've yet to see a good usage scenrio for seperate tooltip groups. The reason for its existance is that it is annoying to have to wait for every other tooltip again when you are moving the mouse over the toolbar to see them all. i'm not arguing to leave out the show-next-tooltip-immediately feature, i'm just saying there's no reason to not apply this to all tooltips. And of course, putting all tooltips in one group makes the behaviour of tooltips equally annoying, since you then have to hunt for a tooltip-less area to get out of fast-tooltip mode again... i don't think this is of course obvious. hunt is simply exxagerating here, since you can easily move the pointer out of the window or into blank space areas like frames. in any case, this isn't an argument *for* individual groups, because if the user meant to explicitely see *no* tooltip, individual groups don't give you that behaviour either, that's because after the intiait tooltip timeout has passed after leaving fast-tooltip mode in your scenario, you're getting a tooltip *again*. you seem to be arguing that it's good for the user to wait a bit until he can figure the new tooltip (group), that doesn't count as good UI behaviour in my book though ;) also, it's always easy to leave tooltip mode by pressing any key, if you really are in a full screen view and have an urge to see no tooltip at all, *and* every place in the app is setup with tips (quite unlikely, eh? ;) Matthias --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Callback based tooltips (Re: New tooltips API, continued)
On Tue, 25 Apr 2006, Soeren Sandmann wrote: Matthias Clasen [EMAIL PROTECTED] writes: On 4/25/06, Tim Janik [EMAIL PROTECTED] wrote: i don't think there's a point in implementing grouping unless the above question has been answered, i.e. we've gotten a resonable usage scenario. so until that happens, it's probably best to leave groups out of the API spec. Well, one reason would be that it is in our current tooltip support, and we don't just remove features for no reason... The reason for its existance is that it is annoying to have to wait for every other tooltip again when you are moving the mouse over the toolbar to see them all. And of course, putting all tooltips in one group makes the behaviour of tooltips equally annoying, since you then have to hunt for a tooltip-less area to get out of fast-tooltip mode again... That's because that feature simply doesn't work. Moving the mouse to a tooltip-less area does not turn off fast mode as it should, regardless of grouping. well, given that behaviour is implemented, there's no need for seperate groups, right? I once wrote down how tooltips should behave: Tooltips: - - Tooltips are too intrusive. The text should be smaller, and they should to the right of the cursor, and a little below the cursor's center. |\ ___ | | tooltip | not centered below the cursor. sounds like a good default, but should be configurable/customizable by the theme engine. - In normal mode, tooltips should appear after ~1.5 s. same here, that's a reasonable default for some users but needs to be configurable (prolly per-display). - When in browse mmode (tooltips appear immediately), tooltips should not actually appear immediately, but rather after ~75-100 ms of the mouse cursor not moving, so that you can move over a set of objects without getting a ton of tooltips displayed. - After a period of around 500ms without any tooltip being displayed, browse mode should be turned of. (That way you can get rid of tooltips by shaking the mouse a bit). Soeren, can you provide reasoning for seperate groups once this behaviour is in place? - Browse mode should be turned off when you leave the area of the tooltip group. what's thr rationale here? why shouldn't browse mode continue, say on the next group of text entry fields after browsing toolbar tooltips? or phrased differently, wehn in browse mode, why should the user wait *extra* time for some of the tooltips and not others? - They should not appear before we have seen at least one motion event on the widget (ie. stuff that pops up under the mouse should not get a tooltip). (Or possibly an 'enter' that doesn't come from popping up if such a thing can be generated). and exception to this (e.g. in the tree view) is prolly either: a) a tooltips is already shown, and the view scrolls to a new tip, or b) no tooltip is already shown and the view scrolls to a new tip. i think it's pretty clear that you want an update on (a), i'm not so sure on whether you want the tip to pop up on (b) though, and if that feels nice in conjunction with the tooltip timeout. Soren --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Callback based tooltips (Re: New tooltips API, continued)
Tim Janik [EMAIL PROTECTED] writes: That's because that feature simply doesn't work. Moving the mouse to a tooltip-less area does not turn off fast mode as it should, regardless of grouping. well, given that behaviour is implemented, there's no need for seperate groups, right? I am not really arguing for (or against) groups. I think 'groups', if implemented, should probably not have any representation in the UI though. They might be useful in the API. - Browse mode should be turned off when you leave the area of the tooltip group. what's thr rationale here? why shouldn't browse mode continue, say on the next group of text entry fields after browsing toolbar tooltips? or phrased differently, wehn in browse mode, why should the user wait *extra* time for some of the tooltips and not others? Right, replace 'the area of the tooltip group' with 'the set of widgets that have tooltips'. The important thing is, if the cursor moves to a place where there are no tooltips, browse mode should be turned off. - They should not appear before we have seen at least one motion event on the widget (ie. stuff that pops up under the mouse should not get a tooltip). (Or possibly an 'enter' that doesn't come from popping up if such a thing can be generated). and exception to this (e.g. in the tree view) is prolly either: a) a tooltips is already shown, and the view scrolls to a new tip, or b) no tooltip is already shown and the view scrolls to a new tip. A view scrolling under the mouse cursor should generally be counted as motion, I think. Soren ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Callback based tooltips (Re: New tooltips API, continued)
On Tue, 25 Apr 2006, Soeren Sandmann wrote: Tim Janik [EMAIL PROTECTED] writes: That's because that feature simply doesn't work. Moving the mouse to a tooltip-less area does not turn off fast mode as it should, regardless of grouping. well, given that behaviour is implemented, there's no need for seperate groups, right? I am not really arguing for (or against) groups. I think 'groups', if implemented, should probably not have any representation in the UI though. They might be useful in the API. - Browse mode should be turned off when you leave the area of the tooltip group. what's thr rationale here? why shouldn't browse mode continue, say on the next group of text entry fields after browsing toolbar tooltips? or phrased differently, wehn in browse mode, why should the user wait *extra* time for some of the tooltips and not others? Right, replace 'the area of the tooltip group' with 'the set of widgets that have tooltips'. The important thing is, if the cursor moves to a place where there are no tooltips, browse mode should be turned off. ACK ;) - They should not appear before we have seen at least one motion event on the widget (ie. stuff that pops up under the mouse should not get a tooltip). (Or possibly an 'enter' that doesn't come from popping up if such a thing can be generated). and exception to this (e.g. in the tree view) is prolly either: a) a tooltips is already shown, and the view scrolls to a new tip, or b) no tooltip is already shown and the view scrolls to a new tip. A view scrolling under the mouse cursor should generally be counted as motion, I think. imagine there'S no tooltip yet, and you're (auto-)scrolling onto an item with tooltip. you think that should be handled like ordinary motion, wait for the initial tooltip timeout and the pop up the new item's tip? thanks for providing a writing up the general timing behviour for tooltips btw, forgot to say that in the previous email ;) Soren --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Callback based tooltips (Re: New tooltips API, continued)
I once wrote down how tooltips should behave: Tooltips: - - Tooltips are too intrusive. The text should be smaller, and they should to the right of the cursor, and a little below the cursor's center. |\ ___ | | tooltip | not centered below the cursor. sounds like a good default, but should be configurable/customizable by the theme engine. What about RTL locales? P.T. -- Petr Tomasek http://www.etf.cuni.cz/~tomasek ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Callback based tooltips (Re: New tooltips API, continued)
On 4/25/06, Tim Janik [EMAIL PROTECTED] wrote: well, given that behaviour is implemented, there's no need for seperate groups, right? The behaviour described by soeren does indeed sound like it may make tooltips groups unnecessary. I've asked Owen if he can describe the original motivation for the groups better than I can, just in case. |\ ___ | | tooltip | not centered below the cursor. sounds like a good default, but should be configurable/customizable by the theme engine. and the locale, as pointed out somewhere else. it should possibly flip in rtl locales. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Callback based tooltips (Re: New tooltips API, continued)
Tim Janik wrote: reading your proposal for the first time (both versions of it), i can't help the feeling that it seems a bit complicated (with nesting tip areas etc.) at least from a widget user perspective. i'm wondering if a callback based approach wouldn't ease the whole setup a lot, so to brainstorm for a second: It looks like that our proposals have a lot in common at the higher level, but we have different thoughts on the details. This might be caused by the complexity of GtkTooltipWindow in my proposal. While I started out with a small callback based setup in the past (long before I managed to send out the first proposal), I was pointed to a mail from Owen [1] where he explained his issues with a callback-based approach. His sketch of an alternate approach looked reasonable to me, so I decided to go on with that and fill in the details (some of which still remain to filled in though). We do agree that we should have a tooltip-markup property on widgets. The query_tooltip signal has some things in common with the populate_tooltip signal we added in my proposal. As an afterthought, I guess the fact that we added a populate_tooltip signal actually indicates that a callback-based is wished ... The point where our proposals really differ is at handling complex tooltips. I think we should go with your approach, if we can fix the problems raised which led Owen to come up with an alternative approach: * Tooltips should be available on demand by the keyboard (already raised in this thread), * Extensibility, which has already been solved with the idea of allowing the widget user to set a custom tooltip window, * Cases where tooltip texts or tooltip areas change dynamically. Tooltips areas change when for example scrolling in a GtkTreeView, I guess this is already handled by the fact that we will query for a tooltip again when the pointer moves (where we might also want to re-query on scroll events). For tooltip texts we would just need a way to get hold of GtkTooltip outside of the query_tooltip callback ... * We also add in that we need the ability to display the tooltip on-demand, which has been raised at a later point. it also coveres moderately advanced cases with gtk_tooltip_set_icon() and gtk_tooltip_set_custom(). for real adventurous tooltipping, people can use gtk_widget_set_tooltip_window() and mess up their custom window instead of GtkTooltip inside of a ::query_tooltip() handler. the common case however would be to not make use of gtk_widget_set_tooltip_window(). When using a custom tooltip window, who would handle popping up/down that window? Is the idea to pop up/down the window from a query_tooltip_callback()? - for area specific tooltipping, widgets don't need to track the mouse pointer themselves. once gtk is in tooltip mode, ::query_tooltip() is simply emitted as the pointer moves. And as said above, maybe also on scroll events. - in constrast to your proposal, the decision of *when* to popup tooltips, and how long they are left up is completely up to gtk. this is actually meant to improve user experience, since gtk can honour per-display tooltip behaviour settings, and tooltip popup behaviour will be consistent across widgets on the same display. In my proposal gtk+ would decide when to pop up/down the tooltips for all tooltips, except for the most complex case where one provides a GtkTooltipWindow themselves. - there's no grouping of tooltips provided. for one, that's because i don't really understand the use case for that. once in tooltip mode, all widget tooltips can simply be popped up/changed seemlessly, until some significant user action forces leave of tooltip mode again (button press, key press). and for another, if grouping really is required, that can still be implemented after the fact with API similar to what you suggested. One of the usecases of grouping can, for example, be found in toolbars. Toolbars have multiple buttons/items, which are all different widgets. If the tooltip is already displayed for one item and the mouse is moved to another item on the toolbar, you usually do not want to wait for the new tooltip to popup. The solution here is to create a tooltip group and include all items on the toolbar. - because GtkTooltip is opaque and basically just implements a limited set of tip setters, future versions could allow gtk-wide or per-display plugging of tooltip objects. this could be interesting for embedded devices, respectively touchscreens, which may want to display tooltips in a non-standard way. e.g. an info popup in the upper right corner like the N770 has it. it also would cover themes that want to implement specialized tooltip display. This is an interesting win with your proposal. - querying tooltips via ::query_tooltip() will also be easily customizable via connecting signal handlers to widgets, and it will work for insensitive widgets
Re: Callback based tooltips (Re: New tooltips API, continued)
On Thu, 2006-04-06 at 10:00 +0200, Tim Janik wrote: On Thu, 6 Apr 2006, Alex Graveley wrote: I sounds good to me, as long as I can force a tooltip to display on-demand as it would if the mouse were hovering over it. hm, can you please explain the use case for forefully displaying tooltips? as opposed to waiting for the usual user configurable timeout and honour user settings like display-tooltips = off ? I can think of a scenario where an application is used for the first time and shows a tooltip for a widget that hasn't even got focus to direct the user to start using the software. For example, a complicated window might have a bunch of widgets on it and new users might think, crap where do I start? But a tooltip could be shown with something like Start here by entering your search criteria into this entry box I think my scenario is more of a tutorial mechanism for new users. -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Callback based tooltips (Re: New tooltips API, continued)
I sounds good to me, as long as I can force a tooltip to display on-demand as it would if the mouse were hovering over it. -Alex Tim Janik wrote: On Tue, 14 Mar 2006, Kristian Rietveld wrote: Hey, [...] hi kris. reading your proposal for the first time (both versions of it), i can't help the feeling that it seems a bit complicated (with nesting tip areas etc.) at least from a widget user perspective. i'm wondering if a callback based approach wouldn't ease the whole setup a lot, so to brainstorm for a second: ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Callback based tooltips (Re: New tooltips API, continued)
On Thu, 6 Apr 2006, Alex Graveley wrote: I sounds good to me, as long as I can force a tooltip to display on-demand as it would if the mouse were hovering over it. hm, can you please explain the use case for forefully displaying tooltips? as opposed to waiting for the usual user configurable timeout and honour user settings like display-tooltips = off ? -Alex --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Callback based tooltips (Re: New tooltips API, continued)
On Thu, 6 Apr 2006, Brijesh wrote: I can give use case where i need tooltip when i tell it to display i am gtk on one of the embedded plateform in which we dont have mouse. we have only keyboard. so when button gets focused , i want to display tooltip. how do i do it? i think that could be covered by a 0 seconds timeout. is that good enough for you? Brijesh eInfochips Business Disclaimer: This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by eInfochips Limited and/or eInfochips Inc(eInfochips) unless sent with that express intent and with due authority of eInfochips. eInfochips has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Note that I am not in a contracted relationship with you and that i have no obligations with respect to treatmeant of your email whatsoever. In general, I will not treat emails as confidential material without specific written mutual agreements. Any further email I receive, which contains this disclaimer or a disclaimer similar in spirit, will most likely be silently ignored. Confidentiality disclaimers are not appropriate for a public discussion forum like this list. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Callback based tooltips (Re: New tooltips API, continued)
Tim Janik wrote: hm, can you please explain the use case for forefully displaying tooltips? as opposed to waiting for the usual user configurable timeout and honour user settings like display-tooltips = off ? Such a use case would not necessarily ignore user settings. It could be a canvas, where tooltip should be shown over specific areas/objects; i.e. a thing like container widget with children which are not widgets. Note that it's not the same as area-specific widget tooltips, e.g. one may want to have tooltip timeout be triggered only when cursor is over some object but not when it's over blank space. Best regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Callback based tooltips (Re: New tooltips API, continued)
On Thu, 6 Apr 2006, Yevgen Muntyan wrote: Tim Janik wrote: hm, can you please explain the use case for forefully displaying tooltips? as opposed to waiting for the usual user configurable timeout and honour user settings like display-tooltips = off ? Such a use case would not necessarily ignore user settings. It could be a canvas, where tooltip should be shown over specific areas/objects; i.e. a thing like container widget with children which are not widgets. Note that it's not the same as area-specific widget tooltips, e.g. one may want to have tooltip timeout be triggered only when cursor is over some object but not when it's over blank space. i don't understand the distinction between blank space and object you're making here. it should be pretty simple actually, once the mouse cursor moved, ::query-tooltips() is emitted after the configured tooltip-timeout, and then your signal handlers get to decide whether a specific location has a tooltip or not. the only case that's not fully covered by this is: 1) area foo has no tooltip 2) mouse moves into area foo 3) tooltip-timeout expires 4) ::query-tooltip() is emitted 5) query_tooltip_handler() returns FALSE; // there's no tooltip here (yet) 6) application changes state 7) application sets (or changes) tooltip on area foo in this case, the tip won't neccessarily be updated without the mouse moving. however that case should be pretty rare and may not even be usually noticable. however, it can be helped by exposing some function the tooltip implementation will require anyway, i.e.: void gtk_display_force_tooltip_query (GdkDisplay*); /* display may be NULL */ this'd basically enforce a jump to (4) if tooltip timeout has already expired, or causes the timeout to be restarted. it'd not usually be required to be called by user code though. Best regards, Yevgen --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Callback based tooltips (Re: New tooltips API, continued)
On 6 Apr 2006, at 09:00, Tim Janik wrote: On Thu, 6 Apr 2006, Alex Graveley wrote: I sounds good to me, as long as I can force a tooltip to display on-demand as it would if the mouse were hovering over it. hm, can you please explain the use case for forefully displaying tooltips? as opposed to waiting for the usual user configurable timeout and honour user settings like display-tooltips = off ? Haven't really been following this discussion, but I hope people are remembering that in gtk, tooltips are supposed to be available on demand from the keyboard (by pressing Shift-F1), so any new scheme should ensure this continues to work. Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]Java Desktop System Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Callback based tooltips (Re: New tooltips API, continued)
On 6 Apr 2006, at 15:59, Calum Benson wrote: Haven't really been following this discussion, but I hope people are remembering that in gtk, tooltips are supposed to be available on demand from the keyboard (by pressing Shift-F1), Sorry, Ctrl+F1... -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]Java Desktop System Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
