|
From: | Daniel J Sebald |
Subject: | Re: GUI doesn't appear when using ./run-octave |
Date: | Wed, 03 Oct 2012 05:57:43 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
On 09/27/2012 01:35 AM, Daniel J Sebald wrote:
On 09/26/2012 10:31 PM, John W. Eaton wrote:On 26-Sep-2012, Daniel J Sebald wrote: | On 09/24/2012 05:16 AM, Daniel J Sebald wrote: | |> I couldn't quite finish a patch that fixes a half dozen GUI bugs. |> Hopefully within a day or so. | | I still need to make a couple small changes...close. Do you mean that you are working on a single jumbo patch that solves a half dozen unrelated bugs? If so, then please split the patch into multiple patches with each one fixing a single problem. Thanks, jweIt would be nice to do individual bug fixes, but what I'm doing is shuffling things around in a more slot/signal fashion. The goal is to make solving all these bugs much easier because everything then falls under the one paradigm. So, it's not like the bugs in the current code can be solved with simple conditional statements or something equally easy. Instead there are problematic things like static variable "alreadyAsking" (which don't work under a multi-object paradigm, e.g., can't recognize multiple file changes on disk). With the changes, I'm expecting it to become easier to develop fixes and solve bugs by making proper connections of signals and slots.
I've put a patch on Savannah:patch #7857: Replace dynamic casts of GUI/IDE editor with more slots/signals configuration
https://savannah.gnu.org/patch/index.php?7857that revamps the file editor portion of the GUI/IDE. I think this is a patch where it might be easier to absorb after applying the patch and looking through the files file-editor.cc, file-editor-tab.cc, file-editor.h, file-editor-tab.h. These files really aren't too big. The patch file seems too disjointed for perusing.
I've paused with development when I could have moved forward touching things up a bit. However, I think it was Michael who pointed out there really isn't a specification for how the behavior should be, so maybe it's good to allow some time for folks to absorb the more signal/slot oriented style. Then we can talk about ways to move forward and improve the code.
For example, there needs to be a way for the Exit/window-close signal to reach the file editor.
Keep in mind that I've aimed to make things as NonModal as possible so that the application is not "frozen" waiting on user input. Such a thing is a big problem in an IDE where there are possible events from the outside (e.g., multiple file changes on disk) and from Octave (e.g., a processing script that might be displaying info or plotting as it proceeds). We can pull back on that some, simply by changing a setting in the message box or file dialog from NonModal to ApplicationModal. But again, conversation about desired and logical behavior would be good. (For example, I'm pretty sure everyone would prefer a NonModal find dialog.)
Dan
[Prev in Thread] | Current Thread | [Next in Thread] |