Patrice Ferlet aka MΣƬΛᄂ3D @metal3d@techlover.eu

@ebassi I feel it abnormal to not help any other library to integrate on the desktop by sharing at least some color informations.

@ebassi sorry for my English and sorry if I'm a bit annoyed but I spent hours to read documentation about GTK 4 to finally realize that I will not be able to continue my idea...

@ebassi that's something that I don't understand... OK, css is cool to make whatever we want for themes. But there are at least 2 needed information, the "dakmrk/light" switch and "foreground/background" colors. That's anormal to have to call GJS (or python) from another language/lib to find this. And anormal that now it's impossible to get these information.

@ebassi that's not to draw on GTK. That's to get the theme generic colors (background and foreground) to color an app using another library (fyne.io).
There is no dark/light information on gnome and nothing to get the theme base colors.
Actually I call some gjs command to get a invisible one shot window color from get_context() method. Grk4 abandoned this.

And if you're not aware about the problem, there are plenty of developers who ask this on StackOverflow, reddit... The general answer is "we changed this because we do better things now". Better ? That was a pain to find colors, now it's impossible!

And yes. #Gnome can use others colors than GTK theme. But in facts, themes provides the adapted colors for GTK. So, I will use gtk3 context for a while, then my code will be broken...

So if you want to make a background and text color retrieval routine to help a graphic library adapt to the user's theme: you're screwed.

Because yes, I use GTK V3 in #gjs to output this information. It's the only viable way. But Gtk V4 has removed the access to the context. That's crazy.

I am extremely annoyed to realize that it is IMPOSSIBLE to find the basic colors of the #Gnome interface in #GTK v4.

Sur #Quotidien je vois deux gars (un philosophe et un scientifique) qui répètent que l'humain est le seul à marcher debout sur deux pattes. Et là je tourne la tête et je regarde mes poules... Qui marchent... Sur deux pattes...

I will not share the link... That's a complete absurdity to believe that you can be a "correct" full stack developer in one month (unless you are a very very very good developer on several others languages)

@mallabori je te réponds dans la journée. Mais je précise que je ne te dis pas que l'étude est parfaite mais leurs chiffres ne sont pas insensés.

@Edent and a good otp app should not ask something which is not in spec. I personally use Bitwarden without any problem. And afaik they don't support anything else than the basic parameters.

@Edent but yes, that's right, a global and official specification should be written for totp URLs

@Edent I will give you my opinion (I can be wrong). RFC gives recommandations about time step and replay (allow user to be in late). So I would say: never use something in the URL which is not describes in RFC. For example, icons is not described (it's not related to authentication). It's a bit like css which has got vendor prefix, I never use them.

@Edent lol I love the apple specification you linked which is exactly the same than Google one but prefixed by "apple-".
https://developer.apple.com/documentation/authenticationservices/securing_logins_with_icloud_keychain_verification_codes

@Edent ho sorry I didn't take the time to read and I answered too fast.

@Edent in case of, the RFC is also described by Google here: https://github.com/google/google-authenticator/wiki/Key-Uri-Format

@Edent but there is an RFC for 2FA and the algorithm is explained. I was writing a tutorial (#Python and #Go). Didn't finished yet.

@Edent in theory, you should see the qrcode or base32 password once and only if you're authenticated. Then the website will never show you the same qrcode again. If you lose the key, that should completely block you. I probably didn't understand well your question (I'm French)