I think you are right and it should be moved to QtCore because this models
doesn't have any relations to GUI itself.
Best regards, Dmitriy.
2011/11/22 Stephen Kelly
> On Tuesday, November 22, 2011 18:23:44 you wrote:
> > On Tuesday November 22 2011, Stephen Ke
On Tue, 22 Nov 2011 22:55:39 ext Sandro Andrade wrote:
> Just to make it clearer:
>
> From docs:
> "You may want to mix QML and C++ for a number of reasons. For example:
> ...
> To write your own QML elements (whether for your applications, or for
> distribution to others)"
>
> iirc, we have two
Holger Hans Peter Freyther said:
> On 11/03/2011 07:06 PM, lars.kn...@nokia.com wrote:
>
> > Yes, I agree that it'd be nice to avoid the recompile in that case.
> > However, this is the best way to be really certain your module works
> > against whatever it depends upon. It's not a huge issue on a
On 11/22/2011 06:49 PM, Holger Hans Peter Freyther wrote:
> Hi all,
>
> I want to run QtDeclarative on MIPS and I will need to apply the QML changes
> for this backend. I wonder about the pro/cons of having implementation and
> tests separated in two different repositories.
Hi Aaron,
I think the
On 22/11/2011, at 9:55 PM, Thiago Macieira wrote:
> On Tuesday, 22 de November de 2011 09.58.02, lars.kn...@nokia.com wrote:
>> A IMO better solution would be to have a repository called e.g. qtsupport
>> (KDE had something similar for quite a while) that contains copies to
>> these 3rd party lib
Hi, the Qt Project has now a collaboration channel focusing on
marketing, events and misc community activities not directly related
with software development:
- qt-project.org content.
- Marketing activities.
- Organization and involvement in events.
- ...
Your participation i
> I can email you more details if needed.
>
More food for thought
http://harmattan-dev.nokia.com/docs/library/html/qmsystem2/classMeeGo_1_1QmHeartbeat.html
Although not very QTimer like, which is why it was decided to not follow this
timer too closely for QtMobility
Lorn Potter
Senior So
On Tuesday, November 22, 2011 18:23:44 you wrote:
> On Tuesday November 22 2011, Stephen Kelly wrote:
> [...]
>
> > It is useful to move them to QtCore.
>
> [...]
>
> I never understood why QAIM is in QtCore and QAPM and the rest of the bunch
> isn't.
>
> +1
My understanding is that the initia
Hi all,
I want to run QtDeclarative on MIPS and I will need to apply the QML changes
for this backend. I wonder about the pro/cons of having implementation and
tests separated in two different repositories.
Pro: The tests can be run with the normal Qt autotests, no other buildsystem
needed (Gyp/S
On Tuesday November 22 2011, Stephen Kelly wrote:
[...]
> It is useful to move them to QtCore.
[...]
I never understood why QAIM is in QtCore and QAPM and the rest of the bunch
isn't.
+1
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com
2011/11/22 Stephen Kelly :
> A replacement API capable of being used for trees would end up just as
> 'hard' as QAIM is if it is to support relevant usecases. The biggest cause
> of the QAIM stuff being hard is the lack of beyond-entry-level documentation
> on how to use it.
I'd disagree that it's
On 11/03/2011 07:06 PM, lars.kn...@nokia.com wrote:
> Yes, I agree that it'd be nice to avoid the recompile in that case.
> However, this is the best way to be really certain your module works
> against whatever it depends upon. It's not a huge issue on a decent
> machine, at least if the dependen
Hi there,
I propose to move the following files into QtCore (along with their
implementations, omitted for brevity):
* itemviews/qabstractproxymodel.h
* itemviews/qidentityproxymodel.h
* itemviews/qsortfilterproxymodel.h
* itemviews/qitemselectionmodel.h
There are other possible candidates to
On 22 November 2011 01:11, wrote:
> I would suggest that the Qt source should include its own local copy of pcre
> and a configure time switch should allow selection between the system or the
> local (Qt source) version of pcre. This is already the approach offered for
> things like image-rela
On 21 November 2011 21:25, wrote:
>>I don't know. We should choose the features we want and then require
>>that.
>>Unicode matching sounds interesting.
>
> As does the JIT. Do you have an idea on how much bigger PCRE gets by these
> features?
On 32bit Linux:
textdata bss dec
On 11/22/11 2:23 PM, "ext Richard Moore" wrote:
>On Tue, Nov 22, 2011 at 11:15 AM, Peter Hartmann
> wrote:
>> Within 15 working days, we have received mails from 10 people who second
>> this nomination, and we have not received an objection.
>>
>>
>> So Rich Moore is hereby solemnly declared an a
On 11/21/2011 03:38 PM, Knoll Lars (Nokia-MP-Qt/Oslo) wrote:
> On 11/21/11 12:42 PM, "Samuel Rødal" wrote:
>
>> On 11/21/2011 11:50 AM, Knoll Lars (Nokia-MP-Qt/Oslo) wrote:
>>> On 11/21/11 10:49 AM, "ext Samuel Rødal" wrote:
>>>
On 11/21/2011 08:48 AM, ext Alan Alpert wrote:
> The threa
On Tue, Nov 22, 2011 at 11:15 AM, Peter Hartmann
wrote:
> Within 15 working days, we have received mails from 10 people who second
> this nomination, and we have not received an objection.
>
>
> So Rich Moore is hereby solemnly declared an approver for the Qt project.
> Congratulations!
Thanks Gu
Just to make it clearer:
>From docs:
"You may want to mix QML and C++ for a number of reasons. For example:
...
To write your own QML elements (whether for your applications, or for
distribution to others)"
iirc, we have two approaches for creating new QML elements: as QML
documents and as QObjec
Within 15 working days, we have received mails from 10 people who second
this nomination, and we have not received an objection.
So Rich Moore is hereby solemnly declared an approver for the Qt project.
Congratulations!
Peter
On 11/01/2011 04:00 PM, ext Peter Hartmann wrote:
> Hello,
>
> he
On Tuesday, 22 de November de 2011 08.53.47, Olivier Goffart wrote:
> I can't recall an example of non-shared copyable class with a private
> implementation in Qt, so that mean they are rares.
If it's copyable, it usually *can* be shared. Non-sharability would exist in
the case where there are con
On Tuesday, 22 de November de 2011 10.05.49, lars.kn...@nokia.com wrote:
> Agree, but it shouldn't be difficult to do a generic backend based on the
> system clock. So if you want to wakeup every 5 minutes, we'll always do
> that at a defined clock time for all apps. We could simply say when the
>
On Tuesday, 22 de November de 2011 09.58.02, lars.kn...@nokia.com wrote:
> A IMO better solution would be to have a repository called e.g. qtsupport
> (KDE had something similar for quite a while) that contains copies to
> these 3rd party libraries for convenience.
I'd prefer that too.
And to kee
On 11/22/11 10:53 AM, "ext jens.bache-w...@nokia.com"
wrote:
>>
>> Yes, I mean if QtQuick2 is designed to reduce memory footprint for
>> non-ui applications it makes sense to keep UI components in a separate
>> module. I'm just arguing that if the Window module will just contain
>> the Window co
On 11/21/11 11:39 PM, "ext lorn.pot...@nokia.com"
wrote:
>
>On 21/11/2011, at 9:51 PM, ext shane.kea...@accenture.com wrote:
>
>> It should be used to extend the QTimer API.
>> Where the system doesn't support this kind of timer, then the in
>>process solution as in Thiago's blog should be used.
On 11/22/11 2:11 AM, "ext craig.sc...@csiro.au"
wrote:
>
>On 22/11/2011, at 2:45 AM, Giuseppe D'Angelo wrote:
>
>> On 16 November 2011 16:08, wrote:
>>> Yes, the implementation based on UTF-8 vs UTF-16 version of PCRE would
>>> only differ on two lines, the UTF-16 -> UTF-8 and UTF-8 > UTF-16
>>
>
> Yes, I mean if QtQuick2 is designed to reduce memory footprint for
> non-ui applications it makes sense to keep UI components in a separate
> module. I'm just arguing that if the Window module will just contain
> the Window component, it wouldn't worth it to keep this component in a
> separate
On Tuesday 22 November 2011 11:52:44 David Laing wrote:
> Hi all,
>
> I was just reading this:
>http://herbsutter.com/gotw/_100/
> and got to wondering about the pimpl idiom in Qt with respect to
> forwards compatibility with C++11.
>
> Should there be some discussion of the relative merits o
28 matches
Mail list logo
