Closed FrankvVeelen closed 10 months ago
When I took a look at Kiri it used a mechanism for schematics that isn't good for KiBot integration. I know Kiri is much better for interactive usage, but not for CI/CD. I'll keep the request, but I'm not sure about it.
Would be an awesome feature! Does Kiri even interfere with kibot if it is triggered separately? With the --no-server flag given the output could be maybe nicely relinked with navigate_results maybe?;) There are workarounds to get this working but up to your answer I guess there is nothing in the pot in the near future?
Hi @Nudelsalad !
I see @leoheck moved to kicad-cli for KiCad 7. Which removes the need for PlotKiCadSch, a real overkill since this is an OCaml tool.
Still using KiCad-Diff for the PCB, which is redundant tool since KiBot uses KiDiff.
Things are getting closer, but I don't have time right now.
Hi guys, KiCad-Diff is a small script, and for Kiri, you don't even need the GUI, I don't see any big problem of having it installed.
Kiri still uses KiCad-Diff because kicad-cli for layouts takes a looong time to export each layer, and considering a big set of layers per commit and also a big set of commits, it takes a lot of time.
But it is also possible to use kicad-cli for this. If KiCad-Diff is not installed (or maybe you have to pass a flag to Kiri), it will use kicad-cli instead. It may work ok if comparing 2 commits.
For instance, here, we just compare 2 commits, removing previous runs, and displaying the commands kiri is running, without launching the browser.
kiri -r -D --kicad-cli -t 2 -l
And this already takes 12.2s on my machine which is a good machine I guess (Dell XPS, i9) The Board used in this example has 22 layers. Not all of them are important but they are/were present in the Kicad project.
Hi @leoheck !
I'll take a look at this. I'll post my questions here. First one: why dos2unix
is a mandatory dependency?
Nope, I just ended up adding it as a workaround since most of the time people do things that they don't know, and they blame my tool for that and I don't always have time to debug everything. You could remove the lines using it. I can end up removing or adding a test to not use it if it is missing.
Would be an awesome feature! Does Kiri even interfere with kibot if it is triggered separately? With the --no-server flag given the output could be maybe nicely relinked with navigate_results maybe?;) There are workarounds to get this working but up to your answer I guess there is nothing in the pot in the near future?
About the link to navigate_results, you mention "workarounds", which ones do you mean?
From what I see you need to start the KiRi webserver and read the pages from it. As a workaround I tried google-chrome --allow-file-access-from-files index.html
and got it working, but is quite specific to a particular case.
I am not sure how KiBot works or how it is used, but Kiri could just generate the images and the website without having to launch it... then the result (the .kriri folder,) can be exported, there is also an argument to make a pack of it. Inside, this folder it has a python script to launch the webserver using the previously generated files.
@leoheck : I was playing with KiRi and found a couple of issues:
It would be nice if --kicad-cli forces the use of kicad-cli even for KiCad 5 files.
Other questions:
I am not sure how KiBot works or how it is used, but Kiri could just generate the images and the website without having to launch it... then the result (the .kriri folder,) can be exported, there is also an argument to make a pack of it. Inside, this folder it has a python script to launch the webserver using the previously generated files.
One of the KiBot outputs can generate web pages to browse all the generated stuff. The problem here is that we can't directly link the KiRi output from this page.
From what I understand the big problem is that KiRi needs to read contents from separated files and this seems to be forbidden for Java Script. Embedding all the SVG files seems to be an overkill and this is why a server is needed.
It would be nice if --kicad-cli forces the use of kicad-cli even for KiCad 5 files.
Yeah, definitely, I will give it a look.
I see you use shell scripts and Python, why not just Python? Is much more powerful and is even more portable, you won't need to worry for things like readlink, sed, realpath, etc. And your shell scripts are Bash specific! By using something like Python you'll be able to drastically reduce the "bin" pollution, you have 19 things in bin, KiRi can't be installed in a regular system, in particular: you even have an env.sh script, that could collide with anything.
Yeah, python is awesome, but shell script is easier for me. Actually, this tool started as an experiment, but then later I adapted it to work on other systems and for others too. It just started as a bunch of commands that I put together in a script. Having everything made in Python would be better definitely it would also make it possible to add on Kicad package manager (people would definitely love this). I thought many times to start changing it to Python only, but it would take a lot of time and effort for me to do it. Maybe if I have some spare time in the future. It is not a big and complex tool. The tool is simple, actually, it gets the commit list from git and iterates through them exporting the schematics/layers to images.
Hi @leoheck !
I tried the following toy test: t1.zip
Running the run_kiri.sh script I got a nice list of commits and can browse the schematic changes. But the PCB looks the same for all the commits. Looking at the logs I see things like:
# 4/6 1db11f8 | 2023-11-27 11:12:45 | KiBot test | Reference
Retrieving commits:
- Source path: /home/salvador/0Data/0Test/#391/t1/.
- Output path: /home/salvador/0Data/0Test/#391/t1/.kiri/1db11f8
...
# Plotting schematics 1db11f8
...
# Plotting layout _local_, F.Cu
Always plotting local, not the corresponding commit. Can you reproduce this bug?
Schematics are hard to spot the differences actually.
But I can see them here...
You can easy see the same with this script
schs=($(find .kiri/*/_KIRI_/sch -name "*.svg"))
for sch in ${schs[@]}; do
# echo "Diffing ${schs[1]} and ${sch}"
diff -q --report-identical-files ${schs[1]} ${sch}
done
Right now, when the local files have not commited changes, they are included automatically on the list of commits.
Hi @leoheck !
Schematics are ok, the problem is with the PCB. The log says that is always plotting the layout for local, so you can't see any difference ;-)
I also found another problem: If I include the same sub-sheet twice KiRi generates:
light_control|light_control.kicad_sch||light_control|light_control
sub|sub.kicad_sch||sub2|light_control-sub2
sub|sub.kicad_sch||sub|light_control-sub
This is good, but when you look into the generated files only two of them are generated (light_control.svg and sub.svg). You may claim that sub and sub2 are the same, but this isn't correct, changes in the annotation (reference numbers) can't be displayed if you don't have both rendered.
Here is the test case: test.zip
About the link to navigate_results, you mention "workarounds", which ones do you mean?
From what I see you need to start the KiRi webserver and read the pages from it. As a workaround I tried
google-chrome --allow-file-access-from-files index.html
and got it working, but is quite specific to a particular case.
Hi @set-soft and @leoheck! Nice to see this discussion going on, My workaround is not really a solution to these problems, but here is a little insight: I installed Kiri directly into the kibot docker container and let them both run their jobs in gitlab-ci. There, the output jobs are pushed to gitlab pages, and with separate links in the readme file or in the index.html I generated, you can access both outputs. The kibot link points to Test-navigate.html in the kibot/web directory and the kiri link points to index.html also in the kiri/web directory. As you might see this is a dirty solution and the container is quite big with all my libs and the full kibot image ~3.2GB My scope was to get it up and running in a short time, not to dig very deep.
Unfortunately I am having some performance issues with kiri output on large projects. I am not sure why it is really lagging on a large schematic. Thinking it must be an issue on the gitlab side, I also spun up the local kiri server and removed all the auxiliary project files. This left me with no clue as I have both a powerful server and a powerful desktop machine. But only on the schematic side! On the other hand, looking at the PCB seems fine and smooth. I'll mail you both the example :)
Schematics are ok, the problem is with the PCB.
Ah, sorry. I am running a fresh install of the OS, I don't have Kiri installed the traditional way and I am not sure if it has everything that it needs.
Testing here, I saw no changes as you are saying. But after cleaning the cache, (flag -r) it started to show the changes. Could you try that too? The local changes should not need this, I will have to check this behavior too, thanks for finding this.
This is good, but when you look into the generated files only two of them are generated (light_control.svg and sub.svg). You may claim that sub and sub2 are the same, but this isn't correct, changes in the annotation (reference numbers) can't be displayed if you don't have both rendered.
Yeah, handling multiple schematic pages is hard, especially the way Kicad stores these things. This behavior can be improved too. In the past, I thought that just one is enough since I was interested in circuit changes only. Perhaps there is a better way to display this.. maybe showing all the instances of each page... however only the designators are going to change, I feel no one will check these changes. I may be wrong tho.
Unfortunately I am having some performance issues with kiri output on large projects.
Is this for a single comparison or for comparing all git history? You can run Kiri with -t 3
to compare only the last 3 changes, including the local if it has chances.
You could also try kiri-docker
if you are using linux or a linux shell.
Check it here: https://github.com/leoheck/kiri-docker There is this kiri command that is a wrapper to the normal kiri command. It mount the local repo inside the docker, launch kiri there, and displays the result in the local browser. This could work for you, maybe.
however only the designators are going to change, I feel no one will check these changes. I may be wrong tho.
If the changes are in the reference numbers and KiRi doesn't show them the user will be confused about what's the difference. In the future KiCad could also allow changing other things, like the component value.
Testing here, I saw no changes as you are saying. But after cleaning the cache, (flag -r) it started to show the changes. Could you try that too? The local changes should not need this, I will have to check this behavior too, thanks for finding this.
Tried it and got the same. Did you try using the run_kiri.sh
script? I suspect the issue could be related to --kicad-cli
Unfortunately I am having some performance issues with kiri output on large projects. I am not sure why it is really lagging on a large schematic. Thinking it must be an issue on the gitlab side, I also spun up the local kiri server and removed all the auxiliary project files. This left me with no clue as I have both a powerful server and a powerful desktop machine. But only on the schematic side! On the other hand, looking at the PCB seems fine and smooth. I'll mail you both the example :)
I got your example, do you mean that doing zoom and pan in the browser is really slow?
I noticed that in my machine at work (not really fast, 3rd gen i7). But if you look at the SVGs they are upto 3.6 MiB. The script is comparing 2 of them. Perhaps the method used is not the best (is this the feColorMatrix stuff @leoheck ), or just the pan & zoom class (svg-pan-zoom). But yes, is slow.
Hi guys (@set-soft @Nudelsalad), I tried to summarize the issues here, https://github.com/leoheck/kiri/issues/104 Do you mind checking if it is missing something or if I misunderstood anything?
======
@set-soft I tried your script once (and again now), the local layers are not being displayed for some reason (the image was just red), as you observed. However, they were generated. I also could not see the differences in the layers of other commits with the browser.
Found the issue, the layouts of the _local_
have different names. the names are not being normalized. They should be normalized to this format layer-00.svg
@set-soft do you have this rename here? I don't have it right now, since I reinstalled the OS, this may the the issue on my side. I will check if I can skip it to use the normal rm tool... since it is more spread and maybe reliable. this causes issues on other distros since not always people have the rename that is the perl script since there are others available.
for some reason, the local changes produce an image with a different kicad version. but there are no local changes made by the user.
However, the changes are not being displayed yet.
@set-soft I could find an issue when generating pcb layers with kicad-cli it is fixed in the repository already, could you check if it works for you?
kicad-cli can be used with kicad 5 layout but not with schematics since it plost only kicad_sch and not sch. This is a poor decision they made. Poor because they have the kicad parser and the kicad exported. They could have just used it.
But I will try to fix the issue with the keyboard changing when xdotool fails.
I tried to address the keyboard change restoring the original keyboard. Let me know if you still have this issue after the update.
@Nudelsalad , I found out that your experience can be much better optimizing the svg files... You have a lot of images.. and this may take some time. It took some time on my i9. Just copy and paste this inside the .kiri folder of your project, this will optimize all the svgs of the schematic files.
optimize_svg()
{
svgs=($(find */_KIRI_/sch/ -name "*.svg"))
total="${#svgs[@]}"
i=0
for svg in ${svgs[@]}; do
i=$((i+1))
orig_size=$(du -sh ${svg} | tr "\t" " " | cut -d" " -f1)
cmd="svgo -q --final-newline -i ${svg}"
eval ${cmd}
new_size=$(du -sh ${svg} | tr "\t" " " | cut -d" " -f1)
printf "%3d/%d | %4s > %4s | %s\n" ${i} ${total} "${orig_size}" "${new_size}" "${cmd}"
done
}
optimize_svg
The output is something like this...
I could add this to kiri and a flag to enable it (or maybe to disable it) when not needed.
You are going to need to have the svgo installed. I installed it on my Ubuntu using this, https://snapcraft.io/install/svgo/ubuntu
@set-soft dos2unix is definitely not needed anymore. thanks for pointing this out.
@Nudelsalad I added this optimization to the kiri, directly. You can test it with the latest version of the repo. It is possible to disable it with the flag (uppercase) -R
. However, the svgo
tool must be available in the PATH otherwise Kiri will skip this step.
Hi guys (@set-soft @Nudelsalad), I tried to summarize the issues here, leoheck/kiri#104 Do you mind checking if it is missing something or if I misunderstood anything?
Very good @leoheck ! I'm updating KiRi with your last patches.
@set-soft do you have this rename here?
I have the rename tool installed.
@set-soft I could find an issue when generating pcb layers with kicad-cli it is fixed in the repository already, could you check if it works for you?
I'm running KiRi right now and I can see it generating images for each hash, not just local, yes, fixed!
@Nudelsalad , I found out that your experience can be much better optimizing the svg files...
Do you know which optimizations are applied? Can you look for a light weight equivalent? I want to avoid Node.js tools, they are slow and bloated.
I'm experimenting with the following approach to draft an integration:
I already modified KiDiff and KiBot is generating almost all the files needed by KiRi. Will post results here.
Do you know which optimizations are applied?
I do not know this.
I just used the first one I could find and it worked really well. So I pushed it to check if @Nudelsalad could tell us if this improves the overall experience for him.
Also, the produced files are normalized, so I can compare them against the others to see if they have meaningful changes and this may allow me to hide layers (maybe schematics too) that do not need to be compared at that time making the review process faster.
We can use a different one, for sure, right now I just don't know any other.
svgo is doing its normal optimization which I don't know what it is. But I also asked it to reduce the precision of the values and asked for a nested svg.
I put this behavior in a separate file, you can also check and experiment with modifying it in this file here ttps://github.com/leoheck/kiri/blob/main/bin/optimize_svg_for_web
I'm experimenting with the following approach to draft an integration: KiDiff generates the SVG files, it can handle SCH and PCB conversion using KiAuto KiBot chooses which files to use, it can handle git repos very well, including submodules. Then I copy the KiRi engine (kiri_server, kiri.js, kiri.css, etc.) to the destination folder. I already modified KiDiff and KiBot is generating almost all the files needed by KiRi. Will post the results here.
Thats nice. Yes, please share the results here, I am eager to see it. I realized recently that Kiri can show and compare the commits, and the local changes too, but not the staging area.
I added an option to compare 2 commits, using this syntax kiri -c HASH..HASH
kind of what git does. the HEAD syntax works too and also the LOCAL, local, local. This may help to have some improvements since it won't need to compare the whole list of commits.
Hey guys, I just tried out the newest kiri updates and somehow the issue of pan & zoom is gone, the kiri website is now working flawlessly but somehow the size had not been significantly reduced. I guess thats really due to the project size. I noticed two things:
Second thing i tested was another svg optimizer tool there are few out there, two seem to be beneficial for here:
optimize_svg()
{
svgs=($(find */_KIRI_/sch/ -name "*.svg"))
total="${#svgs[@]}"
i=0
for svg in ${svgs[@]}; do
i=$((i+1))
orig_size=$(du -sh ${svg} | tr "\t" " " | cut -d" " -f1)
cmd="svgcleaner ${svg} ${svg}"
eval ${cmd}
new_size=$(du -sh ${svg} | tr "\t" " " | cut -d" " -f1)
printf "%3d/%d | %4s > %4s | %s\n" ${i} ${total} "${orig_size}" "${new_size}" "${cmd}"
done
}
optimize_svg
Here the output of my job:
Here the output of svgcleaner after calling
svgcleaner 0603_Dashpanel.svg 0603_Dashpanel.svg
@set-soft you mentioned that you are about to integrate the kiri files and mentioned kiri-server. Is kiri-server really needed in kibot? As I am continuing to dream that navigate_results just links the web/index.html of the kiri_out to maybe the index.html starting page of kibot with maybe a third Option next to PCB, Schematic and maybe Review/Revisions
the issue of pan & zoom is gone
Hm, I increased the speed of the zoom a bit. This could have done the magic.
- Installing all npm dependencies with svgo consumes nearly 600MiB in my container
Normal for a Node.js tool, this is why I asked for an alternative.
- Creating the artifacts of the output with kiri takes for a limit of the 5 last commits on my server 13 minutes which is quite longggg. But I guess this is due to kidiff sadly no verbose output is possible there. In the end it works, but its kind of odd user experience and blocking my runner.
I'm testing the KiRi integration using a toy repo (the one I posted here). Using KiBot is much faster than using kicad-cli
, but is just a toy project.
Second thing i tested was another svg optimizer tool there are few out there, two seem to be beneficial for here:
- scour (pip package) easy to install just the need to add it to your requirements.txt and lets go
Looks very light-weight
@set-soft you mentioned that you are about to integrate the kiri files and mentioned kiri-server. Is kiri-server really needed in kibot? As I am continuing to dream that navigate_results just links the web/index.html of the kiri_out to maybe the index.html starting page of kibot with maybe a third Option next to PCB, Schematic and maybe Review/Revisions
If the navigate_results output is deployed to a web server you don't need kiri_server.
If you generate the artifacts, download them and try to see the navigate_results the kiri.js script will fail, unless you use the above mentioned workaround (google-chrome --allow-file-access-from-files index.html
)
Ok, here is a first working result, not committed: res1.zip
This is KiBot generating the files needed by KiRi engine.
I added a very bizarre situation in the schematic to test how KiBot and KiRi reacts. I included 3 sub-sheets, one is shared, another has a repeated name.
I see big performance issues, it looks like the browser is refreshing stuff all the time, i.e. scroll bars flickering. I'm not optimizing the SVGs yet.
I see big performance issues, it looks like the browser is refreshing stuff all the time, i.e. scroll bars flickering. I'm not optimizing the SVGs yet
@set-soft I also noticed weird flickering of the scroll bar sometimes however it is working fine for me right now with my last project and optimized svgs but i will apply this to more projects and report if it appears again
Both scour
and svgcleaner
work nice,
this is scour working,
using the maximum scrub as it is reported by their github
cmd="scour -i ${svg} -o output.svg --enable-viewboxing --enable-id-stripping --enable-comment-stripping --shorten-ids --indent=none"
eval "${cmd}"
mv output.svg "${svg}"
I also noticed weird flickering of the scroll bar
This may be due to may nasty js/html/css skills.
The svg optimizer could optimize in a way that I can compare 2 to ignore pages/layers without changes.. this could make the review process easier. There is always something inside the file, that is not visible, that prevents me for hiding all unchanged layers.
I tried scour and even when it reduces the file sizes, the real issues still there. I thought it was something related to the complexity of the files, but I can load the SVGs in the browser and they are displayed fast. I suspect the problem is in the pan & zoom class or, most probably, in the way colors are computed (using a complex SVG filter).
One thing that I would like to see is the possibility of diff colors customization. I know it sounds cosmetic, but all the colored diff tools I know for code use added == green and removed == red, KiRi is using cyan for added, which is somehow confusing to me.
What is the txt_icon? I'm not sure if I understand it right: Only the commits where the SCH and/or PCB changed are displayed? If this is the case: What is the TXT icon for?
Looking at the JS code I see the layer colors are hardcoded and the colors in the initial index.html aren't really important. It would be nice if we could allow color changes, so people can use colors that are easy to recognize.
The list of commits has a fixed width that in my system isn't good, is this common? Can be automatically adjusted?
I tried scour and even when it reduces the file sizes, the real issues still there. I thought it was something related to the complexity of the files, but I can load the SVGs in the browser and they are displayed fast. I suspect the problem is in the pan & zoom class or, most probably, in the way colors are computed (using a complex SVG filter).
I felt the same when I ran scour. With the svgcleaner and svgo it was a bit better.
One thing that I would like to see is the possibility of diff colors customization. I know it sounds cosmetic, but all the colored diff tools I know for code use added == green and removed == red, KiRi is using cyan for added, which is somehow confusing to me.
Definitely. It is not just cosmetic, it is important for me too. But I am not sure how to handle those color matrixes. They are quite complex to work with. I would appreciate it if you could try to change them a bit. I don't like the current colors either.
What is the txt_icon? I'm not sure if I understand it right: Only the commits where the SCH and/or PCB changed are displayed? If this is the case: What is the TXT icon for?
Text icons are changes that are not in the sch and kicad_pcb files, but this was tried a long time ago, today I feel they don't help much when comparing the files.
Looking at the JS code I see the layer colors are hardcoded and the colors in the initial index.html aren't really important. It would be nice if we could allow color changes, so people can use colors that are easy to recognize.
I just have to understand how to make it work.
The list of commits has a fixed width that in my system isn't good, is this common? Can be automatically adjusted?
Sure, but maybe something broke in your browser. I felt this was not behaving like this before. But it needs a bit of love.
I will keep notes on this, but I can't guarantee I can fix or improve these things otherwise I would have done so in the past since I agree with everything you are commenting here.
I appreciate any help for improving the items above.
Looking at the JS code I see the layer colors are hardcoded and the colors in the initial index.html aren't really important. It would be nice if we could allow color changes, so people can use colors that are easy to recognize.
I just have to understand how to make it work.
Ok, I think I found an elegant solution. Take a look at 2737da234c16705f582720159adfe8106cdc25a1 here is what I did:
iconify layer_color_margin layer_color_${id}
.I used a separated CSS to make it easier to generate the layer colors CSS and to separate the general style from the layer colors style. Perhaps the layer_color_margin should be moved to kiri.css, what do you think @leoheck ?
So now you just need to provide a separated CSS. KiBot is generating it from the color theme selected by the user. I generated the CSSs for _builtin_classic and _builtin_default:
/* ==============================
Layer colors
** ============================*/
.layer_color_margin {
margin-left:0.5em;
margin-right:0.1em;
}
.layer_color_0 { color: #840000; }
.layer_color_1 { color: #C2C200; }
.layer_color_2 { color: #C200C2; }
.layer_color_3 { color: #C20000; }
.layer_color_4 { color: #008484; }
.layer_color_5 { color: #008400; }
.layer_color_6 { color: #000084; }
.layer_color_7 { color: #848484; }
.layer_color_8 { color: #840084; }
.layer_color_9 { color: #C2C2C2; }
.layer_color_10 { color: #840084; }
.layer_color_11 { color: #840000; }
.layer_color_12 { color: #848400; }
.layer_color_13 { color: #C2C2C2; }
.layer_color_14 { color: #000084; }
.layer_color_15 { color: #008400; }
.layer_color_16 { color: #840000; }
.layer_color_17 { color: #C2C200; }
.layer_color_18 { color: #C200C2; }
.layer_color_19 { color: #C20000; }
.layer_color_20 { color: #008484; }
.layer_color_21 { color: #008400; }
.layer_color_22 { color: #000084; }
.layer_color_23 { color: #848484; }
.layer_color_24 { color: #840084; }
.layer_color_25 { color: #C2C2C2; }
.layer_color_26 { color: #840084; }
.layer_color_27 { color: #840000; }
.layer_color_28 { color: #848400; }
.layer_color_29 { color: #C2C2C2; }
.layer_color_30 { color: #000084; }
.layer_color_31 { color: #008400; }
.layer_color_32 { color: #000084; }
.layer_color_33 { color: #840084; }
.layer_color_34 { color: #00C2C2; }
.layer_color_35 { color: #840000; }
.layer_color_36 { color: #840084; }
.layer_color_37 { color: #008484; }
.layer_color_38 { color: #848400; }
.layer_color_39 { color: #840084; }
.layer_color_40 { color: #C2C2C2; }
.layer_color_41 { color: #000084; }
.layer_color_42 { color: #008400; }
.layer_color_43 { color: #C2C200; }
.layer_color_44 { color: #C2C200; }
.layer_color_45 { color: #C200C2; }
.layer_color_46 { color: #848484; }
.layer_color_47 { color: #C2C2C2; }
.layer_color_48 { color: #000084; }
.layer_color_49 { color: #848484; }
.layer_color_50 { color: #000084; }
.layer_color_51 { color: #000084; }
.layer_color_52 { color: #000084; }
.layer_color_53 { color: #000084; }
.layer_color_54 { color: #000084; }
.layer_color_55 { color: #000084; }
.layer_color_56 { color: #000084; }
.layer_color_57 { color: #000084; }
.layer_color_58 { color: #000084; }
and the default KiCad 6+ colors:
/* ==============================
Layer colors
** ============================*/
.layer_color_margin {
margin-left:0.5em;
margin-right:0.1em;
}
.layer_color_0 { color: #C83434; }
.layer_color_1 { color: #7FC87F; }
.layer_color_2 { color: #CE7D2C; }
.layer_color_3 { color: #4FCBCB; }
.layer_color_4 { color: #DB628B; }
.layer_color_5 { color: #A7A5C6; }
.layer_color_6 { color: #28CCD9; }
.layer_color_7 { color: #E8B2A7; }
.layer_color_8 { color: #F2EDA1; }
.layer_color_9 { color: #8DCB81; }
.layer_color_10 { color: #ED7C33; }
.layer_color_11 { color: #5BC3EB; }
.layer_color_12 { color: #F76F8E; }
.layer_color_13 { color: #A7A5C6; }
.layer_color_14 { color: #28CCD9; }
.layer_color_15 { color: #E8B2A7; }
.layer_color_16 { color: #F2EDA1; }
.layer_color_17 { color: #ED7C33; }
.layer_color_18 { color: #5BC3EB; }
.layer_color_19 { color: #F76F8E; }
.layer_color_20 { color: #A7A5C6; }
.layer_color_21 { color: #28CCD9; }
.layer_color_22 { color: #E8B2A7; }
.layer_color_23 { color: #F2EDA1; }
.layer_color_24 { color: #ED7C33; }
.layer_color_25 { color: #5BC3EB; }
.layer_color_26 { color: #F76F8E; }
.layer_color_27 { color: #A7A5C6; }
.layer_color_28 { color: #28CCD9; }
.layer_color_29 { color: #E8B2A7; }
.layer_color_30 { color: #F2EDA1; }
.layer_color_31 { color: #4D7FC4; }
.layer_color_32 { color: #000084; }
.layer_color_33 { color: #840084; }
.layer_color_34 { color: #00C2C2; }
.layer_color_35 { color: #B4A09A; }
.layer_color_36 { color: #E8B2A7; }
.layer_color_37 { color: #F2EDA1; }
.layer_color_38 { color: #02FFEE; }
.layer_color_39 { color: #D864FF; }
.layer_color_40 { color: #C2C2C2; }
.layer_color_41 { color: #5994DC; }
.layer_color_42 { color: #B4DBD2; }
.layer_color_43 { color: #D8C852; }
.layer_color_44 { color: #D0D2CD; }
.layer_color_45 { color: #FF26E2; }
.layer_color_46 { color: #26E9FF; }
.layer_color_47 { color: #FF26E2; }
.layer_color_48 { color: #585D84; }
.layer_color_49 { color: #AFAFAF; }
.layer_color_50 { color: #C2C2C2; }
.layer_color_51 { color: #5994DC; }
.layer_color_52 { color: #B4DBD2; }
.layer_color_53 { color: #D8C852; }
.layer_color_54 { color: #C2C2C2; }
.layer_color_55 { color: #5994DC; }
.layer_color_56 { color: #B4DBD2; }
.layer_color_57 { color: #D8C852; }
.layer_color_58 { color: #E8B2A7; }
This seems interesting, I will give it a look at the weekend, cool? Meanwhile, do you have a picture showing how this looks on Kibot? I don't have Kibot installed yet neither do I know how it works and what it produces.
Hi @leoheck !
I noticed that the list of layers and sheets embedded in the index.html are useless because the JS code replaces them as soon as we load the page (and/or switch to PCB).
This leads to:
So I tried to avoid filling them. I soon realized the JS assumes the lists are always there so I had to add a few conditionals to avoid accessing data that is not there. Take a look at this patch: 4fb3870d12a0aad00f10442bd59a7013f7871865
This seems interesting, I will give it a look at the weekend, cool? Meanwhile, do you have a picture showing how this looks on Kibot? I don't have Kibot installed yet neither do I know how it works and what it produces.
KiBot produces just files ... Here is the same example I uploaded before, just updated with the current patches: res5.zip
This was generated with the following config:
kibot:
version: 1
outputs:
- name: 'kiri'
comment: "Test for KiRi interface"
type: kiri
layers: ['F.Cu', 'In1.Cu', 'F.SilkS']
options:
color_theme: _builtin_classic
keep_generated: true
KiBot produces just files
Ah, I see, thanks. Actualy I used kibot in the past, I believe.
I was trying to apply the css you sent before, and the changes were not happening, maybe because of this https://github.com/INTI-CMNB/KiBot/issues/391#issuecomment-1836083531
As an alternative to the kidiff tool (which works okay, but doesn't work for analyzing differences between more than a few commits/versions, I think it'd be cool if kibot could integrate Kiri, as it (at least for me) works a bit nicer with tools like jenkins (generating a html page on which i can then analyse differences between commits).
If you need help with implementing this and could give me a few pointers where i should start please let me know.