Created attachment 184109 [details] Screenshot of the issue SUMMARY With the combined update of KDE Frameworks and the new dolphin 25.08, the URL bar got a new design. When the URL bar is outside of the toolbar, which in itself is a good setting, it became impossible to tell where the URL bar ends and content starts, vertically. This is especially annoying if you want to click to select or click and drag to open a selection, and start up to far up, so you miscick into the URL bar STEPS TO REPRODUCE 1. Update kf6 2. Update dolphin 3. Have the location bar outside of the toolbar OBSERVED RESULT UX regression: no separation between URL bar and content, while these things are two entirely separate things that should be treated as such EXPECTED RESULT A visual separation between the two, as we had in the past. Operating System: Fedora Linux 42 KDE Plasma Version: 6.4.4 KDE Frameworks Version: 6.17.0 Qt Version: 6.9.1 Kernel Version: 6.15.9-201.fc42.x86_64 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i5-8265U CPU @ 1.60GHz Memory: 16 GiB of RAM (15.4 GiB usable) Graphics Processor: Intel® UHD Graphics 620 ADDITIONAL INFORMATION This was tested with breeze as the official style, probably the same applies to others, though
Created attachment 184110 [details] Proposed alternative solution as also proposed in the VDG channel This would be a proposal that makes it easy to distinguish whilst still being consistent with other bars. This should (probably) also work in styles that aren't breeze, as otherwise toolbars would look odd in these. And while this in general adds one more horizontal line, this is imho acceptable, since it separates content which is neither toolbar nor folder content, and as such it is separated like other things also would be.
Also suggested testing when this is fixed: - Move the location bar outside of the toolbar to get the default setup with just this placement of the bar - See how it looks both in click and edit mode (CTRL+L by default) - Also toggle find (CTRL+F by default) and filter (CTRL+i by default) and see how it looks with these Preferably it would work with all of these. I can happily provide feedback both here or in the VDG channel if requested.
I kind of think the bar would need to stay content-coloured (i.e. white for Breeze Light) because the whole bar is clickable. We also use the content colour for the location bar when it is in the toolbar. I agree though that some separation makes sense as these components are different and react differently to clicks. >This would be a proposal that makes it easy to distinguish whilst still being consistent with other bars. Other bars also have their line edits content-coloured. The location bar breadcrumb mode might not technically be a line edit but we changed it to seem like one so it counts I think.
(In reply to Felix Ernst from comment #3) > >This would be a proposal that makes it easy to distinguish whilst still being consistent with other bars. > > Other bars also have their line edits content-coloured. The location bar > breadcrumb mode might not technically be a line edit but we changed it to > seem like one so it counts I think. The controls have the background which corresponds to said control, which means a text input has obviously a text input colour. However, the container that holds these controls is, as it's pretty clear in the search box, the same as toolbar. This is also what I do propose, as you can see in the screenshot where the location bar is editable, it looks like a text input box on a toolbar background, consisent with what the search and filter bar do. So the only question is the clickable location bar, and imho content background would be wrong there for multiple reasons, mostly because iti s not the actual content that dolphin shows, but also because that would make it inconsistent if you switch to the editable location bar, and either the container suddenly becomes toolbar-coloured again, or it has the same design as the clickable location bar you propose and thus behave different than the filter- or search bar.
>So the only question is the clickable location bar, and imho >content background would be wrong there for multiple reasons So you also think it is wrong for the default position of the location bar on the toolbar?
(In reply to Felix Ernst from comment #5) > >So the only question is the clickable location bar, and imho > >content background would be wrong there for multiple reasons > > So you also think it is wrong for the default position of the location bar > on the toolbar? I never had that enabled personally, but I now just did, and no, to me it looks correct there. In the clickable mode, it has the backdrop colour of a toolbar, which is fine, if one assumes that the controls are like buttons. In editable mode, it becomes a text input field, which has the same colour as all text input fields (white, for breeze light), which is also fine. As said, the problem when it lives outside of the toolbar is imho not the backdrop of the text input control in editable mode, but rather the container that holds said control, which is currently the same backdrop as folder content. And it isn't folder content in my opinion, and if it was, it would still be impossible to distinguish where one starts and the other ends, which is not good as these behave different (on click, on drag, on drop, on ...) tl;dr: the one in the toolbar is imho fine, the one outside of the toolbar isn't. To fis the latter, I propose giving it a toolbar-coloured backdrop like find and filter also have. If you prefer a thin line: imho not great UX because inconsistent with the rest and hard to spot for people with not-so-great eyesight and with various styles and colours, but I agree that would be an improvement over the current state.
Created attachment 184437 [details] bottom border added to the location bar I like the proposed solution in attachment 184110 [details]. Even if a background color isn’t set, adding a 1px bottom border would still be helpful to identify the location bar.
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/1031
Git commit 2a0fa83b72631b21d2e8d731feb0eff576af0f77 by Akseli Lahtinen. Committed on 19/09/2025 at 08:22. Pushed by akselmo into branch 'master'. DolphinTabPage: Show separator when navigator is outside of menubar When navigator is outside of menubar, we should show separator under it to make it visually easier to understand it's a clickable area. This adds a small separator, that will be disabled when the navigator is moved back to menubar. M +3 -3 src/dolphinmainwindow.cpp M +13 -0 src/dolphintabpage.cpp M +2 -0 src/dolphintabpage.h https://invent.kde.org/system/dolphin/-/commit/2a0fa83b72631b21d2e8d731feb0eff576af0f77