It would be great to see a demo of how well this works the reproduce the kind
of performance you can get with, e.g., ImageView (which in reality is no speed
demon, yet):
using ImageView
include(Pkg.dir("ImageView", "test", "test4d.jl"))
ImageView.view(img)
Now drag the sliders and watch how responsively the display updates. Without
some kind of direct ccall interface with javascript, you're going to have to
ship the data for each frame update.
Or, canvas-drawing like in the lasso selection with Immerse---each mouse drag
generates an event. I imagine that one could probably be handled reasonably
well over a pipe, because there isn't a lot of data.
--Tim
On Wednesday, September 16, 2015 08:00:52 AM Michael Francis wrote:
> Aside from the oddities of websockets I'm not seeing much in the way of an
> issue. Though I'm generating custom events from d3 which get get sent back
> to Julia. Major interactions are defined in a declarative form in JSON (
> and yes are handled by JavaScript ) but where events are relevant to Julia
> I propagate events all the way back.
>
> On Wednesday, September 16, 2015 at 10:35:57 AM UTC-4, Tim Holy wrote:
> > Low-latency callbacks are the main issue, AFAICT. (Assuming you'd rather
> > write
> > your callbacks in julia than javascript.)
> >
> > --Tim
> >
> > On Wednesday, September 16, 2015 07:28:57 AM Michael Francis wrote:
> > > @Tim - can you point me at the gap between Gtk and browser based, I'm
> > > interested as I've spent a fair amount of time in d3/Escher recently and
> > > with the correct
> > > wrapping seems to do most of what I was looking for. We can take this to
> >
> > a
> >
> > > different thread.
> > >
> > > On Wednesday, September 16, 2015 at 10:03:12 AM UTC-4, Tim Holy wrote:
> > > > If the IDE is supposed to include "docked" plotting, then (at least
> > > > currently)
> > > > you're going to get a big loss of functionality if you're using a
> >
> > browser
> >
> > > > compared to what's now possible in Gtk. That said, I don't see any
> >
> > reason
> >
> > > > that
> > > > you really need docked plotting.
> > > >
> > > > Best,
> > > > --Tim
> > > >
> > > > On Wednesday, September 16, 2015 03:55:08 PM Daniel Carrera wrote:
> > > > > Hi all,
> > > > >
> > > > > So... I spent more time looking into how to write a Julia IDE... and
> >
> > I'm
> >
> > > > > not sure it makes sense to write one.
> > > > >
> > > > > I have been investigating the features of Scintilla and
> >
> > GtkSourceView.
> >
> > > > > These are the most obvious components we could use to make the
> >
> > source
> >
> > > > code
> > > >
> > > > > editor. But neither one has enough features that I would be willing
> >
> > to
> >
> > > > use
> > > >
> > > > > it instead of Atom. GtkSourceView doesn't have code folding, and the
> > > >
> > > > issue
> > > >
> > > > > has been pending for over 11 years and nobody is working on it:
> > > > >
> > > > > https://bugzilla.gnome.org/show_bug.cgi?id=134610
> > > > >
> > > > > Scintilla is better in that it does have code folding. But it does
> >
> > not
> >
> > > > have
> > > >
> > > > > a minimap, and the recently added multiple-cursor feature does not
> > > >
> > > > behave
> > > >
> > > > > the way I want when you press Return (it gives you only one new line
> >
> > at
> >
> > > > the
> > > >
> > > > > end).
> > > > >
> > > > > I realize that these are not show-stoppers, but I personally I'm not
> > > >
> > > > likely
> > > >
> > > > > to see a lot of value in a Julia IDE based on Scintilla or
> > > >
> > > > GtkSourceView.
> > > >
> > > > > Maybe Juno is already taking the right approach in extending Atom.
> >
> > Maybe
> >
> > > > > it's possible to stick Atom inside an IDE like you do with
> >
> > Scintilla.
> >
> > > > > Is there any good reason why we should prefer that a Julia IDE be
> > > >
> > > > written
> > > >
> > > > > in Julia? Just asking.
> > > > >
> > > > > Cheers,
> > > > > Daniel.
