After reviewing: ```val styledLabel = Label( b...

# doodle

[Norris]

After reviewing:

val styledLabel = Label(
    bold("Lorem Ipsum").." is simply "..Yellow("dummy text", Background)..
    " of the printing and typesetting industry. It has been the industry's standard dummy text "..
    TextDecoration(setOf(Under), Red, Wavy) ("ever since the 1500s")..
    ", when an unknown printer took a galley of type and scrambled it to make a type specimen book."
).apply {
    width         = 250.0
    fitText       = setOf(Height)
    wrapsWords    = true
    lineSpacing   = 1f
    textAlignment = Start
    letterSpacing = 0.0
}

I think I am running into this issue because I am trying to build objects imperatively not declaratively. Is it possible to do this?

[Nick]

yes, both will work. the apply block above is a Kotlinism that gives you a scope where the this reference is implied; sort of like your code is within the class of the object it is attached to. so anything you see in apply can be done explicitly like you mentioned.

[Norris]

Ok, when constructing CommonLabelBehavior(…) how would you pass TextMetrics?

[Nick]

you’d have it injected into you app first. then pass it on to the behavior.

class MyApp(display: Display, tm: TextMetrics): Application {
    CommonLabelBehavior(tm, …)

    // …
}

this will work as long as you inject it like you do for the Display. you don’t need additional modules since it is bounded by default.

application {
    MyApp(display = instance(), tm = instance())
}

[Norris]

Ok, on that note: is there any way to construct an application at the platform level without using the application DSL closure/lambda?

[Nick]

you can create your Application class anywhere (i.e. MyApp above), since it’s just a regular class. this makes testing possible. but a runnable app has to be inside the application closure for the platform. that closure creates all the platform instances you need to execute an app, like the Display, etc. for web vs desktop, and other platforms.

is there a use case you have that needs to avoid the closure?

[Norris]

I am usually developing complex mobile applications (mainly iOS; traditional; not SwiftUI, secondarily android).

Im not really a fan of using 3rd party frameworks. I wanted to manage the dependencies myself. Constructing the application from scratch and managing whatever is going into it is what Im used to, but it also helps to understand what you are building; being able to fine-tune / adapt the architecture as you see fit - as opposed to just using frameworks. My main concern is architecture/design , secondary concern is performance/optimizations tuning. I understand there are “ways” to do things using the frameworks, but I would much rather make the design decisions about the architecture. I picked up Doodle because I figured it was more of a library than a highly opinionated framework (maybe its both), and the amazing lib of-course.

[Norris]

I’ve built web apps as well, but that of-course requires a different way of thinking when building with traditional web technologies. Given that this is kotlin, I figured I could build in doodle with it architecturally like I would any other compiled typed native language + lib.

[Nick]

nice to hear your background. makes sense that you'd want to minimize frameworks and opinionated architectures. i feel the same by the way. in fact, Doodle is fairly unopinionated. this is why it has so few external dependencies itself. essentially, it only requires the use of Kodein for the application block, Measured (also written by me) for things like time, and Kotlin Date Time when using a some optional controls. otherwise, it tries to get out of your way. a good example of this is you don't actually have to worry about the existence of a injection framework in your actual app. the DI happens in the application block, and you are free to extend knowledge of that to your app, or just pass dependencies into it manually. i prefer the latter b/c it makes apps more testable and isolates them from Kodein.

beyond that, you can use layouts to manage how stuff is presented on the screen, or you can manually position things. you can use Themes, provide explicit Behaviors to the existing controls, or just roll your own Views that don't even care about themes or behaviors.

a big part of Doodle's philosophy is that it shouldn't feel like a web framework. your app won't actually care about browser concepts and it can all be written in commonMain and then run on the JVM etc. w/o any modifications.

feedback is one of the most useful ways to make something like this better by the way. so please feel free to share you experience as you consider Doodle.