Change shape of GtkScale with CSS for GTK < 3.20 and > 3.20

[Cyril Richard]

Hi,

I am trying to change the shape of a GTKScale. To do it I use a CSS sheet.
The following CSS code gives something's good, like in attachment.

.midtone-scale {
background-image: -gtk-gradient(linear, left top, right top,
from(black),
to(shade(white, 0.95)));
padding: 5px;
}

.midtone-scale trough,
.midtone-scale highlight,
.midtone-scale trough:disabled {
border-image: none;
border-style: none;
border-width: 0px;
border-radius: 0px;
background-color: transparent;
}

.midtone-scale slider,
.midtone-scale slider:hover,
.midtone-scale slider:disabled {
border-radius: 0px;
border-style: none;
background-color: transparent;
box-shadow: none;
min-width: 21px;
background-color: transparent;
background-repeat: no-repeat;
background-position: top;
background-image: url("pixmaps/scale-slider-horz.png");
}

But, for GTK version less than 3.20 it does not work. Please, could you
help me to write a CSS sheet working for both ?
Or maybe there's a better way to change the shape like I want ?
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: [PATCH] file chooser: Restore consistent click behavior (for gtk 3.20)

[Jean Delvare]

Hi Matthias,

On Thu, 05 Oct 2017 13:02:34 -0400, Matthias Clasen wrote:
> 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.

Not really. You still need to click twice in most cases, and I doubt
most people do two slow clicks just for the fun of wasting time. So in
practice it's still double-click, with inconsistency sprinkled.

Do you have any pointer to a bug report or mailing list discussion
where someone asked for the current behavior? As it stands, I am under
the impression that the only person who likes it is you :-(

> There is no winning here,

Did you not read anything I wrote above? The winning is clear and
obvious, to everybody who expressed their views in this thread, except
you.

>and I will not support any simple reversal
> unless it comes along with a person who is willing to maintain the
> filechooser long-term,

I would understand the logic if I was adding new code, or changing the
behavior to something uncommon or risky. This is not the case, I'm
removing code, and the behavior is the same as it used to be. I can't
see how it would cause any extra work to the maintainer.

If I were in a playful state of mind, I'd just accept the deal and
agree to maintain the code. After all, the last behavior change was
done by you, and your way to maintain the code is apparently to simply
ignore the massive complaints that was raised by this change. Seems
easy, I'm sure I can do it too ;-)

>and field all the complaints from the 'its still
> not the same as nautilus' crowd.

I have no idea why you mention Nautilus here. The current
implementation is not the same as Nautilus either, so this is not a
valid argument.

> IMO the way forward for the file chooser in GTK+ is
> GtkFileChooserNative, making this entire mess somebody elses problem.

Could be. But I don't see such a big change happening in GTK 3 anymore,
so that doesn't help.

Please be reasonable, admit that commit fb0a13b7f070 was not a good
idea, and accept to revert it.

Thanks,
-- 
Jean Delvare
SUSE L3 Support
___
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)

[Daniel Boles]

>
> From: "Charles Lindsey" <c...@clerew.man.ac.uk>
> To: gtk-devel-list@gnome.org
> Subject: Re: [PATCH] file chooser: Restore consistent click behavior
> (for gtk3.20)


> It seems to me that those who are developing GTK are answerable to no-one,
> and it they continue to behave in this way, we shall simply all be forced
> to switch to QT. It is ridiculous that they are pressing ahead with GTK4
> at a time when several exceeding important applications had not even
> switched to GTK3 (and I am beginning to see why). The file changer in
> these applications will remain as it is, so that everyone will find
> different windows which look the same behaving entirely differently.



It is a non sequitur to say that developing a new major version should not
be allowed because some users are still on the previous stable version.

It is equally irrelevant to completely omit the fact that the current
stable version is now LTS and seeing more and more applications, DEs, etc
moving across to it.

Having a separate bleeding-edge development branch is a precondition for
having a really stable one, and now that exists. So, that problem was
solved. Yet apparently, somehow there are those who want to construe the
solution as a problem in itself...

And as always, just complaining about the development means very little
when so few of the complainers ever contribute any resources to improve the
state of things. If you want to change the focus of "those who are
developing GTK", become one.


That's all kinda separate from the original topic, which I still think
should just be reverted until it's done properly, but anyway.
___
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)

[Tomasz Gąsior]

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)

[Matthias Clasen]

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.
___
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)

[Charles Lindsey]

On Thu, 05 Oct 2017 18:02:34 +0100, Matthias Clasen   
wrote:



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.


The fact that the "Look and Feel" of the filechooser agrees with that of  
Nautilus is a Feature, not a Bug. It is utterly nonsensical to even thing  
of changing it, and if Ubuntu and Suse are reversing the change on their  
platforms, then I applaud that.


