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
*
+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
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
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
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
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.
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,
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
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
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
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
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
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
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
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
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
>
>
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
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
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
> 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
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
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
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
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
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
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
26 matches
Mail list logo