Open korneelb opened 8 years ago
It likely would not run well because the Pi has limited CPU power to both run the browser and OctoPrint
A RPi Model 2 B should be more performant for running the OctoPrint server with its addl. RAM and multiple cores. I was planning to try exactly this ("official" 7" touchscreen on B 2) but haven't gotten around to it yet for testing.
I read this issue, and then noticed these on the Touch UI plugin wiki to do the autostart stuff. https://github.com/BillyBlaze/OctoPrint-TouchUI/wiki/Setup:-Boot-to-Browser
@korneelb, perhaps you could try the steps listed there to get it working and report back on how it goes?
If someone writes a script for that we can ship it with OctoPi. Guy
Would also help if whoever writes a script for that also offered to continue maintaining that script (as in, making sure that following versions don't accidentally break something and everything still works). Neither of us has one of those displays on hand, so we can't test ourselves.
I'll take a look at creating a script. I have two related questions:
2015-12-19_2015-11-21-octopi-jessie-0.13.0.zip
from http://docstech.net/OctoPiMirror/nightly/I resolved my own questions
2015-07-02_2015-05-05-octopi-wheezy-0.12.0.zip
)src/filesystem/home/pi/scripts/
in the repoDeveloping and testing script WIP.
So I had some time to work on this and tested on a Pi Model 2 B with the touchscreen display. From the commit log:
Tested on a freshly configured wheezy OctoPi install on a Model B 2.
After running script and reboot, starts into X/iceweasel on localhost:5000
(OctoPi interface) as intended.
Ideally, still would want things like proper plugin presence detection and
possibly other tweaks. See TODO section in script.
Here's the bash script in a forked repo (made edit in devel
branch):
https://github.com/dpcrook/OctoPi/blob/devel/src/filesystem/home/pi/scripts/boot-to-browser-touchui
I could probably test in the future too. One problem I encountered was that I couldn't get OctoPi to work on any of the other available images built (jessie, jessie-lite nightlies, etc.). Only was able to get the official latest wheezy image to work.
If I could add something to the touchui setup.py file so I can make it presence known (i.e. add a file in the home folder), dont hesitate to ask :) But what if an user installs and then uninstalls it? As far as I known there is no uninstall hook so I can remove it again.
I think it might be possible that An external python script could be run that tries to import the plugin, and reports success+version/ fail. I just didn't know how to do that yet. I'll take a look today
I am having difficulty figuring out how to use existing octoprint code to determine whether a plugin is 1) installed, and 2) enabled.
I started wading through src/octoprint/plugins/pluginmanager/__init__.py
, but surely I am not the first to try this from an external script. Is there any example code someone could point me to?
Can't PIP help you out on the installed part?? Something like /home/pi/oprint/venv/bin/pip freeze | grep TouchUI
As for the disabled part you could check the config.yaml if the plugin has been disabled.
Thanks. I actually figured out how to check a plugin's status in a python script using OctoPrint's Plugin Manager directly.
In my OctoPi fork on GitHub, I uploaded the python script along with edits to the installation wrapper to invoke it:
I tested the python script out on a running OctoPi installation, so I feel it is ready for a pull request...
when I tested TouchUI with the B2 back when I first got my Display it was pretty sluggish, so I went ahead and made my own touch interface with kivy which interfaces with the octoprint API. I plan to put this on github soon-ish, however as kivy + the Xserver would add quite a bit of additional dependencies to the package its propably best to keep it seperate (maybe provide an installation script)
Well thanks for reporting the sluggishness :+1: There have been several updates in TouchUI, including an upgrade to the KWEB3 browser and a touchscreen mode that disables CSS3 opacity animations to address this sluggishness.
Remember TouchUI is not only for touchscreens, but also for mobile's and tablets, so I have to rely on feedback to get it working smooth on multiple platforms. I am currently working on a new version, that will step up TouchUI to be more mature on mobile and tablets, but mostly addresses several issue's for touchscreen (including too much scrolling and more use of the screen)
@BillyBlaze , don't get me wrong here, I love TouchUI for tablets, I just don't think it is necessarily the best fit for a Pi which is already busy hosting OctoPrint et al.
I also suspect that this is highly dependant on the browser, if I remember correctly I tried with chromium. Did you get good results with KWEB3?
Thanks and sorry if I sounded agitated. Yeah I officially didn't support that Chromium version for this specific reason. KWEB3 has a far superior JS engine and very low footprint on CPU and Memory. Even while printing and doing TouchUI interaction.
There also have been a fix(es) in OctoPrint and TouchUI that makes everything alot better.
I initially found touch ui to be sluggish. But with the latest upgrades and running on a Rpi 2. It runs beautifully.
I would love it if there was also a setting that you could turn the screen into just a status screen, i.e. If someone doesn't have a touchscreen, they can still use a small screen to show basic status like print time etc. ... Or maybe support for an adafruit 16x2 GPIO lcd display (If your printer doesn't have an LCD built in)
kind of a waste of a screen. I got me a Chinese 7" android tablet for $35 and use that tablet's browser as my control screen. I'd keep the PiTFT for other projects.
@seefood I don't think it's a waste of a normal screen, but definitely that of a touch screen.
On Wednesday, March 23, 2016, Ira notifications@github.com wrote:
kind of a waste of a screen. I got me a Chinese 7" android tablet for $35 and use that tablet's browser as my control screen. I'd keep the PiTFT for other projects.
— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/guysoft/OctoPi/issues/189#issuecomment-200230995
--DJ
Er assuming this can be closed with such an issue like #364 being open. Closing if no reply.
I don't think my pull request above was ever merged, but I am fine with closing.
So how are people installing?
@idcrook I don't think you ever PRed that script. I am not sure myself.
@foosel do we what this in scripts? https://github.com/dpcrook/OctoPi/blob/devel/src/filesystem/home/pi/scripts/boot-to-browser-touchui
@guysoft they did a PR, it's linked up there, #191.
I think asking @BillyBlaze for an opinion here would be best. The only issue I see here is that if the necessary setups steps might change, an outdated script shipped with the image might cause him trouble down the line.
In any case, I think the contents of the PR probably are no longer up to date, so it would necessitate some work by someone with the screen on hand & ideally experience with the involved steps (I only run TouchUI on my phone). And I'd also suggest to simply make installation of the current version of the plugin part of the setup script (/home/pi/oprint/pip install https://...
), instead of firing up a full blown OctoPrint application context just for checking if it is there.
@guysoft PR was idle for a while (idcrook commented on Nov 5, 2016) so I "un"PRed it.
I do not have time or setup right now to see if the old bash script way still works at the moment but I'll leave repo/commit around in case it is of archaeological interest at https://github.com/idcrook/OctoPi.
P.S. my GitHub username has changed from dpcrook
to idcrook
in the meanwhile as well.
Hi; with the launch of the PiTFT 7" touch screen, would it be an option to include a script that enables the touchUI plugin and then an autoboot to the browser pointing towards the web interface of OctoPrint? this would give people a very easy way to launch the TouchUI..