I doubt that there is any magic selection option somewhere; i think i’m arguing for some culture / library changes in the way the applications are made.
What i ran into this morning:
The podcast descriptions in Kast cannot be copied.
The full text of the About this System panel cannot be selected and copied. EDIT i found the “Copy Details” button so i am delighted to see the acknowledgement culturally that this should be copyable, but the need to provide a special button strongly suggests the need to make copy-ability be the default.
That’s the kind of thing i’d expect from a proprietary lockdown situation, and its quite jarring to find myself typing instead of copying from my own computer when running KDE.
Sorry for the rant; i am sure this is being addressed in various tickets but i was not able to find any quickly and nothing in the forum. Thanks!
Hi - I suspect there’s some balance between making everything selectable for the cases when something should be, and avoiding issues where folks lose track of their cursor because it’s constantly switching to text selection.
In general, I’d think that if there’s a block of text in an application that folks are likely to need to copy out, and it’s not selectable, that’s probably a good candidate for a feature request in that application: Get Involved/Issue Reporting - KDE Community Wiki - the example of podcast descriptions in Kasts is likely a good one.
The key distinction between proprietary and free software is in your freedom to change the software to meet your needs by obtaining the code, editing it, and compiling it into the tool that you need. KDE projects’ source code is available via https://invent.kde.org/, and the community guide to getting involved in development and setting up an environment for it is located here: Get Involved/development - KDE Community Wiki.
Indeed, this isn’t hard to change, it’s mostly a matter of doing it in places where it make sense. For this, bug reports are helpful.
Note that there are some subtleties involved that make it infeasible to simply apply this change automatically for everything, such as text labels located on interactive controls like buttons and list items. This would get confusing if you click-and-hold a fraction of a second too long while moving the pointer and accidentally start selecting text rather than triggering the UI element.
But long static labels full of explanatory text or jargon terms you might want to do a web search for should definitely be selectable!
Kasts developer here. Only saw this topic just now.
As Nate mentioned, changing this is not hard. It’s more a matter of making sure that usability is still ok for all scenarios.
I had been looking into making more text selectable a while ago (more than a year though). I remember that I was trying this on the episode descriptions, and vaguely remember that it was causing problems on touchscreen devices where it would select the text rather than scroll if you would swipe. I couldn’t easily find a solution (probably due to my ignorance), so I gave up at the time. I might now give it another shot, though.
PS: You will probably get a quicker response by opening an issue on the bugtracker for Kasts: Log in to KDE Bugtracking System
The issues end up in the real developers’ inboxes, while not all developers are reading the forums (I only occasionally do).