2012/10/24 d3fault <d3faultdot...@gmail.com>: > > Weird, so what you're saying is: > > QWidget 'this' parent > _Layout > _Layout1Widget1 > _Layout1Widget2 > __SubLayout1 // added via Layout.addLayout(), Layout now being his parent > _SubLayout1Widget1 > _SubLayout1Widget2 > __SubLayout2 // ditto > _SubLayout2Wiget1 > ___SubSubLayout3 // added via SubLayout2.addLayout(), SubLayout2 now > being his parent > _SubSubLayout3Widget1 > _SubSubLayout3Widget2 > > With everything that's a widget being a sibling and a direct child of 'this'? > > I guess that makes sense. I think I'm better off just removing the > part of the comment that's wrong than trying to explain that (but the > QWidget::setLayout docs should (and don't) explain it!). >
Look at http://qt-project.org/doc/qt-4.8/layout.html#tips-for-using-layouts > >> >> Regarding rewriting the example, I think the best way to rewrite it is to >> remove all usage of QThread entirely, and see if you can figure out how to >> program it using the higher-level QtConcurrent API. In my book [Intro to >> Design Patterns in Qt, 2nd edition], I show another multithreaded example >> written both ways and the QtConcurrent version performs much better. >> > >> book > I wish I could see what you're talking about :-P. My goal in making > that example is/was to have a simple and easy to understand reference > that implements a clean and re-usable design. Performance was not a > huge concern, but I wouldn't say it isn't important. > > Why would QtConcurrent be more performant if they both use QThreads in > the background? I'm under the impression that QtConcurrent is meant > for.. err... problems... that scale horizontally. Yes my use of > QCryptographicHash would scale horizontally, but not everything can. > Is QtConcurrent still more performant in those cases where we can't > scale horizontally? If so, I'll look more into rewriting it under > QtConcurrent (if I could see the example in your book I could answer > this myself). > > At a glance (I've read all the QtConcurrent docs previously, but have > yet to actually use it... so I guess I should say "at a re-glance"), > it looks like I could use that template-based readyForConnections() > emitting design described in my previous email very easily within > QtConcurrent::run(). However, then I saw this: "Note that the function > may not run immediately; the function will only be run when a thread > is available" ( > http://qt-project.org/doc/qt-4.8/qtconcurrentrun.html#run ). Within a > large application with many backend objects/threads (doing different > things, so they can't scale horizontally), it sounds sub-optimal to > not be able to have them all running at the same time. You could > override QThreadPool's max thread count, but idk that just seems > hacky. Aren't thread pools meant for numerous shorter living units of > execution? I recall reading somewhere something along the lines of "if > you are going to keep the thread alive for a long time, use QThread > instead". The example, and the design I'm trying to perfect, is the > long-standing single (or I guess double lol) backend thread. > > If I'm wrong and setting QThreadPool's max thread count to be >= your > backend object count on a per-project basis isn't a dirty hack > (separation of concerns!)... and if QtConcurrent really performs that > much better... I'll probably use it for the rewrite. Thanks :) > > d3fault > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest