v13 Readiness

[borgmanJeremy]

@mmahmoudian and @ElTh0r0 I figured we could start an open dialog about what we think must be done before a v13 beta release.

Some of the items currently listed on the milestone page are going to be quite a bit of work after digging into them. Here is my list of things that must be done (that doesn't mean these are top priority, just once these are completed we can do a beta release).

• Fix MacOS code signing. The script that does MacOS code singing is not working so the .dmg will not run on apple silicon. I've really spun my wheels on this one, but I feel its critical to get done. Note this is different than notarization which will cost $100 and we do not do.

• Fix the snap package permissions. The snap now builds, but for some reason flameshot is not reported as "having focus" when started so it cannot engage the gnome permission system. If we don't fix this I'm open to the idea of fully purging the snap from the snap store and directing people to the flatpak.

• I recently fixed our SignPath build so we will have signed windows packages, but I need to test it.

• Flathub Verification #3555

• I'd like to add a compile time flag to remove networking.

Are there any must have items you can think of before we release a beta?

[ElTh0r0]

I am happy to support preparing the v13 release - with the knowledge I have (I'm not sure yet with which tasks I'll be able to support, but I am sure we'll find something for me 😉).

Regarding the networking: Currently it is used for searching for updates and Imgur upload, isn't it? As the imgur upload shall be segregated into a plugin at a certain time and update check won't be needed for Linux packages provided by distributions or AUR (or similar), this sounds like a good idea to make the network dependency optional.
But: It seems the "SingleApplication" module has network dependency as well. You already discussed this module shortly in #3962, but I assume a final decision is needed, if it can be fully removed / can be fixed upstream or the community / looking for an alternative.

It may be obvious, but I want to mention it anyway: The Linux Packing workflow should be fully operational again in order to resume nightly builds and hopefully attract more volunteers to support testing on different systems.

[borgmanJeremy]

I should have been more clear on the networking. I mean add a compile time flag for the imgur uploader until it moves to a plugin. The update checker already has a compile time flag.

You bring up a good point on SingleApplication though. Maybe for the beta we add Singleapplication back in, and if it causes issues during the beta test we remove it for the release? I can add something to the beta release notes to that effect.

And yes the linux packaging workflow is all working, but the rpm and deb definitions all need updated.

[ElTh0r0]

I should have been more clear on the networking. I mean add a compile time flag for the imgur uploader until it moves to a plugin. The update checker already has a compile time flag.

👍 This would be a good code preparation for the plugin segregation

You bring up a good point on SingleApplication though. Maybe for the beta we add Singleapplication back in, and if it causes issues during the beta test we remove it for the release? I can add something to the beta release notes to that effect.

I think the main issue was/is if flameshot crashes. Then a bug in SingleApplication prevents launching flameshot again (until reboot). As flameshot should not crash anymore now 😉 , I assume SingleApplication can be enabled again.
Additionally I would remove the support/flag for the 'external SingleApplication', as for my understanding this is for an old Qt solution, which is deprecated (not available for Qt 6 ?). Instead better adding a flag to easily dis-/enable SingleApplication.
I try to play with KDSingleApplication during the next days; maybe this is a better (and active maintained) alternative.
EDIT: PR for review/testing available: #4032

And yes the linux packaging workflow is all working, but the rpm and deb definitions all need updated.

I am working on DEB/RPM and preparing a PR draft. Support is welcome: #4029

[mmahmoudian]

Just to update, the Flatpak is finally verified and now there are 4 Flathub compliancy issues that I'm trying to solve. They are listed in #4013 and soon there will be a PR for it.

[borgmanJeremy]

Awesome, Thanks for the work on this!

[oms9]

#3392 I believe is important (or even a must?) as it is an outright crash and harms the reliability of Flameshot (and even usability to be honest)

There was another issue I am unable to find about the Space bar menu being cut off (left monitor is "below" middle monitor and therefore the menu spawns at the appropriate height of the middle monitor which is too high for the left one)

[borgmanJeremy]

Are you able to see if you can replicate it by building from source on our master branch? I have no way to test dual screen windows.

[oms9]

I tried using the Nightlies from github Actions and I couldn't get the app to launch citing missing QT6 dlls.

Is there a write up to build from source for Windows? if so I can get on that and report back.

[borgmanJeremy]

I think the appveyor build contains the .dlls: https://ci.appveyor.com/api/buildjobs/ck4ktbtwpr1eoh7e/artifacts/build%2Fartifact.zip Not sure why the github build is missing them.

I didn't document the windows setup when I recently completed it, but here are the broad strokes I remember. If you try it and it works it would be a great addition to the README

1.) Download the open source Qt community edition
2.) Use this to install QtCreator and Qt6 for MSVC.
3.) Install Visual Studio C++ to get the MSVC compiler
4.) Open the main CMakeLists.txt file in QtCreator to "import" the project (im most fuzzy on this step)
5.) Now you should be able to compile the project in QtCreator.

