I hope I figure this out... gotta d

demo tomorrow

I just found a bug in TabPane.tab<UIComponentType>() if it's used inside of a UIComponent. It didn't take the current scope into account when it was looking up the UIComponent. I committed a fix just now.

I never did anything with scopes

Coming home, opening slack and seeing woodworking talk. I had to take a second (and third) look to make sure I am in the right channel 😉

Why? Are you missing the keyboard talk?

@jschneider Haha! I was thinking that we got a little off topic there for a second, but everybody needs some basic wood working info anyways, so it's a win win 😎

Granted, I do mostly aluminium 🙂

I'm thinking about that login/preloader thing. I could actually change the GitHub demo into supporting this, at least if I can find a way to verify a session. I don't want to create a demo that saves unencrypted credentials.

Actually, I can generate a demo token. GitHub supports logging in with username:token using Basic Auth. I think I'll go this route.

To sexy up the demo a little I just committed: "ConfigProperties (

config

) is now

Closable

so it can be used with `use`"

How does using a demo token change the picture?

@edvin are you suggesting handing off a token from the preloader to the app via the filesystem?

@Carlton Whitehead Not much, admittedly. It is temporary, I can show it in the demo and how it's stored in the file system, and also warn about "don't do this at home". When I think about it - maybe it would be better to showcase good security practices instead 🙂

the minute you put it in a demo, people will blindly copy it, with full disregard of the "do not try this at home" warning

@carlw I don't think the preloader needs to know about anything, it's just a dumb screen that will be removed by the LoginController when it determines if it should show the app or the login screen, based on what it has.

@ron Good point.

@edvin ok. there's an old javafx sample on the oracle site that does the auth step in the preloader and uses callbacks to communicate with the app

@carlw Since the preloader is a view, I don't think it should contain the business logic, and since it's trivial to keep it completely dumb, I'd probably prefer that. Looking at the sample..

also the session info could be in the controller and would be available to the mainscreen. I once stored info like that encrypted in an app, so it was not available in a memory dump

@edvin i think the use case for merging the preloader and the app is a one-time app init versus two progress bars: the preloader progress + the app init progress. so, you can load the data post-login under 1 progress bar

i work with the preloader to provide a customized startup screen

@carlw Good point. It would be easy to re-show the preloader if you need to do more work after login though. By the way, I'm not actually talking about using the JavaFX preloader, I see no value in that, it just complicates things with very little gain, if any.

@edvin added TILES DataFormat as a companion object, and something is happening

@amanda.hinchman-dominguez You're not getting the dup message anymore, right?

One of the things I want to avoid with my app is forcing the user to authenticate every time they re-open the app. Many apps accomplish this by using credential stores provided by OS (Account services on Android, Keychain on Mac, Keyring on GNOME, etc). I found a library that abstracts access to those services on Mac and Windows, but the PR open adding Linux support makes it seem abandoned. https://bitbucket.org/east301/java-keyring

well last update is in 2015

@ron can keepass work in that capacity or is that overkill?

you mean keepassFX (which I should finish one of these days) or keepass in general?