* It is untested by CI and adds a lot of complexity compared to manually
compiling toxcore and toxext in a couple commands. This also exposes
the cmake configs rather than wrapping them in an out of date list of
script configs for users.
* It is only partially covered by CI and doesn't simplify the build process
much for users. Replacing it in CI with just build-osx.sh significantly reduces
script complexity and is fully tested.
* bootstrap-osx.sh copying system libs and headers locally is unneeded.
Already the DMG file contains them, and re-linking the app against
updated system files may be desirable.
* Update INSTALL.md for macOS to use brewfile, use common dependency build
scripts, and use cmake rather than wrapper scripts.
* Build macOS in Release mode in CI, for release artifact creation
* Don't copy all used libs into a local folder, macdeployerqt already
handles this for the dmg, and for local running of the app using the
system libs and relinking on update is desirable to avoid running out of
date dependencies unexpectedly.
Was used to update all the duplicate versions of toxcore spread around the
repo. Now all builds and user instructions for the version come from
buildscripts/download/download_toxcore.sh directly, so this script serves no
purpose.
Mick Sayson (3):
fix(filetransfer): Fix UI inconsistencies with pause/resume
refactor(filetransfer): Move file transfer progress into ToxFile
feat(filesform): Add in progress transfers to files form
Motiviation:
* Reproducing issues in CI is currently difficult
* Predicting issues in CI is currently difficult if you are not on
ubuntu 18.04
* Reproducing issues submitted from other distros is currently done by
creating a VM of that distro and building qtox for it locally
* Documentation for how to build on different distros is out of date
* Issues on non-ubuntu distributions are not caught by CI
* Cross compiling for windows locally is not trivial
* Iterating when working with custom build scripts is slow, scripts
don't necessarily support re-running without re-starting the docker
container and re-building qtox again
* Updating dependencies is a pain
Changes:
* docker-compose file has been added to the root of our repo.
After `docker compose run --rm ubuntu` (or other supported distros),
you are ready to compile and run qtox
* Dependencies are owned by dependency install scripts in buildscripts/.
This allows us to use the same exact dependencies in our
OSX/windows/linux scripts
* New docker images have been added for a variety of distributions.
These are now run in CI in a variety of configurations
* Docker images are cached in CI so rebuild time for the majority of
jobs is quite quick
* Build scripts have been trimmed to leverage state of docker
containers.
* Windows build script no longer installs anything, dependencies are
now managed by the windows_builder docker images
* Build scripts should now be easily re-runnable. Usage is now `docker
compose run --rm <image>` and then run the scripts
* All artifacts are now uploaded to github after build, this means we
can take an appimage/flatpak/exe/dmg for any given PR and try it out
without having to build it ourselves
Notes:
* Docker image size is quite important. We have a maximum of 5GB cache
space on github actions. The majority of the linux distro docker
images cache at ~300-400MB, which gives us room to test ~6 distros
after accounting for the sizes of flatpak/windows docker images
* Docker layer ordering is relatively intentional. Approximate order
should be that large dependencies that change infrequently should be
farther up. This lowers the amount of rebuilding we have to do when
dependencies are updated
* download_xxx.sh scripts are the cleanest way I could find to implement
a shared dependency map between osx scripts and docker containers.
Although it would be nice to have a single dependency mapping file,
splitting it into individual scripts allows us to only rebuild some
docker layers when dependencies are updated.
* Github actions are split between docker image building and docker
image use. This allows us to re-use the same docker images for
multiple jobs, but only build it once
* Unfortunately I could not find a way to de-duplicate the stitching
between jobs, so we have a lot of copy pasta in that area
As part of #1532 it was identified that long running file transfers
could get lost deep in the chatlog. This could result in unexpected use
of bandwidth over time if users lose track of old/large transfers. This
commit updates the files form to show in progress file transfers and
offer a way to control them.
* FilesForm now works on ToxFiles instead of finished file paths
* FilesForm widgets have been replaced with an MV tree view with depth
1. The existing QListWidget did not provide us the controls to render
more complex items. The use of delegates allows us to efficiently draw
progress bars and controls
* getHumanReadableSize has been extracted from FileTransferWidget into a
more general utils file
* Refactor/test ToxFileProgress to ensure that when it's moved it
behaves well
* Notice problems with speed averaging. We were average speeds without
keeping track of the times they were over. Adding samples of different
lengths would result in incorrect speeds. Refactor whole class to correct
* Move ToxFileProgress to be a member of ToxFile
* Remove duplicated members between ToxFile and ToxFileProgress
* Move sample addition into CoreFile
By profiling qTox using perf I discovered, that
NotificationIcon::updateGradient takes significant amount of CPU time
even though qTox is idle and no one is typing.
This commit fixes:
1) correctly determine visibility of NotificationIcon
2) only invalidate boundingRect in fixed intervals
3) apply the same fixes to Spinner since it has the same problem
Anthony Bilinski (20):
revert(chatlog): "fix stick to bottom behavior"
revert(chatlog): partially revert "prevent invalid history access"
revert(chatlog): "add comments for functions that load history"
revert(chatlog): "scroll bar stuck to bottom (fix#5755)"
revert(chatlog): "update workerStb"
revert(chatlog): "optimize load messages during the search"
revert(chatlog): "feat: save selected search text after scrolling up"
revert(chatlog): "feat: check chat status before start a search"
revert(chatlog): "fix: data validation during the search"
revert(chatlog): "fix a crash when there are no messages to load"
revert(chatlog): "prohibition to remove messages in group chat"
revert(chatlog): "edit load history when scrolling"
revert(chatlog): "simple edit code"
revert(chatlog): "remove part messages from chat"
revert(chatlog): "edit position chat after load history"
revert(chatlog): "add action "Go to current date""
revert(chatlog): "edit load history in search"
revert(chatlog): "edit function "Load chat history""
revert(chatlog): "load messages from the database after date"
chore(review): Copyright notice cleanup
Mick Sayson (8):
fix(history): Fix qt deprecation warning
revert(chatlog): "feat: load messages from the database before date"
revert(chatlog): Revert cleanup
refactor(chatlog): Move rendering of messages from GenericChatForm -> ChatLog
refactor(chatlog): Store ChatLine::Ptr in messages instead of ChatMessage
feat(chatlog): Re-implement sliding window ChatLog view
refactor(chatlog): Remove unused getRow functions from ChatLine
refactor(chatlog): Rename ChatLog -> ChatWidget
* Replace lines/messages with helper class to synchronize state between
IChatLog and ChatLog more easily
* selection indexes have been replaced with ChatLine::Ptrs, this is to
ensure consistency while the view slides around
* This has another benefit of removing all the code that has to
manually slide the selection boxes around
* Replaced all insertion/removal functions with single "insertAtIdx".
This helps ensure that mappings between ChatLogIdx and position within
the view are captured correctly as items in the view slide around
* workerTimeout replaced with more generic name "renderFinished" that is
used in synchronous and asynchronous paths
* Removed unused function ChatForm::insertChatMessage
* Re-implemented "Go to current date" with new ChatLog APIs
* Removed unused GenericChatForm::addSystemDateMessage. This is handled
by ChatLog now
* Resolves#6223
* Resolves#5878
* Resolves#5940
* Simplifies reasoning about who owns what functionality between
GenericChatForm and ChatLog. GenericChatForm is now just a layout
class and ChatLog handles all interactions with retrieving and
displaying messages from the model
* Reasoning for work is described in more detail in #6223
