[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: Why these settings are deprecated?
From:       Tomasz_Gąsior <mail () tomaszgasior ! kao ! pl>
Date:       2017-12-26 22:11:06
Message-ID: f733a5d8e94ab1af35037835c7cbf2fa () tomaszgasior ! kao ! pl
[Download RAW message or body]

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 <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.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

[prev in list] [next in list] [prev in thread] [next in thread]