GUI design

[Jordi Gutiérrez Hermoso-2]

On 28 March 2012 04:55, Daniel J Sebald <[hidden email]> wrote:
> To me, an IDE has to bring something to the table.  It has to convey
> information and organize one's work in a way that makes the user more
> productive.

But the GUI is not for you. You're already productive. It's for the
people who think they can't be productive with a CLI, whether they're
right or not is irrelevant. It's what they think.

- Jordi G. H.

[John W. Eaton]

Jacob,

First, let me say that the current version of the IDE is much improved
and seems to work well, at least judging from the limited testing I've
done.  I think the appearance is nearly what we want.  The defaults
seem mostly good at this point.  I have just a few specific comments
below.

On 27-Mar-2012, Jacob Dawid wrote:

|     * An area for the main command window that presents the Octave
|       prompt and displays the output from commands, just as you
|       currently see when running Octave in a terminal window.
|       [...]
|
| Works.
|
|     * An area to display command history.  It should be possible to
|       select and paste previous commands from the history window into
|       the command window.
|
| Works.
|
|     * An area to display the contents of the current workspace.  It
|       should be possible to display the contents of variables from this
|       list.
|
| Works.
|
|     * Octave's doc command should display a formatted version of the
|       manual in a separate window.  It is essential that this window be
|       visible simultaneously with the command window.  We should not
|       use a tabbed interface for this feature.  It should be possible to
|       choose which program is used to browse the documentation.
|
| Works. You can either choose to have it tabbed or aligned parallel -
| which is also true for editor windows. The default at startup is the
| tabbed mode, probably a mistake I make, because now people seem to
| think it's all tabbed and needs to be replaced.

How about starting with only the command window and making the
documentation browser a separate pop-up window that is accessible
through the "Help" menu item?

|     * When there is an error running an Octave script, an editor should
|       pop up and place the cursor at the line of the error.
|
| Does not work yet.
|
|     * You should be able to interact with the debugger through the
|       editor.
|
| Does not work yet.
|
|     * It is absolutely essential that the choice of editor is
|       configurable.  It must be possible to use Emacs for this purpose.
|
| Works.
|
|     * The windows used to display the OpenGL-based graphics must use the
|       same GUI toolkit that we use for the rest of the IDE.
|
| Not implemented yet.
|
|     * Functions like uigetfile should use the same GUI toolkit that we
|       use for the IDE.
|
| I can't comment on this, but I assume it is not implemented yet.

It's not.  We need to replace src/DLD_FUNTIONS/__init_fltk__.cc with a
Qt version to match your Qt-based IDE.

|     The Octave IDE will be used by novices.  It is NOT the place for UI
|     innovation.  We should use GUI/IDE features that are proven, familiar,
|     and easy to work with.  We do not need dockable widgets.  The ability
|     to change the relative sizes of the command, workspace, and history
|     windows would be useful, but we do not need to be able to rearrange
|     their locations within the main window.  Tabbed interfaces will not be
|     used.  Octave's IDE does not need a built-in IRC client, and will
|     not include one.
|
| The IRC Client has already been moved to the help menu. I would
| agree if I knew how to start an external IRC Client - then it does
| not make sense to have one built-in.

OK.  I think this should be made a separate program so that it will be
easier for users to invoke their favorite client through some script.
Shouldn't it be possible to start an external irc client program using
a call to "system".

|     Since people seem to like it, following the design of "GUI Octave"
|     makes sense to me.  But it is not necessary to include every feature
|     of that interface in the first version of Octave's IDE.  It would be
|     far better to have just the features above working reliably than to
|     have many more features that are only partially implemented or buggy.
|
|     Comments?
|    
|     jwe
|
| From my point of view there are still three essential things to do:
| - fix crashes that are caused through thread-insafety

Yes, this must be done.  I don't know how you are doing things now,
but band-aids for Octave thread safety are probably not going to do
it.  I think you have to ensure that Octave is not called except when
it is safe to do so.  So you can queue events for Octave to process,
then let Octave handle them when it is safe to do so (like in the
readline idle loop) but you can't just call internals of Octave at any
time.

