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

[Richard Shann]

On Wed, 2015-11-18 at 12:27 +0000, Emmanuele Bassi wrote:
> Hi;
> 
> On 18 November 2015 at 11:16, Richard Shann <address@hidden> 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