A modern programming language that makes developers happier.

kotlinlang

Hello!
<@U3ZLHBTLG>, do you think that migrating from anko to splitties is possible without a complete rewrite?
I mainly use the layout DSL: `verticalLayout, scrollView, textView, button`  etc

Hello <@U66SV6HSQ>!
Yes, it is. In Splitties, everything is as explicit as possible. I advise you to read (on GitHub) the Views DSL doc, and the docs of additional Views DSL modules (ConstraintLayout, Material Components…). Having read this, you should know exactly what to expect, how layout parameters are explicitly defined, and that'll prove handy when moving from Anko which defines layout params differently, and adds views implicitly. For `ScrollView`, you'll want to use the `.wrapInScrollView()` extension.

If you don't change your mind after reading Splitties doc, maybe you could start a draft PR adding a migrating from Anko markdown document for others, and possibly your future self?

Was just reading the docs and came across to this:
“To use a View in an Anko layout, in addition to a function for DSL usage, a subclass of it, specially tailored to work with Anko layouts is needed.”

I have added extensions to anko without subclassing.  Just using 2 lines of code. What am I missing?

Example:
```
inline fun ViewManager.flexboxLayout(init: FlexboxLayout.() -&gt; Unit = {}): FlexboxLayout {
    return ankoView({ FlexboxLayout(it) }, theme = 0, init = init)
}
```

Oh, 4 things that might be helpful too:
1. git, starting clean, obviously
2. "Replace in Path" IDE action after you select code to replace
3. "Find in Path" IDE action, works with selected code too
4. Disabling java/kotlin auto-import, then removing the anko imports file per file, try to use Splitties imports instead, changing what needs to be changed. You can also disable suggestion of anko imports to get rid of ambiguities. Then, after you change a layout, make sure it looks AND works as before.

You don't support `FlexboxLayout.LayoutParams`. That's what you're missing.

Yes, but I have a comment :rolling_on_the_floor_laughing::
//  Do not call anko’s `lparams()` on the nested elements,
//  it will cause a **crash**.

In Splitties, `lParams` for `FlexboxLayout` doesn't exist, but you'll be able to write it easily once as an extension, just like I did for `ConstraintLayout`, `LinearLayout` and `FrameLayout`.

Is AS 3.5 required to open Splitties?
I am getting such a message.

Is 3.5 usable? Haven’t tried it. Earlier beta versions have proved really PAINFUL.

3.5 is the best Android Studio version yet, it finally dropped Instant Run for Apply Changes, which is very reliable.
I submitted bugs and starred others. A fair share of them have been fixed.

rc01 is usable to me, and it's also about the last minute to report important bugs or issues you might encounter.

Early versions had loads of memory leaks, but also a detection for them and a reporting system, and I started a habit of restarting the IDE everyday after reporting the remaining leaks after each new alpha/beat, but this has now been fixed, and I now close it every other day.

:slightly_smiling_face: memory management and android-whatever will never be friends

Wow!! The AS size decreased in v 3.5!!
Unbelievable!

They ditched Instant Run and other old "crap" probably