GUI work (was: Graphical help browser)

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

GUI work (was: Graphical help browser)

Jordi Gutiérrez Hermoso
2008/11/25 Søren Hauberg <[hidden email]>:
> tir, 25 11 2008 kl. 00:51 -0600, skrev Jordi Gutiérrez Hermoso:
>> What problem are you solving that generating HTML from TeXinfo isn't solving?
>
> I am indeed using 'makeinfo' to generate the HTML files. The help
> browser is just a simple HTML viewer that is integrated with Octave.

I know that until I have contributed any substantial code myself I
probably don't have a right to form opinions in our meritocracy... but
could I kindly suggest that we focus efforts on a single project
instead of branching forever new individual projects? QtOctave already
has an HTML documentation browser, and I've been spending the past few
days reading about Qt and ptys and jwe's idea[1] of how to properly
implement a GUI so that I can try to fix QtOctave's Terminal widget,
and much of QtOctave, which will probably have to be substantially
changed in order to properly interact with Octave; I still haven't
seen how encapsulated is the Octave interaction. I am a bit dismayed
that there doesn't seem to be a ready-made Qt widget to do what jwe
suggests, although it clearly can be done in Qt, as KDE applications
like Kate or Kdevelop embed a console which interacts with ptys. I am
hoping that I may be able to rip out that KDE code and use it with
QtOctave instead of the current implementation.

There is a problem in that ptys are Unix-specific; our Windows users
might not be able to benefit unless I'm mistaken about this. I am not
personally too concerned about this possible shortcoming myself,
though.

I think John Swenson has already implemented most of the Octave-side
necessities for this idea to work in the octave_server class; is this
correct? I'm trying to unite these efforts into a proper GUI, and I've
got the time and motivation to work on this right now. I don't know if
there's a language barrier with working with QtOctave, as Pedro Lucas
occasionally works in Spanish instead of English (e.g. in the svn
logs), but shouldn't we be concentrating on the GUI that currently
seems to be having the most development?

- Jordi G. H.

[1] http://www.nabble.com/GUI-thoughts-td3172755.html#a3172755

Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

Søren Hauberg
tir, 25 11 2008 kl. 10:48 -0600, skrev Jordi Gutiérrez Hermoso:
> QtOctave already
> has an HTML documentation browser,

But can you use it without using QtOctave? Personally, I would find it
very limiting to be using QtOctave. I should say that developing a HTML
documentation browser is trivial these days, so this really isn't much
work.

>  and I've been spending the past few
> days reading about Qt and ptys and jwe's idea[1] of how to properly
> implement a GUI so that I can try to fix QtOctave's Terminal widget,
> and much of QtOctave, which will probably have to be substantially
> changed in order to properly interact with Octave; I still haven't
> seen how encapsulated is the Octave interaction. I am a bit dismayed
> that there doesn't seem to be a ready-made Qt widget to do what jwe
> suggests, although it clearly can be done in Qt, as KDE applications
> like Kate or Kdevelop embed a console which interacts with ptys. I am
> hoping that I may be able to rip out that KDE code and use it with
> QtOctave instead of the current implementation.