| - modify variables graphically (ie. matrices in a table, strings in
|   line edit dialogs)

This would be nice.  If it is easy to do, then great.  But I don't see
it as essential for the first release.  So if it is difficult then it
could certainly wait until later.

| - debugging with the built-in editor, setting breakpoints etc.

I think this is a fairly important feature, but again if it turns out
to be really difficult, it could probably wait.

jwe

[John W. Eaton]

On 27-Mar-2012, Michael Goffioul wrote:

| On Tue, Mar 27, 2012 at 8:59 PM, John W. Eaton <[hidden email]> wrote:
| > The Octave IDE will be used by novices.  It is NOT the place for UI
| > innovation.  We should use GUI/IDE features that are proven, familiar,
| > and easy to work with.  We do not need dockable widgets.  The ability
| > to change the relative sizes of the command, workspace, and history
| > windows would be useful, but we do not need to be able to rearrange
| > their locations within the main window.  Tabbed interfaces will not be
| > used
|
| I'm not going to argue forever about this, so I'll just explain my
| opinion once...
|
| I'm not desperately pushing for dockable widgets, but from my
| experience I would definitely start with a flexible window arrangement
| system. This will define the overall framework for the entire IDE. If
| you don't get it right from the beginning, or go for the more
| straightforward solution of a static window arrangement, it'll be more
| difficult to move away from it later on. I think it's worth spending
| time on that from the start.
|
| The problem I see with a more static layout is that users will most
| likely want to change it. Everybody has his own opinion about how
| window should be arranged, what's important, what should be always
| visible, what is never used... A generic dockable system[1] provides
| the flexibility to make everybody happy, as it's entirely under the
| control of the user.
|
| Michael.
|
| [1]: by this, I really mean a system where windows can be docked,
| popped out, split horizontally or vertically or merged into tabs.

I've looked at the current IDE and the dockable panels seem OK.  And
since they are already done, I don't see the point of removing them.

However, it seems to me that this is primarily a feature for
experienced users, and that novices will accidentally rearrange the
layout and find themselves confused.  Also, since changes to the
layout seem to be persistent, restarting Octave will not restore the
system to a safe and known state.  I think that sort of thing is
likely to cause frustration for new users.  So can we disable dockable
widgets by default?  Is there a way we could provide a menu item so
that the dockable widgets are locked in place by default?

jwe

[Michael Goffioul]

On Wed, Mar 28, 2012 at 6:36 PM, John W. Eaton <[hidden email]> wrote:
> |     * Functions like uigetfile should use the same GUI toolkit that we
> |       use for the IDE.
> |
> | I can't comment on this, but I assume it is not implemented yet.
>
> It's not.  We need to replace src/DLD_FUNTIONS/__init_fltk__.cc with a
> Qt version to match your Qt-based IDE.

FWIW, this is available in QtHandles.

Michael.

[Jordi Gutiérrez Hermoso-2]

On 28 March 2012 14:41, Michael Goffioul <[hidden email]> wrote:

> On Wed, Mar 28, 2012 at 6:36 PM, John W. Eaton <[hidden email]> wrote:
>> |     * Functions like uigetfile should use the same GUI toolkit that we
>> |       use for the IDE.
>> |
>> | I can't comment on this, but I assume it is not implemented yet.
>>
>> It's not.  We need to replace src/DLD_FUNTIONS/__init_fltk__.cc with a
>> Qt version to match your Qt-based IDE.
>
> FWIW, this is available in QtHandles.

Can you push QtHandles on the dev branch, please? Or maybe on the gui branch?

- Jordi G. H.

[Daniel Sebald]

On 03/28/2012 05:37 AM, Richard Crozier wrote:

