Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.
QtCS2018 QtQuick
Jump to navigation
Jump to search
Topics
- controls, quick and QML engine people working together better
- more cooperation between Berlin (designer developers) and Oslo people to ensure optimization opportunities are found
- refactorings in QtQuick break Controls sometimes
- CI could help
- testing private API is too much trouble though
- CI could help
- more cooperation between Berlin (designer developers) and Oslo people to ensure optimization opportunities are found
- marketing/docs: focus on application development more than on building up controls from primitives
- examples have to be in their own repo so they can use Controls
- but QML is different than widget development: customers need to understand how custom controls are built too
- get more QtCore example apps using Quick rather than Widgets
- examples have to be in their own repo so they can use Controls
- QtQuick Core Declarative QML bug category is confusing
- keyboard focus, keyboard operating controls without mouse or touch (e.g. for drone UIs)
- disabled buttons break tab navigation
- too much work, JS etc.
- important for lots of embedded UIs
- disabled buttons break tab navigation
- changing groups of properties more efficiently
- avoid multiple binding evaluation overhead
- avoid explosion of cascading changes and repeating re-evaluations
- pull rather than push, lazy re-evaluation
- dirty flag, maybe update on screen refresh
- onXChanged JS handlers might cause trouble...
- synchronized groups or blocks
- avoid multiple binding evaluation overhead
- bad or lacking C++ APIs
- text
- QQmlListProperty
- it's not just making more public headers
- bindings
- text
- working with NPM modules
- maybe like NAPI (? or something like that) from Microsoft
- QML and Python
- why have Python + JS when you could just have Python?
- come up with a way to use Python to create bindings
- capturing dependencies is hard
- capturing dependencies is hard
- add C++ QtQuick APIs and expose them to Python
- why have Python + JS when you could just have Python?
Current work in progress
- TableView
- Pointer Handlers
- Fix up the version number mess (QUIP 99 https://codereview.qt-project.org/#/c/215625/ )
- main issue is name clashes: existing customer code vs. newly introduced stuff in new versions of QtQuick
- ES6
- test suite is updated
- most ES7 features are there
- missing: atomics, weak map and set, reflect, promises, proxy
- ES8 will add async stuff... that's later
- test suite is updated
- Tracing JIT
- Optimizing simple bindings
Upcoming work
- TreeView
- Dock widgets? ;-) (really?)
- better start prototyping then, to see what goes wrong
- inevitable performance bottlenecks
- better start prototyping then, to see what goes wrong
- Native menus
- Strict mode
- improve portability
- type safety, strong typing
- resolution of types at compile time
- need to specify types of arguments, variables etc. (use TypeScript syntax)
- sane scoping
- no implicit type conversions (i.e. equality testing will not be the same)
- improve portability
Issues
- Complex UIs are slow, can't afford too many objects
- Layer.enabled: true can help
- Item Views don't have true delegates like widget item views do
- Looking up property bindings by name is slow