It seems to me that those who are developing GTK are answerable to no-one,  
and it they continue to behave in this way, we shall simply all be forced  
to switch to QT. It is ridiculous that they are pressing ahead with GTK4  
at a time when several exceeding important applications had not even  
switched to GTK3 (and I am beginning to see why). The file changer in  
these applications will remain as it is, so that everyone will find  
different windows which look the same behaving entirely differently.


--
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: c...@clerew.man.ac.uk  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
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)

[Tomasz Gąsior]

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

Re: [PATCH] file chooser: Restore consistent click behavior (for gtk 3.20)

[Daniel Boles]

I apologise if there is, if I just blocked most of that thread out of my
mind... but is there really a significant number of users out there who had
these complaints about double-click and genuinely think what we have now is
an unambiguous improvement? rather than just an apparent, superficial fix
in one scenario (single-clicking on the pre-selected top item) compensated
by regression everywhere else.
___
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)

[Matthias Clasen]

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.
___
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)

[Daniel Boles]

On 5 October 2017 at 10:46, Jean Delvare  wrote:

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

Right. It doesn't help to enable single-clicking inconsistently, only if
the item is already selected, thus being confusing and irritating when you
open something you didn't want to, or find you can't single-click to open
anything except the 1st item in the list. I find it perplexing how this was
considered to improve anything.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

gtk+-3.20 DnD x11 issues

[Edscott Wilson]

Hi all,

  A good deal of changes went into gdkdnd-x11.c from gtk+-3.18 to
gtk+-3.20. And now my application which works fine with gtk+-3.18 crashes
when a dnd operation starts. I tried to enable deprecated code which works
fine when building with gtk+-2.24, but it crashes just the same. I've spent
quite a while trying to figure out what the problem is, whether is is a bug
in gtk+-3.20 or whatever.

  Has anyone else had issues with DnD with gtk+-3.20? If so, how did you
solve the issue?

TIA

-- 

Dr. Edscott Wilson Garcia
Reservoir Engineering
Mexican Petroleum Institute
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Issue with css and gtk+-3.20

[Jean Bréfort]

Hi,

The code we use in gnumeric for theming does not work anymore ith gtk+-
3.20, more specifically, if I use css code such as:

GnmItemCursor {
 color="black";
 background-color="white"; }

GnmItemCursor.ant {
 color="blue";
 background-color="red"; }

when retrieving the colors with the context for a GnmItemCursor with no class, 
I get the appropriate colors, but using:

gtk_style_context_save (context);
gtk_style_context_add_class (context, "ant");
gtk_style_context_set_state (context, GTK_STATE_FLAG_NORMAL);
gtk_style_context_get (context, gtk_style_context_get_state(context),
       "color", ,
       "background-color", ,
       NULL);
gtk_style_context_restore(context);


fore is still black, but back is changed to (r,g,b,a) = (0,0,0,0). Both colors 
are not what is expected, especially the background which is not even inherited 
from the classless context.

if instead the css has:

.ant {
 color="blue";
 background-color="red"; }

things work, but the style should be restricted to GnmItemCursor, not 
everything having an "ant" class. What are we doing wrong? Things used to work 
with previous Gtk+ versions.

Regards,
Jean


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

GTK+ 3.20

[Matthias Clasen]

GTK+ 3.20.0 is now available for download at:

 http://download.gnome.org/sources/gtk+/3.20/

sha256 sum:

1c3d3a4a6e959ec8636ccb074bcdb8fa25c81ec56fbc70de6a3f5ef83ba6d803
gtk+-3.20.0.tar.xz


What is GTK+


GTK+ is a multi-platform toolkit for creating graphical user interfaces.
Offering a comprehensive set of widgets as well as facilities for creating
your own widgets, GTK+ is suitable for projects ranging from small one-off
tools to complete application suites.

GTK+ has been designed from the ground up to support a range of languages,
not only C/C++. Using GTK+ from languages such as Python, Vala and JavaScript
(especially in combination with gobject-introspection and the Glade GUI builder)
provides an effective method of rapid application development.

GTK+ is free software and part of the GNU Project. However, the licensing terms
for GTK+, the GNU LGPL, allow it to be used by all developers, including those
developing proprietary software, without any license fees or royalties.

Since its origins as the toolkit for the GNU Image Manipulation Program (GIMP),
GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation
of the GNOME desktop.


What's new in 3.20
==

Major new features include:

* The CSS machinery now uses element names for widgets and their components

* CSS margins, borders, padding and min-width and min-height are now much more
  consistently supported