> On 28/03/2012 11:06, Daniel J Sebald wrote:
>> On 03/28/2012 04:07 AM, Richard Crozier wrote:
>>> On 28/03/2012 09:55, Daniel J Sebald wrote:
>>>
>>
>
>> I think what Michael and I are saying is
>>
>> Nothing =>  Lay groundwork for GUI/IDE code that can grow =>  Get the ball
>> rolling =>  When there are a reasonable amount of features on the order
>> of GUI Octave, release the inaugural version =>  Improvements
>>
>
> Isn't this what I proposed? I agree with Michael about the rearrangement
> of windows by the way, but this already works according to Jacob. Maybe
> I needed to say:
>
> Nothing =>  GUI Octave feature set =>  GUI Octave feature set plus some of
> The Mathworks feature set =>  Mathworks feature set =>   Improvements
>
> As I understand it the devs are close to achieving the GUI Octave
> feature set already, or have possibly exceeded them?
>
>> And the big part is laying the groundwork because the group needs to
>> decide on what GUI building utilities and technology to use across
>> platforms, so on.  I assume it is across platforms because 1) Robert
>> points out an IDE may be the only viable option under Windows, 2) John
>> states that Octave needs to still be functional in its current
>> form--implying the IDE would also be on unix-based systems.
>>
>
> I was under the impression this was decided, i.e. Qt, which is
> cross-platform.
>
>> I know at least once John has stated "I wish I hadn't gone that route"
>> with regard to plotting.  The problem is that the GUI Octave direct
>> approach could be the same thing:
>>
>> Nothing =>  GUI Octave =>  Dead end =>  Struggle to advance things for
>> years =>  Startover =>  Mathworks feature set =>  Improvements
>>
>
>
> I'm not sure I understand this, I meant to replicate the features of GUI
> Octave in, say, Qt. Not the actual code implementation of GUI Octave
> exactly. How would this result in a dead end? This would be extensible
> to the new desired features later.

It sounds like developers have looked at the GUI development tools
enough to conclude that Qt provides the power and flexibility for future
growth of an IDE.  Correct?


> I am confused about what you are saying I think, I thought you wanted to
> not produce a GUI with features the same as GUI Octave and hold off
> until there were all the features you suggested implemented.

Not all, but something more substantial than what GUI Octave offers.
Yes, that would be my preference, but...


>  Whereas I
> think it better to produce something with the minimum feature set of GUI
> Octave, and add further features later, as a GUI with these features is
> better than nothing in my opinion.

...it sounds like the majority want to get something out there that
works in Windows.

>> And again, I point out that one doesn't have to copy the look and feel
>> of Mathworks or GUI Octave.  IF there are better ways of organizing and
>> presenting things, that would be welcome as I see it.
>>
>
>
> Sure, this is where I would see the 'Improvements' stage, but how
> different can a GUI be to these examples? There's only so many ways to
> organise an IDE. Most of the IDEs I have seen are very similar, e.g.
> Visual Studio, QT Creator, Matlab, Eclipse, Code::Blocks etc. They're
> all just collections of windows with stuff in them are they not?

Well, in the broad universal set of computer programs all those you
described fall in the "collections of windows with stuff in them"
category.  But they all have their own features unique to what they do.
  Visual Studio is for programming.  Mathworks' IDE has some programming
elements--watch variables, step through a debugger, etc.--but it should
have features with working with and processing data to truly.  I listed
a few things that would be nice but probably aren't in Matlab's IDE: the
two monitor feature for example.  There is this whole new dimension of
"processing and working with data", i.e., extracting and conveying
information which lends itself to new features.

It's certainly better to start out small and let the look and feel
develop on its own.  If one works toward GUI Octave look and feel then
goes some other direction it will just confuse users.


> I'm most interested in the debugging features, but others will have their
> own priorities.

JWE speculated on the debugging feature.  I'll respond to that in a
separate email.

A lot of the work concerning an IDE at the start is just getting
organized so that developers can move.  Here are some thoughts:

Come up with a name for what will be Octave's IDE, and I think we agree
now that it is IDE we're aiming for.  This will make clear what is being
discussed.  Expressions like devs GUI is slightly obscure.  If I'm not
mistaken, Octave developers already have a start...something that was
called QtOctave perhaps?  But QtOctave isn't a good name because it
implies Qt and who knows if down the road Qt doesn't work out or
something better comes along.  It's the look and feel and features that
sort of define the IDE.  I've suggested one name: IDEO -- marketing
gimmick being "Your ideas + Octave = IDEO"

Maybe a Wiki is a good thing for organizing development.  John gave a
list of desired features for the first beta version.  But that sort of
thing gets lost in a discussion list.  If a Wiki described the expected
features, roadmap, time frame, so on, it might focus things a bit.

Will the cross platform IDE look exactly the same on all systems?

Will an IDE be in the same source tree as Octave?  Or does it make sense
to have an ancillary project?  It might be best to not have Octave
compilation dependent on the presence of a library needed for the IDE.

IDE development presents a challenge in the sense that it is difficult
to convey GUI and feature ideas via written text in a discussion list.
How often has someone tried describing something to you and it doesn't
quite make sense, but then when one sees it on the screen or in action
it's voila?  Is there some way to assist a team of developers in that
regard when working with Qt?

Dan

[Daniel Sebald]

On 03/27/2012 02:59 PM, John W. Eaton wrote:

>    * When there is an error running an Octave script, an editor should
>      pop up and place the cursor at the line of the error.

The line number and file is displayed on the screen.  Having the IDE
capture that info is the issue.  What is the preferred means for that?


>    * You should be able to interact with the debugger through the
>      editor.

Same thing here.  There needs to be a way for the IDE to capture things
appearing in the command line window such as

keyboard: stopped in /home/sebald/matlab/debug/test.m at line 3


>    * It is absolutely essential that the choice of editor is
>      configurable.  It must be possible to use Emacs for this purpose.

That makes the debugging feature a bit tricky.  If an outside editor is
used, the debugger window should probably be disabled from modifying
code, simply reload the file and show stepping information every time
the code is re-run.

Or are you saying that Emacs is a good candidate for interacting with a
debugger because there is some way to direct escape commands to it?


> The Octave IDE will be used by novices.  It is NOT the place for UI
> innovation.  We should use GUI/IDE features that are proven, familiar,
> and easy to work with.

Good GUI/IDE design should be comprehendible no matter the complexity.
Also, I would assume some level of computer experience from new users of
Octave.  If the group in question is students, they will have used all
sorts of programs in different courses by the time of being introduced
to Octave.

Dan

[Przemek Klosowski-7]

On 03/29/2012 01:35 AM, Daniel J Sebald wrote:

> That makes the debugging feature a bit tricky.  If an outside editor is
> used, the debugger window should probably be disabled from modifying
> code, simply reload the file and show stepping information every time
> the code is re-run.
>
> Or are you saying that Emacs is a good candidate for interacting with a
> debugger because there is some way to direct escape commands to it?

Emacs is really a full-blown LISP environment that happens to have a
screen-oriented text editing commands built in. The escape commands just
call underlying Emacs LISP functions, and you can call them via various
RPC-like mechanisms as well.

[Daniel Sebald]

On 03/29/2012 12:35 AM, Daniel J Sebald wrote:
> On 03/27/2012 02:59 PM, John W. Eaton wrote:
[snip]
>> * You should be able to interact with the debugger through the
>> editor.
>
> Same thing here. There needs to be a way for the IDE to capture things
> appearing in the command line window such as
>
> keyboard: stopped in /home/sebald/matlab/debug/test.m at line 3

And IDE programmers should note that there can be link aliases in the
file name.  For example, I opened something in the "octave" directory,
but that's a link and the original file/directory is what appears in the
Octave description.

Dan

[Daniel Sebald]

On 03/28/2012 11:49 PM, Daniel J Sebald wrote:

[snip]

> It sounds like developers have looked at the GUI development tools
> enough to conclude that Qt provides the power and flexibility for future
> growth of an IDE. Correct?

The Qt license appears to be the GNU "lesser" GPL.  Have people thought
through whether that is suitable for Octave's normal GNU GPL?

Dan

[Jordi Gutiérrez Hermoso-2]

On 29 March 2012 13:26, Daniel J Sebald <[hidden email]> wrote:
> The Qt license appears to be the GNU "lesser" GPL.  Have people thought
> through whether that is suitable for Octave's normal GNU GPL?

Yeah, the LGPL is fine.

- Jordi G. H.

[Michael Goffioul]

On Thu, Mar 29, 2012 at 6:26 PM, Daniel J Sebald <[hidden email]> wrote:

> On 03/28/2012 11:49 PM, Daniel J Sebald wrote:
>
> [snip]
>
>> It sounds like developers have looked at the GUI development tools
>> enough to conclude that Qt provides the power and flexibility for future
>> growth of an IDE. Correct?
>
>
> The Qt license appears to be the GNU "lesser" GPL.  Have people thought
> through whether that is suitable for Octave's normal GNU GPL?

This is not true. Qt is distributed under GPLv3, LGPL v2 or commercial
license. See http://qt.nokia.com/downloads/downloads#qt-lib

Michael.


>
> Dan

[Daniel Sebald]

On 03/29/2012 01:45 PM, Michael Goffioul wrote:

> On Thu, Mar 29, 2012 at 6:26 PM, Daniel J Sebald<[hidden email]>  wrote:
>> On 03/28/2012 11:49 PM, Daniel J Sebald wrote:
>>
>> [snip]
>>
>>> It sounds like developers have looked at the GUI development tools
>>> enough to conclude that Qt provides the power and flexibility for future
>>> growth of an IDE. Correct?
>>
>>
>> The Qt license appears to be the GNU "lesser" GPL.  Have people thought
>> through whether that is suitable for Octave's normal GNU GPL?
>
> This is not true. Qt is distributed under GPLv3, LGPL v2 or commercial
> license. See http://qt.nokia.com/downloads/downloads#qt-lib

The L of LGPL stands for "lesser".  I'm not sure what the difference is
between the LGPL license and the GPL license, but apparently they are
different:

http://qt.nokia.com/products/licensing

The "lesser" license is a successor of the "library" license:

http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html

I read the following last night, and that is what prompts me to ask if
due consideration was given:

"This license, the Lesser General Public License, applies to some
specially designated software packages--typically libraries--of the Free
Software Foundation and other authors who decide to use it. You can use
it too, but we suggest you first think carefully about whether this
license or the ordinary General Public License is the better strategy to
use in any particular case, based on the explanations below."

Dan

[Jordi Gutiérrez Hermoso-2]

On 29 March 2012 14:54, Daniel J Sebald <[hidden email]> wrote:
> The L of LGPL stands for "lesser".  I'm not sure what the difference is
> between the LGPL license and the GPL license, but apparently they are
> different:

This essay explains what the LGPL is and how it's meant to be used:

    http://www.gnu.org/licenses/why-not-lgpl.html

I noticed earlier in the discussion about GUI Octave that you seemed
surprised that the GPL doesn't allow certain things. Indeed, it
doesn't. The GPL forbids distributing non-free derivative works. And
here "free" means the same thing that it means in the phrase "a free
man". It doesn't mean a man you don't have to pay for, because that
would be a slave, and slaves are certainly not free. ;-)

Briefly, the LGPL explicitly allows linking with non-free works and
distributing the result, but the GPL doesn't:

    http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License#Differences_from_the_GPL

- Jordi G. H.

[Michael Goffioul]

On Thu, Mar 29, 2012 at 7:54 PM, Daniel J Sebald <[hidden email]> wrote:

> On 03/29/2012 01:45 PM, Michael Goffioul wrote:
>>
>> On Thu, Mar 29, 2012 at 6:26 PM, Daniel J Sebald<[hidden email]>
>>  wrote:
>>>
>>> On 03/28/2012 11:49 PM, Daniel J Sebald wrote:
>>>
>>> [snip]
>>>
>>>> It sounds like developers have looked at the GUI development tools
>>>> enough to conclude that Qt provides the power and flexibility for future
>>>> growth of an IDE. Correct?
>>>
>>>
>>>
>>> The Qt license appears to be the GNU "lesser" GPL.  Have people thought
>>> through whether that is suitable for Octave's normal GNU GPL?
>>
>>
>> This is not true. Qt is distributed under GPLv3, LGPL v2 or commercial
>> license. See http://qt.nokia.com/downloads/downloads#qt-lib
>
>
> The L of LGPL stands for "lesser".  I'm not sure what the difference is
> between the LGPL license and the GPL license, but apparently they are
> different:

