I recently submitted a Bugzilla wishlist (Bug 525621) proposing some UI enhancements for the default Clipboard widget. The maintainers correctly pointed out the scope was too broad and suggested I bring the design discussion here to hash out the details.
I am a developer and I intend to implement these features myself, but I want to get VDG alignment before I start writing the QML/C++ code.
Based on the Bugzilla feedback, I’ve narrowed down the scope to two phases that keep Klipper as a fast history tool, while making it more modern:
Phase 1: Rich Metadata Display (High Priority) It’s often hard to tell at a glance what type of content is in the clipboard. I propose adding:
Content Type Indicators: Small icons (Plain text, URL, Image, Rich Text).
Relative Timestamps: e.g., “10 mins ago”.
Basic Metrics: e.g., image resolution or character count.
Phase 2: Optional Grid/Masonry Layout A card-based layout to make better use of widescreen real estate compared to the current single-column list.
How does the VDG feel about this direction? Are there any specific Breeze design guidelines or existing QML components I should use for the metadata layout? Once the design is approved, I will open an issue on Invent and start working on the MR.
I like it! Wouldn’t it a better idea to do the grid / card layout first before adding all the extra information, though? Since you’ll have to come up with a way to integrate them in the current layout otherwise
The current design is actually compact and efficient for small laptop screens, but one major issue with the current Klipper is those many hovering buttons that hides half of the content of the current highlighted item.
this should idea should be implemented first before OP’s phase 1 additional details can be added
the current method of overlaying your options on top of each entry is duplicative and distracting… it is already crowded and phase 1 additions would make it unusable.
having all your options in a side gutter where you can easily access it for the selected entry would be a better way to manage the options that phase 1 wants to add
regarding the metadata proposed:
not sure what the icons add, its’ pretty easy to see what the content is (text vs image)
timestamp would be valuable and enable a time based cleanup feature
metrics are nice to know but i struggle to find a use case for them
—
the grid idea is neat, but what use case does it enable that the above improvement does not?
The big caveat here being that suddenly you need to “select” an entry, which means you’re losing the feature of just being able to one-click-to-copy, which arguably is the main use case and will make many people angry. And for some reason I don’t really perceive this side bar idea as very plasma-like.
I personally also don’t see the issue with overlaying the buttons on hover, though. I usually look at which entry interests me before moving the mouse there.
In CopyQ, as an example, this “issue” is solved by making the default action (a double-click) copy the item. Most people just want to copy an item. The other actions, though requiring an extra click and mouse movement, are less often needed by most.
That said, if they can make this configurable, having overlay icons or a sidebar based on use preference, this would solve the dilemma.
While I won’t be switching from CopyQ myself because it doesn’t depend on a specific DE, I would still like to see Klipper improved.
klippy would otherwise function the same as it does now, just instead of the action icons blocking your view of the item when you hover, they would be kept in the gutter to the side and change as you hover over each entry.
copy / paste is unaffected because the paste buffer is still only the top item in the list.
if you want to paste something else from list, then yes you have to click on it, but that’s how it’s always worked… and then the item moves to the top of the list.
Well, I didn’t consider that’s how you meant it, because… that’s even worse UX in my opinion. Selecting items on hover and then having the user move the mouse to some sidebar is just a recipe for disaster, because they will inevitably hover over a different entry by accident and change the selection. That’s like all those badly programmed hover drop-down and mega-menus of 2000’s websites which we stopped doing for good reasons
Edit: a “modern” version of this problem is the plasma 6 application launcher’s option to switch sidebar categories on hover, which only really kind of worked because they had to insert all sorts of delays and then it still feels really awkward and they had to offer the option to disable it altogether.
so now i see where the need for select would enter into it and why a grid display would be required to give enough real estate for all the hover buttons / data to be shown and accessible only while you are hovering.
still i don’t see how copy/paste is impacted by having to select an item before the gutter actions become locked onto the selection.
if you copy something it will still always be the top entry and if you click on a different entry then it would become the top entry AND it would enable the gutter options.
Well, now with this you can’t use any of the actions without copying the target entry to your clipboard, and if your planned action was “delete” that’s even more counter-intuitive… but even just to favorite or edit an entry I don’t want to push it to the top of the stack instead of my current clipboard.
I just don’t see this proposal working out.
The only viable option so far was ddnnacheta’s suggestion to use double click for copying, but even then that’s going to confuse users who’re used to the current implementation and new users might not ever discover the action in the fist place, because I don’t think plasma is really using a whole lot of double clicking for actions like this anywhere else, so it’d really be out of place.
By the way, joyjasper hasn’t even shown yet how they plan to integrate the actions into the new grid layout, so we’re probably jumping the gun here in the first place.
i like the access to the function on hover: keep that, don’t want to have to select anything.
i like the idea of more details (except maybe not the icons), but don’t see how to present them on hover without a separate gutter area, or blocking even more of the item’s view.
perhaps on hover, it would be more important to show the item clearly and overlay/cover the other items in the clipboard to make an area large enough to accommodate all the buttons and metadata display.
but now i can’t hover over a blocked item… can’t win.
Wouldn’t it make sense to have a grid with the same click/hover behaviour we have now? Maybe have options for grid size and hover options and if we are to have an ‘extended functionality’ sidebar/tray/thing have each item have a selection box like Dolphin and/or have a drag and drop function.
There arent many VDG members active over on discuss. I recommend you post this over the matrix channel. There is already one thread over on invent which you could add your design to https://invent.kde.org/teams/vdg/issues/-/work_items/100
"Thanks everyone for the brilliant feedback on the interaction design! You are completely right, amilias and skyfishgoo—I missed showing how the action buttons (edit, delete, favorite) would work in the grid layout. I will update the mockup to include a hover state for these actions so we don’t break the current workflow.
And thank you dphaldes for pointing me in the right direction! I wasn’t aware of that specific work item. I will prepare the updated mockups including the hover states and post them directly to invent.kde.org/teams/vdg/issues/-/work_items/100, and try to catch the VDG folks on Matrix.
Really appreciate the discussion here, it helped refine the idea a lot!"
