spoiler

made you look

  • 0 Posts
  • 166 Comments
Joined 2 years ago
cake
Cake day: July 27th, 2024

help-circle



  • The idea is that it’s left up to the windowing toolkit itself (.e.g GTK or Qt, etc.), so the compositor can focus on just compositing, which makes sense IMO as it’s how other platforms handle it (Except they have a single OS provided windowing implementation). Problem is, that leads to massive fragmentation of functionality, every app has different toolbars and features based on the toolkit they use, and requires each app to handle it, which sucks and shouldn’t be the case.

    Like in the Factorio case, it uses SDL for windowing, and SDL actually supports handling titlebars itself. But Factorio just wasn’t including the dependency that enabled it at that point, so all it took to fix it was including it and everything started working. But that’s still extra work that had to be done just to get minimum functionality, which wasn’t needed on e.g. KDE.

    I mentioned in my other response, it’s the inflexibility that’s the actual problem. Lots of apps do want CSD, or at least control over how their windows are presented, but Gnome going “you’re on your own” is the worst outcome.





  • What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed.

    Other way around, you can convert a “web safe” JPEG file into a JXL one (and back again), but you can’t turn any random JXL file into a JPEG file.

    But yeah, something like Lemmy could recompress uploaded JPEG images as JXL on the server, serving them at JXL to updated clients, and converting back to JPEG as needed, saving server storage and bandwidth with no quality loss.



  • Can you explains the knitpicking? They specifically decided that only objects orbiting our star can be Planets. It wasn’t an oversight but intentional. How can that be explained? Why do that?

    Because we’re not going to be visiting any exoplanets anytime soon, so it’s not like we can actually check how much they’ve cleared their orbits.




  • They’re called “selections”, the main ones being PRIMARY and CLIPBOARD, and it’s effectively a form of IPC mediated by X. When you select something, that goes into the PRIMARY selection, while when you copy something, it goes into both PRIMARY and CLIPBOARD.

    The problem is that “middle mouse click” isn’t actually paste, it’s “insert primary selection”. As long as they’re in sync you won’t notice any issue (Ctrl+V and MMB will both insert the same content), as soon as they’re out of sync you’re suddenly exposed to an implementation detail of the X11 protocol.

    And it’s easy to go out of sync, simply copy something and then select unrelated text, now Ctrl+V and MMB will output different things. It can be useful, e.g. if you’re having to copy a bunch of different pieces of text from one window to another, you can simply select and MMB, no keyboard needed, but it’s not intuitive IMO, and conflicts with modern usage of the middle mouse button (Get it wrong when trying to open a link in a new tab and you’ll dump whatever text you last selected into the site instantly)

    Also, these selections aren’t a thing under Wayland, it’s been re-implemented as a normal paste operation there. The question is actually whether the middle mouse button should be treated like any other mouse button or have this special behaviour by default. My vote is to expose it via the mouse settings applet and leave it up to users, like any other special mouse button.