Basically, LGPL allows you to distribute software linked against the
LGPL component in binary-only format. So you can build closed-source
software on LGPL, which is not possible with GPL. Many GNU libraries
are distributed under LGPL, while the executables are covered by GPL.
Qt used to be GPL or commercial-only [1], which meant you could only
build closed-source products by buying a Qt license, which was/is
quite expensive. When Trolltech was bought by Nokia, one of the first
change was to add LGPL license (I think the idea at that time was at
least partially to foster development of applications for Nokia
phones).

Michael.

[1] There used to be also a GPL exception for KDE libraries, in the
form of QPL; this was made obsolete when Qt got licensed under LGPL.

[Daniel Sebald]

On 03/29/2012 02:07 PM, Michael Goffioul wrote:

> On Thu, Mar 29, 2012 at 7:54 PM, Daniel J Sebald<[hidden email]>  wrote:
>> On 03/29/2012 01:45 PM, Michael Goffioul wrote:
>>>
>>> On Thu, Mar 29, 2012 at 6:26 PM, Daniel J Sebald<[hidden email]>
>>>   wrote:
>>>>
>>>> On 03/28/2012 11:49 PM, Daniel J Sebald wrote:
>>>>
>>>> [snip]
>>>>
>>>>> It sounds like developers have looked at the GUI development tools
>>>>> enough to conclude that Qt provides the power and flexibility for future
>>>>> growth of an IDE. Correct?
>>>>
>>>>
>>>>
>>>> The Qt license appears to be the GNU "lesser" GPL.  Have people thought
>>>> through whether that is suitable for Octave's normal GNU GPL?
>>>
>>>
>>> This is not true. Qt is distributed under GPLv3, LGPL v2 or commercial
>>> license. See http://qt.nokia.com/downloads/downloads#qt-lib
>>
>>
>> The L of LGPL stands for "lesser".  I'm not sure what the difference is
>> between the LGPL license and the GPL license, but apparently they are
>> different:
>
> Basically, LGPL allows you to distribute software linked against the
> LGPL component in binary-only format. So you can build closed-source
> software on LGPL, which is not possible with GPL.

And Octave, being GPL and non-proprietary doesn't need to concern itself
with the GPL/LGPL nuance.


>  Many GNU libraries
> are distributed under LGPL, while the executables are covered by GPL.
> Qt used to be GPL or commercial-only [1], which meant you could only
> build closed-source products by buying a Qt license, which was/is
> quite expensive. When Trolltech was bought by Nokia, one of the first
> change was to add LGPL license (I think the idea at that time was at
> least partially to foster development of applications for Nokia
> phones).

OK, guess I understand the reason for the LGPL since there is a linking
together of binaries either in the executable file or the code space.

Dan

[Daniel Sebald]

On 03/29/2012 02:06 PM, Jordi Gutiérrez Hermoso wrote:

> On 29 March 2012 14:54, Daniel J Sebald<[hidden email]>  wrote:
>> The L of LGPL stands for "lesser".  I'm not sure what the difference is
>> between the LGPL license and the GPL license, but apparently they are
>> different:
>
> This essay explains what the LGPL is and how it's meant to be used:
>
>      http://www.gnu.org/licenses/why-not-lgpl.html
>
> I noticed earlier in the discussion about GUI Octave that you seemed
> surprised that the GPL doesn't allow certain things.

I see GUI Octave as an aggregate.  Octave is not linked in the code
space.  The L of LGPL started out as "library" for a reason I would
assume.  Some day there will be a "CGPL", where the "C" stands for
"cloud" at first, but then later it will stand for "community".

>  Indeed, it
> doesn't. The GPL forbids distributing non-free derivative works. And
> here "free" means the same thing that it means in the phrase "a free
> man". It doesn't mean a man you don't have to pay for, because that
> would be a slave, and slaves are certainly not free. ;-)
>
> Briefly, the LGPL explicitly allows linking with non-free works and
> distributing the result, but the GPL doesn't:
>
>      http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License#Differences_from_the_GPL

Yes, I see.  And it reads a bit like hypocritical condescension, in my
opinion.  At the end of the description it says:

