To be fair, this is partly because of the internet.
If you install random apps and it destroys your PC, you can fix that by having backups. By contrast on work computers with important data, everything is supposed to be locked down and you can't install random apps. But then we started to increasingly connect devices to the internet.
Now gaining access over a smartphone essentially means being able to send payments via the banking apps. People are sending money with crypto so they are susceptible to simple clipboard swap attacks that are almost impossible for the user to detect until it happens. Then there is all the personal data that can be stolen that can be used for other attacks in the future.
Essentially the amount of damage you can take by losing access has increased much faster than the security devices meant to prevent.
To make matters worse, the security devices that are marketed to the average user tend to be exploitative rather than trustworthy (e.g. OneDrive).
It feels like instead of protecting users developers seem more interested in creating something that only does half of the job and then blaming the user for not knowing how to do the other half, so a comprehensive solution for the problem is never created.
I think there are a lot of things that users can be protected from:
1. Protect users from attackers external to the computer
2. Protect users from attackers who are other users on the computer
3. Protect users from applications run by other users on the computer
4. Protect users from applications they themselves run on the computer
5. Protect unprivileged (non-root) users from their own actions
6. Protect privileged (sudo/root) users from their own actions
OSes have been historically OK at 1-3. Not great or even good. There have been a lot of remote code vulnerabilities and local vulnerabilities over the years.
OSes have pretty much ignored 4 until maybe a decade ago, and are making token progress toward it, but I don't think many of them take it very seriously.
OSes have instead started to crack down on 5-6, which I'd argue isn't even the job of an OS.
Most agricultural plant had a "Lucas key" [1] which meant you could use any key to start any machine.
I used to have one on my house keys long after I actually needed it, kind of an agricultural/industrial shibboleth. It's also how many many years ago I came to be drink-driving an eight tonne excavator through streets of Glasgow at 3am, with some rather grateful Strathclyde Police traffic cops keeping my way clear, but that's a whole 'nother story.
I used to have a keyring with the dozen or so different keys we have for network and equipment cabinets. One day I left it at home, and when I got to site realised that the cabinet was almost certainly one of the ones I didn't have a key for anyway.
I pulled the thin stainless strip out of an old wiper blade I'd thrown into the boot of my car to put in the bin later (and six months later, still had not), chopped two lengths of it, bent one into an L-shape and filed the little notch at the end of the other a little deeper and rounder. At some point muuuuch later I welded a little stainless washer to the ends of them both to put it on a keyring.
Yes, it was quicker and easier to just rake the wafer locks in the rack than find the right key.
Either take some responsibility and properly evaluate what that convenience means for you long term or don't complain when they leverage that vendor lock in at your disadvantage.
I wonder at which point do children become such a liability for platforms that it's easier to just ban all children altogether.
Children don't have disposable income to buy ads/subscriptions. They don't have experience to write about. The only thing they have that adults don't is time which translates into engagement metrics.
In an ideal world, the adults that buy/manage the computers would create age-restricted account for children, and the OS would give this information to the browser, which would just transmit it via HTTP. This is the safest method to verify ages. If an operating system doesn't want to support this, it's ultimately the adult's responsibility to install one that supports it. This would mean there would be no burden on the adults (the majority of the planet) to verify their ages, so there would be no burden on the platforms to restrict ages either.
If platforms could verify ages without inconveniencing their main user base, I wonder if platforms would just start banning all minors, or if there is some reason to allow minors in the platform that justifies all the liability surrounding them.
I guess you are right. I assumed that something like Youtube Kids would have no ads at all given the audience, but it seems it does have ads targeted at young children. Bleak world we live in.
Nobody takes “age-restricted account[s] for children” seriously.
Parental controls and age-restrictions are almost universally half-baked, buggy fig leafs to displace negative attention from software and content providers.
Jesus Christ finally. I'm not joking when I say that the old text tool wasn't simply bad, it was THE WORST text tool I ever used. If you had a dark theme and made the text black, you literally couldn't see the text you were editing!
I believe the last feature Krita needs to become a decent design tool would be fixing the layer styles so you can add the same style multiple times to the same layer (and if possible better bevel and 3D text tools). An immense number of designs are not much more than multiple strokes or "slightly" 3D text. Multiple strokes can be done in Krita in a very complicated and impractical way (you can do it by adding the layer style to a group, but with too many strokes the rounding errors make the outer strokes "flat," so the "correct" way would be to add the largest stroke first and then use clones to add the inner strokes). Photopea (a free online editor) supports both of these.
My opinion is that Krita has a tremendous amount of potential to serve a free and open source application for several niche use cases, but it's routinely held back by lacking "that one feature the user will need." Probably because everyone still thinks it's just an application for illustration and can't be used for image editing or design.
Animation is probably the most obvious one. Krita has an entire curves-based timeline editor, but the integration is so poor that it can only be used to animate opacity and the simplest type of transforms (translate, rotate, scale). That's an incredible waste considering it has cage transform, perspective transform, etc. All the non-destructive filters already have the code to serialize their settings to XML and back, but somehow those settings can't be animated? The liquefy transform, by far the most powerful, can't be animated. If transform masks had opacity and you could animate that, even that could be extremely useful, but they don't so they can't be animated in general.
Layer styles are another integration problem. Many users don't know they exist because they're hidden in the context menu. Krita already has filter masks. It doesn't even need a separate UI for layer styles, the styles could just be filters instead, then they would be able to get drag-n-dropped around and you could add multiple of the same to a single layer. Apparently this is because they want compatibility with Photoshop, but you could just convert Krita filter masks into Photoshop styles in the save step, so I don't really understand the problem. Naturally if the filter settings ever became animatable, that would mean layer styles would NOT be animatable in virtue of them not being filters, which would suck a lot.
By the way, I haven't tested the new version yet but Krita ALREADY has a color overlay layer style. So it looks like they simply... duplicated a feature they already had? Also the UI looks very similar to Clip Studio Paint, but a key difference in CSP is that single-color layers use 8 bit pixels instead of full 32 bit RGBA. I'm afraid this UI I'm seeing in the video is going to mislead some users into creating dozens of 32 bit layers with color overlay for easy color management and then end up with much worse performance than they would have in similar software. It also seems the color overlay "mask" behaves in a way that is completely different from literally every other mask in the software. I guess I'll have to download it to know for sure.
Edit: by "3d text" I sincerely don't mean more than WordArt level stuff. A lot of text for mobile games is very basic "curved text + vanishing point 3D + multiple strokes." Krita also lacks a "long shadow" style (i.e. infinite shadow instead of a drop shadow), which is common in a lot of designs and that GIMP has.
Most of the transfors you describe are still unfortunately destructive (ie the only way to go back is to undo). I'm not an expert on this, but I think the only way this could be key framed would be to take snapshots of the pixels and insert the modified raster data as keyframes? I'm not sure there's a good/correct/obviously way to interpolate betweens say a before and after liquefy operation the way it currently works. Maybe some of them coul store brush+inputs (pressure, cursor movement, etc) but that seems difficult to work with as an artist. Again, not done much animation (as a dev or artist) so maybe I'm just out of the loop completely
But yeah I agree with you in principle though, it would be nice if these were non-destructive and could be keyframed.
They are all non-destructive in Krita. Just use a transform mask and go to tool options, select liquefy and after you liquefy however you want you can just hide the transform mask and it stops liquefying the layer.
Yes, Krita has had this feature for years. Non-destructive filters (adjustment layers), too.
GIMP still doesn't have it. Only in 3.0 it got adjustment layers for filters.
Oh, this is news to me! I've used Krita to pain (recreational noob, not on a professional level) and I never realised this. I'll play with this tomorrow
In my view, the problem isn't specifically reactivity but the fact that reactivity isn't actually native of the UI toolkit.
Instead of HTML, think about GTK or Swing.
To add React-style "reactivity" to it, instead of just making a dialog to change the "title" of a document and committing the change when you press OK, you'd need a top-level "App" class that holds all the state, a class for state properties with IDs accessible at runtime which probably would be a variant (accepts any primitive type), a binding class to bind the toolkit's textbox to the App's state "title" property (because you'll probably want to bind a lot of textboxes, so it's easier to separate the code into classes), and then every time the user types something into the textbox, instead of using the toolkit's code that is already written for you which updates the textbox' state directly, you block the state change in an event handler, send the state change to the App class, let the App class figure out the differences between the current state and the new state, and then it calls some callback in the binding class that is responsible for actually changing the text in the textbox to reflect the new App state. You'll probably run into a ton of issues (selections resetting, assistive technologies bugging, etc.) that you'll have to deal with externally somehow. All just to make it do exactly the same thing it would have done anyway.
It's like you have a fully autonomous robot and you want to add marionette strings to make it move.
I believe every UI developer that has used frameworks like Swing has reached a point where specific user interfaces, even those that look trivial, become too complex primarily due to things like event handlers. Trying to figure out a simple thing like why a radio box is enabled and is marked dirty may require long debugging sessions where one event handler for component A triggers another event handler for component B, which triggers another event handler, etc. And before you know it, 50 events were triggered just during the initial mounting of the UI. Making sense of it all is maddening.
And then said developer does what they think feels right: "I have my state and I simply want all the fields to reflect my state". So they try and rewrite the component into some sort of mini immediate-mode style component. All of the event handlers get wired up a single "layoutComponent" method that tries to call all the UI component setters based on the current state with all the problems you alluded to. I know I've done this type of things numerous times before going back all the way to my first internship, well before React was even a thing.
I think modern frameworks solve the reactivity issue this well enough, that it really doesn't matter if the underlying framework is not natively reactive. I will say though that I've primarily used Vue.js where most state is relatively local and we don't try to re-render the world on every input. I think part of the problem with modern dev is likely that React has become the default instead of a simpler framework like Vue.
That's true. Events are the WORST thing about GUI programming. They're so convenient and so undebuggable it almost feels like a trap.
Ironically, in most cases events are only used by one object, but you always want to consider the possibility that two objects will want to observe the same event, so now you need an entire event dispatching class, and then you'll want observable properties, and the nail on the coffin is going to be observable lists. When you reach that point, one event triggers another, which changes a property, triggering another event, and so on and so on. You are 5 layers deep into event callbacks. The call tree just has the same "callCallbacks()" method over and over again.
Bugs start happening because of the order in which callbacks are called becomes important, so now you need a way to give some callbacks priority over others, or make them happen after all normal callbacks were called. One callback destroys an object which has callback on the event that destroyed it, so you're going to need a wrapper around your callbacks that gets notified when callback's object is destroyed to change its reference to null in order to avoid executing code on the destroyed object if this happens while iterating the callbacks in the event dispatcher. Sometimes calling callbacks in wrong order is a performance hit, when it doesn't just get stuck into an infinite loop and you run out of stack.
I wonder if there is GUI programming paradigm that solves all of this or that you can call the "best" one. Maybe it's reactivity, maybe not. Who knows.
Reskin isn't quite right. Vivaldi offers a ton of amazing features that Chrome would never dream of having. For example, tab tiling is excellent and criminally underused.
Switching tabs doesn't work like you would expect in Opera for example. The order of tabs gets shuffled randomly. It's completely broken. I downgraded to a version where it had worked, stuck with that for a while. When I complained about it people usually say "just use it like chrome where you can't switch tabs properly anyway lol". It was reported with the precise version that broke it. Vivaldi team asked maybe twice on social media, but then it was just tumbleweeds. It's 100% reproducible with a clean install, on both windows and osx. I gave up and preach for people to just stay away from that browser.
Thanks Chrome for ruining web in yet another way. LRU is THE default for virtually every windowed and tabbed application, then Chrome comes and fucks it up. Now we have a video talking about a "fix", and likely not a single user in Vivaldi even using the default (because they would notice it's broken). Kinda hilarious.
If you install random apps and it destroys your PC, you can fix that by having backups. By contrast on work computers with important data, everything is supposed to be locked down and you can't install random apps. But then we started to increasingly connect devices to the internet.
Now gaining access over a smartphone essentially means being able to send payments via the banking apps. People are sending money with crypto so they are susceptible to simple clipboard swap attacks that are almost impossible for the user to detect until it happens. Then there is all the personal data that can be stolen that can be used for other attacks in the future.
Essentially the amount of damage you can take by losing access has increased much faster than the security devices meant to prevent.
To make matters worse, the security devices that are marketed to the average user tend to be exploitative rather than trustworthy (e.g. OneDrive).
It feels like instead of protecting users developers seem more interested in creating something that only does half of the job and then blaming the user for not knowing how to do the other half, so a comprehensive solution for the problem is never created.