>From what I understand the VTE widget for gtk does what is need, and
that this is what John Swensen is using in his work. The impression I
have is that QtOctave does all the easy stuff well, but fails completely
at all the though problems. On the other hand, John Swensens stuff seem
to handle the hard stuff much better. So if you want to help on an
existing project, I would recommend help out John instead of working on
QtOctave (but that's just my opinion).

Søren

Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

John Swensen

On Nov 25, 2008, at 12:11 PM, Søren Hauberg wrote:

> tir, 25 11 2008 kl. 10:48 -0600, skrev Jordi Gutiérrez Hermoso:
>> QtOctave already
>> has an HTML documentation browser,
>
> But can you use it without using QtOctave? Personally, I would find it
> very limiting to be using QtOctave. I should say that developing a  
> HTML
> documentation browser is trivial these days, so this really isn't much
> work.
>
>> and I've been spending the past few
>> days reading about Qt and ptys and jwe's idea[1] of how to properly
>> implement a GUI so that I can try to fix QtOctave's Terminal widget,
>> and much of QtOctave, which will probably have to be substantially
>> changed in order to properly interact with Octave; I still haven't
>> seen how encapsulated is the Octave interaction. I am a bit dismayed
>> that there doesn't seem to be a ready-made Qt widget to do what jwe
>> suggests, although it clearly can be done in Qt, as KDE applications
>> like Kate or Kdevelop embed a console which interacts with ptys. I am
>> hoping that I may be able to rip out that KDE code and use it with
>> QtOctave instead of the current implementation.
>
>> From what I understand the VTE widget for gtk does what is need, and
> that this is what John Swensen is using in his work. The impression I
> have is that QtOctave does all the easy stuff well, but fails  
> completely
> at all the though problems. On the other hand, John Swensens stuff  
> seem
> to handle the hard stuff much better. So if you want to help on an
> existing project, I would recommend help out John instead of working  
> on
> QtOctave (but that's just my opinion).
>
> Søren
>

For my part, I would not be enthused about learning a new UI toolkit  
(e.g. QT).  Several years ago I messed around with QT and got very  
frustrated with the whole SIGNAL/SLOT mechanism and the preprocessor  
hoops you have to jump through.  I was a much less experienced  
programmer back then, so that may have added to my frustrations, but I  
did not have the same problems when trying to pick up GTK/GTKMM.

Once of the biggest plus sides of GTK for this application is the VTE  
terminal widget.  On the UNIXy platforms, it does work with PTYs and  
on the Windows side it uses pipes (or something similar).  The nice  
thing is that regardless of platform the behavior is the same.

I plan  on using the help browser from Søren.  I will probably help to  
by either trying to implement the Xapian algorithm in lookfor, or  
making a compile time check for xapian and simply have lookfor  
conditionally use Xapian.  Either way, as you suggest, I am not going  
to duplicate effort by writing my own help browser.  This will give me  
more time (albeit limited) to work on OctaveDE.

Since I am fairly ignorant on the features of QtOctave, I would be  
interested to know what QtOctave has that OctaveDE doesn't have.  
Maybe QtOctave really is that far ahead of OctaveDE and would merit me  
biting the bullet and switching UI toolkits (you'll probably have to  
do a good job of convincing me though ;) ).  I would also be  
interested to hear from users concerning which feature(s) they would  
like to see most in an IDE.  For your information, here is a list of  
OctaveDE features and what I estimate their completion to be.
1) Octave running in a VTE terminal widget (100%)
2) Command history (100%)
3) Workspace variables (100%)
4) Syntax-highlighting editor (50% : there are still some bugs and  
debugging isn't incorporated yet.  I would also like better emacs  
keybindings, search capability, code completion, blah, blah blah, but  
that is a ways off)
5) Integrated plotting (40% : I still have a bit to implement  
concerning how windowing events get reported back to new property  
system in Octave)
6) Octave server (80% : This is still ongoing, since I assume more  
interaction between Octave and an IDE may be necessary in the  
future).  The octave_server class has the following capabilities,  
although some of them have not been incorporated into the IDE yet:
      a) Get a list of names and details of variables in the current  
scope
      b) Request a complete variable(s) from Octave (not implemented  
in the IDE yet, but Iplan to have a variable preview window)
      c) Get a list of octave command history
      d) Add, remove, and modify breakpoints (this is not implemented  
yet in the server class, but with the new bp_table singleton in the  
Octave sources, I have done it in the non-threadsafe manner from  
OctaveDE)

John Swensen










Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

John W. Eaton-6
On 25-Nov-2008, John Swensen wrote:

| 4) Syntax-highlighting editor (50% : there are still some bugs and  
| debugging isn't incorporated yet.  I would also like better emacs  
| keybindings, search capability, code completion, blah, blah blah, but  
| that is a ways off)

Can't you just use any editor?  Why must we write our own editor?  I
for one would not want a built-in editor that sort of had Emacs-like
keybindings.  I would want Emacs.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

Søren Hauberg
In reply to this post by John Swensen
tir, 25 11 2008 kl. 14:11 -0500, skrev John Swensen:
> 4) Syntax-highlighting editor (50% : there are still some bugs and  
> debugging isn't incorporated yet.  I would also like better emacs  
> keybindings, search capability, code completion, blah, blah blah, but  
> that is a ways off)

Are you implementing your own editor or are you embedding some other
editor? How much communication has to happen between an editor and
Octave? I can think of the following two things that should be possible

