Re: [Development] Settings API for QML
On 12/12/2012 01:16 AM, Thiago Macieira wrote:
On terça-feira, 11 de dezembro de 2012 15.55.52, Alan Alpert wrote:
Would you care to sketch out what your PersistentSettings element
would look like in practice?
In a non QML approximant syntax:
Rectangle {
PersistentSettings {
id: settings
property int width path(application.width)
property int height path(application.height)
property enum ButtonOrder buttonOrder path(system.buttonOrder)
}
What about:
PersistentSettings {
id: settings
propertyMap: {
width: application.width,
height: application.height,
buttonOrder: system.buttonOrder
}
}
And have the PersistentSettings class create the width, height,
buttonOrder properties dynamically. It doesn't need to know the type,
because they are just QVariant (if the backend is implemented via
QSettings, this all should be fairly easy to implement).
Ciao,
Alberto
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QAction-like API for QML
Op 11-12-2012 21:59, Alan Alpert schreef: On Tue, Dec 11, 2012 at 10:49 AM, Shawn Rutledge shawn.rutle...@digia.com wrote: On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote: Why can't this be QML-only? For the set of controls exposed in C++-only we have a C++-only Action API. When we add a set of controls exposed in QML-only we can have a QML-only Action API. We don't Because it seems likely that the business logic of an application would be written in C++, so why not export the actions that the logic can support at the same time? The way I see it, the actions are UI logic, not business logic, and belong on the QML side of the divide (although they are right on the edge). I disagree here. The core of the action - the abstraction of the action method itself and its availability in the current state - is business logic IMO. The same goes for any value the action may have: checked, or perhaps some other value. The action logically bundles state (the availability of an action) with the action itself. The decoration around it - the user visible strings, icons and whatnot - is indeed UI logic. That's why I think that perhaps we conceptually need something like a CoreAction and a UiAction. The UiAction would 'decorate' a CoreAction with the stuff that is needed to represent it in a UI. The implementation of the UiAction part would be different for QML and Widgets, I think. Actions are a very powerful piece of glue between business and UI logic if used this way. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Settings API for QML
On Tuesday, December 11, 2012 04:40:50 PM Bache-Wiig Jens wrote:
I would also consider an even simpler API. How about we introduce a new
keyword for persistent properties and make it part of the language.
Rectangle {
id: root
persistent property width: 400
persistent property height: 300
}
What this means is that the application will automatically store its
persistent properties on exit and recall those properties on startup. By
default they would be initialised to the bound value. It will need some
attached properties or other meta data to override default storage
locations etc. And we also need to enforce id's to keep values unique
per qml file.
Jens
Interesting idea, but isn't that a recipe for horror if you ever want to
change the structure of your application? To make it possible to keep
your application settings if you change your application structure, you
will need to set those attached properties. A default generated value
will not suffice. That either leads to forcing users to set it if they
use the persistent keyword, or leading them into big trouble with
application maintenance in the future. Neither sounds attractive.
You certainly have a valid point and I agree that the persistent property
will need an explicit name. There are several ways we could try to amend it
though:
Using special syntax:
Rectangle {
persistent property int width: [application.width, 400]
persistent property int height: [application.height, 400]
}
Or perhaps get rid of the keyword altogether and just do:
Rectangle {
property int width: Qt.storedProperty(application.width, 400)
property int height: Qt.storedProperty(application.height, 400)
}
I think a dedicated syntax has two distinct advantages over a
Qt.storedProperty alike approach:
(1) In a distinct syntax we can avoid loosing the type information and
instead preserve and propagate it into the settings backend. Preserving as
much type information as possible is going to be crucial for performance
optimizations in the future.
(2) A syntax would allow for sensible group and avoiding repetitive
patterns in the settings names. In your example writing application.width
and application.height is not bad, application is repeated only twice. But
if you think of a real world use-case, then you have application repeated
many many times, which is prone to errors (application vs. accidentally
typing applcation) and it's not very readable. Therefore I think a more
explicit syntax is more suitable:
PersistentSettings {
id: mysettings
group: org.qt.examples.myapp.geometry
property int width: 800
property int height: 600
}
Rectangle {
width: mysettings.width
height: mysettings.height
}
Simon
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enumerations in QML
On Dec 11, 2012, at 4:47, Alan Alpert 4163654...@gmail.com wrote:
People keep asking for enumerations in QML. See QTBUG-15483 and
QTBUG-14861, both assigned to old Nokia identities (so don't trust
that 'in progress' ;) ). Now I don't know when these issues will be
resolved, but there's an important discussion to have before it can
even be scheduled: What would proper enum support look like in QML?
QTBUG-15483 suggests 'property Bar::Weather weather: Bar.Sunny', for
using the C++ 'enum Weather { Raining, Sunny, Cloudy }'. But
QTBUG-14861 does not include a suggestion of what the QML syntax for
declaring an enum should be (just a suggestion for how we could hack
it in there). It's totally not obvious to me what a good QML API for
declaring enums would be, and that could have run-on effects on how
they're used in property declarations. All we know is that Bar.Sunny
is how you use the enum exposed from C++, and that will need to
continue to work with QML defined enums. Note that property
Bar::Weather weather is just a suggestion as well, I actually suspect
property Bar.Weather weather would fit in better (but it depends on
how you declare them).
What should enumeration declarations in QML look like?
And, also important: how much slower is it allowed to be than the current
implementation?
I remembered that there was talk about enums in QML before, so I dug around a
bit, and behold:
The problem with enums is that we couldn't make them fast. They will always be
a lot slower than normal string literals. That is mostly because we could not
avoid the name lookup. Think about,
Text {
alignment: Alignment.Vertical | Alignment.something
}
there is no way for you to remove the name lookups for Alignment, Vertical,
and something. Also, there is no way for you to distinguish Types (e.g.
Item, Rectangle, and co...) from Enums (in our case Alignment). That means,
you cannot build the correct list of dependencies when loading a QML Component.
-- Erik.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Settings API for QML
On Wed, Dec 12, 2012 at 10:03 AM, Simon Hausmann
simon.hausm...@digia.com wrote:
On Tuesday, December 11, 2012 04:40:50 PM Bache-Wiig Jens wrote:
I would also consider an even simpler API. How about we introduce a new
keyword for persistent properties and make it part of the language.
Rectangle {
id: root
persistent property width: 400
persistent property height: 300
}
What this means is that the application will automatically store its
persistent properties on exit and recall those properties on startup. By
default they would be initialised to the bound value. It will need some
attached properties or other meta data to override default storage
locations etc. And we also need to enforce id's to keep values unique
per qml file.
Jens
Interesting idea, but isn't that a recipe for horror if you ever want to
change the structure of your application? To make it possible to keep
your application settings if you change your application structure, you
will need to set those attached properties. A default generated value
will not suffice. That either leads to forcing users to set it if they
use the persistent keyword, or leading them into big trouble with
application maintenance in the future. Neither sounds attractive.
You certainly have a valid point and I agree that the persistent property
will need an explicit name. There are several ways we could try to amend it
though:
Using special syntax:
Rectangle {
persistent property int width: [application.width, 400]
persistent property int height: [application.height, 400]
}
Or perhaps get rid of the keyword altogether and just do:
Rectangle {
property int width: Qt.storedProperty(application.width, 400)
property int height: Qt.storedProperty(application.height, 400)
}
I think a dedicated syntax has two distinct advantages over a
Qt.storedProperty alike approach:
(1) In a distinct syntax we can avoid loosing the type information and
instead preserve and propagate it into the settings backend. Preserving as
much type information as possible is going to be crucial for performance
optimizations in the future.
(2) A syntax would allow for sensible group and avoiding repetitive
patterns in the settings names. In your example writing application.width
and application.height is not bad, application is repeated only twice. But
if you think of a real world use-case, then you have application repeated
many many times, which is prone to errors (application vs. accidentally
typing applcation) and it's not very readable. Therefore I think a more
explicit syntax is more suitable:
PersistentSettings {
id: mysettings
group: org.qt.examples.myapp.geometry
property int width: 800
property int height: 600
}
Rectangle {
width: mysettings.width
height: mysettings.height
}
Simon
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
How about:
This one would be singleton.
PersistentSettings {
id: settings
// All properties defined in here are the global properties
property int width: 800
property int height: 600
// Perhaps enforce that a GroupSettings item can only be
constructed within the PersistentSettings item in an attempt to
enforce settings to be located in one QML file. Don't know if that's
wise or not. Just brainstorming.
GroupSettings {
id: myGroup
property int width: 800
property int height: 600
}
}
Then to use it:
Item {
width: settings.width
}
To use the group settings:
Item {
width: settings.myGroup.width
}
Just some brainstorming. I do like this syntax! It looks very easy and
understandable to use.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Convenience Imports in QML
On Dec 11, 2012, at 4:25 AM, Alan Alpert 4163654...@gmail.com wrote: import Qt 5.0 Which imports all QML modules in the Qt Essentials released with 5.0.0 (except QtQuick 1). It would be the equivalent of import QtQml 2.0 import QtQuick 2.0 import QtQuick.Window 2.0 import QtQuick.Particles 2.0 import QtAudioEngine 1.0 import QtMultimedia 5.0 import QtWebkit 3.0 How about allowing imports without the version number? import QtQml - give me the most recent QtQml for the current Qt install To explain where I'm coming from, look at Qt Creator which compiles agains Qt 4 and Qt 5 from the same branch. This is great: there is a single code base to maintain, there is no confusion on which one to get, and you don't get a combinatorial explosion of branches when you branch Qt Creator for minor releases. During my (brief) stint as desktop components maintainer I wanted to do the same for those: absorb the differences between QtQuick1 and QtQuick2 and present a unified API to users. On the C++ side I had the tools I needed (#ifdefs), but there was no way around the QML imports versioning. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qml mime types
I think it could be useful to do a small recap on mime types, as that is what I am interested in, not extensions (ignore if it is obvious to you): a mime type identifies a type of file, mime types are hierarchical, i.e. a mime type can be a subclass of another. For example text/plain; charset=utf-8 is a superclass to a lot of types. If you don't know how to handle type x, but you know how to handle its superclass text/plain; charset=utf-8 then you might handle the file like that. When you get a file you will have to figure out its mime type. That might come in a meta data, or be guessed from some magic content at the beginning of the file, but very often it is done through the file extension. Still it is possible for a given mime type to have no, or several extensions (think the text/plain; charset=utf-8 example). Mime types are about how to handle the file in a meaningful way. For an editor that can do syntax highlighting for QML, (the use case at the origin of this whole discussion), knowing that a file is some kind of QML is valuable, and I would argue also to decide what to do when trying to open it on linux for example. If it is a more specific type it knows how to handle it might do better, it might have default imports and search paths. I would like to register some types now, later we can always extend them with new types. As said I think that having a type for any file with QML syntax (.qbs and .qmltypes do use the qmlparser, but don't use qdeclarative) is valuable. What remains to be seen is the type of the current qml files. I propose the following hierarchy: text/plain; charset=utf-8 text/vnd.qt.qml-base : a file using the qml syntax in some context text/vnd.qt.qml : the current .qml files text/vnd.qt.qbs : a qbs file text/vnd.qt.qml-meta-info : qmltypes meta info text/vnd.qt.qml-project : a qmlproject file later we might want to split text/vnd.qt.qml in several subtypes (and probably own extensions) for example: text/vnd.qt.qml-qtquick1 text/vnd.qt.qml-qtquick2 text/vnd.qt.qml-qq2-partial text/vnd.qt.qml-qq2-full but I think it is better to leave that for another time, we just have to make sure that we can accomodate them in a reasonable way if/when the need arises. I did think about the +qml, but that did just look strange to me, so I skipped it, but I am willing to reconsider that if someone feels strongly about that. Fawzi From: Alan Alpert [4163654...@gmail.com] Sent: Tuesday, December 11, 2012 9:03 PM To: Mohamed Fawzi Cc: Knoll Lars; fa...@kde.org; development@qt-project.org Subject: Re: [Development] Qml mime types On Tue, Dec 11, 2012 at 6:12 AM, Mohamed Fawzi fawzi.moha...@digia.com wrote: I sort of expected qml-qt-quick to be considered not ok (also Marco Bubke raised that point), which is a fair point, considering BB for example. I am open to better naming, still I would like to differentiate file using qml syntax from .qml file that is supposed to be loaded in the qml runtime or qmlscene as that is an useful distinction for example to decide how to open such a file, or which search path to consider for modules in an editor. Maybe it is useful now, but that's not the correct conceptual split. Firstly QML is a language, not just a syntax. Secondly the runtime discussion is heading towards the correct conceptual split, so we probably should too. This would mean that .qml means a file written in the QML language that can probably be loaded with the qml runtime. I say probably because there might be subcomponents that don't do much on their own, because we encourage users to split up their code into different files. .qqk means a file written for qmlscene because it's an incomplete QtQuick 2 scene (qmlscene also uses the QML language). I did just make this extension up, but that's because it only really needs to be differentiated once we have a real QML runtime. .qbs means a file written for qbs (QBS also uses the qml language). So basically I'd advocate making just .qml mean any file written in the QML language, and let the specializations like QtQuick 2 scenes have their own extensions if they want to differentiate themselves. I understand that the current reality is that virtually all .qml files use QtQuick, and most of those are still using QtQuick 1. The important thing to keep in mind is that back in the Qt 4.x days QML was still a nascent technology and the language was not well separated from the single use-case. I maintain that is the correct way to start, because without one stellar use-case implemented then the technology would never get anywhere. But now QML is starting to develop beyond the one usecase, and we're only now implementing the proper abstractions around that (like the QML runtime). We need to move on from the limitations of QtQuick 1, like the lack of a top-level window item, as much as possible (without screwing over QQ1 users, as much as possible),
[Development] If you are working on documentation...
If you have trouble creating a link to something (usually title or subtitle)
because the title or subtitle you are trying to link to exists in more than one
document and your link goes to the wrong one, consider using the \target
command. It didn't work across modules until today. The relevant qdoc change is
integrating in stable as I write.
Suppose you have this as a section header:
\section1 Qt Script
and you want to link to it like this:
See the section called \l {Qt Script} for more details.
This might not work because there is module page with the title Qt Script. So
if you want to link to the section heading, you might get a link to the module
page instead, and if you want to link to the module page, you might get a link
to the section heading.
In this example, if your link goes to the wrong page, you can use the \target
command. It defines a string you can link to:
\target a_unique_string
\section1 Qt Script
Then you can write:
See the section called \l {a_unique_string} for more details.
...and your link will go to the correct page.
Never use '#' ':' or '.' in the target string, and it is a good idea not to use
'-' either because qdoc replaces blanks with a '-' when it outputs the target
for a title or subtitle, so the target for Qt Script become qt-script.
martin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] heads-up: QtWebKit's SQLite dependency
Hi, QtWebKit requires SQLite for various web related storage mechanism (including cookies). That dependency is quite old actually, but we've done some changes now that clean up the way that dependency is satisfied. Ideally should affect only very few people, but it is quite likely to include folks cross-compiling Qt, targetting Linuxy platforms. The new state of the SQLite dependency union therefore is: (1) WebKit will try to use pkg-config to detect and use SQLite from the system. Alternatively on Mac OS X sqlite is always availble as a system library and conveniently used from there. (2) If option number 1 doesn't apply, then we try to see if QtWebKit is being built as part of a qt5.git checkout (same applies to release tarballs) and we will try to compile in a copy of SQLite right into QtWebKit, the copy that's distributed in qtbase/src/3rdparty/sqlite. (3) If we also fail to locate Qt's copy of sqlite, then we do require the SQLITE3SRCDIR environment variable to be set to point to a location where the sources can be found. qtbase/src/3rdparty/sqlite is one such location. Folks cross-compiling are likely to miss case (1) and might consider enabling the use of pkg-config. Folks compiling on Windows should consider building under qt5/ or setting the SQLITE3SRCDIR environment variable. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] If you are working on documentation...
Oops! The link to the target example should be this:
See the section called \l {a_unique_string} {Qt Script} for more details.
martin
On Dec 12, 2012, at 12:22 PM, Martin Smith wrote:
If you have trouble creating a link to something (usually title or subtitle)
because the title or subtitle you are trying to link to exists in more than
one document and your link goes to the wrong one, consider using the \target
command. It didn't work across modules until today. The relevant qdoc change
is integrating in stable as I write.
Suppose you have this as a section header:
\section1 Qt Script
and you want to link to it like this:
See the section called \l {Qt Script} for more details.
This might not work because there is module page with the title Qt Script. So
if you want to link to the section heading, you might get a link to the
module page instead, and if you want to link to the module page, you might
get a link to the section heading.
In this example, if your link goes to the wrong page, you can use the \target
command. It defines a string you can link to:
\target a_unique_string
\section1 Qt Script
Then you can write:
See the section called \l {a_unique_string} for more details.
...and your link will go to the correct page.
Never use '#' ':' or '.' in the target string, and it is a good idea not to
use '-' either because qdoc replaces blanks with a '-' when it outputs the
target for a title or subtitle, so the target for Qt Script become qt-script.
martin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] If you are working on documentation...
On Dec 12, 2012, at 12:22 PM, Martin Smith wrote:
If you have trouble creating a link to something (usually title or subtitle)
because the title or subtitle you are trying to link to exists in more than
one document and your link goes to the wrong one, consider using the \target
command. It didn't work across modules until today. The relevant qdoc change
is integrating in stable as I write.
Suppose you have this as a section header:
\section1 Qt Script
and you want to link to it like this:
See the section called \l {Qt Script} for more details.
This might not work because there is module page with the title Qt Script. So
if you want to link to the section heading, you might get a link to the
module page instead, and if you want to link to the module page, you might
get a link to the section heading.
In this example, if your link goes to the wrong page, you can use the \target
command. It defines a string you can link to:
\target a_unique_string
\section1 Qt Script
Then you can write:
See the section called \l {a_unique_string} for more details.
That's wrong. It should be:
See the section called \l {a_unique_string} {Qt Script} for more details.
...and your link will go to the correct page.
Never use '#' ':' or '.' in the target string, and it is a good idea not to
use '-' either because qdoc replaces blanks with a '-' when it outputs the
target for a title or subtitle, so the target for Qt Script become qt-script.
martin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enumerations in QML
Unto all so did sayeth Alan:
What should enumeration declarations in QML look like?
Did respondeth Erik:
And, also important: how much slower is it allowed to be than the current
implementation?
I remembered that there was talk about enums in QML before, so I dug
around a bit, and behold:
The problem with enums is that we couldn't make them fast. They will
always be a lot slower than normal string literals. That is mostly because
we could not avoid the name lookup.
Text {
alignment: Alignment.Vertical | Alignment.something
}
there is no way for you to remove the name lookups for Alignment,
Vertical, and something. Also, there is no way for you to distinguish
Types (e.g. Item, Rectangle, and co...) from Enums (in our case
Alignment). That means, you cannot build the correct list of dependencies
when loading a QML Component.
Ouch. That is quite unexpected.
We seem to have multiple intentions regarding adding Enums to QML:
(1) Those with a native (C/C++) background may have thought Enum to be
faster than String (e.g., performance-goal)
(2) Some may prefer the cleaner-look by using an unquoted Enum over a
quoted string literal
(3) Some may expect a compile-time check for (valid) enumerated-values,
as compared with a run-time check with string-lookups (? this may not be
a real consideration depending on how the QML parsing engine works)
(4) Lack of Enums in QML is (another) example of how QML might be
considered a second-class-citizen (mentioned by Chris, another example
being composite types in QML are not backed by a QQmlType and thus are not
available in JavaScript as are types defined in C++)
IMHO, the performance is the biggest issue, as we have currently
work-arounds to enable enumerations in QML.
Some of the post-V8-engine discussion may address the performance issue,
at which point all of the above considerations could be achieved. (Lars
may comment on this?)
So: I want Enums in QML, but only if they are as-fast-or-faster than
string lookups. I'm quite happy to defer this feature until that can be
achieved.
--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Branches
On Mon, Dec 03, 2012 at 04:29:24PM +, Knoll Lars wrote: master is closed for new pushes and will go away in a couple of weeks by the latest. this has happened now - the master branches are all deleted. due to the mess found in the master branches, i simply deleted them without merging them anywhere. already integrated changes have been re-pushed for stable or dev as considered appropriate by me - that's why you may see your own changes up for review again. just verify the target branch and have your reviewers re-approve each. still pending changes for master need to be re-pushed by their owners. i suggest we make a change abandonment party in the new year to weed out the obsolete stuff somewhat aggressively. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5 packaging and binary renaming
Hi there,
For anyone packaging Qt 5 and renaming the binaries moc, rcc, uic, etc, please
remember to also change the CMake config files using those to the renamed
binaries.
The files to change are:
In qtbase.git:
* src/widgets/Qt5WidgetsConfigExtras.cmake.in
* src/dbus/Qt5DBusConfigExtras.cmake.in
* src/corelib/Qt5CoreConfigExtras.cmake.in
In qttools.git:
* src/linguist/Qt5LinguistToolsConfig.cmake.in
You need to change the IMPORTED_LOCATION value in the files. For example:
diff --git a/src/corelib/Qt5CoreConfigExtras.cmake.in
b/src/corelib/Qt5CoreConfigExtras.cmake.in
index 0df2703..70c32dc 100644
--- a/src/corelib/Qt5CoreConfigExtras.cmake.in
+++ b/src/corelib/Qt5CoreConfigExtras.cmake.in
@@ -18,9 +18,9 @@ if (NOT TARGET Qt5::moc)
set_target_properties(Qt5::moc PROPERTIES
!!IF isEmpty(CMAKE_BIN_DIR_IS_ABSOLUTE)
-IMPORTED_LOCATION
\${_qt5_corelib_install_prefix}/$${CMAKE_BIN_DIR}moc$$CMAKE_BIN_SUFFIX\
+IMPORTED_LOCATION
\${_qt5_corelib_install_prefix}/$${CMAKE_BIN_DIR}moc-qt5$$CMAKE_BIN_SUFFIX\
!!ELSE
-IMPORTED_LOCATION \$${CMAKE_BIN_DIR}moc$$CMAKE_BIN_SUFFIX\
+IMPORTED_LOCATION \$${CMAKE_BIN_DIR}moc-qt5$$CMAKE_BIN_SUFFIX\
!!ENDIF
)
# For CMake automoc feature
Note also that if you move the mkspecs, you also need to patch the cmake
files. For example:
diff --git a/src/corelib/Qt5CoreConfigExtras.cmake.in
b/src/corelib/Qt5CoreConfigExtras.cmake.in
index 0df2703..24e4625 100644
--- a/src/corelib/Qt5CoreConfigExtras.cmake.in
+++ b/src/corelib/Qt5CoreConfigExtras.cmake.in
@@ -44,7 +44,7 @@ set(Qt5Core_MOC_EXECUTABLE Qt5::moc)
set(Qt5Core_RCC_EXECUTABLE Qt5::rcc)
!!IF isEmpty(CMAKE_DATA_DIR_IS_ABSOLUTE)
-list(APPEND Qt5Core_INCLUDE_DIRS
\${_qt5_corelib_install_prefix}/mkspecs/$${CMAKE_MKSPEC}\)
+list(APPEND Qt5Core_INCLUDE_DIRS
\${_qt5_corelib_install_prefix}/share/qt5/mkspecs/$${CMAKE_MKSPEC}\)
!!ELSE
list(APPEND Qt5Core_INCLUDE_DIRS
\$${CMAKE_DATA_DIR}mkspecs/$${CMAKE_MKSPEC}\)
!!ENDIF
Note that the tests are in the source packages, so to verify that you have
correct packages from the cmake point of view, you can do this:
cd tests/auto/cmake mkdir build cd build cmake .. ctest
Note that this does not work in general for all unit tests in Qt (as many of
them require Qt to be configured with -developer-build), but it will work for
the cmake tests. Please report any failures.
Thanks,
--
Stephen Kelly stephen.ke...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Updating Daemon/Service Support
From: Ahumada Sergio sergio.ahum...@digia.com To: development development@qt-project.org Sent: Wednesday, December 12, 2012 2:19 AM Subject: Re: [Development] Qt Playground - Updating Daemon/Service Support As I know others have expressed interest in helping out, here's the bug report in case you want to join/watch: https://bugreports.qt-project.org/browse/QTQAINFRA-584 Ben Does it usually take this long? I understand the RC is being released, but it doesn't seem like it should take two weeks to get approval for a space in playground. Matt it's unassigned .. so nobody got a notice about it. I didn't know who to assign it to or even that I should assign it to someone. I'll take it. Thanks! Ben ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Updating Daemon/Service Support
I didn't know who to assign it to or even that I should assign it to someone. I am sure I have not assigned anyone explicitly, and it worked out of the box. Perhaps I was just lucky. http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qt#6a17de784cf6db9124e9844959ec8ace In my opinion opinion there should be at least one default assignee for these issues. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] If you are working on documentation...
On 12 December 2012 19:22, Martin Smith martin.sm...@digia.com wrote:
If you have trouble creating a link to something (usually title or subtitle)
because the title or subtitle you are trying to link to exists in more than
one document and your link goes to the wrong one, consider using the \target
command. It didn't work across modules until today. The relevant qdoc change
is integrating in stable as I write.
Hi Martin,
Does the change also allow \l to work across modules? I just tried
writing \l{Qt Concurrent} for a page in Qt Core, to link to
http://doc-snapshot.qt-project.org/5.0/qtconcurrent/qtconcurrent-index.html,
but the compiled text was unlinked.
Sze-Howe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Branches
On quarta-feira, 12 de dezembro de 2012 14.03.52, Oswald Buddenhagen wrote: On Mon, Dec 03, 2012 at 04:29:24PM +, Knoll Lars wrote: master is closed for new pushes and will go away in a couple of weeks by the latest. this has happened now - the master branches are all deleted. due to the mess found in the master branches, i simply deleted them Would you please stop making project-wide decisions without posting to the mailing list and letting people chime in? What mess are you talking about? Do you mean that there already were 5.1 changes in master? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 packaging and binary renaming
On quarta-feira, 12 de dezembro de 2012 14.52.16, Stephen Kelly wrote: For anyone packaging Qt 5 and renaming the binaries moc, rcc, uic, etc, please remember to also change the CMake config files using those to the renamed binaries. For anyone packaging Qt 5: DO NOT RENAME the binaries. We've solved that problem in a different way. Instead, simply set the Qt 5 bindir to something else and install the qtchooser (to be released) in /usr/bin. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Foreign windows, embedding and transiency
I got a WIP branch up for preliminary review: https://codereview.qt-project.org/#change,42633 Any hints (especially on how to write automated tests for the feature) are very welcome :-) I tested it with a simple client and a Gtk socket, and it mostly works (still some focusing issues...). Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 packaging and binary renaming
On Wednesday, December 12, 2012 17:08:54 Alberto Villa wrote: On Wed, Dec 12, 2012 at 2:52 PM, Stephen Kelly stephen.ke...@kdab.com wrote: For anyone packaging Qt 5 and renaming the binaries moc, rcc, uic, etc, please remember to also change the CMake config files using those to the renamed binaries. Aren't we supposed to install them in $archdatadir/bin/ and then install the (yet to be released) wrapper (qtchooser) in bin/? Thiago just said the same thing (but he dropped kde-packager... ) : http://thread.gmane.org/gmane.comp.lib.qt.devel/8622/focus=8628 My mail was a reaction to finding these packages: https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-proper and finding that they were installing broken cmake files as a result of renaming the binaries and moving the mkspecs. So please, whether you use the wrapper tool or not, please run the cmake unit tests to ensure that you are not creating a broken situation for anyone using your packages. Thaigo, if that tool is a requirement for packagers, why is it not a release blocker for Qt 5.0? What do you expect packagers to do? Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Foreign windows, embedding and transiency
On quarta-feira, 12 de dezembro de 2012 17.24.17, Alberto Mardegan wrote: I got a WIP branch up for preliminary review: https://codereview.qt-project.org/#change,42633 Any hints (especially on how to write automated tests for the feature) are very welcome :-) I tested it with a simple client and a Gtk socket, and it mostly works (still some focusing issues...). Thanks for taking this up! But that change should have targeted the dev branch. It's new API and a new feature. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating roquetto for approver status
On 12/03/2012 04:48 PM, Thiago Macieira wrote: (...) Would anyone like to second? +1 from me Disclaimer: I'm at KDAB, like he is, too. +1 from me Disclaimer: I'm not at KDAB, but I am Brazilian like Rafael :-) +1 from me no disclaimer :) Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Foreign windows, embedding and transiency
On 12/12/2012 05:30 PM, Thiago Macieira wrote: But that change should have targeted the dev branch. It's new API and a new feature. Indeed! Though I was just interested in sharing the code with people for early feedback, so I didn't pay much care to the target branch. I'll move the next iteration to the dev branch, but I still welcome people to give some feedback on the current one. Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Settings API for QML
On Tuesday, December 11, 2012 14:51:31 Alan Alpert wrote: One thing that I started thinking about though is that we will need in this case to have a C++ and QML API that can work with the same settings (unlike the existing Local Storage API), so that the C++ and QML halves of an application can work together properly. Yes, exactly. You need to keep something similar in mind in all of your proposals. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Question about QFontconfigDatabase
Hello,
While analyzing the source code in qfontconfigdatabase.cpp (qt4), I stumbled
upon the following piece of code (beginning on line 433):
struct FcDefaultFont {
const char *qtname;
const char *rawname;
bool fixed;
};
const FcDefaultFont defaults[] = {
{ Serif, serif, false },
{ Sans Serif, sans-serif, false },
{ Monospace, monospace, true },
{ 0, 0, false }
};
const FcDefaultFont *f = defaults;
// aliases only make sense for 'common', not for any of the specials
QSupportedWritingSystems ws;
ws.setSupported(QFontDatabase::Latin);
while (f-qtname) {
registerFont(f-qtname,QLatin1String(),QFont::Normal,QFont::StyleNormal,QFont::Unstretched,true,true,0,ws,0);
registerFont(f-qtname,QLatin1String(),QFont::Normal,QFont::StyleItalic,QFont::Unstretched,true,true,0,ws,0);
registerFont(f-qtname,QLatin1String(),QFont::Normal,QFont::StyleOblique,QFont::Unstretched,true,true,0,ws,0);
++f;
}
When registerFont is called, f-qtname is passed as the family name (so
Serif, for instance), but an empty string is passed as the foundry. My
question then follows: how does Qt know where to load these families from,
since no font path is being specifying?
Thanks,
Rafael
--
Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions
smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 iOS
On quarta-feira, 12 de dezembro de 2012 18.31.47, Trismer Technologies wrote: Hello, Does anyone has information about roadmap of Qt5 for iOS ? Digia promises this port in next year but I'd like to know how the current blockers will be removed: the most important one - V8 javascript for iOS ? Are there any plans around that ? Eventually are there plans to port only QtQuick1 for iOS or maybe different JavaScript engine ? If there is an ongoing work in this area, please let us know. Maybe we could help in this matter. From what I understand, the plan is to drop V8 and replace it with a new engine, the one being developed in playground/v4vm. Help is always welcome. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Controlling QML Imports
On Tue, Dec 11, 2012 at 5:27 PM, Jan Kundrát j...@flaska.net wrote:
On Tuesday, 11 December 2012 04:23:51 CEST, Alan Alpert wrote:
For finer-grained control over QML it would make sense to have an API
allowing import restrictions. Two usecases come to mind, platform
security contexts and scriptable applications.
I'm currently using QML as a configuration language (being declarative looked
like a great fit) in a random application. The end goal was to have one file
per supported type of thing that the application works on. The description
of each thing looks like this:
import foo.bar 1.0
ThingType {
// ...
SubThing {
// ...
}
}
Because I'm stuck on 4.x for this particular application, I had to work with
what is available now. In the end, I settled on:
- Using just a QDeclarativeEngine as a good start -- no need for UI items in
my use case
- The ThingType and SubThing are actually implemented in C++
- Enforcing that the top-level item created in QML is exactly the ThingType.
This can be done when instantiating the component by checking its type via
qobject_castQMLMyTypeThing* and refusing to work with that QML file if this
cast fails
This doesn't completely fix the problem, because if the wrong thing is
instantiated it will still be able to do things in the period while
and just after it is instantiated. For example there could be side
effects from them instantiating a different type which you exposed,
and they could still do stuff in the Component.onCompleted handler.
- The ThingType has a QDeclarativeListPropertyQMLMySubThing Q_PROPERTY
which is also a default property. This way, the type of the children of the
ThingType is enforced.
Actually this isn't enforcing the type of the children. That property
has its type enforced, but properties can be dynamically added in QML.
For example
import foo.bar 1.0
import QtQuick.Window 1.0 //Hypothetical back-port of QtQuick.Window to 4.x
ThingType {
SubThing {}
property Window window: Window { } //This will create a window
}
Being able to dynamically add properties is a core part of the
language and I think it would be far, far better to restrict the types
available than to try to disable dynamic properties for some objects.
- If you need further enforcing of certain rules (each ThingType has to be
yellow), you can inherit from QDeclarativeParserStatus and implement
componentComplete. My code works like this:
if (!m_color.isYellow())
qmlInfo(this) The color must be yellow.
- Because these errors are only warnings (and it looks like you cannot really
trigger a fatal error from this stage), I have an isOk() method which I call
before I use the data structure which gets created as a result of these QML
files.
If it was possible to prevent defining the QtQuick namespace from being
available, that would solve half of my problems (with the required property
validation being the remaining half).
Property validation within an item will always have to be done by the
item, so that's the best we'd be able to do.
The blurb about qmlInfo() was in particular rather hard to discover -- I had
read the docs about it before but could not recall the name of the function
when I needed it. Searching for it via phrases like qml error reporting did
not help much.
It's not one of the most public functions in QML. But there should
probably be a mention of it on the page about writing QML types in
C++, if anyone wants to try writing that.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Controlling QML Imports
On Mon, Dec 10, 2012 at 7:23 PM, Alan Alpert 4163654...@gmail.com wrote: For finer-grained control over QML it would make sense to have an API allowing import restrictions. Two usecases come to mind, platform security contexts and scriptable applications. Platform security contexts is about when a platform using QML for the applications wants to have restricted capabilities, like android does, so that packaged applications can be restricted to just the capabilities the package says it needs. The scriptable applications usecase is for if you want to make your application scriptable with QML - you probably only want the scripts to use your application provided functionality and not create popup windows (this is why Window gets it own QtQuick.Window import). Okay, forget about the platform security context usecase. That's much more complicated than we seem to need right now, and I'm fine with leaving that to the platforms. Let's just consider the other usecase for now. For the scriptable application usecase, like Jan has and like Plasma has, is the suggested API helpful? Does the proposed restriction model work, or is there an easier way? -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML Runtime
On Tue, Dec 11, 2012 at 11:33 PM, Sorvig Morten morten.sor...@digia.com wrote:
On Dec 11, 2012, at 8:30 PM, Alan Alpert 4163654...@gmail.com wrote:
On Tue, Dec 11, 2012 at 3:33 AM, Sorvig Morten morten.sor...@digia.com
wrote:
Please bundle the QML runtime in a class that the app author can
instantiate.
This gives us the flexibility to handle platform differences and integrate
with existing workflows. There can still be a qmlscene-like binary that
would simply instantiate the class.
Already done. It's called QQmlEngine.
Seriously, the direction this discussion has gone makes me think that
the 'qml runtime' binary will be basically a vanilla QQmlEngine that
can load a component from a file (or from text input or whatever) with
some command line chrome around it. If you want to load the runtime
within your own C++ application it works *exactly* the same as before.
I think the mindset is important: everything needed as a part of the qml
runtime goes into QQmlEngine. This would include QtQuick2ApplicationViewer
which is currently generated by Qt Creator when creating a new project.
It wouldn't include QtQuick2ApplicationViewer, but that's more because
I don't think QtQuick2ApplicationViewer needs to exist. Looking at it
right now, what it provides is
A) A QQuickView (you could have just used a normal QQuickView, or
started the file with Window {} and used a QQmlEngine)
B) An adjustPath function which is used for finding the main QML file.
I don't know why this is needed, especially given that it does nothing
on most platforms.
C) A different choice for the resizeMode (one that is arguably
incorrect for desktop)
D) Connecting Qt.quit() to qApp-quit()
D is actually the interesting one here because it's a feature you want
when your app is written in QML, but not a feature that you want when
your application uses QML just for certain parts. That level of
application control can't be in the QQmlEngine, because then you can't
use the engine to just load QML as a scripting language. There was the
example in the import security thread of using QML for config files,
for that usecase you don't want a config file to say Qt.quit() and
terminate your app.
So maybe there's a need for a slight split between the 'generic QML
runtime' and the 'application QML runtime'. The qml binary would run
the latter, and most QML using C++ applications would use the former.
I don't know which one the creator template would want to use, but
maybe there's a case for adding a small QQmlApplicationEngine in QtQml
which adds the application runtime aspects? Then a QML only
application which needs a C++ wrapper for some reason (like they all
do now) would just be
QGuiApplication app (argc, argv);
QQmlApplicationEngine(main.qml);
return app.exec();
Would this allow us to get rid of the concept of the QtCreator
templates throwing in their own general utility classes?
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Convenience Imports in QML
On Wed, Dec 12, 2012 at 10:33:06AM +1000, Lincoln Ramsay wrote: On 12/12/12 07:28, André Pönitz wrote: What about something like import QtQml from Qt 5.0 import QtQuick from Qt 5.0 +1 Thanks ;-) All the benefits of a group of QML modules attached to a single Qt release without the performance problem of pulling them all in. Then Qt 5.0 is just some meta-thing (possibly just a qmldir file) that lists the modules/versions it contains. I actually think it's still to specfic. Upgrading from Qt 5.0 to 5.1 would need touching all source files. So import QtQml from TheQtIUse import QtQuick from TheQtIUse and some one-liner somewhere that relates TheQtIUse with Qt 5.0, perhaps even through the build system should be even better. Ande' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Convenience Imports in QML
On 12 December 2012 18:57, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: I actually think it's still to specfic. Upgrading from Qt 5.0 to 5.1 would need touching all source files. So import QtQml from TheQtIUse import QtQuick from TheQtIUse and some one-liner somewhere that relates TheQtIUse with Qt 5.0, perhaps even through the build system should be even better. Am I missing something or if we would really like to do that in the future, then we should immediately raise a P0 bug against the Qt 5.0 release and ask for the QML QtWebKit import to be renamed to QtWebKit2? -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QAction-like API for QML
On Wed, Dec 12, 2012 at 12:44 AM, André Somers an...@familiesomers.nl wrote:
Op 11-12-2012 21:59, Alan Alpert schreef:
On Tue, Dec 11, 2012 at 10:49 AM, Shawn Rutledge
shawn.rutle...@digia.com wrote:
On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote:
Why can't this be QML-only? For the set of controls exposed in
C++-only we have a C++-only Action API. When we add a set of controls
exposed in QML-only we can have a QML-only Action API. We don't
Because it seems likely that the business logic of an application would
be written in C++, so why not export the actions that the logic can
support at the same time?
The way I see it, the actions are UI logic, not business logic, and
belong on the QML side of the divide (although they are right on the
edge).
I disagree here. The core of the action - the abstraction of the action
method itself and its availability in the current state - is business
logic IMO. The same goes for any value the action may have: checked, or
perhaps some other value. The action logically bundles state (the
availability of an action) with the action itself.
The decoration around it - the user visible strings, icons and whatnot -
is indeed UI logic. That's why I think that perhaps we conceptually need
something like a CoreAction and a UiAction. The UiAction would
'decorate' a CoreAction with the stuff that is needed to represent it in
a UI. The implementation of the UiAction part would be different for QML
and Widgets, I think.
Actions are a very powerful piece of glue between business and UI logic
if used this way.
Okay, I think this cuts to the heart of the disagreement. QML is
designed for the 'common codebase' scenario Stephen is talking about,
but this requires a very good split between UI logic and business
logic. The actual business logic that's true no matter the
representation can go in C++, and the UI logic which is dependent on
how it's presented (like on Widgets, with QtQuick, touchscreen etc)
has a different implementation per UI but sharing the business code.
The original Action API I proposed was approaching it as a UI logic
element. Let's see what we come up with when we split it into UI and
business elements
CoreAction://Names are for illustrative purposes only
QtObject { //Prototyped in QML, probably a C++ class that QAction
could migrate to using later
property bool checkable: false
property bool checked: false
property bool enabled: true
signal triggered(bool checked)
}
UIAction://Illustrative purposes ONLY!
QtObject {
property string text
property string secondaryText
property url imageSource
property string shortcut
property alias checkable: core.checkable
property alias checked: core.checked
property alias enabled: core.enabled
signal alias triggered: core.triggered //not valid QML, but you get the idea
property CoreAction core: CoreAction{} //implicity gets one but
you could also set one manually
}
CoreAction may not even need a QML API. QML users either implicitly
use one through UIAction, or explicitly use one from C++.
Theoretically a new QAction could be written to use CoreAction
internally too, and then a QAction and a UIAction could share the same
CoreAction instance.
Does this API solve the hybrid problems the previous one was having?
QML-only users ignore the core property and it works exactly like the
Action API we started with, but the CoreAction can be shared between
multiple UIs for the other usecases. For example, you could even do
UIAction { core:
GlobalActionManager.getAction(akonadi_collection_create); } to
interface with your existing ActionManager approach.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Settings API for QML
On Wed, Dec 12, 2012 at 2:13 AM, Mark mark...@gmail.com wrote:
On Wed, Dec 12, 2012 at 10:03 AM, Simon Hausmann
simon.hausm...@digia.com wrote:
On Tuesday, December 11, 2012 04:40:50 PM Bache-Wiig Jens wrote:
...
I think a dedicated syntax has two distinct advantages over a
Qt.storedProperty alike approach:
(1) In a distinct syntax we can avoid loosing the type information and
instead preserve and propagate it into the settings backend. Preserving as
much type information as possible is going to be crucial for performance
optimizations in the future.
(2) A syntax would allow for sensible group and avoiding repetitive
patterns in the settings names. In your example writing application.width
and application.height is not bad, application is repeated only twice.
But
if you think of a real world use-case, then you have application repeated
many many times, which is prone to errors (application vs. accidentally
typing applcation) and it's not very readable. Therefore I think a more
explicit syntax is more suitable:
PersistentSettings {
id: mysettings
group: org.qt.examples.myapp.geometry
property int width: 800
property int height: 600
}
Rectangle {
width: mysettings.width
height: mysettings.height
}
How about:
This one would be singleton.
PersistentSettings {
id: settings
// All properties defined in here are the global properties
property int width: 800
property int height: 600
// Perhaps enforce that a GroupSettings item can only be
constructed within the PersistentSettings item in an attempt to
enforce settings to be located in one QML file. Don't know if that's
wise or not. Just brainstorming.
GroupSettings {
id: myGroup
property int width: 800
property int height: 600
}
}
Then to use it:
Item {
width: settings.width
}
To use the group settings:
Item {
width: settings.myGroup.width
}
Just some brainstorming. I do like this syntax! It looks very easy and
understandable to use.
Some of that syntax would just fall out of Simon's proposed item. The
singleton part at least, if we add QML singletons you can take a
standard PersistentSettings and make it a global singleton yourself
(so you could access it via Settings.width anywhere in your
application. I think that would be a much better way of accomplishing
that, rather than in the element.
As for the grouping, it could also be accomplished just with a default
subgroups property on the PersistentSettings, such than any 'child'
settings objects inherit the group. e.g.
PersistentSettings {
group: org.qt.examples.myapp
PersistentSettings {
id: geo
group: geometry //Automatically becomes
org.qt.examples.myapp.geometry because it's a child of the other item
}
property PersistentSettings geometry: geo //This line is how you'd
get the Settings.myGroup.width style syntax yourself
}
So for the most part, you could theoretically get that syntax from
Simon's proposed item without having to add additional constraints on
the item everywhere. Just how you use it in your application.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Convenience Imports in QML
On Wed, Dec 12, 2012 at 11:18 AM, Giuseppe D'Angelo dange...@gmail.com wrote: On 12 December 2012 18:57, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: I actually think it's still to specfic. Upgrading from Qt 5.0 to 5.1 would need touching all source files. So import QtQml from TheQtIUse import QtQuick from TheQtIUse and some one-liner somewhere that relates TheQtIUse with Qt 5.0, perhaps even through the build system should be even better. Am I missing something or if we would really like to do that in the future, then we should immediately raise a P0 bug against the Qt 5.0 release and ask for the QML QtWebKit import to be renamed to QtWebKit2? I think you're missing something because I cannot imagine a case where the QtWebKit import would actually *need* to change its name. But I'm missing the train of thought that gets you there from where the discussion was at ;) . -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qml mime types
On Wed, Dec 12, 2012 at 2:59 AM, Mohamed Fawzi fawzi.moha...@digia.com wrote: ... I propose the following hierarchy: text/plain; charset=utf-8 text/vnd.qt.qml-base : a file using the qml syntax in some context text/vnd.qt.qml : the current .qml files text/vnd.qt.qbs : a qbs file text/vnd.qt.qml-meta-info : qmltypes meta info text/vnd.qt.qml-project : a qmlproject file later we might want to split text/vnd.qt.qml in several subtypes (and probably own extensions) for example: text/vnd.qt.qml-qtquick1 text/vnd.qt.qml-qtquick2 text/vnd.qt.qml-qq2-partial text/vnd.qt.qml-qq2-full but I think it is better to leave that for another time, we just have to make sure that we can accomodate them in a reasonable way if/when the need arises. Sorry for my fixation on file extensions. The point about generic qml not being the same as the current .qml files remains valid though. So I'd recommend we make text/vnd.qt.qml be a file written in the qml language and let the current .qml files be text/vnd.qt.qml-qtquick1 already (or just text/vnd.qt.qtml-qtquick and split it up later). The current .qml files containing snippets of a QtQuick scene is a legacy convention, and not how the language should be perceived going forwards. (Note that .qml files containing snippets of a QtQuick scene is a usecase that should always be supported, it's just that the language is growing beyond that as the sole usecase for QML.) -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enumerations in QML
Hi,
On Wed, Dec 12, 2012 at 10:51 PM, Charley Bay charleyb...@gmail.com wrote:
Unto all so did sayeth Alan:
What should enumeration declarations in QML look like?
Did respondeth Erik:
And, also important: how much slower is it allowed to be than the current
implementation?
I remembered that there was talk about enums in QML before, so I dug
around a bit, and behold:
The problem with enums is that we couldn't make them fast. They will
always be a lot slower than normal string literals. That is mostly because
we could not avoid the name lookup.
Text {
alignment: Alignment.Vertical | Alignment.something
}
there is no way for you to remove the name lookups for Alignment,
Vertical, and something. Also, there is no way for you to distinguish
Types (e.g. Item, Rectangle, and co...) from Enums (in our case
Alignment). That means, you cannot build the correct list of dependencies
when loading a QML Component.
Ouch. That is quite unexpected.
We seem to have multiple intentions regarding adding Enums to QML:
(1) Those with a native (C/C++) background may have thought Enum to
be faster than String (e.g., performance-goal)
With v4vm, I believe (Lars or Simon can correct me if I'm wrong) every
single time we have a JavaScript expression (well, one which doesn't do
something totally crazy like build a dynamic expression up as a string and
then eval it, but if you're doing that in your code please be aware that
you're the cause of mass kitten suicide) every symbol will be resolved at
compile time where possible (ie, if the evaluation context cannot change).
Thus, once typenames of QML document defined types are resolvable, we
should get great perf from enums.
(2) Some may prefer the cleaner-look by using an unquoted Enum over a
quoted string literal
If the syntax isn't nice, I don't want it in QML ;-) Times like these I
wish we hadn't included grouped properties :-/
(3) Some may expect a compile-time check for (valid) enumerated-values,
as compared with a run-time check with string-lookups (? this may not be
a real consideration depending on how the QML parsing engine works)
As I mentioned earlier, this should be doable in the future. Enums are
looked up from the Q_ENUMS registered with the type with the given type
name, and should be resolvable at compile time (for both binding
expressions and bound signal expressions, and other dynamically added
functions).
(4) Lack of Enums in QML is (another) example of how QML might be
considered a second-class-citizen (mentioned by Chris, another example
being composite types in QML are not backed by a QQmlType and thus are not
available in JavaScript as are types defined in C++)
It is an example of that, but my point was that implementing enums in QML
is meaningless until we have fixed the problem with unresolvable
typenames. This entire thread should be revisited after QTBUG-24799 is
fixed.
Cheers,
Chris.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML Runtime
Hi, maybe there's a case for adding a small QQmlApplicationEngine in QtQml which adds the application runtime aspects? It's early and I haven't had my second coffee yet, so maybe I'm misunderstanding something, but are these application runtime aspects completely non-gui, non-QtQuick related? If they are GUI/QtQuick related, let's not put it anywhere near the engine, or the QtQml module; let's put it in QtQuick instead. Cheers, Chris. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qml mime types
On Wednesday December 12 2012, Mohamed Fawzi wrote:
text/plain; charset=utf-8
text/vnd.qt.qml-base : a file using the qml syntax in some context
text/vnd.qt.qml : the current .qml files
text/vnd.qt.qbs : a qbs file
text/vnd.qt.qml-meta-info : qmltypes meta info
text/vnd.qt.qml-project : a qmlproject file
You can't have a hierarchy like that, btw. Not outside xdg.
No client will treat text/vnd.qt.qml as a text/vnd.qt.qml-base if it doesn't
know the former. You need a database like xdg's for this, but most users of
mime-types will treat an unknown text/ subpart according to the RFCs: as
text/plain.
Which means btw that text/vnd.qt.{qml,etc} will have to specify that clients
SHOULD add a charset parameter and that that charset SHOULD be utf-8, but
that receivers SHOULD accept also charsets != utf-8, and missing charsets
(defaulting to us-ascii in that case). Just because that's a requirement of
text/plain.
I briefly considered suggesting a variant= or dialect= parameter:
text/vnd.qt.qml; charset=utf-8; dialect=qt-quick-v1
mp/signed uses that (protocol=; micalg=, cf. source of Thiago's mail), but it
requires special handling in clients and only really works in email (and
http), not on the desktop, so I'm not suggesting that.
If you want more subtyping than text/plain as a parent, you need to use
something like +qml. You could also use vnd.qt.qml.* (ie. a prefix), but I'm
not sure 3rd parties would like to place their mime types in the vnd.qt
tree :)
There are trees other than vnd., btw, but I forgot which ones. One of them
might lend itself better to this kind of prefixing that vnd.
Thanks,
Marc
--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
