Re: [Development] Building a QtAddon from git

2013-08-09 Thread Laszlo Papp
diff --git a/src/logger/logger.pro b/src/logger/logger.pro index 4dc96b9..d257ae5 100644 --- a/src/logger/logger.pro +++ b/src/logger/logger.pro @@ -1,6 +1,6 @@ -load(qt_module) TARGET = QtLogger +load(qt_module) QPRO_PWD = $PWD CONFIG += module MODULE_PRI = ../../modules/qt_logger.pri On S

Re: [Development] Building a QtAddon from git

2013-08-09 Thread Thiago Macieira
On sexta-feira, 9 de agosto de 2013 21:37:24, Chris Craig wrote: > I am not sure what the correct value should be for a playground module that > is more or less stagnant should be. Does it need to get bumped with each > release like the official modules? Perhaps Sergio, Ossi, or somebody else > w

Re: [Development] Building a QtAddon from git

2013-08-09 Thread Chris Craig
Hate to reply to myself, but I made a typo. Add that line to .qmake.conf, not .qmake.cache. Chris On Fri, Aug 9, 2013 at 9:37 PM, Chris Craig wrote: > Sigh. I haven't tried building qtjsonstream with 5.1 yet. It looks like > a MODULE_VERSION is now required in .qmake.conf. Try adding someth

Re: [Development] Building a QtAddon from git

2013-08-09 Thread Chris Craig
Sigh. I haven't tried building qtjsonstream with 5.1 yet. It looks like a MODULE_VERSION is now required in .qmake.conf. Try adding something like: MODULE_VERSION = 5.1.1 to .qmake.cache I am not sure what the correct value should be for a playground module that is more or less stagnant shoul

Re: [Development] qmlbundle vs Qt Resource System

2013-08-09 Thread André Pönitz
On Thu, Aug 08, 2013 at 08:18:00PM +0200, Olivier Goffart wrote: > On Thursday 08 August 2013 08:59:26 Alan Alpert wrote: > > I don't know specifically about why it wasn't built on top of QRC, but > > my guess is the performance cost. qmlbundle is more intended as a > > performance optimization for

Re: [Development] Bundling Qt 5 libraries with application package and strange "font" error

2013-08-09 Thread Thiago Macieira
On sexta-feira, 9 de agosto de 2013 17:14:11, Tomasz Olszak wrote: > Application without changing RPATH in Qt libraries and application binary: > http://pbrd.co/136t3GI > > This is application after RPATH modification: > http://pbrd.co/136tyR2 Hi Tomasz RPATH and deprecated and you should not us

Re: [Development] epoll event dispatcher

2013-08-09 Thread Thiago Macieira
On sexta-feira, 9 de agosto de 2013 19:04:56, Oswald Buddenhagen wrote: > i'll note that the qml guys identified that as a major bottleneck a few > years ago and wrote their own timer code. Probably for the same reason why we identified the glib GTimeout as a major bottleneck (and grew worse for

[Development] Bundling Qt 5 libraries with application package and strange "font" error

2013-08-09 Thread Tomasz Olszak
Hi, I've built Qt5 with with e.g. /home/user/qt prefix and wanted to deploy needed Qt libraries and plugins along with Qt application. Application suppose to be installed in e.g. /tmp , Qt5 libraries in /tmp/lib and directories plugins and qml should be placed accordingly in /tmp/data/plugins and

Re: [Development] epoll event dispatcher

2013-08-09 Thread Thiago Macieira
On sexta-feira, 9 de agosto de 2013 08:48:12, Thiago Macieira wrote: > If anything, we'd need to change our interface in QSocketNotifier to > benefit from the edge trigger. We toggle our write notifications all the > time because we need the edge, not the level. > > No, epoll makes no sense until

Re: [Development] 6 months & 2 Qt versions to solve a P1 bug ? Warning:Rant

2013-08-09 Thread Thiago Macieira
On sexta-feira, 9 de agosto de 2013 13:15:34, Jordi Pujol wrote: > Just a doubt, It's normal to have a P1 task > ( https://bugreports.qt-project.org/browse/QTBUG-29716 ) from February > 19th without a workaround nor a solution or patch ? Yes. Technically speaking, all P1s should be fixed by the n

Re: [Development] epoll event dispatcher

2013-08-09 Thread Thiago Macieira
On sexta-feira, 9 de agosto de 2013 14:09:12, Cyril Oblikov wrote: > OK, thanks for clarifying. Can it be somehow optimized? Yes, but it will mostly require a major rewrite of all classes derived from it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Sour

Re: [Development] epoll event dispatcher

2013-08-09 Thread Thiago Macieira
On sexta-feira, 9 de agosto de 2013 10:39:33, Oswald Buddenhagen wrote: > On Thu, Aug 08, 2013 at 09:13:42AM -0700, Thiago Macieira wrote: > > Yes, that would be ideal. That would require iterating over all socket > > notifiers we have on this event dispatcher, to determine which ones > > have chan

Re: [Development] epoll event dispatcher

2013-08-09 Thread Thiago Macieira
On quinta-feira, 8 de agosto de 2013 08:18:18, Thiago Macieira wrote: > Despite the comments in it, the task is actually unrelated. It's asking > about a poll-based dispatcher, not an epoll-based one. A poll-based > dispatcher makes a lot of sense and I'd love to see it implemented. A patch for p

Re: [Development] epoll event dispatcher

2013-08-09 Thread Cyril Oblikov
OK, thanks for clarifying. Can it be somehow optimized? On Fri, Aug 09, 2013 at 12:38:31PM +0300, Cyril Oblikov wrote: > > another consideration is that it is utterly unlikely that the event > > loop's ability to efficiently process hundreds of sockets is of any > > relevance to qt. > > Sure this i