https://bugs.documentfoundation.org/show_bug.cgi?id=99326
Yousuf (Jay) Philips <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected],
| |[email protected]
| |, [email protected]
--- Comment #17 from Yousuf (Jay) Philips <[email protected]> ---
(In reply to Simon Long from comment #7)
> (In reply to Yousuf (Jay) Philips from comment #6)
> > Yes ideally it shouldnt always be disabled, but with the current state of UX
> > issues that have arisen by following the condition in the gtk+2 theme file,
> > it would be best to disable it when building against gtk2.
>
> No, it wouldn't - that is a short-term bodge which does the wrong thing.
Not really a short-term dodge when it has been LO's behaviour since its
establishment. The point is to be conservative with this change (limit it to be
enabled only in gtk3) until it is fully matured.
> > Thanks for the information, though i dont know where to go to change this
> > setting and their isnt a GUI for changing this setting that the novice user
> > would know how to find. It is true that this is a setting in Gtk+2, but that
> > doesnt mean that we must follow it, as there are other gtk+2 apps that dont
> > - e.g. Firefox.
>
> Novice users do not change this setting; theme authors do. All a novice user
> does is to choose a theme. Theme authors do know where to find this setting,
When we move from an interface where we didnt support auto-accelerator to one
where we do, users will first assume that its either a bug (like i did in bug
97586, as well as others) or its a feature that has been implemented in LO,
rather than one that is being implemented based on a theme-level or OS-level
property. Users pick a theme based on what it looks like and not on the value
of the auto-accelerator property, so to say that users wouldnt want to change
this feature is inaccurate, as i'm unable to changing this feature in a easy
way and can imagine what a novice user will go through.
Some gtk+2 desktop environments (e.g. Xfce, Mate) provide users with the
ability to tweak their theme in a GUI interface, like being able to modify the
controls, icons, window borders, etc. They dont give the option to change the
accelerator property, so users who choose a theme which happens to have it
enabled dont have the ability to disable it there without jumping through
hoops.
> and all applications which use GTK+2 properly obey it - the argument that
> because some other applications are doing things incorrectly that it is
> therefore ok for LO to also do things incorrectly is not really sound
> reasoning.
The point I was attempting to get across is that we dont have to adhere to
every GTK+2 property if we believe it has a negative affect to our users user
experience. We havent been adhering to this property since LO's establishment,
so we dont have to adhere to it now just because.
> Implementing code to read this value from the theme and thereupon to enable
> or disable auto-hiding is a trivial change; it's probably easier than
> working out how to conditionally build without any of the auto-hide code...
Yes it is fine that we have the code that does this reading of the value, i am
saying that we should include an IF statement after the reading of this value
that if the user has left the option to show or hide auto-accelerator in the
options dialog to 'Automatic' (likely stored in registrymodifications.xcu as a
NULL value) and LO was built against gtk2 (built with the argument
--disable-gtk3) that auto-accelerator should be disable by default unless a
user/packager enables it. Below is an outline of how it would be written in
php:
auto_accelerator = value read from theme or OS;
auto_accelerator_options_level = value read from registrymodifications.xcu;
if ( auto_accelerator_options_level != NULL ) {
auto_accelerator = auto_accelerator_options_level;
} else {
if ( gtk2_build ) {
auto_accelerator = 0;
}
}
> If I get time in the next few weeks I will look at adding the ability to
> read this value from the theme and to use it to enable or disable auto-hide.
I assume as this gtk2 theming attribute hasnt been implemented yet that i'm
being affected by a gtk3 theme on my gtk2 desktop environment.
> Incidentally - you mention above the ability to compile LO against gtk2 - is
> that even possible?
The daily builds that TDF compiles are against gtk2 and i believe the ones
available on the libreoffice.org download page are also against gtk2.
(In reply to Samuel Mehrbrodt (CIB) from comment #11)
> Although I wonder what exactly the "major UX issue" is, that you are
> speaking of, Jay.
As stated, "this is a major UX issue in not being able to disable this
feature". Meaning not being able to disable this incomplete feature at the
application level and users having to go to the theme or OS level to do so.
(In reply to Simon Long from comment #12)
> But that isn't how GTK applications work. The whole point of GTK theming is
> that *all* applications built on GTK share the same look and feel, which
> comes from the theme. GTK applications do not have app-specific theme
> overrides, as why would you want to override the theme behaviour in only one
> application, rather than in all of them?
LO has app-specific theme and OS overrides options like whether to show icons
in menus, what font to use for the interface, and what option to use for middle
mouse-click, so this wouldnt be something new. Well i would want to overwrite
this theme or OS behaviour exclusively for LO, as it is the only application
that i use accelerators in (never even noticed that accelerators werent there
in any other app i use, but noticed it immediately when they disappeared in LO)
and the auto-accelerator feature is broken in various places (bug 99324).
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
