@manueljlin: Thanks! I hope so too.

I'm adding you're ideas to the task to-do list

I am happy to hear that!

I don't know easy or feasible is to map applications to its wmclass string

I was wondering about that. Hopefully there is an easy way. But ye, this is one of the things that can be done any time later I think.

• Only display conditions that are in use: I am a bit unhappy that I solved this differently than with the "Show all rules"-button. I went with the approach of adding/removing conditions because I thought having a checkbox to enable/disable conditions wasn't easy enough to understand. I especially thought this would be a problem when a new rule is created and the user is faced with five unchecked conditions.

I find your approach (Add/Remove) better from an user point of view, although the problem I see is how to present the possible effects that can be added to the user, that is, what happens when you press "+ Add.... Have you something in mind?

I was thinking about this some more but didn't come up with a way to solve this better than in my mockup. I think it might be fine though. For the "conditions" list the "Add conditions" button would have a dropdown with entries like "Add application condition", "Add window title condition", "Add window type condition", … This way no secondary window is necessary to create a rule. I would guess that most of the time only one or two conditions would be added this way and because there are only a few possible conditions to choose from a dropdown is a great fit here.
For the "rule effects" list the current behaviour has the same benefit of not making a secondary window necessary. The big list of possible "effects" needs to be somewhere and putting it in another window that spawns when clicking an "Add …" button wouldn't make the UI more understandable IMO (although this wouldn't be a bad way to solve this either). The workflow of activating effects in a rule by clicking its checkbox also makes sense IMO (contrary to the "conditions" list).
So yea, although it is a bit unfortunate to have two different ways to add objects to a list in the same window it might still be the best solution for the window rule modification/creation.

This looks much better! Only showing preferences that are part of the rule by default for already existing rules is a good idea too imo.

In D27523#614973, @meven wrote:

VDG questions:

Disclaimer not a VDG member

I didn't mean to discriminate. :P

Add my copyright because I forgot

I want to preface this with saying that I greatly appreciate @elvisangelaccio's work. I am interested in working on Dolphin because it is such a great piece of software.
Nevertheless I went ahead and implemented moving the url navigator to the toolbar as an option. I was hoping that if I provide a decent implementation of this it won't seem that unmaintainable anymore. I have to admit it was more tricky than I expected but I think it worked out okay. Let's hope I succeeded. :)
Have a look:

I want to preface this with saying that this is not a push to ignore the maintainers opinion on this matter. I was hoping that if I provide a decent implementation of this it won't seem that unmaintainable anymore. I have to admit it was more tricky than I expected but I think it worked out okay.

@The-Feren-OS-Dev For the latest discussion on the view mode button check out D23075: Change default Dolphin toolbar layout.

It probably helps that they don't know much German yet. :)

I believe it does. :D I once was at one of their concerts.

Would yo like to open that task?

If it wasn't clear yet I really dislike grouping. So much so that I switch to a TTM when a grouped workflow would be necessary. So I am imo the wrong person to open a task for it because I wouldn't even be interested in using the improved version.
Even for the improved version I would still say that it is a similarly good default choice as the TTM.
However I would have some passion for switching to an IOTM if the target was to have an ungrouped IOTM on the left with the idea of my previous comment implemented because at this moment I feel like it might just be the best of both worlds. If that's ever what we are trying to accomplish you can count on my assistance. ^^

I like that as well. How would you want to handle menus then where tooltips don't show up currently? It could seem a bit redundant to hover Dolphin>Tools>Open Terminal and get a tooltip labeled "Open Terminal [linebreak] Show more". Well in most cases the tooltips aren't identical to the label so it wouldn't be that bad most of the time.

That does sound like an improvement! Most of the time users want to switch to the window that they used last anyway so with this change they would only have to click the grouped entry once in this case. It would remain a bit awkward when jumping to the other windows.

I would say let's think about where users are supposed to find help and then we'll see if What's This is part of that solution. I see the following help "concepts" but I am unsure about the details:

There is already an open task for this: T9986: Delete "What's This" inline help functionality. Maybe the discussion should continue there instead of having a second discussion here?
The discussion there also already covers that the "?" users are complaining about will be hidden by default for Dialogs with Qt 6.
Which KDE windows will then be left that show a "?"? I know of System Settings, Dolphin and KSysGuard.

• In System Settings the "?" is a usability problem imo because so many KCM don't have "What's This?"-help texts. Users might have tried to get help with the "?" and got nothing. We should probably just talk about System Settings instead.
• For Dolphin and KSysGuard it is good for usability I think. Well I wrote the "What's This?"-help for Dolphin so I am as biased as can be about that one but still.
• Kate also has "What's This?" for some items but doesn't show a "?" in the title bar. I doubt users complain about that one.