1) You should be able to set debug break points, and step through the
code from the editor.

2) You should be able to send part of (or the entire) file you working
on to Octave.

Can't stuff like this be implemented by having some inter-process
communication in Octave (like D-Bus). You would have to extend an editor
to talk to Octave through this inter-process channel (most editors
support plugins).

Anyway, I haven't looked at your work, so I'm asking out of ignorance.

Søren

Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

John Swensen
In reply to this post by John W. Eaton-6

On Nov 25, 2008, at 2:23 PM, John W. Eaton wrote:

> On 25-Nov-2008, John Swensen wrote:
>
> | 4) Syntax-highlighting editor (50% : there are still some bugs and
> | debugging isn't incorporated yet.  I would also like better emacs
> | keybindings, search capability, code completion, blah, blah blah,  
> but
> | that is a ways off)
>
> Can't you just use any editor?  Why must we write our own editor?  I
> for one would not want a built-in editor that sort of had Emacs-like
> keybindings.  I would want Emacs.
>
> jwe

You can definitely use any editor you want, and if there was some way  
to put emacs into the IDE I would do it, but that just simply isn't  
possible.  And in the long run, I am not fully implementing a new  
editor.  I am using a GTK widget called GtkSourceView which is used in  
a whole slew of other IDE's and source code editors.  The nice thing  
about having an incorporated editor of some sort is the ability to set  
and modify breakpoints visually.

For the most part, I agree with the sentiments of many on this list  
that an IDE is probably a draw for entry-level Octave users and the  
features of an IDE become less important as a person becomes more  
experienced.

John Swensen
Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

John Swensen
In reply to this post by Søren Hauberg

On Nov 25, 2008, at 2:27 PM, Søren Hauberg wrote:

> tir, 25 11 2008 kl. 14:11 -0500, skrev John Swensen:
>> 4) Syntax-highlighting editor (50% : there are still some bugs and
>> debugging isn't incorporated yet.  I would also like better emacs
>> keybindings, search capability, code completion, blah, blah blah, but
>> that is a ways off)
>
> Are you implementing your own editor or are you embedding some other
> editor? How much communication has to happen between an editor and
> Octave? I can think of the following two things that should be  
> possible
>
> 1) You should be able to set debug break points, and step through the
> code from the editor.
>
> 2) You should be able to send part of (or the entire) file you working
> on to Octave.
>
> Can't stuff like this be implemented by having some inter-process
> communication in Octave (like D-Bus). You would have to extend an  
> editor
> to talk to Octave through this inter-process channel (most editors
> support plugins).
>
> Anyway, I haven't looked at your work, so I'm asking out of ignorance.
>
> Søren
>

As indicated in the email to JWE, I am using GtkSourceView to  
implement the hard parts of the editor.  The rest of it is just  
managing buffers and opening files and such.

As far as I am concerned, the two things you mentioned plus hover to  
view variables are the only interaction between the editor and Octave  
and they are handled as follows:

1) Setting, clearing, and modifying breakpoints are handled through  
the octave_server class.
2) Just as with the command history, when executing highlighted code  
from the editor, I simply send it to the VTE widget as if someone had  
typed it in.
3) Requesting a variable for displaying when the mouse hovers over a  
variable name in the editor is also handled by octave_server.  Of  
course this feature only makes sense after having hit a breakpoint.

At the present time, I see no other interactions between the editor  
and Octave, but if you see others let me know.

John Swensen


Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

John W. Eaton-6
In reply to this post by John Swensen
On 25-Nov-2008, John Swensen wrote:

| You can definitely use any editor you want, and if there was some way  
| to put emacs into the IDE I would do it, but that just simply isn't  
| possible.

In the NEWS file from the current Emacs development sources, I see:

  * Changes in Emacs 23.1

  ** Improved X Window System support

  [...]

  *** Emacs now supports the XEmbed specification.
  You can embed Emacs in another application on X11.  The new command line
  option --parent-id is used to pass the parent window id to Emacs.  See
  http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html
  for details about XEmbed.

  [...]

Would that be sufficient to allow you to embed Emacs in a gtk
application?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

Jordi Gutiérrez Hermoso
In reply to this post by John Swensen
2008/11/25 John Swensen <[hidden email]>:
> For my part, I would not be enthused about learning a new UI toolkit (e.g.
> QT).

Although I happen to be be at the stage where I'm just learning Qt,
and these are the benefits I see:

    1) Completely free and cross platform. I understand compiling Qt
    on Windows with MinGW is trivial, whereas GTK+ is more of a
    challenge, but correct me if I'm wrong.

    2) Highly themable and uses native widgets. I think that we don't
    really *need* a GUI to begin with; we're just trying to put pretty
    pink bows and unicorns on top of Octave in order to give our users
    warm fuzzy feelings, and I know native widgets are a big warm
    fuzzy feeling, especially for Mac users. I personally am also
    really happy with Qt now that I recently found it can also
    completely emulate GTK+ looks with a specialised theme[1].

    3) Nice tools to go with it (I rather like Qt Designer better than
    Glade).

    4) Big players prefer it, so I am guessing they have good reasons
    for it.

Of course, these are very subjective reasons... but in the grand
tradition of past holy wars like Emacs vs vim and Gnome vs KDE (of
which this present jihad feels like an offshoot), subjectivity is all
we have.

I'm lucky enough right now to just be in the very early learning
stages, so I can still be convinced to switch over to GTK+ or gtkmm,
and I have no code to lose for it (I know we all love our code; I love
mine too). So I'm still open to be convinced to something else. All I
will lose is some momentum and enthusiasm that I had been building up
over the past week or so over Qt.

> Once of the biggest plus sides of GTK for this application is the VTE
> terminal widget.

Btw, why do we even *want* a terminal widget? That seems like a
mistake and limitation of the Matlab GUI that we shouldn't copy. It
just occurred to me that a worksheet interface would be much better
(all text, no need to try to LaTeXify the output). The problem with a
worksheet interface is that I often want to output or browse through
gargantuan outputs, but that seems to be easily fixed: on the
worksheet interface, output fields by default are some maximum
(customisable size) and have a little button on them for expansion in
case you really want all the output right there.

> Either way, as you suggest, I am not going to duplicate effort by
> writing my own help browser.

I admit I had largely forgotten about OctaveDE. I'm glad to hear that
Søren's efforts will build into something else.

> Since I am fairly ignorant on the features of QtOctave, I would be
> interested to know what QtOctave has that OctaveDE doesn't have.

I've toyed very little with it recently, and it hasn't impressed
me... but I'm not impressed by GUIs in general. I hope that Pedro
Lucas will follow this thread and give you a better response.

2008/11/25 John W. Eaton <[hidden email]>:
> On 25-Nov-2008, John Swensen wrote:
>
> | 4) Syntax-highlighting editor
>
> Can't you just use any editor?  Why must we write our own editor?  I
> for one would not want a built-in editor that sort of had Emacs-like
> keybindings.  I would want Emacs.

While I sympathise a lot with jwe here, the whole point of the GUI is
the aforementioned pretty pink bows and unicorns for Octave. Most
users don't think that Emacs counts as pretty pink bows. They want a
"simple" editor (which often has to do more than what "simple" usually
means), and they don't want to learn Emacs-like keys. It probably is
best to use an existing editor, although our target users also like
monolithic packages, editor included. If John Swensen doesn't think
it's a huge task to write a simple editor, I say he can go for it, as
long as there's an option to use Emacs as well. ;-)

Also, building debugging into the editor is going to be important
too... If we use Emacs as the external editor, how are you going to
incorporate debugging between the GUI, Octave, and Emacs?

- Jordi G. H.

[1] http://labs.trolltech.com/page/Projects/Styles/GtkStyle

Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

John W. Eaton-6
On 25-Nov-2008, Jordi Gutiérrez Hermoso wrote:

| Of course, these are very subjective reasons... but in the grand
| tradition of past holy wars like Emacs vs vim and Gnome vs KDE (of
| which this present jihad feels like an offshoot), subjectivity is all
| we have.

I would prefer that Octave be relatively toolkit agnostic since the
preferred toolkit seems to change over time.  It seems to me that it
would be bad to be too tightly coupled with a particular toolkit.

| Btw, why do we even *want* a terminal widget? That seems like a
| mistake and limitation of the Matlab GUI that we shouldn't copy.

It seems natural to me that if you are typing commands to an
interpreter, that the results appear interspersed with the commands
you type.  That way you know which commands produced which results.

| It
| just occurred to me that a worksheet interface would be much better
| (all text, no need to try to LaTeXify the output).

LaTeXify what output?  It would help me if you could explain more
clearly what you mean by "worksheet interface".

| While I sympathise a lot with jwe here, the whole point of the GUI is
| the aforementioned pretty pink bows and unicorns for Octave. Most
| users don't think that Emacs counts as pretty pink bows. They want a
| "simple" editor (which often has to do more than what "simple" usually
| means), and they don't want to learn Emacs-like keys.

Emacs can be a simple editor.  When you start a current Emacs on a
modern system with X11, you get familiar "File" "Edit" "Options"
... buttons, and you can start typing immediately to insert text.
Arrow keys move the cursor around.  That's all you need right?  I
think it is what most users expect these days when they type into a
text widget in a browser, no?  What more do you want or need?

jwe

Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

David Grundberg
In reply to this post by Jordi Gutiérrez Hermoso
Jordi Gutiérrez Hermoso skrev:

> Although I happen to be be at the stage where I'm just learning Qt,
> and these are the benefits I see:
>
>     1) Completely free and cross platform. I understand compiling Qt
>     on Windows with MinGW is trivial, whereas GTK+ is more of a
>     challenge, but correct me if I'm wrong.
>
>     2) Highly themable and uses native widgets. I think that we don't
>     really *need* a GUI to begin with; we're just trying to put pretty
>     pink bows and unicorns on top of Octave in order to give our users
>     warm fuzzy feelings, and I know native widgets are a big warm
>     fuzzy feeling, especially for Mac users. I personally am also
>     really happy with Qt now that I recently found it can also
>     completely emulate GTK+ looks with a specialised theme[1].
>
>     3) Nice tools to go with it (I rather like Qt Designer better than
>     Glade).
>
>     4) Big players prefer it, so I am guessing they have good reasons
>     for it.
>  

I don't think Qt is a meta-toolkit, i.e. just because it has native
components/commands/widgets and you use this to create a GUI, the
program will still be a Qt program, and will not look like a native
win32 or GTK+ program. This is a common misconception though, I mean,
GTK+ is also themable, and it's possible to make e.g. buttons to look
like the user's "native" buttons. But the layout padding will be totally
off, the menus will have the items in wrong order and the shortcuts will
be wrong for any platform but the one it was designed for. This is true
for Qt too, or any other multiplatform toolkit.

Neither wxWidgets, GTK+ or Qt makes it possible to design once and get a
native look-and-feel across all platforms. (Trust me, I recently tried
all these toolkits out.) Most of them don't even have basic things like
a layout manager that automatically selects the right padding for the
current platform. If one wants a truly native gui, one must take the
platform differences into consideration and carefully design the gui for
each platform. I think it's better to actually run the native toolkit
for each platform you want your program to run on. (Sorry wxWidgets)
There are no shortcuts to true native experience.

Basically what I'm saying is, if you want your program to run on MacOS
X, design everything in detail to be exactly like a MacOS X application.
The easiest way to do this is to run Apple's toolkit. The same thing
goes for every other desktop environment (GTK+ is easiest for GNOME, Qt
for KDE, WinForms/win32 for Windows, etc..)

Just my .02 crowns...

David
Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

Søren Hauberg
In reply to this post by John Swensen
tir, 25 11 2008 kl. 14:48 -0500, skrev John Swensen:
> As indicated in the email to JWE, I am using GtkSourceView to  
> implement the hard parts of the editor.  The rest of it is just  
> managing buffers and opening files and such.

Yeah, GtkSourceView is really nice -- it does the heavy lifting, and
it's easy to use.

> At the present time, I see no other interactions between the editor  
> and Octave, but if you see others let me know.

I can't think of anything else. So, the integration of an editor and
Octave only requires little. So, wouldn't it be better to run the editor
in a separate process and use some means of inter-process communication
to handle the integration? That way it would be easier to extend
$MY_EDITOR to integrate with Octave.

Søren

Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

Søren Hauberg
In reply to this post by Jordi Gutiérrez Hermoso
tir, 25 11 2008 kl. 13:58 -0600, skrev Jordi Gutiérrez Hermoso:
>     1) Completely free and cross platform. I understand compiling Qt
>     on Windows with MinGW is trivial, whereas GTK+ is more of a
>     challenge, but correct me if I'm wrong.

