Thanks for reporting. 

The overall visual design of Adwaita is steering clear of bulky embossed elements. One has to balance visual noise vs indication of the view being resizable. 

The changing cursor and the active area being considerably larger than the visual representation of the widget seem like a good enough hints to avoid the use of excessive chrome.

See the difference between Attachment #283899 [details] and Attachment #283900 [details]. It is almost the same code.

With GTK+ 3.13, the application looks much more ugly, and requires modifications to fix the design. So for me it is clearly a regression.

Some developers don't have the time to fix all those regressions, so lots of GTK+ 3 applications will look ugly with the latest GTK+.

The GtkPaned:handle-size style property has a default value of 5. The fact that Adwaita doesn't take the handle-size into account is an API break, it is as the style property doesn't exist. But as the screenshots demonstrate, some apps rely on this property to have a good design. GNOME core apps can change this value to 0 if they want, but Adwaita should still be able to draw the handle as before, to not break apps design.

"ugly", "good" design" are pretty subjective terms and we shouldn't be arguing about them in bugzilla, it is not going to lead to any positive outcome.

"Api break" is certainly debatable, but since we are talking about style properties here, it is the theme api that you could claim is broken, not the application api.

Applications can't rely on style properties having their default value to 'look good'.

Now the containers' borders are bonded. At some places the line thickness is 1, at other places 2, 3 or even 4. In the side panel, the combobox with the 'test' directory is now bonded to the container border. And there are probably other details that should be fixed (and this is only in the main window in a specific mode, there are probably other windows or other UI elements that need to be fixed).

For the line thickness, it can be a bit tricky. For a certain container, I need to draw the border on each side except e.g. the left side. And I need to figure that out for all containers, in all possible configurations (depending if a widget is visible or not).

A solution in gtk is to change the default value of the style property to 0, and applications that still want to display the handle can change the property value (but Adwaita should be able to display the handle).

What you are describing here is the problem of collapsing borders, which is tricky and not currently handled by GTK+'s css implementation.

So it is especially important to still draw the GtkPaned handles. There are probably many affected applications, basically everywhere where a GtkPaned is used.

I think the default paned separator should keep being just one line, which is ok in most cases, on the other hand there are cases where a stronger visual separation is needed, so a thicker separator, I'd like to have a class to deal with those (better if set by the by the gtkpaned itself, reflecting a property).

There is already the GtkPaned:handle-size style property.

I think having a random width won't work nicelly

*** Bug 738850 has been marked as a duplicate of this bug. ***

I think this bug causes a more problematic regression: bug #738894.

has nothing to do with this bug

GtkPaned has now the wide-handle property, so I think this bug can be closed. Unfortunately there is no good solution for 3.14.