> it's much more likely i'll get a faster accept than with a very large change.
I do agree the above is true. And maybe it's just me, but it feels like I'm kind of cheating if I stack PRs to get a faster approval. Because when one reviews some dangling code without the context of how it's going to be wired in, they can't really tell what the blast radius will be and consequently what bar they should hold the code against (e.g. performance, security, etc). In these circumstances, usually the most one can do is raise some stylistic nits (which to be fair PR process often degrades into anyway) and move on.
The plan to rely on the presence of alternative OSes is only good so long as those OSes exist. They do today, but it is more of an exception rather than a rule. In a hypothetical scenario, where a signifcant portion of users switch to one of these alternative OSes, there will be an incentive to monetize.
So I'd agree there should be rules what OS should and shouldn't do. And yes, it shouldn't be a fight with an enterprise entity, which has little incentive to restrict itself. It should be a lawmaker level discussion, unfortunately they are pursuing other agendas over there.
> In a hypothetical scenario, where a signifcant portion of users switch to one of these alternative OSes, there will be an incentive to monetize.
Which is why it's better to choose an alternative that is open source, so that when they become evil, you can switch again. It's always been like that: we're fleeing from successful companies becoming evil. What has changed is that those companies have found a way to make it illegal for us to flee, and I suggest we fight against that.
Not invisible for me. I do occassinally enter moderate amounts of text 3-4 paragraphs). I also like to iterate on my texts, so I do a lot of editing and entering at the same time.
The points mentioned in the article are painful, but something I could get adjusted to and get better at with time. There are a couple of things for me though, that I just can't work around, and which are subsequently the biggest pain points for me. These are: lack of vertical space in landscape mode and broken text selection feature. Let me elaborate. Note that I own a google pixel phone, so can't really speak for iphones or androids from other companies.
Pixels gravitate towards long and narrow displays. This can be great for portrait mode, but sucks for landscape most of the time. The issue is made so much worse that neither OS or most apps seem to try to optimize for this mode, further wasting the space available. For example, I'm typing this post in Firefox on my phone right now. About 1/3rd of the screen is taken up by the keyboard. This is fine and is actually the reason I use landscape mode - bigger keyboard allows for faster typing. Another 1/3rd however is taken up by a combination of notification bar at the top, gesture hint bar at the bottom and firefox's address bar. With some manipulation you can make the adress bar go away, but the other two bars can not be hidden on pixels period. Perhaps the biggest frustration is the fact that the "fullscreen" mode I want is already implemented on Android for games and such, there's just no way to turn it on for firefox in either the app itself or the OS.
Text selection tends to be broken when selecting several paragraphs of text, especially when selecting existing text from a web page - the teardrop just jumps around violently not letting you to put it where you want it. Sometimes you can wrestle it with multiple attempts, but other times it just won't let you leaving you with the only workaround of selecting in smaller blocks.
This reminds me there actually was one somewhat recent improvement to text editing on androids from few years back: ability to move cursor by sliding your finger over the space bar. That eliminated one big pain point I used to have.
I do agree the above is true. And maybe it's just me, but it feels like I'm kind of cheating if I stack PRs to get a faster approval. Because when one reviews some dangling code without the context of how it's going to be wired in, they can't really tell what the blast radius will be and consequently what bar they should hold the code against (e.g. performance, security, etc). In these circumstances, usually the most one can do is raise some stylistic nits (which to be fair PR process often degrades into anyway) and move on.