Autor: Teodoro Santoni Data: Dla: Hendrik Boom CC: dng Temat: Re: [Dng] OT: separate GUI from commands (was: Re: The more things
change, the more they remain the same
On Wed, May 27, 2015 at 06:12:15AM -0400, Hendrik Boom wrote: > On Wed, May 27, 2015 at 03:32:00PM +0200, Laurent Bercot wrote:
>
> > As a rule of thumb, developers should always use the smallest possible
> > amount of dependencies for a project, and clearly separate layers - e.g.
> > if a project comes with an engine and a GUI, then the engine should come
> > as a command-line tool in its own package with no dependencies on graphical
> > stuff, which would be the role of the GUI package. But I'm a dinosaur AND
> > a fan of minimalism, so I don't expect many people to think like me.
>
> I mean this as a serious question, not as a piece of sarcasm,
> though it could easily be misconstrued as such.
>
> I am testing the limits of the advice to separate interaction from
> command line, though. Sometimes limit testing leads to discoveries.
>
> I'm in the process of writing (yet) a(nother) editor and output formatter,
> and on reading this, I started to wonder -- just how could one separate
> a command-line version from the UI? I can see that the output
> formatter can be so separated (and very usefully), but the actual
> editing?
It's a matter of building an editor like leafpad, or building a vi or an ed.
What are you working on?
If you're working on the latter, take vim, neovim and vis as examples: they do
a lot more than writing in place, save, colorize and undo. Thus, decoupling
the engine from the UI means that you have already on draft what does the
editor do and how as for example as a list of commands. Then the UI, as a
command line client, probably would behave like a shell script, or like ed or
ex; as a full blown editor, no matter if curses or GUI, probably would grab
commands (through modes or menus) and input, and synchronizes with the engine
(which executes special commands, changes files, write to them, and whatever
else). If everything is in the same process, this synchronization is mostly
done as code execution; otherwise it's developed in a client-server model: the
UI shows to the user her/his edits, while passing messages to the engine, for
example sending text or msgpack through a socket read by clients (where the
user types) and the editor engine. This aids mostly code reuse, because you
could have any kind of GUI and the powerful set of commands you feel comfy
about for editing text.