And every small, movable object kept in QVariant is affected. QMetaType also
keeps pointers to functions defined in plugins if such register a type. I
believe that we had that discussion around Qt4->Qt5 migration. Unloading
plugins is not safe, sometimes it works but still it is very tricky. I a
On Thu, 5 Nov 2015, Thiago Macieira wrote:
It gets worse if you have KF5-based image format plugins, since kimg_eps.so
links to QtPrintSupport. Fortunately, none of them today link to other KF5
libraries, but can we continue to count on that?
Well, the KRA and OpenRaster image format plugins t
On Thursday 05 November 2015 15:50:17 Thiago Macieira wrote:
> On Thursday 05 November 2015 18:23:37 Robin Burchell wrote:
> > On Thu, Nov 5, 2015, at 06:13 PM, Oswald Buddenhagen wrote:
> > > > Problem: performance impact, complexity of the atom/quark solution.
> > >
> > > to lessen the performan
On Thursday 05 November 2015 21:06:20 Marc Mutz wrote:
> On Thursday 05 November 2015 17:44:33 Thiago Macieira wrote:
> > Proposal: force QStringLiteral uses to always address a heap-allocated
> > QString, instead of pointing to the static data. Possibly, this should be
> > an interned atom/quark
On Thursday 05 November 2015 18:23:37 Robin Burchell wrote:
> On Thu, Nov 5, 2015, at 06:13 PM, Oswald Buddenhagen wrote:
> > > Problem: performance impact, complexity of the atom/quark solution.
> >
> > to lessen the performance impact, we could have a #define to control the
> > construction beha
On Thursday 05 November 2015 18:13:36 Oswald Buddenhagen wrote:
> On Thu, Nov 05, 2015 at 11:44:33AM -0500, Thiago Macieira wrote:
> > Alternative: force QPluginLoader / QFactoryLoader to fake unloading but
> > not
> > really unload.
>
> you already did that quite a while ago. was it reverted? or
On Thursday 05 November 2015 18:23:49 Milian Wolff wrote:
> When you load a plugin, or compile a QRegExp, or use DBUS, or ... then the
> cost of these operations easily dwarfs the string heap allocation. So this
> is not that bad, imo.
Making a nothrow operation throwing is bad. Avoiding heap al
On Thursday 05 November 2015 17:44:33 Thiago Macieira wrote:
> Proposal: force QStringLiteral uses to always address a heap-allocated
> QString, instead of pointing to the static data. Possibly, this should be
> an interned atom/quark à la GQuark, so two passes on the same
> QStringLiteral would
On Thu, Nov 05, 2015 at 06:23:37PM +0100, Robin Burchell wrote:
> On Thu, Nov 5, 2015, at 06:13 PM, Oswald Buddenhagen wrote:
> > > Problem: performance impact, complexity of the atom/quark solution.
> > >
> > to lessen the performance impact, we could have a #define to control the
> > constructio
2015-11-05 10:46 GMT+01:00 Massimo Callegari :
> >>> Indeed they aren't on GL windows. The goal with decorations is to move
> >>> them to subsurfaces and just draw them with SHM, so we don't need to
> >>> do hacks for GL windows like we do in the wayland-egl
> >>> hardwareintegration.
> >>
> >> So
On Donnerstag, 5. November 2015 18:13:36 CET Oswald Buddenhagen wrote:
> On Thu, Nov 05, 2015 at 11:44:33AM -0500, Thiago Macieira wrote:
> > Alternative: force QPluginLoader / QFactoryLoader to fake unloading but
> > not
> > really unload.
>
> you already did that quite a while ago. was it revert
On Thu, Nov 5, 2015, at 06:13 PM, Oswald Buddenhagen wrote:
> > Problem: performance impact, complexity of the atom/quark solution.
> >
> to lessen the performance impact, we could have a #define to control the
> construction behavior of QSL at compile time. i'm not quite sure whether
> to make th
On Thu, Nov 05, 2015 at 11:44:33AM -0500, Thiago Macieira wrote:
> Alternative: force QPluginLoader / QFactoryLoader to fake unloading but not
> really unload.
>
you already did that quite a while ago. was it reverted? or never
integrated?
> I've said in the past that unloading plugins is a bad
On Thursday, November 05, 2015 11:44:33 AM Thiago Macieira wrote:
> Proposal: force QStringLiteral uses to always address a heap-allocated
> QString, instead of pointing to the static data. Possibly, this should be an
> interned atom/quark à la GQuark, so two passes on the same QStringLiteral
> wou
And moc data is affected in a similar way. I continue to be in favor of (3)
Simon
Original Message
From: Thiago Macieira
Sent: Friday, November 6, 2015 00:44
To: development@qt-project.org
Subject: [Development] RFD: plugins vs QStringLiterals
Proposal: force QStringLiteral uses to always add
Proposal: force QStringLiteral uses to always address a heap-allocated
QString, instead of pointing to the static data. Possibly, this should be an
interned atom/quark à la GQuark, so two passes on the same QStringLiteral
would result in the same heap pointers.
Alternative: force QPluginLoader
André Somers wrote:
> Actually, you are right about the sync in the EU (for all clocks) and
> about the hour that is duplicated depending on the time zone, but I
> think you are off on the hour it happens. In CET it is 2:mm that is
> duplicated, in GMT and WET it is 1:mm and in finland (EET) it is
On Thursday 05 November 2015 14:54:04 André Somers wrote:
> Interesting, I did not know that the summertime adjustment is
> synchronized in the EU. Interesting little factoid :-)
The sole purpose of this being, of course, to prevent you from speeding with
your car without penalty for more than j
On Thursday 05 November 2015 08:45:01 Thiago Macieira wrote:
> On Thursday 05 November 2015 13:10:33 André Somers wrote:
> > *) At least in so far the actual clock time in the country is concerned.
> > Perhaps for other purposes the EU defines a single switchover moment for
> > the whole of the EU?
Op 5-11-2015 om 00:06 schreef Kevin Kofler:
Welbourne Edward wrote:
I'm looking into QTBUG-49008 and need to work out how diverse
implementations of mktime handle DST transitions: at one end of the year
there's a gap (where 1:59 is followed by 3:00), at the other end there's
a duplicated hour (w
On Thursday 05 November 2015 13:10:33 André Somers wrote:
> *) At least in so far the actual clock time in the country is concerned.
> Perhaps for other purposes the EU defines a single switchover moment for
> the whole of the EU? That is pure speculation though.
Correct. In Finland, the clocks
* André Somers [2015-11-05 13:10:33 +0100]:
> Op 5-11-2015 om 00:06 schreef Kevin Kofler:
> >Welbourne Edward wrote:
> >>I'm looking into QTBUG-49008 and need to work out how diverse
> >>implementations of mktime handle DST transitions: at one end of the year
> >>there's a gap (where 1:59 is follo
Op 5-11-2015 om 00:06 schreef Kevin Kofler:
Welbourne Edward wrote:
I'm looking into QTBUG-49008 and need to work out how diverse
implementations of mktime handle DST transitions: at one end of the year
there's a gap (where 1:59 is followed by 3:00), at the other end there's
a duplicated hour (w
Kevin Kofler wrote:
> The EU actually defines the switchover time in UTC,
That's a surprise. Do you have a reference for that ?
> so which hour is duplicated depends on the actual
> time zone. It's the 3:mm hour in CET/CEST.
I distinctly remember, the weekend before last, seeing the 2:mm hour
d
Hi John,
I was hoping to hear from you - thanks for getting in touch.
> I'm the original author of a lot of the current QDateTime/QTimeZone code,
Indeed; git blame told me this and you'd shown up in my googling for
references to the topic, which is why I've added you to some
code-reviews.
> I'm
>>> Indeed they aren't on GL windows. The goal with decorations is to move
>>> them to subsurfaces and just draw them with SHM, so we don't need to
>>> do hacks for GL windows like we do in the wayland-egl
>>> hardwareintegration.
>>
>> So what's the whole point of having a compositor if you cannot
On 3 November 2015 at 14:28, Welbourne Edward <
edward.welbou...@theqtcompany.com> wrote:
> Hi all,
>
> I'm looking into QTBUG-49008 and need to work out how diverse
> implementations of mktime handle DST transitions: at one end of the year
> there's a gap (where 1:59 is followed by 3:00), at the
27 matches
Mail list logo
