State of remote-gui branch

[Ambrevar]

@jmercouris: Any plan regarding the merge of the remote-gui branch? I can help if there is something blocking on the GTK side.

What are the new features?

[jmercouris]

It is basically 100% blocking on the GTK side.

New features:

1. You can run a session across the internet, the core lisp is completely separated from the graphic engine
2. You can run multiple windows and frames
3. The GUI can be written in any library, it communicates via S-XML-RPC
4. Webviews are significantly more fast because they are not tied to any Lisp
5. All JS is asynchronous

so, we basically developed an API for communication between Lisp and the foreign code (aka GTK graphical server, Cocoa graphical server etc)

the API looks like this:

;;; remote.lisp --- remote gui interface

(in-package :next)

;; expose push-key-chord to server endpoint
(import 'push-key-chord :s-xml-rpc-exports)

(defclass window ()
  ((id :accessor id)))

(defclass remote-interface ()
  ((host :accessor host :initform "localhost")
   (port :accessor port :initform 8082)
   (url :accessor url :initform "/RPC2")
   (windows :accessor windows :initform (make-hash-table))))

(defmethod start-interface ((interface remote-interface))
  (s-xml-rpc:start-xml-rpc-server :port 8081))

(defmethod kill-interface ((interface remote-interface)))

(defmethod window-make ((interface remote-interface))
  (with-slots (host port url windows) interface
    (let ((window (s-xml-rpc:xml-rpc-call
                   (s-xml-rpc:encode-xml-rpc-call "window.make")
                   :host host :port port :url url)))
      (setf (gethash window windows) (make-instance 'window))
      window)))

(defmethod window-delete ((interface remote-interface) window)
  (with-slots (host port url windows) interface
    (setf (gethash window windows) nil)
    (s-xml-rpc:xml-rpc-call
     (s-xml-rpc:encode-xml-rpc-call "window.delete" window)
     :host host :port port :url url)))

(defmethod window-switch ((interface remote-interface) window)
  (with-slots (host port url) interface
    (s-xml-rpc:xml-rpc-call
     (s-xml-rpc:encode-xml-rpc-call "window.switch" window)
     :host host :port port :url url)))

(defmethod window-active ((interface remote-interface))
  (with-slots (host port url) interface
    (s-xml-rpc:xml-rpc-call
     (s-xml-rpc:encode-xml-rpc-call "window.active")
     :host host :port port :url url)))

(defmethod minibuffer-set-height ((interface remote-interface) window height)
  (with-slots (host port url) interface
    (s-xml-rpc:xml-rpc-call
     (s-xml-rpc:encode-xml-rpc-call "minibuffer.set.height" window height)
     :host host :port port :url url)))

(defmethod minibuffer-execute-javascript ((interface remote-interface) window javascript)
  (with-slots (host port url) interface
    (s-xml-rpc:xml-rpc-call
     (s-xml-rpc:encode-xml-rpc-call "minibuffer.execute.javascript" window javascript)
     :host host :port port :url url)))

(defmethod buffer-make ((interface remote-interface))
  (with-slots (host port url) interface
    (s-xml-rpc:xml-rpc-call
     (s-xml-rpc:encode-xml-rpc-call "buffer.make")
     :host host :port port :url url)))

(defmethod buffer-delete ((interface remote-interface) buffer)
  (with-slots (host port url) interface
    (s-xml-rpc:xml-rpc-call
     (s-xml-rpc:encode-xml-rpc-call "buffer.delete" buffer)
     :host host :port port :url url)))

(defmethod set-visible-buffer-for-pane ((interface remote-interface) pane window)
  (declare (ignore view window)))

(defmethod web-view-set-url ((interface remote-interface) view url)
  (declare (ignore view url)))

(defmethod web-view-get-url ((interface remote-interface) view)
  (declare (ignore view)))

(defmethod web-view-execute ((interface remote-interface) view script &optional callback)
  (declare (ignore view script callback)))

(defmethod web-view-set-url-loaded-callback ((interface remote-interface) view function)
  (declare (ignore view function)))

it is of course still a work in progress, but yeah. You can take a look at the GTK repository, and see that there is a lot of work remaining: https://github.com/next-browser/next-gtk

On the other side, the Cocoa library can provide a pretty good reference implementation: https://github.com/next-browser/next-cocoa.

the Cocoa library is also having some minor issues...(mainly with threading)

So, more or less, to get GTK done, one would need to implement the protocol defined above. If any of the above does not make sense, I can make a document showing exactly how the protocol is supposed to work.

-John

[Ambrevar]

Very well. I can start working on that interface just now!

"master" and "remote-gui" have diverged. Is there anything special that needs to be backported from master?

If any of the above does not make sense, I can make a document showing exactly how the protocol is supposed to work.

At first glance the interface seems quite clear, but I wouldn't mind extra documentation if you have time :)

2. You can run multiple windows and frames

Can you define "windows" and "frames" here? In the Emacs sense? Does the current GTK implementation support multiple windows or frames?

[jmercouris]

I do in fact mean windows and frames in the emacs sense (in my message), but in the API, and in the Next project in general, their meanings are meant in the normal way.

I’ll try to write out a good design document when I have the chance,

thanks

-John

On May 22, 2018, at 16:14, Pierre Neidhardt notifications@github.com wrote:

Very well. I can start working on that interface just now!

"master" and "remote-gui" have diverged. Is there anything special that needs to be backported from master?

If any of the above does not make sense, I can make a document showing exactly how the protocol is supposed to work.

At first glance the interface seems quite clear, but I wouldn't mind extra documentation if you have time :)

2. You can run multiple windows and frames

Can you define "windows" and "frames" here? In the Emacs sense? Does the current GTK implementation support multiple windows or frames? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.