Hi; On 18 November 2015 at 11:16, Richard Shann <rich...@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-l...@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] _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list