On 13/10/15 22:46, "Matthew Woehlke" wrote:
>On 2015-10-13 15:59, Jake Petroules wrote:
>> On Oct 13, 2015, at 1:46 PM, Marc Mutz wrote:
>>> I would therefore like to propose to abandon QString for new API (and
>>>over
>>> time phase it out of existing API), and only provide (const QChar*,
>>>si
I’m not a huge fan of having different overloads with QString, QStringRef
and QLatin1String and in some cases (QChar *, int) for many methods
neither. But while your proposal solves some problems it introduces others.
A QStringView class would only work for methods that read the data
contained in
On Tuesday 13 October 2015 22:46:36 Marc Mutz wrote:
> Q: What mistakes do you refer to?
>
> A: The fact that it has copy ctor and assignment operator, so it's not a
> trivally-copyable type and thus cannot efficiently passed by-value. It may
> also be too large for pass-by-value due to the rather
On 2015-10-13 15:59, Jake Petroules wrote:
> On Oct 13, 2015, at 1:46 PM, Marc Mutz wrote:
>> I would therefore like to propose to abandon QString for new API (and over
>> time phase it out of existing API), and only provide (const QChar*, size_t)
>> as
>> the most general form. I would propose
I like idea to devide the job of manipulating data and sending data around in
different classes. Many times I get string from different sources in different
formats with different ownerships. And for performance reasons you don't want
copy or convert that strings. Many sources like databases pro
Oswald Buddenhagen wrote:
> src/corelib/corelib.pro:
>
> ...
> MODULE_CONFIG += qtcore_insanity
I must have done something wrong, because this addition gave me a QtCore with
the additional module included. It's not supposed to be added to Qt libraries.
> user_project.pro:
>
> ...
> CONFIG +=
> On Oct 13, 2015, at 1:46 PM, Marc Mutz wrote:
>
> Hi,
>
> After looking quite a bit into the current state of string handling in Qt for
> my QtWS talk last week, I have become frustrated by the state of string
> handling in Qt.
>
> We have such powerful tools for string handling (QStringRe
Hi,
After looking quite a bit into the current state of string handling in Qt for
my QtWS talk last week, I have become frustrated by the state of string
handling in Qt.
We have such powerful tools for string handling (QStringRef, QStringBuilder),
but all APIs outside QString and its immediate
On Tue, Oct 13, 2015 at 8:44 PM, Thiago Macieira
wrote:
> On Tuesday 13 October 2015 18:01:31 Dominik Holland wrote:
>> Am 13.10.15 um 16:15 schrieb Thiago Macieira:
>> > On Tuesday 13 October 2015 07:35:14 Viironen Kalle wrote:
>> >> * qt/qtapplicationmanager, Qt component for application lifec
On Tuesday 13 October 2015 18:01:31 Dominik Holland wrote:
> Am 13.10.15 um 16:15 schrieb Thiago Macieira:
> > On Tuesday 13 October 2015 07:35:14 Viironen Kalle wrote:
> >> * qt/qtapplicationmanager, Qt component for application lifecycle
> >
> > management
> >
> >> * qt/qtivi, Qt IVI exte
Am 13.10.15 um 16:15 schrieb Thiago Macieira:
> On Tuesday 13 October 2015 07:35:14 Viironen Kalle wrote:
>> * qt/qtapplicationmanager, Qt component for application lifecycle
> management
>> * qt/qtivi, Qt IVI extensible platform abstraction layer
>
> I'd like more information on what's o
Am 13.10.15 um 16:09 schrieb Thiago Macieira:
> On Tuesday 13 October 2015 09:52:54 Knoll Lars wrote:
>> The only one I could see that could make sense in an existing repo is the
>> dbus qml integration, but then again, this one can’t live in qtbase where
>> the rest of the dbus code lives. So it’
On Tuesday 13 October 2015 07:35:14 Viironen Kalle wrote:
> * qt/qtapplicationmanager, Qt component for application lifecycle
management
> * qt/qtivi, Qt IVI extensible platform abstraction layer
I'd like more information on what's on these. What's application lifecycle
management? Is that
On Tuesday 13 October 2015 09:52:54 Knoll Lars wrote:
> The only one I could see that could make sense in an existing repo is the
> dbus qml integration, but then again, this one can’t live in qtbase where
> the rest of the dbus code lives. So it’s either a separate repo, or we add
> it to the qtde
On Tue, Oct 13, 2015 at 02:07:00PM +0200, Dominik Holland wrote:
> qtdbusqml was written some time ago. Although it still works it has a
> lot of rough edges and i think it should go into the playground first.
>
that's still qt/qtdbusqml as far as repos are concerned.
or qt/qtdeclarative//wip/dbu
Sorry, this should have gone to the list at once.
Oswald Buddenhagen wrote:
Thanks,
If anything this led me to the "Adding new configuration features" chapter in
the
QMake documentation. :)
> qtcore_be_insane: DEFINES += QTCORE_BE_INSANE
> SOURCES += $$PWD/data/qtcore_insanity.cpp
>
> src/co
Pocheptsov Timur wrote:
Well, I know that (as in, I've been told it's the case, and I've seen examples
where you cannot do regular, static casts), but that doesn't mean I understand
it (nor does it mean I'm not willing to believe it!!).
Worse, experience with ObjC interferes. There you can cast
qtdbusqml was written some time ago. Although it still works it has a
lot of rough edges and i think it should go into the playground first.
Dominik
On 10/13/2015 11:52 AM, Knoll Lars wrote:
> I think the new repos are generally ok.
>
> The only one I could see that could make sense in an existi
Op 13-10-2015 om 12:22 schreef Oswald Buddenhagen:
> On Tue, Oct 13, 2015 at 09:52:54AM +, Knoll Lars wrote:
>> The only one I could see that could make sense in an existing repo is the
>> dbus qml integration, but then again, this one can’t live in qtbase where
>> the rest of the dbus code liv
On 13/10/15 12:22, "Oswald Buddenhagen"
wrote:
>On Tue, Oct 13, 2015 at 09:52:54AM +, Knoll Lars wrote:
>> The only one I could see that could make sense in an existing repo is
>>the
>> dbus qml integration, but then again, this one can’t live in qtbase
>>where
>> the rest of the dbus code li
On Tue, Oct 13, 2015 at 10:20:03AM +0200, René J.V. Bertin wrote:
> I'm experimenting with something that requires me to add an optional
> simple linker module (static library or even a .o object file) in the
> final step of the build process of an application (or library). It'd
> be part of QtBase
On Tue, Oct 13, 2015 at 09:52:54AM +, Knoll Lars wrote:
> The only one I could see that could make sense in an existing repo is the
> dbus qml integration, but then again, this one can’t live in qtbase where
> the rest of the dbus code lives. So it’s either a separate repo, or we add
> it to th
On Tue, Oct 13, 2015 at 08:53:21AM +, Hausmann Simon wrote:
> I think code that isn't specific to the automotive industry such as as
> the dbus integration should be integrated into existing modules unless
> there is a good reason otherwise.
>
i said the same. ^^
it turns out that there are, e
I think the new repos are generally ok.
The only one I could see that could make sense in an existing repo is the
dbus qml integration, but then again, this one can’t live in qtbase where
the rest of the dbus code lives. So it’s either a separate repo, or we add
it to the qtdeclarative repo.
Chee
On Mon, Oct 12, 2015 at 10:39:29PM +0200, René J.V. Bertin wrote:
> I can't remember, did I file a bug report on this,
>
that shouldn't be too hard to find out, no? ;)
> or has the issue already been picked up?
>
i don't really understand the issue, so no. please have a close look at
the status q
I think code that isn't specific to the automotive industry such as as the dbus
integration should be integrated into existing modules unless there is a good
reason otherwise.
Just my two cents,
Simon
From: Viironen Kalle
Sent: Tuesday, October 13, 2015 09:35
To: development@qt-project.org
Subj
+1
--
Tuukka
From: development-bounces+tuukka.turunen=theqtcompany@qt-project.org
[mailto:development-bounces+tuukka.turunen=theqtcompany@qt-project.org] On
Behalf Of Viironen Kalle
Sent: tiistaina 13. lokakuuta 2015 10.35
To: development@qt-project.org
Subject: [Development] New Qt Mo
Hello,
I'm experimenting with something that requires me to add an optional simple
linker module (static library or even a .o object file) in the final step of
the build process of an application (or library). It'd be part of QtBase
(QtCore, even), and provide a means to control the behaviour o
Hi,
We’d like to have a bunch of new modules under qt-project. These are all needed
in Qt Automotive Suite so let’s try to get this sorted out quickly to get
things rolling nicely.
New repositories needed are:
*
qt/qtapplicationmanager, Qt component for application lifecycle management
*
29 matches
Mail list logo
