Simon Hausmann

Hmmm. I think the majority of modules in our repo don't use `subdir/mod.rs`. Is there a specific future change that you have in mind that benefits from this?

> There is no strong intention to unify using mod.rs, so keeping the source file names as they are is fine. Unless there's a good reason to handle things differently...

I haven‘t tried to reproduce this, but it’s very plausible. I know for femtovg somebody contributed a fix that solved this but that solution is not on the glyph level...

I’ll mark this as a legit bug, although analysis remains pending on where this should be fixed (slint or parley).

> If anything we could detect this specific case and have a warning. That might be an option, I agree. Otherwise I'd say that this isn't a bug.

Hi! Could you elaborate a bit what this PR does? As part of https://github.com/slint-ui/slint/issues/4136 we've been working on generating a `.py` file for `.slint` files (along with embedding typings) in...

> WHY `api/python/compiler` is a downloader?? > > > > A maturin-powered `pyproject.toml` is enough for this case. The idea was to re-use the same binaries we've already built for...

> > > WHY `api/python/compiler` is a downloader?? > > > > A maturin-powered `pyproject.toml` is enough for this case. > > > > > > The idea was to...

> @tronical should we expose apis from `i_slint_common::for_each_builtin_structs!` & ` i_slint_common::for_each_enums!(add_enum);`? I don't think we expose these as-is in the other languages, so I don't think we should do so...

> > I don't think we expose these as-is in the other languages, so I don't think we should do so for Python. > > Are you thinking that it's...