1. Don't have a dependency on hyprlang. Other projects will probably be averse to that. Use a more common configuration language, using a common library.
2. Have a shim layer so that hyprcursor cursors can be used by applications that use the XCursor API (maybe have a drop in replacement library for libxcursor that delegates to hyprcursor).
3. Have a specification so other implementations can use the cursor format as well, in case other compositors/clients don't like your implementation for some reason.
It should be noted that the author is the creator of hyprland/hyprlang, so perhaps not too surprising that they made it a dependency, although I do agree with you.
> 1. Don't have a dependency on hyprlang. Other projects will probably be averse to that. Use a more common configuration language, using a common library.
*.desktop files are at most ini-like, they have a different specification that does not mention "INI" at all. What did formerly_proven refer to when saying "XDG ini"?
The article essentially says--whether this is a good idea or not--that GTK is the one hold-out, which I wasn't really expecting as a punchline; why is GTK not implementing this?
It's a wholly expected punchline to anything wayland: by most accounts Gnome is one of the worst offenders in the death-by-comittee wasteland that is standardising protocols in wayland.
Maybe it can be found under other terms of course, but all I'm saying is, before picking up the pitchforks, maybe it'd be worth asking if they'd just accept an MR. Yes, I know many (myself included) are not thrilled with GNOME's approach to Wayland, but it's not going to be any more productive to just assume bad faith, at some point you just gotta push forward.
If GNOME does anything I personally don’t like it’s usually the result of a grand conspiracy by Red Hat to make the Linux desktop worse, increasing their consulting profits. (/s)
> grand conspiracy by Red Hat to make the Linux desktop worse, increasing their consulting profits. (/s)
I must admit, I have wondered about the plausibility of this in the past. It seems like ironically, making a problem-free Linux would be a conflict of interest to Redhat, which makes more money the more problems it has.
Is there any particular reason you think it couldn't be the case? I could definitely see it within the realm of possibility, especially since they maintain a huge chunk of the ecosystem nowadays (Fedora/RHEL, GNOME, LibInput, Kernel development, NetworkManager, Pulseaudio/Pipewire, Systemd, Wayland, and probably even more in the future.)
Because just factually Red Hat isn't working on many of these things alone. Most of these project have huge interest from many parties. And all those parties work daily with Red Hat and somehow the conspiracy remains undetected. The idea tat Red Hat corporate overlords can easily hurd the Gnome developers just isn't how the project is set up.
Many of the contributes to these project, even when being employed by Red Hat don't always do this as their primary job, many do it because they want to. It just so happens many people that love the linux ecosystem and linux itself work at Red Hat.
Other then that, many project that are very unifying and don't create much 'conflict' are also lead or worked on by Red Hat people. Pipewire for example has been the opposite of 'conflict' for the most part. LVFS is another good example. Flatpak/Flathub are another great example (Maybe Ubuntu is the evil agent of chaos). Systemd is also almost universally adopted by ever major distro even if it created much conflict.
Somehow people can't decide if Red Had is an evil dictator wanting to control everything or if they are deliberately creating 'conflict' so nobody is in control.
The simple reality is, there are a huge amount of people with incredibly different opinions in the Linux space. Even different people employed by Red Hat also don't always agree with each other. So who is really the true Red Hat conspiracy agent?
Difference on opinion is fine as long as people work on their own stuff, but when it comes to unification, like Wayland protocols it just gets really hard. The reason there is KDE and Gnome is because of fundamental disagreements about goals and that will be reflected in how they think wayland properties should be installed.
P.S:
> making a problem-free Linux would be a conflict of interest to Redhat, which makes more money the more problems it has.
What is your actual evidence for this statement? If that was true, why are they working on all those projects. Objectively things like Pipewire, LVFS, Flatpak, Systemd have been major improvements to the ecosystem.
Gnome and Wayland (among other things) are the way they are, in part, to make running anything other than a standard-package-selection Red Hat unappealing to folks who might pay for Linux (enterprise). It’s good for them if their stuff’s a bit broken if you use other distros, or configs/software they don’t want to support, and if they cause integration pain and extra work for other distros.
Or if that’s not the reason, the behaviors of a lot of projects RH birthed or heavily influence make a whole lot more sense if you assume it is and are fairly lacking in explanation otherwise. If it’s not the case, they’ve managed to accidentally do something that’s in their interest, I guess.
I think it's just a standard corporate insularness. Devs being paid to work on the software by the corporation view outsiders as a nuisance and certainly don't like outsiders giving them more work to do. They'd rather find justifications to remove features reinvent old systems to "reduce legacy cruft" (make their jobs easier.). Basically, it all makes sense if you assume standard commercial developer motivations.
Fornunately with Free software that doesn't matter too much because anyone can add a feature and if you don't want to accept it people can go to the other person's implementation instead.
I mean, isn't that how Cinnamon and Panteon and Unity and Cosmic and MATE were born?
It's a great strategy for sure. If I were running a software company that depended on software licenses and consulting fees for income, and I had to keep my stuff open-source, then what you outlined would be the best (and really, only) strategy for long-term survivability. It's a moat, and a good one, because it's plausibly deniable.
So why don't people just stop caring what gnome thinks? Can't they just standardize the stuff regardless of gnome "holding out" on them or whatever it is they're doing? Do they need their permission or something? Just leave gnome behind. Doesn't really matter whether they catch up or not.
> So why don't people just stop caring what gnome thinks?
Because Gnome is RedHat and ...
1) Because RedHat is one of the few companies that puts sustained, long-term funding beind developers working on Linux. As such, they get an outsized say in what goes on because they are doing the work. If you would rather that Linux go a different direction, fund a bunch of programmers and take it that way.
2) RedHat put in the work, time, and money to get certified in ways that allows it to be used for big business. That means adhering to things like accessibility, auditing, etc. If you get the same certifications, big business accounts can use your stuff instead.
If you want people to ignore Gnome, all you have to do is fund a bunch of Linux developers to do all the work they are doing. Easy peasy.
Well to me it sounds like a lot of other people also put in time and effort into making Wayland better, only to be consistently blocked by gnome/redhat at every turn.
It's not the first time I see people air their grievances like that so I gotta wonder why people keep working with them. Let red hat pay the developers to take Linux in whatever direction it wants. Other developers can go in some other direction that they agree with. The beauty of Linux is the kernel enables such a diverse user space. That's what I personally care about.
gnome folks are on the committees just like everybody else is. They don't have veto power in that way over the accepted standards, only in what they implement.
They actually do that. Consensus is a goal. But if it can not be achieved then at some point people will just create a protocol anyway, even if Gnome doesn't implement it. People who claim this isn't the case haven't actually followed the space at all.
Of course issues still get stalled on this, because it takes a while to figure out that the disagreement is to fundamental. Often a compromise is actually found in the end.
Ah we are rolling out the old Red Hat conspiracy nonsense again. Classic HN.
I'm sure that why they invested in Flatpak, they just really want it to make it impossible for people to run non-standard packages on Red Hat. Makes total sense.
That isn't really surprising to anyone who has been following how GNOME approaches wayland.
GNOME is also the one holdout that doesn't support server-side rendering of window decorations (like the title bar with buttons to close and minimize).
GNOME has pushed back on several wayland protocol extensions that all the other compositors supported.
They did that for a reason. Rendering decorations server-side is a really bad idea. Just because X11 did it is not a reason to repeat the mistake.
If other compositors want to do it, they have their optional extension for that. Eventually, they will find out why they shouldn't do it. With mandatory extension, there would be no way back, with optional, there is.
I've yet to see a good argument for why it's a bad idea. To me client-side decorations are mostly yet another way that the desktop is turning into a cluttered mess of different UI styles.
1) Synchronization: when you are rendering decorations in a different process that the window content, you never get frame perfect. You can't synchronize both processes for each frame.
2) When painting using two processes, you need two surfaces. You just doubled your VRAM usage and the amount of blitting you need to do.
Now, decorations are not only the window chrome itself, but parts of them are font rendering (Qt renders fonts a little bit differently than Gtk, you can see the differences) and popup menus (when right clicking on the window chrome). The menus are a difficult thing; they basically pull in the entire respective UI framework (theming, sizing, font rendering, ...). So you do not really have a choice of unified look with server-side decorations; you have choice with cluttered mess between apps using different frameworks, or cluttered mess inside apps using different framework than the one used to render decorations.
So, how the other operating systems do it? They won't allow you to connect directly to compositor in the first place. You _must_ use the platform library, be it Cocoa or Win32 in order to be able to get a surface that gets displayed. And since you are already linking these libraries, they will paint the decorations for you -- unless you override it. All that is client-side, in the address space of your application, in your message queue.
Now, Windows does have a server-side fallback, when you app is not processing the message queue. Then it will paint the system decorations, but since your app is not responding, any synchronization is passe anyway.
So how to solve this in Linux? You will have as many looks, as many apps decide that they do not want to play ball, that they are a special snowflake, that need to avoid the "bloat" of frameworks. The cluttered mess of different UI styles and the permanently broken state of everything is a price you are paying for them to be able to do exactly that.
Otherwise, you would be able to reduce the looks to two (Qt and Gtk). When things would go very well, Qt could do what it does on other platforms and use Gtk+ look. That's about the only way to get unified look.
I'm not opposed to having mechanism to opt in to client side decoration, but making it mandatory is problematic for several reasons:
1. Different apps will draw decorations differently, leading to a lot inconsistency.
2. It means apps designed for other environments that don't draw their own decorations won't have any decorations.
3. If your client doesn't use one of the big all encomposing gui toolkits (not every app needs that), then it has to implement the decorations itself, which is non-trivial to do correctly (I know because I have worked on it for such an app).
4. You can't reliably configure the appearance and behavior of the decorations in a central place for all applications.
Fuethermore, if clients always draw their own decorations, then if you use a tiling wm and don't want decorations at all, you are stuck with them.
2) Only if they use server-side decorations only. In Wayland, client-side is mandatory and server-side optional. So if they do not have decorations, they are broken.
3) You client should use one of the big frameworks. On other operating systems, they are mandatory anyway. Only Linux allows your client connecting to compositor directly. Use that power responsibly. Frameworks bring lot of stuff implemented for you. If you reject that, it is up to you to implement that yourself.
4) You can't even with server-side decorations either.
Yes, with tiling, you get them. However, many apps have toolbar there, so you need it anyway.
macOS cursors are provided by an NSCursor class which can either be one of the standard cursor image or provided through an NSImage object, which supports a number of data types (among the usual pixel-based formats like PNG or JPEG also PDF), it looks like applications can also register their own data formats via a class called NSImageRep.
Is displaying a few hundred KB of data on the screen really enough of a "problem" that it warrants putting image libs and potentially other dependencies in the middle of something as basic as cursor rendering?
Instead of SVG, I wonder if not the ideal format would be Haiku's Vector Icon Format (HVIF) [1][2].
It has binary files that are much smaller and it too supports multiple levels of detail for different sizes.
I heard somewhere that Haiku would use it for its own cursors, but my google searches for getting that verified have not been fruitful.
For many years the XOR sprite cursor was patented, but the patent seems to have expired in 2013. One of us should make the request to the GNOME/KDE/Wayland/DE people and link the expired patent:
EDIT: The linked patent seems to only cover 1 bit inversion, not full color inversion. I can't find the patent for the full color, but recall reading that a patent stopped the adoption of a nice color inverting cursor for Linux that Windows has had for so long. If Windows has had it for as long as you say, then perhaps any relevant patents have expired?
That patent is only for MSB XOR though and seems to be only for hardware. That's not the only way to do it if someone wanted to achieve the result of better visibility.
Surprised that Wayland would go the route of entirely deferring to the client for cursor rendering instead of providing a default implementation and exposing an api which client can use to assume control.
Wayland provides little by design, so this is quite typical. For example:
Screensharing is handled by pipewire [0], changing keyboard layouts aren't defined [1] by wayland, and generally anything Wayland devs think would 'corrupt' their protocol.
They leave most things to the compositor to implement, which leads to significant fragmentation as every compositor implements it differently.
Long gone are the days of xset and xdotool working across nearly every distro due to a common base, now the best you'll get is running a daemon as root to directly access `/dev/uinput` [2] or implementing each compositors accessibility settings (if they have them) as a workaround.
I believe the Wayland spec writers / devs themselves have admitted that due to how strenuous working on X ended up being for them, they erred too much on the cautious side and underscoped Wayland.
Rasters are annoying. Raster means an image is stored with pixels, for example a png, or an mp4. The problem with rasters is that when you resize them, the computer has to take a wild guess at what it should look like."
The problem with any display this software is going to run on is that it is also made with pixels. GTK foundation tried this approach for years, putting all their eggs into this basket, and recently having a reckoning and admitting this approach has not been working. Pixels are here to stay.
By this argument now that GTK supports directly rendering vector fonts sharply at arbitrary pixel densities we should switch back to bitmap fonts so GTK fonts can be bitmap rescaled again. I.e. the recent GTK reckoning you're referring to is actually about avoiding an extra raster rescale for exactly the reasons quoted, not about wanting more of it.
Why can't GTK be asked for the pixel size the display server needs instead of converting them to yet another vector format and rendering them on the display server?
The display server needs to be able to render the cursor or decide the cursor information even when no GTK (or other) apps are running. When it does so it needs to change the size of the cursor based on the display it's on. This size may not always be a whole number of pixels and may or may not change in the middle of a session. If you ever did cursor effects like macOS scaling the cursor on fast movement you'd need a way to handle that per frame size change request as well. In all it just doesn't make sense to move the logic for rendering the cursor into application frameworks.
I think it'd be best if "another vector format" was really "another cursor format which allows the actual cursor data to be tagged with a format". That way every time someone wanted to change the cursor protocol to allow compressed bitmaps or animated files or different vector formats it didn't require a whole new cursor file format to do it. Think something like MKV but for cursor data.
I've been experimenting with using Hyprland (a Wayland WM) on my laptop, and ironically Qt apps have been the ones that misbehave the most. Everything seems happy to use my preferred icon theme, but when hovering over a Qt app, the sizing greatly changes. I've mostly just gotten used to it (plus I never really got their overall theming correct) but I might have to try this out and see if it fixes my issues.
I gave Hyprland a try some weeks/months ago, and seemingly it had a video memory leak where after some hours of usage, it ended up taking more than 5GB of VRAM, with no signs of slowing down.
The thing I like about the Xcursor image format is that it so extremely simple[0]. Every semi-competent developer should be able to implement a parser/writer for the format in under an hour.
But encoding the images with PNG does make sense, given the wide availability of libpng and the potential file size savings. I don't know how the feel about SVG support. One the one hand using vector graphics for cursors seems like a great idea but SVG is a very complex format, with the only real parser available being librsvg, which massively increases toolchain complexity. Too bad PostScript doesn't support transparency.
Looking at the full description of the format, it includes the ability to use nested config sections with `{ ... }`, which has some obvious benefits for some use-cases. But for the complexity needed for defining cursors, I don't see the benefit of `.hl` over fdo `.desktop` configs. In fact, it looks like you could parse the hyprcursor `.hl` config files with a `.desktop` parser? Which might be more palatable for cross-desktop support?
Hmm, this leaves me with mixed feelings. It's obviously easier if everyone just adopts libhyprcursor instead of implementing a spec themselves and everyone having to iron out interoperability issues. Hyprlang doesn't look large, it's probably on the same order of magnitude as your average JSON decoder/encoder, but OTOH it's kind of a bespoke language versus other more "standard" options and I think this is likely to hinder adoption more than anything else. It's another "thing" whereas the desktop is already full of INIs, XMLs and JSON files.
Then again, I have no stake in the matter. I think if Vaxry wants this to be adopted though, dropping it onto the world like this is probably not the most likely case to get there. It probably would've been worth bugging maintainers for other compositors (kwin, sway?) to see if they had any input/thoughts on the matter. I can only imagine Hyprlang as a dependency would've come up immediately as a discussion topic (I could be very wrong though.)
This is a first-party package from the Hyprland organization. This is meant to be used by people that use Wayland+Hyprland and want a better cursor. I don't think the idea is to make the package itself attractive but to make the Wayland+Hyprland switch attractive by saying: look, here are all the things we do better, including cursors.
OK, but I am responding directly to the post itself when I say this. Specifically this:
> Will this ever be adopted?
> I don't know! All I know is that it's a clearly superior system that is easy to implement.
> The best path, in my opinion, would be to push for wp_cursor_shape adoption over at gtk. If gtk finally supports the protocol, almost all desktop apps that people might wanna use on Linux will be able to utilize hyprcursors via the compositor.
> Support from the toolkits themselves for hyprcursor itself is likely not going to happen, as hyprcursor is not made by a million-dollar non-profit entity via a 10-year-long bureaucratic process, unless somehow the developers over there decide it's more beneficial to use hyprcursors now rather than wait and develop their own, new standard. Who knows? :)
On one hand, I agree with toolkits simply adopting wp-cursor-shape. This makes a lot of sense, and unlike with the CSD argument, I don't really think it would place a particularly hard burden on Mutter to just implement this protocol.
On the other hand, though, if other compositors want a better solution than XCursor, they either have to adopt this or something else, or invent their own system. And Hyprland, by virtue of being a fairly popular and pragmatic Wayland compositor, will no doubt collect a fair number of themes in the Hyprcursor format.
And based on this particular wording:
> All I know is that it's a clearly superior system that is easy to implement. ... hyprcursor is not made by a million-dollar non-profit entity via a 10-year-long bureaucratic process, unless somehow the developers over there decide it's more beneficial to use hyprcursors now rather than wait and develop their own, new standard
This seems to suggest that Vaxry has:
- A belief that this really should be adopted, as a superior solution to cursor themes
- Some level of disdain for the idea that other developers might make their own standards instead of adopting this
Which honestly, is true... but that makes it all the more a shame that this probably won't happen for relatively unimportant reasons, meaning that likely, we'll end up with another cursor theme format later on that will be incompatible.
Not blaming them for not trying to do this as it seems Hyprland has mostly succeeded by simply blazing forward without gaining consensus, but there's a two way street to that approach IMO.
But if other compositor also used it, that would make it easier for hyprland users to use cursors that weren't designed specifically for hyprland. It would also be useful for apps that want to use custom cursor shapes (like, say, games).
> In the beginning of wayland, and in the core design spec, it's the client's job to draw the cursor. I mean, it kind of makes sense, as some apps might want to draw a custom cursor (e.g. games)
Wait what. That's even more insane than client-side decorations.
No, it's not the client's job to draw the cursor. The client provides a surface, the same kind of thing as any other window, and asks for it to become the cursor. The client draws into the surface, but the placement and drawing of this surface to the screen is done by the compositor (most likely with an overlay plane).
This allows the application to customize the cursor, which happens more frequently than you might expect, e.g. dragging and dropping a file changes the "cursor" to include the little preview of the file. So the client already needs to learn how to render cursor images to composite the cursor image on top of the DnD preview.
One of Wayland's original core philosophies is to share behavior by shared library, rather than by protocol, because social agreement is already required, and is way better for a community long-term. So there is also a libwayland-cursor library that allows you to load Xcursors, which allows the client to do all the compositing and customization it needs, while still supporting a standard.
zwp_cursor_shape makes sense for a basic client without too many needs, but it's not a great idea for a full toolkit, otherwise DnD dragging (or any other case that requires compositing cursor images) will show a different cursor.
The way I see it, it's a matter of who owns the chrome. Historically, we've seen that it is a losing battle to insist everyone uses your toys (e.g.: web input elements). I am not overtly opposed to keeping the protocol lean so long as there's a canonical and easy way to accomplish the basics.
Of course, because this is Wayland, one good idea suffers due to coexisting with other independently good ideas. The minds behind Wayland didn't want the protocol to ossify like X11 did, so they made extensions essential. If a given functionality doesn't need to be core, it's an extension.
Both great ideas in isolation, yet now, as a result, Wayland has trapped its ecosystem in a half-assed state of completeness. The one saving grace is that, unlike X11, things will actually improve over time as the gaps get filled in and older applications age out of the ecosystem.
Any other system has a cursor hide feature that games/applications opt into. Everything else should have the compositor overlay the cursor
This is particularly important because most applications aren't designed to render at monitor framerate, whereas games make an exception because they tend to be full screen applications & tend to render at a high framerate already
My understanding is that most modern games use the OS capabilities for drawing their custom cursor to the screen instead of just hiding it and drawing their own with custom code. The reason for this is that you don't want the cursor to lag when the game experiences delays or when the framerate is poor. Off the top of my head, Crysis was an example of a game that did this wrong, as the cursor would get really choppy in game menus when the framerate was poor.
This is inconvenient for someone writing a custom client as it is yet another feature to support, but it really doesn't matter for anything that involves framerates unless you start to change the cursor every frame or so. Normally you will just respond to events and it takes a bunch of work and it is irritating you have to do it, but it isn't computationally costly as it typically won't happen often.
Not the parent, but the problem is that applications that don't want to draw custom cursors are (or were except on gnome) still responsible for drawing the cursor. So instead of saying "i want a pointer cursor" when you hover over a link, you have to figure out what cursor theme the user is using, figure out what size you should use for the current screen resolution and scale, find the appropriate image for your desired shape, theme, and size, and render that to a surface. And hope you did all of that consistent with other apps the user uses.
Makes total sense to make cursors SVG, kind of crazy that nobody has done this b4 and that it's that outdated. Then yet again, handling SVG takes a lot more than some uncompressed images. So my question is how many resources, ram ... does it actually take to make some 200kb SVG as a cursor compared to some old uncompressed picture that might be bigger, but it's simply put on the screen 1:1. I guess it COULD be just about the unit process but if it's full SVG support than cursors can now be animated and be calculating all kinds of shit inside the SVG.
I would think hard before supporting full SVG, as it opens a can of worms. https://www.w3.org/TR/SVG11/script.html#ScriptElement: “A ‘script’ element is equivalent to the ‘script’ element in HTML and thus is the place for scripts (e.g., ECMAScript)”
Xcursor doesn't predate PNG. Heck, it came alongside a tool, xcursorgen, that could be used to process pngs and generate the binary cursor files. Xcursor appeared somewhere around 2002-2003 as an extension of Xrender. Before that X had monochrome cursors.
There are some legacy X specifics in the theme format that would necessitate something more modern. IIRC, Xrender used a hash of hard-coded X pixmaps to find the cursor files to match. That's why some of the filenames are a long string of hex digits. The rest are predefined X cursor names.
I think what X did is still the standard, which this article explains is pretty suboptimal. Sometimes crappy solutions stick around until someone pushes for something better.
Doesn't the CPU/GPU bottleneck which is already assumed to be slow actually provide the perfect opportunity for abstraction over a network protocol? Sending "what to draw" and "how" (shaders) over the wire infrequently and issuing cheap draw commands on demand? I think GPUs provide a better situation for a network first model than was available when X was designed.
Only if everyone agrees on a central rendering model & feature set, which simply isn't the case. 2D rendering is not a solved problem, there are many different takes on it. Insisting all GUIs on a given device use a single system is simply not realistic, which is why nobody actually uses any of the X rendering commands other than "draw pixmap" (aka, just be a dumb compositor)
Sorry, but I can’t take the suggestion that the PCI bus and the internet should be treated the same seriously. You’re telling 4 or 5 orders of magnitude difference. Maybe more on some specs.
It’s like saying you should use the same file access algorithms for a RAM disk and punch cards. No you shouldn’t!
> Xorgs decades of highly dubious technical decisions.
People like to say this, yet time and time again, X's design proves to be the superior one in the real world.
Some of it could use minor revisions (adding some image compression would be fine, etc), but it is hard to seriously say things are "highly dubious" compared to the competition.
I have that exact icon theme installed, so I went and checked, and you're right. Most of the cursors look to be in the 160 KiB range (which includes all the sizes together), with only the ones that include animations getting into the MiBs
Clients draw the cursor image, they don't render it to the screen or blit it.
Basically, in the "old Wayland way", the Wayland compositor gave the client a surface and said "hey, draw something into this and I'll make it your cursor" and then the compositor well, composited it, using either true hardware cursor or an overlay layer of some kind. If the app froze, the cursor would still move, it just might not be updated. This seems clean architecturally but turns out to suck because now every client needs some kind of cursor drawing library in it, hopefully the same one everyone else is using so that cursor theming works and you don't get a different default mouse cursor in every app.
So then Wayland introduced wp_cursor_shape, which is where the client instead says "hey, draw a 'standard pointer' cursor over me please." But, the "old" client-drawn way is still supported and used, for example in GTK apps.
This proposal seems to just be a really complicated recommendation to change the file format used behind wp_cursor_shape, and a plea for "old" apps to either adopt this format/library or stop using client rendering. I think that switching to wp_cursor_shape pretty much Makes Sense for most apps, but the article didn't really sell me on this file format.
It's a Wayland problem if it is really problem at all though. The author complains that XCursor themes take too much space on disk (They will live uncompressed in VRAM anyways). Considering we are talking about Megabytes in the age of Terabytes HDDs, as long as you don't want to install thousands of XCursor themes on the same machine this is really a non-issue.
> Considering we are talking about Megabytes in the age of Terabytes HDDs,
Most distributions still use a "Live CD" format, actually a "Live DVD" nowadays (with a few hacks to make it also work as a USB pen drive image), for their installers, and that limits the installation image size (which also includes enough packages for an offline install of a desktop environment) to a bit more than 4GB (they fit into a common 8GB USB pen drive). So it being the "age of Terabyte HDDs" does not matter, for packages expected to be installed on a normal desktop system.
Any USB drive is so super cheap these days, you can easily get something like 128 Gb for $15. Even if you live in an area where it’s not as easy (e.g. not very developed places), you’re likely to find, say, 32 Gb for less than $10. So I don’t know, maybe someone needs that 4 or 8 Gb limitation, but I believe it’s a non-issue in most cases.
Also, on top of that, we do have a very speedy Internet I’m so many places. Which means if you’re limited here, you can go with the net-installer. If you’re limited on both, more likely it’s a very niche case and you can have a spare large disk to download everything offline.
Not optimising things that "make no sense" is how we ended up with operating systems needing gigabytes of RAM just to boot, and AAA video games taking over 100GB each. A reasonably efficient system is the sum of reasonably efficient parts, or else you end up in UniformlySlowCode hell.
> So it being the "age of Terabyte HDDs" does not matter, for packages expected to be installed on a normal desktop system.
But neither does the "size on disk" because the ACTUAL size on disk might be reduced by gzip/bzip2/xz/zstd/whatever is invented later. Even if the program using the package doesn't support compression, it supports filesystems and filesystems often support some kind of transparent compression. It isn't a hard problem to solve.
1. Don't have a dependency on hyprlang. Other projects will probably be averse to that. Use a more common configuration language, using a common library.
2. Have a shim layer so that hyprcursor cursors can be used by applications that use the XCursor API (maybe have a drop in replacement library for libxcursor that delegates to hyprcursor).
3. Have a specification so other implementations can use the cursor format as well, in case other compositors/clients don't like your implementation for some reason.