QML issues: Difference between revisions

Revision as of 16:30, 10 June 2011

This page contains a list of issues and required features that we would like to see fixed/implemented in QML(2)

Enter the issues you wish fixed in the following form:

Idea:	Change QML2
Summary:	We have a chance to change stuff now
Proposed solution:	We change things
Discussion:	http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/

Idea:	QtScript integration
Summary:	a way to expose from c++ to qml QScriptValues, register non qobject data types and functions
Proposed solution:
Discussion:

Idea:	Improved namespace support
Summary:	QML should support namespaces in property types (property MyWidgets.Button myProperty)
Proposed solution:
Discussion:

Idea:	Improved runtime warnings
Summary:	For example: QML should complain when the drag target is invalid
Proposed solution:
Discussion:

Idea:	No QtSql dependency
Summary:	Remove QtSql dependency from QML library: QtSql should be loadable at runtime
Proposed solution:
Discussion:

Idea:	C++ hooks to intercept import statements
Summary:	different ways to resolve pathnames of imports, as well as basic security features are needed
Proposed solution:	if the pathname resolution could be reimplementable in a custom c++ function, would be possible to resolve them differently (for instance implementing a fallback chain) or implement basic security features (for instance blacklisting or whitelisting of imports)
Discussion:

Idea:	MouseEvent.globalX/Y
Summary:	MouseEvent should also expose globalX and globalY
Proposed solution:	adding those properties to the declarative mouse event would be source compatible for existing qml files
Discussion:

Idea:	Layouts
Summary:	Layouts
Proposed solution:	current positioners could have an optional property to resize childs that have minimum/maximum/preferredWidth or height not null
Discussion:

Idea:	Full set of graphical primitives
Summary:	at least Line, Path, Ellipse are missing
Proposed solution:
Discussion:

@@ Line 77: / Line 77: @@
 ==Required features==
+{|
+|-
+! Idea:
+! C++ hooks to intercept import statements
+|-
+| Summary:
+| different ways to resolve pathnames of imports, as well as basic security features are needed
+|-
+| Proposed solution:
+| if the pathname resolution could be reimplementable in a custom c++ function, would be possible to resolve them differently (for instance implementing a fallback chain) or implement basic security features (for instance blacklisting or whitelisting of imports)
+|-
+| Discussion:
+|-
+|}
 {|