https://kotlinlang.org logo
Channels
Powered by
#tornadofx
  • m

    Marcin Wisniowski

    10/30/2017, 7:35 PM
    I also have some code that doesn't work from onDock(), but it does work if I wrap it in 
    runAsync {} ui { //code }
    , it's obviously not the correct way though. It probably needs to wait for something to initialize and the runAsync/ui does that, but what would be the proper way to defer execution to when the View (?) is ready?
  • c

    carlw

    10/30/2017, 7:42 PM
    onDock is tied to the onShowing stage.apply() init. I generally use onShown for my initialization because that's when the Stage is actually on the screen and available to handle a progressbar. So, try moving your code to the onShown() handler primaryStage.setOnShown { evt -> runAsync {} ... }
  • c

    carlw

    10/30/2017, 7:42 PM
    that would go in your View's init() method
  • m

    Marcin Wisniowski

    10/30/2017, 7:44 PM
    What I meant, there is actually no code in 
    runAsync
    , there is no long running operation, but it makes the code in the 
    ui
    block work, because it probably defers it to when the View is ready.
  • c

    carlw

    10/30/2017, 7:45 PM
    ok, then pull out the runAsync / ui and just put your code in the event handler
  • c

    carlw

    10/30/2017, 7:45 PM
    If you have any long-running (file parsing, network contacts, etc) it should go in the onShown handler and not in the start() to provide feedback
  • m

    Marcin Wisniowski

    10/30/2017, 7:46 PM
    Let's say I want to immediately close the window:
    Copy code
    override fun onDock() {
        super.onDock()
        primaryStage.close()
    }
  • m

    Marcin Wisniowski

    10/30/2017, 7:46 PM
    This doesn't work though
  • m

    Marcin Wisniowski

    10/30/2017, 7:46 PM
    But this does:
    Copy code
    override fun onDock() {
        super.onDock()
        runAsync {} ui {
            primaryStage.close()
        }
    }
  • c

    carlw

    10/30/2017, 7:47 PM
    Have you considered transitioning from one View to another rather than closing the primary stage?
  • m

    Marcin Wisniowski

    10/30/2017, 7:49 PM
    I would like to understand how to do that even if it wasn't closing, but in the case of closing, I want to replace the View with a Fragment, I think 
    replaceWith()
    can only replace a View with a View.
  • m

    Marcin Wisniowski

    10/30/2017, 7:52 PM
    I went with this as my main App view: https://ss.nohus.eu/11072/22d492f6
  • m

    Marcin Wisniowski

    10/30/2017, 7:53 PM
    It just opens the actual window I want, which is a Fragment that needs to be StageStyle.TRANSPARENT
  • m

    Marcin Wisniowski

    10/30/2017, 7:54 PM
    It works great, but feels like a hack.
  • c

    carlw

    10/30/2017, 7:56 PM
    you should also test that across all the platforms (win, mac, linux). i have a client who got an AppKit thread on only the mac because of a timing issue shuffling windows around. (It doesn't show up in Windows or Linux; same JVM versions)
  • m

    Marcin Wisniowski

    10/30/2017, 7:58 PM
    Interesting, will do!
  • c

    carlw

    10/30/2017, 7:58 PM
    LauncherView is the main view referenced in the app?
  • m

    Marcin Wisniowski

    10/30/2017, 7:58 PM
    Yes
  • m

    Marcin Wisniowski

    10/30/2017, 7:59 PM
    Since my main window is a Fragment, I couldn't use it even with the StageStyle setting working, because I cannot set it as the main View anyway (since it's not a View)
  • m

    Marcin Wisniowski

    10/30/2017, 8:01 PM
    There is only one main window so it could be a View, but I want all my windows to be subclasses of the same base Fragment which has a lot additional functionality. I would need the main window to be a special case doesn't subclass my base window.
  • m

    Marcin Wisniowski

    10/30/2017, 8:02 PM
    So while this LauncherView solution is a little questionable, it makes the rest of the actual code cleaner.
  • m

    Marcin Wisniowski

    10/30/2017, 8:03 PM
    And my base window class is a Fragment because some of my windows can be opened more than once.
  • c

    carlw

    10/30/2017, 8:12 PM
    Do you think scopes would help you? are you building an MDI (multiple document interface). This is like opening 3 independent IntelliJ projects up
  • m

    Marcin Wisniowski

    10/30/2017, 8:24 PM
    Hmm, I am building a set of related tools, each in it's own window. So there is the main control window, and then you can open a window for each tool, some multiple times. I'm not sure I need the complexity of scopes, all of the tools are quite simple (think opening 3 calculators and 2 notepads).
  • c

    carlw

    10/30/2017, 8:27 PM
    ok...was wondering if there was a single cross-cutting thread that could be managed with a scope like "project scope"
  • m

    Marcin Wisniowski

    10/30/2017, 8:28 PM
    Well, the main window should be alive for the entire lifetime of the app.
  • m

    Marcin Wisniowski

    10/30/2017, 8:28 PM
    Although I plan on making it possible to "minimize it into the system tray" later on, not sure how that works yet, if it needs to close the window then it won't be always alive.
  • c

    carlw

    10/30/2017, 8:29 PM
    system tray is a little awkward because you'll have to work with AWT + Swing
  • m

    Marcin Wisniowski

    10/30/2017, 8:29 PM
    Oh dear.
  • c

    carlw

    10/30/2017, 8:31 PM
    basic min/max stuff should be ok with just FX...i've done a popupmenu and a status icon, but had to bring in the older technologies even when running FX
1...147914801481...2007Latest