In T12441#219280, @ngraham wrote:

I think the TTM works best when […] you're using a large number of windows from the same app, without too many windows from other apps. The IOTM on the other hand is better for basically every other use case IMO.

TL;DR: IOTM better for most users, TTM better when using many windows, IDK which should be default, maybe polling among KDE contributors would give us a clear answer?

I do not share the concern that the toolbar will be too crowded when the path is added. Looking at the mockups I feel like there is enough space left even if we keep the current labels as they are. The path becomes a relative one anyways when there isn't enough space which isn't terrible. When this change was discussed in the VDG chat half a year ago there was a consensus that it looked better and I am pretty sure users will be happy with this change as well.

@esokrates, I think that's a good idea. It does make sense to me to be able to collapse it even further. This would make a "Hide Sidebar"-button in a toolbar even less necessary. So consider it added to my proposal.

Be aware that with the selected pictures alone people will not know what the conference is about if they don't know KDE.
This is a bit of a problem for the banner on the college website - but they are only a click away to find out.
This isn't a problem for the facebook event page.
Just something to consider if you are planning on actually printing a poster. I think my poster is still the best choice for this.

This one isn't about contrast though is it?

The Breeze re-theming?

In T11925#208421, @joricke wrote:

It mostly has to do with decreasing the chance of making the user experience eye-strain. The tolerance in this is of course different from person to person, however here's a survey conducted by the American Optometric Association on the topic of working with computer screens in 2015: https://www.aoa.org/newsroom/most-americans-experience-digital-eye-strain-from-overexposure-to-computers-according-to-survey
Their findings are that 58% of their test-group (which was a sample size of 1,000 people) reported suffering from eye strain due to heavy use of digital screens.

@KonqiDragon, try to only quote things that are necessary to understand your comment. This way it's easier to keep the overview and readers don't have to scroll so much. :)

Between opaqueness, blur, contrast and saturation it might be quite hard to figure out the best settings but this definitely already seems like a big step in the right direction to me. So many options!

This is what I got so far. I hope it is up to par:

In T11925#205802, @niccolove wrote:

Those mockups look fantastic to me. I think it is because the colours have such a high saturation of the various colours that still fit together because wallpapers tend to have matching colours. The screenshots further down that are based on the actual semi-transparency that is commonly used look way worse to me because the background colour is de-saturated towards the base colour (white):

In T11925#206263, @niccolove wrote:

In T11579#204100, @onvitaik wrote:

Would it be possible to drop the vertical text (both bottom-to-top and top-to-bottom) on the sidebar, and instead just use buttons with tooltips? From a UX standpoint, vertical text can be a big negative to users, as you're possibly making them tilt their heads to read the text better. It can also make the UI feel a bit inconsistent by being the only place(s) where text is not horizontal.

I was mostly thinking about manual resizing by the user. In a picture:

Some of the VDG people seem to be in favour of approach 1/1b and I think it definitely can work. But so far I still think having 2 as the basis is the best way forward. Here is a mockup that expands on 2 and @fabianr's comment.

M153 Sidebar design

10

Oh okay. I understand. I only referred to the arrow removing step then.

Thanks for the analysis :) I still think we should get the change in with the current KToolBarPopupAction functionality (like Nate suggest), and then work on refining the user experience. But feel free to pinch in on the user experience part.

This is such a big discussion already. Which suggestion of Nate do you refer to specifically? I thought the current approach that shows indicators was denied.

In D19311#508519, @hallas wrote:

We have previously discussed various ways to simplify this change, but no other suitable solutions has been found, but I am still open to simpler solutions :)

Current (?) one for comparison (from Kubuntu 18.04 since the one from Neon Unstable crashes for me)

• It does fit the style of having different logical parts of the dashboard purely divided by white space (and not by borders, lines).
• It makes very clear that typing will trigger the search while in your screenshot it looks like the search field doesn't have focus and typing might not trigger the search.
• In addition the size of the elements of the dashboard should loosely correspond to their importance. The search is arguably the most important feature of the dashboard. The way you changed it it seems a bit too minor to me.

I agree that the search as it currently is is inconsistent with how we display search fields anywhere else but it does fit with the rest of the dashboard. The overall style of the dashboard is pretty unique imo (for better or worse). So imo keeping the current search would be fine for now.

Yes, that would be alright imo. That's actually mostly what I meant when I said

