Re: [Development] thoughts about a shared models module, and models in general (was Re: Would a (QML) model aggregator class a welcome addition?)
On Wed, Jan 15, 2014 at 12:43 PM, Alan Alpert <4163654...@gmail.com> wrote:
> On Wed, Jan 15, 2014 at 12:48 AM, Rutledge Shawn
> wrote:
>>
>> On 10 Dec 2013, at 11:43 PM, Alan Alpert wrote:
>>
>>> On Tue, Dec 10, 2013 at 12:32 PM, Alberto Mardegan
>>> wrote:
Hi all!
For one of my projects, I found the need to merge several models into
a single model. I wrote a class for it, and I think it's generic enough
to be useful for other people, and I wonder if it could be put into Qt
itself:
https://gitlab.com/mardy/mappero/blob/directions/lib/Mappero/model-aggregator.h
Note that the thing is not complete (especially the implementation),
it's just in a state where I can use it in my application; it needs a
bit of more work before being ready for the generic use.
I'm wondering if I should make this extra effort or not. :-)
If the answer is yes, should it be added to QtCore or QtDeclarative?
Right now it's using QQmlListProperty so that the source models can be
declared inline,
ModelAggregator {
Model1 { ... }
Model2 { ... }
...
}
but that could be removed and substituted by a simple QList of models if
desired.
>>>
>>> This doesn't sound core enough to really benefit from going into
>>> QtDeclarative (please stop developing for QtQuick 1 :P ; but I know
>>> you meant qtdeclarative the repo) or QtCore (no QML types can go into
>>> QtCore, because QtCore cannot depend on QtQml).
>>>
>>> Maybe we should have an add-on repository like qt-qml-extras which
>>> contains small but useful QML modules. Candidate content being this
>>> model aggregator, Qt.labs.folderlistmodel, (and I have a couple
>>> imports at home that I could clean up and contribute too) maybe even
>>> QtQuick.XmlListModel or Qt.GraphicalEffects? Some of the add-on level
>>> imports, like Qt.GraphicalEffects, are large enough for their own
>>> repo. And some, like QtQuick.XmlListModel, feel "core" enough to go in
>>> qtdeclarative as an essential. But there's scope for a lot of small
>>> but useful QML modules, like ModelAggregator and
>>> Qt.labs.folderlistmodel, where a shared and non-essential repository
>>> would make more sense. The alternative is telling each of these little
>>> modules to get their own github/gitorious/playground repo and then
>>> we'd have to organize them with something like inqlude...
>>>
>>> Anyone else want a qml-extras repository for collecting small QML imports?
>>>
>>> And should it be qt-labs, playground, or qt (add on, not essential!)?
>>
>> I like the idea, but the trouble with models is you typically want to create
>> and populate them from C++, which means you need the collection to be in a
>> library which you can link with. The QML modules that get installed e.g.
>> under qml/QtQml/Models aren't used that way because everything under qml is
>> meant to be instantiated only from QML. But it would be nice if these
>> models could be instantiated both ways. The C++ interface is more urgent
>> IMO, because so far the choices seem to be
>>
>> http://qt-project.org/doc/qt-5.1/qtquick/qtquick-modelviewsdata-cppmodels.html
>>
>> subclass QAbstractItemModel yourself (that requires some overhead, mostly
>> boring code being rewritten each time); use a QStringList (but only for one
>> column and only strings); use a QList of QObjects, which at least is quite
>> flexible (but then each row has all the QObject overhead); or use one of the
>> models that you can only instantiate from QML, and then you will have to
>> write more Javascript to populate it. I started writing
>> https://codereview.qt-project.org/#change,74986 and then realized I can't
>> link with it.
>
> Like several QtQml and QtQuick classes, you can have types in a module
> as well as available in C++. Ideally any C++ public classes relating
> to the QtQuick* imports will be in libQt5Quick.so, and ditto for
> QtQml.* and libQt5Qml.so. We have these two C++ libraries relating to
> QML already.
>
>
>> So this module would have to be installed under lib I suppose? and then
>> just because it's a separate, optional module, there would be an objection
>> to depending on that module in any Qt essential module, such as Qt Quick
>> Controls. I want to use such a model for the shortcuts in the
>> next-generation FileDialog (which will be using QtQuick.Controls, and
>> therefore lives in the same git repository now), and we have another
>> potential use case for font families for the font dialog, so it has to be OK
>> for Controls to depend on it, wherever it goes. The easy solution (and also
>> the one which doesn't encourage reuse) is to put this model in
>> QtQuick.Dialogs.Private because that's where I need it. If someone else
>> wants it, they can always copy the code. It's not much code anyway, hardly
>> worth worrying about. But altogether we could end up with a worthwhile
>> collection of mode
Re: [Development] thoughts about a shared models module, and models in general (was Re: Would a (QML) model aggregator class a welcome addition?)
On Wed, Jan 15, 2014 at 12:48 AM, Rutledge Shawn
wrote:
>
> On 10 Dec 2013, at 11:43 PM, Alan Alpert wrote:
>
>> On Tue, Dec 10, 2013 at 12:32 PM, Alberto Mardegan
>> wrote:
>>> Hi all!
>>> For one of my projects, I found the need to merge several models into
>>> a single model. I wrote a class for it, and I think it's generic enough
>>> to be useful for other people, and I wonder if it could be put into Qt
>>> itself:
>>>
>>> https://gitlab.com/mardy/mappero/blob/directions/lib/Mappero/model-aggregator.h
>>>
>>> Note that the thing is not complete (especially the implementation),
>>> it's just in a state where I can use it in my application; it needs a
>>> bit of more work before being ready for the generic use.
>>> I'm wondering if I should make this extra effort or not. :-)
>>>
>>> If the answer is yes, should it be added to QtCore or QtDeclarative?
>>> Right now it's using QQmlListProperty so that the source models can be
>>> declared inline,
>>>
>>> ModelAggregator {
>>>Model1 { ... }
>>>Model2 { ... }
>>>...
>>> }
>>>
>>> but that could be removed and substituted by a simple QList of models if
>>> desired.
>>>
>>
>> This doesn't sound core enough to really benefit from going into
>> QtDeclarative (please stop developing for QtQuick 1 :P ; but I know
>> you meant qtdeclarative the repo) or QtCore (no QML types can go into
>> QtCore, because QtCore cannot depend on QtQml).
>>
>> Maybe we should have an add-on repository like qt-qml-extras which
>> contains small but useful QML modules. Candidate content being this
>> model aggregator, Qt.labs.folderlistmodel, (and I have a couple
>> imports at home that I could clean up and contribute too) maybe even
>> QtQuick.XmlListModel or Qt.GraphicalEffects? Some of the add-on level
>> imports, like Qt.GraphicalEffects, are large enough for their own
>> repo. And some, like QtQuick.XmlListModel, feel "core" enough to go in
>> qtdeclarative as an essential. But there's scope for a lot of small
>> but useful QML modules, like ModelAggregator and
>> Qt.labs.folderlistmodel, where a shared and non-essential repository
>> would make more sense. The alternative is telling each of these little
>> modules to get their own github/gitorious/playground repo and then
>> we'd have to organize them with something like inqlude...
>>
>> Anyone else want a qml-extras repository for collecting small QML imports?
>>
>> And should it be qt-labs, playground, or qt (add on, not essential!)?
>
> I like the idea, but the trouble with models is you typically want to create
> and populate them from C++, which means you need the collection to be in a
> library which you can link with. The QML modules that get installed e.g.
> under qml/QtQml/Models aren't used that way because everything under qml is
> meant to be instantiated only from QML. But it would be nice if these models
> could be instantiated both ways. The C++ interface is more urgent IMO,
> because so far the choices seem to be
>
> http://qt-project.org/doc/qt-5.1/qtquick/qtquick-modelviewsdata-cppmodels.html
>
> subclass QAbstractItemModel yourself (that requires some overhead, mostly
> boring code being rewritten each time); use a QStringList (but only for one
> column and only strings); use a QList of QObjects, which at least is quite
> flexible (but then each row has all the QObject overhead); or use one of the
> models that you can only instantiate from QML, and then you will have to
> write more Javascript to populate it. I started writing
> https://codereview.qt-project.org/#change,74986 and then realized I can't
> link with it.
Like several QtQml and QtQuick classes, you can have types in a module
as well as available in C++. Ideally any C++ public classes relating
to the QtQuick* imports will be in libQt5Quick.so, and ditto for
QtQml.* and libQt5Qml.so. We have these two C++ libraries relating to
QML already.
> So this module would have to be installed under lib I suppose? and then just
> because it's a separate, optional module, there would be an objection to
> depending on that module in any Qt essential module, such as Qt Quick
> Controls. I want to use such a model for the shortcuts in the
> next-generation FileDialog (which will be using QtQuick.Controls, and
> therefore lives in the same git repository now), and we have another
> potential use case for font families for the font dialog, so it has to be OK
> for Controls to depend on it, wherever it goes. The easy solution (and also
> the one which doesn't encourage reuse) is to put this model in
> QtQuick.Dialogs.Private because that's where I need it. If someone else
> wants it, they can always copy the code. It's not much code anyway, hardly
> worth worrying about. But altogether we could end up with a worthwhile
> collection of models if various people have various ideas.
>
> Maybe it should rather be a static library to have one less runtime
> dependency? Another advantage would be that a typical applicat
[Development] QPalette::Mid neglected?
Hello everyone, I noticed that one program that I run displays a lot of black squares when it shouldn't - I traced the problem down to the fact that, at least on this env - KDE4 + Qt5 dev branch HEAD - QPalette::mid() returns QBrush(QColor(ARGB 1, 0, 0, 0) , SolidPattern ), or black. It seems that nowhere in the Qt source code the value of QPalette::Mid is being set, apart from QWindowsTheme. In my case, the relevant class is QKdeTheme, which does set a value for QPalette::Mid but only for the QPalette::Disabled ColorGroup. Therefore, for the Active color group the value is defaulting to black. Is this intended behavior or should this be fixed? For more context, see QKdeThemePrivate::readKdeSystemPalette() inside qgenericunixthemes.cpp. Thanks for reading, 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] Reducing number of allocations in metacall argument marshalling
On quarta-feira, 15 de janeiro de 2014 13:42:01, Kuba Ober wrote: > The metatype system stores the size of types known to it, so it’s a simple > matter to know how big the all-in-one array needs to be, taking alignment > into consideration, of course. > > I don’t know yet if such a change would be binary compatible, that needs > further checking of course. Initially it looks as if it would be > compatible, since the QMetaCallEvent class is internal only, just as > queued_activate is etc. > > I would like to know if such a change would be considered useful. The > potential for underlying allocator global lock contention is much smaller, > besides not paying the uncontested lock allocation costs, and simply using > a bit less memory for every metacall event. It's probably binary compatible and would be 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
[Development] Consoles
Hello, Qt is already well supported on desktops and mobile is mostly there (WP8 being the only remaining itch), what about consoles? Are there any plans for support XBox One and PlayStation 4? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Reducing number of allocations in metacall argument marshalling
Currently, the metacall arguments are marshaled by copy-constructing them in their own heap blocks. The addresses to the copies are deposited in an array-of-void*, passed as the args argument to QObject::qt_metacall etc. So there are two layers of allocations: 1. An array of void* is heap-allocated. 2. It’s filled with pointers to heap-allocated copies of each argument. The void** args protocol can be preserved, but instead of allocating copies on the heap, they could be in-place-constructed right after the pointers. So args would be an array that has: pointer-to-return-value-instance pointer-to-arg1-instance … pointer-to-argn-instance nullptr return-value-instance arg1-instance … argn-instance If any of the pointers is zero, the instance would not be present in the array (it will not occupy an instance space). The metatype system stores the size of types known to it, so it’s a simple matter to know how big the all-in-one array needs to be, taking alignment into consideration, of course. I don’t know yet if such a change would be binary compatible, that needs further checking of course. Initially it looks as if it would be compatible, since the QMetaCallEvent class is internal only, just as queued_activate is etc. I would like to know if such a change would be considered useful. The potential for underlying allocator global lock contention is much smaller, besides not paying the uncontested lock allocation costs, and simply using a bit less memory for every metacall event. As an extension of this approach, one could provide a factory method in `QMetaCallEvent` that would allocate the proper amount of memory all in one go (to fit the event, the arguments, and possibly the types when it owns the types). Does this make sense? Cheers, Kuba Ober ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On terça-feira, 14 de janeiro de 2014 10:40:58, Rutledge Shawn wrote: > Maybe it's not worth the effort if KDE will be using Qt 5 soon enough > anyway. On KDE, Qt 5 apps use a plain QFileDialog by default. KF5 Technical Preview is out, with file dialog and Oxygen support. -- 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
[Development] FYI: using ccache and icecc with qt
as this is likely of interest for more people ...
--- Begin Message ---
On Wed, Dec 25, 2013 at 09:21:50PM +0100, Kevin Krammer wrote:
> On Wednesday, 2013-12-25, 21:53:10, Muhammad Bashir Al-Noimi wrote:
> > Howdy,
> >
> > How can I use ccache in Qt Creator? Do I need to add something in .pro file?
>
> You define it as the C and C++ compiler.
>
> E.g. by setting the CC and CXX environment variables or creating a
> specialized
> mkspec or by overwriting the QMAKE_CC and QMAKE_CXX variables, etc.
>
a much nicer way is compiling the attached program, installing
gcc/g++/cc/c++/make symlinks in a place where it is found first (i have
/usr/local/bin first in PATH, so that's a good place), exporting
WRAPCCFLAGS (i have WRAPCCFLAGS=cache,ice=40, because i want caching and
have a fairly big icecream farm at hand), and everything just works.
always. unless you run into a buildsystem which does not support
parallelization or does not like ccache or icecream, then you may need
to adjust the flags to disable it.
/*
Copyright (C) 2002 Oswald Buddenhagen
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. Neither the name of the University nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
*/
/*
* Usage:
* - compile with gcc -O2 -o wrapcc wrapcc3.c
* - symlink gcc/g++/cc/c++/make from /usr/local/bin (or anything else that
* is in PATH before the actual compiler toolchain) to this executable
* - set up WRAPCCFLAGS:
* - list of comma-separated flags
* - "jobs=n" - pass -jn to make
* - "ice=n" - use icecc, and pass -jn to make
* - "dist" - use distcc, and pass -jn to make (n determined from DISTCC_HOSTS)
* - "cache" - use ccache. It is possible to specify a list of roots with local
* caches: cache=/root1=/cachedir1:/root2=/cachedir2. If no roots are given,
* the wrapper will look for .ccache/ up the directory hierarchy. If none is
* found, ccache's default (~/.ccache/) will be used.
* - "append=-suffix" - suffix to append to compiler binary. This makes it
* possible to invoke x-compilers without wrapping them explicitly.
*
* Example: export WRAPCCFLAGS=cache,ice=40 # caching and a big icecream farm
*/
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
static void __attribute__((noreturn))
Panic( const char *msg, ... )
{
va_list va;
va_start( va, msg );
vfprintf( stderr, msg, va );
va_end( va );
exit( 1 );
}
static int debug;
static void
Debug( const char *msg, ... )
{
va_list va;
if (debug) {
va_start( va, msg );
vfprintf( stderr, msg, va );
va_end( va );
}
}
char *
findpath( const char *path, const char *name0 )
{
const char *pathe;
char *name, *thenam;
int len;
char nambuf[PATH_MAX+1], resolved[PATH_MAX+1];
static char myself[PATH_MAX+1], directory[PATH_MAX+1];
if (!directory[0] && !getcwd( directory, sizeof(directory) ))
Panic( "getcwd failed.\n" );
if (!myself[0]) {
if ((unsigned)(len = readlink( "/proc/self/exe", myself, sizeof(myself) )) > PATH_MAX)
Panic( "readlen /proc/self/exe failed.\n" );
myself[len] = 0;
Debug( "i am %s\n", myself );
}
len = strlen( name0 );
name = nambuf + PATH_MAX - len;
memcpy( name, name0, len + 1 );
*--name = '/';
do {
if (!(pathe = strchr( path, ':' )))
pathe = path + strlen( path );
len = pathe - path;
if (!len || (len == 1 && *path == '.')) {
len = strlen( directory );
path = directory;
}
thenam = name - len;
if (thenam >= nambuf) {
memcpy( thenam, path, len );
if (!realpath( thenam, resolved ))
Debug( "%s cannot be resolved\n", thenam );
else if (access( thenam, X_OK ))
Debug( "%s is not executable\n", thenam );
else if (!strcmp(
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
Here are the QDrive APIs that Tony mentioned below: https://codereview.qt-project.org/#change,75336,patchset=1 Regards, Alvin From: Иван Комиссаров [abba...@gmail.com] Sent: Friday, January 10, 2014 3:49 PM To: Tony Van Eerd Cc: Константин Ритт; Matt Broadstone; David Faure; Alvin Yulo; ; Rutledge Shawn; Alan Alpert Subject: Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground) I also had a drive monitor class https://gitorious.org/qdrive/qdrive/source/bf9f993ec64781534169a7ac630632805ef34374:src/driveinfo/qdrivecontroller.h but it needs a bit polishing Иван Комиссаров 11 янв. 2014 г., в 0:28, Tony Van Eerd mailto:tvane...@blackberry.com>> написал(а): We will put up our stuff into a review next week. Currently it is mostly header/API only, no implementation files. We are just trying to get the API designed. We looked at QDriveInfo (either that one or similar one of the same name) and, basically, "stole" many ideas from it. Ours was also called QDriveInfo until we decided to add non-info stuff like mounting. But maybe it should be kept separate. We should definitely bring all the work together into a consistent API. - 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] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On 13 Jan 2014, at 8:06 PM, David Faure wrote: > On Monday 13 January 2014 22:00:53 abba...@gmail.com wrote: But I think maybe we should get the C++ APIs into qtbase, so that QtQuick.Controls.FileDialog doesn't depend on qtsystems. > > Let me rewind a bit here... I thought QtCore would have query stuff, not > mount > functionality - which most apps don't need. > > Is this because you want to offer mounting devices in QFileDialog? > But in practice QFileDialog is reimplemented on almost all platforms via the > QPA, or should be, right? So that seems a bit pointless. If a volume shows up in the list, the FileDialog should be able to examine its contents. On Windows, the removable-media drives appear even if there is not a disk in the drive. But the mounting/unmounting is a loose concept anyway right? On OSX and Linux, the removable-media drives do not appear if there is no disk, so maybe we can do without mounting on-demand from the file dialog; although it would be an improvement if one could e.g. plug in a USB thumbdrive and have it appear in the dialog right away, whether or not it was mounted. But I at least need notification from somewhere that a drive has been mounted, so when the user opens the dialog and then mounts the drive from elsewhere in the OS, the dialog can see it. With QDriveInfo and my patch as they are now, you have to restart the Qt application because FileDialog only gets the list of QDriveInfo objects once. But maybe the watcher could use a QFileSystemWatcher on /dev/disk/by-label instead of d-bus? I verified that it's possible to get a directoryChanged() signal when I plug in a thumb drive. (But it doesn't tell what new link appeared.) But volume mounting notification does seem like a good thing to add to QPA as long as it can be done without big dependencies like d-bus. > And QtQuick.Controls.FileDialog might not be currently reimplemented via the > QPA, but then that's a bug - it should be, to provide consistent dialogs to > the user. Yes it has been preferring the QPA dialog since the beginning. So far the QML dialog is just for cases where neither a QPA dialog nor a QFileDialog is possible (e.g. on tablets and embedded devices, in applications which do not link the widget module). The 5.1 DefaultFileDialog.qml is feature-poor, just a fallback to make sure that you will always get something when you set a FileDialog visible. In 5.3 it will be using QtQuick Controls, so it becomes possible to have more features, such as a list of shortcuts for available volumes, favorites which can be stored in the application's settings, a ComboBox for the filters, etc. > So e.g. KDE can provide the same mounting capabilities (via the Solid > framework) in both dialogs. > Hmm, OK, on Windows I suppose embedding the native file dialog into QtQuick > is > not so great? It works fine; it's not really embedding, just using QPA to manage the OS-created dialog. It's the same with GTK on Linux and the OSX file dialog. There is some trouble to use the KDE 4 dialog from Qt 5 though: Qt versions can't be mixed within the same process, so that dialog would have to be in a different process if we were to use it. Maybe it's not worth the effort if KDE will be using Qt 5 soon enough anyway. On KDE, Qt 5 apps use a plain QFileDialog by default. The QML dialog might end up being an improvement over that if we add enough features. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On Monday 13 January 2014 22:00:53 abba...@gmail.com wrote: > >> But I think maybe we should get the C++ APIs into qtbase, so that > >> QtQuick.Controls.FileDialog doesn't depend on qtsystems. Let me rewind a bit here... I thought QtCore would have query stuff, not mount functionality - which most apps don't need. Is this because you want to offer mounting devices in QFileDialog? But in practice QFileDialog is reimplemented on almost all platforms via the QPA, or should be, right? So that seems a bit pointless. And QtQuick.Controls.FileDialog might not be currently reimplemented via the QPA, but then that's a bug - it should be, to provide consistent dialogs to the user. So e.g. KDE can provide the same mounting capabilities (via the Solid framework) in both dialogs. Hmm, OK, on Windows I suppose embedding the native file dialog into QtQuick is not so great? -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] thoughts about a shared models module, and models in general (was Re: Would a (QML) model aggregator class a welcome addition?)
On 15.01.14 09:48, Rutledge Shawn wrote:
> On 10 Dec 2013, at 11:43 PM, Alan Alpert wrote:
>
>> On Tue, Dec 10, 2013 at 12:32 PM, Alberto Mardegan
>> wrote:
>>> Hi all!
>>> For one of my projects, I found the need to merge several models into
>>> a single model. I wrote a class for it, and I think it's generic enough
>>> to be useful for other people, and I wonder if it could be put into Qt
>>> itself:
>>>
>>> https://gitlab.com/mardy/mappero/blob/directions/lib/Mappero/model-aggregator.h
>>>
>>> Note that the thing is not complete (especially the implementation),
>>> it's just in a state where I can use it in my application; it needs a
>>> bit of more work before being ready for the generic use.
>>> I'm wondering if I should make this extra effort or not. :-)
>>>
>>> If the answer is yes, should it be added to QtCore or QtDeclarative?
>>> Right now it's using QQmlListProperty so that the source models can be
>>> declared inline,
>>>
>>> ModelAggregator {
>>> Model1 { ... }
>>> Model2 { ... }
>>> ...
>>> }
>>>
>>> but that could be removed and substituted by a simple QList of models if
>>> desired.
>>>
>> This doesn't sound core enough to really benefit from going into
>> QtDeclarative (please stop developing for QtQuick 1 :P ; but I know
>> you meant qtdeclarative the repo) or QtCore (no QML types can go into
>> QtCore, because QtCore cannot depend on QtQml).
>>
>> Maybe we should have an add-on repository like qt-qml-extras which
>> contains small but useful QML modules. Candidate content being this
>> model aggregator, Qt.labs.folderlistmodel, (and I have a couple
>> imports at home that I could clean up and contribute too) maybe even
>> QtQuick.XmlListModel or Qt.GraphicalEffects? Some of the add-on level
>> imports, like Qt.GraphicalEffects, are large enough for their own
>> repo. And some, like QtQuick.XmlListModel, feel "core" enough to go in
>> qtdeclarative as an essential. But there's scope for a lot of small
>> but useful QML modules, like ModelAggregator and
>> Qt.labs.folderlistmodel, where a shared and non-essential repository
>> would make more sense. The alternative is telling each of these little
>> modules to get their own github/gitorious/playground repo and then
>> we'd have to organize them with something like inqlude...
>>
>> Anyone else want a qml-extras repository for collecting small QML imports?
>>
>> And should it be qt-labs, playground, or qt (add on, not essential!)?
>
I also like the idea. I would also like to see a qml-extra or
qml-contrib repo. Which acts more like a package manager and a
standardized way to fetch/compile/install a package from there. These
packages (e.g. qml plugins) should have a common module prefix (e.g.
com.qtproject.contrib..). Which packages will be
hosted there is up to the individual contributors (or a maintainer) to
decide. These packages should ideally not be depending on each other
only on Qt5.
If a package is good enough the qt-project could have the option to add
it into their core-module (e.g. a promotion) and take ownership of it,
if this is wanted at all.
I'm thinking the way nodejs works with the npm package manager. It's so
easy to search packages and install them as local or global packages
(npm install express). Similar exists for HTML packages
(http://bower.io/ or even a more extended version http://yeoman.io/,
which includes a generators).
Just thinking aloud:-)
/ juergen
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] thoughts about a shared models module, and models in general (was Re: Would a (QML) model aggregator class a welcome addition?)
On 10 Dec 2013, at 11:43 PM, Alan Alpert wrote:
> On Tue, Dec 10, 2013 at 12:32 PM, Alberto Mardegan
> wrote:
>> Hi all!
>> For one of my projects, I found the need to merge several models into
>> a single model. I wrote a class for it, and I think it's generic enough
>> to be useful for other people, and I wonder if it could be put into Qt
>> itself:
>>
>> https://gitlab.com/mardy/mappero/blob/directions/lib/Mappero/model-aggregator.h
>>
>> Note that the thing is not complete (especially the implementation),
>> it's just in a state where I can use it in my application; it needs a
>> bit of more work before being ready for the generic use.
>> I'm wondering if I should make this extra effort or not. :-)
>>
>> If the answer is yes, should it be added to QtCore or QtDeclarative?
>> Right now it's using QQmlListProperty so that the source models can be
>> declared inline,
>>
>> ModelAggregator {
>>Model1 { ... }
>>Model2 { ... }
>>...
>> }
>>
>> but that could be removed and substituted by a simple QList of models if
>> desired.
>>
>
> This doesn't sound core enough to really benefit from going into
> QtDeclarative (please stop developing for QtQuick 1 :P ; but I know
> you meant qtdeclarative the repo) or QtCore (no QML types can go into
> QtCore, because QtCore cannot depend on QtQml).
>
> Maybe we should have an add-on repository like qt-qml-extras which
> contains small but useful QML modules. Candidate content being this
> model aggregator, Qt.labs.folderlistmodel, (and I have a couple
> imports at home that I could clean up and contribute too) maybe even
> QtQuick.XmlListModel or Qt.GraphicalEffects? Some of the add-on level
> imports, like Qt.GraphicalEffects, are large enough for their own
> repo. And some, like QtQuick.XmlListModel, feel "core" enough to go in
> qtdeclarative as an essential. But there's scope for a lot of small
> but useful QML modules, like ModelAggregator and
> Qt.labs.folderlistmodel, where a shared and non-essential repository
> would make more sense. The alternative is telling each of these little
> modules to get their own github/gitorious/playground repo and then
> we'd have to organize them with something like inqlude...
>
> Anyone else want a qml-extras repository for collecting small QML imports?
>
> And should it be qt-labs, playground, or qt (add on, not essential!)?
I like the idea, but the trouble with models is you typically want to create
and populate them from C++, which means you need the collection to be in a
library which you can link with. The QML modules that get installed e.g. under
qml/QtQml/Models aren't used that way because everything under qml is meant to
be instantiated only from QML. But it would be nice if these models could be
instantiated both ways. The C++ interface is more urgent IMO, because so far
the choices seem to be
http://qt-project.org/doc/qt-5.1/qtquick/qtquick-modelviewsdata-cppmodels.html
subclass QAbstractItemModel yourself (that requires some overhead, mostly
boring code being rewritten each time); use a QStringList (but only for one
column and only strings); use a QList of QObjects, which at least is quite
flexible (but then each row has all the QObject overhead); or use one of the
models that you can only instantiate from QML, and then you will have to write
more Javascript to populate it. I started writing
https://codereview.qt-project.org/#change,74986 and then realized I can't link
with it.
So this module would have to be installed under lib I suppose? and then just
because it's a separate, optional module, there would be an objection to
depending on that module in any Qt essential module, such as Qt Quick Controls.
I want to use such a model for the shortcuts in the next-generation FileDialog
(which will be using QtQuick.Controls, and therefore lives in the same git
repository now), and we have another potential use case for font families for
the font dialog, so it has to be OK for Controls to depend on it, wherever it
goes. The easy solution (and also the one which doesn't encourage reuse) is to
put this model in QtQuick.Dialogs.Private because that's where I need it. If
someone else wants it, they can always copy the code. It's not much code
anyway, hardly worth worrying about. But altogether we could end up with a
worthwhile collection of models if various people have various ideas.
Maybe it should rather be a static library to have one less runtime dependency?
Another advantage would be that a typical application might only need one of
the models from the lib, so the memory cost would be lower if the linker was
free to leave out the ones that you didn't use. But then if QtQuick.Dialogs is
already going to use it once, that means if your app uses it too, you've
already got 2 copies. Then if you run several Qt apps at the same time, the
copied model code is taking up more memory than if you had linked with a
modestly-sized dynamic library, even if each
