Copy / paste can be fiddly on mobile. I opened an MR today to make the paste part a bit easier in phosh-osk-stub (another old branch finally cleaned up into a (hopefully) mergeable state):

Follow

And here's what we could do for copy. Put that into an extra MR for now so we can check whether it's predictive enough for the user what is being copied (while the paste bits from above can already land for 0.42).

Note that this is orthogonal to what an app/UI toolkit offers for copy/paste (via context menus or drag handles) already.

@agx

Interesting... and how does it predict what the user may want to copy?... and correct it if wrong?

@Blort That's the thing, with the current rope we have we can just take what the text input gives us so we'll need to improve this per toolkit. It works very well for most cases though, that's why I might end up enabling it and work from there.

@agx @Blort does this work only for text input, or for any selected text?

Anyway, looking forward to seeing better paste soon! In the meantime, my workaround is to use the "Ctrl+C" and "Ctrl+V" shortcuts in the terminal layout of the keyboard. That even works for things like pasting images from the clipboard to Dino 😉

@badrihippo @Blort It would only work for text-input. ctrl-c/v is a good fallback for most apps but the quest is to make it superfluous in as many apps as possible.

@agx wait so is this a "third" clipboard besides the system one and primary selection? I've noticed that Ctrl+C'ed text doesn't necessarily match with the paste button of phosh-osk-stub. There's also a little tool(tip/bar) when I select text in some apps (GTK4?) with options to cut, copy, or select all; that one correpsonds to the paste button. Is that also part of the Phosh system your working on, or some other GTK thing?

@Blort

@badrihippo @Blort

> I've noticed that Ctrl+C'ed text doesn't necessarily match with the paste button

Not a third clipboard. If the text doesn't match there's likely a bug elsewhere. Do you have a reproducer? Maybe clipboard selection vs primary selection?

> There's also a little tool(tip/bar) when I select text in some apps (GTK4?) with options to cut, copy, or select all; that one correpsonds to the paste button

The tooltips/bar is part of GTK. That uses just the regular selection.

@agx @Blort

Oh, okay.

> Not a third clipboard. If the text doesn't match there's likely a bug elsewhere. Do you have a reproducer? Maybe clipboard selection vs primary selection?

Let me observe this a bit more carefully to see when it happens. Now that I know it isn't separate 🖇️

@badrihippo @Blort Thanks. Please file an issue against p-o-s once you have some details as this makes is a bit easier to follow than fedi.

@agx okay so my bad, it's not bug after all. Just that when I Ctrl+C something non-text (like an image) the paste button "remembers" the last text I copied and pastes that. Which makes sense given the paste button only handles text, so I guess one could argue it's a feature!

@Blort

@badrihippo

Thanks for reporting back! Yeah, I think it makes more sense to keep the selection. It will get more introspectable by users once someone picks up gitlab.gnome.org/guidog/phosh- . We could then also think about handling images as well and show something sensible in the list of selectable entries to paste.

@Blort

Sign in to participate in the conversation
Librem Social

Librem Social is an opt-in public network. Messages are shared under Creative Commons BY-SA 4.0 license terms. Policy.

Stay safe. Please abide by our code of conduct.

(Source code)

image/svg+xml Librem Chat image/svg+xml