this also shows how 2 threads communicate

which gives me a strange maven error

but that is not important

@edvin concerning the opening view after something like a login screen:

I made this quite some time ago and used

primaryStage.hide()

and

primaryStage.show()

but that code still used tornadofx 1.4.6-SNAPHOT 🙂

@ron: I'll create an updated sample, have some new ideas to make it better.

nice as in this code when switching to the “mainview” you have to initialize it still

I have completely scrapped the UI of the keepass and I want to rewrite it better

expect loads of questions 🙂

Perfect :)

Let me check how I did login in the github browser sample.. Maybe I can evolve that to something nicer as well.

That just uses

replaceWith(OtherView::class)

. Wonder if we could adapt the stage size at the same time...

That works if you don't do any transitions between the LoginScreen and the MainScreen.

In my apps I often use a Preloader View which displays startup progress. If the user has saved credentials, this screen will show while I do a login attempt with the current credentials. After the call is done I close the Preloader. If login was a success I show the MainScreen, if not I show the LoginScreen. If no credentials were stored, I of course show the LoginScreen as well.

@edvin For the task team key-sharing...maybe a user owns (and encrypts) the team private key and transmits it to another user by encrypting the team private key with the target user public key? So, the cloud authentication gives other users access to the encrypted bits and a cloud service transfers the team private key from one account to another?

So we would require a keypair for each user? That might make it a bit harder to get started but might be the best bet from a security standpoint.

@edvin just brainstorming...it might make an app or service that people would actually use versus a demo

@edvin maybe start with an offline mode then move to single and shared modes?

Why does the team key need to be paired? It's not like they need a public key for it. A symmetric key should be fine. How they choose to distribute their key isn't really a concern of the system.

They can use PGP to send it to their team or they can just email it. There's no reason for you to deal with it at all.

@Ruckus I was thinking of making the key distribution easy for them. Today you'd probably just unlock an authentication flag when adding a user to a cloud team. This would also transmit an encrypted key over to another person's account. Not trying to slow things down...just think that working with local storage is a selling point for desktop apps (TornadoFX)

@Ruckus there are a lot of emerging cloud data providers like Realm that would spin up an app like this quickly. However, I think they still have access to your data since they provide some basic crud functionality for you to manage your stuff

Fair

Why not use Google authentication?

@ron you'd need authentication to get the encrypted bits (everyone's encrypted data wouldn't be public) but then a key would be needed to decrypt

are we storing the key or is that the responsibility of the team?

team owner keeps the team key, stored as one more block of encrypted bits in the cloud, the key gets sent over to participants who maintain a copy under their private key (with others)

i'm suggesting this as a tornadofx app because the desktop app works with a local store (view model, etc) with commits -- in the tornado sense -- occurring locally. Then a sync mechanism is added to share the contents

deconflict things at the local level (task diffs should be pretty simple) and push up