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 of using
QFooClass* QFooClassPrivate::q_ptr
to refer to public classe
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
>> conversion before and after the matching.
>>
>> I suggest we
2011/11/21 Alan Alpert :
> On Tue, 22 Nov 2011 09:10:14 ext Adriano Rezende 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
On Tue, 22 Nov 2011 09:10:14 ext Adriano Rezende wrote:
> 2011/11/21 Alan Alpert :
> > On Tue, 22 Nov 2011 00:50:28 you wrote:
> >> 2011/11/21 Alan Alpert :
> >> > On Mon, 21 Nov 2011 17:26:44 ext Alan Alpert wrote:
> >> >> On Tue, 15 Nov 2011 19:24:50 ext Alan Alpert wrote:
> >> >> > Window{ //Not
IOW, something like:
import QtQuick 2.0 // or QtQuick.UI 2.0 (if it makes sense)
Window {
}
- Adriano
2011/11/21 Adriano Rezende :
> 2011/11/21 Alan Alpert :
>> On Tue, 22 Nov 2011 00:50:28 you wrote:
>>> 2011/11/21 Alan Alpert :
>>> > On Mon, 21 Nov 2011 17:26:44 ext Alan Alpert wrote:
>>> >>
2011/11/21 Alan Alpert :
> On Tue, 22 Nov 2011 00:50:28 you wrote:
>> 2011/11/21 Alan Alpert :
>> > On Mon, 21 Nov 2011 17:26:44 ext Alan Alpert wrote:
>> >> On Tue, 15 Nov 2011 19:24:50 ext Alan Alpert wrote:
>> >> > Window{ //Not inheriting QQuickItem, creates a new top level window.
>> >> >
>> >
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.
>
> Should there be a preferred interval?
> For some use cases
On Mon, 21 Nov 2011 23:29:00 ext Artur Souza (MoRpHeUz) wrote:
> On Mon, Nov 21, 2011 at 9:49 AM, wrote:
> > Flickable is not public C++ API, only public QML API.
>
> Are we willing to change this for Qt 5.0 (work on QML's C++ APIs to
> make them public) ?
There are no such plans. The current t
On Tue, 22 Nov 2011 00:50:28 you wrote:
> 2011/11/21 Alan Alpert :
> > On Mon, 21 Nov 2011 17:26:44 ext Alan Alpert wrote:
> >> On Tue, 15 Nov 2011 19:24:50 ext Alan Alpert wrote:
> >> > Window{ //Not inheriting QQuickItem, creates a new top level window.
> >> >
> >> > property int x
> >> >
On Mon, 21 Nov 2011 23:49:27 you wrote:
> Mandag 21. november 2011 17.31.30 skrev ext Alan Alpert:
> > On Mon, 21 Nov 2011 17:26:44 ext Alan Alpert wrote:
> > > On Tue, 15 Nov 2011 19:24:50 ext Alan Alpert wrote:
> > > > If we mostly agree, then that's a good starting point. I'll start
> > > > prot
On 11/21/11 6:29 PM, "ext Thiago Macieira" wrote:
>On Monday, 21 de November de 2011 15.45.49, Giuseppe D'Angelo wrote:
>> But first: do we all (esp. Thiago, Lars) agree to use the UTF-8
>> version for now (and pay for the pattern/subject string/offsets
>> conversions) and then write and enable a
On Monday, 21 de November de 2011 15.45.49, Giuseppe D'Angelo wrote:
> But first: do we all (esp. Thiago, Lars) agree to use the UTF-8
> version for now (and pay for the pattern/subject string/offsets
> conversions) and then write and enable a UTF-16 codepath when PCRE
> ships with proper support f
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
> conversion before and after the matching.
>
> I suggest we get started on this with the current version of PCRE, and
> ho
On Friday, November 11, 2011 13:01:55 Zoltán Herczeg wrote:
> Hi Qt Devs,
>
> I am Zoltan Herczeg, a PCRE and a QtWebKit developer. Stephen Kelly told me
> that Qt would like to replace the QRegExp engine with another regex engine
> (http://thread.gmane.org/gmane.comp.lib.qt.qt5-feedback/1524/), an
2011/11/21 Alan Alpert :
> On Mon, 21 Nov 2011 17:26:44 ext Alan Alpert wrote:
>> On Tue, 15 Nov 2011 19:24:50 ext Alan Alpert wrote:
>> > Window{ //Not inheriting QQuickItem, creates a new top level window.
>> >
>> > property int x
>> > property int y
>> > property int width
>> > p
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 thread about Window{} has progressed, and I still prefer that
attached
Mandag 21. november 2011 17.31.30 skrev ext Alan Alpert:
> On Mon, 21 Nov 2011 17:26:44 ext Alan Alpert wrote:
> > On Tue, 15 Nov 2011 19:24:50 ext Alan Alpert wrote:
> > > If we mostly agree, then that's a good starting point. I'll start
> > > prototyping a Window{} with the following minimal API
On Mon, Nov 21, 2011 at 9:49 AM, wrote:
> Flickable is not public C++ API, only public QML API.
Are we willing to change this for Qt 5.0 (work on QML's C++ APIs to
make them public) ?
Cheers,
--
---
Artur Duque de Souza
openBossa
INdT - Inst
No - classes only exported with Q_AUTOTEST_EXPORT are not meant to be used this
way. They are only exported at all in developer build so that autotests can use
them. Deployed versions of Qt will not have these symbols exported.
Flickable is not public C++ API, only public QML API. To create a fl
Nice, but even if I build qt with -developer-build is it a correct and
reasonable way to create my flickable extended qml component ?
--
Sandro
On Mon, Nov 21, 2011 at 10:04 AM, wrote:
> class Q_AUTOTEST_EXPORT QDeclarativeFlickable
>
> The Q_AUTOTEST_EXPORT means the symbols are only available
On Monday, 21 de November de 2011 10.52.39, lars.kn...@nokia.com wrote:
> Thiago's work was IIRC limited to aligning timers within one process.
> That's good, but it doesn't yet cover the use case of having several
> processes that you want to wake up together (to reduce wake ups and bundle
> netw
Hi there,
I'm wondering about the actual reason of getting a
"QDeclarativeContext: Cannot set property on internal context.".
I need to dynamically create new QML elements as child of my custom QML element:
QDeclarativeRectangle *rect = new QDeclarativeRectangle(this);
rec
class Q_AUTOTEST_EXPORT QDeclarativeFlickable
The Q_AUTOTEST_EXPORT means the symbols are only available when Qt is
configured as a developer build.
They are exported for the unit tests to use, but not exported in a normal build.
> -Original Message-
> From: development-bounces+shane.kea
Hi there,
I'm trying to extend QML flickable element to provide a new QML view.
Building occurs fine but the generated library
have some missing symbols. Any chance for building and linking against
qt private headers outside qt source folders ?
TIA,
Sandro
linux-gate.so.1 => (0xb78a3000
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.
Should there be a preferred interval?
For some use cases, the timer is allowed to be late but not early (e.g.
supervisory timeouts) in
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 thread about Window{} has progressed, and I still prefer that
>>> attached
>>> property approach compared to a Screen property
On 11/21/11 11:22 AM, "ext Robin Burchell" wrote:
>Hi,
>
>On Mon, Nov 21, 2011 at 11:06 AM, wrote:
>> In short, it's a system-wide fuzzy timer, providing a service for
>>applications to synchronize their activity.
>>
>> Now I'm thinking of move it to QtCore, and preferably merge it into
>>QTime
On 11/21/11 10:49 AM, "ext Samuel Rødal" wrote:
>On 11/21/2011 08:48 AM, ext Alan Alpert wrote:
>> The thread about Window{} has progressed, and I still prefer that
>>attached
>> property approach compared to a Screen property on Window. The attached
>> property allows you to access the propertie
Hi,
On Mon, Nov 21, 2011 at 11:06 AM, wrote:
> In short, it's a system-wide fuzzy timer, providing a service for
> applications to synchronize their activity.
>
> Now I'm thinking of move it to QtCore, and preferably merge it into QTimer.
> If so, we probably need to add some interface to spec
Hi,
In QtMobility SystemInfo, we have a QSystemAlignedTimer:
http://doc.qt.nokia.com/qtmobility-latest/qsystemalignedtimer.html
In short, it's a system-wide fuzzy timer, providing a service for applications
to synchronize their activity.
Now I'm thinking of move it to QtCore, and preferably mer
On 11/21/2011 08:48 AM, ext Alan Alpert wrote:
> The thread about Window{} has progressed, and I still prefer that attached
> property approach compared to a Screen property on Window. The attached
> property allows you to access the properties of your current screen from any
> graphical object eas
31 matches
Mail list logo
