Re: [Denemo-devel] Tooltips - what am I doing wrong?



On Wed, 2015-11-18 at 12:27 +0000, Emmanuele Bassi wrote:
Hi;

On 18 November 2015 at 11:16, Richard Shann <richard rshann plus com> wrote:

I've tracked this down, in the latest manual for gtk3:
https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-tooltip-browse-timeout
GtkSettings:gtk-tooltip-browse-timeout has been deprecated since version 3.10 and should not be used in 
newly-written code.
This setting is ignored.

So, it is a "feature". It appears to be the case that even the regular
time before a tooltip appears can no longer be controlled, which many
people will find intolerable (I know of people who set very long times
on the tooltips, basically because it takes them long enough to read the
labels on menu items, so that having tooltips pop up while they are
looking for something is annoying - they would take a long time to read
a tooltip anyway).
I think we'll have to disable tooltips for GTK version 3.10 and above.
Fortunately the tooltip information is still available for commands,
it's just all the help for playback controls etc etc that will get lost.

I honestly don't understand why would application developers expose a
tweak to ensure their applications don't behave like any other
application on the system.

If the people that are not interested in tooltips, and thus change the
timeout to ensure that they are not subject to them, then you can
simply offer a way to disable all tooltips on your controls without
any loss of functionality — after all, these people are not interested
in tooltips in the first place.

If this is an accessibility issue, like you seem to present it, then
we definitely need a session-wide toggle that changes the delay for a
tooltip to be raised for all applications, not just one. That would be
a great thing to introduce in the session, and I'd be happy to review
a patch to that effect.

But in the longer term we are coming up to a crunch - the people
developing Gtk are clearly only interested in a narrow group of users.

Defining "narrow" as "the group that I'm not in" is not conducive to
an honest discussion.

which is why I didn't do anything so idiotic as to define narrow as "not
my group". But you could very reasonably argue that "wide" equates to
large numbers of users and narrow to a few. Whereas, what I had in mind
is wide equating to diverse and complex uses and narrow just to the
popular simple uses. You can send an email and switch to a calendar and
lookup a web page with a simple interface comprising a few gestures, but
you can't do complex technical tasks efficiently that way. 

 You already reached your conclusion, and I'm
honestly not interested in convincing you, at that point.

Personally, I think the amount of users GTK is interested in covers
much, much more than the people tweaking their applications to change
the timeout of the tooltip on a per application basis — but I'm
*personally* interested in getting application developers to stop
considering GTK as a black box, where you just consume an API.

I've recently run some numbers on the GTK repository[0][1], and it's
clear that while the contributors change over the years, the number of
contributors is mostly stable; this means that new features come at
the expense of deprecations — otherwise there are simply not enough
resources to grow the toolkit while maintaining the old API
indefinitely.

For better or worse, the world of computing is changing. 

I think this is the crux of the matter. The "world of computing" has
been joined (swamped?) by millions of new users with new devices that
can't be used for complex tasks (which those millions would not think of
attempting anyway). And the GTK project is adapting to this "big
league".
So, I think you may have answered my question "Where do we go?": we will
have to revert to Gtk2 sooner or later. 

I guess the problem is that if we continue to offer a Gtk3 version the
GNU/Linux distributions will want to build against ever-newer versions
of Gtk3 with resultant problems like the one that started this thread.

Richard




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