On 26 December 2017 at 20:06, Tomasz Gąsior <m...@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. -- https://www.bassi.io [@] ebassi [@gmail.com] _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
