https://bugs.documentfoundation.org/show_bug.cgi?id=99326
--- Comment #18 from Simon Long <si...@raspberrypi.org> ---
(In reply to Yousuf (Jay) Philips from comment #17)
> > 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.
Yousuf, you are looking at this issue solely as a LO user. You are not looking
at it as a user of a GTK environment. As I have asked above, what is the
purpose of GTK compatibility in LO unless to make LO match look and feel of the
other applications in a GTK environment in which it is being used? I cannot
think of one.
Your point seems to assume that someone is using LO as the only GTK application
on their system - as otherwise surely they would notice that they have the
auto-accelerator feature in all their other applications? And if someone did
notice that they had auto-accelerators enabled in multiple applications and
wanted to turn it off, by your argument, every GTK application would need to
individually offer them that as an option - as I have said before, that is not
how GTK applications work.
> 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.
You are trying to dissociate a GTK theme behaviour (auto-accelerators) from GTK
theme appearance, but the two are intrinsically linked; that's what a theme is
for. If a user picks a theme with auto-accelerators, they will get
auto-accelerator behaviour in all GTK applications.
> 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.
But what does it benefit a user to have a way to disable the feature in one
single application? If they don't like it, they will surely want to disable it
in all applications - providing a means to ignore theme in LO will only make
them look for a similar mechanism in other applications, and they won't find
one - because it shouldn't be set in applications.
Your point about some environments not allowing this parameter to be changed in
their user-friendly theme editors is not an argument for adding an override to
LO; it is an argument for adding the ability to globally set the parameter to
the theme editors.
> 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.
This was a bug in LO's GTK emulation which has been fixed - that's why we
didn't adhere to it since LO's establishment; LO was doing the wrong thing
before this fix. LO is now doing the right thing. The argument that we have
been doing the wrong thing for so long that we should never fix it is not a
valid one. We should absolutely attempt to adhere to every GTK property if we
are offering GTK compatibility - as otherwise, what's the point in offering it?
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
