|
Cybernetic Vermin posted:and then the *styling*, the precise way they choose to have a button look, does not matter that much. it's important to acknowledge that it's possible to use a <span> to do a <button>'s (or an <a>'s) job and that sucks. if you want to list things, you can use <ul> and <li>, or you can just use nested <div>s. there are a lot of semantic tags that exist, like <article> <main> <aside> <nav> <details> and those can be used to make accessability better.
|
#
?
Jan 31, 2024 14:31
|
|
|
|
| # ? May 24, 2024 15:59 |
|
|
i guess the one plus side is that when someone uses one of the semantic tags, it's probably more correct than not. someone who doesn't care about accessability and doesn't want to learn will probably just use 1000 nested <div>s to solve every problem
|
|
#
?
Jan 31, 2024 14:35
|
|
|
Wheany posted:it's important to acknowledge that it's possible to use a <span> to do a <button>'s (or an <a>'s) job and that sucks. yeah, for sure there's room to gently caress things up, but a lot of the web does do a button for a button, as the big frameworks do (and tend to push in aria tags as well). it might be worth pondering what's more common: someone rolling a button from scratch as a span, or a "native" app having an onclick-handler on something not a button. one might then extend that to wondering how well native apps do semantic lists and headings compared to the web, maybe not too uncommon that there's a random label stuck somewhere which is actually logically a heading? e: which is to say, not obviously in the webs favor, but imo "is it a real <button>" is a way more correct question than "is it styled the same as everything else?"
|
|
#
?
Jan 31, 2024 15:02
|
|
|
there is a lot more to "native applications" than just the manner in which buttons are skinned, there are a bunch of user interface conventions as well. linux has a particular problem with this because Certain Distributions ham-fistedly apply "theming" to every application so that their commercial sponsor can establish a brand identity at the expense of making third party applications look like poo poo through no fault of the applications' own. an unmodified qt app will always look out of place on some subset of windows and macos no matter how much paint you slather on its individual user interface controls. "electron app" isn't just an implementation technique, it is a "platform" of its own in the sense that those apps use webby user interface conventions as opposed to apple-ish conventions or windows-y conventions.
|
|
#
?
Jan 31, 2024 15:31
|
|
|
if you include some garbage immediate mode ui library in a language, people will start making apps that don't support CJK languages or accessibility stuff
|
|
#
?
Jan 31, 2024 15:33
|
|
|
eschaton posted:in other words, I absolute think 1 is worse than 2 I don't know what the C++ lunatics actually proposed, but my suggestion was a standardisation of paths as a syntactic construct, not a standardisation of all file system operations. Unix-style paths are just names separated by slashes, where optionally you can have a leading slash to indicate a an absolute reference, and otherwise it is relative to some implicit "working directory". You can encode content addressable stores just fine by interpreting the path components. You can even encode drive letters or remote machines, or arbitrary computation using things like FUSE or P9. Paths just encode a path through a graph, that's it. They are the wrong place to put fancy knobs and dials.
|
|
#
?
Jan 31, 2024 16:59
|
|
|
mystes posted:if you include some garbage immediate mode ui library in a language, people will start making apps that don't support CJK languages or accessibility stuff will start???
|
|
#
?
Jan 31, 2024 17:01
|
|
|
Athas posted:I don't know what the C++ lunatics actually proposed, but my suggestion was a standardisation of paths as a syntactic construct, not a standardisation of all file system operations. Unix-style paths are just names separated by slashes, where optionally you can have a leading slash to indicate a an absolute reference, and otherwise it is relative to some implicit "working directory". You can encode content addressable stores just fine by interpreting the path components. You can even encode drive letters or remote machines, or arbitrary computation using things like FUSE or P9. Paths just encode a path through a graph, that's it. They are the wrong place to put fancy knobs and dials. Nope! There's a lot more to it than that. Win32 paths are UTF-16 strings separated by either slashes or backslashes. Some sort of case-folding is also applied when matching filenames in the filesystem. Linux paths are byte strings separated by a 0x2F byte and terminated with a 0x00 byte, and file names are not allowed to include either of those two bytes. These byte strings are typically interpreted as UTF-8 characters, but that is strictly a user-space assumption, and Linux will happily let you create file names that contain invalid UTF-8. This will blow up an application which does not treat file names as byte arrays, which is most of them. It's a reasonable assumption most of the time, but e.g. /bin/mv and /bin/rm should not make it. Also Linux allows filesystems to be mounted with various forms of case-folding. The Steam Deck does this, for example. I don't know what file system naming rules the .DS_Store operating system uses but I'm sure it's something powerfully idiotic. Anyway Rust has a filesystem abstraction that takes all of these issues into account, but Go does not and early versions of Python 3 did not either. It's not an intractable problem by any means, but there are gotchas in there.
|
|
#
?
Jan 31, 2024 17:34
|
|
|
Sapozhnik posted:Nope! There's a lot more to it than that. I am arguing most of that crap is not useful and should ideally not exist at the path layer. Case sensitivity is actually a red herring in this regard, since it is only a subset of checking whether two paths reference the same object. You need to touch the file system to get the right answer. The Unix path model is not perfect, but it is a lot better than the mess of Windows. Surprising, since Unix is older. I can't decide whether it would be preferable to require paths to be valid UTF-8.
|
|
#
?
Jan 31, 2024 17:55
|
|
|
Sapozhnik posted:Nope! There's a lot more to it than that. you can put a slash in a filename in the macos finder, but it will actually be a colon in the filesystem lol (i assume cause you could put slashes in filenames in classic macos, but not colons since they were the separator) also i used to do fancy non-alphanumeric sorting of files by pasting CR in front which wouldnt be visible in finder but would still affect sort order. now allowed any longer tho 
Carthag Tuek fucked around with this message at 18:36 on Jan 31, 2024 |
|
#
?
Jan 31, 2024 18:33
|
|
|
std::filesystem just standardized boost::filesystem with minor tweaks. it is not something i would hold up as an example of brilliant design that solves all of the hard problems for you, but it's basically fine. if you are creating a platform which does not have a filesystem where std::filesystem's api makes sense you can just not implement it. any software which uses std::filesystem is going to depend on a sufficiently unix-like filesystem api even if you don't provide one in the standard library so it's not actually reducing portability in any way. we're actually currently working on making our stuff work without a filesystem to support some incredibly stupid wasm poo poo. the fact that we use std::filesystem has increased the complexity of this project by exactly zero.
|
|
#
?
Jan 31, 2024 18:51
|
|
|
The stupid poo poo part of std::fs is knowing whether you need to link another library for it or not, and the fact that this changes based on your platform & stdlib version.
|
|
#
?
Jan 31, 2024 19:12
|
|
|
I don't believe for a second that win32 paths are utf-16 maybe ucs-2 not gonna look it up tho
|
|
#
?
Jan 31, 2024 20:19
|
|
|
eschaton posted:and while this is awesome for Decker, it absolutely loving sucks for any applications anyone needs to use to get work done or do other non-optional tasks throughout their day I wonder if they would have blocked Safari for having a button that switched between “stop” and “reload”, which was explicitly called out as a banned pattern in the HIG of the time (until I pointed it out to Dave Hyatt and he went and sat on someone’s head) (JavaScriptCore has no UI elements at all, I don’t get what your issue is there)
|
|
#
?
Feb 1, 2024 00:21
|
|
|
Sapozhnik posted:Nope! There's a lot more to it than that. they are sequences of 16-bit code units, but they are not necessarily UTF-16 in that they can contain unpaired surrogate units and other illegal constructs. you can have a Windows filename such that it cannot be expressed accurately in any other encoding. (some Windows APIs will reject paths with unpaired surrogates, but not all, so enjoy) similarly, Linux just requires that paths contain no 0 bytes. you can have a filename on Linux that is not possible to decode as legal UTF-8
|
|
#
?
Feb 1, 2024 00:30
|
|
|
pokeyman posted:I don't believe for a second that win32 paths are utf-16 used to be UCS-2 until Windows 95 or so I think, then kinda-UTF-16
|
|
#
?
Feb 1, 2024 00:30
|
|
|
|
|
#
?
Feb 1, 2024 00:32
|
|
|
Subjunctive posted:they are sequences of 16-bit code units, but they are not necessarily UTF-16 in that they can contain unpaired surrogate units and other illegal constructs. you can have a Windows filename such that it cannot be expressed accurately in any other encoding. (some Windows APIs will reject paths with unpaired surrogates, but not all, so enjoy) also worth noting that just because a path is valid to the rest of linux doesn't mean it's valid to the filesystem in question, so you can't necessarily perform file io just because the path is valid
|
|
#
?
Feb 1, 2024 00:35
|
|
|
Athas posted:I am arguing most of that crap is not useful and should ideally not exist at the path layer. Case sensitivity is actually a red herring in this regard, since it is only a subset of checking whether two paths reference the same object. You need to touch the file system to get the right answer. “reference the same object” isn’t what you’re checking with case insensitivity. you’re checking whether the paths are equal (even if not identical). same-referent helps with open, but doesn’t solve “create(‘a’); delete(‘A’)” because you don’t operate on the object there except as a side effect; you operate on the set of directory entries. just because two paths point at the same file doesn’t mean that they’re equal (even ignoring dangling symlinks and so forth)
|
|
#
?
Feb 1, 2024 01:20
|
|
|
was anyone other than apple ever braindead enough to make a case-insensitive filesystem?
|
|
#
?
Feb 1, 2024 02:35
|
|
|
FAT?
|
|
#
?
Feb 1, 2024 02:37
|
|
|
lmao how could i forget. just checked ~wikipedia~ and it appears this idiocy is limited to fat, hfs, iso 9660 cds, and some ancient dec poo poo
|
|
#
?
Feb 1, 2024 02:39
|
|
|
DELETE CASCADE posted:was anyone other than apple ever braindead enough to make a case-insensitive filesystem? you are. im not saying you did it, but your braindead enough
|
|
#
?
Feb 1, 2024 02:40
|
|
|
my programs may be bad, but i'm at least smart enough to never attempt to make a filesystem
|
|
#
?
Feb 1, 2024 02:41
|
|
|
DELETE CASCADE posted:my programs may be bad, but i'm at least smart enough to never attempt to make a filesystem I worked on a filesystem but it was basically “what if networked filesystem but fully POSIX and you get extN’s core feature set because that’s what we’re wrapping” so we avoided the worst pits of design hell. still managed to gently caress up a lot of stuff, but apparently people are still using it!
|
|
#
?
Feb 1, 2024 02:45
|
|
|
Subjunctive posted:I worked on a filesystem but it was basically “what if networked filesystem but fully POSIX and you get extN’s core feature set because that’s what we’re wrapping” so we avoided the worst pits of design hell. still managed to gently caress up a lot of stuff, but apparently people are still using it! on halloween do the trick-or-treaters come by your house dressed as locks
|
|
#
?
Feb 1, 2024 03:22
|
|
|
Visions of Valerie posted:on halloween do the trick-or-treaters come by your house dressed as locks they dress up as science jobs that use mmap and work on different pages but have a fencepost error in their page splitting so there’s a 1-byte overlap in lock ranges and actually I would sort of be down for the AWOOGA alarm at this facility that means “criticality” because the author of the simulation in question denies that there’s a bug
|
|
#
?
Feb 1, 2024 04:10
|
|
|
"i want Fart.txt and fart.txt to be different files". this is why unix-brains shouldn't be allowed to design anything that regular users can interact with
|
|
#
?
Feb 1, 2024 07:17
|
|
|
but then you have to decide how case-folding and diacritic-insensitive comparison works and that might require talking to non-computer people and maybe even making hard decisions when I wrote the SQLite collation functions used by Core Data my decision was to just punt to the OS and whatever it had established for the process’s locale, and just focus on minimizing allocations… which means you only got Turkish i vs ı rules applied when running in a Turkish locale, but at least it was consistent with everything else on the same system
|
|
#
?
Feb 1, 2024 08:24
|
|
|
Maybe that poo poo should be in presentation layers instead of in the kernel. I dunno, since I'm just some dummy nerd who has never spoken to a human being.
|
|
#
?
Feb 1, 2024 08:31
|
|
|
redleader posted:"i want Fart.txt and fart.txt to be different files". this is why unix-brains shouldn't be allowed to design anything that regular users can interact with now do "㶷.txt" and "𤈎.txt" should those be different op?
|
|
#
?
Feb 1, 2024 08:49
|
|
|
Just got off the phone with mom (a human) and she says that it is important that users of raw filesystem syscalls can take advantage of locale-aware case insensitivity, and that I should not expect all user-facing applications to use libraries that can handle case insensitivity for them. On the other hand I also asked the cashier (edit: another human) at the supermarket, and he says not to forget separation of concerns and the importance of semantic simplicity at the storage layer. Help??? How do I interpret these humans?
Athas fucked around with this message at 09:16 on Feb 1, 2024 |
|
#
?
Feb 1, 2024 09:03
|
|
|
fart simpson posted:now do "㶷.txt" and "𤈎.txt" should those be different op? im leaving that in the well-qualified hands of the unicode committee
|
|
#
?
Feb 1, 2024 09:11
|
|
|
redleader posted:im leaving that in the well-qualified hands of the unicode committee did u know: "F" and "f" are also different unicode code points??? U+0046 vs U+0066. seems like you have some growing up to do.
|
|
#
?
Feb 1, 2024 09:13
|
|
|
redleader posted:im leaving that in the well-qualified hands of the unicode committee yeah, it is all non-trivial, but unicode for one gets you a well-considered specification of at least a way to do it. afaik unicode case folding considers 㶷 and 𤈎 different, but if you want to make a blanket decision i believe there's tables for the full han unification effort available. e: yeah, case folding is a real short list comparatively https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt, but not the only bit unicode offers.
|
|
#
?
Feb 1, 2024 09:17
|
|
|
Cybernetic Vermin posted:yeah, it is all non-trivial, but unicode for one gets you a well-considered specification of at least a way to do it. it considers them different because they made a mistake
|
|
#
?
Feb 1, 2024 09:17
|
|
|
fart simpson posted:it considers them different because they made a mistake right, but presumably then they are normalized in the unification tables. like, it is not the simplest thing in the world to do full unicode with these things, but the info is there if one wants to use it.
|
|
#
?
Feb 1, 2024 09:23
|
|
|
eschaton posted:but then you have to decide how case-folding and diacritic-insensitive comparison works and that might require talking to non-computer people and maybe even making hard decisions everyone just looooves locales. Who doesn't love locales? You can have hours of fun with locales when figuring out why the file from your computer cannot be read on Bob's computer.
|
|
#
?
Feb 1, 2024 10:53
|
|
|
lucky that microsoft offers both, either you get proper filenames and a structure readable by humans, or you open files by guid which gets you the uniquely identified file no matter where it is located (including network shares).
|
|
#
?
Feb 1, 2024 11:03
|
|
|
|
| # ? May 24, 2024 15:59 |
|
|
why not have the real file name and file display name be different things no problems
|
|
#
?
Feb 1, 2024 11:12
|
|
