The popup to invite friends to communities has so far always been a brand new
popup that's opened on top of possible existing popups.
The design however, expects that the same section should be shown as part
of a wizard-like process inside of the existing community profile overview
popup, when entered from there.
This commit extracts the invite friends popup section into component that
can be reused as stack view, as well as modal content, to implement both
scenarios.
This commit changes a bunch of things related to ui bugs in the community
profile popup. Fixes include:
- Removing the `Delete Community` option since this functionality isn't implemented yet
- Changing the color of the menu item's icons in dark mode to be blue
- Doing the same in the memberlist popup
There's a regression in the application where kicking members from communities
doesn't work anymore. This was due to UI logic being moved to a different model
without updating the corresponding view action.
Fixes#2274
This adds a `Publish` stage to the combined `Jenkinsfile` which when the
`PUBLISH` parameters is true pushes a __draft__ release to GitHub.
The job remembers the last value of `PUBLISH` parameter selected.
The release uses the contents of the `VERSION` file at the root of the
repo as the name for the release, and leaves the contents to be filled
in by whoever will approve the release.
The automation overwrites - or to be exact, deletes and recreates - the
release, so releated builds for the same release will simply re-create
it. All the built artifacts are included in the release.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Prior to this commit, only admins of a community could open up the community
profile popup from inside the community. However, normal members should be able
to do so too.
Normal members shouldn't be able to create channels, nor should "leave
channel" be an option of the context menu provided inside of a community.
This commit removes these.
As discussed in https://github.com/status-im/status-desktop/issues/2144#issuecomment-817791172 and https://github.com/status-im/status-desktop/discussions/2145, it's no longer desired
to have different appearance settings across multiple accounts.
Instead, the appearance setting should apply globally to all accounts,
essentially bypassing the individual setting stored in status-go.
This commit introduces a new global setting called `theme` which,
at the time of introducing this commit, can be either:
0 => Light
1 => Dark
2 => System
Because those enum values matches the `AppearanceContainer.Theme` enum,
this commit removes it completely and simply relies on QML's built-in
`Universal.[Light|Dark|System] variants respectively.
Closes#2144
This commit introces global settings that apply across accounts used
inside the application. This is useful when settings like the selected
locale should b the same across all accounts.
Closes#2144
Fixes#2050.
This PR contains changes to fix the name validation for new communities and new channels in communities. In the process of updating this, better validation was also added to both popups (create community and create channel), including the prevention of the "Create" button from being enabled until all form fields were valid.
During this process, it was noticed that the community image cropper was not actually cropping the image *in the preview*. Once the community was created, status-go was successfully cropping the image as the user intended. However, the preview thumbnail prior to creation was not accurately showing the cropped image preview and showing the entire image centred instead. *This is still yet to be fixed.* One solution is to upgrade Qt to `5.15` to take advantage of Image QML's `sourceClipRect`.
It's not supported to run `brew update` multiple times simultaenously. A better
fix for this can be implemented, but for now in the Makefile have target
`bottles/pcre` depend on target `bottles/openssl` so that they run serially
when `-jN` is passed to `make`.
I was originally going to change `brew update >/dev/null` to
`brew update >/dev/null || true` but decided the Makefile change provides a
better guarantee that simultaenous `brew` commands won't interfere with each
other. In the process, I revised some of the script's `echo` output just a bit.
Current settings caching logic was inefficient when attempting to retrieve settings that contain the sensitive mnemonic. While those calls were limited to the login logic, each call would need to round trip to status-go to get all settings when they wanted to include sensitive data, as the cache was not being updated for these calls.
This PR updates the cache regardless if sensitive data is requested of not, effectively making the caching mechanism more efficient during login.
Fixes#2131.
After some heavy profiling, it became clear that sending of each message was causing a fetch to get all contacts from status-go. This was incurring a minimum of a 0.03s delay for each fetch, which was causing a bottleneck each time it was called for various operations throughout the codebase.
This code addds a layer of threadsafe caching to the contacts call, such that only the first call to contacts fetching will incur the delay, as well as every fetch after a contacts CUD operation.
There was a bad merge in PR #2225 that caused the QML propery `activeMailserver` in `SyncContainer` to be stripped out. This was causing an error in the console: `qrc:/app/AppLayouts/Profile/Sections/SyncContainer.qml:16: Error: Cannot assign to non-existent property "activeMailserver”`.
This PR adds the property back in and resolves the issue.
Fixes#2143.
Methuselah is the a task manager for long-running tasks. It allows fo registration of workers that will each run in their own thead. Each worker can pass messages to and recieve messages from the main thread.
MailserverWoker was also introduced which moves all mailserver model logic to a MethuselahWorker. All communication to/from the model is done via a MethuselahTask. Results of the task are returned to the main thread by way of `signal_handler`, which calls the QtObject slot specified in the task.
Mailsever also provides a way for the model to emit events inside of the worker. These events are forwarded to the main thread via the `receiveEvent` slot of the `MailserverController`.
Co-authored-by: Michael Bradley, Jr <michaelsbradleyjr@gmail.com>
This is part of a general restructuring in layout of Jenkins job folders
before we can properly introduce Release signing and notarization.
We need this to distinguish between pr/dev builds and release ones to
avoid signing the dev builds with a release certificate.
The meta job managed with `ci/Jenkinsfile.combined` runs a job for all 3
platforms and currently is quite basic, but in the future can be
extended to include - like the mobile one - updating the nightlies page,
or publishing draft GitHub releases.
The addition of `make check-pkg-target-*` steps to other `Jenkinsfile`s
is necessary because the sub-jobs under `platforms` have no option for
checking out Git submodules at the beginning, so I'm making use of how
the `Makefile` works and triggering that with a target that doesn't do much.
Example job:
https://ci.status.im/job/status-desktop/job/release/job/ci-meta-release-job/
Signed-off-by: Jakub Sokołowski <jakub@status.im>
When the profile popup is opened inside the contacts list, it doesn't have
a surrounding window context (`Popup` types should usually be used within `ApplicationWindow`
or `Window` components as per https://doc.qt.io/qt-5/qml-qtquick-controls2-popup.html).
This is problematic when popup are nested, like it's the case with the
nickname popup that will be instantiated by the profile popup.
With no window context, such nested popup can't be opened by the application.
This commit ensures the profile popup is created with a proper context,
fixing the issue that the nickname popup won't open when visting via
contacts list.
Fixes#2216
Pascal Precht
Jonathan Rainville
B.Melnik
Jakub Sokołowski
Eric Mastro
Michael Bradley, Jr
Iuri Matias