QtWebEngine/WorkShop 2025 August
Jump to navigation
Jump to search
When: 2025-08-26 - 2025-08-27
See QtWebEngine/Features and QtWebEngine/WorkShop_2024_October for the last workshops
Topics
Agenda
Tuesday
- Agenda discussion
- How to follow up on workshop
- Went through last workshop notes
- We are down on man power this next year, so need to take that into account
- QtWebView status and feature requirements
- Platforms
- We have now WebView2 on MSVC, but not clang/mingw
- Android
- iOS/macOS
- WASM, what to do, should we ignore, who wrote it?
- We should delete winRT backend
- Permissions
- Can we handle WebRTC etc..
- Fullscreen requests
- Unknown permission for stuff we dont handle.
- Delegates
- Could be provided if using QWidgets API
- Integrate with native widgets on Android/iOS.
- But we recommend QML for embedded anyway
- Might already be handled within the libraries used by the plugins
- needs to be tested.
- WebActions
- Do we want them
- if not, which of them do we need?
- History API
- JavaScript evaluation
- With or without callback
- can callbacks be done with console write?
- Is very useful for our own testing
- With or without callback
- WebChannel
- should be possible already, but adding convinience API might be desirable
- Find API
- Favicon info
- Downloads
- Clipboard interaction
- Might need to be tested
- Off the record mode
- New window/tab handling
- What does qtwebview currently do?
- Windows might just open new windows we then dont have any API for.
- Plugin capability test api
- Platforms
- QtWebView action steps
- For 6.11, do the following
- Test delegate interaction
- if handled internally, we can do QWindow API
- if we need to handle it, QWidgets API would be simpler
- Also test new window handling
- Capability API to ease implementation of features per plugin
- JavaScript API for testing purposes.
- Feature brainstorm
- Qt 6.11 planing
- QtWebView API
- Extensions API status
- Something useful
- like tabs API
- AdBlocker test
- WebChannel integration
- Something useful
- Rust stuff
- Printing API for frames (new api), JIRA ticket
- The whole update Chromium 138/140 horror story
- Qt 6.11 planing
- Support brainstorm
- Rust requirement
- Start with official stable rust
- Might be a problem in the longer run
- Google uses unstable rust
- Google uses patched libraries
- Allan update his patch
- Chrome standard library
- Google is now requiring their own binaries
- Look into what Linux distros are doing (Peter will check Gentoo, Allan will check Debian)
- AI patch set. MSVC conflict issue, inline asm and stuff.
- Might be possible to only disable on Windows ARM (or use clang-cl)
- Need to check compatibility between cl and clang-cl
- QML issue
- Working with CI
- Is super slow
- Nothing has been done about if for years
- Nobody seems to know how to fix the systemic issues
- What we learned from Windows on Arm issues
- Build took way too long on native build after we finished making it work (40 hours)
- We tried a cross compilation approach, Michael ended up having to do most of the work
- But it was broken in packaging combined native and cross-build binaries, with different configurations
- Now we have matching config builds
- Are trying to push for using full cross compilation build, but it requires cmake and qmake update to make the cross-build libraries working for native end-user builds.
- Another approach is using 128 core native builds.
- Add clang-cl CI config
- Allan will try to add it
- Rust requirement
- Connect to Google/Chromium owners
- Upstreaming might help build up clout
- New owners might not even want to work with us
- Chrome team in Munich. We should try to connect with them
- Backlog grooming
- Follow-up discussion
- Dinner
Wednesday
- Chromium patch workshop
- See QtWebEngine/WebEngine_workshop_patches from last workshop
- Documentation workshop
- QtWebView redux
- Conclussion
Summary
What to do better next time?