Sun 31 May 2015 09:37:44 PM UTC, comment #36:
I'm closing this bug as fixed, the bug described here has been resolved, agree with comment #33. If there are further improvements that could be made to the interaction between Octave and Qt, that should be a separate bug report or patch tracker item.
|
Sun 05 Apr 2015 08:12:13 PM UTC, comment #35:
The advantage is that it is a more proper way of doing object-oriented programming. The overall strategy of OOP is sort of ground up, i.e., start with smaller hunks of code and assemble the objects to create complexity. Passing in the start_gui variable to what is essentially supposed to be Qt window layout means too much functionality is inside that main_window object. That came about because in the beginning the thought was the GUI was the main end goal. The building of the link is in the QMainWindow, the construction of dialog-popups is in the QMainWindow, many things are in there that don't need to be.
The reason the uigetfile is hanging is there is no slot connection to the signal requesting a file-dialog be created when QMainWindow (main_window) is not created. The link sends out a signal and then waits for the answer. It's straightforward to move the pertinent code out of QMainWindow (main_window) and associate it instead with the octave-qt-link; it's only a few lines of code for each action.
If the Qt environment is going to be set up and working without QMainWindow (first changeset), there's no need for widget/dialog code to be in main-window.cc anymore (second changeset). In fact, there is this comment in main_window.cc I must have put in some time ago:
Attached is a back-to-back changeset. You will have to roll back to previous changeset (or extract just the additional changeset from the attached file). There is always cleanup that can be done, but I simply connected the new slots of QUIWidgetCreator to its own signals. Seems odd, but that is the least amount of code change. Also, I'd rather leave it that way for now because I'm anticipating someone will eventually request that the dialogs be non-modal and it seems signals/slots is best for that.
(file #33550)
|
Sat 04 Apr 2015 07:11:31 PM UTC, comment #34:
@Dan: I tried the patch and it applies cleanly, but a simple test of uigetfile failed. What is the advantage of your patch over the one already committed to Mercurial?
Sample code:
|
Sat 04 Apr 2015 06:09:12 PM UTC, comment #33:
This bug as described in the title has been fixed.
It would be helpful to close this burg report and open a new report about other problems as discussed below.
|
Sat 04 Apr 2015 03:12:25 AM UTC, comment #32:
I'm attaching a patch that reorganizes things, basically it goes back to the code prior to this change except the construction of the link is moved outside of the QMainWindow construction then its pointer is passed in the main_window::main_window() constructor. QMainWindow is application window layout and doesn't really need to hold the octave_qt_link. The only other thing needed is a few extra simple signal/slot connections to supply the shutdown and exit_app functionality.
(file #33527)
|
Tue 17 Mar 2015 04:18:06 PM UTC, comment #31:
I can't judge the implementation as I'm very unfamiliar with the GUI, but works for me.
|
Tue 17 Mar 2015 03:56:55 PM UTC, comment #30:
Patch works for me too.
My suggestion is to deprecate fltk and focus on qt.
Maybe the ui... stuff can be seperated more clearly from the GUI (in terms of configure.ac and directory tree), so that some qt packages can be skiped if the user doesn't need the GUI.
|
Tue 17 Mar 2015 03:45:38 PM UTC, comment #29:
Probably not, just thought I'd mention it.
|
Tue 17 Mar 2015 03:37:22 PM UTC, comment #28:
Given that we have limited resources, I'm wondering whether it is worth the effort to try to handle FLTK and Qt widgets.
|
Tue 17 Mar 2015 03:26:05 PM UTC, comment #27:
The patch works work me.
Not sure if this is important, but now I don't get FLTK windows for uigetfile even when the graphics toolkit is set to fltk.
It's pretty easy to see why as the code assumes qt as long as the octave_link is enabled.
|
Tue 17 Mar 2015 02:17:38 PM UTC, comment #26:
I checked in the following changeset so that we create a dummy main_window and initialize the octave_link object when running with --no-gui. With this change, uigetfile seems to work for me and appears to display the Qt widget set.
http://hg.savannah.gnu.org/hgweb/octave/rev/857a8f018f53
|
Tue 10 Mar 2015 11:59:39 AM UTC, comment #25:
Was this patch not planned to also support the ui* functions, like uigetfile and uigetdir? Or are these different? I get the same issue as in comment #18
|
Tue 10 Mar 2015 08:07:17 AM UTC, comment #24:
'Save As' from menu und the ui... commands doesn't work because of the octave_qt_link stuff. Adding a simple octave_qt_link class to octave_cli_thread helps to get 'Save As' working, but then octave hangs when quit or trying to use ui... commands.
|
Tue 10 Mar 2015 03:59:19 AM UTC, comment #23:
Can this bug be closed? The qt toolkit now works for plotting when Octave is launched with --no-gui.
|
Mon 02 Mar 2015 02:28:31 PM UTC, comment #22:
The default qt menu can be removed by
set(gcf, 'MenuBar', 'None')
so it's still possible to build custom menus with uimenu. I think we can forget about the uimenu patch. The octave_link thing still remains an issue.
|
Fri 27 Feb 2015 05:47:54 PM UTC, comment #21:
Second improved patch.
(file #33202)
|
Fri 27 Feb 2015 05:01:30 PM UTC, comment #20:
I will try to help with the octave_link thing.
Could you just remove the obsolete code instead of commenting it?
|
Fri 27 Feb 2015 04:27:33 PM UTC, comment #19:
Sorry, I mean printing.
Attached a first patch to replace qt menus with uimenu entries. It reverts patch 7335cc071ab0 and adds uimenu instead.
The 'about' menu and window get lost for now, but should be easy to add. Translation and icons may be more difficult.
The file dialog is currently opened with fltk, since the qt windows need octave_link, but I did not understand the octave_link thing yet.
(file #33200)
|
Fri 27 Feb 2015 04:19:39 PM UTC, comment #18:
Michael, I wonder why plotting works for you.
Does following command return 0 for you?
Could you also try command 'uigetfile' ?
It opens the fltk window in my case.
|
Fri 27 Feb 2015 04:08:45 PM UTC, comment #17:
Works just fine for me.
plots seem to match fltk.
|
Fri 27 Feb 2015 02:46:13 PM UTC, comment #16:
I checked in the change to enable the qt graphics toolkit in this changeset:
http://hg.savannah.gnu.org/hgweb/octave/rev/c7c50030e76c
|
Fri 27 Feb 2015 02:40:51 PM UTC, comment #15:
Stefan,
I don't know why the QtHandles code uses Qt menus/QAction items directly instead of uimenu. That was part of the code before I started working on it, and I really didn't know how menus were handled in the FLTK code until now.
It does seem like it would be better to share the same menu code for both FLTK and Qt but I don't know how to make that work for the Qt code.
|
Thu 26 Feb 2015 10:45:56 PM UTC, comment #14:
Just tried save of plot from plot menu and
quit while plot open.
Both work for me! Fedora 21.
Thanks!
|
Wed 25 Feb 2015 06:10:36 PM UTC, comment #13:
John,
just looking to the 'Save' issue. Why using
fileMenu->addAction (tr ("Save &As"))->setEnabled (false);
to generate the menus and not
uimenu (__f, "label", "&Save", "callback", @save_cb);
like in _add_default_menu_.m for fltk?
With current qt implementation it's not possible to overwrite or delete the default menu.
However, I still have no clue why save is not working. Maybe something with 'octave_link'.
|
Wed 25 Feb 2015 05:49:59 PM UTC, comment #12:
Could you try the following change to scripts/startup/__finish__.m?
Add
to that function.
|
Wed 25 Feb 2015 02:11:06 AM UTC, comment #11:
here is bt from seg fault if quit while plot is open
|
Tue 24 Feb 2015 06:32:42 PM UTC, comment #10:
I don't see a segfault when quit.
Need to look at the Save as issue.
|
Tue 24 Feb 2015 06:16:07 PM UTC, comment #9:
Stefasn: Did you try save of a plot from
the plot menu? Or try quit while plot is open?
|
Tue 24 Feb 2015 06:13:41 PM UTC, comment #8:
My builds based on b59aabc08e63 and df3f1d2328d7 works with simple plot(1:4) and quit. Tested with and without --no-gui option.
|
Tue 24 Feb 2015 05:59:14 PM UTC, comment #7:
Minor problem with the qt patch:
Quitting Octave with a qt plot open results in:
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
Segmentation fault (core dumped)
|
Sun 22 Feb 2015 06:36:25 AM UTC, comment #6:
"Sure, but there's a difference between
octave --no-gui
and
octave-cli "
OK, I did not know that. Thought they were the same.
|
Sun 22 Feb 2015 05:52:48 AM UTC, comment #5:
I tried the patch. Seems to work OK for:
plot(1:100)
print xxx.pdf
works as expected. But, using the save (as)
menu item in the Figure seems to do nothing.
Is this expected?
Do you know of any possible problem side-effects of this
patch? Or, should it be pushed?
|
Sun 22 Feb 2015 12:23:32 AM UTC, comment #4:
Fine with me. I always use --no-gui
in the appropriate .octaverc files.
Thanks for the clarification.
|
Sat 21 Feb 2015 11:22:59 PM UTC, comment #3:
Sure, but there's a difference between
octave --no-gui
and
octave-cli
While 'octave-cli' is linked without QT libs - so no qt toolkit available - 'octave --no-gui' is linked with qt. With attached patch 'octave-cli' still uses fltk and 'octave --no-gui' uses qt.
|
Sat 21 Feb 2015 06:06:04 PM UTC, comment #2:
I assume that Qt graphics toolkit uses the Qt environment to place windows as opposed to an outboard driver. With CLI no Qt environment exists. (Octave is a subprocess in the Qt environment when run as a GUI...only the main Qt process can run graphics.)
I'm pretty sure this is the case because the file _init_qt_.cc appears in the libgui subdirectory. (The function _init_XYZ_() is evaluated inside "graphics_toolkit()".) It's the file libgui/graphics/__init_qt__.cc if you'd like to look more closely.
|
Thu 19 Feb 2015 10:03:31 PM UTC, comment #1:
Has anyone tested this? Could it be a candidate
for release 4.0?
It does seem useful and it would reduce the
differences between GUI and CLI use. And, in
any case, having qt plotting available in CLI
would be helpful.
It seems to me a bit odd that all the changes
appear to be in GUI code. Does anything need
to be done in CLI code?
|
Thu 29 Jan 2015 03:18:41 PM UTC, original submission:
qt graphics toolkit is not initialized when starting with --no-gui option. Attached a quick and dirty fix.
|