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

[Emmanuele Bassi <ebassi gmail com>]

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. 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. GTK *has* to
change with it. New input methods; new user interactions; new design
directions; all of these do not come for free, and are a requirement
to be able to play in the big leagues — or to have a shot at remaining
relevant. GTK can be made to serve both old applications and new ones,
but it simply *cannot* do that without growing the numbers of its
contributors. Obviously new people will join to add new features,
which leaves the existing users of the old ones in charge of ensuring
that the API they use in their applications is up to date.

I know that maintainers of established projects do not want to take
over duties in GTK, but that's just the reality of the economics
involved. There are *no* free lunches.

> They decide that menus should not be torn off, and that is that, despite
> the fact that Denemo users do tear off menus if they are going to be
> using them for a while.

I sincerely hope you realize that "Denemo users" (leaving aside the
fact that you cannot even define how many those there are) is not a
useful metric for keeping functionality in a toolkit — unless,
obviously, Denemo developers are willing to commit resources to ensure
that the functionality is always tested and kept up to date with the
changes of the toolkit internals.

Tearoff menus are, by *any* metric that is not artificially restricted
to "the Denemo users", a very seldom used UI element in any UI that
has been designed in the past 15 years (to be generous; I haven't seen
them past the early '90s); they complicate the implementation of menu
widgets, which are in themselves one of the five most complicated
widgets inside GTK. The cost/benefit of having such a feature was
simply not worth it with the kind of resources we have working on GTK.
It's just that simple, and you'll notice that most of the
maintainership decisions made inside GTK are done that way.

> They decide that GtkFrames should not have a frame drawn, and so on.

GtkFrame widgets can draw a frame. It's controlled via CSS, and can be
done in a much better way that setting an enumeration value taken
straight off of Motif, circa 1994. That said, you may need to change
the minimum requirements for supporting GTK3 in order to have that,
because the CSS theming machinery is very much an evolving part of
GTK.

GTK 3 is not like GTK 2; it's not the slow moving toolkit, with sparse
releases, and minimal changes, that it once was. It's a very active,
iterating project, with lots of work being done. GTK moves fast
because the requirements of applications move fast, these days; it
sees lots of changes to its internals to ensure that performance is
acceptable. That usually means that API is stable, but deprecations
are more aggressively used; and that things like themes, which poke at
the internals of the toolkit, need to follow suit in terms of speed of
development.

If you want a toolkit that never changes, that never has deprecations,
and whose themes won't need to be updated, then you can still have
GTK2. The obvious side effect to those requirements is that GTK2 is
effectively dead — no new feature, minimal bug fixing, no new API.

> Any suggestions as to where we might go?

You may go to gtk-devel-list gnome org and discuss this with GTK
developers; you can join the #gtk+ IRC channel as well — GTK
developers are there most of the day in various timezones during the
week (please, don't join during the weekend: we also have lives :-)).

Ciao,
 Emmanuele.

[0]: https://www.bassi.io/articles/2015/09/15/who-wrote-gtk-3-18/
[1]: https://www.bassi.io/articles/2015/09/16/who-wrote-gtk-reprise/

-- 
https://www.bassi.io
[ ] ebassi [ gmail com]