Hi, ALL,
According to the documentation here the function is deprecated. However it does not mention what should be used instead.
Do I understand correctly that this functionality is and will not be supported in GTK applications?
What is the reasoning behind this change?
Thank you.
It does say that the setting should not be used in newly written code, and that GTK will ignore its value.
Correct; the timeout of the tooltips is not configurable per-application or per-system.
The real question would be: why do you think you need to set the timeout of a tooltip in the first place?
Settings are not cheap—both in terms of code and in terms of maintenance. So we don’t really add them unless strictly necessary. Additionally, in this case, nothing in the GUI made use of this setting; there is no way to configure this value outside of the application, so there’s no way of a user to change its value. This means that the setting itself is pointless.
Well, I think I was concerned by the tooltip popup myself 10 years ago. Problem is, that if you use an app for the first time, you like tooltips, as it help you learning. But when you know that app already well, you may hate the tooltips. I guess my question that time was how a user can turn on/off tooltips for an app. If I remember correctly answer on mailing list was that it is not possible easily.
Hi, Emmanuelle,
OK.
OK
OK, so basically the tooltip timeout was not implemented inside GTK and calling this function wasn’t do anything, right?
So maybe it is good idea to implement this functionality? If I understand correctly, this should delay the tooltip display for X amount of milliseconds. Why not let the application decide how long it needs to wait prior to displaying the tooltip Or even turn them off on demand. Also, I think you kind of contradict yourself - " there is no way to configure this value outside of the application" vs " the timeout of the tooltips is not configurable per-application or per-system". The former sentence may suggest that you can configure it in application itself, which former cancels.
Also, look at Stefan reply.
Thank you.
I didn’t say that at all. I said that nothing could modify that setting outside of a GTK application calling g_object_set (gtk_settings_get_default (), "gtk-tooltip-timeout", some_value, NULL), which makes it pointless. The user could not change that setting unless each application allowed that to happen. Back in GNOME 1, it’s possible the system settings offered that option, but it was not plugged into anything else, and it definitely disappeared over the past 15 years.
Why? You haven’t explained why this would be helpful or useful.
We don’t have a responsibility to have an option for everything.
Because tooltips are not configurable anywhere else; changing the delay (to the millisecond, as if anybody would care about that sort of granularity) is pointless.
We can maybe discuss to have a central toggle to decide whether or not tooltips should be shown, but I personally find that option fairly aggressive against users.
You can’t change this per-application from a central location; that’s the “downside” of using a toolkit: options are applied to all applications using the toolkit. If you decide to disable tooltips, you’ll disable tooltips everywhere. This means applications would need to have a UI control to toggle the tooltips visibility, which moves the responsibility on maintenance and design into each application, and makes applications slightly different.
To be fair, tooltips are not used everywhere any more, as a UI concept, since the introduction of touch-enabled interfaces. UI design tries to make the various controls more easily understandable without necessarily leaving the pointer on a UI element for a while, and then reading a bunch of text.
Hi, Emmanuelle,
Well, we are not talking about GNOME, are we?
For some unknown reason you think that this post is about GNOME, like one of my previous one on the ML, when in fact this post is about GTK-based application which is not related to GNOME.
This application can infact be running on Windows, or OSX.
So my question one more time is - why do you think such application can’t call:
g_object_set( gtk_settings_get_default(), "gtk_tooltip_timeout", 0, NULL );in its code and make the tooltip appear immediately (or not appear at all - depending on the meaning of “0”).
One more time - I’m talking about user code in GTK-based application not related to GNOME.
Some application may use it.
It is possible, as Stefan wrote, that some end-user will want to turn them off, when they are not needed and annoy people. But the tooltip is already there inside the binary.
Or it is possible that there is a need of the displaying tooltip relatively quickly in order to save someone life in some medical application.
Or maybe there are multiple threads running in the application and you don’t want to see the tooltips while they are running and producing the results you want to see and you don’t care about anything else.
You can make multiple use-cases for such thing.
What do you mean? Both Windows and OSX have the possibility of tooltip timeout. OSX can have it OS- or app-based.
Once again - look at Stefan reply. Novice vs experienced user.
But when you know that app already well, you may hate the tooltips. I guess my question that time was how a user can turn on/off tooltips for an app.
You can’t change this per-application from a central location; that’s the “downside” of using a toolkit: options are applied to all applications using the toolkit. If you decide to disable tooltips, you’ll disable tooltips everywhere. This means applications would need to have a UI control to toggle the tooltips visibility, which moves the responsibility on maintenance and design into each application, and makes applications slightly different.
To be fair, tooltips are not used everywhere any more, as a UI concept, since the introduction of touch-enabled interfaces. UI design tries to make the various controls more easily understandable without necessarily leaving the pointer on a UI element for a while, and then reading a bunch of text.
[/quote]
The last statement is correct. But for fairly large “desktop” application it still make sense.
Thank you.
We are not, but GTK doesn’t have any configuration utility, so it’s an example of what any configuration system would need to do.
I’m not talking about GNOME; of course, since GTK is used by GNOME, and since GNOME developers are the major contributors to GTK, any change to GTK is usually seen through the lens of how GNOME will take advantage of that.
I’m sorry, this is simply not good enough.
Before adding new functionality in GTK we require that it gets used by at least three different applications. We don’t add functionality because “some application” may use it.
Do you have an actual example of an application using or requiring this kind of functionality—possibly on different platforms? Are you maintaining one such application?
Did you actually do some user testing to determine this split? We don’t have “novice” or “experienced” settings, so this would require a fair amount of design to determine if we have this kind of split somewhere else.
Hi,
I understand that GTK is used by GNOME, but it is much more than just a GMOME toolkit.
It is a library that people can use to develop their own application. An application that could or could not be affiliate with GNOME. Or it could be running on MS Windows, since GTK is a cross-platform library.
So, when people put the ‘=’ sign between GTK and GNOME I’d say they are plain wrong.
Also, why does GTK needs any configuration utility? Putting the 1 line of code as I wrote doesn’t cost anything and it can be made work per-application (for example, use last parameter as application name).
I understand and agree with such policy. Because otherwise people will start putting a lot of non-useful junk into the library.
The only problem is - you as GNOME developers (not GTK one) request that those 3 applications were GNOME basic applications, i.e. the one that comes with GNOME. Or am I missing something?
Once again you are talking about GNOME.
As an end-user application developer I see myself creating an application that can be installed on the end user system (a good example “accounting software” - not a basic GNOME one) and while the user get familiar with it tooltips are useful. But when the accountant gets a grip on it - they are just un-needed junk which turns away an attention.
This is just an example, but you should get an idea.
I am not talking about GNOME applications. Please, try to read what I wrote, instead of reading what you think I wrote. If I wanted to say that you need three GNOME applications to share some feature in order for it to be proposed for inclusion in GTK, I would have written precisely that.
Once again you purposefully misread what I wrote.
We don’t have “novice/expert” split in any part of the GTK API. We don’t have settings or API that can be described as “for novices” or “for experts”. Appealing to that kind of user interaction split (which is, in many cases, simply a mistake) requires that you back it up with some proof—like user testing.
Have you tried adding accelerators and shortcuts?
A conventional wisdom in advanced users is to rely a lot less on pointers and much more on keyboards. This means that tooltips are not really part of the user interaction for “experts”.
Additionally, your application could have a series of UI elements that implement most commonly used actions, which would not require tooltips.
In general, tooltips are added by application developers, not by the toolkit. This means that you can decide to never show a tooltip ever again from within your application. Once you set up the UI of your application, you can check your own setting, and set a tooltip on a UI element or not.
Hi, Emmanuelle,
But when the accountant gets a grip on it - they are just un-needed junk which turns away an attention.
Have you tried adding accelerators and shortcuts?
“Usually”, accelerators and shortcuts needs to be learnt by going thru the menus. Unless they are generals, like Ctrl+O for opemning a file or Ctrl+N for creating.
A conventional wisdom in advanced users is to rely a lot less on pointers and much more on keyboards. This means that tooltips are not really part of the user interaction for “experts”.
Correct.
And if there is a so called newcomer, that needs to learn a system?
Additionally, your application could have a series of UI elements that implement most commonly used actions, which would not require tooltips.
In almost all applications I saw tooltips are used from the toolbars and not from the UI elements.
In general, tooltips are added by application developers, not by the toolkit. This means that you can decide to never show a tooltip ever again from within your application. Once you set up the UI of your application, you can check your own setting, and set a tooltip on a UI element or not.
And how do I notify the user that (s)he has such option?
And then what do I do to remove the tooltips - do not display them?
I thought that I can somehow set the delay to -1 and then tooltips will not be shown, because the delay of 0 can mean “show immediately”.
Or maybe do that by some other means. If yes - how?
Am I missing something?
Thank you.
Also, kind of unrelated:
I tried to reply to the thread directly from the e-mail but received following:
The only picture there is is a one from you. I don’t have an avatar.
Could you please check what is happening?
Thank you.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.