Incoperating into more frontends about xrl HOT 11 CLOSED

I guess this makes it sort of related to #22

Hope what I wrote was somewhat easy to understand, I should really document gxi better

from xrl.

Hey thanks for the interest. I'd very much like to see xrl used by as many frontend's as possible and would help you in any way that i can. For you to use the frontend trait with GTK that would require a sync channel of some kind, something like std::sync::mpsc::channel you could then create a frontend struct that forwards events from xi-core through the channel. You would then have to run the tokio reactor in a different thread using thread::spawn

pub struct Frontend(Sender<T>);

impl Frontend {
 ...
}

The other end of the channel can be placed in your MainWin struct and you could fetch the events appropriately from GTK's event loop. But XRL is based on the Tokio event loop and IIRC GTK has to use it's own event loop, if thats the case i think it would make more sense to not use the frontend trait and use XRL for serializing/deserializing & you could use the line cache struct as well.

from xrl.

But XRL is based on the Tokio event loop and IIRC GTK has to use it's own event loop

Maybe we could add a glib based event loop, will look into that.

you could use the line cache struct as well.

Yup, let's see how I can merge gxi's current implementation and xrls. Will work on this tomorrow then :)

from xrl.

A glib based event loop would be nice. Im not sure how easy it would be to make that work, but i know relm integrates tokio and GTK, so it must be somewhat possible.

If there's anything i can do to help please let me know

from xrl.

Alright, so I've just looked into this. How well does using the system instance of xi-editor work for you? Right now in gxi I just build xi-editor's core-lib into gxi and start it on another thread, which I later listen on for messages. I personally prefer this approach to not depend on foreign binaries (and also comes with the advantage that gxi is tested against one specific xi-editor version), but I suppose I wouldn't mind using xrl's approach either.

How do you handle the dependency on the xi-editor binary? Cargo doesn't allow binary dependencies yet and about every other distribution scheme I can come up with sounds pretty messy. I guess I could put the xi-editor binary into /usr/libexec/gxi or similar to avoid clashing with other editors - or do you just error out if you can't find the binary and want the user to install it on their own?

from xrl.

It works pretty well. Your correct we just inform people to make sure xi-core is installed in $PATH, But i think xrl should be able to use both ways. A long time ago i was pondering creating a XiCore trait with 2 implementations SystemXi and CoreLib that would allow using xi however you wish but i never got around to implementing it. WOuld you have a better idea on how to implement it?

from xrl.

Hm, I would've done that by using features, like this:

+[features]
+
+# Run a xi-editor binary in a tokio based eventloop
+default = ["eventloop"]
+
+eventloop = ["tokio", "tokio-codec", "tokio-process"]
+
+# Run an xi-editor instance built into the binary in a seperate thread
+thread = ["xi-core-lib", "xi-rpc"]

And depending on what feature is chosen I'd either use the core-external-binary module or a core-in-thread (names are subject to change :P) module. This makes this a build-time setting, but that isn't much of a problem IMHO.

from xrl.

I guess I'll use the tokio based stuff for now in gxi and change this later on.

from xrl.

Alright, it compiles now with #24, but needs way more work to get back to the previous functionality. Will keep you updated once it works! :)

from xrl.

Now to clean up my mess :)

from xrl.

Now that gxi uses xrl I'm going to close this. I have one remaining question though: Does xi-term somehow make the linecache async, @little-dude? I'm currently having some difficulty with that in gxi. When I open big files in gxi (let's say gxi's edit_view.rs) with syntax highlighting enabled and do something which affects lots of lines (e.g. insert a "`, which will quote all following lines and as such Xi will re-send me all these lines with the changed styles) gxi gets stuck for a bit until all the updates are processed, which is elegy annoying (but this also happened with gxi's old linecache).

from xrl.