4 ms·
The problem with your suggestions is that the program would still need to be updated to support those new libraries. And new mice and touchscreens have gotten n
by BrightGlow 5y ago
The problem with your suggestions is that the program would still need to be updated to support those new libraries. And new mice and touchscreens have gotten new hardware features, which require changes in the software to support them. Even something as simple as upping the resolution of the device can require an API break to widen the data type. Networking is also not something that can just be tacked on by the OS, if you want a decent experience then it needs to be built into the program.
Unicode is required if you want to have decent support for non-English text, for a really basic example you might want to try writing an ASCII document that includes multiple languages in it and see how it doesn't really work at all.
I'm not sure what you mean rich copy and paste is a security nightmare, programs that don't handle a complex data type will just ignore that type. A text editor will commonly just negotiate the type down to "text/plain" or equivalent.
- inetknght 5y ago> the program would still need to be updated to support those new libraries Really? You think programs can't just load all of the libraries in a given directory? > And new mice and touchscreens have gotten new hardware features Yeah, like... more buttons and higher DPI except they still boil down to the exact same interface. "Button X was pressed... button Y was released... moved +X+Y" For real the biggest innovation I've seen in touchscreens is a sensor that tells how far away a stylus is or how hard it's been pressed. And that's really _not_ a big breaking change to require an update to every piece of software. > Even something as simple as upping the resolution of the device can require an API break to widen the data type. Yeah okay but that hasn't really happened any time recently. Or are you going to tell me that we should support a screen whose resolution is measured in _more than_ billions of pixels wide and tall? because I'm pretty sure your eye can't even _see_ that many pixels. > Unicode is required if you want to have decent support for non-English text Yes okay that's nice. That doesn't change the fact that unicode is broken in most apps. > programs that don't handle a complex data type will just ignore that type Programs that do handle that type are exactly what I want to stop. I absolutely never ever want to copy HTML from somewhere but there's often no way to disable it. Formatted text? Trash. Send me a file. Picture? Trash. Send me a file.
- BrightGlow 5y ago>Really? You think programs can't just load all of the libraries in a given directory? They can't, a library implements a specific API. >except they still boil down to the exact same interface. "Button X was pressed... button Y was released... moved +X+Y" Well no, with multitouch the interface has changed from that to a series of events, and you have to handle gestures too. Some apps still don't support these. This isn't just for mobile devices, laptops all have these touchpads now too. >Or are you going to tell me that we should support a screen whose resolution is measured in _more than_ billions of pixels wide and tall? This would be for pointing devices, so yeah, with a high DPI mouse then you might want to make it 32-bit or 64-bit. This wouldn't be for billions of pixels but to subdivide into many fractions of a pixel. Example: the original Win32 API only uses 16 bits for mouse coordinates, so a new API is needed and the apps need to be changed if they want to take full advantage of that mouse. >That doesn't change the fact that unicode is broken in most apps. Please report those bugs to the developer, that should be fixed. >Programs that do handle that type are exactly what I want to stop. I absolutely never ever want to copy HTML from somewhere but there's often no way to disable it. Formatted text? Trash. Send me a file. Picture? Trash. Send me a file. I can't agree with this, I copy formatted text and pictures all the time. Your program should have the ability to remove the formatting.
- inetknght 5y ago> They can't, a library implements a specific API. I'm sorry, what? That's the whole point of putting things into a library. Every library should be compatible with the common set of APIs. Any library that isn't compatible is defective. > with multitouch the interface has changed from that to a series of events, and you have to handle gestures too. Some apps still don't support these. This isn't just for mobile devices, laptops all have these touchpads now too. A series of events is exactly what a mouse has always reported. Gestures? Apps don't need to support gestures. Even iOS often doesn't understand the gestures that it claims it supports. Why on earth do you think an app should support something that the OS itself can't support? > subdivide into many fractions of a pixel The whole point of a pixel is to be the smallest point that a program needs to understand. > the original Win32 API only uses 16 bits for mouse coordinates My screen resolution is 2560x1600. I have two monitors spanned, giving me 5120x1600. I can see someone having a couple dozen of them to get up beyond 65k width. But at that point the user is already reaching the limits of the hardware to render such a large number of pixels, the limits of physical space to even _have_ them. Given that the Win32 API has been around for a few decades and I don't think we're actually reaching the hardware capabilities to need the upgrade... I'm going to simply say that you're being hyperbolic. > Please report those bugs to the developer, that should be fixed. No, fuck that. I have better things to do with my time than to be every developer's free QA.