Hi
>
> I am porting an application to Qt5/KF5 and was surprised to see the
> main widget of the application was showing all black. There are
> screenshots of the original version and the buggy version[1] online. I
> removed
>
> setAttribute( Qt::WA_PaintOnScreen, true );
>
> on that widget and t
Yay :)
Simon
Opprinnelig melding
Fra: Thiago Macieira
Sendt: 21:43 onsdag 13. august 2014
Til: development@qt-project.org
Emne: [Development] Fwd: Change in qt/qtbase[5.4]: Add the QStorageInfo class
It merged.
-- Forwarded Message --
Subject: Change in qt/qtbase[5.4]: Ad
It merged.
-- Forwarded Message --
Subject: Change in qt/qtbase[5.4]: Add the QStorageInfo class
Date: Wednesday 13 August 2014, 20:58:46
From: Qt Continuous Integration System (Code Review)
To: Ivan Komissarov
CC: Konstantin Ritt , Denis Shienkov
, Shawn Rutledge , Qt
Sanit
Hello,
I'm pcman, a developer of LXQt project (http:/lxqt.org/).
This is a new open-source Qt-based desktop environment, just like KDE.
We already ported the whole desktop to Qt5 and is preparing for a new
release, but now we're blocked by some XCB related problems of Qt 5.
https://bugreports.qt-p
On Wed, Aug 13, 2014 at 08:37:06AM -0700, Thiago Macieira wrote:
> On Wednesday 13 August 2014 17:07:16 Daniel Teske wrote:
> > On Wednesday 13 Aug 2014 08:05:52 Thiago Macieira wrote:
> > > On Wednesday 13 August 2014 14:32:13 Ziller Eike wrote:
> > > > So my question: Does anyone have any idea ho
On Wednesday 13 August 2014 18:07:53 Kevin Funk wrote:
> > Does fromUserInput("C:/tmp") return "file:///C:/tmp" ?
>
> With QUrl::fromUserInput("C:/tmp") we get the exact same results.
>
> I guess I should just file a bug then...
It would be easier if you submitted the fix. QUrl::fromUserInput an
On Wednesday 13 August 2014 07:57:55 Thiago Macieira wrote:
> On Wednesday 13 August 2014 14:14:38 Kevin Funk wrote:
> > Hey,
> >
> > while porting to Qt5/KF5, we've found some issues with the new
> > QUrl::toDisplayString method on Windows.
> >
> > Running the attached test-case [1], we get the
On Wednesday 13 August 2014 17:07:16 Daniel Teske wrote:
> On Wednesday 13 Aug 2014 08:05:52 Thiago Macieira wrote:
> > On Wednesday 13 August 2014 14:32:13 Ziller Eike wrote:
> > > So my question: Does anyone have any idea how this could possibly
> > > happen,
> > > how we could reproduce and/or d
On Aug 13, 2014, at 5:07 PM, Daniel Teske wrote:
> On Wednesday 13 Aug 2014 08:05:52 Thiago Macieira wrote:
>> On Wednesday 13 August 2014 14:32:13 Ziller Eike wrote:
>>> So my question: Does anyone have any idea how this could possibly happen,
>>> how we could reproduce and/or debug and fix it?
On Wednesday 13 Aug 2014 08:05:52 Thiago Macieira wrote:
> On Wednesday 13 August 2014 14:32:13 Ziller Eike wrote:
> > So my question: Does anyone have any idea how this could possibly happen,
> > how we could reproduce and/or debug and fix it?
>
> I also got a bug report that is similar:
> https:
On Wednesday 13 August 2014 14:32:13 Ziller Eike wrote:
> So my question: Does anyone have any idea how this could possibly happen,
> how we could reproduce and/or debug and fix it?
I also got a bug report that is similar:
https://bugreports.qt-project.org/browse/QTBUG-40636
It's right now in "ne
On Wednesday 13 August 2014 14:14:38 Kevin Funk wrote:
> Hey,
>
> while porting to Qt5/KF5, we've found some issues with the new
> QUrl::toDisplayString method on Windows.
>
> Running the attached test-case [1], we get the following results
> with Qt5 dev branch on Windows:
>
> path "/C:/tmp"
For Qt Creator we get the following crash reported:
https://bugreports.qt-project.org/browse/QTCREATORBUG-11262
It seems to happen randomly, on unix (i.e. OS X and Linux) but possibly not on
Windows, at least Qt 5.2.1 and later, and the seemingly only person in the
Berlin office which also gets
Hi,
I am porting an application to Qt5/KF5 and was surprised to see the
main widget of the application was showing all black. There are
screenshots of the original version and the buggy version[1] online. I
removed
setAttribute( Qt::WA_PaintOnScreen, true );
on that widget and the widget was ren
Hey,
while porting to Qt5/KF5, we've found some issues with the new
QUrl::toDisplayString method on Windows.
Running the attached test-case [1], we get the following results
with Qt5 dev branch on Windows:
path "/C:/tmp"
toLocalFile "C:/tmp"
toDisplayString "file:///C:/tmp"
toDisplayStr
> Discussed on IRC with Jake
I completely missed the fact there's an IRC channel. How there as "OnO". Fell
free to ping me.
--Adam
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
> Afaics the suggestion is to never have the absolute path to the Qt frameworks
> added to the rpath at all. Which would make the rpaths *only* be useful for
> the bundled dependencies. So, when not using the “bundle stuff” option, it
> would require setting either DYLD_ in the run environme
On Aug 13, 2014, at 12:32 PM, Adam Strzelecki wrote:
> Ziller Eike wrote:
>
>> Can we please already now turn a cross-platform hat on, and at least think
>> about options that at least do not right away block using the same for
>> non-OS X?
>
> Sure, this is just a proposition, "bundle_qt" (
On Aug 13, 2014, at 11:07 AM, Oswald Buddenhagen
wrote:
> On Tue, Aug 12, 2014 at 07:08:45PM -0400, Jake Petroules wrote:
>> On 2014-08-12, at 06:50 PM, Adam Strzelecki wrote:
>>> I agree that such facility should be provided internally while
>>> implementing Phase II changes.
>>>
(1) Ad
Oswald Buddenhagen wrote:
> yes. except that i want these to be called QMAKE_BUNDLE_*.
> this is irrespective of x-platform use. i like the idea of calling the
> functionality "bundling".
Yup, that sounds better. So they will be:
QMAKE_BUNDLE_LIBRARIES
QMAKE_BUNDLE_PLUGINS
Adam Strzelecki wrote:
> Ziller Eike wrote:
> > Can we please already now turn a cross-platform hat on, and at least think
> > about options that at least do not right away block using the same for
> > non-OS X?
> Sure, this is just a proposition, "bundle_qt" (proposed in latter posts)
> seem
Ziller Eike wrote:
> Can we please already now turn a cross-platform hat on, and at least think
> about options that at least do not right away block using the same for non-OS
> X?
Sure, this is just a proposition, "bundle_qt" (proposed in latter posts) seems
to match it better.
> I do not se
On Tue, Aug 12, 2014 at 07:08:45PM -0400, Jake Petroules wrote:
> On 2014-08-12, at 06:50 PM, Adam Strzelecki wrote:
> > I agree that such facility should be provided internally while
> > implementing Phase II changes.
> >
> >> (1) Add qmake options QMAKE_EMBEDDED_FRAMEWORKS,
> >> QMAKE_EMBEDDED_
On Aug 12, 2014, at 9:14 PM, Jake Petroules
wrote:
> On 2014-08-12, at 12:36 PM, Adam Strzelecki wrote:
>
>>> Default behavior: I’m on favor of keeping it opt-in, either via "CONFIG +=
>>> bundle_frameworks" or “make bundle”
>>
>> Me too. However as I said previously stakeholders are to dec
On Aug 12, 2014, at 4:25 PM, Adam Strzelecki wrote:
> Okay, Phase II.
>
> (1) Introduce "bundle_frameworks" CONFIG option, and set it default for
> "rpath" shared builds on iOS & OS X
Can we please already now turn a cross-platform hat on, and at least think
about options that at least do no
25 matches
Mail list logo
