Are we doing this efficiently?

[Foggalong]

I want to also start a discussion about how we develop the icon themes for different platforms. Currently the setup is worked such that icons are added to each platform individually and if the icons are used on multiple platforms then they will eventually be move across. This process is slow and often leaves icons being left behind.

I envisage a numixproject/numix-circle which contains all the raw icon files with easy to recognise names and then a build script which generates the content for Linux, Android, etc. It would mean that rather than contributing an icon to the Linux version specifically people would be contributing an icon for Circle in general.

We could also use this as an opportunity to fix #2430 by renaming this repo to the new one and creating a new repo for numix-icon-theme-circle.

I don't know if this is something people would be on board with doing and any feedback would be appreciated.

[satya164]

The Android icons don't have that much in common though.

[andia89]

Would that mean that icon requests for android apps could be made in the new numix-circle repo as well? If yes the issue tracker might explode :P But generally I think this is a good idea because it would help to get new icons for android as well...

[palob]

As far as I understand it's the Android theme which could use many icons from the desktop theme (albeit the symbols on the Adroid icons are often bigger).

So for instance desktop icons would be made to begin with, say $ so as to be recognised as such by the script. Wouldn't the script method complicate direct installations from git?

I haven't got the faintest idea how Android theming works and where to get the icon names from. Requests are made from inside the app, not against the repo, right?

If we just could see the requests and icon names here contributors easily could copy the icons over. Anyway, this copying/renaming task is still needed in case of a united repo isn't it?

Other than that I don't think any single contributor came here as Android user, I think it's a pretty alien concept to the average Numix on Adroid user.

[ismaelgv]

I think it is a good idea, you can improve a lot the workflow here. I got some suggestions:

• Create an icon database as in hardcode-fixer (simple csv file or another kind of db):
  • You can got a better control of icons we got and requests this way.
  • You can just insert symlinks in the database and later create them with the script. This keep folders cleaner without symlinks.
  • If you want to work with different sizes I think this is a must have.
  • You can have arbitrary icon name and then assign real names stored in db and running the script (Android, Linux, etc.).
