Multi-threaded GUI

[Gor Gyolchanyan]

On Thu, Jul 26, 2012 at 12:16 PM, Russel Winder <russel at winder.org.uk>wrote:

> On Wed, 2012-07-25 at 23:17 +0200, Kagamin wrote:
> > On Wednesday, 25 July 2012 at 18:50:51 UTC, Simon wrote:
> > > You have to be very, very careful with trying to do multi
> > > threading w/ windoze windows. Try doing a google search on it,
> > > and the advice is invariably: don't do multi threaded windows.
> > > Everybody including people famous for their in-depth window
> > > knowledge recommends a single thread UI with non-UI worker
> > > threads.
> >
> > Hmm... AFAIK it's quite opposite: windows UI is the only UI that
> > works in multithreaded environment, it's just recommended to not
> > do it, because this feature is inconsistent with other UI
> > frameworks, so that you don't get used to wrong programming
> > technique.
>
> I know essentially nothing of Windows, but quite a lot about
> AWT/Swing/JavaFX/GroovyFX, GTK+2, GTK+3, PyGTK, PyGObject, PySide,
> PyQt4, wxPython, and tkInter. As you say all of these use an
> single-threaded event loop to manage all widgets. Fundamentally this is
> because there is only one screen and one window manager, and all widgets
> need to be manipulated relative to that. Using a single-threaded event
> loop is the easiest way of avoid deadlock and livelock given that there
> is a shared resource.
>
> The same message has been learnt in Web servers where the multi-threaded
> approach has given way to a single-threaded event loop approach.
>
> So if Windows is really doing multi-threaded widget management, this
> would be very interesting.  Where is the material that I can look at
> that leads you to say that Windows is a multi-threaded UI.
>
> As Simon mention, just because the UI is single-threaded doesn't mean
> the application is. Exactly the opposite, good UI-based applications are
> generally multi-threaded, it is just that there is only one thread
> running the UI, all the others handle business logic.
> --
> Russel.
>
> =============================================================================
> Dr Russel Winder      t: +44 20 7585 2200   voip:
> sip:russel.winder at ekiga.net
> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>

So the good way to do this will be to have a single thread, which pumps
messages and distributes the appropriate message handlers to worker
threads, right?

My goal here is to have 100% working and responsive GUI no matter how bad
the application lags. If, for instance, The user would push a button, which
initiates a very expensive computation, I don't want the GUI to become
stuck. If the user doesn't wait and pushes the button again, it should
display a message, which says "The operation is already in progress" or
something like that.

-- 
Bye,
Gor Gyolchanyan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120726/7cf446e4/attachment-0001.html>