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

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

[Octave-bug-tracker] [bug #44219] Deleted GUI file editor tabs not forgo


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #44219] Deleted GUI file editor tabs not forgotten upon command line "exit"
Date: Sat, 14 Feb 2015 17:59:39 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15

Follow-up Comment #11, bug #44219 (project octave):

Thanks for testing.  Attached is an upgrade.

- The default confirm_shutdown() was returning false, when it should return
true.  octave-cli now exits.

- I picked the wrong save-modified-file message.  I meant to choose the "Do
you want to cancel closing, save or discard the changes?", which seems to
generically cover all cases.  Again, if we want it customized, I suggest
passing in a QString under the different scenarios (note that the -1 case no
longer exists because with the changeset "exit" at the command line now
confirms exit).

Regarding the character strings.  I see that they show up in
libgui/languages/it_IT.ts.  Does it seem like there should be a different way
of managing the original string?  If GUI dialog boxes are managed in the
layout program, is translation maintenance part of that?

As for the discussion in #42307, I disagree with the approach of using C++
api, especially via some callback method across threads.  The big drawback is
that requires knowledge of the API routines in order to do GUI programming,
routines that really aren't defined in stone or documented.  On the other
hand, commands are well defined, have extensive documentation, have a generic
return format of octave_value, and keep the GUI from being entwined with the
core worker process so that someone else can write a GUI in some other
framework without too much trouble.  The way things are laid out right
now--with a GUI main process and an octave core worker process--lends itself
to the use of commands.  There is always going to be some element of
coordination to deal with in an asynchronous environment like a GUI.  Can the
GUI call API functions directly?  No, because octave core could be busy doing
some processing.  So either it is queuing callback function calls (across
threads), or queuing commands.  The language already has the ability to do
everything needed, as far as a GUI is concerned.  Realtime graphics may be
another issue, but that would require more thought and better design--it's
down the road, another stage, given the way open-source projects work.

(file #33075)
    _______________________________________________________

Additional Item Attachment:

File name: octave-shutdown-djs2014feb14_1130.patch Size:27 KB


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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