octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #44775] CreateMode argument for msgbox/errordl


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #44775] CreateMode argument for msgbox/errordlg/warndlg
Date: Wed, 08 Apr 2015 17:58:38 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15

Follow-up Comment #1, bug #44775 (project octave):

The addition looks fine to me.  It's just a message.

The reason that program execution is blocked is that there is no existing
mechanism to communicate results back to the Octave core.  The layout
framework layout is as follows: Qt GUI is the main thread and the Octave core
is in a secondary thread--a "worker thread" of sorts.  (Only the main thread
can do graphics in Qt, with rare exception.)  That's a perfectly fine setup. 
It would be straightforward to make the dialogs non-modal and let the worker
thread continue on its way, but there is no way right now to communicate the
result back to Octave core.  The way to do this in the asynchronous,
cross-thread environment is with signals and slots.  The dialog box can send
out a signal when it is done, but there needs to be a slot on the worker
thread side of things to accept the signal.  That means whatever slot is on
the work thread side needs to remember information about the dialog that was
issued, probably with some identification in the case of multiple
dialogs/figures, etc.  Worker thread also needs to accept signals
"asynchronously", be that between script commands or whatever the case.

If by implement in Octave you mean that there are some primitives for drawing
plot elements, that seems like too much work at the moment--to define and
maintain.  Custom icons should be possible within the existing framework.  If
one attempts the custom layout that this changeset hints at, it may well end
up that it would work better with some more primitive OOP classes.  In that
case things could be restructured, but the advantage of going with the more
high level dialogs directly is the small amount of code it requires to
implement given the large amount of Qt objects.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?44775>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]