• You can include hardcode fixer in the icon theme as separate executable. (I am not sure about the drawbacks of this idea).
• All icon request in the same repo (I've seen icon requests even in Launchpad).

[ismaelgv]

I was even thinking in SQLite to manage icon database. It is present in any distro and got csv import/export if you don't want to directly work with it for some reason.

[Foggalong]

@satya164 As well as what @palob said there's a big overlap for web stuff which is where a lot of our requests seem to come from these days

---

@wa4557 Yeah, it'd mean Android, Linux, etc were all made in the same place. I'm not entirely sure how the tagging would change though

---

@palob The design guidelines aren't supposed to be different for the two so the discrepancy might be an error.

The current numix-icon-theme-circle repo would still exist, just icon updates to it would be generated periodically (say weekly) from the core numix-circle repo.

We were actually in the process of changing how icon requests worked for Android but that work was never finished afaik.

---

@ChuckDaniels87 That's the kind of thing I was imagining there!

Including hardcode fixer in the repo is a big more complicated since it's usage is very installation/update dependent. Possibly something to look into though.

---

I'm gonna make a demo repo with ~10 icons to show what I mean a bit more clearly over the next few days. It could be that it's a terrible idea and becomes immediately obvious to be such but it could also really refine how we do things. I dunno!

[palob]

A demo repo sounds like the way to go :+1:

[ismaelgv]

Nice :+1:

[ismaelgv]

I've been running some tests with SQLite, it works like a charm to keep a db of icons and requests, including hardcoded icons tracking and mixing OS (Android and GNU/Linux distros). It is lighweight, really simple to use, omnipresent (it comes installed in almost any distro and Android) easily scriptable and there are nice graphical tools to manipulate it (p.e. sqliteman).

I've found also some drawbacks, mostly with git version control. Databases are binary files, impact in git repository is obvious, mostly in log files. There are common solutions:

• Do not store database in the repo (kinda obvious). Store it externally.
• Store dumped database in the repository. You can easily dump into text file with SQLite needed information to recreate database and later recreate database from that [1][2][3]:
  1. sqlite3 .dump > icons.txt
  2. sqlite3 icons.db < icons.txt
• Do not use SQLite directly, use csv plain files

Well, these are just some thoughts. I got not much experience managing DBs if someone knows more about this please correct my post. :wink:

[satya164]

@ChuckDaniels87 why not use plain JSON? We don't need complex DB queries anyways.

[Foggalong]

Yeah, SQLite wouldn't be my first choice for this kind of thing. A bit more complex and I'm not a fan of binaries in git repos, and it needs to be there so that it can be used for other themes (Square, Hex, etc). My first choice would be CSV, and failing that JSON.

[ismaelgv]

I've got little knowledge about this but I understand JSON is an object storage format and you need something to parse and manipulate it. I've been reading about it usage and there is no "standard" tool in contrast to SQLite. With a simple CSV file and SQLite schema file we could reproduce database virtually anywhere.

We could create a unique database for all OSes, storing hardcoding state, symlinks, several icons sizes state, etc. With simple filtering of database using SQLite in a script you can install theme anywhere. It seems more scalable to me this approach.

[Foggalong]

Expanding on the needed for other themes thing: the plan is to have the DB stored in the Circle-Core repo and just downloaded for the Square, uTouch, etc ones so that we only have to maintain one copy of the list (which is open source :+1:)

[ismaelgv]

I've commented at the same time :yum: I'm also against using binaries in git. I'll try to do a test repo for showing my work flow idea, but basically is this:

CSV+Schema file in the repo -> Automatized local database recreation -> Database modification -> Exporting CSV -> Commit new CSV

[ismaelgv]

I've created a repo for testing icon databases. I used SQLite as first approach, CSV file + SQLite scripts.

[satya164]

@ChuckDaniels87 JSON is a standard format and all programming languages have libraries to parse JSON. You don't even need libraries if you use GJS/NodeJS.

What's the problem with storing the DB in a plain text format rather than SQLite? The core team doesn't have any experience in SQLite, so we can't do any changes, and a plain text file is always easier for everyone.

SQLite is a database which is more suitable to store complex data. We are just storing simple data, and JSON is good enough for it.

[ismaelgv]

SQLite is almost anywhere and it is not needed to use command line to modify database. As I said, sqliteman, SQLiteStudio or even Firefox Plugin SQLiteManager can be use to easily modify icon database.

I understand that this process add just one step (export/import CSV <-> SQLite) that is already scripted in two ultra-simple SQLite scripts. You can even check what is your DB state right in GitHub cause it supports CSV (example I, example II) with search included. I just like SQLite compromise between ease of use, flexibility and simplicity.

I'm really curious how a DB could be managed in JSON, I got no experience in that and I'd like to know more about it. :wink:

[satya164]

@ChuckDaniels87 Not everybody knows SQLite. We're all designers here, and we aren't expected to know how to operate databases.

Anyone who wants to contribute isn't expected to know SQLite.

JSON is a simple plain text format which anyone can understand easily and modify in any text editor, or write a small tool to update it. You don't even need to know programming to understand JSON.

About managing a DB, we're just storing structured data. JSON supports structured data as arrays and JavaScript objects (akin to hashmaps), which is enough for our need. We don't need a database like SQLite. A DB is good when you have complex data, but in our case, I think it's overkill without any added benefits and a learning curve.

[ismaelgv]

Ok then, I'll take a closer look to JSON format and parsers available and run some cases in my test repo. Any suggestion to start from?

[Foggalong]

Only just reading this and laughing because I've implemented my demo repo in pure CSV. We'll see how this goes :P

[Foggalong]

@bil-elmoussaoui Do you know anything about using cairosvg.svg2png to turn a 48px SVG into a 96px PNG? At the moment I'm using os.call and an Inkscape function but I'd sooner keep it as much Python as possible

[bilelmoussaoui]

i don't think so, but i will take a look this weekend. You only need 96px size ?

[Foggalong]

I need to export 96px as 192px and 256px as 1024px

[andia89]

As far as I understand the python code this is currently not possible :(

[Foggalong]

I've been a bit too busy for the demo over the last few days so I've uploaded it so that others can take a look and see what they think :)

continuing discussion in numixproject/core-demo#1