I'm under the impression that gtk works easily with mingw, but I haven't
used windows in a decade, so I'm as far from being an expert as
possible. But see http://live.gnome.org/gtkmm/MSWindows for details.

>     3) Nice tools to go with it (I rather like Qt Designer better than
>     Glade).

John, do you actually use such a tool in OctaveDE? I didn't for the help
browser, as it seems to be in the way for such a simple GUI.

>     4) Big players prefer it, so I am guessing they have good reasons
>     for it.

Really? I was under the impression that Qt is mostly used in embedded
applications. But hey, I don't really know...

> Of course, these are very subjective reasons... but in the grand
> tradition of past holy wars like Emacs vs vim and Gnome vs KDE (of
> which this present jihad feels like an offshoot), subjectivity is all
> we have.

Yay, we can a flame-war :-)

Søren

Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

John Swensen

On Nov 25, 2008, at 3:35 PM, Søren Hauberg wrote:

> tir, 25 11 2008 kl. 13:58 -0600, skrev Jordi Gutiérrez Hermoso:
>>    1) Completely free and cross platform. I understand compiling Qt
>>    on Windows with MinGW is trivial, whereas GTK+ is more of a
>>    challenge, but correct me if I'm wrong.
>
> I'm under the impression that gtk works easily with mingw, but I  
> haven't
> used windows in a decade, so I'm as far from being an expert as
> possible. But see http://live.gnome.org/gtkmm/MSWindows for details.
>
>>    3) Nice tools to go with it (I rather like Qt Designer better than
>>    Glade).
>
> John, do you actually use such a tool in OctaveDE? I didn't for the  
> help
> browser, as it seems to be in the way for such a simple GUI.
>
>>    4) Big players prefer it, so I am guessing they have good reasons
>>    for it.
>
> Really? I was under the impression that Qt is mostly used in embedded
> applications. But hey, I don't really know...
>
>> Of course, these are very subjective reasons... but in the grand
>> tradition of past holy wars like Emacs vs vim and Gnome vs KDE (of
>> which this present jihad feels like an offshoot), subjectivity is all
>> we have.
>
> Yay, we can a flame-war :-)
>
> Søren
>

1) Michael Goffioul had to build some of the libraries by hand to get  
OctaveDE working on Windows.  I'm not sure if there were a lot of  
patches needed, or just that the packages weren't available pre-
compiled.

3) I haven't used a UI designer since the days when I was first  
learning Java.  Because of the dockable widget I use for OctaveDE, I  
couldn't have used the glade UI builder anyway.  However, at some  
point I have to use libglade to store the user's preferred/previous  
layout so I can restore it when it loads again.

It's starting to get cold here in Baltimore, but flames are  
unnecessary ;)

John

Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

Jordi Gutiérrez Hermoso
Apologies for responding to several people at once. If you prefer
separate emails per response, let me know and I'll break it up.

2008/11/25 John W. Eaton <[hidden email]>:
> I would prefer that Octave be relatively toolkit agnostic since the
> preferred toolkit seems to change over time.  It seems to me that it
> would be bad to be too tightly coupled with a particular toolkit.