@Leon0402 and I were just discussing this change in the VDG chat room so I'll write down some opinions I got.
Overall I think it is very helpful and elegant to teach the shortcuts within that combobox. We need to make sure though that the area description + default shortcut fits into a row in most locales.
If the user has changed the shortcuts to something that doesn't fit into the combobox I would favour simply not displaying the shortcut because in this case the benefit of teaching the user a shortcut is hardly there anymore. Making the dropdown wider is the other option but I'd imagine that might look kinda bad. This needs testing.

I think it is fine having two actions that both open the Search/Findbar. The new 'toggle-search' would replace 'open-search' in the Toolbar and 'open-search' would still be associated with Ctrl+F.
This is similar to having two actions for typing a new location:

In D23075#510653, @ndavis wrote:

In D23075#510484, @ngraham wrote:

[Previews] are enabled by default.

Ok. If we're not going to have a button to enable/disable them by default, we should disable previews for documents under a certain size. Maybe =< 32px or =< 22px?

This is not very nice to look at

... compared to this

There wasn't much discussion about using the view mode button in the VDG:

I kept the names lowercase because after trying both I liked them lowercase better. The visible difference between lowercase separator/spacer and title case actions makes the list a tiny bit more neat imo. I don't mind changing the names to title case though. Judge for yourself:

Rename to "expanding spacer", Cast to QToolBar instead

You all are too kind!

Use insertWidget(before, spacer) instead of addWidget(spacer)

In T11153#191838, @niccolove wrote:

What about tabs on top? I'd say those should be used when they only change a part of the window and not the whole view (except in falkon of course),

How about only making security update notifications persistent? There is no real harm in missing non-security updates in my opinion.

+1 for the idea. Dolphin is often used to differentiate between drives so having the format option right there would be kool.
Should it open the KDE Partition Manager?

Looks great overall!
I just want to nitpick that the top-right search bar doesn't align with the sidebar. Adding the class "mr-3" to the form and setting the .form-control width to 255px seems to have aligned them for me but that is maybe not the right solution.

Use classes "list-unstyled m-0 p-0"

I think the dropdown menu for the language selection might be too hard to spot if an unknown language is displayed.

In D22240#492315, @ognarb wrote:

and when I have a bit more time I will implement the RSS feed feature.

Add RSS feed with recent blog posts and change wording to "Community blog posts"

In D22240#490845, @ognarb wrote:

@felixernst do you want to try implementing this functionality?

Change "News from KDE contributors" to "News from contributors"

Change wording like @skadinna suggested - this time for real

Oops, I'll try that again.

Change wording like @skadinna suggested

I don't have commit access. Would one of you land it for me please?

Change "timeoutInS" to "timeoutInSeconds" and add const

I thought non-integer values could not be entered because entering a dot there is not possible for me. Comma works though.

Do not use ceil until the first integer was reached
This way when a non-integer value like 4,5 seconds is entered
it won't show 5 seconds in the title for the first .5 seconds of
the timer.
I also made the math more easily understandable by extracting
calculations into separate lines.

I would agree with that but the UI only allows for integer values as a timeout right now.

There are two different scenarios for sidebars explained in T11093: Improve Consistency across the Board. Just to be clear: This task is only about the second one, right? I would tend to think these can be viewed as separate issues for now (roughly quoting @niccolove):

Use i18ncp and have "second/s" instead of an "s"

Make seconds localized
I actually tried to research if "s" is an international
symbol beforehand and it seemed to me like it was
(https://en.wikipedia.org/wiki/International_System_of_Units)
but I trust your call on this.

What do you say it is down to one line now! Your latest changes really helped there.
I would have created this diff sooner but it's way too hot in my room and I had to rebuild all dependencies because I switched to developing in a virtual machine. So I was delaying this but seeing that it won't be cooler anytime soon I took this burden on me. :P

Rebase to master

Thanks for fixing this!

Remove trailing whitespaces

This does sound like it could be a good solution. I am not quite sure if I am picturing this correctly.

I don't have commit access. Can you land the patch for me, per favore? :)

I don't think Konqi should be called a banker when wearing a suit. It doesn't fit the collaborative non-profit nature of KDE. I think Boss Konqi is alright. Business Konqi can work too.

Excuse me for not making these small changes and sentence restructuring sooner. Re-reading my help messages now brought different details to my attention.

Start help message for "Show hidden places" with "This"

Unify sentence structure and add requested space
Sentences should start with "This does/is/etc." for
better intelligibility if possible instead of using
the imperative or omitting the subject.

But for now I'll wait until D21638: Display delay in the taskmanager has landed and I'll rebase to master then.

The following text has become longer than I intended to. I will put it somewhere else if it is seen as off-topic. I have been thinking about this for a while and I want to get it out there because I think it might be a solution to multiple problems.