if you get two VGA controllers then you have an optimus setup

I'll check, ETA 10

Just one I'm afraid

Actually, there is two, but

grep VGA

hid it:

I can right click any app and choose

run using dedicated graphics

IDEA seems to run beautifully. Fonts look good as well.

so if you run factorio with optirun I wonder if the fps will be faster as that nvidia card is quite good

I tried to run with dedicated graphics, then it dropped to 20/60, so I guess that means the intel card. Maybe it was running with the NVIDIA card earlier? Now everything seems a bit more sluggish though.

Trying TornadoFX in IDEA now 🙂

this is what I expected to be honest

wayland is not ready enough for opengl stuff

Some serious HiDPI issues with JavaFX though. Everything renderes ultra small. It doesn't seem to care about the "zoom setting" the rest of the software respects.

I guess not 🙂

tbh my favourite linux setup at the moment is ubuntu with cinnamon desktop

The rest is pretty spectacular here, really. Going to try with xwindows before I give up.

RPM is really up to speed compared to APT as well.

the macbook has a intel card and it runs at 60/60 too

Linux always mess up driver support 😞

Luckily I don't care about games. I just need 60fps for screencasts.

But this HiDPI stuff is killing me. Everything renders really tiny in JavaFX.

after one of you guys pointed out using kotlin as a kind've code-behind strategy I've been thinking about the differences between XAML and FXML. The biggest one for me has always been the partial-class scheme that WPF uses. Its a really odd language feature that i never understood how to use properly.

Having also spent a fair bit of time with dagger2 and antlr lately im warming up to the idea of code generation (probably a bad sign)

anybody think maybe we simplify view-binding logic with generated interfaces? Since kotlin gives us interfaced properties, you could potentially ask KAPT to generate an interface with getters for each FXID encountered on a document:

<!-- whateverView.fxml -->
<GridPane fx:id="mainView" fx:controller="com.whatever.WhateverController">
  <Button fx:id="helloButton" onAction="#onHelloClicked" text="${controller.helloButtonText}/>
</GridPane>

would generate the code:

interface WhateverView {
  val mainView: GridPane
  val helloButton: Button
}

which you could then implement to "use"

class WhateverController(viewImpl: WhateverView): WhateverView by viewImpl {
  
  val helloButtonText = "hello bindings!"

  fun doDomainThing(domainObject: DomainModel){
    helloButton.state = compute(domainObject);
  }

  fun onHelloClicked(event: ActionEvent){
    //regular FXML handler handling
  }
}

and which would require some kind of factory likely involving dynamic proxies to leverage:

val controller = uiFrameworkFacotry.create<WhateverController>()

this has the design wins that: - you dont need to use the field name matches FXID scheme, which, of course, are bound and runtime meaning that spelling mistakes can only be found relatively late - you dont need to mention the type yourself, which probably makes your code a little more refactor safe. Consider

mainView

is changed to a

VBox

instead of

GridPane

, theres a good chance that if you made that change in the view code, you wouldnt need any changes in the kotlin controller class. - This also makes explicit the fxml resolution strategy. I don't know how other FXML users do it but I almost immediately implemented some reflection to find the view by a naming convention. Here that problem is taken away from us.

@edvin good to know, I may try it later. I am using SimpleScreenRecorder, I think it's called that. It's nowhere near as good as Bandicam, and my research couldn't find an effective Linux substitute for it. You'll have to let me know if you find one, even if it's commercial.

@groostav That's an interesting idea. I actually looked into this a while back, but stopped because annotation processing was flaky with Kotlin if I remember correctly. If it is complete and fully working now, this is absolutely doable. It probably involves writing the annotation processor as well as a custom xml parser that understands fxml style imports to resolve the classes etc, unless we can just piggyback onto the default FXMLLoader and check it's map of discovered fx:id's when it's done.

I have some alternative ideas about how to access the genrated properties however. If we can make the annotation processing work I'd be able to do a POC pretty quickly.

I seems like kapt is not supported in Maven either 😞

yeah @edvin I really wanted to stay away from a custom FXML parser, but for the kinds of things I was thinking it is almost unavoidable. I could hack apart some of its components through reflection but thats not nice. And Im suprised that it isnt supported with maven, I got it working with gradle and dagger2 with very little effort