Open DonKult opened 1 year ago
pktiuk
commented
1 year ago I am just toying with the idea of adopting the package in Debian
AntiMicroX is already adopted in Debian. There is an antimicro package containing AntiMicroX (but it is a bit outdated). AFAIK @mirabilos was maintaining that package.
I am far from my PC now and I will respond to your questions later.
DonKult
commented
1 year ago I am just toying with the idea of adopting the package in Debian
AntiMicroX is already adopted in Debian. There is an
antimicropackage containing AntiMicroX (but it is a bit outdated. AFAIK @mirabilos was maintaining that package.
Sorry, I was using Debian-lingo here which I probably shouldn't have… He orphaned the package earlier this year (like a responsible maintainer should) to officially denote that the package needs a new maintainer and to denote that anyone can come forward and adopt the package within Debian. The adoption is officially done by retitling the bugreport as ITA (intend to adopt) and of course an upload closing that bug. I am merely toying with the idea, as I just stumbled over antimicro(x) and my usage is rather minimal, so I haven't actually decided if I want to and/or declared my intend – or if I e.g. hope someone else will pick up the pieces instead.
pktiuk
commented
1 year ago Those are black-and-white and hence don't really fit with the rest of the icons, so I doubt they are from oxygen.
TBH I am thinking about getting rid of these icons (maybe put emojis in their place :thinking: ) because they don't look very well with dark themes.
That might alternatively be a good moment to choose all icons from a single theme (like oxygen) and run with it.
In terms of icons used by app, I am already thinking about updating them to something more modern and consistent ( https://github.com/AntiMicroX/antimicrox/issues/597 ), but TBH I lack some aesthetic sense, and I am not sure where I could look for a new, nice and consistent set of icons. And currently used oxygen does not look very modern/gaming related.
I am not much of a GUI programming person, but if I understand the code right these are all/mostly supposed to be fallbacks if the current theme doesn't come with its own icons of that name (but some are renamed like battery, so no?) … so mostly a Windows/MacOs issue as on Linux and Co. packaging could just depend on an icon theme like oxygen and be done with it, no?
You are right, most of these icons are just fallbacks used mostly by Windows.
In general you raised a lot of good points, most of which would be solved (I hope) by https://github.com/AntiMicroX/antimicrox/issues/597, but that issue is stuck for now in limbo because of the aspects mentioned above.
In terms of copyrights and general licensing I can't say much, because simply I am not sure.
pktiuk
commented
1 year ago He orphaned the package earlier this year (like a responsible maintainer should) to officially denote that the package needs a new maintainer and to denote that anyone can come forward and adopt the package within Debian.
Good to know, at least now I know, that I shouldn't bother him anymore.
Hi,
in an attempt to find the most daunting type of issue nobody wants to look at between years (well, not really, I am just toying with the idea of adopting the package in Debian and looked a little too hard for why this package doesn't use a declarative copyright file) I now wonder what the source(s) of all those icons are.
I can visually confirm that:
is from Gnome Mist theme as pointed at in the Readme file. I would personally replace that with another icon as folders tend to be a dime a dozen, but okay, moving on:
Are visually from KDE oxygen, the other source mentioned in the Readme. Usually they have the same name (minus
s#_#-#) except for the games_config ones and the (recently added) battery icons.So far so good, but that leaves:
Those are colored. Some look a bit like earlier versions of oxygen icons, some like they are from a different Gnome theme. I think I have seen them all before… they at least look familiar – which on the upside means they should be easy to replace if need be.
Might be dangerous territory claiming ownership and/or copyright and/or a license on that one.
Those are black-and-white and hence don't really fit with the rest of the icons, so I doubt they are from oxygen. Perhaps some high-contrast theme? At least most of them have visually similar (but colored) alternatives in oxygen.
If that mixture remains, it might be a good idea to give each bundled icon set its own sub-directory so that it is more clear where they come from and someone later adding new ones is "forced" to think about there to add them hopefully keeping the licensing straight.
That might alternatively be a good moment to choose all icons from a single theme (like oxygen) and run with it. I am not much of a GUI programming person, but if I understand the code right these are all/mostly supposed to be fallbacks if the current theme doesn't come with its own icons of that name (but some are renamed like battery, so no?) … so mostly a Windows/MacOs issue as on Linux and Co. packaging could just depend on an icon theme like oxygen and be done with it, no?
The parent directory of actions has another few images with dubious sources (they at least don't look like they are from Mist or Oxygen) and even the logo of antimicrox itself… I mean, it says "made by Freepik" and points to flaticon.com. Searching there a bit finds me this as probable source, but I have my doubts this remark deeply hidden inside a subdirectory Readme satisfies the "Attribution is required" demand. Especially as they have an explicit suggestion for how to attribute them in an "app" (and how on a "website"). It also raises the question if a packager would need to include attribution in the package description, so that it appears in the "marketplaces" and "stores" of a typical Linux distribution or if my interpretation is a bit too zealous in that regard (At least in Debian I would question if that would be possible/desirable. I have at least not seen something like that before).
Also, as all (?) those icons are available as SVG and most places you want to use them should nowadays support svg it might be better to switch to that format compared to sticking to 16x16 icons and optionally converting with ImageMagick at built time if other formats are needed rather than ship a couple different versions? But that is hardly related to the initial issue at hand.
Best seasonal wishes (and sorry for raising this)
David
Upvote & Fund