I think we need an executive decision here. The past work that has
been going on for the past several years with 7 or 8 or however many
different aborted GUI attempts and we *still* don't have anything to
show to console-phobic users is a big problem. We'll have to make a
choice and stick to it, and no choice is perfect, but there must be a
least bad choice. :-(

> LaTeXify what output?  It would help me if you could explain more
> clearly what you mean by "worksheet interface".

I mean something like what you get when you embed a Maxima session in
TeXmacs... Now, hear me out, that also sounded like a stupid idea to
me for Octave because I'm so used to the Octave prompt, but it could
make a lot of sense if it's properly executed. It would negate the
need for a command history in a dockable window as in Matlab, since
past commands are visible right there in the buffer, and you can
intuitively scroll up to edit them... large output by default gets
truncated, so your worksheet doesn't overflow with
garbage... copy-pasting with a mouse becomes more intuitive too. It
seems like an overall better idea than just trying to put a terminal
with helper windows like Matlab does.

> | While I sympathise a lot with jwe here, the whole point of the GUI is
> | the aforementioned pretty pink bows and unicorns for Octave. Most
> | users don't think that Emacs counts as pretty pink bows. They want a
> | "simple" editor (which often has to do more than what "simple" usually
> | means), and they don't want to learn Emacs-like keys.
>
> Emacs can be a simple editor.  When you start a current Emacs on a
> modern system with X11, you get familiar "File" "Edit" "Options"
> ... buttons, and you can start typing immediately to insert text.
> Arrow keys move the cursor around.  That's all you need right? 

Not quite. Unfortunately, it has become almost universal that C-x is
"cut", C-c is "paste", C-z is "undo" and C-v is "paste". I am guessing
that someone out there must have done a "non-GNU keybinding theme",
but I can't imagine how it could possibly work properly with Emacs.

That still leaves the problem of making three apps cooperate (GUI,
Emacs, and Octave) when debugging instead of just two (GUI, Octave).

2008/11/25 Søren Hauberg <[hidden email]>:
> tir, 25 11 2008 kl. 13:58 -0600, skrev Jordi Gutiérrez Hermoso:
>>     1) Completely free and cross platform. I understand compiling Qt
>>     on Windows with MinGW is trivial, whereas GTK+ is more of a
>>     challenge, but correct me if I'm wrong.
>
> I'm under the impression that gtk works easily with mingw, but I haven't
> used windows in a decade,

That's good to know. Like I said, I'm not intrinsically adverse to
GTK+, if it works, great. I just want to choose something already so I
can work with it too.

>>     3) Nice tools to go with it (I rather like Qt Designer better than
>>     Glade).
>
> John, do you actually use such a tool in OctaveDE? I didn't for the help
> browser, as it seems to be in the way for such a simple GUI.

As soon as you do anything significant, I would rather be able to
layout widgets visually than not. I would also look at your layouts
visually instead of reading through your source code for anything
significant sort of layouting.

>>     4) Big players prefer it, so I am guessing they have good reasons
>>     for it.
>
> Really? I was under the impression that Qt is mostly used in embedded
> applications. But hey, I don't really know...

Skype, Google Earth, those are two of the biggest I can think
of. Qutecom née Wengophone also uses Qt, but that's a much smaller
app.

> Yay, we can a flame-war :-)

Well, let's keep it friendly. :-)


2008/11/25 David Grundberg <[hidden email]>:
> I don't think Qt is a meta-toolkit, i.e. just because it has native
> components/commands/widgets and you use this to create a GUI, the program
> will still be a Qt program, and will not look like a native win32 or GTK+
> program.

I was under the impression that Skype and Google Earth looked native
in each of their environments. Was I mistaken?



2008/11/25 John Swensen <[hidden email]>:
> 3) I haven't used a UI designer since the days when I was first learning
> Java.  Because of the dockable widget I use for OctaveDE, I couldn't have
> used the glade UI builder anyway.

Qt Designer has dockable widgets; it's overall a very nice design (but
I could be wrong about things; again, I'm still learning it).

- Jordi G. H.

Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

David Grundberg
In reply to this post by John Swensen
John Swensen skrev:
>
>
> 3) I haven't used a UI designer since the days when I was first
> learning Java.  Because of the dockable widget I use for OctaveDE, I
> couldn't have used the glade UI builder anyway.  However, at some
> point I have to use libglade to store the user's preferred/previous
> layout so I can restore it when it loads again.
>

Just thought I'd point out that libglade isn't designed to store user
preferences. For that matter, it doesn't have a "save" functionality
either AFAIK.

OT: Is there absolutely nothing one can do to make this list cc
automatically on reply?
Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

bpabbott
Administrator
n Tuesday, November 25, 2008, at 03:58PM, "David Grundberg" <[hidden email]> wrote:

>John Swensen skrev:
>>
>>
>> 3) I haven't used a UI designer since the days when I was first
>> learning Java.  Because of the dockable widget I use for OctaveDE, I
>> couldn't have used the glade UI builder anyway.  However, at some
>> point I have to use libglade to store the user's preferred/previous
>> layout so I can restore it when it loads again.
>>
>
>Just thought I'd point out that libglade isn't designed to store user
>preferences. For that matter, it doesn't have a "save" functionality
>either AFAIK.
>
>OT: Is there absolutely nothing one can do to make this list cc
>automatically on reply?
>

I assume you tried "reply all"?

What email client are you running?

