Skip to content
This repository has been archived by the owner on Jun 30, 2023. It is now read-only.

unify python gui's #23

Open
timeyyy opened this issue May 28, 2016 · 2 comments
Open

unify python gui's #23

timeyyy opened this issue May 28, 2016 · 2 comments

Comments

@timeyyy
Copy link
Contributor

timeyyy commented May 28, 2016

I see benefit for developers and coders in sharing code for the python guis.
If we build the right abstractions it would mean implementers of other toolkits could very easily:

  • test
  • documentation
  • api
  • even implementation ( see below)

The logic required for going from nvim to a gui could be abstracted away so implementers only have
to add a bunch of methods such as, delete line, insert line etc etc.

Tarruda has mentioned the idea of doing a gtk library in c. We could also implement hooks for wrapping nvim gui c libraries into python here.

Is this type of thinking feasible cross language?

@bfredl
Copy link
Member

bfredl commented May 28, 2016

IIRC @tarruda :s plan was to implement part of the event processing and what now is screen.py as a reusable c library (also used by the builtin TUI), so that the individual gui implementation only need to care about the grid and not the details of the ui update events.

@tarruda
Copy link
Member

tarruda commented May 29, 2016

so that the individual gui implementation only need to care about the grid and not the details of the ui update events.

If a gtk widget is also implemented, then gtk applications would only need to feed msgpack-rpc data to the widget without worrying about how to draw the grid

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants