GUI integration

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

GUI integration

John W. Eaton
Administrator
I checked in the following change on the GUI branch:

  http://hg.savannah.gnu.org/hgweb/octave/rev/bfc220d1de67

Now when you build Octave (on the GUI branch), ./run-octave will start
the GUI when Octave is running interactively.

We have two new options for Octave:

  --no-gui       disable the gui

  --force-gui    force the gui to start, even when executing
                 commands from a file or processing an --eval string

There is also a separate binary, octave-cli that is not linked with
the gui libraries.  This allows you to save memory and startup time
when you don't plan to use the gui.

Note that this is still a work in progress.  If you are compiling
Octave in a clean build tree, you will need to do the following after
running configure

  make -C src interp-core/mxarray.h

This extra step is needed because the GUI currently includes files
that need mxarray.h but that file is generated as part of building
the liboctinterp library.  I'm looking at making some changes so that
it will not be necessary to manually generate mxarray.h.

jwe
Reply | Threaded
Open this post in threaded view
|

GUI integration

John W. Eaton
Administrator
On 10-Aug-2012, John W. Eaton wrote:

I checked in a few more changes on the GUI branch.

The --enable-gui/--disable-gui option is now set to be enabled by
default.  If you use --disable-gui, the configure script should not
check for the gui toolkit or tools, and the Makefiles should be set up
to avoid building in the GUI directory.

With these changes, building with or without the GUI should work with
the usual autogen.sh, configure, and make process.

Two Octave binaries will be generated (octave and octave-cli).  By
default, the octave binary will start the GUI.  If building with
--disable-gui, then both binaries should be identical.

I think we are ready to merge away the GUI branch, but perhaps there
are some other issues I've missed.  Comments?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: GUI integration

Jacob Dawid
John,
 
I think we are ready to merge away the GUI branch, but perhaps there
are some other issues I've missed.  Comments?

which is the default working directory for the GUI, when run with ./run-octave.sh ? The GUI expects a few file to be in the right place, and I think I have to fix that before a merge.

Jacob 
Reply | Threaded
Open this post in threaded view
|

Re: GUI integration

Michael Goffioul
On Sat, Aug 11, 2012 at 5:11 PM, Jacob Dawid <[hidden email]> wrote:
John,
 
I think we are ready to merge away the GUI branch, but perhaps there
are some other issues I've missed.  Comments?

which is the default working directory for the GUI, when run with ./run-octave.sh ? The GUI expects a few file to be in the right place, and I think I have to fix that before a merge.

At the moment, I'm always seeing an empty file brower dockwindow. Is this related?

Michael.

Reply | Threaded
Open this post in threaded view
|

Re: GUI integration

John W. Eaton
Administrator
In reply to this post by Jacob Dawid
On 11-Aug-2012, Jacob Dawid wrote:

|     I think we are ready to merge away the GUI branch, but perhaps there
|     are some other issues I've missed.  Comments?
|
|
| which is the default working directory for the GUI, when run with ./
| run-octave.sh ? The GUI expects a few file to be in the right place, and I
| think I have to fix that before a merge.

The default working directory will be whatever it is when you execute
the run-octave.sh script.  Normally it would be the top-level build
directory (if you run ./run-octave.sh) but it could be anywhere else
in the filesystem.

What files need to be found?  Can the locations be specified by
command-line arguments or environment variables?  If not, that should
probably be allowed anyway.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: GUI integration

Jacob Dawid
John,

What files need to be found?  Can the locations be specified by
command-line arguments or environment variables?  If not, that should
probably be allowed anyway.

at startup, the GUI checks whether a configuration file exists and - if not - copies the default configuration file into the home directory of the user. But I think, instead of doing that, I can just define default settings hardcoded in a function and write that to a file, so the need for a default configuration file gets eliminated.

The icons are compiled into the binary.

Jacob

PS: What about the GUI flag for octave, so octave can determine whether a GUI is available or not? It should not be a big deal to add the code to launch the texinfo browser in the GUI, we just need to agree upon a flag name.
Reply | Threaded
Open this post in threaded view
|

Re: GUI integration

John W. Eaton
Administrator
On 11-Aug-2012, Jacob Dawid wrote:

|     What files need to be found?  Can the locations be specified by
|     command-line arguments or environment variables?  If not, that should
|     probably be allowed anyway.
|
|
| at startup, the GUI checks whether a configuration file exists and - if not -
| copies the default configuration file into the home directory of the user. But
| I think, instead of doing that, I can just define default settings hardcoded in
| a function and write that to a file, so the need for a default configuration
| file gets eliminated.

I think it would be better to have the defaults in a file.  That way
someone could customize the defaults for new users without having to
recompile.

| PS: What about the GUI flag for octave, so octave can determine whether a GUI
| is available or not? It should not be a big deal to add the code to launch the
| texinfo browser in the GUI, we just need to agree upon a flag name.

How about a "window_system" function that would return "Qt" or "none"?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: GUI integration

John W. Eaton
Administrator
On 11-Aug-2012, John W. Eaton wrote:

| On 11-Aug-2012, Jacob Dawid wrote:
|
| |     What files need to be found?  Can the locations be specified by
| |     command-line arguments or environment variables?  If not, that should
| |     probably be allowed anyway.
| |
| |
| | at startup, the GUI checks whether a configuration file exists and - if not -
| | copies the default configuration file into the home directory of the user. But
| | I think, instead of doing that, I can just define default settings hardcoded in
| | a function and write that to a file, so the need for a default configuration
| | file gets eliminated.
|
| I think it would be better to have the defaults in a file.  That way
| someone could customize the defaults for new users without having to
| recompile.

I checked in the following change:

  http://hg.savannah.gnu.org/hgweb/octave/rev/098546e95a5e

jwe
Reply | Threaded
Open this post in threaded view
|

Re: GUI integration

Mike Miller
On Sat, Aug 11, 2012 at 5:59 PM, John W. Eaton <[hidden email]> wrote:

> On 11-Aug-2012, John W. Eaton wrote:
>
> | On 11-Aug-2012, Jacob Dawid wrote:
> |
> | |     What files need to be found?  Can the locations be specified by
> | |     command-line arguments or environment variables?  If not, that should
> | |     probably be allowed anyway.
> | |
> | |
> | | at startup, the GUI checks whether a configuration file exists and - if not -
> | | copies the default configuration file into the home directory of the user. But
> | | I think, instead of doing that, I can just define default settings hardcoded in
> | | a function and write that to a file, so the need for a default configuration
> | | file gets eliminated.
> |
> | I think it would be better to have the defaults in a file.  That way
> | someone could customize the defaults for new users without having to
> | recompile.
>
> I checked in the following change:
>
>   http://hg.savannah.gnu.org/hgweb/octave/rev/098546e95a5e

With this revision I get a segfault when running after make install
and no ~/.config/octave directory. If I ./run-octave first and let it
create ~/.config/octave, then the installed copy of octave runs fine.
Maybe install_defaults() hasn't been called yet?

Here's a gdb backtrace:
#0  0x00007ffff47e8f4b in std::basic_string<char,
std::char_traits<char>, std::allocator<char>
>::basic_string(std::string const&) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00007ffff4ca0805 in operator+<char, std::char_traits<char>,
std::allocator<char> > (__rhs=..., __lhs=...) at
/usr/include/c++/4.7/bits/basic_string.h:2365
#2  default_qt_settings_file () at ../../../gui/gui/src/resource-manager.cc:67
#3  resource_manager::reload_settings (this=this@entry=0x7ffff4f34630)
    at ../../../gui/gui/src/resource-manager.cc:84
#4  0x00007ffff4ca0b72 in resource_manager::resource_manager (
    this=0x7ffff4f34630) at ../../../gui/gui/src/resource-manager.cc:41
#5  0x00007ffff4c7ed06 in __static_initialization_and_destruction_0 (
    __initialize_p=<optimized out>, __priority=<optimized out>)
    at ../../../gui/gui/src/resource-manager.cc:35
#6  _GLOBAL__sub_I_resource_manager.cc(void) ()
    at ../../../gui/gui/src/resource-manager.cc:1698
#7  0x00007ffff7deaf80 in ?? () from /lib64/ld-linux-x86-64.so.2
#8  0x00007ffff7deb077 in ?? () from /lib64/ld-linux-x86-64.so.2
#9  0x00007ffff7dddb2a in ?? () from /lib64/ld-linux-x86-64.so.2
#10 0x0000000000000001 in ?? ()
#11 0x00007fffffffe313 in ?? ()
#12 0x0000000000000000 in ?? ()

--
mike
Reply | Threaded
Open this post in threaded view
|

Re: GUI integration

John W. Eaton
Administrator
On 11-Aug-2012, Mike Miller wrote:

| On Sat, Aug 11, 2012 at 5:59 PM, John W. Eaton <[hidden email]> wrote:
|
| > I checked in the following change:
| >
| >   http://hg.savannah.gnu.org/hgweb/octave/rev/098546e95a5e
|
| With this revision I get a segfault when running after make install
| and no ~/.config/octave directory. If I ./run-octave first and let it
| create ~/.config/octave, then the installed copy of octave runs fine.
| Maybe install_defaults() hasn't been called yet?
|
| Here's a gdb backtrace:
| #0  0x00007ffff47e8f4b in std::basic_string<char,
| std::char_traits<char>, std::allocator<char>
| >::basic_string(std::string const&) ()
|    from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
| #1  0x00007ffff4ca0805 in operator+<char, std::char_traits<char>,
| std::allocator<char> > (__rhs=..., __lhs=...) at
| /usr/include/c++/4.7/bits/basic_string.h:2365
| #2  default_qt_settings_file () at ../../../gui/gui/src/resource-manager.cc:67

It works for me.

The call to install_defaults happens in octave_initialize_interpreter,
which is the first thing called in main, before calling
octave_start_gui.

Please set a breakpoint in default_qt_settings_file and step through
it and examine the values of Voct_etc_dir and file_ops::dir_sep_str()
before the crash.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: GUI integration

Mike Miller
On Sat, Aug 11, 2012 at 6:37 PM, John W. Eaton wrote:

> On 11-Aug-2012, Mike Miller wrote:
>
> | On Sat, Aug 11, 2012 at 5:59 PM, John W. Eaton <[hidden email]> wrote:
> |
> | > I checked in the following change:
> | >
> | >   http://hg.savannah.gnu.org/hgweb/octave/rev/098546e95a5e
> |
> | With this revision I get a segfault when running after make install
> | and no ~/.config/octave directory. If I ./run-octave first and let it
> | create ~/.config/octave, then the installed copy of octave runs fine.
> | Maybe install_defaults() hasn't been called yet?
> |
> | Here's a gdb backtrace:
> | #0  0x00007ffff47e8f4b in std::basic_string<char,
> | std::char_traits<char>, std::allocator<char>
> | >::basic_string(std::string const&) ()
> |    from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> | #1  0x00007ffff4ca0805 in operator+<char, std::char_traits<char>,
> | std::allocator<char> > (__rhs=..., __lhs=...) at
> | /usr/include/c++/4.7/bits/basic_string.h:2365
> | #2  default_qt_settings_file () at ../../../gui/gui/src/resource-manager.cc:67
>
> It works for me.
>
> The call to install_defaults happens in octave_initialize_interpreter,
> which is the first thing called in main, before calling
> octave_start_gui.
>
> Please set a breakpoint in default_qt_settings_file and step through
> it and examine the values of Voct_etc_dir and file_ops::dir_sep_str()
> before the crash.

Got it, resource_manager is initializing its instance before main is
called, a static singleton rather than created on-demand.

--
mike
Reply | Threaded
Open this post in threaded view
|

Re: GUI integration

Mike Miller
On Sat, Aug 11, 2012 at 6:53 PM, Mike Miller wrote:

> On Sat, Aug 11, 2012 at 6:37 PM, John W. Eaton wrote:
>> On 11-Aug-2012, Mike Miller wrote:
>>
>> | On Sat, Aug 11, 2012 at 5:59 PM, John W. Eaton <[hidden email]> wrote:
>> |
>> | > I checked in the following change:
>> | >
>> | >   http://hg.savannah.gnu.org/hgweb/octave/rev/098546e95a5e
>> |
>> | With this revision I get a segfault when running after make install
>> | and no ~/.config/octave directory. If I ./run-octave first and let it
>> | create ~/.config/octave, then the installed copy of octave runs fine.
>> | Maybe install_defaults() hasn't been called yet?
>> |
>> | Here's a gdb backtrace:
>> | #0  0x00007ffff47e8f4b in std::basic_string<char,
>> | std::char_traits<char>, std::allocator<char>
>> | >::basic_string(std::string const&) ()
>> |    from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>> | #1  0x00007ffff4ca0805 in operator+<char, std::char_traits<char>,
>> | std::allocator<char> > (__rhs=..., __lhs=...) at
>> | /usr/include/c++/4.7/bits/basic_string.h:2365
>> | #2  default_qt_settings_file () at ../../../gui/gui/src/resource-manager.cc:67
>>
>> It works for me.
>>
>> The call to install_defaults happens in octave_initialize_interpreter,
>> which is the first thing called in main, before calling
>> octave_start_gui.
>>
>> Please set a breakpoint in default_qt_settings_file and step through
>> it and examine the values of Voct_etc_dir and file_ops::dir_sep_str()
>> before the crash.
>
> Got it, resource_manager is initializing its instance before main is
> called, a static singleton rather than created on-demand.

Confirmed, the following quick and dirty change gets rid of the
segfault for me. I get the "Welcome to Octave!" dialog again, however
it's still stuck in an endless loop, is this supposed to be working
yet?


