Description of problem: I recently updated from fedora 21 to 22 using fedup and have noticed that in Pronterface the Extrude, Reverse and Print Speed modifier numeric entry fields are not shown in the UI. I am running KDE as my desktop. I do not know if this affects GNOME also. Version-Release number of selected component (if applicable): printrun-2014.08.01-1.fc22.src.rpm How reproducible: Every time. Steps to Reproduce: 1. Start Pronterface under KDE on fedora 22 2. Observe the Extrude, Reverse and Print Speed modifier numeric entry fields are not shown Actual results: Information is missing from the Pronterface UI. Expected results: Pronterface should perform as it did under fedora 21 and show all input fields. Additional info:
Could you share a screenshot please?
Created attachment 1038790 [details] Screenshot of missing UI elements This screenshot was taken after removing .pronsolerc and .pronsolerc~ i.e. a fresh start. I am wondering if the problem is insufficient space to insert the widgets due to KDE's much larger widget sizes in KF5. There is no means to drag the left hand area size now the expander/reducer buttons are present so I cannot test this idea. The problem is still visible with a fully maximised window.
Actually, this is probably related to the move to wxPython 3 which is now built against GTK3. It looks like the GTK3 widgets are larger than their GTK2 counterparts and there isn't enough space allocated for them.
Well, I have wxPython 3 on Fedora 21 (from Copr) in Xfce and I can see the input fields quite well. Haven't had time to test actual Fedora 22 yet.
Yes, it looks to be a GTK3 thing. Firefox, which also uses GTK3, has huge widgets in the add-ons preferences and its own preferences dialogs. I initially thought that KDE was the culprit because large parts of its desktop are also oversized but that's due to the KDE Developers assuming we all have 200+ DPI displays on our desktop systems.
@Miro, I see you made a commit[1] upstream to resize the widgets, are you sure you're not running with that change in place? [1] https://github.com/kliment/Printrun/commit/acc9117dbcb9b06c9f1e81084727f9ec78b8c722
Quite sure. But let's just upgarde the package to https://github.com/kliment/Printrun/releases/tag/printrun-20150310 and see if it gets any better.
Could you check? http://koji.fedoraproject.org/koji/taskinfo?taskID=10164315
That helps some, but the widgets still need to be resized further probably.
Given that printrun does not receive much attention, is there a case for rebuilding the package against wxPython-2.x? I know the voices of reason within fedora would say that it should be built against wxPython-3.x but there are a few mitigating factors: 1) This problem was observed some time ago with GTK3-3.15.4 but went away with a later update only to resurface again. 2) The pronterface UI is hard-coded and offers no resiliency against widget size changes. This is exacerbated by the recent switch from having a resizing capability to the use of panel hiding buttons. Right now I am without the utility of being able to easily manually extrude and rewind material for filament changes. Entering GCodes to achieve this by hand is tedious and error prone. Something needs to be done here as fedora is somewhat limited in choice for 3D printing hosts since the closed-sourcing of Repetier. We only have cura and repsnapper as alternatives and they have their own problems relating to currency.
Well, that would mean we would need wxPython 2 compat package in Fedora. Scott?
Also, Neil, if you could open /usr/lib(64)/python2.7/site-packages/printrun/gui/controls.py and try some fiddling with numbers until this is fixed? We can than patch it on Fedora level (or even propose the changes upstream). This commit being an inspiration: https://github.com/kliment/Printrun/commit/acc9117dbcb9b06c9f1e81084727f9ec78b8c722 I could do it, but not until next week.
I've taken a look at that code and it's horrendous. Given that I'm not a Python programmer and it'll probably take more than a week for me to get up to speed on how all this stuff works, seeing as there are multiple variants of the UI, I'll have to leave that aspect. I recall, years ago doing some of this style of layout code and it was all based on metrics of the letter "M". The controls were sized based on that and you had the flexibility to change font sizes as you pleased. This is not how to implement a IU. I can see why it is all but abandoned.
Heh, right :D
The problem really isn't wxPython 3, but rather wxPython built against GTK3. In order to get wxPython 3 built against GTK2, we would have to build wxWidgets 3 against GTK2, and the last I checked with the wxWidgets maintainer, he wasn't interested in doing that. I can't say that I totally disagree with him, as Fedora generally tends to be a forward-looking distribution. I suggest the following: 1) I'll take a stab at a patch for adjusting the widget sizes for now. 2) We encourage upstream to remove the hard-coded widget sizing and move to a more dynamically sized UI.
Sorry to be unhelpful on this occasion. Still coping with the after-effects of a general anaesthetic from a week ago (and more to come this Friday). With respect to creating patches, I noticed that it's not just the main window that is affected. The Settings|Options dialog is also affected. I don't know how amenable upstream is to fixing this. I think Pronterface et. al. are receiving minimal development effort. Any patches Scott produces might be the final solution.
Neil, what problem(s) are you seeing on the Settings->Options page? The spin controls in the Build Dimensions section? I'm also seeing a problem with the FloatCtrl not working quite right - they don't seem to be working with floating point numbers, only integers. I'll have to investigate that.
Scott, thanks for offering help.
Created attachment 1044736 [details] Screenshot of Options dialog In this screenshot of the Options dialog the "Build dimensions" value entry fields are large enough for only one digit to display. Additionally, the field to the right of "Extruders count" appears to be missing a label.
Still working on this as I'm working on sorting out what's going wrong with the FloatSpin controls (not anything Pronterface is doing wrong).
Created attachment 1046122 [details] Patch to fix widget sizing and replace FloatSpins OK, I think I have a working patch that resolves these issues. FloatSpin is still broken (I reported upstream), but I ended up replacing those widgets with SpinCtrlDouble's, which is generally a better solution. SpinCtrlDouble is new in wxWidgets 3.0, so that is why it probably wasn't used previously. FloatSpin is a bit of a hack - it involves trying to hide part of the GtkSpinButton. Anyway, take a look and let me know what you think.
Thanks Scott, I've built a scratch build http://koji.fedoraproject.org/koji/taskinfo?taskID=10290544
The left side looks pretty wide and I got a traceback when I went to settings -> options -> user interface -> [uncheck] display temperature graph
Created attachment 1046166 [details] Screenshot after patch from #c19
Can you be any more specific about "the left side looks pretty wide?" I can reproduce your traceback, but only the first time I uncheck "display temperature graph." It seems to be something that goes away once there is a certain entry in ~/.pronsolerc.
Well, I meant that after the patch, the panel lost it's compactness and consumes much more space than before. I think the usability has decreased. But it is probably only my personal view.
Well, unfortunately, the way that GtkSpinButtons are in GTK3, the buttons are now side by side instead of stacked as they were in GTK2. This means the widgets are a lot wider. I made all of the spin buttons wide enough so that all digits would be visible (as per the max value settings of the spin buttons that were in place). If the app doesn't really need all those digits, we could probably make the widgets a bit smaller.
For guidelines on this we could go with: Temperatures: 3 digits Measurements in mm: 3 digits Speed in mm/s: 3 digits Speed in mm/min: 5 digits Baudrate: 6 digits A lot of the fields in the Options dialog are hugely oversized. Perhaps we can settle on a solution that is a balance of useful functionality over aesthetics. The only downside I can see is that for smaller displays (I am talking 1280x1024 and below) users might have to choose the Tabbed GUI option. I have a 1920x1080 screen (100dpi) so can happily cope with a wider real-estate but I do need to see all the labels and numbers.
Neil, the widget widths are basically already setup for those quantities of digits. The Printer Settings dialog is actually one place where the widget sizes are not hard-coded (except for the Build Dimensions section). Thus, the page width is basically determined by the width of the Build Dimensions items.
Scott, Then we have another problem! In .pronsolerc I have the following entry for Build Dimensions: set build_dimensions 200.00x200.00x200.00-100.00-100.00+0.00-100.00-100.00+200.00 You can see some 200.00 and 100.00 values. The options dialog shows 0 for all values associated with Build Dimensions. So, either the controls (are they called spinedit?) is showing the values incorrectly or the code is failing to parse the settings line and everything is defaulted to 0.
Hi, I've just tried Miro's scratch build and it works... almost! It addresses the the problem I observed in comment #30 above but there is still a significant problem i.e.: When the right-border is dragged rightwards, to increase the main window size, the widgets in the left-panel increase in size. This is, I guess, expected? However, when the right-border is dragged leftwards, to decrease the main window size, the widgets in the left panel continue to increase in size. This is not at all what I would expect.
That was already reported here: https://github.com/kliment/Printrun/issues/615#issuecomment-96334442
Hi Miro, What is the current status on this? Your earlier scratch build repository has been deleted so we only have the broken packages available to fedora 22. Can we get Scott's efforts into a package update so that Pronterface is usable on fedora 22 and later? Regards, Neil Darlow
Oh, sorry. Should I just push the same thing that was in the scratch build?
Hi Miro, I would say yes but can you please see if it is possible to fix #1250668 at the same time? Regards, Neil Darlow
As a side note, upstream wxWidgets did supposedly fix the issue I reported with FloatSpins. So, assuming it works, and we get the patch in Fedora, we could consider going back to FloatSpins. The only advantage I can see is that it would make this patch more attractive to upstream as it wouldn't require a wxPython 3.0+ feature. I don't know if you plan to try to push this upstream or not.
I would like to push this to upstream.
(In reply to Miro Hrončok from comment #37) > I would like to push this to upstream. Do you think they will object to forcing wxPython 3.0+?
(15:32:29) iXce (upstreram dev): I'd rather keep backwards compatibility as much as possible
(In reply to Miro Hrončok from comment #39) > (15:32:29) iXce (upstreram dev): I'd rather keep backwards compatibility as > much as possible OK, I'll see about reworking the patch to go back to FloatSpins.
(In reply to Scott Talbert from comment #40) > (In reply to Miro Hrončok from comment #39) > > (15:32:29) iXce (upstreram dev): I'd rather keep backwards compatibility as > > much as possible > > OK, I'll see about reworking the patch to go back to FloatSpins. Upstream patch for fixing FloatSpins seems to work, but I'm still getting an invalid rectangle error - investigating that.
Created attachment 1061786 [details] v2, updated to support wxPython < 3.0 OK, so I'm still a little wary of the GTK+3 FloatSpins, so I decided to just implement a check for the wxPython version and use FloatSpins when running on wxPython < 3.0. Updated patch attached.
*** Bug 1274415 has been marked as a duplicate of this bug. ***
I just tested the above patch from Scott and it works. Miro, can we apply and build?
I have been using the earlier patch for some time now. The update to GTK3 also impacts the Plater program but that is so quirky I tend to use Slic3r to perform that function.
On it. Sorry for the long delay.
printrun-2015.03.10-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-9930ac9ba1
printrun-2015.03.10-2.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-b192b7af01
printrun-2015.03.10-2.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update printrun' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-b192b7af01
printrun-2015.03.10-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update printrun' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-9930ac9ba1
printrun-2015.03.10-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
printrun-2015.03.10-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.