> > Imagine being able to unzip a build of your software to a blank windows/linux server and expect that it work flawlessly 100% of the time, regardless of any prior/lack of configuration or other supporting dependencies on that machine
> 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.
> One big argument for Docker is no dependencies, but Go and C# already can create fat native binaries that have no dependency on anything else (no .net framework or even VM, all native, same thing in Go). I believe Rust too offers the same thing. There is no excuse with all those different languages all supporting that.
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.
Well, the conveniently indicated grams on the packet are not units of weight - they're units of volume. So you've got two kinds of units of volume in your recipes: milli/centi/decilitres, and grams of butter. But it's fairer than the grams of flour I've been ranting about elsewhere here because at least the manufacturer can have some responsibility for fine tuning it to their product!
Well, tell that to Europeans, who don't use millilitres to measure their flour or sugar by volume - they use bizarre units of volume called "grams of flour" or "grams of sugar". Check their cup measures! It's crazy.
Apparently it works perfectly fine for household cooking to use units of volume for flour and sugar. Close enough is good enough!
Australians, Indonesians, Germans all measure recipes with two kinds of spoons (!). Australians also use cups (that are 10-12 mL bigger than American ones); other countries may too.
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.
Why will Virgin be treated differently than Ansett? (I was pretty young when Ansett went bankrupt, but Virgin's reputation seems to have been "trying to be Ansett and make a duopoly again".)
Oh, another of Apple's hidden features. Once upon a time, one button mice were a feature so that features weren't hidden and even beginner users could quickly become power users.
In the days when computers were places you stored your data, ROX was great. It was the first GUI that made me manage my files using a mouse. Nowadays, computers are mostly glorified web browser containers. And the way Gnome is so integrated into itself now means you can kinda either use a good window/session manager and Nautilus (with a good file manager on the side), or a crappy window manager, no session manager, and a good filemanager.
(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.
Well for many programs there isn't really any separate designer, particularly for line of business apps. That was really where I was coming from - the person who designs the app is simply someone who was trained in coding.
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.
Yep okay, so I guess that's not inline by my definition (since it overlays the text). I have definitely seen webpages that change the size of the containing box to add in the confirmation message and buttons.
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).
You're radically misunderstanding that definition.
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.
Yes but have you seen software - almost anything that's been developed since the growth of mobile platforms has basically done the exact opposite of what that field of science teaches.
> Come on, we're all adults here. We can take a few 90 degree angles.
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.
Yeah I think nowadays a lot of people think "modal" means "a dom element positioned with respect to the viewport that prevents interaction with the rest of the webpage".
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.)
That isn't actually true. I think I have UI experience, but I would actually have preferred some mockup examples instead of 1 bit bmp pseudo-thumbnails to represent his ideas. Surely it would be better to show some good user interfaces.
Since you deny a weird context switch for your eyes, are these actually inline elements? That would imply the size of the containers is changing. Which would surely be a weird context switch. But at least I can have no doubt what my action is about to affect - I get frustrated on sites when it says "you're about to delete these items" and i have no idea whether it agrees with me about which items I'm about to delete or not.
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.
> 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.