* Package name    : kicad-gruvbox-theme
  Version         : 1.1.0
  Upstream Contact: Alexander Brevig
* URL             : https://github.com/AlexanderBrevig/kicad-gruvbox-theme
* License         : MIT
  Programming Lang: n/a
  Description     : Gruvbox colorscheme for KiCadi

A simple gruvbox colorscheme for the EESchema and PCBNew editors within
KiCad. KiCad 8 allows for the system-wide installation of
colorschemes, thus ITP'ing now.

best,

werdahias
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmX++pEVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1ALsP+wZaCyJ09gu+5b3dDFtz4mpYlZ43
VCAt6Jk9AL/19TLhgqx8cLWAXLltsTbmptRfI5po0InQVux3iS8s7DdvqyQ25z3A
JKEAmQuWWWP7FaQ6GqZmUbcLVXC7lts0tLHfBj71TI8LpQn0aeoBKByvfEu30tcX
taZ9pEig/cpp4L2w6Ew7Zhbpb5rSoOwVoISVlB5/w+tihGotyqKd7B+/rVjYyqo+
y2fnRPBDsA/k/H6zPxUPJNp4TR+nebcl9JmWoxwDwQ2RyLxpYEoYyDZw7fryCUIv
TO7uaDfiXBdVAq+zvAYC6fki3MVuShNqHQHDbbWDD/IPi3zlccUkZxc4d0PFsMEo
o8kNsZwNxrQotWV06p3q4ciD62vAbaBimvD0twYSe3RALrcg4FVY6D8VL1A+Ug2l
Yb/p/rzdzneZx6Sw7emoTYnBOLqkuWxV+6QHrE0O5RUt4xYj+OWb/2mXhrLHk8kC
jo47JQJjx06tFZYB8WRWTdDhGYtovFm4ac/ByhFmqwF134eGal48P6O7fJZArckf
8TVeYZT0HgS2v25ITx5rv4gt3fyxli2rjnFH3SKpfE01Mmyeta0ArHIRVj39Nilm
zLAwyal1zuZuQSVp7GWdxptVGTSAURvVI5RFwf9AtNJsNJO2Feg9Sa3GxNl1hphF
cmJqrvQ3sNqCSfny
=ed5N
-----END PGP SIGNATURE-----

Hello Matthias,

Am 23.03.24 um 16:51 schrieb Matthias Geiger:

how is this system wide installation intended to work.

Even the upstream project site states the installation needs to happen
into ~/.config/kicad/colors or ~/.config/kicad/6.0/colors (besides it
uses the older version 6.0 as user folder)

As long as I follow this feature I'm not aware that any system wide
installation of themes is now possible.

Given it is possible, how the internal Plugin and Content Management
will handle this?

Am 23.03.24 um 17:23 schrieb Carsten Schoenert:
Hi Carsten,

thanks for maintaining KiCad. What you mentioned is true for Kicad <=
7.0. With 8.0 a change landed enabling installation of colorthemes
system-wide  (see https://gitlab.com/kicad/code/kicad/-/issues/15920).

I already created a package and installed it and it works as intended.
Since this does not touch user files this conforms to Debian policy. 
The plugin manager does not show this scheme as installed since it only
looks for user themes.

best,

Hello Matthias,

Am 23.03.24 um 17:40 schrieb Matthias Geiger:

nice, o.k., then upstream has still some work to do. :-)

Would it not better creating one src:package which would package the
various themes all together that are out there? e.g. named kicad-themes

I dislike a bit multiple packages that a user needs to know (and to
install then) if all could get packaged into one.
There could be of course also a virtual package kicad-themes which pulls
in the installation of all the real other theme packages.

Most of the other themes are not under heavy development and will only
change randomly.
Downside otoh is you will need to run a own scripting to detect changes.
Is also not that complicated.

But that's up to you if you can agree on my ideas.

Am 23.03.24 um 17:53 schrieb Carsten Schoenert:
I agree that packaging all themes is doable. However, how would I create
a src: package with different upstream tarballs? I could use some help
with that. Providing a virtual package for all themes is also a good idea.

Would you be ok with this package being maintained under the Electronics
Team ?

best,

Am 23.03.24 um 18:29 schrieb Matthias Geiger:

To me you don't need multiple tarballs to archive the goal, you could
add all the various sources into one tarball. Using so called component
tarballs brings no gain to me, the usage of them also have
disadvantages. How these tarballs are getting used did Raphael Herzog
explain in one of his blog posts [1].

I think you can go like this, arrange the folders and finally create a
tarball of the top folder.

The creation of this tarball can be done by a script living in the
debian/ folder. Adding later another theme is simply adding one more
folder and adjusting d/rules, d/copyright and sequencers maybe.

If you want to create various binary packages adding a new themes will
require a new binary upload to NEW then. This is no issue, such uploads
get processed much quicker than a complete new src package.

Sure, why not. Would be quite logical to place it here.

[1]
https://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/