Created attachment 1922728 [details] screenshot Description of problem: 1. model view does not draw (main problem) 2. buttons seem to have lost their styles (cosmetic) (see attached screenshot) You can still print, but cannot see what is being printed. Version-Release number of selected component (if applicable): pronterface-2.0.0-0.23.rc8.fc37.noarch dependencies versions: python3-wxpython4-4.2.0-1.fc37.x86_64 python3-pyglet-1.5.23-3.fc37.noarch python3-psutil-5.9.1-1.fc37.x86_64 python3-gobject-3.42.2-2.fc37.x86_64 python3-dbus-1.2.18-5.fc37.x86_64 python3-cffi-1.15.1-2.fc37.x86_64 python3-cairocffi-1.3.0-5.fc37.noarch simarrange-0.0-3520170316git8238ce5.fc37.x86_64 python3-3.11.0~rc2-1.fc37.x86_64 How reproducible: 100% Steps to Reproduce: 1. run pronterface 2. 3. Actual results: cannot see what you print Expected results: can see what you print Additional info: stdout repeatedly prints error message, not sure if related: (pronterface:5224): Gtk-CRITICAL **: 14:03:46.877: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton
Sounds like https://github.com/kliment/Printrun/issues/1283 I am a bit swamped with other things. Scott, do you have any idea?
(In reply to Miro Hrončok from comment #1) > Sounds like https://github.com/kliment/Printrun/issues/1283 Yes, that issue looks the same. Tried to downgrade python3-wxpython4, but that looks pretty impossible if you don't want to downgrade half of the system (the RPM has dependence on exact python(abi) version, as other packages do, and downgrading one implies downgrading them all). We need a fix, though not sure if for pronterface or for python3-wxpython4.
I have a hunch about this. I'll take a look later today.
Created attachment 1923433 [details] Screenshot from swt2c Is this what the GUI is supposed to look like?
Yes, more or less. > 1. model view does not draw (main problem) This seems fixed. You can download a gcode file, e.g. https://churchyard.fedorapeople.org/cube.gcode and load it with $ pronterface cube.gcode (or the Load File button in the middle of the top bar) and the middle view should give you a preview of 9 cubes. It should allow a 3D rotation via mouse. > 2. buttons seem to have lost their styles (cosmetic) This seems to still be the case. ----- I'll attach a screenshot from Fedora 35.
Created attachment 1923534 [details] Screenshot from Fedora 35
Great, looking forward to test a F37 build of your fix.
Okay, so my fix seems to resolve the issue with the model viewer - I tested with Miro's cube.gcode and it seems to work. On the issue with the button sizing, that seems to be an intentional change in wxWidgets (see https://github.com/wxWidgets/wxWidgets/commit/215a6ee238fdc0bafab79aab0a529aea8e6bba08) as pronterface seems to be using the wxBU_EXACTFIT style. I'd suggest taking this one up with upstream pronterface if it is really that big of a deal. I would argue that wxWidgets is doing the "right thing" with the "exact fit" style. Back to the issue with the model viewer. This one is a bit complicated and is somewhat my fault. So, I implemented OpenGL EGL support in wxWidgets because the existing GLX support didn't work on Wayland as it is X11-only (Miro, you may recall the patch we put in to force X11 in pronterface because of this...). This new EGL support was enabled by default and is an either/or compile option at the moment. Unfortunately, when using EGL, the pronterface viewer is broken - perhaps because the other OpenGL library (pyglet) isn't working with EGL. Because of this, and some other applications that have been broken (e.g., hugin which uses glew), I've come to the realization that the world isn't ready for EGL-only in wxWidgets. Rebuilding with GLX support resolves the problem. The downside of this is that it involves an ABI change, so any packages that use wxGLCanvas need to be rebuilt. Even trickier, unfortunately this is a little harder now that F37 is released, but I suppose can be down. I'll probably open up side tags in F37 and Rawhide, ask the wxGLCanvas package users to rebuild their packages, and if that doesn't happen quickly, I might try to flag down a provenpackager to help (hi, Miro!). So, in the case of pronterface, the fix only involves rebuilding wxGTK and python3-wxpython4.
> I'd suggest taking this one up with upstream pronterface if it is really that big of a deal. Not a big deal for me. > I might try to flag down a provenpackager to help (hi, Miro!). Sure thing. Just let me know the list of packages and side tags to build in.
Should fix the model viewer for F37: https://bodhi.fedoraproject.org/updates/FEDORA-2022-6be9e24d9c
Fixed now in F37 + Rawhide.
Thank you so much, Scott!
Thanks a lot, the model view is now back after updating via # dnf upgrade --refresh --advisory=FEDORA-2022-6be9e24d9c A few minor issues with controls still remain: * buttons above/below the model view still compressed (cosmetic) * flow/speed controls only work by mouse dragging the scrollbar, buttons "+"/"-" or inserting a value manually dumps following error on change: Traceback (most recent call last): File "/usr/lib64/python3.11/site-packages/printrun/gui/controls.py", line 200, in speedslider_spin root.speed_slider.SetValue(value) TypeError: Slider.SetValue(): argument 1 has unexpected type 'float' Any changes made these ways won't be sent to printer by pressing the "Set" buttons. Did not find this problem for the original bugreport, but have seen it last week before the update. Are you going to address this? Should I open a new bugreport?
TypeError: Slider.SetValue(): argument 1 has unexpected type 'float' is definitively a different bug. It has been fixed upstream via https://github.com/kliment/Printrun/commit/302ed8a1aa012552529d5abd30f4b40b0b429580 and I can backport it.
On your first issue, if you're referring to the button sizing that you noted previously, please refer to my previous comment about the code using the "exact fit" style. I don't plan to do anything about this. And yes, on the second issue, it's an unfortunate Python 3.10-ism. That backport should fix it.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-f700a8f04f
Thanks a lot, flow/speed controls now look fixed.
Still not very stable, hangs after a few hours of printing.. wonder if it prints something on stdout when started from console
Hang reproduced - looks like livelock with printing in loop "Attempted to write invalid text to console, which could be due to an invalid baudrate", at least in this case. Probably unrelated to this bug, can open a new one when knowing more. Thanks for fixing.