gindely
> I mean, that's basically _why_ Docker exists.
It is, but Docker isn't it. At the least, Docker won't run side-by-side with Virtual Box on Windows, so "regardless of prior configuration" is not met. In general, Docker adds an extra dependency on top of a blank system: Now you need to get Docker set up and running first, and then you can deploy your app. The alternative in question is about controlling the build to such an extent that you can reliably deploy the artefacts onto any system without having some runtime environment prepared.
Using Nix, you can build a self-contained deployment for just about any language/rutime you can imagine, and the target machine doesn't need to run Nix.
Apparently it works perfectly fine for household cooking to use units of volume for flour and sugar. Close enough is good enough!
I wonder if the ideal country where no-one uses units of volume other than litres and millilitres actually exists.
The really bizarre units of volume are certainly the ones I've seen in Europe - where you get measures marked in "grams of flour" and "grams of sugar". I suppose no-one has ever asked for a hundred grams of sugar of flour, but I'm tempted to every time I see one of them.
(In the olden days I had Sawfish set up so that it had a button that would take a look at the path it displayed or interact with the app via whatever scripting it provided, and show the active document in the ROX. Ah, so great. Sawfish is, nowadays, too primitive for me - I want an expose style feature to find my window.)
I still like to switch to ROX to rename or move files in my codebase rather than do it in IntelliJ. I had a plugin for that for a while but I never quite got around to setting it up again on some migration or upgrade or something. Nowadays it's only VIM/gVim that responds to F12 and shows the document location.
I have given some thought to porting it to Gtk3 and Gtk4. I guess getting an infrastructure around it isn't going to happen - but the Filer was the centre.
In any case, as I said, you get a problem if the person who designs the app is simply someone who was trained in coding, and you get a problem if they're simply someone who was trained in art.
I guess it's an between case I didn't consider - it's maybe not modal with respect to the whole app, but it seems to be modal with respect to that one comment (you can ignore it and do something else with the rest of the program, but with that comment, you can't even read it).
It has to do with the notions that are expressed by "can, should, might, must, has to" etc. These words (most of them are called "modal verbs" in English) modify a proposition in such a way that they do not mean it happened/happens/whatever, but qualify it, or indicate its possibility etc. So "he's going out now" is a proposition. "He can go out now" modifies that proposition - no longer are we affirming it, but merely affirming the possibility or permissability of it.
Nothing about "are you sure" is modal. A modal dialog is called modal because the mode of the program has changed - no longer can it accept requests to delete articles or add text or modify an avatar, but it is now in a mode when you can either say "delete this" or "don't delete this".
In particular, if you showed an inline prompt that says "are you sure? delete/cancel" but still allows you to interact with the rest of the system, it's not modal.
This seems to confirm the op's point.
I know that 90 degree angles on webpages are not more dangerous for children, parents, adults, or any other known subcategory of humans than for any other known subcategory of humans, but ... lots of people who use webpages and dev tools are actually children.
Didn't a lot of us get started as kids?
Have we collectively forgotten the olden days, when to print something, the solution was to ask the neighbor's next door kid? (who was probably you). Printers aren't any easier to use today than they were back then, but I guess that practice is over nowadays.
The classical sense of "a collection of related controls that prevents interaction with the rest of the application (however the collection, controls and application are implemented)" is surprisingly rare now, particularly since the older sense were often called "dialogs" (and indeed, "modal" was short for "modal dialog") - intended to emphasise that this was communication between the user of the application and the developer of the application to decide how the application should behave.
Therefore, a modal dialog should be used when the communcation couldn't have happened before and cannot happen later, and the developer of the application cannot do something intelligent and allow the user to correct it later on. (For instance, just delete the thing and let them undo it - no interaction between the developer and the user actually needs to transpire.)
But if they're overlaid elements, like a context sensitive menu that contains two options - delete, cancel - is there any substantive difference between a menu and a modal? The main advantage of a classic menu over a modal seems to be that it has a implicit cancel option that is uniformally implemented. But nowadays, menus are implemented without toolkit support - yay dom, yay - so even that is not consistent.
And many designers are artists ("designers") not ux engineers, so their main goal is to make something that shows their artistic skill - they're going to be trained in design packages, not designing a good ui.
(I mean, when was the last time you saw a clickable button on a modern user interface? nowadays it's just "guess what this shade of grey means")
However, I have use ROX for a long time - called RISC OS on X - it is/was basically a file manager based around RISC OS, as well as some associated desktop technologies (like app directories). I think it's fair to describe it as a dead as a doornail (I just upgraded to Ubuntu 20.04, and since it no longer comes with pygtk2, various tools are dead). Some of its innovations found their way into other Linux desktop technologies, such as shared-mime-info.
But if you want to see what once was, it's a place to begin.
(ROX was actually a lot nicer than RISC OS, when I finally installed it on my RPi.)
Still discovered the hard way that I needed an ergonomic keyboard. I use a kinesis advantage, but frankly a Microsoft one will do. It just needs to be enough.
Also major factor: Switching away from a mouse. Every time I've done full time work at a computer (i.e. when I'm not studying), I got wrist pain.
Switching to a touchpad is tiring for the fingertip, since it's not designed to drag on a surface all day.
But switching to a trackball has been a fantastic choice (six or seven years ago by now - some kind of red Kensington ball). I think there's so much more choice in using a trackball than a mouse or a touchpad, since it can be operated with the fingertip or the hand, and it's trivial to operate it without bending the wrist badly.
I got the ergonomic keyboard before the trackball; but the trackball made an almost instantaneous difference, whereas the keyboard only makes a cumulative difference - nowadays I can use a straight keyboard temporarily (e.g. if I want to go somewhere and use a laptop, I can, even for weeks at a time) but I wouldn't want it fulltime.