On Wednesday 19 November 2014 18:12:20 Pau Garcia i Quiles wrote:
> > What library is that? I thought we did dlopen libudev...
>
> libQt5SerialPort
There's dlopen code in QtSerialPort. Something went wrong with the build or
the source code since that was introduced...
It's a regression, we had
On Wed, Nov 19, 2014 at 5:59 PM, Thiago Macieira
wrote:
> On Wednesday 19 November 2014 11:38:41 Pau Garcia i Quiles wrote:
> > Today I installed an snapshot of Qt 5.4.0 for Linux x86 on my Kubuntu
> 14.04
> > and found a problem: it links to libudev.so.0, while Ubuntu 14.04
> provides
> > libude
On Wednesday 19 November 2014 11:38:41 Pau Garcia i Quiles wrote:
> Today I installed an snapshot of Qt 5.4.0 for Linux x86 on my Kubuntu 14.04
> and found a problem: it links to libudev.so.0, while Ubuntu 14.04 provides
> libudev.so.1.
What library is that? I thought we did dlopen libudev...
--
On 19/11/14 11:59, "Knoll Lars" wrote:
>>API and style mistake -- the new constructor should very likely be
>>protected (useful only from subclasses?), but the private should be
>>passed by reference (or "QOpenGLPaintDevice(0)" gives a cryptic error):
>>
>>> class Q_GUI_EXPORT QOpenGLPaintDevic
On 19/11/14 10:43, "Giuseppe D'Angelo" wrote:
>ABI break (changing a private static in a public exported class)?
>
>> --- a/src/gui/text/qfontdatabase.h
>> +++ b/src/gui/text/qfontdatabase.h
>> @@ -160,14 +152,14 @@ private:
>> static void createDatabase();
>> static void parseFontName(
On 19/11/14 09:46, "Giuseppe D'Angelo" wrote:
>Il 19/11/2014 09:35, Thiago Macieira ha scritto:
>> On Wednesday 19 November 2014 09:22:46 Giuseppe D'Angelo wrote:
>>> Was adding a new override in the middle of an hierarchy safe? Or
>>> subclasses in user code will now require a recompilation? (No
Hello,
Today I installed an snapshot of Qt 5.4.0 for Linux x86 on my Kubuntu 14.04
and found a problem: it links to libudev.so.0, while Ubuntu 14.04 provides
libudev.so.1.
I was wondering if it would be a good idea for Qt to move from explicit
linking to dlopen/dlsym. That would help supporting d
ABI break (changing a private static in a public exported class)?
--- a/src/gui/text/qfontdatabase.h
+++ b/src/gui/text/qfontdatabase.h
@@ -160,14 +152,14 @@ private:
static void createDatabase();
static void parseFontName(const QString &name, QString &foundry, QString
&family);
Il 19/11/2014 01:23, Thiago Macieira ha scritto:
On Tuesday 18 November 2014 16:38:33 Frederik Gladhorn wrote:
Attaching simpler diff.
The diff is still huge because it trips over a massive change in Khronos
headers, which are 3rd party -- we have no control over those. Should we
move them
A couple of weeks ago (some of) the involved parties discussed the road ahead
here at the Oslo office. This mail is a summary of the outcome.
The story so far:
High-dpi support is implemented for Qt on OS X and iOS. This is the
“devicePixelRatio” scaling mode. For 5.4 a patch was proposed that
Il 19/11/2014 09:35, Thiago Macieira ha scritto:
On Wednesday 19 November 2014 09:22:46 Giuseppe D'Angelo wrote:
Was adding a new override in the middle of an hierarchy safe? Or
subclasses in user code will now require a recompilation? (Not a big
deal, I don't expect that many QRubberBand subcla
On Wednesday 19 November 2014 09:22:46 Giuseppe D'Angelo wrote:
> Was adding a new override in the middle of an hierarchy safe? Or
> subclasses in user code will now require a recompilation? (Not a big
> deal, I don't expect that many QRubberBand subclasses with a timerEvent
> override...)
Over
Thanks for the simplified diff, question:
index b603415..7193f69 100644
--- a/src/widgets/widgets/qrubberband.h
+++ b/src/widgets/widgets/qrubberband.h
@@ -196,6 +196,7 @@ protected:
#endif
void keyPressEvent(QKeyEvent *);
void changeEvent(QEvent *);
+void timerEvent(QTimerEvent
13 matches
Mail list logo
