I think this only works if everyone is in agreement on what constitutes a bug and they get reported accordingly.
Also if a community application has no desire to develop for touch, yet Purism includes the project in their repository for the Librem5, then it sounds like the user is in a position of being able to report to the developer who responds that it is working as intended and report to Purism who says to report to the developer because it’s a bug according to Purism.
Being as the user purchased the device from Purism this is more likely to result as negative emotions toward Purism and in turn negative feedback about Purism and/or their products than anything negative toward the application developer.
I doubt everyone is in agreement on what constitutes a bug and as such I think being more open to work around solutions results in better customer experiences than not. And yes, that does mean sometimes workarounds will last longer than would be ideal. Using the copy/paste bug as an example though, how much of the current progress would have been slowed by prioritizing that over what was done while people used the keyboard as a work around for now?
Sure I’d love for copy/paste to work across all applications via a touch context menu, and I do hope that such will be implemented in time. But I am also fairly forgiving since there is a workaround and there’s other progress clearly being made.
The repository includes almost the entirety of Debian. For some applications there’s even absolutely no expectation to have them work in a phone form factor, but they work fine when docked to a screen, keyboard and mouse - and that’s fine.
To add on this - even if the user does’t realize that we ship third-party software for which there’s limited expectation of bug freedom, our software lists flter out software which is not suited for the phone form factor by default. A naive user won’t even see broken software!
Slowed? It could have been sped up:
no one would have expended the effort to implement functionality required for the workaround
someone who otherwise wouldn’t contribute might have gotten annoyed enough to actually fix copy-paste.
The key is to give the community space to work on it with us, rather than to do everything ourselves (even if it’s by exposing rough edges sometimes). We’re Libre, and that means we’re not locked into doing everything ourselves.
Doubtful, since the functionality of the terminal layout would still be desired functionality for interacting with the terminal so the ctrl key functionality would still need to be implemented.
Annoyance with something is a poor motivator.
With the number of people that care about the terminal functionality I could more easily see the argument that if you developed copy/paste but not a terminal keyboard layout that someone would have developed a terminal keyboard layout.
But my point was less about who does what work and more about how things are perceived by a user for whom it is likely is infeasible to contribute to either.
My skillset for instance is not conducive to contributing code nor contributing to keyboard layouts. As such for this specific example I am at the mercy of powers beyond my control.
Hearing the feedback that what looks like a keyboard and acts like a keyboard is not actually a keyboard and that software relying on a keyboard should be changed to function differently rather than implement an on screen keyboard is disappointing from my perspective. It is just my perspective and as such is not necessarily right or wrong, just my own. Though I doubt I’m completely alone on this.
As far as the community having space to work with you vs doing it all yourselves, I don’t see how what is prioritized when impacts this. As long as there is clear documentation and communication teamwork is likely to be successful.
I think this discussion is slowly descending into pointless, digressing further and further from the OP, and certainly not getting us closer to phone-working-for-customers.
Maybe it should be forked to Round Table and reserve this topic for someone who is going to solve the OP’s problem.
I don’t necessarily agree with that. Something may eventually reach the threshold of "hey, I’m actually going to do something about this ", as distinct from "I’m just going to whinge on the internet " (not necessarily talking about changes to open source code, could equally be talking about any number of other annoyances in the world).
You’re not going to be surprised if I say that this should be responsiblility of the terminal emulator, are you?
I don’t know, it works for me sometimes. Eventually.
And someone did I didn’t code it myself, I just coded ctrl. So an unfulfilled need motivates to do things to some extent.
That makes sense. Ultimately, I think the earlier we shed outdated approaches and embrace the future, the better. Fewer people will have to put up with this. Naturally, you can argue about disappointed early adopters, but this is the tradeoff I chose.
I acknowledge that. I long intended to make it look less like a keyboard to correct any possibly mistaken expectations, but other things took priority. Oh well.
I didn’t code it myself, I just coded ctrl. So an unfulfilled need motivates to do things to some extent.