There is lot of separate things in here. I'll do a couple of different comments per thing

Password store
It should default to $home/.password-store/ on linux and no dot on linux
https://dev.gnupg.org/source/gpgpass/browse/master/src/util.cpp$23

This code is inherited from QtPass and is also chosen by both me and QtPass to be compatible with pass(1) (https://www.passwordstore.org/)

I do also think it makes likely sense to have ~/.password-store/ only encrypted to your private key(s) and shared stores elsewhere (profiles)

First start wizard

QtPass had a first start wizard, just made of random QMessageBox'es, and the code was kind of geared to wanting to be setup.

It also looks like you haven't noticed the first data input page; that's only shown if number of secret keys is 0 and offers you to create a key.

Some of my later restructuring does work with a uninitialized password store and offers to initialize with specific keys, so the "select keys" part of the wizard could at least be dropped.

If we hardcode the initial password store to the "suggested one", I guess that one could also be dropped and people could go to profiles to modify it and add shared bits.

I do think we do need some kind of annoyance popup if number of secret keys is zero during first start, and somehow guide the user to key creation.

File dialogs
Code does use the standard Qt File dialog, but I_think I should redo it to use the static methods instead because that let the backend take over.

Yeah this task is a bit bad as it does not really split this up into actionable tasks. But I found it obviously "ugly" (Since QWizards are ugly) and from a user experience standpoint outdated that I thought a general task would be enough to say that this must be changed and improved. The first start is the most important one and to be greeted by a wizard which I still am apparently where I don't really understand what the software wants from me is strange.

"Don't make me think." Imagine a very non technical person opening this for the first time. Does not know what a certificate is, does not know what a key is, does not have a private key pair themselfs.

They are used to double clicking a file and entering the password for the file. Or to Right click a file and enter the passphrase to encrypt it again. That is the persona we want this software to help in the first place. So we cannot use any expert terminology and have to do as much automatically as possible.
And at least in my opinion all wizards should die! Forward and back and then partially with only a single line input on on one page (this is just meant in general). Qt also managed to style them very uglyly on Windows and afaik according to Ingo they do not work well for accessibility.

@Carl Since you are at it and also have a Windows build available could you take a look at it not only on the technical level but also from a user experience standpoint. I mean of course in the end I would rather just have a "Store in gpgpass" option in pinentry to save a password but for now we can probably check fast and easy it is to solve a common usecase.

Like you get a file encrypted by mail.
And a password printed on a sheet of paper.
And your collegue says to you that you are allowed to use gpgpass to store that password.

And of course you don't have an asymmetric key yet. I am mostly commenting here since that was the ticket I had created regarding gpgpass and since carl currently is tasked to go over it some more, which is a bit unlucky regarding the timing since you are on leave right now. I wanted to update and clarify my comments.

If you want to use gpgpass without a secret key, the most I would offer, if at all, is the option to use a symmetric key instead.
Maybe like this:

GPGPass is designed to be used with a secret GPG key. 
You can generate one using Kleopatra and come back when you generated one.

Alternatively you can use a password (symmetric encryption).

Enter password: _________________________

Keep this password save!

IMHO, everything else will become to complicated.
When using a public key based password manager, you should have a basic idea of what you are doing.

No I don't think we should support that. I just meant that at first start we have to expect that the user does not have a secret key yet. And offer an easy way out of this by generating one.

Currently the software basically says: "Now go and generate a key with kleopatra and come back when you have done this"

IMO Gpgpass should link to libkleo for this, since that way we avoid most dialog / translation / code duplication.

I and most users don't read what software says and just click where I think I reach my goal fastest. If there are only instructions to do something I am unable to continue.

I created a merge request here https://invent.kde.org/carlschwan/gpgpass/-/merge_requests/3

The first start widget only displays two fields now: the storage location (pre-filled with ~/.password-store on linux and ~/password-store on Windows) and a "User Certificate:" field (prefilled with the "default-key" from gpg.conf) and allow to create a new key directly from gpgpass using the same certificate creation dialog as Kleopatra. In the usual case, the user should just have to click on save to get started.