Re: GUI work (was: Graphical help browser)

[Pedro L. Lucas]

2009/1/28, John Swensen <address@hidden>:
>
> On Jan 27, 2009, at 10:28 PM, John W. Eaton wrote:
>
>> On 28-Jan-2009, Pedro L. Lucas wrote:
>>
>> | We need your help to do that. You (or all togheter) must define an
>> | interface for IDEs.
>> | If you don't do that, every IDE will make its own interface ==>
>> Chaos
>>
>> Why should this be my job?  I don't personally care that much about
>> using an IDE for Octave, so I'm fairly certain that I would not be the
>> right person for this job.  Instead, I think the people who care about
>> writing and using IDEs should be involved in the discussion, and
>> should ultimately be the ones to write most of the code.  That doesn't
>> mean I won't have an opinion about what design is good or bad, or what
>> should be included in Octave, but I doubt that I will be making it a
>> priority to come up with something.
>>

Ok.

> I don't think it is your job. In fact, after the patch was applied to
> allow multiple event hooks for the readline idle event, I think there
> is little that need to be added to the core of Octave.  In my case,
> where I run OctaveDE in the same process, I am able to register an
> event hook for direct access to Octave data.  However, even for those
> running in a different process and using IPC, it is really as simple
> as making something like the octave_server class in OctaveDE as an OCT
> file and registering it at startup.  It may make sense to have all the
> IDE people get together and hammer out what this combined IPC and
> direct call class should look like, and try to make it the same for
> all IDEs, but in the long run it may *never* need to be part of Octave
> proper.

input_event_hook is a good solution. I have found some problems in it,
but they are not important. Example: If you connect octave with pipes
to IDE,  input_event_hook doesn't work. You must run Octave with
--read-line option. Try "cat | octave | cat" to check it.


>
>> | If I start to send patches, these patches will work only for
>> QtOctave,
>> | because I will define my own interface.
>>
>> What prevents you from designing something more general?
>>
>> | XML interface sounds good. Easy to use and can be used from all
>> | programming languajes. I think thqt QtOctave can be modified to
>> use it
>> | and so do other IDEs.
>> |
>> | What do you think?
>>
>> Does XML do a good job for large amounts of binary data (like a large
>> double precision floating point array, which is something that is
>> common in Octave)?  If not, then I'm not sure it's really a good
>> choice.
>
> I can imagine the main reason for sending back data will be for
> scalars.  I often use the variable inspector in the Matlab IDE to
> quickly see variable values.  I also often use the mouseover feature
> in the editor after a breakpoint has been hit to see variables.  But,
> you are right that it is rarely for variables larger than 3 elements.
>

I'm writing an experimental XML interface for Octave. I'm going to
check it. Then we can think about it can be useful for IDEs or not. I
think that IDEs written in Java or Python can use this interface.
Moreover other tools can use it, a CAD tool could use Octave for its
calculations. Or tools can send this XML output by sockets and control
several Octave sessions in several computers (parallel computing).


>>
>>
>> Why should the IDE run separately from Octave?  It seems to me that it
>> would be better for it to be more closely integrated.  For example,
>> running in a separate thread.
>>
>>
>> jwe
>
>
> Having made these comments, I also must comment that as I get further
> into my PhD, I am finding less and less time to work on OctaveDE.  In
> fact, the last 2-3 months I probably haven't done more than add a few
> code comments and answer people's emails about it.  So, I don't know
> if a call for help is deemed proper by the list admins, but if someone
> is interested I would be open to some help.  It also might motivate me
> to stay up late a few more nights if I know someone else is depending
> on me making progress for them to make progress.
>
> John Swensen
>