Nick Coghlan writes: > they're available? Or even a separate OS field with "Windows, Mac OS X, > Linux, *BSD, Other" as the options? XEmacs has a multilink field "platform". The default is "Any or all" (mislabeled N/A), and values include hardware (currently x86, PPC, other), OS (POSIX, Windows NT), and GUI (Windows, X11, Carbon, TTY[sic]). Multilink means you can have as many as you want, and no attempt is made to enforce "one of each" or anything like that. I don't know if the distinction between OS and GUI is as important for Python. And "platform" is rarely useful for us -- platform bugs tend to be spectacular things like build breakage or crashes, and so get attention from a much wider circle than just the platform specialists. (Especially since the guilty party is usually a nonspecialist who never heard of that kind of dragon before.) So I can't really offer a pile of relevant experience, but it seems like a good idea.<wink> > While there is some Windows and Mac specific code, treating them as > separate components seems fairly unintuitive. Not always unintuitive. There are some features only available on a particular platform, then "component" sort of makes sense. OTOH, there are some bugs that are only available on a particular platform even though the code is generic. There "component" isn't very intuitive. In theory, I could see having both the component and the platform fields, but probably that would require too much user education to be worth it.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4