The two instances is a cross browser bug / i added the same printer with Firefox, but for the showcase its fine 
(codekit transfered the data to chrome)
[fixed]
[todo]
source:
The installation section is not fixed yet.
For port i use 8080 for normal installation / i use port 4000 for development
I have to check how to setup github pages 
have fun
It's explained here but the most important (and probably only) step for you is this:
since the repository is basically a web page already. I might be mistaken though.
Also: Awesome job! 
Really glad to see someone pick up the reigns on this.
I put it on an external webspace to prevent https.
Otherwise i had to setup https on every machine.
But this should be fine because only the page is transferred over the web.
Ok i can't use the octoprint client library with vue2 + electron so i have to rewrite it as a vue2 plugin :-/
Just to enlighten me (so I can avoid any issues like this in the future): Why not?
Now it works. but not in a nice way :-/
I now coded it different than the normal way you use vue2 with electron (and most of the other vue frameworks will not work )
lets see its a learning process 
:edit progress
In order to use 2 different jQuery version i did.
<script src="./assets/js/libs/jquery/jquery-1.11.2.min.js"></script>
<script>window.$ = window.jQuery = require('./assets/js/libs/jquery/jquery-1.11.2.min.js');</script>
<script type="text/javascript" src="jquery-3.2.1.min.js"></script>
<script type="text/javascript">
var octoJquery = $.noConflict(true);
</script>
and replaced the $ and other jquery stuff in octo_packed_client.js
not nice but now it works fine 
next step:
saving the config
I hate to ask, but why are you using two versions of jQuery? That's not really a long-term solution, as you've drastically increased every page load size and time, the time the JS parser spends before the page can work, and the amount of memory and CPU both the page and JS engine consume. You've also created a lot of duplicate event listeners and bindings.
It's a better solution to forward port whatever code you're using that has an ancient requirement, or to just write something from scratch. I mean, if this is an intermediary step in porting that code, and you're just showing off your development chops, I get that, but if this is an endpoint, I think you're going to cause a lot of resource constrained browsers (mobiles, tablets, Chromium on Pis, etc.) to run into resource contention that slows down and/or breaks your interface.
the css frameworks needs jquery 1.x ... 
Which CSS framework is that? Probably should use something a bit more modern for the framework if the one you're using requires jquery 1.x and can't handle something newer.
OctoPrint itself does seem to load an ancient version (2.2.4) in packed_libs.js in my browser, but that could be a plugin's fault as opposed to OctoPrint itself - not really sure. Oddly enough, it's not been run through an optimizer/minifier for the released version, but that may be intentional to make plugin development easier, or an artifact of a plugin. Both could probably pretty easily be packaged with OctoPrint and the non-minified one swapped in with configuration setting for plugin development (I know this was easy when I was developing in other languages for the web, so I'm guessing there's an easy python way, too).
Given the above, you may have 3 distinct copies of jQuery loading, which seems to be an awful lot of overhead for any resource constrained browser (even 2 is a lot).
octoprint uses
jQuery v3.2.1
==========
Version 3.0: Promises/A+ support for Deferreds, $.ajax and $.when, .data() HTML5-compatible
OctoPrint core may use v3.2.1, but something (probably a plugin) is also loading that older version. It's actually the very first thing in packed_libs according to my browser. Which means I've got 2 versions of jQuery already loaded, most likely.
Bootstrap 4 uses jQuery 3.2.1, so it may be worthwhile to port the theme you're using to it...not sure how hard it would be, but there may be guides, since Bootstrap is pretty popular.
It can be hard to keep up with Envato's constant license changes...you probably need to make it very clear that your plugin can't be bundled in any kind of commercial product that includes OctoPrint if you bought that template under their current licensing. They will come after you, not after whomever decides it's okay to do it anyway, unless you've made it crystal clear that it isn't, because you're who bought the license (unless it was already in the project and isn't licensed under their current model?). Nothing worse than having a bunch of lawyers chase after you for someone else's license violation.
i will later write my own framework some things are missing in this one ...
OctoPrint uses 2.2.4, but only because I had to bundle something and the last time I updated this stuff 2.2.4 was the current version. Not sure where that 3.2.1 version is coming from, but not core.
I wonder how much 3.2.1 would break? I don't remember the changes, but there are some posts/guides. jQuery said there weren't any major breaking changes, but there were some smaller breaking changes, so they bumped the version. There are also an upgrading guide and a jQuery plugin that will show you if anything needs to be updated for breaking changes, so evaluating it may be worth considering for your next major update.
They basically called jQuery 3 a continuation of jQuery 2.2, but bumped the major because there were some minor breaking changes, according to the blog post when they released it:
https://blog.jquery.com/2016/06/09/jquery-3-0-final-released/
For the record, OctoPrint 1.3.9 will ship with 3.3.1. Doesn't seem to break anything as far as I can see so far.
@danielkrah, since someone asked about farm frontends again on the Q&A sheet for the upcoming OctoPrint On Air, could you tell me what the state of this PrinterView fork of your's is? Is it "production ready"? I just gave it a quick test at printerview.moorviper.net and looking at the server log it's a bit spammy:
2018-06-06 14:47:48,088 - tornado.access - INFO - 200 GET /api/printer (127.0.0.1) 8.00ms
2018-06-06 14:47:48,115 - tornado.access - INFO - 304 GET /api/printerprofiles (127.0.0.1) 25.00ms
2018-06-06 14:47:48,122 - tornado.access - INFO - 200 GET /api/version (127.0.0.1) 5.00ms
2018-06-06 14:47:48,131 - tornado.access - INFO - 200 GET /api/job (127.0.0.1) 7.00ms
2018-06-06 14:47:48,141 - tornado.access - INFO - 200 GET /api/printer (127.0.0.1) 8.00ms
2018-06-06 14:47:48,167 - tornado.access - INFO - 304 GET /api/printerprofiles (127.0.0.1) 23.00ms
2018-06-06 14:47:48,174 - tornado.access - INFO - 200 GET /api/version (127.0.0.1) 5.00ms
2018-06-06 14:47:48,184 - tornado.access - INFO - 200 GET /api/job (127.0.0.1) 7.00ms
Seems to be querying with an interval of less than 100ms, might be causing a bit too much load on the server, so right now I'd not recommend it. Or am I missing something?
Yes i increased it because i am using a baytrail board and it can handle it.
I change it back to the default values.
I now have it locally on my machine and when i have a telekom intenet access again, and not that crappy ipv4 NAT by rhön energie m) ich can use it directly from outside my home.
One thing i will implement when i have the time is editing the printers but the DSGVO Bl$!&§T* came and i had to take of some websites down and currently fixing one site for our local Feuerwehr-page 
:edit
ok it was set to 5000ms
i found bug when deleting a printer.
the "cam" server runs on port 4000 for both.
I deleted the first of 3 printers and now the first has the cam port of the deleted printer 
I also started programming it as a electron app but there is a lot to do.
And Electron has actually some security issues ...
So as long you have a few printers it is usable / but when you delete one you have to delete all and readd them again.
(As long the deleted was not the last printer.)
:edit2
// remove the printer from the page
document.getElementById("printer"+index).remove();
// remove the printer from the printers object
printers.ip.splice(index, 1);
printers.apikey.splice(index, 1);
ok there i forgot to delete the printer cam port
The deleting of the cam port should now be fixed.
Hello,
I set up a local version of you modified PrinterView and I've run into a snag. With the original version I was able to add multiple IP's and API keys to index.js so the page loaded with all the printers for anyone. when i add my ip's, api keys, and camera ports to index.js, it only loads the first printer.
are you using a different format than "ipaddress1","ipaddress2", etc... or "apikey1","apikey2", etc or "camera port1","cameraport2",?
thanks in advance,
Brian
Oops, i take that back,
none of the printers i tried to preload are showing up once i switched to a browser that had never added any printers to an instance of printerview.
Brian