Why these settings are deprecated?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Why these settings are deprecated?

Tomasz Gąsior
I would like to ask question directly to main GTK developers. Why these
Xsettings are deprecated?

* gtk-button-images
* gtk-enable-mnemonics
* gtk-icon-sizes
* gtk-menu-bar-accel
* gtk-menu-bar-popup-delay
* gtk-menu-images
* gtk-menu-popdown-delay
* gtk-menu-popup-delay
* gtk-show-input-method-menu
* gtk-show-unicode-menu
* gtk-toolbar-icon-size
* gtk-toolbar-style
* gtk-visible-focus
* gtk-alternative-button-order

What is the reason of limiting GTK customization? Why only application
programmer should have ability to change these settings (as g-object
properties etc.) and why user shouldn't?

And second question. Why you are forcing removing icons from images and
menu items instead just disabling it by default in GNOME? Maintaining
code of GtkImageMenuItem or images in buttons is too time-consuming?
(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.)

Thanks for reply.

--
Tomasz Gąsior
https://tomaszgasior.pl
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Why these settings are deprecated?

Emmanuele Bassi
On 26 December 2017 at 20:06, Tomasz Gąsior <[hidden email]> 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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Why these settings are deprecated?

Tomasz Gąsior
Thanks for you reply. Now I unsterstand your decisions. But I have also
third question.

>> * 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.

These two menu items are not visible in my OS. I use both Arch Linux &
Manjaro. They are not visible in GTK3, but they are visible in GTK2.
Should I install additional software to get these menu items in GTK3?

---
Tomasz Gąsior
https://tomaszgasior.pl

W dniu 2017-12-26 21:39, Emmanuele Bassi napisał(a):

> On 26 December 2017 at 20:06, Tomasz Gąsior <[hidden email]>
> 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.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Why these settings are deprecated?

Daniel Boles
In reply to this post by Tomasz Gąsior
On 27 December 2017 at 12:00, <[hidden email]> wrote:
Date: Tue, 26 Dec 2017 21:06:30 +0100
From: Tomasz G?sior <[hidden email]>
To: [hidden email]
Subject: Why these settings are deprecated?
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=UTF-8; format=flowed

I would like to ask question directly to main GTK developers. Why these
Xsettings are deprecated?


Although in this case you got a very detailed answer, I'd like to suggest that it is usually better to check resources like the migration guides, "git blame", etc. to track down the rationale for decisions - instead of expecting that a developer will always see your post and have time or desire to directly explain so many things in precise detail.

Sure, that takes a bit longer as a user, but the alternative is that developers have to spend time constantly relitigating past decisions, which at its extreme would mean they'll have no time to develop. :P


_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Why these settings are deprecated?

Charles Lindsey
In reply to this post by Emmanuele Bassi
On Tue, 26 Dec 2017 20:39:41 -0000, Emmanuele Bassi <[hidden email]>  
wrote:

> On 26 December 2017 at 20:06, Tomasz Gąsior <[hidden email]>  
> 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.

Nevertheless most Unix systems are likely to remain using X11 because too  
much existing software expects it.

If there is some useful feature that only works on some operating systems  
and the feature is deprecated & removed for that reason, then we shall all  
be forced to use only features that work  on he lowest common denominator  
of operating systems (no names, no pack drill, but some of us choose  
operating systems that lie above any such lowest common denominator for  
the good reason that they are better operating systems, and we do not like  
being held back by enforced compliance with "bad" oftware.
>
> 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.

If an equivalent Gtksetting exists, then that is fine.

--
Charles H. Lindsey ---------At my New Home, still doing my own  
thing-----------
Tel: +44 161 488 1845                         Web:  
http://www.cs.man.ac.uk/~chl
Email: [hidden email]      Snail: 40 SK8 5BF, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4  
AB A5
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Why these settings are deprecated?

Matthias Clasen-2
In reply to this post by Tomasz Gąsior
On Tue, Dec 26, 2017 at 3:06 PM, Tomasz Gąsior <[hidden email]> wrote:
I would like to ask question directly to main GTK developers. Why these Xsettings are deprecated?

* gtk-button-images
* gtk-enable-mnemonics
* gtk-icon-sizes
* gtk-menu-bar-accel
* gtk-menu-bar-popup-delay
* gtk-menu-images
* gtk-menu-popdown-delay
* gtk-menu-popup-delay
* gtk-show-input-method-menu
* gtk-show-unicode-menu
* gtk-toolbar-icon-size
* gtk-toolbar-style
* gtk-visible-focus
* gtk-alternative-button-order

What is the reason of limiting GTK customization? Why only application programmer should have ability to change these settings (as g-object properties etc.) and why user shouldn't?

And second question. Why you are forcing removing icons from images and menu items instead just disabling it by default in GNOME? Maintaining code of GtkImageMenuItem or images in buttons is too time-consuming?
(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.)


Emmanuele already gave a fairly detailed run-down of these one-by-one, but here is my general response:
 
In some cases, these settings were there to support transitions for changes in UI paradigms (such as moving away from pervasive icons in buttons and menus). In other cases, they have been superseded
by platform-wide configuration (for example, we want to let users configure input methods for the whole session, not per-entry). Also, some of the features controlled by these settings have changed in a way
that the settings don't make much sense anymore (e.g focus and mnemonic indication is a lot more dynamic now than it was in gtk2 days, and icon sizes are going to be set via css in the future).

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list