diff --git a/gui/src/resource-manager.cc b/gui/src/resource-manager.cc
--- a/gui/src/resource-manager.cc
+++ b/gui/src/resource-manager.cc
@@ -32,7 +32,7 @@

 #include "resource-manager.h"

-resource_manager resource_manager::_singleton;
+resource_manager *resource_manager::_singleton;

 resource_manager::resource_manager ()
 {
diff --git a/gui/src/resource-manager.h b/gui/src/resource-manager.h
--- a/gui/src/resource-manager.h
+++ b/gui/src/resource-manager.h
@@ -32,7 +32,8 @@
   static resource_manager *
   instance ()
   {
-    return &_singleton;
+    if (!_singleton) _singleton = new resource_manager ();
+    return _singleton;
   }

   QSettings *get_settings ();
@@ -50,7 +51,7 @@

   QSettings *_settings;
   QString _home_path;
-  static resource_manager _singleton;
+  static resource_manager *_singleton;
   bool _first_run;
 };



--
mike
Reply | Threaded
Open this post in threaded view
|

Re: GUI integration

Jacob Dawid


Confirmed, the following quick and dirty change gets rid of the
segfault for me. I get the "Welcome to Octave!" dialog again, however
it's still stuck in an endless loop, is this supposed to be working
yet?

It can't find the config file. I will have to fix it, but for a quick solution copy the file "default-settings" to ~/.config/octave-gui/ and rename it to "settings".
Reply | Threaded
Open this post in threaded view
|

Re: GUI integration

Mike Miller
On Sun, Aug 12, 2012 at 10:38:29AM +0200, Jacob Dawid wrote:
> Confirmed, the following quick and dirty change gets rid of the
> > segfault for me. I get the "Welcome to Octave!" dialog again, however
> > it's still stuck in an endless loop, is this supposed to be working
> > yet?
> >
>
> It can't find the config file. I will have to fix it, but for a quick
> solution copy the file "default-settings" to ~/.config/octave-gui/ and
> rename it to "settings".

I know, I just wasn't sure if jwe's changes had addressed that yet.

The path to the file is now gui/default-qt-settings and the destination
path is ~/.config/octave/qt-settings.

Attached is a cleaned up version of the above that initializes
resource_manager using the Octave singleton pattern. This gets rid of
the segfault for me. Look good?

--
mike

rsrcman.diff (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GUI integration

John W. Eaton
Administrator
On 12-Aug-2012, Mike Miller wrote:

| On Sun, Aug 12, 2012 at 10:38:29AM +0200, Jacob Dawid wrote:
| > Confirmed, the following quick and dirty change gets rid of the
| > > segfault for me. I get the "Welcome to Octave!" dialog again, however
| > > it's still stuck in an endless loop, is this supposed to be working
| > > yet?
| > >
| >
| > It can't find the config file. I will have to fix it, but for a quick
| > solution copy the file "default-settings" to ~/.config/octave-gui/ and
| > rename it to "settings".
|
| I know, I just wasn't sure if jwe's changes had addressed that yet.
|
| The path to the file is now gui/default-qt-settings and the destination
| path is ~/.config/octave/qt-settings.

Also, the location of the default-qt-settings file can be specified
by an environment variable and the run-octave script uses that to find
the default file in the source tree.

| Attached is a cleaned up version of the above that initializes
| resource_manager using the Octave singleton pattern. This gets rid of
| the segfault for me. Look good?

It's better than before, yes, so please check it in.

I'd prefer to be using static methods and writing

  resource_manager::reload_settings ();

instead of

  resource_manager::instance()->reload_settings ();

but I can make that change later.  At least with your change we should
avoid the crash that is due to order of static initialization issues.

Thanks,

jwe
Reply | Threaded
Open this post in threaded view
|

Re: GUI integration

Mike Miller
On Sun, Aug 12, 2012 at 10:03 AM, John W. Eaton wrote:

> On 12-Aug-2012, Mike Miller wrote:
>
> | Attached is a cleaned up version of the above that initializes
> | resource_manager using the Octave singleton pattern. This gets rid of
> | the segfault for me. Look good?
>
> It's better than before, yes, so please check it in.
>
> I'd prefer to be using static methods and writing
>
>   resource_manager::reload_settings ();
>
> instead of
>
>   resource_manager::instance()->reload_settings ();
>
> but I can make that change later.  At least with your change we should
> avoid the crash that is due to order of static initialization issues.

Sounds good, checked in as ad9523348676.

Your fix for no X display is also working great, no major remaining
issues for me.

--
mike