#1 seems practically impossible to do, considering that the definition of what a crime is tends to vary between jurisdictions. It may work if on a closed internet and social media that is segregated by jurisdiction.
#2 is already true in some cases, but as usual, the real answer is something like "it depends."
Do you have any studies that actually quantify that? IMO large groups singling out and bullying individuals is not really a new thing, that has been happening for a long time.
Some US states do have laws of that type, though not all of them. In general, the answer to any kind of employer abuse is mostly the same as always: unionize.
That seems to hinge a lot on having a specific and consistent definition of what "related to the job" and "part of their work" means that won't unfairly affect some companies, maybe there is an established legal definition of that somewhere?
So to allow any post through, twitter should have a process that randomly selects an unbiased jury of other twitter posters, and have them judge the post before it becomes public? And that process will be administered by democratically elected representatives who ultimately decide on the 5% that doesn't get thrown out? What if you are a person who just happens to hold strong preconceived opinions about a lot of things, wouldn't you be seen as "too biased" for any jury, and get totally excluded from this process? Would that be the system being fair, or would it be another example of "cancel culture" stopping people from being jurors? I don't know, I'm just spitballing here, I'm not a legal expert or anything, but I do know that jury stacking/tampering is a real thing that happens.
So what is the solution there? Should twitter and facebook have their own internal legal system, decided upon by democratic vote as I was just describing? What would make it inherently less tribal if they did that? Would that stop large groups of people from all deciding to vote as a block and criticize one person all at once? Or is the goal something else? Surely, if this problem were theoretically solvable by a social media site, there should be some different way to operate one?
I mean, to me that sadly is nothing new. I've known my share of people who just assume by default that people they don't know are jerks, and are hostile toward them. I don't know what you would call it. Untrusting? I can't see where you would cross that line and all of a sudden start calling it "cancel culture" or "consequence culture" or whatever. Is it because it's happening online now?
I guess I'm confused, there are a lot of things in life that become known by hearsay and don't reach the same consensus as codified law. What makes this special? Would it really be any different if twitter actively had daily democratic polling on who should be criticized that day? And how would that be any different from "mob mentality," if large groups of users all decided to impulsively vote the same way?
So what would that look like? Would employers no longer field public complaints about potential problem employees, under any circumstances? In effect, they would be required to always side with the employee in case of a dispute?
Just to be clear, is it "cancel culture" or "consequence culture" when the legal system puts people in jail, or practices capital punishment? Or are those considered something different entirely? If so, why?
So how could responsibility be ensured? Make a social media site where people can't criticize each other at all? Require all posts to go through third party fact checkers?
To put it another way: If, in your opinion, twitter users are not subject to accountability based on the chaotic randomness of public opinion, then who are they being held accountable to? Who even determines what a "consequence" is in that scenario, or what the threshold for that bloodthirsty behavior is? Honest questions here, I really don't know what the solution is.
That's quite interesting, thank you. I haven't heard of that. My only concern with that is, I hope some app developers don't see it as an excuse to avoid using the native accessibility APIs and adding the necessary properties to their controls.
Screen readers doing OCR is a big no-no. There is no possible way that will have the effect you want it to have. The text-to-speech part is the absolute bare minimum of what a screen reader is actually doing. For example that would break horribly with the situation you describe, where some piece of text gets clipped.
Just IMO, it's unrealistic to expect to have an accessible GUI that stores no state, does none of that type of bookkeeping, has no OOP model, and only outputs to pixels. The point with these type of assistive technologies is that the user can't work with that type of visual data, they need more state presented to them. Sure, it makes everything easier to develop when you cut it all out and only use immediate mode, but that's exactly the problem: everything else has been cut out, on purpose.
I still don't really understand the difference, is it not possible to host a service on your planet, and then have people make accounts on it and log into it with some other means? If so, that would seem to make it identical to mastodon, or any other internet service really. There doesn't seem to be any reason you can't bridge it with random HTTP services. I mean, in theory you could even run a mastodon-like service inside a planet?
That seems like it could be interesting. It sounds like you would need to have part of a library store and diff the tree state, and then send updates based on that? You could use that part for immediate mode GUIs, and then retained mode GUIs could skip it and maintain their own trees, and just deal with the protocol, maybe even the raw protobuf bindings or whatever it is you choose.
The Linux desktop environments could really use more people working on the accessibility stack, it's really outdated at the moment.
Such cross platform API would belong in a cross platform toolkit, it really makes no sense for Windows to provide that. For example Qt has a cross platform accessibility API, and GTK is currently working on making theirs cross platform. Maybe somebody should move this functionality out into a standalone library?
Applications don't have to implement this, the toolkit is supposed to handle it. It happens at the layer above Vulkan/DirectX, because those APIs are too low level and don't know anything window controls, text, etc. When applications disregard the platform's toolkit and use another toolkit that is not at feature parity with the one provided by the platform, they'll lose functionality. That's always been the case.
It gets brought up because, at least from my perspective, none of the immediate mode toolkits are addressing this. I understand the desire to keep the code simple and only handle the rendering, but that is fundamentally opposed to the way some assistive technologies work. They need to access the UI as a state tree to even make sense. If the goal with these toolkits is to always avoid storing state information, that isn't ever going to work with screen readers. You can't push this task to the app developer, it really needs to be tied to the toolkit's internal hierarchy and focus handling.
My opinion for the last several years has been, if you use these toolkits, you might just have to accept that your app is not going to be accessible and is not really suitable for anything beyond highly specialized use.
That really has nothing to do with language-specific versus distro packaging. If you replaced a bunch of rust crates with random modified builds from a third party, you would probably see the same types of breakage.
I guess that's why most games are a bad fit for trying to ship as part of an open source Linux distribution, where the requirement to get packages upstream is that they have to be open source and compatible with the distro's usage and redistribution policies.
Newer Gtk apps that use app menus with GAction and GMenuModel should work fine, and will be forward-compatible with other similar tools, since those will export the menu over d-bus.
It doesn't particularly matter, I'm just addressing a common misconception. Dynamic linking doesn't have to happen only at build time and it doesn't have to depend on any particular symbols being present. Even if you static link your libc and SDL, you're still likely going to be doing some dynamic linking at runtime, and in most cases this is probably what you want. You just don't have to handle it yourself because it's implemented within SDL -- it handles all the version detection logic at runtime for you and can decide how to handle things based on the existence of some symbols, so with that it's possible to support multiple version of the same dynamic library, within the same program, and without a recompile.
Depending on how you build SDL2, your application could be entirely statically linked at build time, but you could still be using libraries dynamically loaded at runtime for other necessary system components: https://github.com/libsdl-org/SDL/blob/c59d4dcd38c382a1e9b69...
This is a hard requirement if your application uses OpenGL or Vulkan, you can't really statically link those libraries at all, and you have to use dlopen/dlsym to check each individual function in order to support extensions.
- Editing shortcuts within the menus is not really discoverable, except by accident, it's too easy to accidentally change a shortcut that way and screw up your program, and the UI around saving/loading/resetting them is not good
- Tearoff/multicolumn menus were seen as a workaround for programs that have too many huge and/or nested menus, where something like a toolbar or a command palette would be more appropriate