"Proprietary software developers, seeking to deny the free competition
an important advantage, will try to convince authors not to contribute
libraries to the GPL-covered collection. For example, they may appeal to
the ego, promising “more users for this library” if we let them use the
code in proprietary software products. Popularity is tempting, and it is
easy for a library developer to rationalize the idea that boosting the
popularity of that one library is what the community needs above all.

But we should not listen to these temptations, because we can achieve
much more if we stand together."

All right.  ALL FOR ONE AND ONE FOR ALL!!

But near the front of the description it reads:

"Using the ordinary GPL is not advantageous for every library. There are
reasons that can make it better to use the Lesser GPL in certain cases.
The most common case is when a free library's features are readily
available for proprietary software through other alternative libraries.
In that case, the library cannot give free software any particular
advantage, so it is better to use the Lesser GPL for that library.

This is why we used the Lesser GPL for the GNU C library. After all,
there are plenty of other C libraries; using the GPL for ours would have
driven proprietary software developers to use another—no problem for
them, only for us."

Huh?  But, but... but you just said don't give in to the temptation.

Dan

[Judd Storrs-2]

I think at this point we can all agree that Jordi doesn't like that
GUI Octave is closed source and feels its developer is an ungrateful
antisocial slime ball. Unfortunately, being an ungrateful antisocial
slime ball is not GPL (or even GPLv3) incompatible. I shudder to think
what Jordi's email conversation with the developer of GUI Octave
looked like and how it reflected on Octave.


--judd

[Jordi Gutiérrez Hermoso-2]

On 29 March 2012 18:53, Judd Storrs <[hidden email]> wrote:
> I think at this point we can all agree that Jordi doesn't like that
> GUI Octave is closed source

I don't mind that so much. I mind that it's non-free and we can't fix
it.

> and feels its developer is an ungrateful antisocial slime ball.

I don't think he's ungrateful. I don't think he's a slimeball. I think
he's a little strange for thinking that accepting changes to his
source code will tarnish his artistic integrity. I think he's confused
by the non-free Windows culture of not sharing code, that sharing code
is somehow harmful. I don't think he's a bad guy. He's after all
providing GUI Octave seemingly pretty selflessly. I think his only
satisfaction is the gratification of preserving his artistic integriy
on his source code. I think we can invite him to instead have the
gratification of forming part of a larger community of Octave users
and developers, to work with us, instead of against us.

> Unfortunately, being an ungrateful antisocial slime ball is not GPL
> (or even GPLv3) incompatible.

Some antisocial behaviour is GPL incompatible, such as creating
non-free derivative works. I don't know what you are referring to with
"slime ball", so I don't know if that's GPL incompatible or not.

> I shudder to think what Jordi's email conversation with the
> developer of GUI Octave looked like and how it reflected on Octave.

I think I was quite civil to him and did not call him antisocial nor a
slime ball. I can't reproduce my conversation with him because it was
private and I don't have his permission to do so. You can ask him
yourself, if you want, how my conversation with him went.

In fact, I'm CC'ing here. You can ask him yourself if I was as hostile
to him as you think I am.

Hello, Joaquim. Would you reconsider releasing the source code to GUI
Octave? It is very awkward that you are making non-free code based on
copylefted free code. I have tried on several occasions to appease
your requests, to explain why Octave 3.4.3 isn't connecting to GUI
Octave, and to reassure you that we are not purposely trying to
sabotage GUI Octave, and to help fix the problems you were having with
running a debugger from GUI Octave.

Do you think we have not done enough to work towards you? Is there
something else you would like from us in order to release your source
under a free license?

- Jordi G. H.

[Judd Storrs-2]

2012/3/30 Jordi Gutiérrez Hermoso <[hidden email]>:
> I don't think he's ungrateful. I don't think he's a slimeball.

Ok. Perhaps I'm projecting.

Nevertheless it is completely inappropriate for this piece of
closed-source software to occupy the name "GUI Octave" with the
hostile anti free-software stance the developer has taken. It must be
renamed. It advertises itself as a "completely free" wrapper to "GNU
Octave". It must be explicit that it is not free software as
understood by GNU. This is deceptive.


--judd