This is serious UX problem. If we’re fusing the empty space with the titlebar visually, the empty space should act like a titlebar in every regard (except pulling up the Kwin window management menu). This means that when you double click empty space on the toolbar it should maximize the window, etc. I like the idea of fusing the two but function MUST follow form here.
Dolphin isn’t even draggable by empty space in the toolbar because this space only looks empty but is actually occupied by the address bar which intercepts all drag events.
For all applications, it’s difficult to determine where you need to double click in order to maximize since the titlebar is so small relative to the toolbar and the two are fused. This makes the most basic feature of window management - double click to max - unreliable.
Until breeze is patched to fully support window management actions in the toolbar, the titlebar and toolbar should be visually separated by default. After/if breeze is patched, separators should remain in place for apps that don’t use breeze (since with those, there are no assurances about the behavior or appearance of the area below the titlebar)
As a side note, I would also recommend implementing dragging from buttons like Kvantum and GTK already do, in order to increase the dragging area and reduce the need for precise mousework.
cc @ngraham. The toolbar/menu is visually merged with the titlebar yet it doesn’t really act like one (on dolphin you can’t even drag from the apparently empty space because it’s occupied by an invisible address strip).
So I’d propose the following:
draw a frame around the address bar in dolphin
implement double click to maximize for empty space in the menubar and toolbar, given that there is no separation between these elements and titlebar.
implement dragging from buttons to maximize drag space (kvantum theme does this optionally). It really makes it so much easier to drag windows.
draw separators between titlebar and chrome for non-QT apps (maybe make it configurable via window rules for apps like firefox which do support wm operations from the chrome).
This stuff makes basic windows management is less predictable and facile on KDE than on Gnome, despite the fact that the former has system decorations.
This part of your suggestion is a known bug with a known solution. As you suggested, the location bar needs to be styled in a way that makes clear that it acts differently when clicked than empty areas. We have mockups for this, but nobody has implemented them yet.
This is a bit of tangent, but I don’t like the merger of headerbar and title bar because neither functions as the other. Buttons on the Titlebar don’t behave nor look the same as the headerbar, right-clicking on the titlebar is different from the headerbar, plus all the issues you’ve mentioned.
Even worse is even if everything was somehow fixed and there was 100% consistency between the two, not every app is going to have a headerbar. See, when the titlebar was a different color, it was 100% identical in every app (that didn’t use gtk), it was consistent in size, elements, and feature. It worked predictably 100% of the time. A headerbar is neither of those things, not every app has the same buttons, nor size, nor right click behavior, some have a menu bar, etc… By visually merging the two, you have a situation where a small part of it is consistent across almost all apps, and a bigger part that isn’t.