In T11663#213940, @squeakypancakes wrote:

You have a lot more room to work with if you want to put the full path into the split title.

Well compared to the remaining UI elements that _can_ be interacted with it does look out of place or odd at least. Yes I agree that overall line edits are used for such things and it'd break up consistency, but it doesn't look "right" as it is right now. I'll try to work some thoughts into image later. 

Is it necesseray for the "Search here" input field to have this not so pretty border and padding around it? Why not fuse it with the entire cell it's located in?

In T11663#213094, @manueljlin wrote:

"Keep a single URL Navigator in the toolbar, but change it dynamically to show the path for the active split view" is probably the best option

The issue with that approach is that you can never be 100% sure you're in the right directory on your inactive split view. A minor issue, yes, but an issue nonetheless.

In T12192#212937, @ndavis wrote:

What if we just drop the A-Z tab or put it in the sidebar with the rest of the categories?

Picking up the discussions taken place on Reddit, on T12308 and on T11662, I'd like to show a revised mockup and would love some input on it:

I think moving over to the other discussion would be more beneficial.

Like so?

First of all, thanks for linking this @manueljlin
How would the design look with a split view?

The Aurorae engine is a more popular and easy but limited way to make custom window decorations. I don't think it would be able to do what you're talking about.

I didn't mean to ask for a solution using Aurorae. I'm currently working on a decoration and QStyle set which is based on a fork of Breeze, so it's good to know I can pass information from one to the other. Helps me out a ton for some fun ideas.
Thanks!

I haven't dug too deep into KFrameworks stuff, but is the decoration able to detect if the QStyle has to render a toolbar? I'm asking because on macOS for example the gradient is always the same, just more or less stretched depending on the size of the titlebar. This creates a very consistent look over all. This could also be used to draw or hide a titlebar seperator depending on wether or not a toolbar will be drawn in the window.

Oh okay, so if I were to make a theme and would like to create a gradient that extends all the way from the top of the window to the bottom of the toolbar I'd essentially have to create a decoration and a qstyle and use the two to give the impression of a continuus gradient?

One question that came up in my mind: how would this new "combine area for titlebar and toolbar" affect themes that draw gradients on the titlebar?

You should draw a widget using QStyle in order to make it look reasonably with other styles

Well yes, I was merely saying the margins and paddings could be adjusted without breaking a sweat or visual compatibility.

So either we change it everywhere

Consistency on the desktop is a big goal of KDE and therefore I agree, if changes like these make it into Dolphin, other parts where similar elements appear should be re-evaluated as well.

So it either should be outside frame, like the checkmark button

It already is though. The navbar in my mockup is what is known as an "input group", which is a regular UI element that can consist of an arbitrary amount of buttons, labels and input fields. A prominent example of this for web UI would be Bootstrap: https://getbootstrap.com/docs/4.1/components/input-group/
Generally such groups are used to visually signal that the individual items interact with each other within that group. I hope my crude mockup makes clear what I try to explain:

So more like this then?

In that case I prefer "no lines but arrows". It looks cleaner and less crowded:

Is it not possible to query the device the box has to be rendered on whether it uses touch or pointer input? If it is possible, the SpinBox could render in two different ways, one of which is the current design and the other being a touch optimized render.
Mobile users are very much used to in input field with a Minus control button on the left and a Plus control button on the right to modify the value of the input by a pre-set step. However this design is not very logical for pointer input devices such as regular desktop PCs, or laptops.

it sticks out as visually inconsistent with drop down menu buttons.

I agree.

Windows may do it that way, but I don't find it intuitive have the order of UI elements changed.

Absolute agreement on that part.

Actually, it's the blank area to the right of the text and the arrows that triggers the edit mode. When you click the text, Dolphin switches to the directory in the label.

You're right, my mistake.

In T11662#209294, @mglb wrote:

That's why it should not look exactly the same as something other - it is different control. With big advantages as a concept, limited to this use case.

Well yes, maybe I didn't make myself clear enough; while it has to look different to signal that it's a different control element, it still should look same-ish to existing control elements. I'd even argue that no matter how you'd style the navigator, users would probably understand that it's a breadcrumb thing after being subject to those in a lot of web applications but still, gotta get it _right_ to make it look like it "belongs".

The biggest problem that I see with the breadcrumbs receiving a new coat of paint with pointy or slanted lines would be the fact that it's a UI element that doesn't exist in vanilla KDE anywhere else in that form. At least I can't think of where it shows up, but please correct me if that is wrong. Taking Gestalt theory into consideration, this might be bad UX as it exposes users to new elements that are unique to that one location.

Would that impair a setup that is already using VDs in a 2x2 grid? Asking for a friend :^)
Honestly though, what would happen on desktops that are using said grid? Would Activities be forced in my layout?

In T10201#208569, @ndavis wrote:

one of those in my mockup is actually the name of the Application Style subcategory.

