There are a lot of interesting concepts in this project. I have a question regarding View technology. In the current code, as I understand it, the view part is an entirely new one, using only canvas to draw elements on it. However, the building of UI through this kind of code could be attractive in existing contexts. Do you think it would be possible to have something similar with a binding mechanism on an existing technology like, let’s say, HTML?

Some questions about syntax: If all dimensions are in

dp

, why can't I just put a number, instead of doing

<number>.dp

? What is the deal with the

+

operator (in

style = +themeTextStyle { subtitle1 }

for example) ? I've read the documentation about it, but I still don't understand the need for it.

Right now when you press

ctrl+space

in a composable constructor it shows you the suggestions for the current positional parameter (in this case

TextAlign

), and then all of the available optional parameters. Is there plans to bump up the positional parameters in autocompletions of composable constructors? I think It would be a good idea.

Hi guys, the Jetpack Compose write their components pixel by pixel using Canvas (if i'm correctly), I was wondering if is possible to write the Canvas in other platform, like Kotlin Native targeting iOS, and use the already created components of Jetpack Compose. I know that this is not the goal of the project, but, it's possible?

Will Compose be as fast in rendering as Flutter? I’d like to be able counter-argument colleagues who are trying to push Flutter just because of the 60fps advantage

OK. Put this list of talks / blogs together real quick that might be interesting to anyone wanting to understand more about declarative patterns that Compose appeals to: http://intelligiblebabble.com/content-on-declarative-ui/

this reminds be with a kotlin library called anko i used long time to write dynamic UI through code. https://github.com/Kotlin/anko/wiki/Anko-Layouts

Is the source code for

ScrollingList

available somewhere ? I can't find it. It's the

RecyclerView

equivalent mentionned there:

Is there a way to try compose on a windows pc?

It appears that having multiple children under

Surface

crashes the app

Hi all, I'm not sure if I understood the

SlotTable

responsibility in compose algorithm, it keeps slots and other concepts that are made do manage slots, but what exactly is stored on those slots values, and what its relationship with a compose tree? Is it the core of a compose tree management or something like that? Could anyone explain it, please?

It doesn't give you a stack Trace or anything?

@Gil Goldzweig I had something similar, I had to import compose (or composer, can't remember) even though intellij marks it as unused. This might or might not be the same issue

I am getting this error while building the project. Anyone have an idea how can I fix it?

It appears to have been fixed in a recent change.

What is the "recommended" way to position an element? For example: Bottom | Start And is there a plan to make a compose version of constraint layout or motion layout?

Yes, we have wrappers for existing Android views

They behave as something between an object constructor and update function, and they're basically always nouns

Is it possible to setup all properties in a function call code block and drop the parenthesis? Eg:

@Composable
fun StoryWidget(story: StoryData) {
    // ...
    Card {
        cornerRadius = 4.dp
        elevation = 4.dp
        columns += Column {
            children += Image { file = image }
            children += Padding {
                spacing = 16.dp
                content = Text { content = story.headline }
            }
        }
    }
}

No, the syntax is that of function calls

Will there be a version of compose that can be converted in runtime? That way there can be support for custom UI fetched from remote repositories. It can be good for things like custom popups or A/B testings

Yes, they return Unit, but the Compose annotation is hooked up to a compiler plugin and this causes some magic in generating a model/hierarchy of the views (that is what I understood from my unit-testing question here: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1557666472013700?thread_ts=1557666472.013700&cid=CJLTWPH7S )

Any tips on why Compose functions are structured via

@Compose

annotation rather than something more common in Kotlin dsl’s

Compose.foo()

extensions on some context object? It seems to me that it could make this more extensible and user-friendly than annotations and compiler plugins I’ve read about it somewhere that devs went out from traditional “build-view-tree -> diff-view-tree -> dispatch-changes” way to improve performance. Are there any studies on how much actual performance gained?

Setting aside the performance question entirely, the decision to use unit functions like this is also a win for the API shape itself. If you call something, it's part of the composition. You can use normal looping and control flow constructs without requiring people to use functional map/filter/etc. as the only option

that's really interesting because using this API we will be able to write for loops but we close the door to other interesting parts like testing

for unit testing, the "virtual dom" or whatever you want to call it could be the key to success

let me know if you need a beta tester or something for the testing part. I've been writing tests for Android using many different approaches and it could be awesome if I can help with this part

There is an implicit context in which the ui/tree is rendered, which can be queried, IIRC

They can't. The behavior is similar to

suspend

in that they can only be called from other

@Composable

functions