Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default backend selection depending on platform #3643

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ogoffart
Copy link
Member

Don't have Qt by default on non-linux

Make skia the default on non-wasm (but unfortunately still builds femtovg by default)

In order to have default feature dependent on the platform, one must use an intermediate crate

Don't have Qt by default on non-linux

Make skia the default on non-wasm  (but unfortunately still builds
femtovg by default)

In order to have default feature dependent on the platform, one must use
an intermediate crate
@ogoffart
Copy link
Member Author

I'm putting this up for discussion. But I actually don't think it is a good idea to merge as is, because it will slow down compilation by building both skia and femtovg.
Also Qt is the default but usually doesn't get enabled on Win and Mac anyway because it's not installed usually.

@tronical
Copy link
Member

Yeah, I guess in practice this is a no-op on macOS, Windows, and wasm.

I acknowledge that once rust-skia built-in binaries don't apply, the barrier of entry for trying Slint increases a lot - and then the build time goes by a lot, too. The big advantage of femtovg is that it's the opposite: a super low barrier of entry for trying out Slint.

In my experience so far, we end up two tiers: It's easy to get going right now (especially if you don't have Qt installed) and for some users that's enough. And often for others we recommend "upgrading" to Skia, at which point it is a conscious choice and trade-offs are evaluated. I have the feeling that we could keep going with this strategy for a little longer.

The topic of the Qt backend is an entirely different one (with other issues such as complicating cross-compilation) and I think if we want to make changes there we need to agree on the styling first.

@ogoffart
Copy link
Member Author

I think if we want to make changes there we need to agree on the styling first.

What do you mean agree on the styling? I though we already agreed in #3431 (which is implemented: Qt is no longer the default style even if Qt is found on windows and mac)

@tronical
Copy link
Member

I think if we want to make changes there we need to agree on the styling first.

What do you mean agree on the styling? I though we already agreed in #3431 (which is implemented: Qt is no longer the default style even if Qt is found on windows and mac)

Sorry, that came across wrongly. I'm only talking about Linux now. According to #3431 (comment) we need the Qt backend, which comes with benefits and trade-offs. Over time the benefits and trade-offs change, and so if we ever end up discussing those again, then it's possible that in the future we come to a different conclusion and perhaps technical solution as we did in #3431 . If that conclusion implies that we don't need the Qt style by default anymore, then what I was referring to talking - possibly making the qt backend not the default anymore on Linux - will become affected. Anyway, this isn't news - I don't to suggest changing anything in this PR. With this comment I merely want to clarify what I think we agree on: We can only make changes to the default Qt backend choice on Linux if we make changes to the default styling choice on Linux.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants