Question about popovers
I want to ask question about GtkPopover. GTK3 documentation says "GtkPopover is a bubble-like context window [...]" but popover is not a real window but it is a floating widget inside other window. From perspective of window managers and compositors popovers don't exist. Appearance of popover is similar to window but it is not window — this causes inconsistences in animations. Window animation is defined by WM and compositor, popover animation — in GTK theme. There are also problems with big popovers in small windows. See example: Mousepad GTK3, "Find and replace" dialog. First: http://en.zimagez.com/zimage/przechwycenieobrazuekranu2018-01-2915-15-00.php and then: http://en.zimagez.com/zimage/przechwycenieobrazuekranu2018-01-2915-15-22.php Why did you — my question is directed to GNOME devs — chosen this way of implementation of this feature? Why popovers are not normal windows (with disabled server side decoration and with client side shadow)? I don't want to criticize your decision, probably you are more experienced, just I want to understand. Firefox uses in some parts of its UI widgets with appearance similar to GTK popovers. Fx devs implemented it as real window. See http://en.zimagez.com/zimage/przechwycenieobrazuekranu2018-01-2915-27-18.php I have also second question. Why GNOME uses popovers instead normal menus for menus purposes? Thanks for reply. -- Tomasz Gąsior https://tomaszgasior.pl ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Why these settings are deprecated?
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 gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: First deprecate APIs and then remove them in the next major version
Instead of forking, you can create your own patches to vanilla GTK3. :) I like GTK-based desktops but some GNOME devs decisions are not good to me, so I created my own patches for GTK3. You can do something similar. See https://github.com/TomaszGasior/gtk3-mushrooms --- Tomasz Gąsior https://tomaszgasior.pl W dniu 2017-12-23 14:47, Salvatore De Paolis napisał(a): On Wed, 13 Dec 2017 15:08:46 -0800 Christian Hergert <christ...@hergert.me> wrote: Ardour could never move to Gtk3 because a number of VST plugins use Gtk2 and you cannot mix both into the same process space. DAW authors will often cite the necessity for plugins to be in process to allow for a large number of tracks/plugins due to context switching. (This is a contributing factor to why many DAWs write their own UI toolkits). As for GIMP, I think the lesson I take away is that we need to recruit people to go do the ports for important projects rather than expect them to track us. Red Hat has shown that this strategy works in both Firefox and LibreOffice (which are arguably the two hardest applications to port). http://libremusicproduction.com/news/20171221-lsp-plugins-version-110-released-farewall-gtk I wonder why GTK+ has not been forked yet. S. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Build GTK3 without ATK
Hi. It is possible to build GTK3 without Accessibility Toolkit dependency? How can I do it? -- Tomasz Gąsior https://tomaszgasior.pl ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] file chooser: Restore consistent click behavior (for gtk 3.20)
W dniu 2017-10-06 16:41, Matthias Clasen napisał(a):
On Fri, 2017-10-06 at 09:52 +0200, Tomasz Gąsior wrote:
W dniu 2017-10-05 19:02, Matthias Clasen napisał(a):
> On Thu, 2017-10-05 at 11:46 +0200, Jean Delvare wrote:
> > The change in single-click vs double-click in the GTK 3 file
> > chooser
> > from commit fb0a13b7f070 ("file chooser: Allow activating without
> > double-click") causes more problems than it resolves. There have
> > been
> > a lot of complaints about it:
> >
> > * The first item in a directory is selected by default, so a
> > double-click on it misbehaves. Specifically, if that item is a
> > directory, the first click enters the directory, and the second
> > click will apply to whatever is listed first in that directory
> > (which is also selected by default, so effect is immediate.)
> > This
> > is unexpected and quite confusing.
> > * The ability to activate a selected file or directory with a
> > single
> > click interacts badly with selection of multiple files. If you
> > start the selection with a file which was already selected,
> > then
> > that file is immediately opened, before you have a chance to
> > complete your selection.
> > * This new behavior is inconsistent with Nautilus, GTK 2
> > applications
> > (which are sill many) or basically any other existing GUI
> > toolkit.
> > Having incompatible behavior between applications is confusing
> > for
> > the user.
> > * While a number of people are advocating the ban of double-click
> > and
> > the use of single-click for everything to make computers easier
> > to
> > use by non-tech-savvy people and people with limited abilities,
> > this change does not even achieve that.
> >
> > If the problem that this change was supposed to address is that
> > double-clicking fast is a challenge for some people, this issue
> > should be addressed at the desktop environment level, by
> > accessibility tools and/or mouse configuration. The GTK 3 file
> > chooser is way too high level and specialized to handle this.
> >
> > So the best thing to do is to revert this change. Ubuntu has
> > already
> > done so, and SUSE is in the process of doing the same.
> >
> > https://bugzilla.gnome.org/show_bug.cgi?id=758065
> >
>
> You are just bringing back the complaints about double-click.
>
> There is no winning here, and I will not support any simple
> reversal
> unless it comes along with a person who is willing to maintain the
> filechooser long-term, and field all the complaints from the 'its
> still
> not the same as nautilus' crowd.
>
> IMO the way forward for the file chooser in GTK+ is
> GtkFileChooserNative, making this entire mess somebody elses
> problem.
Can't you just add ability to change single- or double-click behavior
in
dconf?
For example you can create setting
"/org/gtk/settings/file-chooser/click-mode" with two possible values
"double" or "single".
If "click-mode" is set to "double", do nothing because this is
default
behavior of GtkTreeView. If "click-mode" is set to "single", set
"activate-on-single-click" property of GtkTreeView class to "true".
It's all. It seems to me it would be simple to maintain in the
future.
And this way is more consistent — you always have to double-click or
single-click. Also you don't have to write a lot of code — all it's
needed is in GtkTreeView now.
Adding an option is not a solution at all, thats just a way to avoid
finding a solution.
Putting ability to control behavior of this thing to the user is the
best and the simplest solution that we can find.
---
Tomasz Gąsior
https://tomaszgasior.pl
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] file chooser: Restore consistent click behavior (for gtk 3.20)
On Thu, 2017-10-05 at 11:46 +0200, Jean Delvare wrote:
The change in single-click vs double-click in the GTK 3 file chooser
from commit fb0a13b7f070 ("file chooser: Allow activating without
double-click") causes more problems than it resolves. There have been
a lot of complaints about it:
* The first item in a directory is selected by default, so a
double-click on it misbehaves. Specifically, if that item is a
directory, the first click enters the directory, and the second
click will apply to whatever is listed first in that directory
(which is also selected by default, so effect is immediate.) This
is unexpected and quite confusing.
* The ability to activate a selected file or directory with a single
click interacts badly with selection of multiple files. If you
start the selection with a file which was already selected, then
that file is immediately opened, before you have a chance to
complete your selection.
* This new behavior is inconsistent with Nautilus, GTK 2 applications
(which are sill many) or basically any other existing GUI toolkit.
Having incompatible behavior between applications is confusing for
the user.
* While a number of people are advocating the ban of double-click and
the use of single-click for everything to make computers easier to
use by non-tech-savvy people and people with limited abilities,
this change does not even achieve that.
If the problem that this change was supposed to address is that
double-clicking fast is a challenge for some people, this issue
should be addressed at the desktop environment level, by
accessibility tools and/or mouse configuration. The GTK 3 file
chooser is way too high level and specialized to handle this.
So the best thing to do is to revert this change. Ubuntu has already
done so, and SUSE is in the process of doing the same.
https://bugzilla.gnome.org/show_bug.cgi?id=758065
You are just bringing back the complaints about double-click.
There is no winning here, and I will not support any simple reversal
unless it comes along with a person who is willing to maintain the
filechooser long-term, and field all the complaints from the 'its still
not the same as nautilus' crowd.
IMO the way forward for the file chooser in GTK+ is
GtkFileChooserNative, making this entire mess somebody elses problem.
Can't you just add ability to change single- or double-click behavior in
dconf?
For example you can create setting
"/org/gtk/settings/file-chooser/click-mode" with two possible values
"double" or "single".
If "click-mode" is set to "double", do nothing because this is default
behavior of GtkTreeView. If "click-mode" is set to "single", set
"activate-on-single-click" property of GtkTreeView class to "true".
It's all. It seems to me it would be simple to maintain in the future.
And this way is more consistent — you always have to double-click or
single-click. Also you don't have to write a lot of code — all it's
needed is in GtkTreeView now.
---
Tomasz Gąsior
https://tomaszgasior.pl
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk-alternative-button-order — will be deprecated?
Hi! I'm newbie here so please be understanding for me. ;) I'm user of GTK-based desktop. GTK has Xsettings option called "gtk-alternative-button-order". It should be used to reverse order of buttons in dialogs. Is this option deprecated or it will be deprecated? Currently GTK3 and GTK4 documentations says that not, but I see in GTK source code that this option does not work anymore. I have not wide knowledge about C (I created only small patches for GTK called gtk3-mushrooms for my own usage) but it seems to me that this option is kept in GTK code by mistake. Only GtkAssistant window uses "gtk-alternative-button-order" option. Code in GtkDialog is removed from GTK4 and deprecated in GTK3. Regardless of current code state I want to ask GTK developers to keep this option working in GTK code base. I'm understand that GTK3 developers move customization options from users to developers (ex. toolbar appearance in GTK3 is changeable only from code, not by Xsettings now) but "gtk-alternative-button-order" should be kept in GTK. Windows and KDE uses reversed (comparing to GTK) order of buttons in dialogs so this option can be very useful for users of both GTK-based desktop and KDE or MS Windows. It can be also useful for better integration of GTK running on MS Windows. -- Tomasz Gąsior https://tomaszgasior.pl ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