It's very possible there is a simpler way, but I literally only use windows to test the flameshot CI builds so I'm not sure.

[oms9]

The instructions are close enough, the only missing step is to navigate to the windeployqt_stuff directory and copying over the contents of the folder to where the .exe is compiled to be able to run Flameshot.

I am unable to reproduce the crashing!

But the other issue concerning the "Tool Settings" menu I brought up is still present though, I'll attach an image for reference:

[ElTh0r0]

I am unable to reproduce the crashing!

because you have now all Qt DLLs installed (they are shipped with the Qt package, which you installed for compiling everyhting) 😉

I tried using the Nightlies from github Actions and I couldn't get the app to launch citing missing QT6 dlls.

Is there a write up to build from source for Windows? if so I can get on that and report back.

My fault 😖 the issue began with my Qt caching change #4008. I removed 'QTDIR' from the action as it wasn't directly needed there, but it is used in src/CMakeLists.txt

flameshot/src/CMakeLists.txt

Line 394 in d420a53

if (EXISTS $ENV{QTDIR}/bin/windeployqt.exe)

Following the install-qt action upgrade guide, we should use 'QT_ROOT_DIR' instead everywhere.

I'll follow up on this after work (and will check if I break anything else when using QT_ROOT_DIR) and fix it.

EDIT: Should be fixed with #4022

[borgmanJeremy]

@mmahmoudian I'm thinking the current master branch is in okay shape for the v13 beta. It's not perfect but probably good enough to ask for wider testing. If that's good with you ill tag it tomorrow. I have some release notes drafted but want to compare it with the release notes github drafts (but i cant generate those until I drop a tag).

[borgmanJeremy]

@mmahmoudian I think we are good to release v13 unless you can think of something that needs to be completed first.

[mmahmoudian]

@borgmanJeremy I have no objections, but I have three questions 🤓:

1. Did you manage to solve the Windows signing? As far as I remember, we released the v13_rc without signed binaries for Windows.
2. Are we going to include the merged PRs that were merged after release of v13_rc?
3. Are you planning on releasing the Flatpak, Snap, and AppImage without imgur upload?

[borgmanJeremy]

1.) Yup, I actually uploaded the windows signed binaries to the beta
2.) Yes that was my plan
3.) Yes that was my plan but see below about snap and appimage.

Snap: Snaps have become increasingly hard to troubleshoot for me, and they are starting to have unique issues. I want to drop snaps unless a community memory helps maintain them.

appimage: We do not have an appimage building in our CI. I think we should point people to flatpak. It's won the "universal packaing" war, and it adds maintenance burden to support so many formats. But if someone wants to add appimage and test it before v13 I am okay with that.

[mmahmoudian]

@borgmanJeremy
Great. Thanks. Let's roll with that then.

About AppImage, I personally like it as it makes it easy to test multiple versions side-by-side with minimal effort. But I agree that Flatpak has practically won the race, especially in desktop software.

Regarding snap, I'll ask again on Fediverse in case someone wants to adopt the maintenance of it. 🤷

[borgmanJeremy]

Someone IRL reported #4090 to me and I replicated. I think that should be a blocking issue since we are recommending flatpak.

[electriquo]

following #3824 (comment).
macos arm64 package is not included in v13 release.

following #4012 (reply in thread), maybe i am missing something, but flatpak is for linux, not macos.

any intention to include macos arm64 package in current\future release?

[electriquo]

I think that's something that is better to come from the user rather than the maintainer.

I wish. Unfortunately, past experiences proves the opposite to be true.

[mmahmoudian]

@electriquo I created the following issue:

Homebrew/homebrew-cask#222922

[mmahmoudian]

Ok, we have the answer. They are removing any software that is not notarized by Apple. I quickly checked the documentation and it seems like a quick process:

https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution

Also it seems that there are Github Actions to do this automatically:

https://github.com/lando/notarize-action

I'm just not yet clear if this is going to cost us money or not.

[borgmanJeremy]

This is already fixed

[electriquo]

What do you mean by

This is already fixed

What was fixed? (Homebrew still shows deprecation)