On 26 December 2017 at 20:06, Tomasz Gąsior <mail tomaszgasior kao pl>
wrote:
I would like to ask question directly to main GTK developers. Why
these
Xsettings are deprecated?
XSettings are an X11-only concept that does not translate to any other
windowing system platform supported by GDK.
You're probably thinking of GtkSettings properties - which can always
be set using the settings.ini file; some of the ones you're referring
to, though, have been deprecated and the handling code removed.
* gtk-icon-sizes
Custom icon sizes are part of the stock items system, and went away
alongside the stock items.
* gtk-enable-mnemonics
Mnemonics are hidden by default, and made visible when pressing "Alt",
so this setting is pointless.
* gtk-menu-bar-accel
The key used to toggle the menu bar is either part of the toolkit, and
thus shared by all applications and documented as part of the global
documentation; or it's defined by the application, in case of
conflicting key binding (though application developers are *strongly*
encouraged not to mess around with global key bindings).
* gtk-menu-bar-popup-delay
* gtk-menu-popdown-delay
* gtk-menu-popup-delay
These are internal details of the toolkit, and at most should be part
of the accessibility layer.
* gtk-show-input-method-menu
* gtk-show-unicode-menu
These two menu items are always visible in GTK+ 3.x and future major
versions; it's a toolkit feature, not something that comes under the
purview of application authors or users. Application developers can
intercept the context menu and use their own, if they really want to
have a different looking menu.
* gtk-button-images
* gtk-menu-images
* gtk-toolbar-icon-size
* gtk-toolbar-style
Application developers are the ones that ought to decide how their
application looks and behaves; if they wish to provide a setting for
users, it's entirely possible for them to do so.
* gtk-visible-focus
Focus rectangles are always visible, because otherwise it makes for
very poor UX.
* gtk-alternative-button-order
This is not marked as deprecated, but it ought to be.
The alternative button order was a remnant of GTK 1.2 carried over
into 2.0, but it's really a decision that is made by the platform's
human interface guidelines.
What is the reason of limiting GTK customization?
Not all customisation is good, warranted, or future-proof.
Why only application
programmer should have ability to change these settings (as g-object
properties etc.) and why user shouldn't?
Because application developers are the one deciding how their
applications should look like, and how it should behave. A toolkit
should not give out setting that radically modify an application, as
it's the wrong layer for that to work. If an application developer
wishes to provide settings to alter the UX of their project they can
do so.
And second question. Why you are forcing removing icons from images
and menu
items instead just disabling it by default in GNOME?
Because icons alongside text in menus and buttons do not provide any
additional value:
http://uxmyths.com/post/715009009/myth-icons-enhance-usability
On the other hand, lots of icons in the UI increase the cognitive load
on the user, who now has to interpret what an icon means in the
context of each application and then commit it to memory; and they
increase the load on the graphic artists, who now have to create
unique assets to represent complex concepts, often in 16x16 pixel
icons, which is utterly ridiculous.
We have this thing called "text" that is used to convey meaning;
pictographs do not really scale as well.
Maintaining code of
GtkImageMenuItem or images in buttons is too time-consuming?
Yes, it is. Mostly, because it's not "just maintaining code" in a
widget: you have to maintain the internal hierarchy of widgets; the
logic to switch between themes; the logic to swap between text, and
icons and text; the logic to change the setting depending on the
platform; the logic to change the setting depending on the desktop
environment on the same platform (remember: there is no "Linux"). On
top of that, every time we have to refactor the asset loading code, or
the rendering code, or the input layer, we have to deal with the
potential fallout of any change breaking this automagic code.
(I know that programmer can pack image to button or menu item
manually, but
it is not the same. It isn't convenient and user have not ability to
disable
images added this way.)
"It isn't convenient" may be an argument for application developers,
not for users; and it's not really a major argument, considering that
icons can be added using a template GtkBuilder file, or abstracted
into a separate function.
Users being unable to change a setting at the toolkit level is just a
fact of life; it's not like the toolkit is mandated to offer settings
for everything, and there's plenty of stuff that you cannot really
change in GTK already. Application developers can offer this kind of
customisation, as they are in the position to decide whether it works
best within the constraints of their own project.
Ciao,
Emmanuele.