Ben
Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

David Grundberg
In reply to this post by Jordi Gutiérrez Hermoso
Jordi Gutiérrez Hermoso skrev:

> 2008/11/25 David Grundberg <[hidden email] <mailto:[hidden email]>>:
> > I don't think Qt is a meta-toolkit, i.e. just because it has native
> > components/commands/widgets and you use this to create a GUI, the
> program
> > will still be a Qt program, and will not look like a native win32 or
> GTK+
> > program.
>
> I was under the impression that Skype and Google Earth looked native
> in each of their environments. Was I mistaken?
Looking and behaving are two different things.

Make no mistake, they probably worked a lot to make it happen. It's like
I said, they probably designed the layout specifically for each
platform. There's no way they just designed it on one platform and pop!
it looked great and worked exactly right (in regard to user expectations
such as mnemonics) on the other one too. There are probably a lot of
layout ifdefs, I'd suspect.

This being said, a lot of cross-platform applications are designed for
Windos only, and most users on "other" platforms (except mac users) are
used to Windows shortcuts etc, and they get by. Still, it's technically
wrong, since a GNOME user who haven't used Windows would be frustrated
since the shortcuts would be wrong, and the settings dialog wouldn't
work (as they expected).

Google Earth isn't really a good application to discuss, since part of
the user experience is exploration, and the gui isn't designed to be
familiar, it's supposed to be cool and Web 2.0 or whatever. Also, mayor
part of the user interaction is with a custom component, the 3d view.

Haven't used Skype for a long time, so I can't really relate.
Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

Michael Goffioul
In reply to this post by John Swensen
On Tue, Nov 25, 2008 at 8:46 PM, John Swensen <[hidden email]> wrote:
> 1) Michael Goffioul had to build some of the libraries by hand to get
> OctaveDE working on Windows.  I'm not sure if there were a lot of patches
> needed, or just that the packages weren't available pre-compiled.

If I could compile GTK+ (and all deps) with VC++, I guess you can
assume it would be even simpler with MinGW. In most cases, problems
were related to build system (autotools+libtool are rather anti-VC++)
no to the code.

Michael.
Reply | Threaded
Open this post in threaded view
|

Re: GUI work (was: Graphical help browser)

Michael Goffioul
In reply to this post by John Swensen
On Tue, Nov 25, 2008 at 7:11 PM, John Swensen <[hidden email]> wrote:
> 5) Integrated plotting (40% : I still have a bit to implement concerning how
> windowing events get reported back to new property system in Octave)

Concerning this point, there are still things lying around in my (too long)
TODO list. These are related to the fact that the GUI and octave runs in
different threads. There are operations that happen in the GUI with immediate
effect, but this can imply to run some octave code, which must be run in
the octave thread.

Think for instance about 3D-rotating a plot: you want the rotation to follow
your mouse seemlessly (without any delay). This rotation is typically
performed by changing View property and redrawing. If you want responsiveness,
you'll do that in the GUI thread. Now, if there's a listener attached to View
property, this has to be run in the octave thread.

To handle such situation, my idea was to modify how octave executes
listeners and make it thread aware: if a listener execution request is made
from the octave thread, run it immediately, otherwise queue it for later
execution in the octave thread.

The other solution is to block the GUI thread until the octave thread has
run executed the listener. But the problem here is that the only way to
trigger octave/GUI communication is during readline event_hook, which is
executed every 100ms (by default) [1]. This introduces a significant delay in
the GUI process and you can be sure people will complain. You can have
a feeling of such delay in the current FLTK backend: event processing is
done synchronously with octave, every 100ms; this is noticeable when
you draw a zoom box or rotate the axes.

Now to give my 0.02 about the GUI/toolkit discussion, like John, I also
think the that octave code base should be toolkit agnostic. But OTOH
it should also provide a good framework to build a GUI around it (like this
thread awareness I was talking about previously). That is we should try
to factorize the code as much as possible. In the end, we should also
try to have as few different GUI as possible to avoid manpower spreading.
But I think you won't be able to prevent a few of them, at least the
GTK+/Qt duality. If you focus on GTK+, some time, somewhere, someone
will pop up to write another GUI based on Qt. And vice-versa.

Michael.

[1] AFAIK, there's no way to tell octave "stop what you're doing and execue
me this".
1234