Looks really nice and in-line with the overall KDE website theme. Good job!

You made the redundancy worse again. Why waste space on the titlebar and make it larger again? Why add the "Application Style" font?

This one isn't about contrast though is it?

The Breeze re-theming? No. I was merely stating why some designers do this based on some findings that are circulating in some circles.

Ooh, interesting thoughts. Let's see:

I understand the need for branding, but a simple site to display all icons is not really immersive for the user. Taking a look at how Apple advertise their icons on https://www.apple.com/macos/catalina/ you can see that they do a combined showcase of their desktop layout and feature a few core applications which obviously also have their icons displayed on the page. This is pretty effective and subtle.
Microsoft even dials it back further on https://www.microsoft.com/de-de/windows/windows-10-apps and https://www.microsoft.com/de-de/windows/features by not even making the interface the important part, but rather the entertainment and productivity you could have when using them.
A page listing all icons could be done like https://fontawesome.com/icons?d=gallery and similar icon sets do it, or make it similar to how Cuttlefish looks (att. 1).

In T11925#208335, @felixernst wrote:

Having read my share of black on white .pdf files I tried to figure out why "grey"/"brighter black" text is sometimes used in web dev or in general on digital screens:
Some people say it looks better to them. It honestly seemed like a fad to me.

Yes, I'm aware of that, but even on that screen there's a mention of "Application Style" that implies the decoration of the entire window. It's just a mass of redundancy and confusing naming all over again. Can we not declutter this? And coming back to a discussion on the evolution of breeze: dial back the usage of styled frames?

I'm not sure the redundancy of information is a good thing, to be honest.

I don't think we should allow applications to "brand" themselves

On the topic of titlebars and their colors: what is the general consensus of having applications be able to set their own colors for titlebars? This would allow developers to establish a more "in brand" visual appearance (see screenshot attached). I'm currently working on a window decoration that lets users set per-window settings for titlebars. If users want, it'll also draw a separator underneath the titlebar by using the titlebar color and then applying a .lighter(n) filter to it to dark it considerably. This makes for a very smooth and fitting insert which still lets the user decide on what color-scheme they would like to use. Even when the titlebar area is extended to include the toolbox like in this mockup https://phabricator.kde.org/T10201#186877 it'll still look gorgeous. Readability of the icons can be ensured by doing simple lightness checks on the background color and then applying either white or black icon sets. I'm already doing this for the text in the titlebar and the inactive window buttons.

Got it 👍

One thing I noticed while browsing the re-design candidates: many websites showcase screenshots with features that don't exist anymore. Case in point: the Konsole website shows the old split-tab feature that doesn't work on current builds.
Then there are some applications like Okular using screenshots from KDE3 which is just confusing to viewers.

The installation process part is already taken care of by most (if not all) distributions in one way or another though, see https://phabricator.kde.org/T11979#207050 and in my opinion it's the most sensible way to nag users when they set up their system, as the installer requires input by them on partioning and other settings anyway.

If something like that is going to be used, it would be good if the user could click _anywhere else_ to dismiss this window.

Why though?

Interesting, I was thinking about something like that as well to create an easy on-boarding experience for users that only have experience with other operating systems (in particular Windows and macOS). The less time users have to spend to figure out new interfaces, the sooner they can get work done/enjoy the system, which in my opinion is a great quality of life improvement.

Thanks. That's a good starting point as QML is pretty easy to pick up for anyone who knows JavaScript in my opinion. I'll poke around that example.

And QML plugins can be packaged and hot swapped on a compiled browser?

To close off the rant about the workflow on KDE: it's not that there's many tools, it's that there's so many different tools that all use different logins. For the bug tracker I don't need a KDE identity account, for Phabricator I do. Why keep the bug tracker seperate from the projects? Makes no sense, as you're missing overview this way.

It is using Qt for Python (PySide2 and Shiboken2) which are official parts of Qt.

Okay, that makes sense.

Disclaimer: I haven't looked at the Falkon source yet, so excuse me if I ask things that should be obvious from knowing the source.

It's a distributions job to get users up to snuff with the desktop environment during the installation phase. See for example openSUSE's installation or Ubuntu's background installation part which shows users a slideshow of things they can do and expect from their new desktop.

I like Falkon but it's not ready to be shipped anywhere and needs a good amount of polish.

Sure, why not. I'm not sure how much time I can dedicate to this though as I'm quite packed.

Increased difficulty, maybe yes, but also increased "wow" effect for users when done right. In terms of getting SEO to properly work with SPAs and VueJS in particular, maybe check out https://dzone.com/articles/how-to-make-vuejs-website-seo-friendly
I have quite a bit of experience with VueJS, vue-router and vuex and never did I have serious issues with SEO thanks to methods described in the linked article. In my opionion it's definitely worth investigating.

Just a quick idea: how about recreating the Discover interface as a SPA and using that for kde.org/applications?