Bugfix thumbnail not working #123
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
HugoCLSC
force-pushed
the
bugfix-thumbnail-not-working
branch
from
c10a58f to
d119313
Compare
HugoCLSC
previously requested changes
Dec 12, 2025
Instead of only requesting the available files when Klippy is ready request them when websocket opens. Moonraker handles the files, so there is no need to wait until klippy is connected. This also ensures that when the screen connects with moonraker and klipper the information about all available print files are ready to be handled by the GUI. This stems from a problem loading the thumbnails. There were many instances of initializing the application mid print, when this happened a request for the available thumbnails is made, because the files are loaded after receiving the klippy ready event, the moment when asking about the current job thumbnail there are not files nor metadata loaded onto the GUI, so no thumbnail is fetched. Now with this change the same situation doesn't occur.
There is no need to add list type to the signal. The thumbnails were passed there before, we will load the print thumbnails when we get the metadata from the file. Passing the thumbnails here was unnecessary.
The progress bar fills a circumference until the print is complete, the inner part of the widget is blank and is suposed to have a thumbnail of the current print, before a QGraphicsView overlaped with the progress bar widget. Now we add the functionality to add a pixmap on the progress bar itself. It calculates the scaling for the pixmap to fill the inner part of the progress bar widget without overlaping anything. There are some bugs still, such as what happens when resizeEvent is emitted, the automatic scaling is not working properly yet.
The solution provided by @Robert0Mart showed us that the thumbnail building needed some work, this commit intends to extend that effort to rewrite this feature. We will simplify thumbnail building, less widgets for this feature to work. We will also let the progress bar widget handle the small widget painting, and propagate the click to expand to a bigger thumbnail painting that fills the entire screen.
Refactored class method positions to add some structure to the class. Privatised some class variables, should add @Property decorator with getter and setter for these variables since they are actually properties. Captured MousePressEvent of the widget and filtered the events only to those inside the inner rect of the widget, when triggered, send an event `thumbnail_clicked` to signal that the thumbnail was actually clicked.
Added type for argument, refactored method body readability
Added initial thumbnail expansion, it works, but it needs to be worked on. We need to hide all widgets so that the thumbnail doesn't have anything on the background while its expanded. this requires us to hide all widgets used one by one. it's not incorrect per-se but it's not the best. The thumbnail is loaded once when the thumbnail is received, so it just paints once and stays in memory until `.show()` and `.hide()` methods are called. Once the print stops for whatever reason. Since the widget is built when the thumbnail comes, the QGraphicsView and its childs are deleted, freeing memory. It'll be built again when a new print job is selected.
Reduced branching on printer object handlers, Added simple docstring to the `jobStatusPage` class.
When the provided thumbnails are Null Pixmaps, the should not build the QGraphicsView Widget. Before , even when pixmaps were null, it whould be built, the user could click the progress widget and the scene whould expand, only without anything to show. Now the widget simply does not build anything when all pixmaps are Null. The click signal connections are now done inside the `_load_thumbnails` method, the progress widget pixmap is also set inside that method. Everything related to thumbnails (except the eventFilter method) is now handled inside the `_load_thumbnails` method. The next step, filtering the provided Null Pixmaps. Only load not Null pixmaps
Simplified thumbnail filtering. Now i can have any number of Null pixmaps, if no pixmap is usable, cancels thumbnail loading, if there is at least one usable pixmap. It'll load the thumbnails on the progress widget and on the QGraphicsView. This means that if only the smallest resolution is available (48x48) it'll paint with low resolution
HugoCLSC
dismissed
their stale review
The problem was resolved, by going with another approach to the problem of the thumbnails
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What Changed?
Fixed Thumbnails not updating correctly or missing thumbnails
Changes