* CSS features that have been added: radial gradients, recoloring symbolic
  icons, image(), calc(), rem

* Help overlays to document keyboard shortcuts and gestures

* GTK+ now reads .XCompose files

* GTK+ can use native file choosers on Windows

* A HighContrastInverse theme has been added

* The Wayland backend has full support for DND, kinetic scrolling, startup
  notification, primary selection, presenting windows, bell.

* Deprecations and removals: Style properties, testing infrastructure,
  geometry support in window sizing, GdkDeviceManager,
  gtk_text_iter_begins_tag, gdk_display_get_screen


For more details and lists of fixed bugs, see the NEWS file that is
included in the tarball, or see:

 http://git.gnome.org/browse/gtk+/plain/NEWS?id=3.20.0

For concerns about porting from older GTK+ releases, see the README file
that is included in the tarball, or see:

http://git.gnome.org/browse/gtk+/plain/README.in?id=3.20.0


Where to get more information about GTK+


Information about GTK+ including links to documentation can be found at:

 http://www.gtk.org/

An installation guide for GTK+ is found at:

 http://library.gnome.org/devel/gtk3/stable/gtk-building.html

Common questions:

 http://library.gnome.org/devel/gtk3/stable/gtk-question-index.html


Contributing


GTK+ is a large project and relies on voluntary contributions. We are actively
searching for new contributors in various areas and invite everyone to help
project development. If you are willing to participate, please subscribe to
the project mailing lists to offer your help and read over our list of vacant
project tasks:

http://live.gnome.org/GTK+/Roadmap


Thanks to the many people who contributed to this release in the form of bug
reports, patches and translations.


March 21, 2016
Matthias Clasen
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GTK+ 3.20

[Matthias Clasen]

GTK+ 3.20.0 is now available for download at:

 http://download.gnome.org/sources/gtk+/3.20/

sha256 sum:

1c3d3a4a6e959ec8636ccb074bcdb8fa25c81ec56fbc70de6a3f5ef83ba6d803
gtk+-3.20.0.tar.xz


What is GTK+


GTK+ is a multi-platform toolkit for creating graphical user interfaces.
Offering a comprehensive set of widgets as well as facilities for creating
your own widgets, GTK+ is suitable for projects ranging from small one-off
tools to complete application suites.

GTK+ has been designed from the ground up to support a range of languages,
not only C/C++. Using GTK+ from languages such as Python, Vala and JavaScript
(especially in combination with gobject-introspection and the Glade GUI builder)
provides an effective method of rapid application development.

GTK+ is free software and part of the GNU Project. However, the licensing terms
for GTK+, the GNU LGPL, allow it to be used by all developers, including those
developing proprietary software, without any license fees or royalties.

Since its origins as the toolkit for the GNU Image Manipulation Program (GIMP),
GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation
of the GNOME desktop.


What's new in 3.20
==

Major new features include:

* The CSS machinery now uses element names for widgets and their components

* CSS margins, borders, padding and min-width and min-height are now much more
  consistently supported

* CSS features that have been added: radial gradients, recoloring symbolic
  icons, image(), calc(), rem

* Help overlays to document keyboard shortcuts and gestures

* GTK+ now reads .XCompose files

* GTK+ can use native file choosers on Windows

* A HighContrastInverse theme has been added

* The Wayland backend has full support for DND, kinetic scrolling, startup
  notification, primary selection, presenting windows, bell.

* Deprecations and removals: Style properties, testing infrastructure,
  geometry support in window sizing, GdkDeviceManager,
  gtk_text_iter_begins_tag, gdk_display_get_screen


For more details and lists of fixed bugs, see the NEWS file that is
included in the tarball, or see:

 http://git.gnome.org/browse/gtk+/plain/NEWS?id=3.20.0

For concerns about porting from older GTK+ releases, see the README file
that is included in the tarball, or see:

http://git.gnome.org/browse/gtk+/plain/README.in?id=3.20.0


Where to get more information about GTK+


Information about GTK+ including links to documentation can be found at:

 http://www.gtk.org/

An installation guide for GTK+ is found at:

 http://library.gnome.org/devel/gtk3/stable/gtk-building.html

Common questions:

 http://library.gnome.org/devel/gtk3/stable/gtk-question-index.html


Contributing


GTK+ is a large project and relies on voluntary contributions. We are actively
searching for new contributors in various areas and invite everyone to help
project development. If you are willing to participate, please subscribe to
the project mailing lists to offer your help and read over our list of vacant
project tasks:

http://live.gnome.org/GTK+/Roadmap


Thanks to the many people who contributed to this release in the form of bug
reports, patches and translations.


March 21, 2016
Matthias Clasen
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list