Dolphin icons outline update

To clear this up a it, this isn’t a new design. It’s the existing design we’ve used for years in menu items and list/grid highlights through out System Settings, System Monitor, Discover, Plasma widget config windows, and all other QtQuick software.

The change here is not to adopt a new design but rather make Dolphin and other QtWidgets apps visually consistent with the existing design we’ve had for years, but had simply not yet implemented for QtWidgets-based list, grid, and tree views.

Functionally, almost nothing has changed with any of Dolphin’s item views. The rectangle select feature still only selects items once it touches the area where their highlight will be visible. There are no invisible hitboxes; you can see them by hovering over them, same as you always could.

However I do agree with you that the new hitboxes are uncomfortably large compared to the old ones.

2 Likes

Exactly. Even if you have smaller outlines, they are still obscure (will tell more below).
Also I think Dolphin could perfectly made convergent for phones without a big UI change, but those outlines become a big burden for touch input. Speaking about experience with Nautilus. I don’t know if KDE will ever become convergent, but with the current overall app-design it would be a wasted opportunity. Just as a little offtopic hint.

I know, it is just hard to me to see a single solution where both parties are happy with.

Well, good point. The difference is, that other elements are more like 1-click-buttons similar to start-menus and less like an organization tool for files and folders. As button-design it is really fine. But file-manager are a tool I heavily work with, sometimes with 10 open tabs/windows, sometimes moving single files and folders around, sometimes whole batches creating temp-backups, reorganize, manage local git patches and so on. I do not just copy one or two times a year my holiday pictures where a less optimized file-manager is valid.

I know file-manager are not only for “power-users”, but also not only for the person that only uses it few times a year. It should work for everyone.

First, this is a key point of my critics. The area is obscure, not visible until hover. I usually click while moving (not super precise, especially with high mouse DPI that I require for large screens). But I have to stop it now, looking that I do not accidentally click on the border, because otherwise I move the item around. Old hitboxes had the size of icons and labels, perfectly predictable.

Second, there is less space to click on the fly. Even if the border would be visible all the time (not obscure any longer), it has much less space to click. When clicking on an item to open it, I slow down my mouse anyway for double-click and because my target is done when it open the item. But when selecting I accelerate my mouse. Before I realize that I grabbed an item and drag it around, the cursor is on the other side of the screen. Luckily Dolphin opens a dialogue “copy/move/link” and so I can stop that action (in Nautilus I often moved an item into a folder etc).

I do not care for all these things on other implementations as Folder-View-Widget, which is basically an *.desktop starter attached to desktop panels to me. Would I use it as file-manager, I would criticize the same (but makes not much sense to me to use it this way). I hope I could explain the difference well enough.

Forgot to answer this part. If you can help me to bring it to work (in case I require it), sure.

1 Like

The hitbox was already invisible, it just hugged the outline of the icon and text a bit better. But it was not 100% outline-hugging; there was still an invisible hitbox where your pointer would highlight the file while it was still over an area of whitespace. So the change here was a matter of degree, not a fundamental shift in approach.

For what it’s worth, I’m also a file manager power user. The only awkwardness I encounter as a result of these changes to Dolphin is the fact that dragging a file on top an empty area of the view fails a lot now because much of the empty area is taken up by the large invisible hitboxes for files. This feels like a relatively easy fix, though:

  1. Make the hitboxes a bit smaller to preserve more actual whitespace
  2. Accept drags onto files and don’t highlight them; instead forward them to the view rather than failing.

Ok, let’s showcase it. You are not wrong, but there is an important difference.

As you can see, the cursor does not hover the file. And the whole cursor is in the space that is required by filename-label. So this is probably the space that will not be removed with the new outline, because there is only one outline while previously there were two.
And of course, one pixel to the left and I hit the invisible hitbox you spoke about. This is nearly aligned with folder icon size. That’s why it worked so good previously.

So…

Is this correct?

I like the ability to drag on top of another file, I think macos does this too but I haven’t used my mac in a looong time. (I instead use one of the crappiest tuxedo laptops now, which is technically a huge downgrade, but software better and it’s good enough)

My “newer” section is probably wrong now according to @Marata‘s screenshot, how does it handle the text?

Sorry @ben2talk, now you are exaggerating: The PET was not 16 but only 8 bits. Great machines though. Had much fun with them, at school and at work in the first years.

Not exaggerating, but yes, I remember it was the 6502 chip, so it would be 8-bit… just confused. 16 bit was later with my Amiga (6800 processor). It’s all a bit fuzzy now… I was busier grappling with large books with circuit diagrams for huge circuit boards - just one radio receiver would have at least 8 or 9 separate boards, and there were some newer digital RADARS there which had 16 separate boards, at least a half metre square, just to handle the rotation of the antenna.

1 Like