Hi, IMHO in MVC its not the task of the Model to instruct the View to update. This is the task of the controller! It listens to the Model and View and syncs their states.
Having said this what you are trying to do is Databinding and there are multiple frameworks in Java who allow you to bind your Model and View. One them (I think the only one which support QT) is Eclipse-Databinding [1] where a project named UFacekit [2,3] I announced lately on this list provides a QT implementation. I've currently not implemented QT-Threading support but that's not really hard to do. Tom [1]http://wiki.eclipse.org/JFace_Data_Binding [2]http://uface.googlecode.com/svn/trunk/incubation/org.ufacekit.incubation/org.ufacekit.ui.qt/ [3]http://tom-eclipse-dev.blogspot.com/ Derek Fountain schrieb: > Gunnar Sletta wrote: >> Tom Schindl wrote: >>> QApplication#invokeLater(Runnable) >>> QApplication#invokeAndWait(Runnable) >> There is also the option of posting events to objects in the gui thread >> or using queued connections: >> http://doc.trolltech.com/qtjambi-4.4/html/com/trolltech/qt/qtjambi-signalsandslots.html > > I seem to be getting myself rather confused about this. What comes of > trying to learn Java, Qt and Model/View/Presenter at the same time I > suppose. :o) > > The challenge I've set myself is to write a MVP based program using > QtJambi for the view. I'm trying to maintain the separation properly - > in theory if someone said "rip out the QtJambi view and replace it with > a text-based one" that should be possible. The Model has no QtJambi in > it - I want it entirely standalone from whatever display technology is > used in the view. > > The problem I'm hitting is what happens when a thread in the model wants > to update the view. I have a timer in the model (a native Java one, not > a QtJambi one) that triggers code that updates the model data. This > model update calls a method of the view to have the view updated. It's > not a Qt signal - no Qt stuff in the model remember - just a regular > method call. The view's method does a simple update() to redraw the widget. > > But this doesn't work, because the thread doing the update started off > life triggered from a Timer object, and hence isn't running in the main > thread. Thus the update() croaks. > > It's important that this issue is solved in the view. The model should > neither know nor care about thread-based limitations in the view. The > model should just call into the view saying "update required" and the > view should sort threading things out as it requires. > > So how do I handle this? I'm in a method of a QWidget derived object > wanting to call its update() immediately, but can't because I'm > executing in the wrong thread. From the pointers given to me so far it > seems I might be able to use invokeLater() to start off a one line > method that calls the update(). I might be able to "post an event into > the main thread," although I'm not sure how to do this (the docs I've > found so far are all C++ based). Or possibly use this idea of Queued > Connections, maybe having the code called by my model-started thread > emit a signal that's indirectly connected to a slot that does the update. > > I'm not sure what to do. All those options seem to forego the idea of an > immediate update - they all want to tell the main thread to do the > update when it gets round to it. I'm not sure I want to make that > compromise - what if I really need the update to occur *now*? > > Is this stuff difficult, or have I missed something obvious and over > complicated things? > _______________________________________________ > Qt-jambi-interest mailing list > [email protected] > http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest _______________________________________________ Qt-jambi-interest mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest
