Closed ogoffart closed 2 weeks ago
tronical
commented
2 weeks ago Hmm, the template comes with the vscode extension recommendations, .gitignore, etc. - I think it's a good thing to start. My preference would be to either change the quickstart to use the separate .slint file or we change the rust template to use the macro instead of build.rs. Shouldn't they be in sync?
ogoffart
commented
2 weeks ago cargo new also add the .gitignore
Good point about the vscode recommendation but i don't think it's worth it. (We do the recommendation in the text and not everyone uses vscode)
On the other hand, the value of not using a template is that it show it is simpler and there is no magic. I value the "start from scratch" approach as an educative one.
My preference would be to either change the quickstart to use the separate .slint file
Yeah, that would be fine. But that's a bigger change. In the mean time, I think we should merge this PR.
or we change the rust template to use the macro instead of build.rs. Shouldn't they be in sync?
I think the point is that the build.rs setup is more complicated and also the recommended way for bigger application. And therefore the template. While the macro is simpler to start with and for small applications.
FloVanGH
commented
2 weeks ago
cargo newalso add the .gitignore Good point about the vscode recommendation but i don't think it's worth it. (We do the recommendation in the text and not everyone uses vscode)On the other hand, the value of not using a template is that it show it is simpler and there is no magic. I value the "start from scratch" approach as an educative one.
My preference would be to either change the quickstart to use the separate .slint file
Yeah, that would be fine. But that's a bigger change. In the mean time, I think we should merge this PR.
or we change the rust template to use the macro instead of build.rs. Shouldn't they be in sync?
I think the point is that the build.rs setup is more complicated and also the recommended way for bigger application. And therefore the template. While the macro is simpler to start with and for small applications.
I'm still not happy with the macro also for small applications, because in my eyes it is bad practices and makes it really hard to get a good separation of components. So I see it more like an example helper. I think from the beginning we should teach the people to do it a good way.
So yes I also agree to make the for the slint file separation later :-).
tronical
commented
2 weeks ago What's a bad practice about the macro? Why does it make separation of components harder?
For the record: I used to also have a "metal block" about the macro, but for me this fixed it, in the sense that I think that's a rather elegant way to migrate from inline to external files.
slint::slint! {
import { MainWindow } from "memory.slint";
}What's a bad practice about the macro? Why does it make separation of components harder?
For the record: I used to also have a "metal block" about the macro, but for me this fixed it, in the sense that I think that's a rather elegant way to migrate from inline to external files.
slint::slint! { import { MainWindow } from "memory.slint"; }
For example it does not work with build.rs and you define your library import paths there. And if you separate it your code, also the main slint stuff should be in a separate file. It's really hard to teach that people to do it in other way e.g. for a more complex application after have gotten used it the other way. I speak from experience, not specifically from the macro but similar topics on other projects.
ogoffart
commented
2 weeks ago I'm merging this as this fix the immediate inconsistency issue.
Whether the quickstart should be converted to use slint-build is another debate that is outside of the scope of this PR.
The quickstart use the slint macro which doesn't use build.rs. The template is conter-productive as it uses the slint-build and build.rs to compile Slint file. If we're not using that, it is much easier to start with a fresh clean project.