Progress 2.0 #26
Draft
Progress 2.0 #26
Conversation
This file contains 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
* Update POTFILES * Update progress-tracker.pot * Update all available .po files
Fix bug where the background was saved only if the board's name was modified as well (cherry picked from commit 550e25b)
(cherry picked from commit fb491d1)
* Add task removal * Add click gestures for TaskWidget objects
* Update Brazilian Portuguese Translation * Mark "Task Name" string as translatable
* Remove unnecessary includes * Bundle all binary objects into 'progress-tracker'
runtime error * Include <app_info.h> where necessary * Set GSK_RENDERER to opengl only on WINDOWS PLATFORMS * Hide button frames of EditableLabelHeader objects
smolBlackCat
force-pushed
the
new-feature
branch
from
8ef401e to
66d8d18
Compare
* Mark new strings for translation * Discard old UI
smolBlackCat
force-pushed
the
new-feature
branch
from
55675fc to
74a625e
Compare
What was causing the issue was bad colour conversion approaches taken
Because BoardBackend::load is proper for locking the GUI main loop, mainly when connecting to the internet, a better approach to the problem is to simply delegate the task of loading board data into memory to a thread. Current issue is that the background does not seem to be updated even after properly synchronising data access with std::mutex and Glib::Dispatcher
…f GTK resources outside the GUI thread
…card This is a quick fix, but it stems from a fundamental problem that the data model is poorly designed
…e the AdwAboutDialog Adwaita and GTK are meant to work together, not the other way around apparently. Even though it was possible to set a AdwAboutDialog to a GtkApplicationWindow, it appears that it's been a silent problem for some months, causing the app to break.
By adding class scope, we don't need to allocate memory every time the user opens the card dialog. The approach taken is to define a CardDetailsDialog instance as a member of ProgressWindow and have a CardWidget get the root (ProgressWindow) and open the dialog. The functionality is as equivalent as the later implementation. The memory leak is still in investigation since the approach taken by the app is quite new. Also GTK is known to quite lazy when dealing with memory pages
* Remove can-close workaround * Properly use AdwDialog builder UI
* Properly use AdwDialog UI builder * Remove can-close=false workaround to be able to close dialogs using adw_dialog_force_close
smolBlackCat
force-pushed
the
new-feature
branch
from
d677691 to
de1ee48
Compare
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.
A series of features will be implemented in this iteration of the application. The branch is not expected to work 100% all of the time as it is development focused.
Features